CODEWITHSUNDEEP
androidsqlclassdata-structures
AutoM8R
AutoM8R

Reputation: 3080

How to Properly Structure my Android App, Classes, Views, Databases, Made Simple?

I'm having a hell of time grasping the best way to "package" my Android app into logical components, my objective is to make an app that is easy to update and add new features to.

I believe a "modular" approach would work best, one where my data is represented as Data Classes, my DB has it's own DB Helper Class which handles all DB interaction and finally View "Controller" Activity Classes which interface the DB Helper, Data Classes and Views all together.

This being said, I need some high-level rules in order to structure my programming, I find if I don't have rules, I end up with sloppy code and massive rewrites as the code gets too complex.

All things considered, are these rules a good foundation for a SQL backed App?

My theoretical Android rules:

  1. The DB Helper Class should contain all DB logic. This means, the DB Helper will contain the code to open and close the DB, as well as the code for inserting, updating and deleting all records. The DB Helper will return data not as cursors, but as Data Class objects that I create, each Data Class will have a constructor which takes the cursor and uses it to populate the values of the Class.

  2. Data Classes will allow DB records to be represented as objects and not just cursors. As the DB Helper will only be returning objects I will have to create adapters for items such as ListView's to render my object's data as opposed to the cursor (I'm a bit fishy on this point, not sure if this is a good idea or not). All business logic, so all calculations to be done on the data contained in the Data Class, will be done in the Data Class itself. I envision my Data Classes having typical getters and setters as well as "calculate" methods, these calculate methods will take vars from the Data Class and do some meaningful business logic on them, returning the result (is this a good idea?).

  3. View Controller Activity Classes will literally tie the DB Helper's methods to the Data Classes and update the Views with the resulting information. This Activity Class will be quite normal, it will initialize the layout and widgets, it will use the life-cycle methods to perform various queries on the DB through the DB Helper at the appropriate times, and it will have simple update methods which update widgets using the Data Class object they're fed.

I am finding I have no troubles with Android except for struggling with issues of design such as these. I am tired of my applications becoming too complex, and I need a simple system to ensure things stay manageable and extensible.

If you struggled like me, please, please, please, push me in the right direction for structuring an App. It's all that's holding me back from making what I hope are amazing apps for everyone's enjoyment.

Upvotes: 4

Views: 642

Answers (1)

BlackHatSamurai
BlackHatSamurai

Reputation: 23503

The biggest thing you need to consider when designing your app is: who is going to maintain it? If you are going to be the only one who is doing maintanence on your app, then do whatever works best for you. However, if others are going to be maintaining this app, then yes, you will want to keep similar things together. It sounds like you have a pretty good plan. Make sure you use comments and if you like, you can include a "readme.txt" that will allow others to see what is going on and for you to explain your design logic. To keep things from becoming too complex, you can use packages to store similar classes.

Ultimately there is no single right answer to your question.

Upvotes: 1

Related Questions