Is there anything I need to take into account when repeatedly calling the same activity?

Question

I am developing an app where a single activity is instantiated multiple times by itself. I guess you could think of it like a book where each activity is a page. At the end of the page (activity) the user presses a button to go to a new page. I fire off an Intent for the same Activity, but I push different data into the Bundle so that a different page is loaded.

This works fine, and I like the fact that the user can back up to a previous point, but my question is whether this will eventually be a problem? What happens if this activity is instantiated 10 times, or 50, or 100? Will the device run out of memory, will GC come along and clean up old activities, or what?

If GC does clean them up, what happens when the user presses Back and the previous Activity is no longer on the stack?

Is it better to keep track of the user's path, finish() the activity, and override the Back button so that whether the user is moving forward or backwards, I only load a single Activity? Another approach I could take is to refresh all the data on the page so that it's still the same activity, but with new data. The Back button would not work as expected in this case.

Thoughts?

Answer 1

Hi, have you considered perhaps using the same Activity and just changing the content that it renders.

So in the book example. You would have a book Activity which would have a Page ViewGroup somewhere in its view hierarchy that renders the contents of the page. Then when a user goes to the next page or the previous page, the Page ViewGroup simply renders the contents of the desired Page. You could then use a data-structure to manage your stack of pages and the users current position.

Not sure what your app is trying to do, so I understand this might not work for your particular use. However, I would expect this to have a better run-time performance than instantiating entire Activities.

Old Activities that are no longer visible will get destroyed if their memory is needed. However, Android has a state persistence mechanism in place so that when an Activity is restarted (navigating back to page that was destroyed in your case) it can be reconstructed properly. This can be done through the shared preferences mechanism or the bundle object passed into Activity.onCreate. However, you will have to explicitly save off the state in Activity.onStop(...) and Activity.onSaveInstanceState(...), and then restore the state in Activity.onCreate(...) and Activity.onRestoreInstanceState

More on the lifecycle of Activies can be read here (Not sure what your level of understanding is) http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle:

Now I'm not sure what happens at the extremes of this, whether you can create so many Activities that Android will no longer be able to bring back ones it killed. I would expect that there's some sort of protection mechanism in place to prevent that but I don't know what it is.

Found this article which might provide some more info, not sure if this is the info you were looking for though: http://zerocredibility.wordpress.com/2009/08/24/why-android-swap-doesnt-make-sense/

Cheers & Happy Hunting!

Answer 2

I would rather override the back button behaviour and using for instance a ViewFlipper to do the animation job. That's pretty simple to do:

    // You could do simpler by overriding onBackPressed() if you
    // don't need 1.6 compatibility
    //--
    @Override
    public boolean onKeyDown(int keyCode, KeyEvent event) {
        if (keyCode == KeyEvent.KEYCODE_BACK && event.getRepeatCount() == 0) {
            if (currentPage>0) {
                return super.onKeyDown(keyCode, event);
            } else {
                currentPage--;
                showPage(currentPage);
                return true;
            }
        }
        return super.onKeyDown(keyCode, event);
    }