Our Top Android Development Tips

Android offers many exciting possibilities. We at Visual Design round up 10 important tips that will help you make the most of your development time

A smartphone war is flaming, pitched as a neck and neck fight for market share; but I see it in another way. Android is an open base, iphone is a wonderful product, everything else is decor. Android is most interesting in its incarnations outside of what is likely in mobile, desktop and tablets. I foresee it in thousands of upcoming weird and wonderful products but in any case you’d best think smartphone use isn’t going to slow down any time soon. Tinkering with Android technology these days guarantees many exciting future possibilities.

Android makes it really easy to get started. The full contents of the Android source code are obtainable online, with extensive documentation and an keen and helpful community. A variety of demos and tools for IDEs will ease an normally steep learning curve. And here we’re going to boost it even further with 10 tips to make the most of your development time.

1. Reserve your name space

The Google Android Market uses the package name that you assert in your manifest to distinctly identify you between the 1000’s of other apps on the market. If you know ahead that you’ll be releasing a specific application, it’s a good idea to get in there first and make sure you can hold your place!

2. Listen to your users

I can’t emphasise this enough! Lately we were doing work for a client who believed that their application required feature X and that the omission of feature X was the reason for a lot of the poor complaints he was viewing on the Android Market comments. Rather of implementing the wrong thing, we examined the comments and suggestions on the Android Market ourselves and put together a list of feature requests, along with a number correlating with their requested volume. Lo and behold feature X was actually at the bottom of the collection!

Your own preconceptions and choices can shutter you to what the majority of people really care about. Pull together as much feedback as you can about your app and more significantly, be sure to act on it.

The love/hate relationship of feedback

3. Use Android’s platform patterns

We all would like our applications to be distinctive but there’s a expression that “To break the rules you first must know the rules”. Presently there are a lot of apps out there and we want them to play well collectively, so prior to you start cutting out your distinctive niche in the Android Market, think about first attempting to fit into the method people are already using Android apps. If you link yourself into their present habits you’ll already have an keen well informed bunch of users!

Take into account how you can motivate people to share information into and out of your app. The most widespread way to share functionality is via platform intents. Uncovering intents to your app is greatly advised and there are many intents from which your app may benefit, and documented in the official Google developer reference material and even more agreed upon at open intents. Probably the most popular of all is the generic Intent. ACTION_SEND option. Declare that you offer an ACTION_SEND option within your manifest and see users flock to your app through their normal message and picture sharing app.

Once you have shared functionality, think about offering the expected basics in how your application’s functionality is presented in its UI before using any brave new guidelines. Dashboards, action bars, search bars, quick actions and widgets are all desired when you install an Android application and if you aren’t providing this, users are instantly compelled to begin understanding something fresh before they start just using your app for what it best offers. Contemplate using a framework such as GreenDroid to get a headstart on the typical elements of your UI.

4. Use Hiearchy Viewer while creating views

/tools/hierarchyviewer

/tools/hierarchyviewer

The View Hierarchy gives you a approach to examine activity UIs and can assist you visualise complex designs. This is my preferred Android tool but for security reasons is only offered on devices flashed with a developer version of the Android Platform. So if you would like to take advantages of this tool (you do), you’ll either need a phone with an Android OS development version or the emulator.

On the other hand, you can include Romain Guy’s ViewServer Class into your app to allow the same views on any retail mobile. When presented with a styling issue, large or small, I encourage all developers to swiftly turn to the Hierarchy Viewer. I’ve lost count of how many occasions during styling I developed additional styling under flawed presumptions. Later on I’d open the Hierarchy Viewer and in light of the actual view model in memory I’d make a successful change immediately.

It has two contexts; HierarchyView & Pixel Perfect. HierarchyView is wherever the majority of interest lies. When revisting places for UI polish, Pixel Perfect helps get in on the fine positioning details of images and ensure they are rendering properly on all densities.

The Hierarchy View will help you across the full development cycle of your Layouts and styling development.

To start with, you’re introduced with a list of elements, both system and your own activities currently sitting on the Dalvik stack. By choosing any of these you can view its associated tree view layout.

TreeView and Properties navigation

Drill down into a view’s associated details through the collapsible properties area and highlighted nodes can be filtered by entering an id or class name.

Capture PNG/PSD

Numerous useful details can be exported to assist when you’re debugging and compiling your app mockup models. You can save a screenshot object model of the current view hierarchy tree or even export the current state as a collection of layers accessible to switch on and off, move about as layers in a PSD for use in Adobe Photoshop.

View Optimisation

Render times and performance indicators for each item are additionally accessible as shaded dots on every view. Each gives a high-level concept of view creation bottlenecks. Left to right, dots signify measuring, layout, and then draw time of a respected view in contrast to the rest of the nodes in the tree.

In comparing to the other items in the tree, a green dot is allocated to views 50 per cent faster, a yellow dot for items 50 per cent slower and a red dot for the overall slowest rendering.

HierarchyViewer lets you delve deeper into your Android UIs

5. Optimise your XML layouts with layoutopt

/tools/ layoutopt

/tools/ layoutopt

Working layoutOpt against your XML layouts helps distinguish redundant views that might perhaps be taken out. It also indicates areas exactly where more effective platform features could be applied to be able to have much less views rendered to the UI at run time. A frequent recommendation is the use of relative elements such as android: layoutToRightOf=”id” and android: layoutToRightOf=”id”. These android attributes can be allocated to items in a relative layout instead of overly nesting views, whose only objective is to contain other attributes.

Using the tool against a valid XML will result in a short outline of the issue along with any suggested solution and the line number of where to find it.

6. Use themes

Themes help you handle styles across an entire application. Looking for reference in how to best apply your themes to your app will not yield many results, yet this is still some thing I recommend in managing an application of any scale. Designing your app with rigid styling early on in the development of your application will make it less difficult to deal with unusual device behaviour later on when you are creating your app for the best presentation on several sizes and resolutions of displays.

In your Android Manifest:

Then in your res/values/styles.xml:

<!--?xml version="1.0" encoding="utf-8"?-->

<!--?xml version="1.0" encoding="utf-8"?-->

You can now override all your own themed widget items! Here is an example of overriding a button with your own declared style of ‘Widget.Button’.

@style/Widget.Button

@style/Widget.Button

7. Add layout defaults to your theme

Each and every layout item in views is going to need a expressed height and width. As a whole this adds up to a lot of extra work in your XML layouts and styles. As an alternative, fallback on the smart default of always wrapping your layouts. This way, except if you declare otherwise in your styles, you can assume your views to wrap their content and you can conserve space on all those obsolete width/height declarations.

Simply add the following within your theme:

8. Extend sensible parents in your styles

Styles are designed to cut down on redundancy and so i like to push this as far as possible. The prior tip spoke about the redundancy of width/height combos. In order to take this even more each time, you really need to apply a style: why not start from one of a set of smart defaults? Here’s a selection from some of my most-used smart default styles:

9. Offer translations but start simple

Google’s Android Market (Google Play) is a global marketplace. After all your effort getting an app into the wild, you would like as many users downloading your application as possible! Get a head start in dipping into a greater target audience by simply offering a translated title and description for your app in the Android Market. Grow from this userbase to slowly offer localised text for specific regions that seem to be interested in your application. You can view the downloads pertaining to specific regions in the Android Market.

10. Standardise your naming convention

Within the res/values/directory you’ll see many attributes, but don’t to get caught up in creativeness with your naming. Identify some practical guidelines and then stick to them. In doing this, later on down the line during an important bug fix, your development partner or colleague will be able to find items unassisted.

It’s up to you how specific you’d like your resources to be targeted

For example, I prefix icons with ‘ic_‘ activity layouts with ‘act_’. I also prefix the ids of each layouts view items with distinctive identifiers so you can naturally point out to the user where this item is being used. When styling an item, if the item is unique then I’ll also tend to use the exact same name for an item’s style, dimensions, color & strings.