Mobile Applications - Native vs. Web App (Part Three)

Continuing the series on from (Part One) and (Part Two) today I will talk about development of the apps, the tools available and some of the practices that allow a developer to create the advanced and interactive apps we see today.

Javascript - I'm a real boy programming ^ language.

JavaScript has become a powerful tool for developing web applications. There are an increasing number of well-polished applications that deploy JavaScript to a very high standard, Google Mail being a great example. There are several frameworks out there now that make JavaScript development a much more pleasant experience taking it away from a more procedural and messy coding style to a well formatted, OO, patterned approach and it is these frameworks that allow for the power providing in applications on the web today. A JavaScript library helps to make code that bit more manageable offering functionality to be integrated as and when needed, more akin to development in a native app language. JQuery as I’m sure many of you reading this article will know is one of the more popular frameworks and offers a lot of useful functions for a developer that would otherwise take a lot of time to develop and test. Libraries offer the developer a tool to speed up development of their application while maintaining good quality code.

Frameworks on the other hand offer a way to structure a system or component architecturally. There are particular frameworks that allow JavaScript developers to maintain their code and develop using tried and tested design patterns. One in particular I have used is Backbone.js; a lightweight library that helps building applications using MVC. Now I won’t go into too much depth with Backbone or MVC at this point as this is not a tutorial article and is out of scope of the subject, but the structure of Backbone (Model, Collection, View, Controller) allows for a well-formed, easy to maintain application and, as found on Backbones’ website have been utilised in a number of large applications such as LinkedIn Mobile, DocumentCloud and BitTorrent.

The point of this is to highlight that JavaScript is no longer just an option to add a little bit of functionality here and there. It is at the core of web application development and with the addition of libraries/frameworks it is rapidly becoming a technology to compete with native device languages. Another great bonus to tip the balance of development in the direction of JavaScript is that of IDE’s, your browser can be your IDE. When you look at the development tools available to you with browsers such as:

Google Chrome (Developer Tools)

Firefox (Firebug)

The ability to develop and test JavaScript on the fly makes it much easier to get started in developing JavaScript applications. Download and install your browser, you have your JS IDE. There is no fuss with ensuring you have the latest version of Eclipse, or JVM/JDK, no extra space or time to run/debug applications it is all there collectively at your fingertips inside your browser.

CSS3 – Hey there good looking!

CSS3 has made a huge impact into the aesthetics achievable in web development; this coupled with the semantically oriented mark-up of HTML5 has allowed the creation of some wonderful websites such as EllaDesign and HTML5Readiness. CSS3 offers a number of effects that, up until now, designers were forced to use images for (which as you all know increases bandwidth which we are trying to save!). HTML5 also offers us the Canvas API which allows for dynamic drawing on a page. Using JavaScript and CSS with canvas can achieve some stunning effects as demonstrated particularly by Liquid Particles. CSS3 offers tools that allow for modern, crisp and professional looking UI designs without the need for learning the multiple methodologies utilised for native UI design, for example UI design on the Android platform uses the View and ViewGroup nodes using XML which have requirements for how they must be laid out and structured. CSS3 brings together this diversity of knowledge to implement a single technology to allow cross-compatibility across devices. Boston Globe is another great example of all the main principles of web development (particularly responsive web design).

Mobile Apps - Native vs Web (Part Two)

While doing some more reading and research trying to determine the subject for this article (continuing from Part One of the series), I decided to elaborate on some factors I found leaning towards pro-native. This is not to say that I think they are wrong, or I am right but merely to offer an outlook that was possibly overlooked. Firstly, an argument of “if it needs no internet connection it should always be developed as a native app”.

The issue of internet connection or not is an issue of distribution, and the method by which apps are installed and updated.  Coming back to the subject of local storage (covered in Part 1) there is no reason to rule out a HTML5/CSS/JavaScript application for a pure offline application. There are a number of HTML5 browser games now that allows offline play. The use of local storage to store user data such as save states or appcache for assets and offers the same kind of functionality that would be available through a native app. Again the limitation is that most mobile markets do not allow for apps that are not natively developed. This is where the issue of cross compatibility comes in; the potential of web/browser applications is limited only by the self-serving restrictions imposed of the respective markets. Not only can the user data be stored you can cache most of, if not all the application data through the browser thus rendering the “offline == native” argument redundant.

Any application whether it is a native or web app will initially need downloading from the relevant website or the specific device market. In the case of said web app you can cache all downloaded components in the browser offering true offline capabilities and likely a much smaller first download than a native application will need due to the small amount of data in HTML/CSS/JavaScript files (especially when you consider minified files). Whether native or web technologies they are merely presentational, it is about the approach that suits the application. This issue of ‘installations’, ‘clean end to end experience’, ‘browser support’ are all concerns that have existing or rapidly developing solutions when you look at applications developed using  web technologies.

Installations as it is, I think people overlook installation via caching using the Application Cache interface or AppCache as it is otherwise known. This provides many benefits, albeit providing some functionality that is an unfamiliar experience for the user however with the push to cloud technologies and the impact the web is having on people’s everyday lives it is something a user will adjust to. AppCache also provides a seamless, transparent update to the application which is a benefit to the user in a number of ways. First, the speed is increased as cached resources are local thus removing the need to make server requests for assets, this has a noticeable issue in performance speed for the user. The only exception to this is a download of resources from the server that have changed but again, this only benefits the user as it seamlessly updates the application without the user being prompted or distracted by notifications. Eric Bidleman has a great article explaining AppCache in more depth. ^[1]

Installations are a short sighted concept and installation via caching and transparent upgrades are often overlooked even though the single feature has been credited as the main success behind the Google Chrome browser. Using the AppCache interface, which provides a transparent updates and seamless updates to the application, can benefit to the user in a number of ways. First, the speed is increased as cached resources are local thus removing the need to make server requests for assets, providing a noticeable issue in performance speed for the user. The occasion where performance may be an issue is when downloading newer versions of changed resources from the server, but again, this only benefits the user as it seamlessly updates the application without the user being prompted or distracted by notifications. The only major downside would be user confusion over the new, improved, and transparent installation/upgrade procedure as the rapid change in analogy may affect the experience of users whose expectations lie with the existing monotony of the “next, next, finish” interface and are off put by its absence.

It is not ‘installed’ but still perfectly functional offline, with the ability to get updates over an internet connection (as any native app would). The advantage of web technologies is the ability to use the flexibility offered by mark-up/presentation along with a number of robust, efficient libraries and API’s available. I think it is a case of people not trusting the nature of the connection, the user likes the trust offered on app markets – and the way that you install applications is irrelevant, it just needs a clear analogy. There are a number of other concerns when you consider the approach to take with mobile applications such as browser support with things such as CSS compliance and JavaScript engines, but the same argument applies when you consider developing apps across multiple devices. The overall cost of developing an application across multiple browsers is far less than employing more developers to deploy apps for iOS and Android etc. especially when you consider the financial cost of targeting both. Both use different native languages, both need separate IDE’s and one even requires a particular set of hardware and operating system. All major factors to consider when weighing up the business side of things with the technical.

References:

[1] http://www.html5rocks.com/en/tutorials/appcache/beginner/

Mobile Apps - Native vs Web (Part One)

Mobile development is booming at the moment, everybody wants a mobile application. However before development begins, a question comes up that is a rather hot subject at the moment, native or web app?

Source: Global Intelligence Alliance

The results of my recent reading seem to show a very large split over which of the two is best to use and if any particular one is better than the other. Will HTML5/JavaScript/CSS3 technologies ever be robust enough, even when their respective /specifications are finalised/, to lure the mainstream developer away from the native mobile platforms? It was an issue that up until recently I was rather stubborn over and attempted to always bias my findings toward web apps. I remained convinced there was a definitive yes, HTML5 is the way forward. On reflection however I don’t believe it is as simple a question to answer.

Source: w3

HTML5 brings some fantastic tools (and let’s face it, an awesome logo) to the table that can really help with the look and feel of mobile applications:

Geolocation ^[1] is one of them and it has a huge hype at the moment as it allows a user to ‘check’ themselves into places, let users know where they are/have been (with the users permission) and has become a novelty for a number of websites and allowed for some very interesting interactive experiences (see geocaching).

Local Storage ^[2] has been a massive bonus for HTML5, especially popular among game developers, allowing for both on and offline play. The ability to synchronise the local and server storage allows for true data persistence. The browser, for both mobiles and desktops, is slowly becoming the primary tool for a user.

Websockets ^[3] are another technology that simply cannot be ignored; they offer a solution to a problem that many people have implemented “hacks” for to do for a very long time. When you consider their potential for mobile applications, their bi-directional communications give much more efficient bandwidth consumption and will also be much more efficient with battery power consumption. Websockets also have the potential to push notifications to your device with much more efficiency than native API’s. It is not at the moment a guaranteed, concrete solution but again with things such as canvas, geolocation, WebGL it is the impact these technologies can have when developed and researched further.

The question I kept asking myself was can web apps ever replace a native application. Being new to mobile applications, new to JavaScript, new to HTML5 it was a question I asked over and over and spent many, many hours trawling blogs, books and articles to give a concrete answer for this question. Despite being new to the technologies in general I have realised I am asking the wrong question however. I am approaching the subject wrong trying to force the answer I want, I biased any opinions to making the answer yes, HTML5 is in fact better. I got over my zealous attitude to web technologies and realised it is not about one technology replacing the other; it is a case of what tool is best for a job. HTML5 will never be able to integrate with a device’ hardware to the level a native application can. However depending on the purpose of the application it brings a great alternative to having to learn a native language, learn a new IDE etc. It has allowed a whole new area of experimentation and potential, it has allowed a developer the flexibility to decide what tools are best for the job at hand. 

Source: Backbone.js (DocumentCloud)

Take Jérôme Gravel-Niquet’s Todo’s tutorial ^[4] using HTML5 and Backbone, a simple but effective application made possible without having to know Java or Objective C, without having to learn how to use Eclipse or buy a Mac. Knowing the ins and outs of each technology, each possibility is the key to developing an effective and efficient mobile application. Bear in mind however that these technologies are still growing and as more and more documentation is complete, more experts educate people like me on the benefits of the API’s it offers…the future is still very bright for the possibilities HTML5 can bring to not only mobile applications, but to the internet in general.

I suppose in summary I came to realise the simple truth. When you consider developing an application either natively or as a web-based application, it is a matter of finding the right tool for the job not about making the tool fit the job.

References:

[1] http://diveintohtml5.org/geolocation.html

[2] http://diveintohtml5.org/storage.html

[3] http://websocket.org/quantum.html

[4] http://localtodos.com/

Cotinued in Part Two - Discussing the arguments behind the 'installation' issues with Native vs Web

About Me...

I will be blogging about all things technical relating to the web that I can think of. My thoughts, opinions, and ramblings about all the nerdy subjects that I get excited about and I hope people enjoy said nerdy ramblings. Before these however, I should introduce myself.

I’m currently working as a back end developer producing Insurance related websites for a large Software House. I recently graduation as a Software Engineer from the University of Wolverhampton and I’ve started this blog to continue developing my more theoretical and academic thoughts and theories. I currently live in the United Kingdom with my better half, my two dogs and rats (yes I have pet rats!).

What started off a passing interest in computers through College has now developed into a growing passion for the technologies and trends on the web since progressing through University. I aim to expand my own and others knowledge on whatever areas I can and hope that people will enjoy both the writing and any code examples provided. I hope it can come to be a source of discussion, assistance, tutorials and to build a welcoming community to people who share the same passions and interests.