OSCON 2013 – Presentation on Android SDK Geolocation

If you are headed to OSCON, swing by my session on Mastering Android Geolocation. It’s a deep dive into the Android SDKs android.location package. If you’ve ever wanted to learn about the fundamental’s of the SDKs Geolocation capabilities then this is a must attend session. It will also give you a strong foundation to understand the underlying capabilities of the new Google Play Services SDK that includes Fused Location, Activity Recognition, and Geofencing APIs.

The presentation includes digging into the capabilities of my open source GPS Testing tool that lets you easily test different aspects of the Geolocation capabilities.

Here’s the details and I hope to see you there:

 Location, Location, Location: Mastering Android Geolocation
07/25/2013  5:00pm –  5:40pm PDT (40 minutes)
Room: Portland 251 (capacity: 200)
https://www.oscon.com/oscon2013/public/schedule/detail/28713

Smartphones aren’t getting any smarter

As an Android and mobile web developer, I feel compelled asking people I know or meet a lot of questions about their phones. One trend I’ve been seeing is feedback that smartphones, themselves, aren’t really getting any smarter. The ironman/crossfit marathon to add new features at warp speed has left behind a trail of cool phones that have some fundamental issues. So, I’m going to take a look at some of these here.

To put things in perspective, at Google I/O 2013, Sundar Pichai announced that there have now been 900 million Android activations world-wide to date. That’s not including iPhone activations, of course. But, Yeow, that’s a lot of phones! So, let’s look at some things that haven’t improved much. It’s almost like Newton’s Third Law of Motion can be applied to smartphones: while some things improve, other things must take a back seat.

Security. I can say this with certainty – I have yet to see or hear about a smartphone advertisement that says something such as “we’re striving to make this phone the most secure phone yet.” One thing is clear that Apple’s app vetting process helps reduce the level of malware compared to Google Play. Sure I understand that nothing is 100% secure, but the operating system vendors and the handset vendors could at least talk about it.  And, why don’t smartphones come with built-in, optimized versions of virus checkers and anti-malware tools like Windows PCs and laptops?

Most people’s lives could be seriously disrupted by the data stored on your typical smartphone, and we lose these and leave them behind accidentally by the thousands, and we inadvertently install malware.

Case in point – do a search on Google or bing using the term “smartphone security”, and see how many articles are published by the major phone vendors about security and securing your phone. The top result is by the FCC about their Smartphone Security Checker.

Restoring an Android phone. If you reset your droid or buy a new one, restoring everything back to the way it was and in it’s exact place, well…a very manual process. This is not very user friendly. Hey Android vendors, you should take a lesson from Apple on this one.

Display brightness and energy consumption. Phone displays appear to continue to be the “number one” draw on battery life. I’ve started to think most (many?) like their screens really bright. I mean realllly bright. It’s funny, I keep mine pretty dim to squeeze as much life out of the battery as possible, and I’ve lost count of the number of times people have said something like “how can even you see what you are doing??”

GPS energy consumption. My Garmin GPS lasts over 17 hours of continuous usage with two AA batteries. The battery on a typical smartphone has much greater storage capacity, but in actual field tests I’ve killed smartphone batteries in as little as 4 -5 hours of continuous GPS usage. GPS used wrong is a huge draw on the devices battery. Sure, a smartphone is doing a lot more work than a typical, single purpose GPS. But, my point is why hasn’t GPS battery consumption improved over five generations of smartphones? Those of us who build GPS-based native and web apps have to jump through hoops to optimize battery life in applications that do more than take a snapshot of the users current location. Some of the algorithms we write should simply be built-in to the firmware.

Charging times. Now I admit this varies from phone-to-phone but it’s still not very fast in general. I know I have said before that many people are never more than 10 feet from a charger, but for those of us who aren’t that attentive to charging I can say charging times can be an issue. For example, my iPad (okay it’s more of a tablet than a smartphone) is the slowest charging device on the planet compared to my original Google Ion which charged from dead to full in about an hour and a half. Sure, I understand there is a huge difference in battery size, but my point still stands. The cute, itty-bitty charger for iPad is way under-powered for the needs of charging a larger battery.  And, maybe some people are okay with that?

Planned Obsolescence.  This one is totally on Android. I’ve lost track of the number of Android phones that I have sitting around that have been rendered obsolete because the handset manufacturer provided one or maybe even two OS updates to the phone, and then they stopped. They become obsolete in the sense that some apps don’t run on older versions of the operating system. Sure, the upgrades are enticing (better camera, more memory, faster processors, etc. etc.) but what if someone doesn’t want or need to upgrade?

This may become more of an issue for people as some carriers are stopping their subsidies of phones and pushing users to carry the cost of a new phone directly. And new phones can give you sticker shock. If you have to pony up $350 – $600 for that new phone and all it’s advertised features, you might not be inclined to upgrade phones as often as you used to.

Wrap-up. So, I’ve written a mish-mash of different things that should be improved for both Android and iPhone. What I’d really like to see, and it probably won’t happen, is for Android, Apple and Microsoft to take a step back from the feature/functionality marathon and work on some fundamental issues to build an even stronger foundation for the next generation phones.

 

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