CODEWITHSUNDEEP
androidandroid-activity
Barles
Barles

Reputation: 200

Save multiple instances states of the same Activity in Android

I am developing an Android app and I would like to avoid reloading similar data when it comes from the same Activity using the same extra.

Specifically, when I launch my Activity 'A' with extra, I use this extra to load remote data from server. From this Activity, I can relaunch 'A' with different extra and so on.

Example :

A:id1 --> A:id2 --> A:id3

But, it can also be an extra that I already loaded :

A:id1 --> A:id2 --> A:id3 --> A:id1

In this case, I wouldn't request the server again or lose the activities stack.

As I understand, "onSaveInstanceState" allows to save one instance of one Activity, but in my case, it's multiple instances of same Activity (with differents extras).

So, is it the solution to manage a list of saved instance states (bundle) for the same Activity ? Or something else ?

Thanks in advance

Upvotes: 4

Views: 1580

Answers (2)

Edward Falk
Edward Falk

Reputation: 10103

+1 for MattDavis' answer, but I'd also suggest you use what's known as the "singleton pattern".

Essentially, this is a way to cache things in memory. You create a class whose purpose is to hold all the database data you don't want to keep reloading. There's a single global instance of this object, which is initially null. You call a static method that returns that instance. If the static method finds that the instance is null, it creates the instance, populates it from the database, caches it, and returns it to the caller. From that point on, all requests for the instance just return the cached copy. If your app gets killed by the system for lack of resources, and started again later, it transparently re-creates the instance as needed.

This is a very common implementation, and works in a multi-threaded environment:

public class Singleton {
    private static volatile Singleton instance = null;
    private Singleton() {
        // This is the place where you initialize the instance
        // from the database.
    }
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized(Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

I use this pattern in a lot of places; it's very handy.

To really do it right, you should also implement onLowMemory() or onTrimMemory() in your activities to release the singleton instance when resources are tight.

Upvotes: 0

MattDavis
MattDavis

Reputation: 5178

The onSaveInstanceState method isn't used in the way you describe. Check this out, it's the documentation for the Activity Class, specifically the Activity Lifecycle section. onSaveInstanceState is a method that gets called when the OS has to kill an Activity for some reason. It allows you to populate a Bundle which will help recreate that specific instance of the Activity where the user left off. Usually this happens because the user switched to a different app and the OS is killing the Activity to reclaim memory, but also happens on screen rotation, so it's a nuance of the platform that is important to at least be aware of.

As for your question, what I would do is use a database to store the information that is retrieved from the server. When you start an Activity, you can first check to see if the data that needs to populate that Activity exists in the database. If it does, load and display it from there, else make the server call.

This is nice, because the data will be persistent over multiple uses of the App. Going further, if the data from the server has the potential to be stale, you can easily extend this to display the data from the database initially, and fire off an asynchronous request for the data that will update both the UI and database when it returns. Your user will almost never be in a state where they're waiting for things to load, which is always a good thing!

Here's a good tutorial on the basics of implementing an sqlite database. This will also give you the added benefit of keeping the data stored over separate runs of your application.

As an alternative, if you don't really need the persistence or other features of the database and don't think that the overhead is worth it, you could create a Singleton class which keeps track of the data as its returned, perhaps implementing it using the Application class. It's important to note (and bringing us full circle) that any in-memory method of storing this data should be managed with onSaveInstanceState to ensure you don't lose any data if the Activity is killed at an unexpected time.

Upvotes: 3

Related Questions