Cross-Platform Mobile Development Tools Analysis
Author: Alberto Crespell
Nowadays, there are several mobile operating systems on the market that hinder the creation of applications since each system uses a different programming language. To make an application reaching as many users as possible and avoid the problems caused by fragmentation, regarding to the resources needed to develop such applications and to minimize the time to market, some companies are offering solutions that aim to write code once and develop the application to all platforms.
The analysis is focused on evaluate the main solutions to write cross platform applications: PhoneGap, Titanium Appcelerator, Marmalade and Strawberry.
The way followed to analyze each tool consisted on develop a simple application using the Android SDK (Java) and then try to achieve the same results using each of the mentioned cross platform frameworks.
The application implemented with the Android SDK is a simple application to see weather and forecast of any city around the world. When the application start is shown a splash screen while saved weather forecast data of a city is loaded or during 4 seconds at least. If no forecast data is stored a help screen is showed, else forecast screen. In both cases there is a toolbar where the user can choose to load the weather forecast of its current location using GPS or any location by typing a city name. Forecast data and images are loaded from WorldWeatherOnline and data is stored serialized to check if the different frameworks support it. Finally, when the user clicks on any element of the forecast list is performed a cube animation with the corresponding weather icon as a texture using OpenGL.
PhoneGap provides an API to access device specific features not available in HTML / JS and some are not supported depending on the device’s operating system. IDE is not provided to help developing.
A key point of PhoneGap is that it helps to develop an application in different OS without the need of learning different languages. But some considerations have to be taken because mobile applications are conceptually very different than web ones and development methodologies and techniques have to be different.
The main problem of PhoneGap remains on the leak of standardization of HTML / CSS implementation, which use to be different along different OS and even in different versions of the same OS. The browser fragmentation slows down the development process and force to use dirty workarounds sometimes, even will force to write different code depending on the target OS.
The cost of using standard HTML rendered in a native web view is reflected in the fact that some features available in all OS that are implemented in different ways are not available when developing in HTML. For example: internationalization, native UI elements, native buttons or actions, notification system, communication between different applications, etc.
The use of a scripting language over the native layer leads to a lower performance.
Before using PhoneGap is very important to know which kind of application is going to be developed, which native features are going to be used and which are the target OS / versions.
There are performance problems with running tasks in background (background downloads, synchronization, processing, etc) as browsers run webpages in a single thread environment.
– Front-end compiler: generate the appropriate platform-specific native code, native project and build any specific code that is necessary to compile Titanium for a given platform compiler.
– Platform compiler & packager: launch compiler and packager specific of each OS.
Titanium has a development IDE that helps to autocomplete, deploy and debug.
Not standard HTML + CSS + JS. Framework is based on JS + JSS (style sheets), what increases the learning curve until developer become familiar with the Titanium API and the way to implement layouts.
Documentation API can be better, most method’s properties are defined by the data type (string, int, etc) without specifying which values are valid (for example font is defined as an object and height is defined as a float but it can be a string representing a percentage value as well). Some methods and classes have a description indicating availability in IPhone and Android but some not. The result is that lot of time was spend on Titanium forum to check values of the properties, search if some feature works in Android, searching workarounds, etc.
Overall impression is that Titanium is more mature regarding to IPhone than Android as it has more features, plugins and is less buggy.
Titanium framework includes features specific of each platform by enabling the use of Android Intents and Services, providing folders to place specific assets for IOs (IPhone / IPad) and Android (drawables of multiple densities) and detecting Android buttons events. On the other side, the benefit of enabling specific platform features leads to fragment the coding style with if statements to evaluate if the application is running under IOs or Android systems.
Despite of allowing the use of features specific from each platform there are other simple features that are in the common API that are not supported in one platform instead that the native platform covers that feature. For example gradients for Android are not supported using Titanium but yes with the SDK.
Programming style based on object oriented architecture.
From all the time needed to create an application the 80% of this time is wasted on implementing UI layouts instead of implementing the logic of the application.
While the native and PhoneGap weather applications are around 200 / 300KB, using Titanium it needs over 5MB (framework library include apache http, mozilla, jax, w3c dom).
Titanium allows writing Android and IPhone using the same language but this does not mean that writing code once will work on two systems; a lot of work is required to get same results on both platforms.
Marmalade is the re-branded evolution of Airplay SDK, a mobile cross platform to build mobile applications with standard C++. It consists of two main components:
– Marmalade System: it is an operating system abstraction API, it features a C style API that provides access and control of core device services, events and sub device properties. The developer is thus entirely abstracted from a given platform’s programming model and relieved of having to consider device-specific issues or even install any device specific development kits.
– Marmalade Studio: it is a suite of tools and runtime components focused on high-performance 2D/3D graphics and animation:
It implements a kind of virtual OS or middleware rendering with OpenGl, what makes possible that the application looks the same independently of the OS running on the device. So the application can be developed and debugged using the PC (x86) emulator and then deployed to devices ensuring the same results.
The applications have similar performance and graphics look the same in all OS, from old mobiles to the latest smartphones. In standard applications the developer has a virtual screen and does not to be worried about different layouts depending on the screen size. On the other side, the look & feel of the UI components is poor and doesn’t have the look&feel of the native UI.
Marmalade comes with a UI Builder, which at the moment is under beta version and when trying to design something fairly straight forward as screen composed by a background, one image and some labels, it takes a lot of time reading docs and dragging elements and layouts around and is very difficult to get anything as expected.
There are still some important points to keep in mind when using Marmalade. For example, devices with limited memory may behave unexpectedly when not managed correctly and devices with hardware limitations may have performance issues.
Strawberry is a cross platform framework very similar to Marmalade using C++ and OpenGL but adding support to instantiate the UI components of the target operating system, so applications have a native look & feel. Currently it is in private beta and it’s not known yet the available licenses and their costs. Being a beta version, support & documentation is very limited, but the C++ API is less complex than Marmalade, and more focused on app development.
Development is only supported on Mac OS via Xcode IDE.
Although all programming is developed using standard C++, interface layout is done using HTML & CSS. In this way developers can completely separate the logic from the presentation, and use different presentations for different kind of devices.
The HTML / CSS code is not W3C compliant, is totally custom and extensible, so there are elements that are not standard but facilitate the design of the application interface (button, slider, scroll view, etc.)
Being able to extend the HTML tags facilitates the reuse of custom components.
Strawberry has a standalone player that allows parallelizing the work of the layout designer and the programmer.
Strawberry uses OpenGL for drawing the UI components, which makes the presentation consistent across different platforms and resolutions.
Internationalization is supported using Strings files like in iPhone.
Multiresolution images are supported via image packages. Each package contains the images for each supported resolution. The framework will load at runtime the images at the closest resolution available on the package.
The analysis reveals three different types of frameworks:
- Web based: frameworks using a native web view to render standard HTML / CSS / JS code enabling the access to some native capabilities (access to the file system, GPS, etc.) in some platforms. This kind of frameworks doesn’t allow to use a native UI but can be a good option for rapid prototyping because doesn’t require much learning when the developer is familiar with HTML. The lack of standardization of the HTML browsers along different platforms and different versions of the same platform as well, makes difficult to achieve the same UI using the same code.
- Translators: frameworks using a layer to translate custom HTML into native code at runtime or with a pre-compiler. These frameworks can use native graphic components and have better performance than the web ones. Start to use these frameworks doesn’t require much learning because are similar to standard HTML / CSS / JS.
- Virtual SDK: frameworks implementing a virtual system. Like translators, these frameworks can have a native look & feel, but they require a learning process as it is like a new operating system.
Cross platform mobile frameworks are tools that are growing fast but are not mature yet, not enough to replace native development.
Before using a framework is important to set the requirements of the application (from development and UX points of view) and the target platform and versions in order to ensure that it will be useful.
As said before, web based frameworks can be useful for rapid prototyping but, surely, when the application grows it must be replaced by a native development or another kind of framework.
On the other hand, other frameworks are oriented to make code more consistent along the different platforms / versions and will contribute to ease the code maintenance when the application is in a production environment because there is one code for all platforms and fewer resources are required. Unfortunately, there is still a long way to go to ensure that one code can run in different platforms without doing some particular implementations to cover different native user experiences.
There is a limitation when new versions of native systems appear; developers have to wait until the frameworks are updated. Some frameworks allow developers to write their own modules, thus the new features can be added but it will represent an overwork for the developer and work that will be discarded when the framework adds the functionality.
For more details visit SlideShare @ http://www.slideshare.net/telefonicaid/cross-platform-mobile-dev-tools
Source code can be found @ https://github.com/telefonicaid/MobileCrossPlatformTools