Monday, May 28, 2012

Getting started with Appcelerator

A few days ago I started looking into Appcelerator Titanium, which enables you to develop mobile applications for a multiple platforms using Javascript.  If you already have knowledge developing in Javascript, now you can use that knowledge to create native applications for the IPhone and Android.  Appcelerator does this by taking the javascript that you write, and compiling it into code that is supported by each specific platform.  This takes out a lot of the rework usually needed when creating applications on multiple platforms, although it still enables you to add functionality that is specific to each platform.

If you jump over to the Appcelerator web site, you will find a ton of information.  I would advise reading some of the documentation to get a feel for what is actually going on.  Appcelerator provides their own IDE which you will need to use in order to develop applications, and in order to get the IDE, you will need to create an Appcelerator account.

The next step is to install each platform's SDK if you have already not done so in the past.  When you launch the IDE, the dashboard that is displayed will show you what SDK versions are required depending on the platform that you are developing for.  

I ran into a few issues here. First of all it said that I already have xcode installed (which I do) and that I am ready to develop IPhone apps.  After creating a new project and running it, I found out that I am not ready to develop IPhone apps.  It turns out that you need the newest version of xcode in order to use Appcelerator, and depending on your version of OSX, you might not be able to get it.  The newest version of xcode is version 4, which requires OSX Lion.  So, even though Appcelerator doesn't state it, you will need to update to Lion and then update xcode to version 4.  At this point you will be ready to develop IPhone apps.

If you do not plan on building IPhone apps, but instead your cup of tea is Android, you might also run into a few problems.  On Appcelerator's dashboard, the Android tab stated that I need to update to a newer version of the SDK, but when I clicked on the update SDK button, nothing happened.  It seems to have been an issue with the IDE.  I then went on a path of trying to figure out how to update the SDK.  This was a little tough since most of the Google documentation assumes you are using Eclipse.  I ended up going into Eclipse and updating the SDK from there.  Then I went back into Appcelerator and pointed it to my newly updated version of the SDK.  

After all of the setup I was finally able to develop native applications, now all I needed was a way to learn how to do that.

After a little Googling, I found a great starter tutorial on mobile tuts. I would advise you to check it out here.

The tutorial is pretty good, it walks you through how to make a simple twitter client that loads a user's tweets into a list.

The tutorial was informative, but when I was done, I wanted to be able to add a 'refresh' button in order to refresh the tweets.  In order to accomplish this, I added a button to the top of the tabView and then added a click event to it so that when the user clicked on it, I could refresh the list.
var refreshBtn = Titanium.UI.createButton({
 title: "refresh",
 top:0,
 height:40
});

refreshBtn.addEventListener('click', function(){
 Titanium.API.log('user clicked refresh');
 loadTweets();
});
As you can see, I set the top to 0 and the height to 40.  This puts it at the top of the tab.  I then changed the top in the TabView to be 40 so that it starts right after the button.

If you run the application and click the refresh button, it will update the list and everything appears to be working.  If you try to scroll down the list though, you will start to see the text duplicate on each row.  This is  because you are creating a new tableView and adding it to the window each time you hit refresh.  In order to get around this, you need to move the creation of the TableView outside of the loadTweets function.  Then inside of the function, use tableview.setData(rowData); to update the table with the new data.

var tableView = Titanium.UI.createTableView({
   top:40
  });
...

function loadTweets(){
...
      tableview.setData(rowData);
...
}


Now when you run the application and hit the refresh button, the rows are updated and not created on top of each other.

The documentation on the Appcelerator web site is not the greatest when it comes to starting out for the first time.  Their site recommends that you download their sample project 'kitchenSink' which contains a ton of examples.  It is overwhelming at first, but if you know what you are looking for, it can be very helpful.  I used the 'button.js' example to determine out to create buttons and add events to them, and then used the 'table_refresh.js' example to determine how to refresh the list.

Getting started with Appcelerator might be a rocky road, but it definitely looks promising.

Friday, April 13, 2012

Bouncy Castle Decryption - Illegal Key Size


Recently I was asked to implement a solution that decrypts a PGP encrypted ZIP file.  I had never worked with encryption/decryption in Java before, but the task seemed simple enough. I found Bouncy Castle, fished though the API, which us loaded with examples, and poof, I was ready to test.

This is where I ran into a problem.  I received an 'Illegal Key Size' error. I turned to Google and found an answer on StackOverflow 

It turns out that the decryption provider I was using, JCA, cannot handle secret keys greater than 128 bits. The solution is to download updated JAR files from oracle and add them to our JRE.  This isn't really the best solution since I would rather not touch my installation of Java.

At this point I turned back to the API to look for a better solution. This is where I found a better solution. The trick is to remove the dependency on JCA altogether by replacing the decryptor factory as below.
Replace:

InputStream clear = pbe.getDataStream(new JcePublicKeyDataDecryptorFactoryBuilder().setProvider(SECURITY_PROVIDER).build(sKey));

with:

InputStream clear = pbe.getDataStream(new BcPublicKeyDataDecryptorFactory(sKey));

Success. No need to tweek your Java installation.

References:
http://www.javamex.com/tutorials/cryptography/unrestricted_policy_files.shtml
http://stackoverflow.com/questions/6481627/java-security-illegal-key-size-or-default-parameters 

Friday, May 20, 2011

Java Class Generator

One of the biggest issues I had when switching from SOAP web services to REST was the lack of a WSDL. Now I know that a WADL can be used in it's place, but I have had issues with it when working with custom complex objects. To get around this issue, I have been advocating the use of XSD files. The XSD file describes every field within an object. If you create one of these for your services request and response objects, you will then be able to share the XSD file with others so that they can easily create clients to your services.

This all seems like a great idea, but before when we were using the WSDLs everything was generated for us, now we are expected to create classes and XSD files by hand? With bigger objects this could be very time consuming. To overcome this issue, I have created an ANT script that generates Java classes from XSD files. If you place all of the XSD files and the script in a single folder, the script will generate all the required Java classes with annotations required by JAXB. (If you are not using JAXB, I would love to know what you are using, and don't say XStream)

Below is a link to the actual script, but before we jump to that, let's look it over.

We are using XJC to generate the classes. This is something that comes bundled with Java, so the only extra jar file that we need is antcontrib.jar. This file can be found here. We then need to make sure this jar is visible from to our script.

<path id="classpath">
  <fileset dir="${lib.dir}" includes="*.jar" />
 </path>
 
 <taskdef resource="net/sf/antcontrib/antcontrib.properties">
    <classpath refid="classpath" /> 
 </taskdef>

Next comes the meat of the script. We are going to iterate over every XSD file in the directory and generate a class for it.
 <target name="all">
  <foreach target="generate" param="fileName">
   <fileset dir="${xsd.dir}" casesensitive="yes">
    <include name="*.xsd"/>
    <exclude name="*.xml"/>
   </fileset>
  </foreach>
 </target>

Once we have the file we want, we use an existing xjc task to create the class.

<xjc destdir="${output.dir}" package="${output.namespace}">
   <schema dir="${xsd.dir}" includes="${basename}" />
   <depends dir="${xsd.dir}" includes="*.xsd" />
   <produces dir="${xsd.dir}" includes="*.xsd" />
   <arg value="-verbose"/>
  </xjc>

That's all there is to it, run the script using Java 1.6 and the classes will appear before your eyes. Now with the time you saved creating those classes, you can go through and do a better job unit testing your actual work.

Food for thought: Which should first the XSD file or the class?

View entire script: DTOGenerator.xml