I'm writing a small application for Android and I'm using GreenDAO as my ORM. I wonder how long should I keep my session open? I have several activities that read/write data from database and I see the following possibilities:
Keep session open per Activity basis: created in onCreate and closed onPause/onStop
Keep one session open in all activities and just pass it somehow between them.
Open session in onCreate, read all the data necessary to populate list view and close while still being in onCreate - I think this forces me to read all the data at once, which can slow down application considerably though.
Which option do you think I should choose? Maybe there's some other, canonical way of doing this?
I found a comment to this article:
http://greendao-orm.com/documentation/how-to-get-started/
where "DaoMaster" recommends application scope dao sessions.
He also talks about using Singletons, but I would not recomentd Singletons in Android unless you realy know what you're doing, because Singletons work a little different then on the jvm.
Related
I am new to android development and I see that there are different components (activities, services, etc.) where each component has a different life cycle.
I am encountering a situation where I have an object that should be accessed by different components. Namely, I have a list of objects that changes dynamically, and that list should be accessed by:
An activity that displays the list in a ListView
A broadcast receiver, that responds to alarm events scheduled in the AlarmManager.
The broadcast receiver may kick in hours after the activity was used. At this time, the activity may or may not be still alive in memory.
Is there anywhere I can put the list so it will be accessible to all app parts? My idea was to serialize the objects I need to share, write them to shared preferences and then recreate them whenever needed. I'm not sure it's a good idea, and even if it is - how would I design it? when would writing to shared preferences (or somewhere else) occur? when would reading occur (it would be preferable to read the object from memory when possible)?
You can put it in SharedPreferences if it a compatible data type, or serialize the list to a file in the internal or external storage (see saving files, you probably want internal storage for your situation).
You can read the list in the onResume() method of the Activity or the onReceive() method of the receiver. Writing will occur whenever a new element needs to be added to the list, you will deserialize the list, add the element and re-serialize it. You may need to place the reading and writing in a synchronized block or method to prevent simultaneous access.
If the list may be added to outside of the Activity when the Activity is resumed you may need to provide a broadcast receiver or other mechanism for the Activity to be alterted and reload the list.
As Gabe pointed out, you could store it in a static variable somewhere, but the way you described the situation serializing sounds like a better option. Otherwise the list is gone if your process is terminated by the Android system.
As kcoppock pointed out, you could use an SQLite database to store the data, but this sounds like overkill from what you described. You will be in for some additional coding without much benefit.
What you are looking for is the Android Shared Preferences. You can access Sharepreferences using getApplicationContext() from an Activity or a Service.
Hope this helps
If you don't want it permanently stored, put it in a static variable somewhere (anywhere they both agree to- a separate class would be a good idea). Then you can access the list unless Android kicks the class out of memory- which it should only do it its terminating the app due to lack of memory, in which case it doesn't matter much anyway.
If you do want it permanently stored, the filesystem is the best way. You'll need to synchronize access to it of course.
Just wondering what is a better practice to pass information between activites, adding it to a bundle or using a singleton class to store and access this data. I have used both in the past for various android side projects, but I am now working on an android project that is of much larger scale, so would prefer to do things right towards the beginning.
My application authenticates users and then will have to do various queries based on it's id. To minimize coupling between activities, I would think just adding the id to the bundle, and then letting each activity query for the information that it needs, would be the best bet; however to increase responsiveness, I was leaning towards using a singleton class to store persistent information, preventing more queries than need be.
Personally, I would create an extension of Application to store the state of your app and share data between the different activities. The Application acts as the context for your whole app and Android guarantees there will always only be one instance across your app. Hence it works similar to defining your own Singleton, but using Application will allow Android to take control of the life cycle of your shared data and basically do the memory management for you.
Here are some more details. If you go down this path, you can simply add any getter/setter (or other) method to your application extension to store/retrieve data and do operations on it. Especially the latter can become quite a pain to manage (and keep consistent) when using Bundles passed back and forth between activities. If would only use a Bundle if the data is needed in just one or two places that are neighbours in the activity flow and does not need any (complex) operations to be run on it.
The better way to go for you is to use SharedPreferences to keep userId you need to keep and reuse. Of course you can use singleton approach or even Application class, but the data will be lost after application is killed.
The only time I pass data between Activities via bunlde is if it's something that I won't need to access for a while(i.e the the resID of a resource I want to use only once in the calling activity, etc). I would also think the difference in responsiveness would be very minimal, so that shouldn't be of concern. I suggest the singleton approach
Passing bundles is a tedious job. You'll have to pass a bundle for every change in activity to make sure that the value is not lost, even if you're not using the value in the called activity.
Singleton pattern have some bad results. For example:From Main activity you call secondary activity. Phone call interrupted your work.After ending phone call Android is trying to bring secondary activity to screen. Here is my nightmare - many users complaint about exceptions - Google reported to me NULL pointers in my singleton. So you have to provide not only singleton, but all data inside singleton have to be as singleton too. This maked come very complicated :(
I have a multiple Activity application that progresses the user from entering an IP/Host address, to entering some data (another Activity), to viewing a stream of video frames (yet another Activity). I share the Socket between the Activities by creating a singleton. Is this considered a bad pattern to use for an object that cannot be serialized?
I have looked all morning through some of these posts and others through out the web and the best that I can come up with is there is no real easy way, but this one seems very easy to me. The only other approach I think has merit is a custom Application object.
Any insight by people who have worked with singletons across Activities I would really like to hear of any problems I may not be aware of that might get me later... Thanks!!
The downside to your approach is that you cannot rely on the singleton's data structures to always be kept around in memory. Your best bet is to persist information in either SharedPreferences or a SQLite database.
It sounds like your singleton might be a good candidate for a Service. Services are meant for long runnning operations that do not have any UI. Multiple Activities can bind to a service and interact with it. Unlike a singleton, if/when your service gets killed, you will get lifecycle hooks to deal with it appropriately. You can also set it to be restarted when appropriate.
I have a (hopefully) quick question regarding handling SQLite database connections in Android. I have an app that is composed, naturally, of several activities. I have no trouble creating/updating/querying the database, as I've created a single, dedicated class to handle that work via SQLiteOpenHelper, etc.
My question is this: since these activities all share this same database, is this usually implemented as a single, static member, or should each activity own its own connection? My concern of course is the cost of re-connecting to the database in each activity.
Or, put another way, is there any reason not to just store a singleton instance?
I'm also wondering if there's something going on behind the scenes similar to .NET's connection pooling to reduce the cost of opening connections.
Thanks in advance!
Connection opening in SQLite is about 0.2ms.
The best practice tells us to open and close the connection each time we need one.
Just use SQLiteOpenHelper.getReadableDatabase() and SQLiteOpenHelper.getWriteableDatabase() - Android will manage and cache the connection so you don't need to.
In fact, refer to the official Google Using Databases documentation:
To write to and read from the
database, call getWritableDatabase()
and getReadableDatabase(),
respectively. These both return a
SQLiteDatabase
I have a Weather app with four Activities. The main/launcher activity is 'invisible' using...
android:theme="#android:style/Theme.Translucent.NoTitleBar"`
...and is simply used to do a few checks (whether this is a new install, whether a network connection is available etc) before firing off one of the other Activities. The other Activities are UI-oriented - two simply display weather data pulled from a website and the third to provide a location 'picker' so the user can choose which area to show the weather for.
However, all four activities make use of a WeatherHelper object which basically does everything from checking for available SD card storage to maintaining preferences and pulling/formatting website pages.
So, my question(s)...what is the best way to have one instance of WeatherHelper which can be used by multiple activities and where/how are best to create it in my case?
I've been an OO programmer for a lot of years but I'm very new to Android and the design concepts - I've read a lot on the Android Developers site over the past weeks but I've stalled trying to decide on this.
Any ideas gratefully received.
I would store shared information in you Application object. Subclass this and add any extra initialization and data there. You can get your application using getApplication() from your activity, which you can cast to your specialized version and access the shared data.
I would also avoid launching the special startup activity if possible and do the work in your Application's onCreate() override.
Well, your question has been answered, but it seems like it would be much simpler to instantiate your WeatherHelper object in the onCreate() of the Activity that has the launcher intent, and make the WeatherHelper static.