2 Answers
2

Be careful with your "singleton" implementation. Your init method should be synchronized to ensure that you don't end up with multiple instances of your DatabaseManager class due to concurrency issues. I would just combine the init and getInstance methods to the following (note the added synchronized keyword):

To answer your question about how to organize your loading methods like getAllCars, I would first suggest making them static, since they do not depend on anything else besides your method to get your singleton of DatabaseManager, which of course, would also be static. If you have a small number of these types of methods, you could make them all static members of DatabaseManger. If you have many, you could make a helper class for all static methods corresponding to a type.

If you have a method that does depend on the internals of a given instance of CarMDL or MarkMDL (like you need a method to get some associated references), consider making these methods members of the CarMDL or MarkMDL class.

I actually do not have a problem with the locally cached DAO instances. Looking them up in the DaoManager requires an object creation and there is no penalty that I can see. That's the pattern that all of the example objects use.
–
GrayApr 9 '12 at 23:07

ok, combining init and getInstance looks nice! But I'm not sure to put all the models functions in a single class, would be better to create another DAOs that extends an interface with some common methods? but I´m not sure how this could be...I'm a bit confused
–
skaboApr 10 '12 at 13:17

I put all my one-time-per-app work in Application onCreate and I keep a reference of the application instance itself, so I can do many tasks without having to mess with synchronized methods or similar. So let's say we have an Application (remember to add it in the manifest):