With the rise of HTML5, the technology world continues to buzz with talk of moving mobile application development from a native approach.
NATIVE VS. WEB
APP DEVELOPMENT
HTML5 TRANSITION
page 1
Transitioning to HTML5 and details on the hybrid approach.PROS & CONS
page 2 - 3
Other valuable additions in HTML5 and an
introduction to WebKit.
MOBILE ISSUES
page 4
Common issues when developing HTML5 mobile applications.
CONCLUSION
page 5
Is the technology mature enough to be used today?WHAT’S INSIDE
NATIVE VS. WEB
APP DEVELOPMENT
With the rise of HTML5, the technology world continues to buzz with talk of moving mobile application development from a native approach, whereby an application must be designed and developed for each individual mobile OS, to a web-based approach, in which one can build once and deploy to any device that has a browser.
The latter approach would be a panacea for any company bringing a mobile application to market. There would be no need to worry about the ever-changing dynamics of mobile hardware and operating systems or to fund and maintain multiple variations of the same application. The user could enjoy ubiquitous access from any screen. The benefits of using a web-based approach to mobile application development seem enormous, but are technologies such as HTML5 really ready for primetime?
IS IT TIME TO TRANSITION TO HTML5
THE HYBRID APPROACH
HTML5 – Not Standard. Widely Supported.
Gaining Ground.
Presently, most apps built for mobile platforms, such as Android and iPhone, are native apps – which means they are developed specifically for these platforms. However, with the benefits touted within HTML5, developers aspire to be able to “build once and deploy to many” with the ability to create rich apps to run on any device with a web browser. In the end, HTML may win the battle, but it will surely take some time to get there. Both from a technical and market perspective, there are a handful of challenges to building HTML as the de facto approach to developing mobile apps.
There is a third option, an extension to web-based application development and closer to native application development– a hybrid approach. With a hybrid approach it is possible to place a native “wrapper” around core web-based application. This approach delivers more efficiency in terms of reuse than a pure native application since the core components are built using web technologies. This “core” can be built and deployed across the landscape of mobile platforms. However, the application can deliver a better experience for the user and the brand (compared to a mobile web site) since it utilizes native capabilities and features. This native “wrapper” extends the core of the application to the platform and is fully designed specific to the native OS. The effort to develop the native look and feel is limited to this wrapper versus having to redevelop the application in total. The utility of this hybrid development approach is dependent upon the complexity of the application, but can be suitable for a wide breath of applications. In its core, the hybrid-approach is still primarily web-based development with some advantages over pure HTML, but overall has the same key pros and cons.
Flexibility and Speed: Allows for faster implementation and deployment. Build one app and deploy to any
device with a browser. Plus, changes to the User Interface (UI) can be built and pushed instantaneously across the entire user base.
Less Costly: Instead of developing and supporting multiple specialized mobile variants, a web-based app
streamlines the effort since only one core app needs to be developed and maintained. The result saves time and money to produce and deploy.
Ecosystem: While HTML5 is still evolving, there is an incredibly large development community available to tap into.
HTML has an established base and Javascript is also one of the most popular programming languages. Many companies are creating tools and libraries for the web, but mature and well established tools are still lacking.
Standardization: Since web-based technologies are standard, a larger development base is available and the
application is transferable across vendors.
Distribution and Support: While debated, both web-based and
native apps offer a number of benefits for developers and users alike in terms of distribution. The Apple approach using a closed system built around native applications has certainly helped drive user and developer adoption within a controlled, centrally managed system. But proponents of web apps tout user accessibility as a benefit. No closed systems needed, a user can access an app direct from a company through their browser. An additional benefit for the developer is a potentially more lucrative revenue stream without an App Store middleman. However, discovery remains a problem. This will require some awareness building and some behavior changes, but in the end companies will ultimately be able to drive the relationship directly. The web-based applications have also the option to be packaged as native applications using an embedded web view. Technologies like PhoneGap help with this. This allows the web-based apps to be delivered either through the phones marketplace (e.g. App Store) or to be directly accessible.
PROS
Slower Performance: At present, HTML5 mobile apps cannot match native apps, or at least, not always with
acceptable performance. Applications requiring more sophisticated algorithms, complex data manipulation or those using heavier graphics are still slow when implemented as web-based applications. Conversely, natively built apps appear as a natural extension of the platform, seamlessly working with the controls and resident applications on the phone.
Current Adoption: The ultimate success of HTML5 is largely driven by network effects – if the base of users fails
to develop, support will diminish. Looking at online uptake alone, only 35% (source Alexa) of companies have adopted HTML5 to drive their websites. In the mobile space, native app usage continues to outpace mobile web usage. The typical mobile user consumes 30% more minutes on average with native apps versus the mobile web (source Flurry). Optimistically, this installed base will continue to foster to the point of dominance, but the ramp up may take longer than proponents might believe.
Slower Pace of Improvement: Also remember that HTML5 is a standard that is driven by a consortium. The process
to identify and implement improvements to the current state of HTML5 technology may take longer than expected. Mobile web browser vendors will most likely implement the latest proposals even before they become standards, but whether they will be universally available on all platforms implemented the same way is a big question.
Availability of Developer Tools: Gaps exist in the availability of developer tools to build HTML5 applications. Debugging on the Mobile Devices is Hard: Debugging HTML5 applications for mobile devices is hard. This is
especially true for the hybrid case where native and HTML code is mixed.
Many Javascript Frameworks: On one hand there are a lot of options for Javascript Frameworks, however they
presently are not mature enough.
Heavy Testing (Still) Required: Given some of HTML5’s present performance gaps, developers still need to heavily
test web-based applications across multiple mobile platforms in the market. As such, much of the benefit resulting from the development of one “core” application is negated presently.
CONS
WEB SOCKETS
Simplifies the exchange of data between web servers and web applications – thus supporting real bidirectional communication channels in the application. End result – Cloud-based apps perform with real-time access to data offline.
SUPPORT FOR CANVAS
An element that gives drawing space in JavaScript. It allows images or vector graphics to be added to Web pages on the fly. The end result is that rich and dynamic graphics can be created similar to the native application.
VIDEO AND AUDIO SUPPORT
HMTL5 serves up a richer platform with added tools to support multimedia in the application environment. The end result is that it is much easier to integrate audio and video content.
LOCAL STORAGE
Allows web applications to store data. Also, through a special manifest, the browser can cache pages, resources, CSS to be accessible even if offline mode. End result – Your online data can be available even when you go offline.
BACKGROUND THREADS
Allows running background threads via the Workers objects. The end benefit is that the application can perform background tasks without blocking the UI.
GEOLOCATION
Unified API that returns the location of the device. Typically supported on the mobile browsers and some of the desktop browsers.
HTML5 sounds like a panacea for cross platform development. It provides a common language and frameworks that can run on any mobile platform without any changes. In practice, this is not true, at least not with the current crop of mobile browsers. Things are especially bad with the Android platform where some devices are not easily upgradable and there can be devices in active use with old and possibly buggy versions of the operating system and the web browser.
Below are some common issues encountered when developing HTML5 mobile applications for Android:
When an input HTML element is clicked, a web view member function displaySoftKeyboard(boolean isTextView) is called. Internally it checks the current zoom level and, if it is different than a previously calculated default one, an automatic zooming is performed. This causes a problem because the user sees the screen transition and realizes that this is a web page. Furthermore, if manual zooming of the web view is forbidden (which is typically the case to avoid user zooming), then zooming back is impossible. There is a workaround for this issue using meta tags and setting the scale levels, but is only required for the Android platform.
When a select HTML element is invoked from the Android web view, the OS creates a native alert dialog box with a listview inside. The listview items contain a radio button and a text field. On some devices, this implementation is buggy and the text in the select items is not wrapped and appears cut off. The developers has no control over this behavior and may choose to avoid select elements. This is unfortunate because otherwise select elements “preserve” a native look and feel. One possible solution is to use radio button groups instead of select elements. Android’s webview has a lot of known bugs, some of which are very old and are still not fixed. Some blatant examples include:
• Issue 17535: WebView - URL mechanism is broken - passing parameters does not work; http://code.google.com/p/android/issues/detail?id=17535
• Issue 19293: WebView.loadUrl() can not load a local file if there is hash appended to the file path http://code.google.com/p/android/issues/detail?id=19293
Finding a workaround for such issues is often very time consuming and workarounds can lead to other issues. This can often negate the benefits of the common code base between the platforms.
On the positive side, browsers are maturing quickly. The browsers and HTML5 are at the center of the modern mobile platforms and a lot of effort is put to maintain and improve them. In the next few years these issues should be resolved and possibly through helper Javascript frameworks, a true cross-platform development can be achieved.
At present, the decision to move to web-based apps versus native largely depends on the use case. Consider the difference between two very different applications – a gaming app and a publishing app. The gaming app will rely much more heavily on the native controls of a specific mobile platform. The publishing app is much less dependent on native integration, typically featuring a fairly basic UI (consisting mainly of text and menus). Serving content within this framework is much less complex and therefore lends itself quite well to a web-based framework. The Financial Times is an excellent example of a publishing company that has delivered its application successfully using HTML5 technology. In less than six months since launching its web-based HTML5 app, the Financial Times signed on 1 million unique users. However, if any of the elements below are required in your application today, a native approach is likely a better path.
WHERE HTML5 WORKS (TODAY)
Complex graphics Sophisticated algorithms
Sophisticated UI and screen transitions with a lot of animations Very native looking UI, controls and behaviors
HTML5 will continue to mature and the installed base will grow over the near-term to support the technology as a de facto technology for deploying applications across the bevy of devices in market. However, the technology is not mature enough today to adequately deliver a quality mobile application experience for many companies. Limitations in terms of functionality and performance will likely hinder the adoption of the technology for many developers except those supporting less complex applications such as those in the publishing business. As the technology continues to mature, hybrid approaches appear to be an ideal bridge for many applications in advance of fully moving to web-based application development.
CONCLUSION
1 http://www.zdnet.com/facebooks-mark-zuckerberg-knocks-html5-in-favor-of-native-apps-7000004082/ 2 http://venturebeat.com/2012/05/02/linkedin-ipad-app-engineering/#s:1-linkedin-ipad http://gigaom.com/2012/01/09/mobile-app-use-soars-while-mobile-browsing-wanes/?utm%20source=newteevee&utm_medium=specialtopics http://blog.frontendforce.com/2010/04/html5-javascript-api-whats-new/SOURCES
NATIVE IS STILL PREFERRED FOR BETTER USER EXPERIENCE
The biggest argument for implementing the application natively is that it guarantees the best user experience. The cost is higher to maintain separate native applications for each platform, especially if three or more platforms must be supported. However, sometimes this is justified if it leads to a better overall user experience and higher adoption rate. A recent example of this is Facebook’s transition from HTML to native implementation. Facebook’s founder Mark Zuckerberg said in his first post-IPO interview, “The biggest mistake we made as a company was betting too much on HTML5 rather than native.”1 One of the biggest complaints about the Facebook’s HTML app
was its performance. Based on the Facebook experience it would be tempting to conclude that applications should be built natively. However, the Linkedin application for iPad, which was built almost entirely using HTML5, gets good user reviews (most people cannot tell that this is an HTML app).2
Abalta Technologies has served more than 60 brands and launched over 200 innovative programs, defining it as a leader in designing and developing location-based software.
Since 2003, Abalta Technologies has been focused on designing and delivering location-based software solutions. Each member of our team has helped pave the way for growth of GPS in the market today and Abalta continues to transform location data into a meaningful experience for businesses and consumers alike. Our experience in developing location-based software spans industries, global markets and technical platforms. From automotive-grade solutions to smart phone apps and in between, Abalta has delivered hundreds of proven solutions to the market. Abalta’s success in the field follows the continued adoption of GPS in our lives today. We have managed programs across numerous segments including outdoor recreation, sport and fitness, navigation, travel and tourism, and enterprise. Using location-based experiences, we have helped consumers connect with the world around them, with the brands they prefer and with each other.
Given our focus and dedication to the location-based software field, our value-add extends beyond development with a rich depth of expertise and awareness from which our customers and partners can benefit. From technology advice to market awareness, Abalta maintains a view of the field that is unrivaled in the market today. Across our customer engagements, this knowledge has helped our partners bring ideas to market more quickly and more efficiently while improving the final result.
We thank you for your interest in Abalta Technologies and look forward to working with you to bring your location-based ideas to life.
Abalta Founder and President, Michael O’Shea, merged Irish roots with a strong mission. Starting with the name “Abalta” -- which means “talented” and “capable” in Irish Gaelic -- and working towards completing the mission: To provide services and solutions to customers that would positively impact their businesses and the world. Bring unique talents and innovative capabilities to the table, resulting in their customers saying “Those guys really made a difference here.”
3510 Torrance Blvd., Suite 220 Torrance, California 90503 U.S.A
+1 (310) 316-0427
6480 Weathers Place, Suite 101 San Diego, California 92121 U.S.A
+1 (858) 458-0760
Mladost 1-A, Bl. 548, Office 305 Sofia 1729, BULGARIA
ABALTATECH.COM
@abaltatech
LOS ANGELES SAN DIEGO BULGARIA
