Android : Developing HTML5 apps part 1


...the future

…the future

As promised in my previous blog post, in the following series of articles I will try to document the highs and lows of an android HTML5 application. Development is still ogoing, in fact the app is morphing from a simple RSS reader to something like a “web content explorer app”… the latest version includes the ability to pull a photostream from flicker. In this first part I will focus on :

  • Intel XDK new
  • HTML, CSS and jQuery

Intel XDK new

The whole app started as a playground where I could test out this platform, and I’m impressed. There isn’t much I can elaborate on here, not because the platform isnt great, but because it’s so easy to use. Everything is setup in a thoughtful and well laid out manner. I’ve never used cordova, weinre, or ripple before (all tolls that XDK uses), but it was such a breeze to start writing my app, emulate, test and build it. I especially like XDK’s test feature, which allows you to either launch your app by scanning a QR code, or simply selecting your app over WiFi, using the companion android app “intel xdk preview“. It makes testing on an actual device extremely easy. This is where the platform shines, in allowing the developer to focus on code, rather than the tools and infrastructure necessary to test and deploy and app.

Selection_105

Intel XDK’s testing screen

HTML, CSS and jQuery

The app is entirely based on HTML, CSS and javascript. At this point in time I have not used any of the “bridge frameworks” which allow you to access some native platform features through javascript functions. That means even things like swiping are implemented in javascript. When I first started out, I implemented the swipe functionality using touchSwipe, a 3rd party jquery library that focuses on touchscreen events. I did however run into a problem with this library. The library binds to a DOM element of your choice. In my case this was the main “body” element so the user can swipe left or right anywhere on the screen to change the RSS feed they are seeing. However, on binding to the element, the library suppresses other events that happen within the element. So for example, tapping on a tile within the body element would not work, because the “click” event would not bubble up from the tile div… it would get consumed and stopped by the touchSwipe library. This wasn’t a problem on my older android devices (running android versions up to and including 4.3), however on the newest android kitkat 4.4 this was a problem.

So I pivoted and instead used jQuery mobile’s swiperight and swipeleft functions. They worked quite well, and I didn’t run into any event suppression problems. I am still experimenting with what constitutes a “right swipe” and “left swipe”. That is to say, one needs to carefully set thresholds of when the swipeleft or swiperight events are triggered. I found that the default settings were too sensitive, and when trying to scroll vertically, jquery mobile would fire a swipe event because I have a tendency of moving my finger in a slight arc when scrolling up or down (probably what most mobile users do). So I had to adjust the default threshold for the events like so:

  • The jquery mobile swipe event documentation page mentions the setting $.event.special.swipe.horizontalDistanceThreshold but I was unclear on how exactly to change it.
  • The solution, as in many cases, was found in the fantastic stackexchange site, here. To re-iterate, you need to set the threshold before jquery mobile even loads (which is event before the document ready event fires), so as Gajotres mentions in his post, you’d need something like so:
    <script src="jquery.js"></script>
    <script>
        $(document).bind("mobileinit", function(){
            $.event.special.swipe.horizontalDistanceThreshold (default: 30px);
        });
    </script>
    <script src="jquery-mobile.js"></script>

As far as UI goes, it is based almost entirely on Sergey’s excellent Metro UI css. Again not much to say here, any developer with experience using the bootstrap framework will feel right at home, and thanks to Sergey’s work, everything pretty much works right out the box. I did however, want to experiment also with bootstrap directly, especially for the carousel I used in the photo slideshow (if you’re using the app, this is found via the menu > Show me photos > show slideshow). Here I ran into the obvious problem that the bootstrap css was conflicting with the metro UI css, leading to some unexpected UI features. My workaround was to enclose the carousel and it’s containing modal in a completely seperate html page, which only included the bootstrap css and javascript files, hence avoiding conflicts. There was one last hiccup here, since I naively just used a normal html link (the “a” element). But I still ran into problems because by default jQuery mobile binds to every “a” element and makes it an asynchronous call to the link, while keeping the results from the link within the original page. This is normally very helpful and accelerates single-page app development, but it wasn’t what I was after in this case since I actually wanted a completely new html page to avoid conflicts. In my case, the simple solution was to simply override jquery Mobile’s a binding with my own:

$('#showSlideshow').click(function(){
         window.location = "./carousel.html";
 });

(assuming the “a” element has an id of “showSlideshow” of course)

Last but not least, the perks of HTML5. I found the localstorage feature of HTML5 to be invaluable. The android app has no server side component (almost none – the marvelous YQL plays a fundamental part in this app – but more on that in a separate post)  so all user preferences (like last feed viewed, and hopefully soon – offline viewing) are all stored on the mobile device itself, rather than a user profile that is retrieved from a server. Localstorage was perfect for this and i’ve used it for:

  • Simple key value storage to store what feed or category the user was last viewing, for example:
localStorage.setItem('category','photos');
  • Complex array storage via JSON.stringify and JSON.parse (since localstorage can only handle strings, not javascript objects). The app basically downloads content from various sources and stores them in a javascript array. For persistence and passing the arrays between one function and another (rather than using the global scope) the array is then stringified and placed into localStorage like so:

localStorage.setItem(‘titles’, JSON.stringify(titles));

When needed again, the array is recreated from local storage by parsing the contents like so:

var titles = JSON.parse(localStorage.getItem(‘titles’+feedName));

Simple, easy and convenient :)

I have to say, I am believing those people who say “I have seen the future… it’s in my browser”

About these ads

3 thoughts on “Android : Developing HTML5 apps part 1

  1. Mobile environments are already crippled sufficiently by low power CPU, lack of memory and terrible process switching latency.

    Why on earth would you want to develop software with a language that makes this situation worse on a mobile platform?

    1. Hey Pogg,
      Well, I disagree that mobiles are low powered or crippled. Year on year we are seeing big improvements in hardware across all mobile platforms, like octo-core processors on tablets, and 64-bit CPU on the latest iPhone. So, the trend is that hardware keeps getting better and better. But aside from that concern, I think that HTML5 / Javascript get an unnecessarily bad rep when it comes to performance. It highly depends on how the app was written, but if done properly, an HTML5 app can come extremely close to native. Just look at m.youtube.com or other mobile sites…Even my simple app runs well on an old samsung ACE I was using…

      But the winning point imho is the ubiquity and ease of use of HTML5 + javascript. Browsers run literally everywhere (and by extension, so does HTML + javascript). Approaching the majority of clients with advantage has always been a selling point. Normally the design dept of a client would want a native app – cause does look and feel much better – but the operations people love how easy it is to maintain a relatively single code base, while sales people love that they can point out that the app runs across all platforms, and lastly the finance people always look at money, and it is so much cheaper to code, run and maintain an HTML5 app

      Native apps will always outperform and out better HTML5 apps – else they wouldnt need to be called “native” – but there are very compelling cases to using HTML5, in some cases, they are the better way to go. If you have smaller clients (like in Malta … most businesses are SMB), HTML5 is the best way forward since you need far fewer resources and capital/investment.

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