Design Android Apps Using Html5

I built my first mobile application in 2012 using the Sencha Touch framework and PhoneGap Build. Since then mobile applications have become my full time focus, and I have experimented with a few different frameworks like Famo.us, Phaser and more recently Ionic.

I've been building HTML5 mobile applications for around three years now, and am confident in the skills I have and the tools I use, to build mobile applications that look and perform just as well as native applications. Back in 2012 HTML5 mobile frameworks were already quite powerful, but they just keep getting better and better.

There were a lot of obstacles and roadblocks I hit along the way though. This was partly due to the fact that HTML5 was my first attempt at mobile app development (I had only ever done a small amount of native Android development previously), but mostly because there's a lot more twists and turns for HTML5 mobile developers than there is for native developers.

If you have a web background, it may be easier to learn a HTML5 mobile framework than pick up a native language like Objective C, but you have to learn how to deal with the complications that using HTML5 presents like:

Accessing Native APIs (use PhoneGap or PhoneGap Build)
Managing the DOM (a bloated DOM can lead to poor performance)
Giving the UI a native feel (this is mostly handled by the framework)
Creating App Store ready builds (again, use PhoneGap or PhoneGap Build)
Signing Applications (if you don't have a Mac you can use OpenSSL)

All of these things are easy enough to overcome once you know how to do it and have had a bit of practice, but discovering how to do everything is a little more difficult than doing it the "normal" native way.

There's quite a bit I've learned, discovered or surmised over the time that I have been developing hybrid mobile applications. These are the top 7 lessons that I think someone getting started with HTML5 mobile development should know.

1. HTML5 is NOT better than native, but it rarely matters

Despite what I said above about HTML5 mobile applications performing just as well as native mobile applications, high end native applications still have the potential to be better. The pareto principle, or the "80/20" rule, applies really well here. With HTML5 you can create an app that feels and performs about 80% as well as a well designed native app. If you want, or the clients wants, that last 20% – the beautifully smooth and magical experience – it's probably going to cost 80% more.

HTML5 does a great job across most platforms which drastically reduces cost by only having to develop a single version of the application, but to get a perfect app, an investment into developing native applications for each supported platform will be required.

I've turned down clients who seemed to want a Facebook level experience within their application, and told them that if they want that level of polish then HTML5 is not the answer. Often though these are the same people that don't realise the level of investment required to create an application like that. HTML5 can do some amazing things and Fastbook by Sencha is a great example of this, but the engineering required to get that level of quality would be out of reach for most developers.

Some people have the impression that because there's a general consensus that native is better in terms of performance, that a HTML5 mobile app will be sub standard or poor performing; "if you want a real app then you should go native". The fact is though that in the majority of cases you wouldn't even be able to tell the difference, only when it comes to these high end apps where companies spend tens of thousands of dollars or more creating the perfect experience. A well designed HTML5 mobile application can outperform an average native application, and a lot more apps are using web tech these days than you probably realise (Netflix being one of the bigger "out and proud" HTML5 users).

When dealing with clients though, by far the most common thing I've noticed is: they do not care if it's HTML5 or native. In fact, despite explanation, they rarely ever understand the difference. Deliver what they want and they will be happy no matter what you make it with.

2. It is possible to create iOS applications without a Mac

It is an extremely common misconception that you need a Mac to develop iOS applications, even if you're using HTML5. This is not true.

You couldn't be blamed for thinking it though, most tools will tell you that you need the iOS SDK only available on Macs to build for iOS. Take a look at what happens when I try to add iOS as a platform from a windows computer for example:

WARNING: Applications for platform ios can not be built on this OS

After seeing this message, one might reasonably conclude that they need a Mac if they want to build iOS applications. This is partly true: if you want to build the application on your machine you will require a Mac, but there are ways around it.

By using the PhoneGap Build cloud service to build the application (this avoids the requirement of having the SDK as the application is built on their end, not yours) and using OpenSSL to create a personal information file necessary for signing your application (which otherwise would require a Mac to create) you can easily create iOS applications on a Windows machine as well.

3. You need to use a HTML5 framework, and you need to choose a good one

As a caveat to the first point, if you're not using a decent HTML5 mobile framework then your app will be nowhere near as good as native. You should never attempt to build a mobile application without using a UI framework like Sencha Touch or Ionic, except in very specific circumstances.

HTML5 mobile frameworks have been engineered to handle all the unique challenges of creating native like behaviour with JavaScript. This includes things like screen transitions, scrolling lists with acceleration and deceleration, viewport bouncing and so on. The frameworks also improve performance by doing things like recycling DOM elements. It would require a monstrous effort to get anything that performs anywhere near as well as a native application without using one of these frameworks.

Even still though, some frameworks are just not as good as others and may not perform that well. There's so many available today, and of course some are good and some are bad. I can tell you that from my experience Sencha Touch and Ionic are both well performing frameworks and you won't go wrong with them. There's still plenty of frameworks that I have never even been able to take a look at though.

The amount of frameworks available is a double edged sword. It's great that there's options out there as it increases competition between the frameworks as they strive to be better than their competitors. At the same time though, it's possible that a framework you have chosen to use may stop being actively developed, it could be overtaken by a competitor, something completely new could come out that blows it out of the water and so on.

As a technologist you're probably used to keeping up with all the latest developments and constantly learning new skills. Native developers don't have to worry about these things though (well, to a lesser extent at least), as the language the device uses never changes.

4. HTML5 can do EVERYTHING native can do

Technically speaking, HTML5 by itself can only do what the browser can do. When compared to everything a native application can do that isn't a lot (a browser is very sandboxed).

With PhoneGap though, that doesn't really matter. The browser can talk to PhoneGap and PhoneGap can talk to the device, so the browser has access to everything that a native application does. The process may be a little more convoluted, but it's certainly possible – and since there's PhoneGap plugins available for just about everything you'll ever need to do it's pretty easy to implement native functionality.

If you want to learn more about PhoneGap and PhoneGap Build you can download my PhoneGap Build Quickstart Guide for free.

5. There are elitist native developers and defensive HTML5 developers

Some native mobile application developers portray an attitude that "real developers" code native mobile apps. Some HTML5 mobile app developers get defensive of their chosen tech and also go on the attack. This creates an extremely toxic environment that's completely unnecessary.

I think a lot of the animosity boils down to the fact that developers on either side of the argument are scared that the time they have invested into their tech is going to become redundant. There's benefits to using both in different circumstances, so to outright dismiss either option is not reasonable.

As developers, we often pride ourselves on our knowledge. It is easy to associate your self worth and identity with the skills you possess. Criticism of your chosen tech can often feel like a personal attack.

If you're getting into mobile application development – or anything really – always keep learning and approach everything with humility. Research the pros and cons of different options and don't believe everything everyone says, as they often have vested interests.

6. The DOM is the biggest determining factor for performance

Javascript performance is getting better and better, Apples new WKWebView with the NitroJS engine touts an impressive 400% increase, but that doesn't mean HTML5 mobile applications will perform 4x better.

The biggest limiter of performance for HTML5 mobile applications are DOM operations. The DOM, for those uninitiated, is the Document Object Model – it is essentially a tree of nodes that represents the structure of a web page.

As the DOM becomes more complex (more elements, more nesting) the tree structure of the DOM becomes more complex and takes longer to navigate and modify.

The frameworks you use will often have smart ways of reducing impact of manipulating the DOM (e.g most good frameworks recycle DOM elements in a scrolling list when they go off screen), but it's still something you need to pay attention to. Whenever you're building HTML5 mobile applications always keep this in mind and look up strategies for keeping the DOM as simple as possible.

7. Debugging is sometimes awesome, sometimes difficult

The benefit of using web technology to build mobile applications is that you can test it right in your browser – no emulators or devices needed. You can debug in an environment that you're probably already familiar with, something like Chrome Dev Tools.

Most of the time though, you will also be using something like PhoneGap. PhoneGap can not be tested through the browser since it accesses the native API's of the device (obviously not available through your browser).

To test any PhoneGap functionality you will need to test on a device, and then things become a little more difficult. You can use something like GapDebug to provide you with debugging tools similar to the browser whilst your app is installed on a device. This makes it easy enough to test, but the annoying part is having to create a new build with PhoneGap and install it on your device to test any changes.

NOTE: When testing with GapDebug, if your app isn't working and there are no errors in the console, try this:

Open up the debugger for your app
Wait for it to load
Go to the 'Resources' section and click the refresh icon

This will ensure the debugger is active when your app is starting up, so you won't miss any errors that occur right at the start. It's very common for HTML5 mobile applications to get stuck at the start up screen when installed on a device (but not when run through the browser) – this is usually because some error is occurring on the device that you can't see (usually related to a PhoneGap plugin).

Summary

There's certainly a lot to know when it comes to building web or hybrid mobile applications. A lot of this is technical stuff like "how do I pull in data from a server?", but as I've outlined above, there's also a lot of conceptual differences between native and web.

The conceptual stuff can be quite hard to figure out initially, and it took me a while to understand what was going on behind the scenes or why things were done a certain way. Hopefully this can give you a bit of a head start if you're going through the same things.

If you're just starting out with mobile development, feel free to post your thoughts or questions below. If you're a more seasoned mobile developer – HTML5, native or other – it'd also be great to hear your thoughts below.