Forget Native: Learn to Write HTML5 Mobile Apps

You want to write a bunch of mobile applications, but you dread learning the Objective-C of iOS, the flavors of “bastardized Java” for Android and BlackBerry, or the C#/Visual Basic of Windows Phone. Never fear—armed with your existing knowledge of HTML and CSS, you too can write some killer, device agnostic, mobile applications and even learn the required steps for taking part in each device’s hardware functionality.

Native development can be great for games and those needing hardcore CPU or graphics processing power. But most of the non-gaming applications you use everyday can be (or already are) written in HTML5 offering you one code-base to serve a diverse hardware market.

In addition to training and creating their first, basic HTML5 mobile application, attendees will also learn about marketing and delivery options for non-native applications.

Forget Native

https://github.com/skookum/webchat
https://pinboard.in/u:dbecher/t:sxswtalk/
http://schedule.sxsw.com/2013/events/event_IAP15741

What are mobile web apps good for? Also: What are they not good for?

Good For:

  • Simple document viewing / data viewing.
  • Simple data entry (no long form text or rich text editing)
  • Example: Lanyard (http://m.lanyard.com) - focuses on things that are reasonable on a mobile device
  • Easier Cross-Device compatibility. Still need to test, test, test!

Not Good For:

  • Games
  • Complex data viewing / editing
  • Anything that might require complex data processing on the client (media, image processing)

How to make sure that a web app is the right fit?

  • Refine the problem before you start. How complex is your problem?
  • Cut all non-essential features. On a mobile device, what are people going to want to do? What are they not going to want to do?
  • Take inventory of every screen. How many views are required to do what you want to do? If you are getting into double digits, you either need to cut or rethink your approach.

What’s different about a mobile web app? How are applications different than a website?

  • More time consuming to build.
  • A mobile app is going to be a lot slower than on the desktop.
  • Everything you add to the page is going to slow it down.
  • A mobile web app is offline-able. On a desktop site you assume that they are online. Not so on mobile.
  • Important that you user-test it.
  • A mobile site is more bleeding edge. You don’t have to worry about old browsers. What this doesn’t mean is only testing in webkit.
  • Less focused on things like SEO. Most traffic is going to direct traffic.

meta tags

  • Viewport - meta name=“viewport”
  • IE10 ignores the viewport tag for anything less than 400px. @-ms-viewport {width: device-width;}

Icons

  • Custom home screen icons.
  • Link tags in header

Startup Image

  • Only applies to an iPhone
  • Specify a static PNG
  • Should be the default view to give the appearance of a quick launch
  • In iPhone 5, if you don’t have the full screen image, it will render in letterbox mode

Other

  • apple-mobile-web-app-capable
  • apple-mobile-web-app-status-bar-style
  • apple-mobile-web-app-title
  • format-detection
  • cleartype (IE10)

New form input types

  • Dates
  • Use whenever possible, even if it is not supported, it will eventually be supported and you will get a custom keyboard.

Special Content Types

  • Email Input Field
  • URL Input
  • Telephone Input
  • Number Input

HTML5 Audio / Video Tags

Allow you to play back audio and video content in a way that is optimized for the device that the user is on.

Cache Manifest

  • Tells the browser to download assets to store locally to be used offline. Allows you to launch and potentially use the application.’
  • ALA Article - Application Cache is a Douchebag
  • A separate file that you would reference in your HTML
  • If you use this, files always come from the cache. New files are only downloaded when the Manifest changes. The manifest itself - not the files.
  • Can add comments in the manifest and it will force a download of the new content.
  • Don’t ever cache the Cache Manifest!
  • No conditional downloads.

Best Practices

  • Don’t hide your content. Make any relevant content easily viewable. Example - When you click on a link and are redirected to the mobile homepage and then you have to find the article again.
  • Don’t use hover states.
  • Use content types that are supported (PNGs with transparency, H.264 video, mp3)
  • Don’t use plug-ins
  • Use native elements (form controls)
  • Use feature detection (modernizer)

HTML Performance Considerations

  • Defer parsing of JS.
  • Defer and async on scripts.
  • Use as few elements on a page as possible. As few HTML elements (tags, nesting). Simple applications should have a simple HTML structure.
  • Above 480 elements on the page, it starts to feel laggy.

CSS Pre-processors - make it easy to write bloated code.

  • Gradients - use them wherever you use images (background for example)
  • Border Radius - no prefix, just the standards version
  • Shadows - box-shadow and text-shadow
  • -webkit-user-select (none | text | all | element) also -moz-user-select, -ms-user-select
  • Transforms - Translating an element in 3D space. Need to supply vendor prefixes. Really useful for animating content. One benefit of these is that the browsers can optimize them. Some transform properties are hardware accelerated.
  • Two types of transforms - Transition, Animate

CSS Performance Considerations

  • Some properties are slow (really slow) - Especially border radius
  • Selector matching can be slow
  • Remove unused selectors
  • Don’t use universal rules (star selector)
  • Be careful when using reset stylesheet - Going to use universal and tag rules. Normalize.css has better performance than most.
  • Don’t overly qualify ID and class selectors.
  • Use the most specific category possible. If you can take a tag selector and add a class, that will be better than just using the tag selector.
  • Avoid the descendant selector. The most expensive selector that you can use in your CSS. Probably want to use a child selector instead.
  • Use inheritance. Setting font size for the entire page. Setting the list style on the container.
  • How do I know if my CSS is bad? Webkit CSS profiler. CSS Profiles. Shows every selector, how many matches (rough idea) and total percentage of time taken to match. 0 means there is no match and can be removed.
  • Audits tool. Shows which rules are not being used on the current page.
  • http://www.stuffandnonsense.co.uk/archives/css_specificity_wars.html

Javascript

  • Needs to be optimized the most.
  • Don’t use JQuery (or JQuery Mobile) on a mobile web app.
  • Zeptojs.com - Written with modern browsers in mind.
  • Ender.js
  • Use small, light frameworks - microjs.com

Features you can use in JS

  • Local Storage - lets you store data in the client persistently. Up to 5MB of data. Not for storing cached assets. For displaying data to the user.
  • Cors - Cross Origin Resource Sharing - Allows you to use Ajax requests across domains. Useful if you have a client / server architecture.
  • Geolocation - From cell towers, GPS, wifi access points. Two types - current position once or watch for their position. You get Lat / Long, heading and speed, accuracy. Before you get the location, the user must allow it.
  • Touch Events - useful for more accurately specifying what should happen when a user touches the page. It’s up to you to chain the events together.
  • Pointer Events - Are going to be the standard for the touch mobil events. Only supported by IE10 (Windows 8). Gives you the simplicity of mouse events but with more power. Pointer events go in the CSS.

Best Practices in JS

  • Be optimistic when writing JS.
  • Use local data (as opposed to remote data). Use local storage to sync data to the server later. You aren’t making the user needlessly wait.
  • Use Templates (mustache). All of the individual views are in templates.

Performance Considerations for JS

  • Memory management. Work with the garbage collector to make the JS run efficiently.
  • Managing events. Often times we start to listen for an event but don’t stop. On the desktop, the event listener ends when they leave the page.
  • Don’t load thing into memory until they are needed.
  • Reduce Reflows. When the dimensions change, the browser has to re-layout the page.
  • Don’t update DOM nodes on the page rapidly if you don’t have to.

Marketing / Delivery

  • Add to Home Screen - Detect if the browser is in standalone mode. Most people don’t know this exists. Will probably require some coaching. No downside to having someone add to home screen.
  • Wrap in a native application. Phonegap. Performance hit by doing this. Don’t get the faster JS engine.

⇠ Next Article Previous Article ⇢

About The Author

G. Brad Hopkins's avatar
  • G. Brad Hopkins
  • About Me: I bought my first computer - an Apple Performa 6320 - when I was in college and have been building websites ever since. These days I spend most of my time writing code and helping to bring interesting projects to life.
  • @gbradhopkins