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.
You can extend the library's Application class in the application project and provide any additional implementation. If you do this, you will have to use this extended Application in the manifest.
The Application class in Android is the base class within an Android app that contains all other components such as activities and services. The Application class, or any subclass of the Application class, is instantiated before any other class when the process for your application/package is created.
AAR files can contain Android resources and a manifest file, which allows you to bundle in shared resources like layouts and drawables in addition to Java classes and methods. AAR files can contain C/C++ libraries for use by the app module's C/C++ code.
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. ;)
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With