Appcelerator Titanium JavaScript Code Completion in IntelliJ

Tags

, , ,

This blog post shows you how to add code completion and documentation lookup support for Appcelerator Titanium in IntelliJ IDEA. This is mostly building on top of the posts made by Amit Kothari and James Low.

Generate the Titanium JavaScript file

The first step is to get your hands on a JavaScript file containing the API and documentation with JSDoc tags by using the utilities described here, or by grabbing the file from my GitHub repository. Note that the file in this repository is specifically for Titanium Mobile.

Method 1: Include the JavaScript file as part of the project

The easiest method is to simply place the JavaScript within the project directory so that IntelliJ can parse it, as described in Amit’s blog post.

Method 2: Add the Titanium JavaScript file as a global library

The other method is to add the Titanium JavaScript file generated above as a global library in IntelliJ as described here. The steps in the article are summarised below:

  1. Click on the JavaScript Libraries item in the Project Settings section in Preferences.
  2. Click on the Configure global JavaScript libraries available on the right hand pane, which will open up the Project Structure dialog.
  3. Click on the Global Libraries item in the Platform Settings section.
  4. Click on the + (plus) button on the top of the dialog, which will add a new global library
  5. Give the library a name, for example Titanium Mobile, and attach the source JavaScript file by clicking the Attach Debug Version(s) button and selecting the file in the dialog.
  6. Click OK

Now all we need to do is associate our Appcelerator projects with this library, which is done by:

  1. Click on the Usage Scope sub menu under the JavaScript Libraries item available under Project Settings in Preferences. This should show the project in the right hand panel.
  2. Click on the libraries, which will bring up a list of libraries.
  3. Select the Titanium library defined previously.

Result

This should now enable code completion and documentation lookup as shown below:

Converting the Appcelerator Titanium JSON API to JavaScript

Tags

, , , , ,

I’ve been spending some time playing around with Appcelerator Titanium Mobile recently, and been doing most of it using Titanium Studio, which is an IDE built on top of Aptana, which in turn is built on top of Eclipse.

Although I’m a big fan of Eclipse and all the work they’ve done for the development community, I’ve found myself recently moving towards the JetBrains suite of products, specially due to their amazing integration with all the major languages and frameworks. Stuff just works!

Unfortunately getting code completion and documentation lookup working for Titanium in IntelliJ was harder that it should be due to the Titanium API being exposed through JSON in a proprietary format called JSCA. I’m guessing the reason for this is due to the various programming languages that they support for Titanium, and maintaining the API documentation for all the different languages in a manner supported for each of the languages would turn into a nightmare pretty quickly. However for my purposes all I needed was a properly annotated JavaScript file that I can use with IntelliJ. Since this wasn’t readily available, I resorted to creating my own by parsing the Titanium JSON API.

You can find the utilities I used to convert the JSON JSCA API under my GitHub account here, along with the resulting Titanium Mobile JavaScript file. Unfortunately some of the identifiers used in Titanium do not convert to valid JavaScript, but nonetheless I found the generated file quite useful. I simply added this file as a JavaScript module in IntelliJ and got pretty good completion and documentation working in the projects I was playing around with.

Credit:

I got the idea of generating this JavaScript after reading about a similar converter in my good friend Amit Kothari’s blog post. The script was written in PHP by James Low. Unfortunately this script changes some the identifiers to get around the problem of invalid JavaScript identifiers and the documentation uses ScriptDoc tags, both of which doesn’t work very well with IntelliJ.

Sharing (Export/Import) IntelliJ IDEA Code Style Formatters

Tags

, ,

Unlike Eclipse, IntelliJ doesn’t seem to provide a way to export and import code formatters through the GUI. Instead we need to manually copy a particular file from/to an directory created by IntelliJ to store code styles.

Exporting a Code Style Scheme

The formatting options used by IDEA can be customised through the Code Styles section in the Settings (or Preferences in OS X) window.

After customising the styling rules to what you like, click on the Use per project settings radio button, and click on the Export button. This will bring up a dialog asking for the name of the code style scheme that you’ve created, and once you’ve entered an appropriate name, click on the OK button to save this scheme. This will now create and save a XML file with the given name within the codestyles directory and is equivalent to Eclipse’s export code formatter option, except you cannot specify the location you want the file to be saved. The directory this file is placed in is platform dependent and is listed in the next section.

You can now use this file to share the code formatting rules used in your project with the other members of your team.

Code Style Directory Location

The code styles directory is platform dependent, and is available in the locations listed below. Please note that you need to replace <product-name> with the name and version of IDEA you use.

Mac OS X:

~/Library/Preferences/<product-name>/codestyles/

Linux:

~/.<product-name>/config/codeStyles/

Windows:

<User home>\.<product-name>\config\codeStyles\

Importing a Code Style Scheme

If you want to use a code style scheme that was created and shared by someone else, then simply copy the file over to the relevant codestyles directory for your platform as listed in the previous section. After restarting the IDE, you should see this new scheme under the Code Styles section in the Settings window.

Running integration/acceptance tests in JBoss 7 using Cargo

Tags

, , , , , , , ,

Some integration tests and almost all acceptance tests require the availability of a deployed application, and it’s always a good idea to run your tests by deploying the application into the target container itself. Almost all the applications I develop end up running on JBoss, and given JBoss 7′s amazing startup times and Cargo supporting JBoss 7 since version 1.1.2, there’s almost no excuse for not running (at least most of) these tests within the main build cycle itself.

The following is a brief outline of how you can configure your Maven build to startup JBoss, run integration tests and shutdown the container once done. Since I don’t like depending on the availability of a JBoss installation as a prerequisite for a build, we will also download the application server as part of the build and process.

More information on the Cargo’s Maven integration can be found in the Cargo Maven 2 Reference Guide, and information on Cargo’s support for JBoss 7 can be found in the Cargo JBoss 7 page.

The End Result

We can download JBoss 7, unpack it, start up the container, deploy the app, run integration tests, and shutdown the container by including the following in our pom.xml and replacing the deployable section with the details of the application artifact. Please check the following sections for a more complete explanation of what’s been done here.

<build>
  <plugins>
    <plugin>
      <groupId>org.codehaus.cargo</groupId>
      <artifactId>cargo-maven2-plugin</artifactId>
      <!-- JBoss 7 is only supported from this version onwards -->
      <version>1.1.2</version>
      <configuration>
        <container>
          <containerId>jboss7x</containerId>
          <zipUrlInstaller>
            <url>http://download.jboss.org/jbossas/7.0/jboss-as-7.0.0.Final/jboss-as-7.0.0.Final.zip</url>
          </zipUrlInstaller>
        </container>
        <deployer>
          <type>installed</type>
          <deployables>
            <deployable>
              <!-- Artifact to deploy; change to your artifact -->
              <groupId>com.navinpeiris.examples</groupId>
              <artifactId>example-artifact</artifactId>
              <type>war</type>
              <!-- Don't forget to change the following to your apps URL -->
              <pingURL>http://localhost:8080/myapp</pingURL>
              <!-- This is the default; make larger if required -->
              <pingTimeout>20000</pingTimeout>
            </deployable>
          </deployables>
        </deployer>
      </configuration>
      <executions>
        <execution>
          <id>start-container</id>
          <phase>pre-integration-test</phase>
          <goals>
            <goal>start</goal>
            <goal>deploy</goal>
          </goals>
        </execution>
        <execution>
          <id>stop-container</id>
          <phase>post-integration-test</phase>
          <goals>
            <goal>stop</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

The Various Parts

This section aims to provide a more detailed explanation of the what’s been done in the pom file extract above.

Downloading and Unpacking JBoss

Cargo can be configured to download and unpack a container within the target directory by specifying the URL to a ZIP of the container in the zipUrlInstaller element within the container section as follows:

<container>
  <containerId>jboss7x</containerId>
   <zipUrlInstaller>
     <url>http://download.jboss.org/jbossas/7.0/jboss-as-7.0.0.Final/jboss-as-7.0.0.Final.zip</url>
   </zipUrlInstaller>
</container>

Alternatively we can configure Cargo to download the container as a Maven Artifact by using the artifactInstaller element instead of a zipUrlInstaller element. More information on accessing JBoss 7 as a maven artifact can be found here. Please note that in addition to the following, we also need to make sure that we can access the JBoss Maven Repository through the pom, which has been described in the provided link.

<container>
  <containerId>jboss7x</containerId>
  <artifactInstaller>
    <groupId>org.jboss.as</groupId>
    <artifactId>jboss-as-dist</artifactId>
    <version>7.0.0.Final</version>
    <type>zip</type>
  </artifactInstaller>
</container>

Starting and Stopping the Container

We start and stop the container in the pre-integration-test and post-integration-test phases by specifying the executions section of the plugin as shown below:

<executions>
  <execution>
    <id>start-container</id>
    <phase>pre-integration-test</phase>
    <goals>
      <goal>start</goal>
    </goals>
  </execution>
  <execution>
    <id>stop-container</id>
    <phase>post-integration-test</phase>
    <goals>
      <goal>stop</goal>
    </goals>
  </execution>
</executions>

This binds the start and stop phases of the cargo plugin to the relevant integration test phases.

Deploying and Waiting for the Application to Start

We can get Cargo to deploy our application artifact into the container in one of two ways:

  1. Define the artifact as a deployable within the configuration/configuration/deployables section of the plugin. Note that there is a second configuration section in Cargo.
  2. Define the artifact as a deployable within the configuration/deployer/deployables section of the plugin

The first has the advantage that the artifact is deployed before the container is started and therefore has a small startup time speedup. However Cargo doesn’t wait for the artifact to finish deploying before moving to the next lifecycle phase of the build, and therefore we have to resolve to checking the state of the application within our tests.

The second deploys the artifact after the container starts up, and we can specify a URL for Cargo to ping for a specified amount of time using the pingURL and pingTimeout elements. The Cargo documentation says that these elements can be defined in the first method as well, but testing has showed that the plugin doesn’t honour these tags.

Therefore, we specify our application artifact to be deployed using the second method as follows:

<configuration>
  ...
  <deployer>
    <type>installed</type>
    <deployables>
      <deployable>
        <!-- Artifact to deploy; change to your artifact -->
        <groupId>com.navinpeiris.examples</groupId>
        <artifactId>example-artifact</artifactId>
        <type>war</type>
        <!-- Don't forget to change the following to your apps URL -->
        <pingURL>http://localhost:8080/myapp</pingURL>
        <pingTimeout>20000</pingTimeout>
      </deployable>
    </deployables>
  </deployer>
</configuration>

Other Considerations

There are a few other matters that should be considered but are outside the scope of this post:

  1. We should use the maven-failsafe-plugin for integration tests so that the application server is guaranteed to be shutdown even if any integration tests fail.
  2. We should define the above deployment within a maven profile so that we have the ability to use other deployment/container types in the build.
  3. Although we use a downloaded instance of JBoss there is no reason that we can’t use an existing local or remote installation.
  4. If we are using the downloaded instance, then we should configure the ports to non-standard values so that we don’t have port conflicts if/when running multiple simultaneous builds on the same machine.

Summary

This shows how we can use the Cargo plugin to start a JBoss 7 instance and deploy an application artifact before we run our integration tests. We also configured Cargo in such a way that the we wait for the application to complete deployment before starting.

Download and unpack JBoss AS 7 distribution through Maven

Tags

, , , ,

I quite unintentionally happened to find the JBoss AS 7 distribution in the JBoss maven repository while looking for something completely unrelated.

My first thought when I found this was that given the size of the distribution (72MB) and the amazing startup times, I can very easily download the entire distribution, unpack it, and run my integration tests (using arquillian) in the unpacked container itself, without affecting to the build times too adversely. This would allow the project build to be self contained in that it doesn’t have to rely on or assume the availability of a remote or local JBoss installation.

The maven artifact information for the AS 7 distribution is:

<groupId>org.jboss.as</groupId>
<artifactId>jboss-as-dist</artifactId>
<version>7.0.0.Final</version>

Before you proceed, make sure that you’ve added the JBoss maven repository to your POM or nexus repository. More details on the JBoss maven repository can be found here.

Using this information, I can download and unpack the server before the integration tests are to run by including the following in my POM:

<plugin>
  <artifactId>maven-dependency-plugin</artifactId>
  <executions>
    <execution>
      <id>unpack</id>
      <phase>pre-integration-test</phase>
      <goals>
        <goal>unpack</goal>
      </goals>
      <configuration>
        <artifactItems>
          <artifactItem>
            <groupId>org.jboss.as</groupId>
            <artifactId>jboss-as-dist</artifactId>
            <version>${jboss.version}</version>
            <type>zip</type>
            <overWrite>false</overWrite>
            <outputDirectory>${project.build.directory}</outputDirectory>
          </artifactItem>
        </artifactItems>
      </configuration>
    </execution>
  </executions>
</plugin>

The unpacked server will be placed in target/jboss-as-7.0.0.Final.

OS X Lion: Reverse Two Finger Scroll Direction

Tags

, ,

The default scroll direction in OS X Lion has been inverted to be the same as what you would be using on an iOS device. Although it makes perfects sense on an iOS device, this new scroll direction is very confusing when you’re so used to the normal scroll direction in a non-touch device

You can easily reverse this scroll direction back to what it was in Snow Leopard through the Trackpad Preferences under your System Preferences. In Trackpad Preferences, click on the “Scroll & Zoom” tab, and deselect the first option, which is called “Scroll direction”:

And ta-na! Sanity has been restored…

Download and Install Java Source and Documentation on OS X

Tags

, , , , ,

UPDATE: These instructions have been updated with the changes made to the Apple Developer Downloads site, and modified to not be specific to Lion.

The Java installation in OS X doesn’t come with the JDK source code and documentation which any Java developer will require sooner or later. For me this becomes a hassle when I want to browse or lookup something in the Java API through Eclipse. This guide shows you how to download and install a Java for Mac OS X Developer Package and show you where you can find the documentation and the source jars, which can then be used in your favourite IDE etc.

First, go to the Apple Developer Downloads site at http://developer.apple.com/downloads and sign in using an Apple Developer ID. You will need to create a developer ID if you don’t already have one.

Next, find and download the Java for OS X Developer Package relevant to the version of Java installed in your machine from the list of downloads shown, for example, at the time this post was edited the latest version was Java for OS X 2012-005 Developer Package. The download appeared on the 2nd page at the time of writing, but it’ll be much easier if you filter the list by entering Java in the search box on the left hand side of the page.

Once the download is complete install this package by clicking on the DMG and then the PKG, and following the instructions in the dialogs.

The source and the documentation artefacts will now be placed in paths similar to that below. Please make sure you substitute the [version] with the appropriate version for your installation:

Source:

/Library/Java/JavaVirtualMachines/[version]/Contents/Home/src.jar

Documentation:

/Library/Java/JavaVirtualMachines/[version]/Contents/Home/docs.jar

For example, on an OS X Lion installation, the relevant paths will be:

/Library/Java/JavaVirtualMachines/1.6.0_26-b03-383.jdk/Contents/Home/src.jar

and

/Library/Java/JavaVirtualMachines/1.6.0_26-b03-383.jdk/Contents/Home/docs.jar

You can now use these paths to refer to the relevant jars through your IDE or any other application that might require it.

OS X Lion: Change Finder Sidebar Font Size

Tags

, ,

One of the first thing that I noticed in Lion was the huge font in the Finder sidebar, which IMHO makes the whole Finder window look very ugly:

The size of the font can be quite easily changes, but the option shows up in a not so obvious location; under the General preferences window within your System Preferences:

If you change the “Sidebar icon size” to Small, your sidebar should start looking something like:

OS X Lion: Enable Forward/Back History Navigation Gesture for Finder and Chrome

Tags

, , , , ,

Unfortunately the forward/backward history navigation gesture doesn’t work out of the box in OS X Lion for Finder and Chrome. This is because both these applications (and maybe others) expect the gesture to be the same three finger navigation as it was in Snow Leopard, but by default Lion has configured this to be the new two finger gesture. We can get the old behaviour back by simply re-specifying this gesture back to the old three fingered gesture.

To do this, first disable the “Three finger drag” option which is available under the “Point & Click” tab in the Trackpad Preferences window in System Preferences:

This will however leave you without a gesture to move windows around with, but as a workaround you can enable the old one finger click and drag gesture as shown here.

Now to enable the three finger history navigation gesture, click on the “More Gestures” tab in Trackpad preferences and specify the “Swipe between pages” gesture to be “Swipe left or right with three fingers”:

You should now be able to navigate through the window history in both Finder and Chrome using three fingers.

OS X Lion: Enable One Finger Drag Gesture

Tags

, ,

Lion doesn’t come with the same one finger click-and-drag gesture that used to be in Snow Leopard, and instead the user has an option of enabling a three finger drag gesture through the system preferences. This post shows you how to re-enable the one finger drag gesture.

To enable one finger drag, go to System Preferences, click on Universal Access, and then the Mouse & Trackpad tab. Now click on the “Trackpad Options…” button available at the bottom of this screen. Enable the second option, which is named “Dragging” and select the desired dragging behaviour from the drop down list:

After this you should be able to do one finger click and dragging just like in good old Snow Leopard :).

Follow

Get every new post delivered to your Inbox.