I have a library defining an abstract Activity. The app using this library extends the Activity, and therefore needs to add it to its AndroidManifest.xml.
The AndroidManifest.xml of the library gets merged to the one of the app following some rules.
However, I can't seem to find a way to declare my abstract activity in the AndroidManifest.xml of the library. I would like to set android:configChanges and android:launchMode in the base class instead of having to declare it in the manifests of all the subclasses.
Is that possible in some way?
In your manifest you only have to declare the Activities that are actually used by your application. You should declare the Activity that extends your abstract Activity.
To edit the configuration of your activities, you have to set these parameters for each of your concrete activities in your manifest.
Short answer; no.
From what I can find, the only way to set the android:configChanges and android:launchMode attributes is in the manifest. And the manifest only accepts the name of the class that you will be instantiating (i.e. the subclasses of you abstract class).
Related
Android application using Xamarin but I think this applies to non-Xamarin. I read this article while doing research.
In an Android application, you will notice that the AndroidManifest.xml file contains an entry for which is used to configure various properties of your application: icon, label, theme, etc. Depending on your application's needs, this is sufficient. The application when instantiated will perform the necessary initializations based on the values configured in the manifest, and it will then load the Activity that is defined as the view to load on startup.
In some cases, you may wish to extend the Application class in order to perform custom initialization on application startup, or to maintain global application state (for example, in the case of a game that is tracking score across multiple levels). The example that you have shown above is the case where someone has decided to subclass the Application class and override it's OnCreate method, although they haven't included any custom code in the override method. It looks like their purpose was to create a global static property to always have access to the Activity that is currently loaded.
Previously, I did not need to extend the application class so I just had my manifest handle it like this article says. However, I recently had a need come up to extend the application class so I can use the OnCreate event for the application.
I added a new class which extends Application and it looks like this:
namespace MyApp.Droid
{
public class MyApp : Application
{
public MyApp(IntPtr handle, global::Android.Runtime.JniHandleOwnership transfer)
:base(handle, transfer)
{
}
public override void OnCreate()
{
base.OnCreate();
//Do OnCreate things here.
}
}
}
It seems just adding this class is not complete. First question, do I also have to modify my manifest now? Second question, the class can have attributes for theme, icon, etc... which are and have been defined in my manifest. Can they stay in the manifest or do I need to move them to this new class as attributes?
Here is the manifest:
<application android:allowBackup="true" android:icon="#drawable/mainapplogo" android:label="#string/app_name" android:roundIcon="#mipmap/ic_launcher_round" android:supportsRtl="true" android:theme="#style/AppTheme">
Thank you!
First question, do I also have to modify my manifest now?
In this question if you mean just because you have added the new application class is there a need to make any change in the existing manifest then NO there is no such requirement.
Second question, the class can have attributes for the theme, icon, etc... which are and have been defined in my manifest. Can they stay in the manifest or do I need to move them to this new class as attributes?
The Android Manifest's Themes and everything else will stay there, The Android Application class and AndroidManifest.xml work independently and hence adding an extended application class does not require any change in your Manifest file or vice versa.
Good luck,
Feel free to revert in case of queries
UPDATE
See to it that your application class has the [Application] attribute on top of the class name
#if DEBUG
[Application(Debuggable=true)]
#else
[Application(Debuggable = false)]
#endif
public class MyApp: Application
{
Is it compulsory to add a class file, which extends activity, to manifest?
I have created a java file for handling file IO and to use openfileoutput() openfileinput() i have extended Activity class.
YES you most declare it in the manifest so the application will know its activity.
If you use/call that class (which extends Activity) somewhere in your code, you MUST declare that class (Activity) in Manifest file. If you don't, you will get exception.
Manifest file is used to declared essential information for your app (Activity, Service, Broadcast Receiver, keys,...).
For more info about Manifest, you can check it here.
when you launch the application first the OS will check your manifest file.So if your Activity is not Listed in the Manifest file.Then it won't execute it.So your ACTIVITY class should be declared in the Manifest file.
I am having two classes in my android project so, should I mention two activity tags in my app manifest file or will it work without including the activity tag.
Although, my app is working fine but I think this creates error - Unfortunately, your app has stopped working.
it depends Which kind of classes you have.. if your class is extending Activityor ActionBarActivity or AppCompatActivity or the class wich extends any of these, than you must define it in manifests.xml file. otherwise if your class extends nothing or just extends view, then no need to define it in manifests.xml file.
Yes,every Activity you used must be declared in manifests.xml,or when jump the activity,app will crash.
Inside my android manifest file I have an application tag and inside is name property/label.For what is this used for ?
If you are referring to the android:name XML attribute, then, quoting the documentation, it is:
The fully qualified name of an Application subclass implemented for the application. When the application process is started, this class is instantiated before any of the application's components.
The subclass is optional; most applications won't need one. In the absence of a subclass, Android uses an instance of the base Application class.
Application class in the Android is used for global settings or running entrance.
In the Android reference it describes the Application class: "Base class for those who need to maintain global application state. You can provide your own implementation by specifying its name in your AndroidManifest.xml's tag, which will cause that class to be instantiated for you when the process for your application/package is created." more
Assuming I have a shared activity class defined in a Library project, which does not change for any application using it and thus does not need to be subclassed, can I get a way with creating applications without subclassing this activity for them?
To better explain my question, say I have a single activity in a Library project:
public class LibActivity extends Activity {
...
}
And now I am creating an application using that Library project. Do I really need to create
public class AppActivity extends LibActivity {
// totally empty!
}
Only so that the application have its own activity to be referenced in its own AndroidManifest.xml?
Can I get a way with a minimalistic approach, in which I subclass the activity only if I need to modify the library's activity core behavior?
Here is the fully qualified answer:
Yes, an activity based application doesn't have to derive an activity from the library's activity. The application simply uses the library's activity verbatim, unmodified.
Yes, I can get a way with a minimalistic approach, in which I subclass the activity only if I need to modify the library's activity core behavior.
I have been able to verify this with an AndroidManifest.xml that is identical in both the library and the application. It would be interesting to see whether some of this redundancy can be eliminated. I will experiment with this and report back.
UPDATE: Sure enough, it is possible to create a perfectly running application in which the only activity is defined in the library and the library's AndroidManifest.xml doesn't have any <application> or <activity>! This is possible if the application's AndroidManifest.xml has them.
You can reference library Activity classes directly from your application AndroidManifest.xml. Just specify the fully qualified name like so android:name="com.example.LibActivity"