|
|
|
|
|
|
by rogerbinns
5118 days ago
|
|
|
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 |
|
|
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.