CODEWITHSUNDEEP
android
wufoo
wufoo

Reputation: 14571

Class extending Application in Android project library?

I have a project (in Eclipse) which I've turned into an Android Project Library so as to re-use some of the code in another similar project. I think I've shot myself in the foot however as I'm getting the error:

Unable to start activity ComponentInfo{com.test.scroller1/com.lib.scrolltest.ScrollTestActivity}: java.lang.ClassCastException: android.app.Application cannot be cast to com.lib.scrolltest.resAppVars

com.lib.scrolltest is my Project Library which instantiates a class extending Application (resAppVars). In the onCreate() method I call:

mRav = (resAppVars) getApplicationContext ();

This way, I can use methods in the mRav object which would otherwise be a lot of duplicated code in other classes (such as passing a query to a generic select statement which returns an ArrayList of results).

What's the problem here? It seems I've hit a limitation in the way I've implemented the Application class.

Upvotes: 6

Views: 7605

Answers (2)

ilomambo
ilomambo

Reputation: 8350

Although this is a very old post. I encountered the same problem and solved it. So I thought I'll post the solution for everyone.

It turns out that I forgot to declare the subclassed application name in the manifest file. The android:name should point to the extended app class, even if it is defined in the referenced library.

<application
    android:allowBackup="true"
    android:icon="@drawable/ic_launcher"
    android:label="@string/app_name"
    android:theme="@style/AppTheme"
    android:name="com.example.lib.MyApp">

After I added that I could use the extended app with (<cast>) getApplication() anywhere in my project.

Upvotes: 3

Trevor Johns
Trevor Johns

Reputation: 15762

Calling getApplicationContext() returns the Application object for the current application (i.e. the application that owns the activity that onCreate() is running inside of).

Unless you're doing something strange, you don't get to pick which Application class is used. There's even a note in the documentation for Application saying not to do this:

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.getApplicationContext() when first constructing the singleton.

You should just create a regular shared class inside of your library project. Or if you don't have a need for the special functionality library projects offer, you can also just use a regular .jar file.

And if you need shared state, just make it a singleton. ;)

Upvotes: 4

Related Questions