To Flex or not to Flex: that is the question:

If you have been trying to follow the events of the last months or so in the mobile arena, you’d agree that it was crazy. The everlasting Ping-Pong game which big companies play with lawsuits not only is fun to follow, but also implicitly shapes the mobile ecosystem.  On top of that, today Adobe announced dropping support for Flash Player for mobile browsers.

But no matter who wins a given lawsuit, or what technology gets pushed aside, one thing is apparent – we need to consider more than one option when thinking through our next mobile application platform. Other features which we need to consider are: ease of coding and packaging, tooling availability, ease of maintenance, unified code-base (if possible), skillset availability, and so on.

Up until a couple of months ago I was seriously considering using the Dojo/PhoneGap combination to create a single HTML5 code base deployable to BB OS, Android, Windows Metro and iPad based devices. However, as I was following Adobe’s never fading commitment to the AIR platform I realized that the choice of Flex is as strong as it has always been. Adobe has never stagnated and always stayed on top of the game. As a result it kept improving AIR, as well as, created sophisticated tooling for HTML5 development. But before we dove into the details, let’s go back few years.

It is natural that users working with websites or web-based applications require UI to be responsive and interactive. Up until few years ago, this was achieved by using a scripting language such as JavaScript, put on top of a static language – HTML. In other words, while HTML was providing the static layout and content of a page, JavaScript was used to make it live by adding additional run-time behavior to HTML. This was known as DHMTL (Dynamic HTML). However, the plethora of browsers and different implementations of similar features brought up significant headache to the web developers who tried to create cross-browser solutions. In order to mediate these challenges, several frameworks were born targeted at hiding the cross-browser implementation complexities. Today, creating an interactive HTML page means using one of those frameworks rather than raw HTML coding as before. Examples of such frameworks are jQuery, Dojo, and etc.

Generally speaking, there are many technologies which allow creating mobile applications, but when considering cross-platform compatibility the choices are narrowed down mostly to Flex and tooling like PhoneGap and Appcelerator’s Titanium which allow to code in HTML/JavaScript/CSS and then package for each platform natively. Both technologies allow cross platform developing and packaging. So, how do we choose which one to use? After all:

• Both can be packaged for all mobile platforms (The new AIR 3, released four weeks ago along with Flash 11, features “captive runtime” technology that help developers distribute AIR apps to places where Flash isn’t welcome–iOS devices or the forthcoming Metro interface for Windows 8.)
• Both support rich set of UI components including charts and graphs
• Both support non-UI features such as geolocation, web storage, and etc.

With no clear winner, arguments can be made in both directions, so let’s look at cons and pros of each platform from a birds eye view.

HTML5

Pros:
While there are many advantages to using HTML, I am really struggling finding those which will distinguish it from Flex. One of the main advantages of HTML based solutions is the fact that they require no additional runtime as opposed to Flex which can only run in a Flash Player or in AIR. However, this argument is valid only if the solution is being accessed from a browser. In case of natively installed mobile applications this argument is not applicable any more. The reason is because natively installed Flash/Flex applications run on Adobe AIR which can be installed seamlessly as part of the installation process.

Cons:
HTML5 is still in draft, but quite close to reach the Candidate Recommendation during 2012. Some sections are already relatively stable and there are implementations that are quite close to completion. But if we look at HTML5 support by different browsers (see the resources below), we will realize that we are long way from having truly cross-browser implementations. While some of these challenges can be mediated with frameworks such as Dojo, the mobile market adds cross device issues as well. In other words two Android devices from different vendors can use different methods in rendering certain UI elements. The differences in rendering might not be noticeable on the big picture, but surely something that should be considered.

Also, the other day I got to play around with the demos and samples from IBM’s Web 2.0 Mobile Showcase (deployed on WAS 7.0) using my Galaxy 10.1 tablet. One thing I noticed off the bat is that every page rendering ended up with an annoying flickering. On top of that I was not impressed with the overall performance of the UI heavy demos. These will definitely not go unnoticed for users working with your application on daily basis.

Flex

Cons:
No doubt that Flex has its own corks. Over the last few years we have seen all sorts of problems ranging from weird layout problems to the protocol specific one, where the Flash Player would offset the timestamps in date type fields. Other problems included\ lack of page specific navigation and total application crash when something goes wrong, but all these problems can be addressed with proper coding and testing.

Pros:
Today there are many flash-based applications and games exist which can be downloaded from iTunes. This became possible after Apple removed the ban on Flash applications back in Sep 2010.

While being a single vendor standard Flex is open and keeps progressing supported by a single vendor implementation. This fact should allow us to have identical UI across all devices. Other important advantages for our current products are: existing assets which include application infrastructure, reusable code, and, the most important of all – our experience. Over the last few years developing PULSE and iEHS we have come up with many problems being layout or protocol specific. But thanks to our teams we have overcame those challenges and moved on collecting an important experience along the way.

Considering the thoughts outlined above, we have decided to use Flex as our mobile platform for iEHS. The prototype is yet to be created, but I am quite excited about the opportunity to expand our experience and build a totally new layer of services which we can provide to our clients.

About the author

Aram brings to PointSource over 15 years of experience in the IT industry. He joined PointSource in 2007, after working closely with the PointSource team for over 6 years on varying projects as a consultant. Aram is an experienced software architect who has been involved in numerous complex solutions involving multiple technologies. He has authored and co-authored multiple publications in both IT and science related fields. Aram holds an MS degree in Theoretical Physics from Yerevan State University, Armenia, with a specialization in Computer Modeling in Physics.

  for their research and contribution to this blog.

Resources:

HTML5 and Mobile
http://www.slideshare.net/WorkLightInc/…

Tablet devices and enterprise apps
http://www.riagora.com/2011/10/…

A whitepaper comparing Flex, Silverlight and HTML5
http://www.scottlogic.co.uk/blog/colin/2011/05/…

HTML5 Support in browsers
http://caniuse.com/#