Something else for new Android developers is to realise that Android apps are structured completely differently than iOS or desktop apps (if you follow best practise).
Instead of a single main() entry point, consider your app to be a mashup of ui (activities), data (content providers), processing (services), broadcast state (receivers) etc. You can just as easily incorporate those components from other apps as from your own. You don't have to do most things yourself - eg to include Dropbox/Facebook/Twitter/Google or your own account system you can use the AccountManager instead of building your own credentials user interface (the sign of an iOS ported app).
If your app will be talking to a server, along the lines of providing a user interface to view data and make changes, with the underlying data flowing over REST or something similar then watch this talk which talks about best practises. It is especially a good idea to remember that mobile platforms can arbitrarily kill applications at any time for any reason, and the same can happen to the network. Consequently you need to record what is going on in a local database to be resilient. Talk is from Google I/O 2010 but applies today: http://www.youtube.com/watch?v=xHXn3Kg2IQE
So, I spent some time trying to implement the architecture proposed in that talk. I kept finding myself adding just tons and tons of more or less boilerplate code. This felt wrong to me. Surely there must have been a better way.
Fortunately, Google released the source for the Google I/O app, built using the same architecture. What did I discover? A giant pile of boilerplate code to accomplish very little in terms of actual functionality. Moreover, this was for an app which fit pretty well into the relational model (small objects with few relations each).
It may be current best practice, but there has to be a better way.
Unfortunately it is very easy to end up with boilerplate code when using Java. It isn't a direct fault of the language but rather that Java developers hate making decisions so you end up with endless layers of abstraction and indirection. (Immortalized as FactoryFactoryFactory.)
You may find this list of libraries used in Android apps useful. There are several that cover this architecture pattern if you want to use them (eg data access, networking, format parsing):
Instead of a single main() entry point, consider your app to be a mashup of ui (activities), data (content providers), processing (services), broadcast state (receivers) etc. You can just as easily incorporate those components from other apps as from your own. You don't have to do most things yourself - eg to include Dropbox/Facebook/Twitter/Google or your own account system you can use the AccountManager instead of building your own credentials user interface (the sign of an iOS ported app).
If your app will be talking to a server, along the lines of providing a user interface to view data and make changes, with the underlying data flowing over REST or something similar then watch this talk which talks about best practises. It is especially a good idea to remember that mobile platforms can arbitrarily kill applications at any time for any reason, and the same can happen to the network. Consequently you need to record what is going on in a local database to be resilient. Talk is from Google I/O 2010 but applies today: http://www.youtube.com/watch?v=xHXn3Kg2IQE