Click here to Skip to main content
Click here to Skip to main content

Tagged as

Go to top

Guideline for your first (Android) mobile application

, 10 May 2010
Rate this:
Please Sign up or sign in to vote.
I've had multiple requests on information about developing an (Android) mobile application so I decided to add my tips in this guideline. Please mind that these tips are general and may not apply to all situations.

I've had multiple requests on information about developing an (Android) mobile application so I decided to add my tips in this guideline.
Please mind that these tips are general and may not apply to all situations.

  1. Do create an architecture as you were designing for the desktop applications (before you jump through the ceiling, read #2)

    Use MVC, MVP, IoC, inheritance, composition, frameworks, third party tools, etc.
    You need to keep the code clean and extensible. Forget about performance issues. Chances are, by the time you finish your application, the hardware capabilities of the devices will double. You will need to easily maintain your code more than handle performance issues.

  2. Do bend/break the rules

    It's the opposite of #1. You need to make a choice between performance and code architecture. Try to isolate the modules that break the good architecture code. Do everything you need to get the best performance and usability, but, in the mean time, try to stick to rule #1.

  3. Speed up your application

    The Internet connection can be pretty slow. Cache your downloaded data for the next session.
    Create thumbnails for pictures.
    Use place holders in list items and load pictures on demand - when the list items are visible.
    Connect the lists directly to the data source. If you can't, then create lightweight objects for your list items.
    Store the history of the user activity - last internet searches, pictures, etc.
    Use StringBuffer. Use SpannableString.
    If you get a lot of configuration from an XML file on start up, consider serializing the information so that on the next start up, you don't parse the XML but rather deserialize objects.
    Use lazy loading as much as possible.
    Profile your application. It will give you an inside view of how Android works and will provide you most valuable information on where the bottlenecks reside. Prepare for surprises.

  4. Handle exceptions gracefully

    Consider using fall back, fail safe, fail recovery techniques.
    What we certainly do not want is for the application to crash or to show 'weird' exception messages to the user.

  5. Log and send exceptions

    Log exceptions and trace your application extensively but not to the point where it interferes with performance or usability.
    Add a button to easily send the logs to the developer.

  6. Test your application

    Design your application to be testable. Use TDD if possible or post coding testing. Make a test for each bug you fix.
    Test on as many real devices as possible - device fragmentation is a real problem.
    Use different configurations for the emulator - network speed, resolution, density, etc.

  7. Security and privacy

    Require as few permissions as possible. If your application is a book reader, do not ask permissions for reading the contacts. People are paranoid about their privacy - and they should be.
    Do not cache sensitive data, track users, modify or transfer user data without letting the user know and agree to the policy - you may get sued otherwise.
    Use encryption for sensitive data.

  8. Prepare your mindset for mobile usability

    Do not try to get the same look and feel for your desktop application as for your mobile one - i.e., do not clone.
    Learn from the GUI of other mobile applications. Look at what is already available on the market. Steal (in the artistic meaning, not as copyright infringement) the ideas of the interfaces, customize them, make them better.

  9. Be consistent with the GUI

    Try to use the phone native controls. Chances are you will not have enough time to make better controls anyway. Use the built-in styles - the user can change themes and if you hardcode your styles your GUI may become unreadable.
    Do not use other phones' look and feel - like putting the LWUIT or Nokia look and feel on the Android. The majority of users know how to use an Android phone, but they will most likely get confused when presented with a new interface.

  10. Polish your application

    Make your application look great. Use nice icons. Make it user friendly. Make it fast.
    People are more likely to adhere to a 'shiny' application, even if there exists a similar one, that can do the same thing even better and faster, but which looks a little bit 'shabbier'.

  11. Make your application usable out of the box

    Assume reasonable defaults for the user settings. The user should not have to configure the application before using it.
    Consider making a dialog on first run of the application where the user can choose the language or other such important settings.

  12. Make your application aware of location

    Try to make your application look and feel aware of location: language, number decimal separators, default currency, etc.

  13. Publish your application only after it passes the 'maturity' test

    Users are very annoyed with beta versions. They will easily rate your application down. Only publish after you have fully tested and polished you applications. Use your friends as beta testers.
    NB mature means, in this context, the application that has passed the quality tests. It does not imply that it is the final version to be released, but rather a version that is good enough to be released.

  14. Add features in stages

    Publish the first version of your 'mature' application containing only the bear essential features. You will add extra features regularly, based on user feedback.
    Do not try to add too many features at once and miss deadlines or delay releases. Your users may get very impatient and upset.
    Remember the 80/20 rule.

  15. Respect your users

    They can be your best friends or your worst enemies. Listen to their requests. Answer their mails as soon as possible. In case of irritated users, you have to be the humble one. Learn patience. Learn to settle a debate before getting into a fight.
    If you meet special people that help you with your application then make sure to give them credit - maybe a thanks in the application About box or on the application website.

  16. Expect bad ratings

    You will probably get down-ratings, especially right after publishing your application for the first time. That's ok. It is normal. It happened to all of us. We improved our application and then we upped our rating back. Also see #15.

  17. Advertise/Market

    Tell people about your application. Search for people that would use your niche application. Post on niche forums and groups. Put your application up for reviews - there are specialized sites that do Android software reviews. Don't spam.

  18. Make a website for your application

    Make a web page for your application - add Description, Installation, Support and Troubleshooting sections.
    Don't be surprised that the majority of your users will actually not read your website. But for those who do, it will mean a sign of respect and professionalism.

  19. Subscribe to Android groups, forums and magazines

    Become part of the community. Learn from other peoples' mistakes. Help others.
    Learn what new features the new Android versions bring. Learn about the newest Android software. Learn what the market offers and needs.
    Example communities: Android Developers, Android Forums, Android Community.

  20. Publish your application on multiple markets

    Although publishing on multiple markets will make your releases more tiresome since you have to maintain multiple markets, you still need to do this because many users prefer other markets than the Google Android Market.
    Example markets: Android Market, AndAppStore, SlideME, AppsLib.

EDIT: If you are an Android programmer, you must check this link out


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Adrian Vintu

Austria Austria
Adrian is an old timer who has had the wonderful experience of working in a variety of quality environments and with various quality people.
Throughout time he has got down with Assembler, C++, Borland Delphi, Java, C#, Android etc.
He took part in projects concerning software security, industrial controllers, health-food and health-care ERPS, AI simulations, data mining and mobile development.
Adrian is always interested in the big picture of the things and wishes to become a great architect one day.
Adrian maintains a blog here[^] and is trying to make it as nice and helpful and user friendly as possible.

You may also be interested in...

Comments and Discussions

GeneralMy vote of 1 PinmvpMark Nischalke17-Apr-11 12:09 
GeneralRe: My vote of 1 PinsubeditorIndivara18-Apr-11 2:36 
GeneralRe: My vote of 1 PinmemberAdrian Vintu18-Apr-11 2:40 
GeneralMy vote of 5 PinmemberRejang Lintang21-Nov-10 17:13 
GeneralMy vote of 5 Pinmemberoren.bengigi@gmail.com14-Sep-10 9:48 
GeneralMy vote of 4 PinmemberJoeSox31-Aug-10 8:54 
GeneralMy vote of 3 Pinmembersurbhiagreeya21-Aug-10 21:11 
GeneralRe: My vote of 3 PinsubeditorIndivara18-Apr-11 11:55 
GeneralNice article PinmemberHimanshuJoshi20-Aug-10 10:43 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web04 | 2.8.140926.1 | Last Updated 10 May 2010
Article Copyright 2010 by Adrian Vintu
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid