0

When I switch from ActivityA to ActivityB I need to do a bit of background processing on a Bitmap from ActivityA (maybe a few seconds' worth) before it shows up in ActivityB. Rather than delay the launch of ActivityB and make my app feel sluggish I'd like to launch it immediately and have it make use of the Bitmap as soon as the processing is finished (the user can do useful things in ActivityB before the Bitmap is ready).

The standard answer for receiving data from long-running processes seems to be a retained, non-UI Fragment, which works great if your Activity gets destroyed then re-created, but what about where you switch to a different Activity? Even retained, non-UI Fragment instances appear to be associated with a particular Activity class, even after the Activity itself is destroyed, and it appears that calling FragmentManager.findFragmentByTag(String tag) from an instance of ActivityB will fail to retrieve a retained, non-UI Fragment created in ActivityA.

Is FragmentManager.findFragmentByTag(String tag) supposed to work from an instance of a different Activity and I'm just doing something wrong? Or is there some other technique recommended in this situation?

A Service feels like overkill here, but maybe I'm wrong and frequent creation/destruction of Service instances is perfectly acceptable in Android apps (in which case my question is: why bother with a retained, non-UI Fragment ever?)

Edward Coffey
  • 447
  • 3
  • 8

1 Answers1

1

How about creating your own Application object?

You can have a private member variable to hold your bitmap along with a getter and setter that both activities can access.

Something like:

public class MyApplication extends Application 
{
    private Bitmap bitmap;

    public void setBitmap(Bitmap bitmap)
    {
        this.bitmap = bitmap;
    }

    public Bitmap getBitmap()
    {
        return bitmap;
    }
}

Then reference your application in your android manifest file.

    <application
        android:name=".MyApplication"
        android:icon="@drawable/ic_launcher"
        android:label="@string/app_name"
        android:theme="@style/AppTheme" >

Then in your activities, just call getApplication(), cast it to your Application class and call the getter or setter.

    MyApplication app = (MyApplication)getApplication();
    app.setBitmap(bitmap);
    Bitmap bitmap = app.getBitmap();
Michael Krause
  • 4,689
  • 1
  • 21
  • 25
  • I'm having trouble finding much about recommended uses of the Application class on http://developer.android.com, but its API documentation (http://developer.android.com/reference/android/app/Application.html) says "There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way" - so maybe the answer is to use a singleton (then shower thoroughly). – Edward Coffey Oct 10 '14 at 00:46
  • A singleton would certainly work as well. We all should probably shower regardless. :) – Michael Krause Oct 10 '14 at 02:34
  • I did a bit of searching and found an interesting discussion about singletons and `Application` that goes through a lot of the pros and cons. This comment made me feel a bit better about the API's recommendation of the singleton approach: http://stackoverflow.com/questions/3826905/singletons-vs-application-context-in-android#comment8239671_3888560 There's also a mention of Dianne Hackborn, so I tracked her down and found her preferred Singleton approach here: https://groups.google.com/forum/#!msg/android-developers/2i82mjoM46M/2cqBiR9UtpYJ – Edward Coffey Oct 10 '14 at 03:51
  • Wow. The Google group discussion is a good one complete with comments from heavy hitters like DH and Mark Murphy. A good read! – Michael Krause Oct 10 '14 at 06:29