This Website is Best Experienced Everywhere

If you were one of the early smartphone users and were subjected to Internet Explorer on Windows Mobile, then you're probably also one of Today's smartphone users who appreciate their modern mobile web experience the most. IE mobile is actually a good representation of how Microsoft approached the mobile operating system all wrong. They didn't really change anything, they just took a desktop OS, made it fit on a small screen and expected the devices to ship with a stylus. Mobile IE had scrollbars and the first few versions didn't scale the pages down. Later versions may have done a better job, but I gave up on it somewhere after WM6 started shipping.

Microsoft is now trying to catch up with Windows Phone 7. That's great (really!). The competition is healthy for everyone except the competing companies. I really do hope that WP7 does well and can become a relevant competitor against Apple, RIM and Google. What I hope for even more is that they learned a lesson or two from their previous experience with mobile computing.

Windows Phone 7 will ship with a mobile version of Internet Explorer, as anyone would have guessed. Recent evaluations appear to be failing at getting anyone excited. So competition is good, right? But do we really need another rendering engine? Politics aside, why not adopt WebKit like everyone else? When it comes to browsers, users just want the websites to look and behave exactly how the author intended and have some browser features that enrich the user experience. Please compete on the latter, but stay away from the former. Competing (read: different) rendering engines only make web development painful and inevitably frustrates users when websites break in the particular browser that they are using. Instead, why not build on an existing and popular framework and then contribute to it to make it even better instead of working in silos to reinvent the wheel?

Inconsistent page rendering is not the only thing making me uneasy about the re-emergence of mobile Internet Explorer. Early reports are stating that it will not support HTML5. Instead, Microsoft is working closely with Adobe to try to get the Flash player to run on WP7 devices. The duo is more or less bringing the Flash vs. HTML5 debate to the mobile world. Now, again, competition is good, right?  Is it?  I would say yes if, as a consumer, you had the choice between the two which is independent of the device that you like. For web developers, the worst part of all of this is that it's like writing JavaScript in 1997 all over again.  Do you double your effort to support both platforms, or give up and put a notice on your site stating "This website is best experienced with Netscape Navigator"?

I can't find a single web developer who is happy about having Internet Explorer 6 with us almost a whole decade later and even less that it will be around for a few more years. No one can even guess at the type of economical impact this browser has had over the web industry throughout those years. With all of this baggage, why bring that over to the mobile web?

True cross-compilation for Android and iPhone?

I went to another presentation on mobile development, this time it was for the xmlvm project presented by Arno Puder. Most of the frameworks that I've seen so far that attempted to ease cross platform development in the mobile space seemed to tackle the problem in similar ways. They introduce some kind of soft layer between your code and the underlying OS and hardware. 

This is where xmlvm sets itself apart from the rest. It does not rely on a runtime or interpreter to abstract the code from the underlying layers. The development cycle looks a bit like this:

1. Write an android app in Java, with eclipse and the android plugin.
2. Build your UI and other components using the xmlvm library
3. Build and execute within their own emulator
4. Repeat
5. When you want the real thing, run their compilation tool which compiles native binary code for either Android or iPhone.

I hope I got that right, it's what I remember from the talk. The most interesting and unique part is step number 5. How do they do this? Java and Objective-C are such drastically different languages, this can't possibly be reliable.... right? The trick is that it doesn't work at the language level. The cross compilation uses the java byte code as the source, parses and morphs the logic into an XML document (hence the name) and from that XML, it can generate several types of output applications. This is brilliant.

Wait, did he say "their own emulator"!?

Yes I did. They have their own iPhone emulator so that you can test your code without having to go through the process of cross compiling (yet). From the demo that was shown, it works great. It might even be better than Apple's emulator since there are controls for tweaking the accelerometers. Arno even showed a demo app on his iPod which connected remotely to his emulator running on his laptop. He was then controlling the emulator's accelerometer by moving around his iPod. All of this, of course, is developed using xmlvm.

So far, I'm quite impressed, but there are differences between Android and iPhone that are more complex than just syntax. A question that I had was how the memory model is managed between the two outputs. Java uses Garbage Collection while Objective-C uses the retain/release model and that impacts how you write your code. I didn't grasp exactly the answer that Arno gave me, but in essence he said they use reference counting and so circular references would cause memory leaks. This part would need to be understood clearly by any developer that would adopt this technology to make sure they really understand how their memory is being managed on the device that they are targeting. 

Xmlvm most likely violates the Apple's terms of service and they are aware of this. However, I consider it to be in the same gray zone as Titanium and PhoneGap. An important distinction is that xmlvm generates a true native binary and is probably much harder for the Apple app review process to prove that an app was actually built using a cross-compiler than the other frameworks that rely on interpreters.

The presenter made it clear that this library is not perfect and still has a way to go, but if this technology really does as much as what was presented, then I am definitely interested. I'll have to fiddle with it when I have a chance, now that I have my brand new and free nexus one. Oops! Did I just say that!?

The Titanium Promise

I've been hearing a lot of talk around Appcelerator's Titanium framework lately.  Appcelerator has found a way to ease the development of apps across the iOS and Android operating systems, with blackberry support trailing not far behind.  They provide a free SDK that allows you to write your mobile application in JavaScript and compile it into native applications for multiple platforms.  This is huge and could mean significant savings in development costs.

I spent a some time looking into the framework a few weeks ago in preparation for Today's hands-on tutorial.  My initial sentiment was that the framework is still in its infancy.  Having sat through this tutorial, my original assessment remains intact.  Appcelerator does not provide an IDE or a step-through debugger which is kind of annoying, but that's not really a show stopper.  My biggest issue is that I was often faced with compilation errors when trying to build and run a brand new project or their kitchen sink demo.  At first I thought that I massacred my dev environment, but Today's presentation was regularly interrupted with similar "I'm getting several errors when I do that on my system" comments.  It turns out that the release of iOS 4 broke a few things in the Titanium framework and we all had to install an unreleased version to circumvent the errors.  That solved the immediate problem but it uncovered an even bigger issue; the Titanium framework is heavily dependent on third parties that they have no control or influence over.  What makes this even worse is that one of those third parties is Apple.  That dependency reveals two major risks for a developer:

1. Apple can drastically change their SDK and/or tools with little to no notice.  If this change breaks the Titanium compiler, you may not be able to release an updated version of your app until Appcelerator releases a patched version of its SDK.   You'll probably still be able to build it using the older Apple SDK, but picture this scenario:
1. Apple releases iOS 4.0 which breaks the Titanium build.
2. iPhone/iPod owners start upgrading to iOS 4.
3. There is a problem with an existing Titanium app when running on iOS4 that causes it to crash.
4. The developer is unable to release an updated version which will fix the crash in iOS4 until Appcelerator fixes the Titanium build.
2. The Titanium framework is flirting with Apple's updated terms of service.  Titanium apps are currently being approved into the app store, but knowing apple, that could change anytime.  Steve Jobs' infamous open letter talked about a common denominator for features which could potentially be applied to Titanium.

All of this might never end up causing any issues.  It's probably in Apple's best interest to keep allowing quality Titanium apps into its store since it makes their devices more appealing.  However, it is notable and probably worth mentioning to stake holders.

There is another important piece of information that I learned over this session that was not obvious before: the JavaScript code is not cross compiled to Java or Objective-C.  The Titanium SDK generates Android and XCode projects and does compile native binaries using the XCode and Java compilers but the app itself is not really a native app.  The application that results from this process, atleast the iPhone version, is essentially a JavaScript interpreter with your JavaScript code compiled into it as a string resource.  This has several implications:

• Performance is sacrificed for convenience.  No matter how well you optimize your JavaScript, it simply will not run as fast as if it were compiled to native machine code or byte code.
• Though the JavaScript code is minified and obfuscated, it is most likely still very easy to reverse engineer.  Other JavaScript frameworks like Google's GWT suffer from the same problem except that in the GWT case, you can move some of that sensitive logic to the server.

Don't get me wrong, there were a lot of good things that came out of this presentation and the Titanium frameworks still have a lot to offer.  The use of JavaScript and it's literal syntax makes it easy to build apps in a decoupled fashion and the event handling model will be familiar to any web developer.  There was also mention of a community effort to build a tool that can take a XIB file and convert it to declarative JavaScript to build the UI.  It apparently works well, though I'm not sure about the maintainability of this approach.  The framework can surely ease the development of most apps available Today, but it is still young and has room for improvements.  The Appcelerator team has big plans for the future such as providing an IDE with a step-through debugger, support for universal binaries, and more.  If you're working in the mobile space, you should definitely keep an eye on it.  I know I will.