Welcome to the Java Programming Forums

The professional, friendly Java community. 21,500 members and growing!

The Java Programming Forums are a community of Java programmers from all around the World. Our members have a wide range of skills and they all have one thing in common: A passion to learn and code Java. We invite beginner Java programmers right through to Java professionals to post here and share your knowledge. Become a part of the community, help others, expand your knowledge of Java and enjoy talking with like minded people. Registration is quick and best of all free. We look forward to meeting you.


Members have full access to the forums. Advertisements are removed for registered users.

View RSS Feed


A few Android tips

Rate this Entry
Well I have been working with Android for a few weeks now and I am absolutely loving it. Here are a few little tips I have discovered along the way to make life easier.

  • Do not fight with Android. Everybody knows that robots are bigger and stronger than flesh and blood. If you find yourself fighting against the system you are doing something wrong.
  • Do not hard code strings - use the strings.xml resource and come up with a naming convention that works for you. There is no namespace with the strings resource so be verbose and consistent with your ID's.
  • As a java developer you are spoiled with a very informative stack trace. The error messages for XML are not so great. Keep the XML files very tight and correct at all times. If you don't, it will claim there is a problem with the Java source and you can spend a long time tracking down problems in the wrong place.
  • You do not use dashes '-' or spaces ' ' or capital letters in your resource names. The reason? Android automatically collates resources into a single .dex file and you access it via a pointer in the autogenerated R class. If you tried to name something
    Icon.png instead of icon.png it could mistake this for the object Icon.
  • Log everything. Personally, I prefer to use break points to aid in debugging but in Android dev logging is absolutely essential.
  • Do not use AbsoluteLayout. You are programming for thousands of different devices with different sizes so AbsoluteLayout makes absolutely no sense.
  • Do not use the UI builder in eclipse or tools like DroidBuilder. They are OK for quick and nasty mockups but start to fail once you get past HelloWorld.
  • Do not bother with the AppBuilder. It doesn't really do anything useful and you cannot upload them to the market.
  • Never, ever, ever import Android.R. It takes precedence over your own R file and is responsible for the three most frustrating hours of my life.
  • Avoid the little red 'X' at the top right of the emulator.
  • Garbage collection is expensive. Try to reuse objects rather than recreating them.
  • Get familiar with the Activity workflow diagram and make use of onPause() and onResume() to handle the state transitions.
  • Use the 'filter by API level' in the API reference.
  • Get the Android source for your reference.
  • Go through the samples provided in the SDK. They will answer most of your questions.
  • Become familiar with the tools provided in the SDK.
  • Use eclipse. It's supported by the people who created Android and the other IDE's are chasing it's tail.
  • Don't rely on eclipse. Know how to use the command line to perform the basic operations.
  • Save constantly and make sure 'Auto compile' is on. Eclipse updates it's intelli-sense with the contents of your resource files but only after the changes are saved.
  • Every feature your app uses need to be included in the manifest. The market automatically filters out apps that cannot run on your phone.
  • Android does a lot of magic behind the scenes. Just run with it.
  • You will come across situations where there is both a Java and an Android class that seem to do the same thing. Always go for the Android class - it is optimized for mobile development.
  • Surprisingly, the biggest concern with mobile development is not efficiency but battery consumption. Unfortunately, there is no good way of gauging how much battery your app consumes. As a general guide, anything that does something uses battery. The more you do, the more you drain. For example, a background service that constantly polls the GPS will make you a lot of enemies.
  • You only have 5 seconds between a user action and a result before you get an ANR (force close). If you have even the vaguest suspicion results could take longer, put it in it's own thread. Don't just block the parent thread; implement a Handler.
  • Follow the UI guidelines. Trying to break the users expectations about how their phone should behave will be met with poor reception.
  • It seems there is a group of individuals who steal your apps and re-publish them for their own profit. There is nothing you can do about this and the market is simply too large to expect Google to moderate this activity.

Some must watch videos:

The only link you will ever need:

Some other peoples tips and tricks:
Tags: android, java, tips