Android App Surgery: "MySettings"

This post is the first of what will (hopefully) become a regular series of Android App Surgeries. You can vote for which app I should review next, or nominate your own app for review on the Android App Surgery Moderator page.

As an Android Developer Advocate at Google I work with developers, helping them get the most out of Android so they can provide their users with the best experience. An important part of that is using apps,  figuring out what they do well, what they could do better, and what could really make them sparkle.

A lot of apps make similar mistakes (and leave out the same functionality). Last Wednesday I wondered aloud on Twitter if sharing my opinion with a wider group might be useful. The response led me to create this moderator page for people to nominate their apps for me to review publicly.

The goal is to highlight Android best practices for you guys to use in your own apps -- more of a code review than a book review (though without seeing any code). I won't be giving ratings out of 5, describing the app in detail, and telling you why you should (or shouldn't) install it. I will be sharing my opinion on how the User Experience (UX) could be improved, which additional Android features could be added, and how stability / performance / battery life could by optimized.

It should go without saying that while I'm a Google employee, the opinions and suggestions made on this site are my own, and don't necessarily reflect the opinion of my employer. Also, they're my opinions - I'd love to see if other Android users agree with my thoughts.

The App: MySettings from JQ Soft

MySettings is a relatively simple app that displays a single screen of shortcuts to some of the most commonly used system settings and toggles.

I’m actually really glad this was one of the most popular nominations last week because it lets me talk about some common UX stuff that I'd like to cover.


User Experience

The overall UX is pretty good - the layout is simple and intuitive, it looks good and works well in both landscape and portrait orientations on both HVGA and WVGA devices. In particular I liked that it featured:

• optimized layouts for landscape and portrait views (how-to).
• screen size and resolution independence with optimized high-res assets (how-to).
• support for trackball navigation (hopefully using StateListDrawables).
• A PreferenceScreen to implement "standard" application preference screens.

Like a lot of apps they've implemented some custom UI behaviour.

One of the beauties of Android is the freedom to do whatever you like when it comes to UX, but with freedom comes risks.

• The app is presented in a partially transparent floating window. That's pretty unusual and I found it a little off-putting. I've seen this before, but more commonly only when the app is launched from a widget.
• The custom menu. Pressing the menu button brings up a menu, but rather than the standard menu mechanism they've implemented a totally custom UI. This introduces some potential UX issues:
• It's unexpected and unfamiliar. I know what to expect when I hit menu, a custom menu makes me stop and think about what I'm looking at and how to use it.
• It doesn't include the text labels I'm expecting, and it doesn't use the standard icons I'm expecting (particularly for accessing settings).
• It doesn't support trackball navigation.
• The regular menu is modal, this one isn't.
• The menu has an "Exit" Button. Thanks to the Android application lifecycle there's no need for it - pressing "Back" will exit the app just as effectively.
• The "About" dialogue doesn't derive from Dialog and pressing back exits the app rather than closing the dialogue. An alternative is to use the AlertDialog and completely replace its UI. It's also good practice to let the Activity handle the Dialog lifecycle.
• The standard behavior for a long-press on Android is to display a ContextMenu. In this app a long-press performs an alternative action (opening a contextual settings screen). While useful,  overloading an existing UI metaphor is risky.
• Enabling or disabling WiFi and Bluetooth doesn't provide any feedback on what's happening. They could use Toasts to provide updates. The system broadcasts Intents that announce changes to both WiFi and Bluetooth device state.

Android Features

I thought the (optional) ongoing notification as a shortcut to the app was clever, and I loved their use of Intents to open specific system preference screens.

What might be nice additions are a Live Wallpaper and a some Widgets.

A Live Wallpaper is fully dynamic and interactive, so you could implement the entire UI as one, though with homescreen real-estate being crowded as it is, a widget might be better.

I'd love to see them include a widget that looks just like one of the settings buttons. It could use a configuration Activity that lets users select which of the settings buttons they'd like it to represent. Then you could add multiple, different, settings shortcut buttons to the homescreen.

Stability / Performance / Risks

The app stability is great (I got no crashes) and it's nice to see that no unnecessary Services are being created.

One thing that worried me a little is that the app is directly toggling some system settings. Earlier releases have moved some of these toggles (notably GPS) into the read-only secure settings table. It might be worth confirming the settings are directly modifiable, then falling back to open the right page in the System Settings if they aren't.

Hopefully you guys found that useful

Later this week I'm going to take a look at AndCam3D. If you'd like to see your app reviewed, you can self-nominate at the moderator site. You can also go there to vote for which app you'd like to see reviewed.

If I get enough interest, and have the time, I'll try and do these on a semi-regular basis.

Tracking the London Marathon

One of the fun things about being a Googler are the opportunities that come along to work on unofficial ad-hoc projects using a bunch of different Google technologies. It’s even better when you get to do it while helping charity. I got the chance to do just that in the lead-up to the 2010 London Marathon.

About a month ago Phong Luu, Jean-Laurent Wotton and I offered to help Stephen Woodford raise some money for NABS. Stephen volunteered to run the marathon, we pitched in by building an application to let people follow his progress.

Why Build New?

Existing tools such as Latitude and MyTracks didn't offer the real-time, high frequency live updates needed to allow anonymous visitors to track a marathon in real time. The goal was to create a simple web app using Street View and Maps that didn't require a login that got updated as Stephen was running.

What We Used

1. AppEngine was used to create a server to receive position updates during the race.
2. A purpose-built Android app transmitted updates to the server at a regular interval during the race.
3. Google Maps and Street View displayed each updated position along the route.

Practical Considerations

Before Stephen took off there were a few practical considerations. In particular I needed to be wary of two things: battery life and data signal availability.

To maintain battery life we made the frequency and minimum distance of our location update requests user configurable. During testing we found that 5 minute intervals over 1km was a good compromise between real-time updates and battery life.

As any Londoner knows, a 3G data signal isn’t something you can take for granted while running (literally) around the city. To account for this I created an upload Service. Each new location was recorded into a Content Provider along with a timestamp. Using a combination of Alarms and Broadcast Receivers, I could then start the update Service at semi-regular intervals - or when a data connection was available - and upload all the pending updates to the server.

The Future

With the 2010 race now over, the team is looking for ways to improve our custom solution to offer a generic tool for future marathons. To do that we'll need to:

• Update the Android app and AppEngine server to support tracking multiple runners simultaneously and in different races.
• Add compass direction so that Street View shows the direction the runner is facing.

Spring! (or the Return of the Awesome Sunset)

I do love me some Spring, and this Spring I get to enjoy sunsets like these from the comfort of my living room.

Which is the perfect way to end a day spent wandering around the gardens of Cannizaro Park and Wimbledon Common.

Oh, and because it's Spring, Vodafone UK have started selling the Nexus One. Did I mention how much I enjoy Spring?

The Return of the Animal Translator

Earlier this year I was lucky enough to be a part of Google London's "Translate for Animals" April Fool's joke. 

To avoid confusion it got taken down shortly after April Fool's, but in the short time it was live it had tens of thousands of downloads and over 1,000 comments (averaging 5 stars!).

I've gotten some requests for the app to be made available for people to cruelly torment their kids drunk friends, so I've put the app back on the Market as "Animal Translator". Enjoy!

Content Provider Iterator (or Things That Make Me Nervous)

Yesterday Tim Bray, Google's newest Android Developer Advocate, shared his Content Provider Iterator. Before he shared it with you, he showed it to me to check "is this sick and twisted?". Here (with some additional colour) is what I told him.

Let me start with an admission. I have a deep mistrust of metaprogramming tricks in statically-typed systems. I've spent far too much of my working life unpicking frameworks created to simplify complex parts of existing frameworks. Often as not, the class descriptions could be summed up as "I don't understand this way of doing things -- this class makes this framework behave the way I expect."

There's often a good reason the original framework works the way it does. In Android that reason is performance. When developing for servers and PCs simplicity and familiarity is often a good trade-off for a marginal performance hit. In mobile it isn’t.

That said, these sorts of helper classes can improve code readability and cement best practices so I owe it to Tim to justify my unease.

The Problem

First off, let’s look at what we’re trying to solve -- iterating over a Cursor.

Tim’s code lets us do this:

Reader calls = new Reader(Call.class, activity, CallLog.Calls.CONTENT_URI);
for (Call call : calls)
  String number = call.getnumber();

The alternative in “normal” Android is this:

Cursor cursor =   
  getContentResolver().query(CallLog.Calls.CONTENT_URI,
                             null, null, null, null);
while (cursor.moveToNext())
  String number = 
   cursor.getString(cursor.getColumnIndex(CallLog.Calls.NUMBER));
cursor.close();

Certainly Tim’s solution is more familiar to those of us who prefer working with Objects to Cursors, and we save a line of code, but what’s the cost?

A Solution?

The two golden rules when designing for performance in Android are:

• Don't do work that you don't need to do
• Don't allocate memory if you can avoid it

 This pattern looks expensive.

1) Avoid creating objects

Allocating memory (and performing garbage collection in a resource constrained environment is expensive. Every time you extract information from a Cursor Using this class, you're creating a new object for each row, and allocating memory to store every column value too.

2) Avoid Reflection

Wow, that’s a lot of reflection. Reflection is expensive.

For every iteration you’re using reflection to create a new instance of your row object. During the construction of every object you use reflection to find a Setter for each column, then again to invoke the Setter for each column.

That’s a lot of reflection and it won’t take long to feel that hit on your performance.

3) Avoid Method Calls

Method calls are (comparatively) expensive - enough so that it's generally considered good practice in Android to avoid using Getters and Setters within a class. After creating objects you need virtual method calls to allocate each of the row values used, and again to extract them.

4) Minimize frequency of object creation

What's neat about this solution is it's dynamicsm, it creates your new objects each time you to iterate over the list without needing to maintain a separate collection.

But there is a risk here. Because it's dynamic, the generic solution doesn't offer a solution for monitoring changes to objects or the addition or removal of rows. To handle this you'd re-iterate over the list whenever the underlying dataset changes - reinforcing the performance issues described above.

5) Static state and thread safety

As written, this code isn’t thread safe, and maintains the current position of the cursor as a state variable. Using the same Reader to iterate over a cursor in two threads will come to grief very quickly indeed!

Conclusion

The Call Log has a half dozen columns and maybe a hundred rows, so you might get away with this. But what happens when you do it over contacts? Or email? Or Ocado’s entire grocery catalogue? It’s a dangerous pattern because its performance cost is dependent entirely on the shape of your dataset.

Imagine the case for a retailer with a database of several thousand products, each with a dozen String-based columns. Say 2,000 products with 12 string rows. That’s using reflection over 50,000 times and creating nearing 30,000 objects. That’s an awful lot of reflection and object creation to save a line of code.

Different platforms require different thinking. In my experience, becoming comfortable with how these systems are designed to be used is vital to understanding the best ways of implementing solutions. To quote an Android engineer on the subject, “I understand that coming from Ruby, one would want objects generated for you, but there is such a huge performance cost on mobile devices that it simply doesn't work.”

Android on the Farm

Those of you who follow me on Twitter may have noticed an unusual drop in my posting frequency over the last few weeks. I can't divulge details, but my inactivity is a result of having been head-down finishing an exciting new Android project that I've been lucky enough to be involved in with the mobile engineering team here in London.

Between the developer lab world tour and finishing Professional Android 2, I haven't had the chance to focus solely on building an Android app for far too long. It's been great to work as part of the Google team to put together something which (I think) is pretty incredible.

We've spent the last couple of days doing final testing in the English countryside. With that now completed, and the launch imminent, I'm going to stay a few days longer and take a well earned break. All will soon be revealed, but while you wait for the app to be available in the Market I thought you might enjoy some video clips I took during the development and testing process.

(Feel free to guess what you think is going on, but please don't ask me to comment on or confirm speculation. Posting these clips is as far as I'm willing to go!)

Professional Android 2 Application Development: This Time It's Personal

Professional Android 2 Application Development, started shipping today (Monday) from Amazon US - so those of you who pre-ordered should be seeing your copies in a couple of days. I'm really excited and can’t wait to find out what people think.

A lot has happened in the year since Professional Android was released. In November of 2008 version 1.0 of the Android SDK had only just been released. There was one handset (the G1) on one carrier (T-Mobile) in one country (the US).

What's new?

As Professional Android 2 rolls off the presses there have been 6 new platform releases (up to Android 2.1), and Android is now available on 26 handsets in 48 countries on 58 carriers.

Understandably much of the original Professional Android material is now out-of-date. Accordingly, Professional Android 2 has been totally revised and expanded to cover all the changed and new API features introduced in the past year up to and including Android 2.1.

That includes the new Bluetooth API, Widgets and Live Wallpaper, the updated contacts and Sensor APIs, the new ASyncTasks and Services framework, as well as expanded sections covering using the camera, microphone, and media framework.

In all there are an extra five chapters and over 100 more pages.

Oh, and there's a new cover image that is so awesome it's almost enough to justify replacing the older copy by itself.

Where to buy

If you're interested in a copy the best place for you to buy a paper copy of the book is from Amazon using one of these links:

• Amazon.com
• Amazon.co.uk
• Amazon.de

I'm also particularly excited to say that you can also purchase Professional Android 2 as DRM-free e-book PDF from the Wrox website:

• Adobe DRM-free E-Book

Every concept in the book is supported with code snippets and a bunch of detailed step-by-step examples -- all of which you can download from the Wrox Open Source site.

Android development conversation

I'll be looking to answer Android questions at the Wrox P2P forums, Stack Overflow, and the Android Google Groups.

For more information on Android and the book you can follow me on Twitter or Buzz. I'll tweet any 'bugs' and changes to the text or code samples, as well as updates on any SDK releases that cause book code samples to break.

The phone I have been waiting 2.5 years for, has arrived

It's here

The Nexus One, the phone I have been waiting 2.5 years for, has arrived at last.

Yesterday Google, working with its partners, made the Nexus One 'super phone' available directly from the Google web site. It comes SIM and ROM unlocked, available either stand-alone or with a contract from an expanding list of carriers (currently T Mobile US). It's a platform for mobile innovation with an emphasis on simplicity -- for consumers and developers alike.

I first ranted about the phone I really wanted in June 2007

In June of 2007, shortly after the iPhone release, I first ranted about the phone I really wanted. At the time I (like many others) termed it the gPhone - a device sold by Google, tightly integrated with the Google services that were a vital part of my life, and with a slick form factor and powerful development platform beneath it.

By October of that year Google moved most of the services that were missing into the mobile cloud before the November release of the first preview Android SDK changed the mobile world (and mine).

Full Webkit-based browsers on smartphones brought all the websites I needed direct to my phone, and Android provided an incredible platform on which to explore the development possibilities of a mobile extra-sensory device.

In September of 2008 the G1 launched in the US for $180 with contract on T-Mobile, and we finally had hardware on which to run our Android applications. By December of 2009 nearly 20 different devices were available, in 48 countries and on 59 different carriers.

Now, the Nexus One joins the Android menagerie, and a welcome addition it is.

I can tell you it's easily the nicest phone I've had the pleasure of using

Having played with this device for a while, I can tell you it's easily the nicest phone I've had the pleasure of using. The screen is ridiculously clear and bright, the form factor has just the right balance between "sleek" and "robust", and Android 2.1 includes most of the stuff I've been hoping for since 1.0.

I particularly like:

• The new Picasaweb integrated Gallery which is simply too cool to describe with mere words
• Multiple email providers (one device for work and home!)
• Multiple contact providers (work contacts, meet home contacts. And Facebook contacts)
• Live Wallpaper (because they are TOO AWESOME)

Today we have our first Google Super Phone

This direct to consumer model is going to further increase the rate of mobile innovation -- for hardware, the Android platform, and apps.

A year ago there was one Android phone and a handful of apps. Today there are 20 phones and 18,000 apps. Today we have our first Google Super Phone, tomorrow looks... exciting.

Android, European Developers and ADC 2

My new role at Google hasn't left me with much time for bogging lately, which is a shame because there's a lot going on that's worthy of note.

The good news is that blogging is now a bigger part of my job role -- albeit not on this blog.

As part of Google's developer relations team I'll be writing regularly for the EMEA Developer Blog (like last week's post calling for European entries for the second Android Developer Challenge). We aim to include plenty of content with a local flavour for developers in Europe, the Middle East and Africa. Rather than do all the work ourselves, we're also hoping to reach out to the community and get regular guest posts from EMEAs developer community. Comments are open, so let us know what you think and what you want to hear about.

While I'm here, some Android updates:

• Andy Rubin has announced around 18-20 new Android powered handsets before the end of the year.
• The HTC Hero is available for order at Orange UK.
• The Samsung Galaxy is available from Bouygues Telecom in France and O2 in Germany (as the i7500).

Android News

So it seems today is a day for Android announcements.

HTC has made the Android 1.5 (cupcake) system image available for the downloading and device flashing pleasure of ADP1 (developer phone) owners everywhere. This is an excellent opportunity to test your SDK 1.5 targeted applications on real hardware before it hits consumers, so get to it.

Speaking of consumers, O2 Germany just announced the June release of the first non-HTC device to hit the market, the Samsung I7500.

With more SDK features, more countries, more carriers, and more devices coming thick and fast, the potential audience for your kick-ass Android app is getting bigger by the second. Download the 1.5 preview SDK now and get started.

The Calls are Coming from Inside the House

By now it should be pretty clear that I'm a fan of Android. It's a platform exciting enough to have driven me from my comfortable niche writing Windows desktop software into the world of mobile application development.

Now, I'm (extremely) happy to say that Google have let me turn my part-time amateur Android developer support and evangelism into a full time role as an Android Developer Advocate. I'll be based in Google's London office helping developers in EMEA produce the sort of awesome mobile applications I've always known are possible. It's a particularly exciting time in Android with version 1.5 of the SDK (now available in preview) featuring home-screen widgets, live folders, and video recording.

So what exactly is a developer advocate?

It's an opportunity to work on the inside, helping the developer community on two fronts: first by working with development teams to improve and perfect their apps, and secondly as a conduit back to the Android development team - helping to guide future Android development in a way that makes it even easier for developers to create great apps.

What does that mean for this blog?

I'll continue to blog about my own projects, as well as taking some close looks at the Android SDK as it grows and evolves. I'll also continue to feature new Google developer products as they're released, as well as my own projects and 'how-to guides'. What you won't see here, for obvious reasons, is speculation on future Google products, Google secrets, or new product announcements. As a member of the Developer Relations team in EMEA, I'll also take on some of the responsibility for Google's UK Developers Blog, so expect to see some more Android content from me there soon.

Over the past year I've found myself using Twitter (@retomeier) when I spot cool new products, and will probably continue to do that rather than dedicate whole blog posts to track every new product announcement.

Google I/O - Should I Come?

Yes! I'm really excited about Google I/O this year. There's going to be a ridiculous amount of useful information for people doing development with Google's developer offerings. Android developers in particular won't go away disappointed. I really hope to see some of you there - particularly if your based in any of the EMEA countries - so if you come along, be sure to come over and say 'Hi!'.

Earthquake! for Android

A couple of years ago, the real-time earthquake display on display at the Natural History Museum in New York impressed me so much I stole copied created my own version of their concentric circle filled goodness.

Lately I've been focussing on mobile applications, so I figured why not move the same compelling UI to my Android handset?



Like the exhibit that inspired it, Earthquake! (Applications > News & Weather) shows not just the epicentres, but also an approximated 'damage zone' (inner circle, dark shading) and 'rumble zone' (outer circle, lighter shading) to give an impression of the areas likely to be affected by each earthquake. Zoom in to see which cities and suburbs will feel the tremor, and which are at risk for property damage.

Being a mobile app invites some personalization features not possible on a web site or museum display. Earthquake! lets you configure notification for new earthquakes that cause the phone to vibrate in proportion to the size of the detected quake. Small, magnitude 3 quakes barely shake your phone, but Big One's at 8 or 9 on the Richter scale will vibrate for up to 20 seconds.

Using My Location you can filter notifications to only alert you to earthquakes nearby, or for which you're within the expected 'rumble zone'.

So now if you've got an Android powered phone, you can have you own mobile real-time earthquake display. Then if you wake up in the deserted ruins of a post-apocalyptic nightmare you won't have to wonder whether or not the damage was caused by a magnitude nine earthquake splitting the Earth's crust in two.

The code used to create Earthquake! is a polished version of the ongoing example code shown in Professional Android Application Development, so if you like the idea pick up a copy and see how it's done.

eBooks, Kindles, and Mobiles

A couple of weeks ago Chris Webb (of publisher John Wiley & Sons) wondered if Amazon's decision to make Kindle titles available on a variety of mobile phones might be especially game changing.

Being an eBook skeptic I wasn't entirely convinced. A spirited discussion on Twitter (@retomeier / @chriswebb) followed, which eventually led to Chris putting my response up in full on his blog as 'Digital Books: Digital FAIL?'.

Professional Android Application Development: Out Now!

Professional Android Application Development ships tomorrow (Tuesday) from Amazon US, so those of you who pre-ordered should be seeing your copies in a couple of days. I'm really excited and can’t wait to find out what people think.

Where to buy

If you're interested in a copy the best place for me, for you to buy the book is Amazon following one of these links:

• Amazon.com
  
• Amazon.co.uk 

Free stuff and resources

If you'd prefer not to fork out without knowing a little more about what you're paying for (or just don't want to fork out at all), here's some useful resources that come free of charge:

Chapter 1 is available as a free PDF download [pdf] from the Wrox site if you want to learn more about Android before you commit to a 400 page tome. The TOC and index are there too. Chapter 7 [pdf ] -- which focusses on maps, location-based services, and the geocoder -- is available too.

Every concept in the book is supported with code snippets and a bunch of detailed step-by-step examples -- all of which you can download from the Wrox Open Source site.

If you're looking for details on something specific, Amazon's "Search Inside" is a surprisingly useful resource.

Android development conversation

I'll be looking to answer Android questions at the Wrox P2P forums, StackOverflow, and the Android Google Groups.

You can follow me on Twitter or FriendFeed, or just get book related news from the books Twitter feed and Friend Feed Room. I'll tweet any 'bugs' and changes to the text or code samples, as well as updates on any SDK releases that cause book code samples to break.

Still to come

To celebrate the book release I'll be posting a bunch of stuff about Android, including tutorials, walk throughs, and open source projects -- both here and other places online.

As luck would have it I got my G1 last week, so I can finally test and tweek my Android applications, so expect to see announcements about them in the coming days and weeks.