In the last year, more or less, I’ve been listening to a lot of discussions regarding the development of applications for mobile devices such as smart phones and tablets, with particular focus on the first kind of these two.
In most cases, the discussion is between the implementation of native apps versus non native or hybrid apps. Both have their pros and cons (for instance, you may read the first chapter of the book Pro Android Web Apps which explains the main capabilities of each) and, although I’m no expert in this kind of development (only 1 mobile application implemented using both approaches, as explained in the following sections of this post), I do now have a clearer vision of what are the main advantages and problems on both of these 2 approaches.
Create the mobile version of Clockare to enable users to register their own activity using their mobile phones in offline mode, synchronizing their data with the server anytime they want.
- Mobile application that works disconnected from the server
- Local database to save the local data
- Synchronization between the server and local databases
- Geolocation awareness in what concerns the presentation of the projects to which the user wishes to report the activity, i.e., depending on the user’s current location, detect and show the list of projects to which the user may report hours, sorted by geographical distance to her current location
- Accessing the device’s phone calls so that the user may associate them, if she wishes to do so, to the professional activity, i.e., to state directly from their phone that a specific phone call was a working call, which must be registered as such in the corresponding project
Linkare, a company of Java developers!
In the next two sections, both approaches we took (or, actually, are taking) to implement this application are explained. Before reading the following sections, though, bear in mind that we are a company of Java developers and that, this technological background may be the explanation for most of our conclusions!
The native implementation, using Android SDK took us only 1,5 weeks in 2011 (yes, that long ago!). This time includes the implementation of the services in Clockare’s server and all domain related changes to be synchronization aware. To learn how to do that application using Android, all it took was reading an Android book, to learn how the API works, install Android SDK into Eclipse, do some tests with that API and adapt those to the application’s specific needs. This implementation was only a prototype to test the development of applications using Android and, although only a prototype, all core features defined above were implemented in a more or less easy manner.
The main problem with that prototype is that it worked only in Android. However, and although it was just a prototype, without any investment in terms of the user interface to make it look good, nor in performance issues (notice that, for instance, the interaction with the mobile client app and the server was being made through SOAP services which are, by nature, very verbose, leading to penalties in performance but even so, the application behaved in a very satisfying way in terms of response time!), nor anything that we usually are concerned when making an application for real use, the truth is that for a newbie in Android, it took only 1,5 weeks to get it done!
Mobile Web App
So, at the moment, and with all the complains I’ve been listening during this development, I’m not really that excited about developing applications for mobile devices using this approach… (by the way, I believe this is a good opportunity to tell you that a second part of this post may be published later, depending on how well the development in the next weeks go)
Several internal discussions about other alternatives have already came up, including ADF mobile (for instance, take a look at the following blog, sponsored by Oracle – yes, I know, we can’t trust completely in something said by someone about… himself! 🙂 ) but we don’t know exactly how that works (yet) not are certain about licensing strategies and prices but I’m pretty sure it won’t be cheap.
So, at the moment, I don’t feel very confidant in advising people to implement their own applications for mobile devices using HTML5 + CSS3 + JQuery Mobile + …
I am certain that it is important to know more about those technologies and libraries – knowledge is precious – but using those, comes with a cost… in development time. If your requirements do not force you to support all existing mobile platforms, using native development only may be way more beneficial.
First, it doesn’t limit you to anything available in your device (it is true that more and more APIs are getting made to allow a developer using HTML5 to access the inner device’s sensors and tools but at which cost and when will they be ready? And what about future sensors and tools?…).
Second, rich components, namely components for dates (for instance, using a date picker natively was just a matter of drag and drop while using the second approach took us hours to choose the appropriate one – most of them were too slow in some of the mobile devices we tried!) are readily available, provide a coherent look and feel and are very easy to use.
Third, in development speed terms, the native implementation “kicked ass” and finally, although I don’t have any benchmarks that support my feeling, the native implemented version seemed better in performance terms, even when the only thing you do is click the option to go from screen 1 to screen 2. It seems to me that new frameworks will have to come up in the coming months/years to eliminate this gap and turn mobile development much more effective, reducing implementation costs and maximizing profits…
As a final note, I would like to notice, once again, that this is only my opinion and born from only one case. But even still, I believe it may be useful to share.
And what about you people? What were your experiences so far? Have you tried different approaches? Better results?