Android apps vs Mobile Web apps

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.

The what

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.

Core features

  • Mobile application that works disconnected from the server
  • Local database to save the local data
  • Synchronization between the server and local databases

Optional features

  • 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

The who

Linkare, a company of Java developers!

The how

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!

Android

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

At the moment, we are implementing that same application (but not as a prototype which means more care with user interfaces – yes, this one is getting very pretty! 🙂 -, security, performance, etc.; therefore, we will probably go through this implementation till the end and make it a real application, ready to be downloaded and used in the real world) in HTML5 + CSS3 + JQuery (and JQuery Mobile) + Several other javascript libraries to aid in the development (and also to better structure the implementation to make this mini app more maintainable in the future).

One of Linkare’s best developers (I didn’t say Java here on purpose because, although he is a Java developer, in this case he is a very polyglot developer, adapting easily to other languages and technologies, including Javascript related libraries) is working on it at the moment, and the development time has reached the 2nd week, now, and I believe we are not even in half of the development final effort. Additionally, and although we can’t really compare the two because they have some important differences, namely in the synchronization services (we opted to implement REST web services using JSON as the serialization format to make sure the services are performant), it seems that the native application behaved faster!

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)

Conclusions

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?

Advertisements

2 comments

  1. This is very inspiring, as getting from the start & Having no real background in programming (aside from making some adventures on ZX-81 and MSX), I want to get started on developing something for my own Android based eBook reader and android app development training even this online course seems to be interesting http://www.wiziq.com/course/13599-professional-android-app-development-training-1-on-1-sessions. Has anyone tried any online courses so far. Please do provide a light on this also.

    1. First of all, thank you for your post. Now, about your question, I don’t know that course but it seems interesting, indeed. Nevertheless, and as I said in my post, that Android book was more than enough for me to get started 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s