Category Archives: Mobile Development

XMLVM is Actually Pretty Fast

DISCLAIMER: The Benchmark results in this post turned out to be flawed due to GCC/LLVM optimizations unduly favouring XMLVM. Please see the next post where I discuss the corrected benchmark and associated results.

In a previous post, I described some of my experiments in creating an Avian port for CodeNameOne. As mentioned in the post, one of my motivations was to see if I could improve on the performance of the current default iOS port which uses XMLVM to convert the Java code into C code (and ultimately compiled with Xcode). I had a hunch that binaries produced via the XMLVM translation would be slower than an AOT compiled Java implementation because of the way it works (It converts VM byte code operations into C stack operations in the C language – which would presumably produce much less succinct code).

After some tedious conversion of XMLVM runtime library calls to JNI calls, I was able to successfully build my Avian iOS port for CodeNameOne. Next I created a simple application (based on the CodenameOne Tabbed Application template) that runs the Towers of Hanoi problem, and built two versions of the app:

  • One using the CodenameOne build server (which uses XMLVM in its build process)
  • – Another one using my Avian, Proguard, and Xcode.

The Benchmark Results

The results were surprising.

I ran both apps on my iPhone 4s which is on iOS 5. The app is set to solve the tower of Hanoi problem for n=30 moving from pole 1 to pole 3. The time required to complete the problem was pretty consistent. On average, the XMLVM app would complete the problem in 35 seconds, and the Avian app would complete it in 42 seconds.

NOTE: After fixing the benchmarks so that GCC/LLVM *had* to run all of the code, it turned out that Avian was actually a bit faster.

This is quite the *opposite* of what I expected. While I’m a little disappointed in the results, I am also encouraged. This means that the performance of apps developed in CodeNameOne for iOS (using their build server) is actually quite good. I can be confident that I am building on a solid foundation.

I posted these results on both the CodenameOne forum and the Avian forum and a few explanations for the outcome were proposed. One explanation, that makes sense is that the XMLVM build benefits from optimizations of GCC and LLVM such as method inlining, loop unrolling, autovectorization, code motion, and intelligent register allocation. Avian’s AOT compiler, being simpler, and far less mature doesn’t implement any of these optimizations so the resulting binary is actually working at a slight disadvantage.

Joel Dice (creator of Avian) did note that a simple benchmark like Towers of Hanoi is not really helpful for determining real-world performance. A full comparison on real-world tasks would be more informative.

UPDATE: The Benchmark results in this post turned out to be flawed due to GCC/LLVM optimizations unduly favouring XMLVM. Please see the next post where I discuss the corrected benchmark and associated results.

The Executable Size

Another important factor when producing a mobile app, is the actual executable size. Why install a 100MB application when you can get the same app in under a meg. I used Proguard on the Avian build to trim down the code size (so we don’t need to include the entire JRE. XMLVM, also uses a number of optimizations to ensure that dead code isn’t included in the final executable.

My test app came out at 3.5MB for the XMLVM build, and 6.0MB for the Avian build. So XMLVM seems to have won here again.

What Now For the Avian Port

Now that I have established that the current XMLVM implementation of the iOS port is quite fast indeed, there is little need to continue to develop an Avian port. This exercise was academic in nature, and I’m satisfied that I have achieved my goals, which were:

  1. Can it be done? (i.e. Create an Avian port for CodenameOne). The answer was YES!
  2. To learn about the CodenameOne architecture. I learned a lot.
  3. To learn about the Avian architecture. I learned a lot here too.
  4. Find out whether the performance would be dramatically improved by using an AOT java compiler instead of XMLVM -> C -> Xcode. The answer, for now, was NO. XMLVM is pretty fast as it is.

Despite that fact that my experiment didn’t yield any performance improvements, there still might be some advantages to developing apps on the Avian stack. Off the top of my head, these include:

  1. A more familiar Java environment. JNI instead of XMLVM’s runtime when interacting with the native environment.
  2. JDK7 support. I’m not actually sure what version of Java I could use with CodenameOne’s XMLVM implementation. It is at least Java 5, but I don’t think it is at Java 7. I notice that they use Apache Harmony for the iOS port.
  3. Perhaps better debugging and exception handling. Shai Almog noted that XMLVM doesn’t support ClassCastException and doesn’t check cast validity. Its stack traces are also a bit cryptic when you get an exception.

Up Next For Avian/iOS

I am keen to try my next experiment with Avian and iOS: Combining my Java-Objective-C bridge with Avian to produce a Java solution that is similar to MonoTouch. I.e. Where you write the code in Java but still use the Apple development tools for the UI. This wouldn’t be a cross-platform solution like CodenameOne produces, but it would be useful, I think.

Up Next for CodenameOne

Time to develop some real-world apps!


CodeNameOne + Avian = Java on iOS

In my last blog post I was expressing my hopes for a Write-Once-Run-Anywhere solution for Java mobile. One of the founders of CodeNameOne responded to the post by saying that CodeNameOne offered everything that I was looking for. It provides a full solution for writing mobile apps in Java that will run in iOS, Blackberry, Android, and J2ME. They provide a Java class library that encapsulates most useful functionality required by a mobile app (e.g. GUI toolkit, Contacts, Camera, Location, Database, Network, Video, Web Browser, etc…). Their GUI solution is akin to Swing in that it is light-weight and pluggable – making it ideal for cross-platform development.

I was already aware of CodeNameOne and had it at the top of my list to try out. A few months ago, I downloaded their Netbeans plugin and played with it a bit – though my “playing” was limited to just starting a new project from a template and trying out their build server to see what the finished iOS executable looked like. I was actually quite impressed that the app (a simple 4 tab application with a few buttons and a map) came out at a trim 6 megabytes. For java this is good, because this had to include all of the components from the JRE compiled into the binary.

My main stumbling block was the dependence on their build server for actually producing the distributable application. The build server, from my brief interaction with it, works flawlessly, but I don’t like making myself too dependent on factors beyond my control. I have been burned already several times by “the cloud”. I have written software that relies on cloud APIs that are backed by major players like Google. In every case, the API has either been discontinued at some later date, or has been changed to a pay-per-use API that renders the application unusable. As another example, when the iPad first came out I purchased some comics through an app that was based on “the cloud”. I stopped using the app for a year, and when I went to use it again, the company had changed to a 3rd party provider for their purchasing – and all of the comics I had purchased no longer “worked”. Similar things have happened in the Mac App store due to changes in policies.

In any case, I am no longer naive (and may be a bit jaded) when it comes to building a process that relies heavily on “the cloud”.

With these “cloudy” experiences as a backdrop, the ability to build my own applications (at least as an option) is very important to me. In navigating around the CodeNameOne site (when I was first investigating it), I was not able to find any instructions on how to build the applications myself. A few questions had been asked in the forum but the response was that, while it is possible to build it yourself, the weren’t supporting it because it was complex and they didn’t want to clog up the support forum with requests of this nature.

Thankfully, I was finally able to find some instructions in the forum on how to build a CodenameOne application using XMLVM. This thanks to jon… for posting these. They were a lifesaver.

The Avian Port

I also mentioned in my last blog post that Avian had great potential for bringing Java to iOS since it is a lightweight JVM that provides AOT compilation. Its creator, Joel Dice, has already posted a simple “Hello World” application that runs on iOS using Avian. This provides a solid foundation for further development, and importantly a starting point for writing an Avian port for CodeNameOne

Let’s back up a little….

Why would I want to write an Avian port for CodeNameOne? Didn’t I just say that CodeNameOne already provides the ability to deploy Java apps on iOS?

My motivations for writing an Avian port for CodenameOne are three fold:

  1. To get intimately acquainted with the CodeNameOne architecture so that I can become a productive developer on the platform.
  2. The get familiar with Avian so that I can make use of it in my future projects.
  3. To see if I can improve the performance. UPDATE: Check out my later blog post where I discuss my benchmark results

The performance issue is of abstract importance to me at this time. If performance didn’t matter at all, I would just use a stack like PhoneGap to create multi-platform apps. But performance matters, you you *can* tell the difference between a native app and a PhoneGap app when it comes to things like scrolling. Writing games and heavily graphical applications also depend greatly on performance. Especially when we’re talking about low-powered mobile devices like the iPhone.

CodeNameOne’s iOS implementation is currently based on XMLVM, which is a brilliant project developed and maintained by Arno Puder. It works by converting the primitive virtual machine instructions into an intermediate XML representation, which can then be transformed into another language. E.g. The JVM is a stack based virtual machine, so many of the instructions just boil down to stack operations. These can quite easily be represented in any programming language. In XMLVM’s case it is converting the Java VM instructions into C source code.

If you actually go through the build steps for XMLVM, you can take a look at the C code that is generated. Basically a C source file corresponding to each Java library that is used in the application, is produced. It uses name mangling to produce functions that correspond to each Java method, and it provides a small set of runtime functions to be able to interact with the generated code (e.g. convert data types).

I think this solution is particularly clever. It gives us an excellent baseline for porting from one language to another. My instinct tells me, though, that the performance probably takes a bit of a hit due to the increase in number of commands required to perform each function. I haven’t done any benchmarks to test out this theory, but Shai Almog did acknowledge this during the JavaOne demo. (UPDATE: Check out my later blog post where I discuss my benchmark results). He did say that many of the important native iOS functions have been hand-coded, though so performance is pretty good where it counts.

Avian, on the other hand, compiles Java down to machine code so it should be very fast. I suspect, almost as fast or even faster than Objective-C for some things. I would like to be able to compare the performance, side-by-side, with the XMLVM implementation so that I can find out how much of an improvement there is to be gained. Realistically, if we want to treat CodeNameOne as a platform on which we can build a vibrant ecosystem of applications, plugins, and libraries, then the foundation needs to be as *fast* and *solid* as possible. UPDATE: Check out my later blog post where I discuss my benchmark results

Creating the Avian Port

In order to create the Avian port, I just needed three puzzle pieces to fall into place:

  1. I needed to see a sample of a project that can be built and run on iOS. The hello-ios sample project posted by Joel Dice, contains enough detail to work with in this area.
  2. I needed to see how the existing XMLVM port is built. Thanks to Shai Almog for pointing me to this post that describes the steps..
  3. I needed to know a little bit about the CodeNameOne architecture. Specifically where it interfaces with the native environment. Thanks, again, to Shai Almog for giving me some pointers in this area. It turns out that most of the native interface is contained in a single class: com.codename1impl.ios.IOSNative. Its native implementations were likewise contained inside a single IOSNative.m file which can quite easily (though tediously) adapted to use JNI instead of XMLVM.

With these 3 pieces in place, it was just a matter of time, sweat, and carpel tunnel syndrome to make the Avian port a reality.

The CodeNameOne Architecture & The iOSPort Project

If you want to start hacking on the CodeNameOne core, the best place to start, is with the code. You can check out the entire repository, which includes the foundation libraries, the designer project, and all of the port sub-projects. These instructions almost worked perfectly for me, except that there were some problems compiling the bar-code reader libraries, which likely are a new feature since the instructions had been written. I didn’t actually get it to build completely, but I got close enough that I’m sure I could have without too much extra work.

The iOSPort project includes a blueprint that can be quite easily followed to port CodenameOne to any platform you desire. All platform specific functionality is provided by a single class, CodenameOneImplementation, which can be overridden as necessary to implement functionality for the platform. The iOSPort project further factors out most native methods into the iOSNative class. This native class uses XMLVM conventions for native classes rather than the more common JNI conventions, but it was easy enough to generate JNI headers for this class and port all of the functionality over.

With the XMLVM-powered port, all of the source code in CodeNameOne, Apache Harmony, the iOSPort project, and the actual mobile app that is to be built is converted to Objective-C code using the XMLVM compiler. This produces a rather large project since .h and .m files are generated which correspond to each Java class that is used. A set of hand-coded native sources (Objective-C) in the nativeSources directory of the iOSPort project are also included. These one of these Objective-C source files is IOSNative.m, which includes all of the native implementations for the IOSNative class, but there are also several other classes that encapsulate various other components, and are referenced by IOSNative.m.

In producing an Avian version, I primarily just had to go through each of these hand-coded native files and replace all references to XMLVM with corresponding functionality that makes use of the JNI functions. Most of the references to XMLVM involved type conversion and array manipulation, which XMLVM provides some runtime convenience methods for. These replacements were tedious but not terribly difficult. After all of the replacements were made, it was just a matter of adding all of the source files to an Xcode project that is set up to build using Avian, then dealing with build errors one at a time.

The iOSPortAvian Project

Once I replaced all of the XMLVM references with JNI equivalents, I was able to set up an Xcode project scaffold based on the Hello-IOS example. The process for setting up the Xcode project was roughly as follows:

  1. Download the OpenJDK Mac port files from SVN. Download Avian from SVN. Download Proguard. Download the Hello-ios Project.
  2. Add all files in the iOSPortAvian/nativeSources directory to the Xcode project.
  3. Build the JDK.
  4. Copy all of the Java source files and resource files that are found in the CodeNameOne project and in the application to be built into the src directory of the Hello-IOS project.
  5. Use a modified make file to build the Java source code into native binaries and link them into the Xcode project.
  6. Create a custom entry point for the application, main.m, that initializes the JVM using JNI and passes control to the CodenameOne_GLAppDelegate class to enter the application.

Most of the build steps have been included in the build.xml ANT task that is part of the iOSPortAvian project.

I have uploaded the entire project source on GitHub as a point of reference for others who may want to extend it or learn from it.

I will write the specific steps required to build your app with Avian in a future blog post.

The KitchenSink Demo App Running on Avian

My first test app was just the “Hello World” app that is produced from the CodeNameOne template in Netbeans. The next one was the Kitchen Sink demo app. Most of the app started up with no problems. Yay!! Themes worked. Effects and transitions worked. As a proof of concept this feels very close to viable.

>Problems with Garbage Collection

Unfortunately I hit a snag that I suspect is related to Avian’s garbage collection. After performing a few successful transitions and functions, the Kitchen Sink app would crash with an EXC_BAD_ACCESS error (using the iOS simulator). I suspect this problem is related to Avian’s garbage collection but I don’t really have any leads on how to solve this issue. I have posted the issue in the Avian forum but haven’t had any response yet. Until such time as I have a lead in this area, the Avian port will remain 99% complete – but unusable.

UPDATE: Thanks to Joel Dice in suggesting some debugging techniques, I was able to solve the garbage collection issue. It is now working 100%!!

Thoughts in Summary

  1. CodenameOne is the real deal. It really does provide cross-platform mobile development in Java. I really hope the community gets behind this project because it is worth of attention.
  2. The CodenameOne devs (Shai Almog, and Chen Fishbein) deserve medals for their work on this project. The massive scope of the project across so many platforms surely required a massive effort to get it working. If you look at the CodeNameOne forums you’ll see that Shai responds to pretty much every inquiry that comes in the same day in most cases. If you look at the source code of the project, you’ll see their names in pretty much every javadoc, which tells me that these guys are wearing both the tech support hats and the dev hats for this project. I really hope a community forms that takes some of the burden off of these founders. Being the maintainer of some other open source projects myself, I know how difficult it can be when you have to respond to every question that comes into the forum.
  3. Avian is very cool also, but the community doesn’t seem to be there. I have posted 4 questions to the forum and have not received a response to any of them. I answered my own queries in the forum when I found the answers myself, but the last query that is currently the show stopper, hasn’t received a response yet. Since Avian is the only pure AOT solution that I’m aware of that has working examples on the iOS, I think it is still work paying attention to even if the community isn’t really there yet.
  4. XMLVM is brilliant. A great way to learn about the possibilities of XMLVM is to look at the iOSPort project of CodeNameOne. It is a wonderful example of the possibilities. I didn’t actually get to the point where I could compare the performance with Avian/Native code, but the fact that it is being used successfully in CodenameOne serves as a compelling proof of concept for it. Great work, Arno and team on this.
  5. I still don’t have a good handle on the relative benefits of using CodeNameOne vs using an HTML5 technology (e.g. PhoneGap) vs using Native (other than the fact that Java is a superior language, IMHO). Does CodeNameOne’s performance rival native apps? Does it beat the performance of HTML5 apps? If so, what tangible things can be achieved with CodeNameOne that cannot be done with HTML5?
  6. Currently CodeNameOne doesn’t support external Jar files. This is partly because it doesn’t support the full J2SE spec for all platforms. You can work around this problem by just adding the source files for the external libraries into your application’s project. However this kind of nullifies one of the best features of Java: the ability to build up collections of third party libraries that can be used in multiple projects. I suspect that this feature will be added in future releases, but it is certainly a notable omission for now.
  7. All of this tinkering with building my CodeNameOne projects on my own are merely academic for now. Even if I did produce a working Avian port, I would probably still opt to use their build server since it is so automatic and they have worked out all of the little issues with optimization. That said, I think without easily accessible public build instructions, it will be difficult for an open source community to build up.
  8. I still want JavaFX on mobile. I haven’t really explored the limits of the UI and graphical API capabilities of the CodeNameOne libraries, but I can guarantee that they don’t come close to approaching the capabilities of JavaFX.

Follow Up

Check out my later article where I discuss the results of a benchmark comparing the performance of XMLVM and Avian.

I want Java on Mobile

What makes Java unique? Actually there are quite a few things that set it apart from other languages, but I want to focus on its true cross-platform presence. No other platform provides the end-to-end tools for building a robust desktop application and deploying it on every major desktop operating system. The best you can hope for with other languages is that you can share most of your business logic across platforms, but when it comes to the user interface, well, you need to build that separately for each platform.

The mobile space, sadly, is a different story. Many devices do use JavaME, but the big players (Android, iOS, Windows Phone, Blackberry) all have their own toolkits that make it difficult to truly write once run anywhere. While Android and Blackberry do use Java as their primary development language, their toolkits are incompatible with each other. iOS and Windows Phone, likewise, are incompatible with each other, and everyone else. What I want is a Java toolkit that does for mobile what Swing (and now JavaFX) did for desktop.

2012 has seen some progress where there was previously only darkness. There are now a handful of solutions that will allow you to write mobile apps with Java (e.g. CodeNameOne, ADF Mobile, J2Objc, Avian, to name a few), but none of these offer the same type of run-once-run-anywhere development experience as Swing did (and JavaFX does now). CodeNameOne, perhaps, comes the closest, as they provide cross-platform libraries for most things, including the UI. My hesitation with this framework is its dependence on their cloud services for building the applications. ADF Mobile includes a small JVM for the business logic, but relies on PhoneGAP (HTML5) for the user interface and for interacting with Phone services. J2Obj is interesting also, as it allows you to compile Java source code to Objective-C code that can be used from your iOS front-end, but this doesn’t get us anywhere near cross-platform development – just easier sharing of code between Android and iOS. Avian, is an alternative, light-weight JVM that provides AOT compilation and has been successfully used to build ARM binaries that can be run on iOS. It provides, perhaps, perhaps the most hope since it is open source. But examples are scarce for iOS, and it isn’t backed by any major players at this time AFAIK.

There seem to be two trends for attacking cross-platform mobile development:

  1. Write Once, Run Anywhere – Using HTML5 for the UI.
  2. Share business logic, but use native tools for building and designing the UI.

The problem with the first approach is mostly performance related. HTML5 is great, but on mobile devices you may need to crank as much as you can out of that little processor. The second option solve the performance issue, but it just isn’t as fun. Nor is it as maintainable.

I want what is behind door number 3: Write once, run anywhere, with a rich UI toolkit that is cross-platform but has a pluggable look and feel so that the applications can be made to look native. This UI toolkit should be efficient (perhaps OpenGL) so that we aren’t having to choose between portability and performance to a great degree.

I guess, what I want is JavaFX on mobile (i.e. iOS, Blackberry, Android, and Windows Phone).

Scrolling iFrame on iOS

I just finished adding scrolling support to the RecordDialog class in Xataface for the iPad. The RecordDialog basically allows you to open an edit form or new record form in an iframe using a Javascript call. This is useful if you want to be able to pop up a form without the user having to navigate away from the page. It uses an iFrame for legacy reasons, until the forms API can be updated to work 100% through AJAX. This component has worked well for a long time on the desktop, and it works okay on the iPad and iPhone if the form fits inside the iframe without having to scroll. The trouble is that you can’t scroll an iframe on iOS, so if the form is too long, it just gets cut off and the user can’t see the bottom of the form.

After some Google searching I found a few strategies for overcoming this issue. The proposed solutions can be categorized into 3 groups, and all of the solutions have one common element: start by making the iframe unscrollable using the scrolling=”no” HTML attribute. From there, you can either:

  1. Set the iframe height to be as tall as the document body, and wrap the iframe in a scrollable div tag.
  2. Wrap the contents of the iframe in a scrollable div tag. (This requires sizing the DIV’s height to be the same as the iframe’s parent’s inner height).
  3. Use javascript touchStart and touchMove events to do scrolling with Javascript inside the iframe.

After experimenting with options #1 and #3, I settled on solution #2: wrapping the iframe’s contents because it seems to work best for all occasions. Of course this solution won’t work if you don’t own the contents of the iframe.

Option #1 (wrapping the iframe in a scrollable div) is problematic because, by changing the size of the iframe to be taller than the screen, potentially, it screws up calculations in the body of the iframe that rely on window height. I found that dialogs that are created to be displayed in the middle of the page end up displaying way down the page because the window is deemed to be effectively the size of the iframe, which has been artificially resized to be way too big.

Option #3 didn’t look as appealing because of the amount of custom javascript handling. I just have the feeling that I would have been starting down a long road of browser incompatibility glitches.


  • A good blog post on some of these strategies
  • A stack overflow conversation on the topic.
  • JavaOne: A Look Back

    I am now home from my Bay area adventure at Java One. This was the first conference I’ve attended since 2005, and is by far the largest conference I’ve ever been a part of. I was blown away by the scale of this one. The downtown core was plastered with Oracle and Java signs. Buses dipped in oracle insignias roamed the streets constantly, and you couldn’t walk a block without seeing at least 5 people brandishing Oracle swag. (I quite liked the back pack that they provided).

    In addition to the sessions (which I’ll get to next), there was a steady stream of entertainment events for the benefit of conference attendees. Union square (and a few other locations) were blocked off for music performances; and then there was the “fan appreciation” event featuring Pearl Jam and Kings of Leon. Doesn’t sound like nerd conference, does it?

    The Sessions

    My reason for attending was the sessions. From Sunday to Thursday my schedule was jam packed with talks about topics ranging from JavaFX to MongoDB and a smattering of Java ME, iOS, and Android development. For any given one hour slot, I had to choose between 2 or 3 talks that I really wanted to see, and another 8 or 9 that would have been interesting. Being able to hear about new technologies directly from the people who are behind it is awesome. It imparts a kind of understanding that cannot be achieved through a book or reading blog posts.

    This conference has sparked a fire in me to seek out more conferences like this, similar to the way that a my first exposure to Disneyland led me to look for other parks that offer the same experience. In fact, the way a child reacts to his first experience at Disneyland is an accurate way to describe my reaction to the conference schedule.

    The Topics

    Currently I have a number of desktop applications that have been developed in Swing and have been deployed as applications on OS X. Therefore, I was most interested in learning about Swing’s successor, JavaFX, and how to deploy applications on OS X. The conference was heavy on JavaFX (yay!) but a little light on OS X. There were two talks on OS X deployment, but sadly I could only attend the first one (which way a fantastic talk, by Scott Kovatch). Nonetheless, I have left the conference with stockpiles of new ammunition for building applications with JavaFX. In fact, I’m really exciting about using JavaFX and Scene Builder (the GUI editor for JavaFX) to start building some business applications at work.

    The demos provided by some of the community served as proof of concept to me that JavaFX is something special. E.g. Gerrit Grunwald’s (@hansolo_) set of gauges in the JFXtras project show what can be achieved with a little time and artistic flair.

    On the OS X front, it looks like we’re all set to go now with the Mac App store. The javafxpackager tool provides the ability to easily deploy applications as native bundles. This is a new direction for Java (up until now, they have been recommending Web Start distribution), and I think it is a good one.

    Another topic that I am keenly interested in is mobile development (iOS and Android). Last year’s java one included a demonstration of JavaFX running on an iPad, but then nothing more was heard. This year they announced that JavaFX will be available for Java7 SE Embedded, and they had a conference scheduler application running on an small, embedded device in a kiosk at various stations in the conference. But there were no announcements about JavaFX for iPad or Android. The announcement of its availability on embedded devices is a step in the right direction, though, as this is a prerequisite for running on the major embedded platforms.

    I did attend one talk (actually 2 talks on the same topic) on Java for iOS and Android. The CodenameOne project (that I’ve blogged about before) is a java library and framework for building cross-platform mobile apps (i.e. deployable on Android, iOS, Blackberry, and J2ME). This looks very promising.

    When I had reached my saturation point on JavaFX, I wandered across to the Parc55 building for a couple of Java Enterprise Edition talks. I attended a talk on the new Project Avatar, which provides a thin-server approach to web applications (i.e. most view logic and layout is handled on the client in javascript, and the server just sends over the data). This project looks quite interesting, both in concept and execution. The concept coincides with much of the more recent development I’ve been doing with Xataface.

    The last talk of the conference that I attended was on NoSQL and scaling strategies. There, Nike’s director of engineering discussed some of their architectures for handling heavy traffic with NoSQL databases and Data grids.

    My head is full. My notebook is full. Now to put all of this new knowledge into practice.

    CodenameOne Project : Finally Java on the iPhone

    I periodically monitor the progress of multi-platform development solutions for the mobile space. As a Java developer, I’m especially interested in solutions to bring Java to the iPhone. Even better would be a Java solution that will run on all of the major devices (Android, iOS, and Blackberry).

    CodenameOne is the most promising project to appear in this space so far. It includes an API, a GUI designer, and a build/deployment solution so that you can develop your application in 100% pure Java then a native application on most major platforms (including iOS, Android, RIM, Windows Phone 7, and J2ME). The API forms a thin abstraction over the native libraries on each platform so many components are heavy-weight. This allows the applications to take on the native look and feel of the host system. The underlying mechanics work differently for each platform. E.g. on Android, the Java runs on the built-in VM, whereas iPhone builds use XMLVM to convert the Java bytecode to native code.

    So far I haven’t done very much with it (just discovered it last night). I downloaded the Netbeans plugin which adds the ability to create a “Codename One Project” within Netbeans. This includes a GUI editor with a few themes to get you jump started with some common application structures. My initial test application was just a default tabbed application. It took me 2 minute to create it.
    The Netbeans plugin includes an iPhone emulator so that you can test the application right inside netbeans. In my initial tests, this seemed to work quite well. Building the application was a single click.

    I’m a little wary of the build process, as it occurs on their server. Apparently the Java is compiled to byte-code on your local machine, then it is sent to their server to have it converted to a native application. This requires that you sign up for a free account. After signing up for an account, and logging in, it said that I could perform up to 80 builds before upgrading. It didn’t say whether this is 80 per month, 80 per year, or 80 total — but I didn’t look into it too deeply. The build process took a little while (more than 20 minutes — I just requested the build, then waited 20 minutes and went to bed). In the morning the build was ready for download.

    I was quite impressed with the file size. It was only 6.9 megs. Yes this was just a simple app with 4 tabs, some buttons, and forms, but this size is still quite good. Especially considering that it includes all code necessary from the Java libraries in order to run. I was expecting it to come in around 50 megs, as I fully expected the whole JVM to be statically compiled into it. Luckily, it looks like they use some optimizations to remove dead and unused code before building it.


    Pros: Java. Support for most major devices. Good documentation. Good IDE support (both Netbeans and Eclipse). Easy, one-click-builds, Support for signing so you can submit apps to their respective app stores. Open Source (GPL 2. With Classpath Exception — free for commerical/non-commericial use)

    Cons: Building is done in the cloud. This is convenient but it opens the door to problems in that you are now dependent upon them. They say that you can build it yourself and that there is information on the net on how to do this – but they offer no support for it.

    Hopefully I’ll have the opportunity to build my first app with this in the next couple of weeks.


    • Codename One Website
    • How CodenameOne Works (a Stackoverflow discussion).
    • XMLVM – The underlying tool that allows them to cross-compile Java to native code.
    • LWUIT – A toolkit for user interfaces on mobile devices of which CodenameOne is a descendent.

    JavaFX Has Finally Arrived

    JavaFX 2.1/2.2 finally gives me the tools that I need to build the applications that I want to build. This release provides 2 missing pieces that make all the difference:

    1. Scene Builder – Finally a good graphical GUI tool for Java. This makes building GUIs almost as easy as Apple’s Interface Builder.
    2. JavaFXPackager Native Bundles – Now you can instantly build native application bundles for Mac, Windows, and Linux.

    The only question is whether these features are too late to the party to make a difference. Sun dropped the ball with desktop Java a long time ago. It survived the past 10 years almost entirely on the backs of JavaEE (i.e. web/server programming) and, more recently, Android. Desktop application developers have been fending for themselves for the most part.

    Now we have the tools that we need to make some serious applications. The upcoming release of JDK 1.7 will also finally enable Java developers to get their applications into the Mac App store. Currently the bundle size for an application is quite large (over 50 megs for my hello world application test), because it needs to contain the entire Java Runtime Environment, but this should improve over time as we get better at compressing and splicing the JRE to suite specific purposes).

    I downloaded Netbeans 7.2, JavaFX Scene Builder, and JavaFX 2.1 (included with JDK 1.7.0u6) to try to build a simple web browser application. This proved to be super easy, and it gives me a lot of faith in the power of technologies such as FXML (an XML format for representing user interfaces). Some key points that impressed me during my short test:

    1. Netbeans now has an option to create a Swing-wrapped JavaFX project. This was previously a real pain, since JavaFX has lots of cool toys, but wouldn’t give you a full desktop experience. E.g. You still needed swing to get menus at the top of the screen for Mac. Swing still does a lot of things well, so if you wanted to use JavaFX, you would generally need to rig up the Swing FX Panel yourself. Having this as a default option for a project is nice. No more messing around.

    2. Using a controller for the FXML file makes it very easy to achieve full separation of the view and logic. The @FXML annotation also makes it incredibly easy to reference elements of the FXML UI from the controller. Attaching events for controls was quite simple.

    In order to truly be successful, JavaFX still needs to get a mobile presence. It currently doesn’t run on Android or iPhone (despite demonstrations to the contrary at previous JavaOne conferences). If they can somehow port it to these platforms, I think it will really take off.

    Exploring the HTML/CSS Mobile Toolkit Landscape

    I’m in the process of developing a mobile interface to Xataface so I’ve been experimenting with different toolkits to help with the UI. I have worked with jqTouch in the past (to create the Web Lite TV iPhone/iPad interface) and found it mostly good, but a little bit heavy, and also buggy when you get into the fine details. (It may have improved since then).

    Apple’s Dashcode is also quite impressive for developing UIs in a more WYSIWYG fashion, but I felt a little trapped inside their box and unable to customize things in the way I wanted to, especially when developing apps that needs to generate the UI dynamically – not just populating data to a static layout.

    So, going into this, I wasn’t entirely happy with my toolkit. Let the exploration begin for better mobile HTML/CSS toolkits:


    First stop: iScroll. iScroll, in my opinion, is a major breakthrough in HTML/CSS application development on mobile touch devices. It is the first library to allow good scrolling of the content of any HTML tag. Outside of iScroll, you couldn’t just scroll the contents of a div whose CSS declares that it should be scrollable… even iframes wouldn’t scroll.

    Major step forward… but not a complete toolkit. It doesn’t provide any of the familiar nav bars and buttons that users expect in a native app… that is simply beyond the scope of the iScroll project. So we’ll use this as a tie-down point in our expedition, and we’ll proceed to explore toolkits that incorporate iScroll.

    Stop 1: appML

    appML uses its own custom markup language for web applications, called appML. It is built on jqTouch and iScroll and serves as a framework for building native looking mobile apps (native to iPhone at least). The demos are quite stunning so I decided to give it a go.

    First of all, I have to say that the developers are doing a fantastic job on this framework. The UI is very appealing and the markup they have developed is quite intuitive. However this project is still in alpha phase and it has the feel of a project that is still taking shape and forming direction. I like the fact that it is built on jQuery, but it is still a little bulky, and the API is still a little rough around the edges. The show stopper for me was that it isn’t currently possible to load pages using AJAX. This severely limits the types of applications that can be produced. I’m sure that this will be addressed in future versions, but for now I’m forced to move on.

    Stop 2: ChocolateChip-UI

    ChocolateChip-UI (CHUI) is a real gem of a toolkit. The project has a small, well-defined scope that makes for a clean and polished API. It is well documented, slim, and easy to extend. It defines its own markup language (WAML) similar to the way that appML does, but it is much better documented, and cleanly implemented. It seems to closely mirror the official iOS cocoa API, providing simple tags for all of the major views, containers, and buttons. It is self contained (doesn’t use jQuery or any other bulky libraries) which is nice (I generally still use jQuery in my apps anyways, but it’s nice to have the option of leaving it out).

    It is hard to express just how good this toolkit is in relation to all others that I have tried so far. If we were to give any of the other toolkits a 10 out of 10, then Chocolate Chip UI deserves a 50 out of 10.

    Why do you need an app for that?

    I have recently stopped using the Facebook and Mail apps for my iPad and iPhone in favour of the HTML equivalents offered through Safari. The reasons: Mobile-optimized web applications are now as good, or even better in many cases, as their native app equivalents. In the case of the Mail app, I have found that the gmail mobile version has a superior search feature and is much faster in loading my messages. For facebook, I just found the app limited and more buggy than the HTML equivalent.

    In general, I’ve come to the conclusion that if you’re going to build a native app for something, you’d better have a good reason – and good reasons are becoming fewer as HTML browsers improve their support for HTML5. The only valid reason at this point is a requirement for significant client-side processing – e.g. a 3-D game. But as WebGL matures even this will be quite possible in HTML.

    So here are some reasons for developing your mobile applications in HTML5:

    1. Increased productivity in most cases over development of native apps.
    2. Real standards-based, cross-platform support so you can write it once and have it work on all major platforms (Android, iPhone, Blackberry, etc…).
    3. True freedom of deployment. You are not locked into Apple’s (or the next would-be gatekeeper’s) store or subject to their sovereign choice of what can and cannot be installed.

    The remaining reasons why you may still need to develop a native app:

    1. You want to use a platform specific feature that isn’t available through the web api. E.g. the accelerometer, or the contacts list, or push notifications, GPS, etc..
    2. You need more client-side processing power than you can harness through the web.

    The compelling reasons to want to develop a native app:

    1. To get it into the app store and maybe make some money.
    2. Toolkits (e.g. XCode/Interface builder) are developed and promoted specifically for making apps target a specific platform. This can make it seem easier to break into the market since there are lots of learning resources on how to use these tools.

    The biggest challenge right now facing HTML mobile developers is that the tools are less promoted and more scattered. This is because the major stakeholders (e.g. Apple) have a significant interest in getting you to develop your app natively so that it will be exclusively available for their platform, and they will get a cut of any revenue through their store model. If you look, however, there are tools out there for building slick HTML mobile apps that look and feel very much like native apps. Some examples include:

    1. Sencha Touch
    2. jqTouch

    And there are more where those came from. If you still want to develop a native app and you would prefer to work with open technologies like HTML and Javascript you may want to look at Appcelerator which provides tools to develop applications in Javascript, HTML, and CSS that can be compiled into native apps all the major smart phones (e.g. Android, iOS).

    iPad: Initial impressions

    Just picked up an iPad today and am very impressed – not only by its potential for changing the world, but for its immediate utility. Here are just a few things that I notice after playing with it for 4 or 5 hours:

    1. When reading, scrolling down a page is quite hard on the eyes (you get kind of car sick doing that too much). I notice this particularly because of the extensive use of side “sweeping” in iPad applications. E.g. the Comic book apps allow you to read a comic one page at a time, and then just flip the page to see the next cells. This is very easy on the eyes. The Financial Times app also makes use of side scrolling to read its news paper – less scrolling down – more sweeping across. This makes for a much more pleasent reading experience. Look to see much more of this style in the future as more devices like the iPad hit the market.

    2. It looks like there’s nothing for sale yet in iBooks (probably a delay because we’re in Canada). However its extensive selection of free titles (generally classics that have passed their copyright expiration dates) makes for lots of choice still. I started to read “The Rise and Fall of the Confederate Government” by Jefferson Davis (the president of the Southern Confederacy during the American Civil War) this afternoon to complement the a book I’m currently reading about Abraham Lincoln and his cabinet. The iBooks experience is almost as good as reading a real book. It makes it very easy to flip pages, change font size, and skip to any part of the book. I appreciate it’s little status message ever present at the bottom right corner indicating how many pages are left in the current chapter.

    3. The Kindle App is also quite good, and currently provides a much larger selection of books to purchase. (iBooks appeared to have zero books available for sale). The only problem is that they make it damn hard to purchase any books. The Kindle app has a button to “Shop for books from the store”. But this just takes you to the amazon web site which is not optimized in any way for mobile devices or the iPad. After logging in, entering credit card info, and finally finishing the purchase, it downloaded a book on iPad software development into Kindle. They really need to build the purchase mechanism into the iPad to make it competitive with iBooks (which allows you to simply click on a book and purchase it on the spot – and be reading it in seconds).

    4. Comics! The iPad is a savior for the fledgling comic industry. Reading comics on this thing feels very natural. I downloaded both the Marvel Comics app and the Transformers Comics app, which allow you to read comics in a rich, full-screen, environment. They offer some free comics and have others for sale. I purchased one issue of Transformers for $1.99 and it was as simple as one click and I’m reading it.

    5. News papers are now multi-media. I downloaded the free Financial Times app which is a UK news paper. Reading it was much like reading a news paper, giving you the same ability to read the articles in columns and scan to the right to see other stories. They have embedded videos associated with some articles, and tapping on the video displays the high quality video right inside the window (as expected, but still really cool). I think we’re just hitting the tip of the iceberg in our exploration of how different media can be melded together to enhance the user experience.

    6. HTML5 Support – After reading about iPad’s rich support for HTML 5 it occurs to me that Apple is doing the world a favour by taking a hard stand against browser extensions like Flash and Java (sad to say). The market share of the iPhone OS (estimated at over 318 million units between iphone, ipod, and ipad) is so big that Apple is able to single-handedly force us to endure a little pain for the greater good in the long run. HTML has been moving at a snails pace since it’s introduction and this has been a sort of chicken-and-egg problem, whereby developers don’t use any cutting edge features because of lack of browser support, and the standard hasn’t progressed very fast because there hasn’t been the demand for cutting-edge features from the development side. Apple is changing that with the powerful HTML 5 support in Safari for iPhone and iPad. Finally HTML/CSS/Javascript is at the point where you can create a full desktop application using open web standards. In addition this model for networked applications is much cleaner and safer than previous strategies (such as Java and Flash applets) because they truly run inside a sandbox where they cannot harm your computer.

    The Apple war against browser extensions (Flash and Java applets) reminds me in some ways of the American civil war and the related end to slavery. Just as slavery was entrenched into the culture of the south to the point where they could not willingly let the practice go without experiencing major economic hardships, we, as computer users, have become dependent on proprietary browser plugins like flash to make up for features that ought to have been built into the browser to begin with. Just as it took a bloody war (or some southerners might say a Northern dictator) to force the issue on slavery, it takes a dictator from the South to force us into the future of computing for our own good, when we lacked the will to make the leap on our own.

    I’m very excited to start developing HTML 5 applications, now that there is a reliable and stable platform to target: the iPad!