Those of you who write Android apps, what application design patterns do you use to organise them?
I've seen people re-create almost exactly the DAO-Service-Controller (Activity) layering you'd find in a server-side application, using RoboGuice as DI container. So, the DAO talks to the SQLite database, converts the result set to a list of entities, and so on. This approach bothers me because you lose (or have to work hard to re-create) a lot of Android's built-in benefits (e.g. URI-based dataset change notifications) and there might be performance or memory problems with larger datasets. I've tried staying closer to the built-in structures: content provider as DAO, services for most business logic, broadcast receivers as message-driven beans, activities as controllers and cursors/adapters for data binding. The disadvantage here is that everything tends to become very loosely typed. Between dispatching, threading, networking and actual business logic, things feel frustratingly messy. The lack of easy DI because of the need to pass the Android context everywhere makes composition a little harder. What do you use to stay organised? A few simple things are easy to centralise. For example, for database mapping, I use a static inner class per table, which leads to constants like these: Database.Presentations.TABLE_NAME and Database.Presentations.DURATION. Uri matching and construction is handled in a static helper class. But I haven't really found anything on a larger scale. Moandji -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
