3 Approaches To Mobile – HTML5 Denver User Group Presentation

Tonight I had the pleasure of presenting at the HTML5 Denver User Group. It looked like there was a really good turnout of over 130 people. I followed an excellent presentation on JSON by Tom Marrs. He really dived down into the guts of what JSON is, and I wished someone had done as good of a job explaining it when I was just getting started using JSON.

The concept of my presentation was that there are three main approaches to building web mobile applications: JavaScript mobile, Hybrid and Responsive. By a show of hands it looked like over 50% in the audience were brand new to web mobile and I had planned for that so hopefully the level of content was just right. If you want to discuss any of the content in more detail, feel free to drop me an email.

Here’s a link to a PDF version of the presentation

Android emulator vs actual device

Native Android apps and web apps need to be tested on multiple phones and tablets before being placing into production. Period. Sure you can use the emulator to do some very basic UI sizing validation, but there is no substitute for testing on actual devices.

Typically, I have one phone with the latest version of the OS and the rest of my phones are WiFi-only and have no carrier agreement. Buying used devices with no cellular contract is one way to save money, and can help budget strapped shops to do more thorough cross-device quality assurance (QA) tests. Obviously there are too many different types of Android devices on the market for the typical shop to have all of them in house, but having a few different models and versions gives you a huge QA advantage.

Why not use the out-of-the-box emulator? I’m not saying you shouldn’t use the emulator at all. It can be a valuable tool for check UI differences across various screen sizes and resolutions. But, in my opinion that’s about it. Personally I don’t use the out-of-the-box Android emulator much at all for daily coding since I almost always have a phone handy. Here are a few things that an emulator cannot help you test:

  • Exact look and feel
  • Application load times
  • Application performance
  • UI performance (View transitions, orientation changes, scrolling)
  • Browser differences (for web apps)
  • Subtle differences in UI touch events
  • Real-world GPS testing
  • Battery usage/consumption
  • Unique characteristics from the handset manufacturer and carrier.

My final beef with the Android emulator is it is awfully slow even on powerful laptops. It’s simply not a feasible test platform if you have to do multiple builds in a reasonable amount of time. Waiting for the emulator to load can be a painful experience. Granted, under some circumstances you can leave a single instance of the emulator running and push multiple builds to it, it can still seem sluggish. From a productivity standpoint, my experience has been its cumulatively much faster to simply push builds to a phone. And then, as mentioned above, reserve the emulator for specific instances of testing screen sizes and resolutions.

Recommended bare-bones set up. I don’t have a particular manufacturer recommendation because that’s a personal choice. My bare-bones recommendations are more focused on Android SDK version and having at least one phone with the major versions. Since Donut-based v1.6 phones now represent 0.2% or less of all phones I no longer recommend testing on it. Having a v2.x phone is a really good idea for general distribution apps as it’s a fact that roughly 50% of the phones in circulation are still running it:

  • V2.x smartphone
  • V3.x smartphone
  • V4.x smartphone
  • V4.x tablet

If you have experience with testing across different versions please post your comments!

References

Using the Android Emulator

Android Version Dashboard

Supercharge your Android Emulator

How accurate is Android GPS? Part 1: Understanding Location Data

There are many different ways for developers to get access to location information using the Android SDK, and there are already plenty of code examples on the internet showing how to do that. This post, on the other hand, focuses on putting the location data into context and offers suggestions on how to use it in the best possible way. In this series I’ll discuss various aspects of the Android SDK’s android.location package and how you can best take advantage of them to build a great end-user experience.

To try out GPS different usage scenarios, be sure to download the GPSTester app, both the .apk and source code are available on github.

Six types of location data

It’s not just about latitude and longitude. The great thing about the Android SDK is you get access to a ton of information related to location. The fun, challenging and sometimes frustrating part is deciphering the information. There are six types of location data that you have programmatic access to. This data comes from what’s referred to as a provider, and it will be either a cellular network-based or a GPS provider. As you’ll see, you can use these providers in a variety of different ways.

All locations derived from the LocationManager are guaranteed to provide a valid latitude, longitude and timestamp, all the other parameters are optional depending on who manufactured the handset and who is providing cellular service. However, if you have a device that doesn’t give you access to the accuracy parameter then the location data is practically worthless. I haven’t come across such a device yet, but I’m assuming it’s possible. My advice: always check for null location parameter values in your production code.

Cached GPS. Most Androids have the ability to store the last know GPS location. This is typically used when an application first starts up, and you can retrieve the timestamp, latitude, longitude and accuracy.

locationManager.getLastKnownLocation(LocationManager.GPS_PROVIDER);

Cached Network. Android devices can also store the last known location as determined by the cellular carrier’s network location provider. The provider gathers information from the cell network and WiFi, if it’s turned on, then sends that off to a remote server-side process that crunches the information and sends back an approximate location. This is not available in all countries.  Just like the GPS, you’ll typically retrieve the timestamp, latitude, longitude and accuracy.

locationManager.getLastKnownLocation(LocationManager.NETWORK_PROVIDER);

Real-time GPS. This is the raw information that is streamed off the GPS.  When a GPS is first turned on it won’t immediately return any information, it has to basically warm up first. The warm up time varies by device and can typically take from one minute or longer if you are inside a building. More on that in a bit. Depending on what your provider allows you can get access to timestamp, latitude, longitude, altitude, bearing, speed, accuracy and distance travelled.

locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER,time,distance,listener);

Real-time Network. This is the raw network location provider information returned by the cellular carrier, such as AT&T in the U.S. Different carriers use different information to determine location such as WiFi data, GPS information, nearby cell towers, etc. Depending on what your carrier allows, you can get access to timestamp, latitude, longitude, altitude, accuracy and distance travelled.

locationManager.requestLocationUpdates(LocationManager.NETWORK_PROVIDER,time,distance,listener);

Passive. This option just means that your application can listen for location updates while it is in a minimized state. The idea is to save battery power, such that your applications providers aren’t running full speed ahead while the app is miminized. That would be huge battery drain. Passive location can listen for another application to request location updates. You may be able to get access to timestamp, latitude, longitude, altitude and accuracy. As far as I know, you won’t be able to determine from which provider this information was derived.

<receiver android:name=".PassiveLocationChangedReceiver" android:enabled="true"/>

NMEA. Although it’s not human readable, you can get access to the raw NMEA strings. Typically these strings are used for programmatic access and would only make sense to a developer or engineer. This data is often used in maritime apps. The data is only available once the GPS has warmed up, which is a concept discussed in more detail below.

addNmeaListener(GpsStatus.NmeaListener);

Working with cached locations

Working with cached locations is an interesting problem because the first location you get is not going to be the most accurate, and typically it can be wildly inaccurate compared to your actual, physical location. Think of the location capabilities on the device as being similar to a car engine on a cold morning. The engine needs to warm up first before it can perform optimally, and this typically takes a few minutes. And once the engine is warmed up, if you make a quick stop at the grocery store the engine will still be mostly warm when you come back out.  

Location provider components act in a very similar way. When an app is first launched the providers may be “cold”. The only information that is immediate accessible will be via cached network, cached GPS and the passive listener.  Alternatively, if the app is launched when the providers are still warm or even hot, then you will get better accuracy with the cached results and the real-time locations may start streaming sooner.

Cached locations aren’t always best 1st choice. When an app first launches, the inclination of many developers is to simply grab the cached location data and use that as a starting point, but as implied above…be careful! Caveat emptor applies here. Cached locations are simply the very last result stored on the phone and it’s not always what you expect. As you can see from the Cached Network Provider screenshot taken from the GPSTester app, the accuracy of that data snapshot is 1780 meters (1.1 miles). Keeping that in mind, consider these use cases:

Business traveler – You last opened the application on a business trip to San Francisco and you are now in Denver where you happen to live. When you start the app in Denver the cached locations could very well be for San Francisco.

Consumer –You last used the app at home and now you have traveled to the other side town, or even to a nearby city to visit friends. The last cached locations will be from near your home and not very helpful to your immediate surroundings.

Cached locations vary considerably because you almost always never leave the location provider services running constantly. Leaving them on all time can easily kill the battery in a few hours, and end users will unanimously reject that kind of battery life.  Therefore cached locations represent the fact that either your app or another app had explicitly turned on location providers at some point in the past.

Timestamp and accuracy. You will also want to compare the timestamps and accuracy of the cached network and cached GPS. If network data isn’t available then look at the cached GPS results. If both are available then check to see which one is the most recent.  Here are several example use cases to demonstrate whether or not they would be valid for your requirements. Which one would you go with?

Date of cached network data is 7 days old and accuracy is greater than 1000 meters (or ~3/4 mile). No cached GPS data is available.

Timestamp of cached GPS  is the yesterday with accuracy of 1000 meters, and cached network data is from today with an accuracy of 1780 meters.

Timestamp of cached GPS is from yesterday and the accuracy was 250 meters. Cached network data is not available.

When you answered those scenarios did you take into account any behavior patterns? How would your answers differ if you were aiming for business travelers versus aiming for local consumers that frequently stay within a 50 mile radius?

Know Your Users Behavior Patterns. The bottom line is people move around a lot. You’ll need to be very aware of the persona that you are targeting with your app and understand their general behavior and geographic movement patterns that answer questions such as:

How often do they access the map from a different location: once a day, several times a day, once a month?

How far do they travel per each trip: getting groceries (1 – 3 miles?), going to work (5 – 20 miles), visiting client sites (20 – 100 miles?), etc.?

Are their trips always within a dense city limits? City center users may encounter many more stop lights and traffic jams in town but drive shorter distances. Urban users who are out in the suburbs might travel longer distances.

Do they travel or live near many canyons, mountains, tunnels or large buildings that might affect an accurate signal?

What country do they live in? Not all countries offer network provider services.

Are the use cases so varied that you simply can’t predict the behavior patterns? If this is the case then you may have to launch the app and build in ways to gather statistics so you can start to analyse the behavior.

As you can see, someone’s geographic behavior of a period of time can significantly affect the model you are using and force you to look at cached location data in new and different ways.

Wrap Up

That’s it for Part 1 of this series. We’ve looked at six different ways that Android can provide location information, and examined different scenarios on how you can use that information. We also briefly skimmed the surface on how geographic behaviors can affect what you do with cached location results. You’ve seen that cached results can be misleading and your users may have to wait until the phone can provide more accurate information. I hope you find this information useful. Stay tuned for Part 2 which will talk about different patterns for retrieving real-time data, and how to start applying use cases to validate your results.