1

I am fairly new to the android sdk and databases and have been searching for an answer to this quite some time.

I am trying to build an app which has multiple tables within a database. e.g. one for weapons, armours etc.

However, my DatabaseManager class which handles all of my table creating, DatabaseHelper inner class and populating of data is creating for an extremely large class requiring high maintenance. Every time I would like to add or remove a table column I need to change quite a few areas of code, - Every reference to the addition of a row in that table with data - The method that the above calls - The method returning all of the database rows - The code in the helper class creating the table - Any specific update methods

My question is this: Surely there must be some better way of coding this system, maybe using a database isn't the best way to go, or am i just not used to such large classes having only learned java at university and my largest class consisting of a mere 400-600 lines of code.

Thanks for any help!

mscriven
  • 11
  • 1
  • 1
    One a somewhat separate note from the question posed, I would say a class with 400-600 lines of code is about as big as it should get. When classes start getting bigger, think about refactoring. – dhaag23 Jan 10 '11 at 16:09

1 Answers1

0

You could use source code generation, e.g. what is provided by jOOQ. See the examples page. When you generate source code from your development database, you can be sure your Java code accessing the underlying database will always be up to date. If anything changes in the database structurally, you will have compilation errors at all relevant places. That way, you can be sure not to forget anything.

On the other hand, if you add a field to a table and you want to insert/update into that table, that field will automatically be considered in all insert/update statements.

In addition to the above advantages, you can use the IDE of your choice (e.g. Eclipse) to provide you with auto-completion to phrase your SQL statements.

Note that support for SQLite is still a bit experimental in jOOQ. Any feedback is welcome!

Lukas Eder
  • 211,314
  • 129
  • 689
  • 1,509
  • How far has the project developed for SQLite? This looks interesting and will definately have a look at this! Thank you. – mscriven Jan 11 '11 at 00:19
  • All my integration tests run smoothly, also for SQLite. This means that you can generate source code from a development schema and run all CRUD operations, including nested selects, unions, etc. By "experimental", I mean that I do not have a lot of experience with SQLite's loose type system. jOOQ will enforce a rigid type system upon SQLite, like in any other RDBMS. i.e. if you have strings in number columns and vice-versa, you may run into problems with jOOQ. I'm planning to support that in the future, though – Lukas Eder Jan 11 '11 at 07:27