Top 10 Android Developer Take Aways from Google I/O 2012
The Android operating system took center stage at Google I/O 2012 that wrapped up at the end of June. The first keynote was Android-centric and there were almost always two concurrent Android sessions offered during all three days of the conference. Here are the most important Android developer themes that we picked up at Google I/O 2012.
Android Development Take Away #1: Design Quality, Great Looking Apps
A consistent theme throughout the conference was to create great looking apps. This includes how they look on all devices, how they behave and how they perform. Great looking apps with consistent behavior and exceptional performance are good for the developer, the user, and the platform as a whole. On the last day of the conference, a room was dedicated to design-related topics. The sessions ranged from basic design guidelines and making the most of the Android Design site to specific application design case studies.
Android Development Take Away #2: Follow the Recommendations on the Android Design Site
The Android Design site (http://developer.android.com/design/index.html) was referenced at many talks. Google is serious about getting all developers to read the Android Design guidelines. They want everyone to know the information and to follow the guidelines closely. This doesn't mean that all apps should look the same. It does mean that apps that strictly follow the design guidelines so the app works in a way that Android users expect. If your app doesn't follow the guides then users may get confused, use it improperly or, worse, uninstall it and give it a bad rating.
Android Development Take Away #3: Use the Action Bar, Drop the Dashboard
A couple of years ago at Google I/O, some design patterns were presented. Among those were the notion of an Action Bar (a bar at the top of the screen with a contextual title and common actions) as well as a Dashboard (essentially an icon driven main menu screen). The Action Bar design is being pushed as something that all apps should have now. With backward-compatible framework support libraries and pointers on how to create a compatible Action Bar, there is little reason for developers not to use them in just about all apps. Although, not everyone we talked to likes Action Bars, using them is another case of platform consistency that makes using your app more familiar to users.
Android Development Take Away #4: Android Isn't Just For Smartphones
This may seem obvious to many, given the popularity of tablets, but Android is more than a smartphone platform. For that matter, Android extends far beyond tablets too. Android-powered Google TV devices have different inputs, different sensors and different hardware profiles; they also come with a different user base. At Google I/O this year, Google introduced a new Nexus device called the Nexus Q. It runs Android. It has a built-in speaker amplifier. In theory, a user can plug in their speakers and use the device. What's missing? Any sort of interface -- there is no screen, no keyboard, mouse, or stylus. Instead, it's controlled from other Android devices. To drive the point home Google gave all of the attendees got one of these new devices. //Did you get a Nexus Q? If so we need to disclose that here or at the end of the story.
Android Development Take Away #5: Make Apps Great No Matter What Device They Run On
Following up with the message that Android goes beyond phones is the design message to create applications that perform well across all of these devices. That is, don't just create an app that can run on one device. Create an app that uses the special features of each class of device. This ranges from using cameras or sensors that exist on some devices, but not all, to the more complex design decisions, such as using a special authentication device (e.g. fingerprint reader) or input device (e.g. analog inputs for a game, stylus input). In some cases, it makes sense to code a separate version of the app if the customization for some devices would complicate the app source code. Also consider software differences such as device-specific manufacturer skins and leverage add-on SDK features.