>Android Programming GuideFebruary 11, 2011 at 11:56 pm | Posted in Article, computer and high technology | Leave a comment
>With thousands of new Android Programming applications being published in Android Market every week, its becoming more and more important to proactively work at breaking through the clutter (hooray for marketing jargon!). One way of improving your apps visibility in the ecosystem is by deploying well-targeted mobile advertising campaigns and cross-app promotions. However, theres another time-tested method of fueling the impression-install-ranking cycle: improve the product!
A better Android Application can go a very long way: a higher quality app will translate to higher user ratings, generally better rankings, more downloads, and higher retention (longer install periods). High-quality apps also have a much higher likelihood of getting some unanticipated positive publicity such as being featured in Android Market or social media buzz.
The upside to having a higher-quality app is obvious. However, its not always clear how to write a so called better app. The path to improving app quality isnt always well-lit. The term quality, and its close cousins polish and fit and finish arent always well-defined. In this post, well begin to light the path by looking at a couple of key factors in app quality, and furthermore, look at ways of improving your app along these dimensions
Having the right set of features in your app is important. Its often easy to fall into the trap of feature-creep, building as much functionality into your app as possible. Providing instant gratification by immediately showing the most important or relevant information is crucial on mobile devices. Providing too much information can be as frustrating (or even more so) than not providing enough of it.
And again, listen to your users by collecting and responding to feature requests. Be careful, though, to take feature requests with grains of salt. Requests can be very useful for Android Programmers and Android developers in aggregate, to get a sense of what kinds of functionality you should be working on, but not every feature request needs to be implemented.