An extended Application class can declare global variables. Are there other reasons?
Introduction:
If we consider an apk file in our mobile, it is comprised of
multiple useful blocks such as, Activitys, Services and
others.
These components do not communicate with each other regularly and
not forget they have their own life cycle. which indicate that
they may be active at one time and inactive the other moment.
Requirements:
Sometimes we may require a scenario where we need to access a
variable and its states across the entire Application regardless of
the Activity the user is using,
An example is that a user might need to access a variable that holds his
personnel information (e.g. name) that has to be accessed across the
Application,
We can use SQLite but creating a Cursor and closing it again and
again is not good on performance,
We could use Intents to pass the data but it's clumsy and activity
itself may not exist at a certain scenario depending on the memory-availability.
Uses of Application Class:
Access to variables across the Application,
You can use the Application to start certain things like analytics
etc. since the application class is started before Activitys or
Servicess are being run,
There is an overridden method called onConfigurationChanged() that is
triggered when the application configuration is changed (horizontal
to vertical & vice-versa),
There is also an event called onLowMemory() that is triggered when
the Android device is low on memory.
Application class is the object that has the full lifecycle of your application. It is your highest layer as an application. example possible usages:
You can add what you need when the application is started by overriding onCreate in the Application class.
store global variables that jump from Activity to Activity. Like Asynctask.
etc
Sometimes you want to store data, like global variables which need to be accessed from multiple Activities - sometimes everywhere within the application. In this case, the Application object will help you.
For example, if you want to get the basic authentication data for each http request, you can implement the methods for authentication data in the application object.
After this,you can get the username and password in any of the activities like this:
MyApplication mApplication = (MyApplication)getApplicationContext();
String username = mApplication.getUsername();
String password = mApplication.getPassword();
And finally, do remember to use the Application object as a singleton object:
public class MyApplication extends Application {
private static MyApplication singleton;
public MyApplication getInstance(){
return singleton;
}
#Override
public void onCreate() {
super.onCreate();
singleton = this;
}
}
For more information, please Click Application Class
Offhand, I can't think of a real scenario in which extending Application is either preferable to another approach or necessary to accomplish something. If you have an expensive, frequently used object you can initialize it in an IntentService when you detect that the object isn't currently present. Application itself runs on the UI thread, while IntentService runs on its own thread.
I prefer to pass data from Activity to Activity with explicit Intents, or use SharedPreferences. There are also ways to pass data from a Fragment to its parent Activity using interfaces.
The Application class is a singleton that you can access from any activity or anywhere else you have a Context object.
You also get a little bit of lifecycle.
You could use the Application's onCreate method to instantiate expensive, but frequently used objects like an analytics helper. Then you can access and use those objects everywhere.
Best use of application class.
Example: Suppose you need to restart your alarm manager on boot completed.
public class BaseJuiceApplication extends Application implements BootListener {
public static BaseJuiceApplication instance = null;
public static Context getInstance() {
if (null == instance) {
instance = new BaseJuiceApplication();
}
return instance;
}
#Override
public void onCreate() {
super.onCreate();
}
#Override
public void onBootCompleted(Context context, Intent intent) {
new PushService().scheduleService(getInstance());
//startToNotify(context);
}
Not an answer but an observation: keep in mind that the data in the extended application object should not be tied to an instance of an activity, as it is possible that you have two instances of the same activity running at the same time (one in the foreground and one not being visible).
For example, you start your activity normally through the launcher, then "minimize" it. You then start another app (ie Tasker) which starts another instance of your activitiy, for example in order to create a shortcut, because your app supports android.intent.action.CREATE_SHORTCUT. If the shortcut is then created and this shortcut-creating invocation of the activity modified the data the application object, then the activity running in the background will start to use this modified application object once it is brought back to the foreground.
I see that this question is missing an answer. I extend Application because I use Bill Pugh Singleton implementation (see reference) and some of my singletons need context. The Application class looks like this:
public class MyApplication extends Application {
private static final String TAG = MyApplication.class.getSimpleName();
private static MyApplication sInstance;
#Contract(pure = true)
#Nullable
public static Context getAppContext() {
return sInstance;
}
#Override
public void onCreate() {
super.onCreate();
Log.d(TAG, "onCreate() called");
sInstance = this;
}
}
And the singletons look like this:
public class DataManager {
private static final String TAG = DataManager.class.getSimpleName();
#Contract(pure = true)
public static DataManager getInstance() {
return InstanceHolder.INSTANCE;
}
private DataManager() {
doStuffRequiringContext(MyApplication.getAppContext());
}
private static final class InstanceHolder {
#SuppressLint("StaticFieldLeak")
private static final DataManager INSTANCE = new DataManager();
}
}
This way I don't need to have a context every time I'm using a singleton and get lazy synchronized initialization with minimal amount of code.
Tip: updating Android Studio singleton template saves a lot of time.
I think you can use the Application class for many things, but they are all tied to your need to do some stuff BEFORE any of your Activities or Services are started.
For instance, in my application I use custom fonts. Instead of calling
Typeface.createFromAsset()
from every Activity to get references for my fonts from the Assets folder (this is bad because it will result in memory leak as you are keeping a reference to assets every time you call that method), I do this from the onCreate() method in my Application class:
private App appInstance;
Typeface quickSandRegular;
...
public void onCreate() {
super.onCreate();
appInstance = this;
quicksandRegular = Typeface.createFromAsset(getApplicationContext().getAssets(),
"fonts/Quicksand-Regular.otf");
...
}
Now, I also have a method defined like this:
public static App getAppInstance() {
return appInstance;
}
and this:
public Typeface getQuickSandRegular() {
return quicksandRegular;
}
So, from anywhere in my application, all I have to do is:
App.getAppInstance().getQuickSandRegular()
Another use for the Application class for me is to check if the device is connected to the Internet BEFORE activities and services that require a connection actually start and take necessary action.
Source: https://github.com/codepath/android_guides/wiki/Understanding-the-Android-Application-Class
In many apps, there's no need to work with an application class directly. However, there are a few acceptable uses of a custom application class:
Specialized tasks that need to run before the creation of your first activity
Global initialization that needs to be shared across all components (crash reporting, persistence)
Static methods for easy access to static immutable data such as a shared network client object
You should never store mutable instance data inside the Application object because if you assume that your data will stay there, your application will inevitably crash at some point with a NullPointerException. The application object is not guaranteed to stay in memory forever, it will get killed. Contrary to popular belief, the app won’t be restarted from scratch. Android will create a new Application object and start the activity where the user was before to give the illusion that the application was never killed in the first place.
To add onto the other answers that state that you might wish store variables in the application scope, for any long-running threads or other objects that need binding to your application where you are NOT using an activity (application is not an activity).. such as not being able to request a binded service.. then binding to the application instance is preferred. The only obvious warning with this approach is that the objects live for as long as the application is alive, so more implicit control over memory is required else you'll encounter memory-related problems like leaks.
Something else you may find useful is that in the order of operations, the application starts first before any activities. In this timeframe, you can prepare any necessary housekeeping that would occur before your first activity if you so desired.
2018-10-19 11:31:55.246 8643-8643/: application created
2018-10-19 11:31:55.630 8643-8643/: activity created
You can access variables to any class without creating objects, if its extended by Application. They can be called globally and their state is maintained till application is not killed.
The use of extending application just make your application sure for any kind of operation that you want throughout your application running period. Now it may be any kind of variables and suppose if you want to fetch some data from server then you can put your asynctask in application so it will fetch each time and continuously, so that you will get a updated data automatically.. Use this link for more knowledge....
http://www.intridea.com/blog/2011/5/24/how-to-use-application-object-of-android
When I try using the code bellow in the onDestroy() method in MainActivity it seams it does not work. What I am doing wrong?
Code:
#Override
protected void onDestroy() {
super.onDestroy();
deleteCacheData();
}
public void deleteCacheData() {
File cacheDir = this.getCacheDir();
File[] files = cacheDir.listFiles();
if (files != null) {
for (File file : files) {
file.delete();
}
}
}
There is two cases with your code:
You can't reliably depends on the case that onDestroy() method will be called. Because there is no such guarantee that it will always be called by the system. Here the excerpt from onDestroy() documentation:
protected void onDestroy ()
Perform any final cleanup before an activity is destroyed. This can happen either because the activity is finishing (someone called finish() on it), or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method.
Note: do not count on this method being called as a place for saving data! For example, if an activity is editing data in a content provider, those edits should be committed in either onPause() or onSaveInstanceState(Bundle), not here. This method is usually implemented to free resources like threads that are associated with an activity, so that a destroyed activity does not leave such things around while the rest of its application is still running. There are situations where the system will simply kill the activity's hosting process without calling this method (or any others) in it, so it should not be used to do things that are intended to remain around after the process goes away.
Derived classes must call through to the super class's implementation of this method. If they do not, an exception will be thrown.
You should call your deleteCacheData() before calling the super.onDestroy(). So, this is incorrect:
#Override
protected void onDestroy() {
super.onDestroy();
deleteCacheData();
}
this is the correct one:
#Override
protected void onDestroy() {
deleteCacheData();
super.onDestroy();
}
If you using Windows OS
Because In your Windows task manaegr one Process is Running when the android studio start or build run or stop named
Java Jmt first stop it then your can directly delete the both build folder not need to clear cache
For comparison, android has a kick-ass logger, where in one line I can do
Log.d("TAG", "Something important is happening here.");
Using eclipse on app engine, I have been doing
private static final Logger LOG = Logger.getLogger(MyClass.class.getName());
…
//inside method
LOG.info("I don’t want to have two lines");
I am moving to android studio, is there a way to do something as cool as the one on android? I imagine I might have to add a dependency to Gradle. Any ideas how I might do this?
Not sure what you're asking. How is your logging dependent on your IDE?
But to answer your question: When using Java on AppEngine you should use java.util.logging. Only java.util.logging logs will go into the Monitoring -> Logs section of your cloud console. We're using slf4j in our projects, which is nice if you have multiple projects with different logging mechanisms but what to use the same syntax.
Actually, you could also use a different logger and write the logs to System.out but i don't recommend it. You should use the facilities App Engine provides.
If you must, you could do something similar as you have in Android Studio. That would probably work with a static import of a Log class and a lot of reflection / stack unwinding to get the logging class name. Since reflection is the opposite of performance, i wouldn't do that.
Unfortunately no, the Log you mention (the cool one) is part of the Android framework and it's independent of your IDE.
You could build your own log "utils" and either extend it or call it statically to reduce logging code.
eg.
public class LogAware {
protected void log(Level level, String message){
Logger.getLogger(this.getClass().getName()).log(level,message);
}
protected void logInfo(String message){
log(Level.INFO,message);
}
protected void logFine(String message){
log(Level.FINE,message);
}
protected void logWarning(String message){
log(Level.WARNING,message);
}
protected void logSevere(String message){
log(Level.SEVERE,message);
}
protected void logException(Exception e){
Logger.getLogger(this.getClass().getName()).log(Level.SEVERE,"Exception Thrown",e);
}
I am trying to set an ImageView in a Google Maps Marker's InfoWindow and have copied the code from this answer pretty exactly, except that my InfoWindowAdapter isn't an anonymous inner class (it's just an inner class of the activity). This was working before, but for some reason it has stopped working - the onSuccess method in the Callback doesn't get called, so the InfoWindow only displays the image the second time it is opened.
Looking at the logs for Picasso I'm getting messages similar to Main canceled [R20]+374ms target got garbage collected. I figured this might be because the Callback is getting gc'd, and tried making it final, and also saving the object in a class field (neither of these worked, although maybe I was doing it wrong?)
What could be happening here, and how can I fix it? Is that target in the error message referring to the Callback, or could it be referring to the marker that gets passed as an argument to the Callback's constructor?
Another odd thing is that sometimes the images are loaded correctly when the InfoWindow is first opened - I'm trying to find out why, but basically I have a lot of markers and whether their images load correctly or not on the first go seems to be inconsistent. There are some (the majority) that never seem to load correctly when the InfoWindow is first opened.
[edit] This was after a bunch of code was merged into that activity, so could it be a memory thing? (there's more processing done now than there was when I wasn't having this problem)
[edit 2] I'm having exactly the same issue with Glide!! Probably garbage collection?
I'm not familiar with that answer, but Target could be gc'ed when you do not hold strong reference to that.
It's because Picasso holds Target instance with weak reference.
You should hold Target instance somewhere outside of Picasso.
Check this issue: https://github.com/square/picasso/issues/352
Solved it, the garbage collection message was actually referencing the ImageView, not the Callback object. Ensuring that the ImageView object isn't garbage collected will correct this (e.g. by saving the ImageView in a field in the class, or even the activity that my class was nested in)
I was doing the same mistake, here was the solution that worked :
My previous code :
picasso.load(url).into(new Target() {
#Override
public void onBitmapLoaded(Bitmap bitmap, Picasso.LoadedFrom from) {
}
#Override
public void onBitmapFailed(Exception e, Drawable errorDrawable) {
}
#Override
public void onPrepareLoad(Drawable placeHolderDrawable) {
}
});
After this I just created a new variable for Target object :
final Target target=new Target() {
#Override
public void onBitmapLoaded(Bitmap bitmap, Picasso.LoadedFrom from) {
imageView.setBackground(new BitmapDrawable(mContext.getResources(), bitmap));
imageView.setScaleType(ImageView.ScaleType.CENTER_CROP);
}
#Override
public void onBitmapFailed(Exception e, Drawable errorDrawable) {
}
#Override
public void onPrepareLoad(Drawable placeHolderDrawable) {
}
};
then I used the target object later in my code :
picasso.load(url).into( target);
I'm going through some memory issues with my Android development.
I was wondering if my actual model would work, and also would like some input on how to do this in a better way:
I need public static final globals
I need public global variables that never gets garbage collected
I need to have an Engine running and never destroy without me calling stop()
MainApplication : Application
public static final Boolean DEBUG = false;
onCreate()
Engine.getEngine().prepare()
MainActivity : Activity
onResume()
Engine.getEngine().start()
onPause()
Engine.getEngine().stop()
Engine
prepare()
MainApplication.DEBUG = true;
start()
LocationManager.requestLocationUpdates()
stop()
LocationManager.removeUpdates()
Engine is a Singleton class, receiving location updates and such.
It is imperative that my Engine class does not get released not the DEBUG variable.
For your "Type 1" constants use a dedicated public class containing public static final T NAME = Val; - declarations.
For the Engine, I'd recommend using a Service.
For your "Type 2" vars, the Service could offer getters or you could make use of SQLite.
I see there's some "Location"-Stuff going on there ... the developer website has some good "best practices" on using the Location Services. Maybe there you'll get some more inspiration.