0

I need to store an ArrayList that will fetch data from Database, i am thinking of declaring that ArrayList in class that is subclass of android.app.Application class as i would be needing this frequently for search, sort etc purpose all over in my application.

1. It would be good approach to create get the Database instance in Application subclass.   
2. Storing a list in the Application subclass.

I am not sure it is correct approach, i want to know what would be the drawbacks of this approach. Suggest if some other approach can be used.

Bill the Lizard
  • 369,957
  • 201
  • 546
  • 842
  • Serialization/Deserialization. I don't see any drawbacks in using a subclass of Application (except if you're relying onTerminate to get called when your app dies), personally I would use serialization, but it all depends on project requirements. – nullpotent Dec 21 '12 at 14:39

3 Answers3

1

I don't believe there're any drawbacks, despite the fact that you have to declare your Application on the manifest.

But you can easily achieve the same result creating a singleton which IMHO is a much cleaner way of doing it.

edit:

I just saw your edit and I'm editing my answer:

same thing goes to the DB object. Use a singleton! And on the first access you open the DB.

Budius
  • 37,587
  • 15
  • 92
  • 134
  • I'd try to use the Application class over a Singleton-pattern as much as possible, as singletons can create memory leaks! [This SO post](http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons) has some valid arguments – Ruben Dec 21 '12 at 14:42
  • @budius "I don't believe there're any drawbacks, despite the fact that you have to declare your Application on the manifest." \n please elaborate this comment and share the deeper meaning of the sentence. –  Dec 21 '12 at 14:45
  • @Ruben any poorly written code can cause memory leaks. Singleton or not. The database is an unique 'thing' within the whole app and as such I think the singleton is the pattern for that. – Budius Dec 21 '12 at 14:50
  • @guptakvgaurav if you override the Application you must declare it on the manifest, so that the system can instantiate the correct object. Inside the `Application` tag you have to include `android:name="_your_application_class_"` – Budius Dec 21 '12 at 14:52
  • @Budius That's true, however, when using a singleton design pattern, there is usually a static object which may or may not be collected during garbage collection. (This is in my opinion a very interesting topic and I'm happy to read more arguments why you would prefer one over the other) Plus, why would declaring the Application class in the manifest be a drawback? – Ruben Dec 21 '12 at 14:54
  • @buduis : so is there any harm/security issue/violation of coding standard practice in declaring my application class in manifest file. (and this declaration is must in this case) –  Dec 21 '12 at 14:56
  • @guptakvgaurav not at all. It's the normal practice, just don't do anything silly overriding stuff and changing behaviours. – Budius Dec 21 '12 at 14:59
  • @Ruben not really drawback, just an extra step before stuff is working. Ps.: All my discussion here is specific for DB objects: 1) Proper class compartmentalisation. Application and DB are different stuff and as such shouldn't be tied together in the same class. 2) if you instantiate and destroy the DB object on Application `onCreate` and `onTerminate` you're having an object that it will never be garbage collected and will use memory for as long as the Application exist. If you do it as a singleton, the DB object will only start to exist on the 1st access, and go away `onTerminate` – Budius Dec 21 '12 at 15:08
  • hey @Ruben just to be clear, I agree it's a fascinating topic and I'm just discussing ideas, not getting religious about stuff. Feel free to reply and tell me more about your ideas. I believe there's the correct situations for the correct proper stuff. And to add to my point of view I would like to point to this Dianne Hackborn (software engineer at the Android Team) comment: http://stackoverflow.com/questions/3826905/singletons-vs-application-context-in-android#comment8239632_3888560 – Budius Dec 21 '12 at 15:14
1

If I am understanding you correctly, you could set up a class to handle your DB actions and then create a reference to that class when needed, passing whatever parameters you need. You could have a function to return an ArrayList if that's what you need. Depending on what you need, you may be able to implement this as an interface in the activities that need them.

codeMagic
  • 43,753
  • 13
  • 72
  • 91
  • This is exactly what i have done, but with this approach i have to do similar task again and agian, like i will getWritableDataBase first, then query, get the list then, now if i have to display the list i will return list, if i have to sort i will do same process again and do sort and return resulted list. yes, i can remove common task and make it centralize but still i have to do that repeatidely. I want to remove repetition so that i have list available all time and make local copy of list and whatever you i want –  Dec 21 '12 at 14:52
0

There are a few things you should take into consideration before deciding whether you're going with a Singleton design pattern versus the by Android provided Application class.

You may find some arguments that may help you choose in these SO posts:

And here is a great tutorial on databases in Android:

Community
  • 1
  • 1
Ruben
  • 776
  • 2
  • 9
  • 21