How to avoid subclassing Android.App.Application

Question

In the past I've subclassed Application to maintain an active database connection for the application. However, according to this SO answer Application runs in the UI thread, which makes me think I should definitely not use it for database access. Furthermore, according to the Xamarin Application docs (and those of Android proper):

There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), the function to retrieve it can be given a Context which internally uses Context.ApplicationContext when first constructing the singleton.

I think I understand the Context to be something I can use to maintain some sort of static access to application resources, but there are no examples in the docs and I've not encountered this situation before. Would anyone be able to explain the above note and relate how they have used Context to maintain application resources (unless I'm completely missing the point)? Links to or direct examples would be appreciated.

score -1 · Accepted Answer · answered Sep 24 '17 at 02:28

I believe I've found the droid answer I'm looking for.

Dave Smith has provided a simple example of a "static singleton" as referenced in the doc notes above:

public class CustomManager {
    private static CustomManager sInstance;

    public static CustomManager getInstance(Context context) {
        if (sInstance == null) {
            //Always pass in the Application Context
            sInstance = new CustomManager(context.getApplicationContext());
        }

        return sInstance;
    }

    private Context mContext;

    private CustomManager(Context context) {
        mContext = context;
    }
}

The Context itself does not contribute to the longevity of the CustomManager - its existence is simply owing to the nature of a static singleton itself. The Context as provided by context.getApplicationContext() (Xamarin Context.ApplicationContext) is simply a means of accessing the application Context if it is needed by the singleton.

That being said, as elaborated by this SO question and its top two answers, the real question is not so much if, but how do you want your global application data to be a singleton - as an extension of the framework-supplied Application singleton, or as an additional, separate singleton you create which may or may not make use of the former.

For my part, I think I am content with simply subclassing the Application after all. It intuitively makes more sense to store application data in some variant of the Application class. Furthermore, I have certain OOP misgivings about creating singletons in general, so I feel safer using the one already existing than making my own. This singleton is managed by the framework, so while that does not guarantee safety from the typical woes of what essentially boils down to a global variable (boo hiss), at least it is a little safer than rolling my own.

P.S. - re: the using the Application which runs in the UI thread, it seems using a static singleton does not do me any extra favors - again, since that's all using Application amounts to anyway. I think I will probably follow the advice offered here and make use of AsyncTasks for processor-heavy operations.

How to avoid subclassing Android.App.Application

1 Answers1