Dan Bricklin's Web Site: www.bricklin.com
An Overview of HTML 5, PhoneGap, and Mobile Apps
Understanding how web languages are used for apps and how they work with native code.
In my discussions with business IT people, I'm finding that the use of HTML5 and perhaps "hybrid" architecture is becoming more and more commonly accepted. However, I'm also finding out that most people don't understand exactly what this means, nor have a clear picture that lets them differentiate between variations of that architecture supported by the multitude of development environments. This essay fills in a lot of the details to help you understand that picture.
When browsers first came into being back in the early 1990's, web pages were specified using a single computer language, HTML, the HyperText Markup Language. HTML covered the content (text and images), the presentation of that content (layout, fonts, etc.), and behavior (links, buttons, typing areas, etc.). Everything was right there in the one specification of that language, and if you knew that language you could create any type of web page that could be displayed by the browser. To change what was displayed on the screen, the author would have you switch between a series of different pages. These pages were often created dynamically by a program accessed through a web server, with each successive page having different HTML.
People were pretty happy with being able to so easily create usable presentations of information, and do basic interactions and transactions. If a developer knew the HTML language, and knew how to write programs in a language supported by web servers (initially Perl, but later PHP, Java, Cold Fusion, and other languages), they could bring all sorts of useful functionality to users around the world who could connect to their servers through the Internet.
Early HTML was very bare-bones. The main content was text. It had very simple visual markup, such as letting you specify text as normal body text, more pronounced headings, mono-spaced font computer program listings, or list items. Over time, different browsers added additional capabilities. One of the earliest was the addition of in-line images in the Mosaic browser, adding this content type. Later we saw the addition of the FONT tag to let the author more precisely specify the look of text and the TABLE tag that could be used for both more complex lists and for control of positional layout. Netscape drove a lot of this expansion of the language, attracting many graphic design-oriented people to its camp. Many web sites were created that depended upon these new features, leading to notices of "Best viewed in Netscape". The Internet community continued to expand the standard language, and the various browser developers (most influentially at the time Microsoft and Netscape) moved in that direction. This brought on new versions of HTML: HTML 2, HTML 3.2 and HTML 4.
The initial "HTML does it all" architecture quickly became a limitation. Interaction designers and programmers wanted more control over the behavior and the ability to add functionality. Visual designers wanted more control over the "look" of the pages.
The community of developers making browsers produced yet another language, CSS (from the words Cascading Style Sheets), for addressing the presentation and layout of HTML pages. Rather than explicitly code positioning information in the HTML with table cells and the colors, fonts, and other visual aspects with special HTML tags and attributes on those tags, a more general purpose method was proposed. This used a hierarchy of definitions written in the CSS language, included either as part of an HTML page or referenced in a separate file on the web server and loaded by the browser, that when processed for any particular HTML element specified how that element was to be presented. This separated the definition of the presentation (the CSS) from the content (the HTML). By careful use of the "cascading" hierarchy of the CSS definitions, a web page author could easily change the look of a page to suit different situations (such as to be different when printed than when viewed on the screen). The CSS language lent itself to enhancement over time on many facets, such as fonts, colors, borders, backgrounds, and more, and having those being able to be applied to all different types of HTML elements without needing to change the definition of the HTML language, or even changing the HTML of an existing page.
Support for CSS arrived slowly in the browsers. To meet the needs of web page designers, the behavior of CSS on the different browsers had to be as identical as possible in all cases. Retrofitting such specifications (which were evolving) into existing browser implementations was difficult. However, eventually a reasonable subset of a "full" implementation of CSS could be found in the major browsers.
This combination fueled a change in the experience of using the web. Email systems, like Google's Gmail in 2004, and productivity applications from the early Halfbrain.com spreadsheet in 1999 to Google Docs around 2006 changed the feel of the web from "click, wait, click, wait" to desktop-like interaction but with real-time access to data on shared servers. Seeing Google Maps (released in 2005) for the first time was a real game changer for many people and inspired them to better exploit the capabilities of the browser for their own applications.
Recent advances and the name HTML 5
The latest browsers have pushed things further. At this point, a large percentage of all browser users are running relatively recent versions, and those versions are becoming better at getting the users to continue to upgrade with new releases.
The benefits of these new versions include better and better support for HTML 5. This version of the standards specification improves on the older HTML 4 which helped usher in the CSS era. HTML 5 includes native video and audio as well as the CANVAS element and other means for supporting vector graphics. This means that the standard browser content can now be text, image, audio, video, and vector graphics. These features lessen the need for native code add-ins for this functionality, making it more standards-based and consistent across multiple browsers.
The early mobile phones and PDAs that included Internet connectivity and HTML web browsing posed new challenges. These included the Palm/Handspring Treo, the Microsoft-software based phones and handhelds, the Symbian-based devices, and many cell phones with mobile versions of the Opera browsers built-in. Compared to today's smartphones, these devices had limited processing and display capabilities, limited memory, and limited bandwidth. They also had quite small screens, physically and in number of pixels.
Users of such devices were initially quite pleased to have any web access at all on those devices. It was quite liberating compared to needing to be at a desktop or laptop computer. Over time, though, you miss being able to have a more full experience.
In July 2008 Apple started to allow developers outside of Apple write applications in "native code" that could be installed and be stored on the iPhone and used without needing an Internet connection. These applications had to be written in the main Apple development language, Objective-C, a language dating back at least to the days of the NeXT operating system developed in the 1980s but accessing the new functionality provided by Apple in the iPhone operating system (later named iOS).
Mobile App Development
Creating apps for iOS (iPhone, iPod touch, and iPad) is similar to programming for a desktop or laptop computer. You write code using the Objective-C language, which looks somewhat similar to other languages derived from the original C programming language used to create Unix. The language has additional syntax to access software objects that make use of the "[" and "]" characters and named arguments to object methods. For example, to set the image on a button, you might use the statement:
[stopButton setImage:[UIImage imageNamed:@"stop.png"]
Programs make use of libraries of code provided by Apple as part of the iOS operating system. For example, the "setImage: forState:" method of the UIButton class shown here is provided as part of iOS. Those libraries are quite extensive, providing objects and methods for everything from buttons and lists to timers, strings, network I/O, cameras, GPS, and much more. The definitions of how to use these libraries are called the Application Program Interface (API) for iOS. Once the code for an app is written, it is compiled on a Mac, and then the resulting ".ipa" file (an iOS App Store Package) may be installed on an iOS device. The process for this is described below.
For Android apps, the process is similar. The language, though, is Java, the same language commonly used for many other purposes, including for writing corporate server-based applications. Java has a more common syntax and was first released to the public in 1995. The functionality provided by the Android code libraries, the Android API, is extensive, much like for iOS. The files for installing apps are ".apk" files (Android application package).
Writing apps in native code has the advantage of having direct access to all of the functionality that the device manufacturer provides to developers through the operating system API. This API usually lets a developer access most of what the manufacturer uses for their built-in apps for the device. Together with native code for speed, using the API for access to functionality gives rise to smooth games, interfaces that use the operating system's standard visual controls, and integration of much of the hardware capabilities of the device including touch, accelerometers, GPS, cameras, camera illumination light, etc.
Another benefit of native code apps is that they may be installed on the device and reside in storage on the device. This lets them be started using the device operating system's standard means of launching apps (e.g., the home screen on iOS) and execute without requiring, in most cases, an Internet connection.
A common use of a Web View is to provide informational help screens in an app. It is often much easier to write and display the content you would expect in a help system this way. The user of the app would not see anything unusual when part or all of the screen is rendered this way. In fact, it is better than the more simplistic displays that a programmer might otherwise have had to use in order to create their app in a reasonable amount of time. For example, in early versions of iOS (and even, to some extent, in later ones) displaying "rich text" with mixed fonts, borders, images, etc., is very complex to program and to author content for. Use of a Web View and a little local HTML, CSS, and some image files is much easier. In other cases, the HTML could be created programmatically in the native code based upon live data, but then that HTML would be displayed using a Web View as a part of a more complete data display, perhaps including graphics drawn using native code next to the Web View.
Sometimes this combination of a simple Web View with all or almost all of the app functionality written in browser languages is called a "wrapped" app or a wrapped HTML5 app. (Note that there are other computer-oriented uses of the term "wrap", such as to refer to installation or application management and security information added to the app package.) An app that uses both HTML and native code is often referred to as a "hybrid" app, especially if it makes use of native code facilities not normally available to a browser.
To the app user, whether or not a Web View is present on the screen is not apparent. It is just one of the many controls available to the app developer.
PhoneGap and Cordova
The PhoneGap system started out as an Open Source project from a company named Nitobi. The company was acquired by Adobe in 2011. The code was then contributed to the Apache Software Foundation, where it is known as Apache Cordova and is therefore somewhat independent of Adobe, though Adobe is a main contributor to, and distributor of, the project. Adobe distributes the Open Source Cordova code under the name PhoneGap and provides services called PhoneGap Build. We will use the terms Cordova and PhoneGap somewhat interchangeably except as noted.
To create a "PhoneGap app" as a developer, you download the Cordova sample code for the desired operating system. That sample has all that you need to build a basic app that starts up as a full-screen Web View and then runs some simple HTML code showing that PhoneGap is active. You edit the downloaded code in the normal development environment that you use to create native apps for an operating system. You can then replace the sample HTML with your own, or have the Web View start out by loading the HTML from a URL on the web. The sample code includes many basic plug-ins, such as for accessing the camera and accelerometer, but you can download and include others in your development environment if needed. You then build the app as you would any normal native app, and test and deploy the resulting app package.
This process is pretty simple for apps whose functionality is completely provided through PhoneGap. If you want more extensive native code, for example, to handle various conditions natively, or to add additional screens and controls that are implemented in native code, you just modify the sample code in the native language. Alternatively, you use the sample code as a guide for adding Cordova code to an existing project.
While the frameworks take care of much of the work to display data and provide controls like buttons, a developer still has to write the code to actually provide the data to the controls and react to presses of those buttons. The frameworks have many, many options to provide for some of the customization that is needed for different apps. Setting up the code for this can be additional tedious work. There are tools being developed that make it easier to create some of such code but there are still a lot of pieces to the puzzle of creating an app.
Of course, all of this is just for developing the part of an application that runs on the mobile device. For many complete applications, you also need to develop the server, database, and web service components. For many applications, especially in business but also customer-facing, a regular desktop/laptop browser interface is also needed.
There are a variety of ways to deploy apps to mobile devices for use by end users. For example, web apps that are served up by a regular web server are relatively easy to deploy. You just need to open the correct URL in a web browser, such as Safari (iOS) or Chrome (Android). Control over who uses it may come from passwords and other methods common to web sites. Unfortunately, web apps may be operating with the browser controls still visible, such as the "Back" and "Refresh" buttons and the address bar. You can add URLs as bookmarks on the home page of many devices, but, for example, on iOS the browser that comes up when you use such bookmarks reloads from scratch each time you switch back to that app so you can lose state during a phone call.
For most common apps right now you will want a separate icon on the home page that launches the app or returns to the currently running copy as it was when you last saw it. This involves installing the app on the device. Apps are installed using app packages. The installation functionality in most of these phones enforces certain rules about what may be installed. In general, the app package must include appropriate credential data. The credential data, actually computer data "keys" created using various cryptographic methods, ensures that there is some information about the origin of the app's code and gives the operating system company control over what may be installed. Adding this data when putting together an app package is called "signing" the app package and is usually done by the app development tools.
For sources other than the Apple App Store, the installation is only allowed if that particular device (e.g., a specific iPhone or iPad) has an additional special data key installed on it (called a provisioning profile) and the app package was signed in way that makes reference to that profile. This allows a developer to send out test copies of their app to beta testers (this is called "ad hoc" distribution) and enterprises to distribute apps directly to their employees ("enterprise deployment"). There are restrictions, though, on the provisioning profiles. For example, a regular developer may only create provisioning profiles for up to 100 different devices each year, and an enterprise may only distribute profiles to devices that are used by employees or within the company, but not, for example, general use by customers. (At least, those are the current rules as I understand them.)
This means that installable apps that a company produces that they want to be used by others outside of the company on iOS devices may need to be submitted to the Apple App Store and available to everyone, though a login ID may be needed to make much use of it. (Apple must be given a test ID for review.) This is also the case if the developer and users don't qualify under Apple's "enterprise distribution" plan.
Android app packages must also be signed to be installed. However, there is no restriction that the packages must be distributed through a particular means. The signing lets the user insure that updates to an app only come from the originator, for example, and not from an imposter.
I hope you find this helpful in understanding the "lay of the land" in this important area.
-Dan Bricklin, May 2, 2013
© Copyright 1999-2017 by Daniel Bricklin
All Rights Reserved.