Tag: web mobile

Offline JavaScript Part 2 – Overview of Interfaces and APIs

In Part 1 we looked at the differences between partial and fully offline use cases. Part 2 provides an overview of the HTML5 Interfaces and JavaScript APIs that make it possible to go offline with web applications. Going offline involves working with multiple pieces and coding for specific patterns. I’ve tried my best to stick to technology that is widely available across the largest variety of browsers.

Offline dependencies

Offline web applications are dependent on three things.  It doesn’t matter if your application is partially or fully offline, you’ll still need to address these in your code.

  • Caching HTML, CSS and JavaScript
  • Data Storage
  • Offline/Online detection

Caching

Application Cache. The Application Cache, or AppCache, interface lets you specify and store HTML and CSS files as well as JavaScript libraries so that they are available from the browser’s native cache. Once an item is in the cache the browser will use it regardless of whether it’s online or offline. It’s almost like you never went offline!

The AppCache is an essential part of your application strategy for allowing offline browser reloads or restarts. Without this an application will simply fail to re-load while offline.

Data Storage

Browsers have a variety built-in JavaScript APIs for storing data. The data can be for maintaining the applications state such as for storing bookmarks and form data. Or, it can be used for storing information such as maps, address and phone lists, TO-DOs or points of interest for a vacation.

LocalStorage. The LocalStorage API is super-easy to use. It stores Strings in simple key/value pairs. It’s limited to about 5MBs on most browsers. The two main challenges you’ll run into with LocalStorage are hitting the storage limit and performance hits when serializing and deserializing data.

IndexedDB. IndexedDB is essentially an asynchronous noSQL database that lets you store a wide variety of datatypes so that you don’t have to deal with serialization/deserialization.  Datatypes include String, Object, Array, Blob, ArrayBuffer, Uint8Array and File. While many online sources will tell you that there isn’t a size limit, I’ll tell you that in general you should limit your storage on a mobile device around 50 – 100MBs to help prevent the browser from crashing.

WebSql. It’s widely recommended that you not build applications directly on WebSql. The World Wide Web Consortium (W3C) is letting this standard die off in favor of IndexedDB and LocalStorage. I’m really only including this here for reasons such as Safari 7 and and the Android native browsers before 4.4 only support WebSql. For more information on how to get around this read down to the section on IndexedDBShim.

3rd Party Browser Storage

If the built-in browser storage capabilities aren’t meeting your needs you still have other options.

IndexedDBShim. IndexedDBshim is a Polyfill for WebSQL-based browsers. Because IndexedDB isn’t natively supported on older versions Safari 7 and Opera you can use this 3rd party shim to transparently translate your IndexedDB code to work across Android and iOS.

PouchDB. PouchDB is an Open Source experimental library that is an attempt to smooth some of IndexedDB’s rough edges as well as provide additional functionality, such as the ability to sync with remote stores.

LocalForage (Mozilla).  LocalForage is also an attempt to bridge the gap between LocalStorage and IndexedDB. It gives you an interface that provides much wider browser coverage than IndexedDB by itself.  One of the downsides is the amount of storage you can use. If a user is on an older browser such as IE8 that’s limited to LocalStorage then that user will be limited to storing about 5MBs of data. If you requirements call for using more than that, such as downloading large address lists, then the app won’t work on that browser or you’ll have to build in some sort of paging mechanism that deletes the old data and brings in the new.

Offline/Online Detection

There are a number of ways to detect if the browser is online or offline as well as when the internet status changes.

NavigatorOnline.online.  Some browsers have a built-in detection mechanism. However, it is not always reliable and false positives are a distinct possibility. For that reason, you will have to build additional detection capabilities or lean towards a 3rd party library.

Offline.js. Offline.js is a small Open Source library (~3KB) that detects when you lose an internet connection and when it comes back up. While not perfect, it does handle a lot of cross-browser compatibility issues for you. And, if you find bugs you can always create a fix and submit pull requests.

References

Caniseuse – IndexedDB

Caniuse – LocalStorage

Caniuse – WebSQL

Let’s Take This Offline

6 myths on migrating from web to mobile

If you have a public facing website today, then it should be mobile enabled. Period. In this post when I say mobile I’m referring to both native and web mobile. There are an endless variety of articles discussing the benefits of moving from web to mobile, however there are very few articles on the internet that discuss the costs of migrating from a traditional web software development environment to mobile. And, yes, in 2013 there are still some major and not-so major companies that haven’t migrated to mobile. I think the best way to start talking about costs is to expose some common myths.

These myths are more about discussing the impact of not “going mobile” and adjusting to an increasingly mobile-friendly world. Consider your users to be the experts on what the mobile experience should or shouldn’t be like. Remember, building mobile web sites and apps in 2013/2014 is about accommodating usage patterns that many, many users have already adopted and are intimately familiar with. This is okay, but you’ll need to play by the rules already established by thousands of other companies and organizations that have already built mobile apps.  Don’t play and it could mean lost customers and slower business growth.

Myth #1 – Mobile, we don’t need no stinkin’ mobile. The sheer number of mobile devices in circulation is a hard, cold fact. There’s hundreds of millions of them. And rest assured these devices are well loved and used constantly 24 x 7 by their adoring owners. Smartphone and tablet sales worldwide have finally started to outnumber desktop sales. Along with the shift to mobile, the use cases have changed in a significant way. Think about this: desktop use cases only apply when you are sitting at your desk or crack open a laptop. In comparison, mobile devices go with us wherever we go and we can access them anytime and almost anywhere: such as standing in line at the grocery store, waiting for dinner at a restaurant, getting real-time driving directions and the list goes on and on. The very nature of having a device with you all the time, even when you go to bed, lends to its ease-of-access.

Myth #2 – Squeeze existing content onto a smaller screen. Don’t do it. It can lead to awful and sometimes nearly unusable navigation and surfing experiences. Users who spend many hours a day looking at their mobile devices and visiting dozens or hundreds of sites and apps that are mobile-ready will absolutely expect your content to be mobile compliant.  For this reason major phone OS vendors have spent a lot of time and money to publish user interface guidelines.

Myth #3 – Continue to use long development cycles. The mobile world changes fast. Prototyping should occur in hours, days or weeks rather than months or years. Full release cycles are  often measured in months. To get an idea of the pace of change check out how fast updates occur to the Android operating system. I’ve gotten feedback on some companies with mobile development cycles being planned for up to 1.5 years from design to delivery of v1.0. In today’s fast paced world that can be a sure bet for problems and increased risk of project failure.

Myth #4 – Recreate complex workflows on smaller screens. Mobile device workflows call for simplified, intuitive workflows with fewer steps. If you have what I’ll call an enterprise web app with dozens of menus and pullouts, pulldowns and multiple pages then you’ll need to do some homework along side a good user interface designer to figure out how to make it work on mobile. Chances are your app will have to be sliced and diced into smaller and more digestible chunks.

Myth #5 – Reuse existing security measures on mobile. Mobile security is vastly different than desktop security and applying desktop security patterns to mobile can be a recipe for disaster.  People carry their devices everywhere and they tend to download many different apps, and some people don’t even use their screen lock. We’ve all heard stories of devices being left unattended in public places or left behind at airport security screening.  So, there are many more ways for potentially serious security breaches to happen via mobile devices than your typical laptop.

Myth #6 – Users won’t like change. If you have a public facing web site today that’s not mobile compliant, chances are you’ll have a significant portion of your mobile users who aren’t happy. The best way to find out: survey. Ask your users what they think…don’t leave it to guesswork and opinions. Get the facts from the people who matter most: your customers. And, I’m going to go out on a limb and say that the majority of users would jump at the chance to use a mobile version of your website.

References

iOS Version History
Android Version History
WindowsPhone Version History
iOS User Interface Guidelines
Andriod User Interface Guidelines