Is it okay or possible to extend the Application class in android twice and have two childs of it in an application? And also why do we need it & what's the purpose of extending it?
Is it okay or possible to extend the Application class in android twice and have two childs of it in an application?
You can only have one registered Application subclass in the android:name attribute of the <application> element. You are welcome to create as many subclasses of Application as you want, but only one will be used. However, you are welcome to have MyApp extend Application, have MyOtherApp extend MyApp, and register MyOtherApp in the manifest.
And also why do we need it
Few apps need it. Quoting the documentation, "There is normally no need to subclass Application".
what's the purpose of extending it?
If you have application logic that needs to be executed every time Android forks a process for you, Application is a common place to trigger that logic. For example, most crash logging libraries (e.g., ACRA) have you configure them in an Application subclass, so that they can handle crashes from everywhere else in your app, for every one of your processes.
You want something like this?
MyApp extends Application
MySecondApp extends MyApp
This is possible. There are several usecases for this. For example define an Application for your App but override it for a specific build type or product flavor (e.g. debug). Or a custom Application for your (Android) Tests:
MyApp extends Application
MyDebugApp extends MyApp
MyTestApp extends MyApp/MyDebugApp
Define each Application Class in the according AndroidManifest:
MyApp => main package
MyDebugApp => debug package
MyTestApp => androidTest package
Yes, it's possible. The reason extend classes is to reuse code written in the parent class and extend its functionality.
Related
I'm trying to realize functionality for login launched activities names. I don't want to add checking in every activity. Short time ago i saw that it's possible to realize something like "activity lifecycle manager" inside application and catch callbacks like activityCreated(...) or activityDestroyed(...). But unfortunately i forgot the exact name of that method/interface(i don't even remember what was that :( ) and i didn't manage to find something similar here.
So, can somebody tell me how can i achieve this?
You can extend the Application class and implement the ActivityLifecycleCallbacks interface:
public class MyApplication extends Application implements ActivityLifecycleCallbacks {
// Various activity callbacks here
}
You can read about the callbacks here.
The above class will need to registered in the <application> tag of your manifest file under android:name:"" property as android:name:"MyApplication".
I am new to volley.I have two classes,AppController Singleton class, and ImageController Singleton class.But in Manifest,it allows only one application name.So how do I solve this?
You can try this way:
Application Class no one:
public class MyApplication extends Application {
}
Application class no two:
public class MyApplication2 extends MyApplication {
}
In your Manifest:
<application
android:name=".MyApplication2"
android:allowBackup="false"
android:icon="#drawable/app_icon"
android:label="#string/app_name"
android:supportsRtl="true"/>
Only the <manifest> and <application> elements are required, they each must be present and can occur only once
According to documentation manifest file with only one application element is valid.
Try to Marge in Single Application Class
First of all, every application should have only one application class that is the concept of MVC in android.
You should remove one application class and do whatever it is doing in another one.
As per your requirement: you have AppController and ImageController application class then remove all the code of ImageController application and merge it in AppController application class. Now use AppController class in manifest.
I'm guessing you are using a Singleton as to have a class that holds your App data for the current session and\or another one for specific stuff (e.g. networking), if so, you have a couple ways of going about that:
Use ONE Application class - you shouldn't have more than one, if so - merge them.
If you insist on having 2 Singleton classes because you want to separate some functionality, you may create 2 Singleton classes, which are NOT your application class.
If you choose option 2, you should initialize(and maybe also control) them from your application class, especially to avoid duplicating a context object (that might lead to a memory leak), but make sure it's really necessary first.
since you tagged your question with the Volley tag, I'm guessing this SO thread about isolating Volley requests might help.
Hope anything here helped!
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.
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"
I'm working on an Android app which has an activity and a widget. This is currently implemented via two classes in two .java files - one for the activity (extending Activity), one for the widget (extending AppWidgetProvider). Nothing out of the ordinary here as far as I'm aware...
However, the widget class code could be a lot simpler if it was to make use of functions and asynctasks defined in the activity class. Duplicating these functions seems like bad design, so I'm wondering how I can structure the app to make them usable?
Can I extend both Activity and AppWidgetProvider somehow? Can I import one in the other?
Thanks!
either make the funcs static, or make a 3rd class to hold these funcs
Move the functions down into a service. Create a Service and you can use context.startService(Intent) from you WigetProvider or from the activity to access the functions.