My Activity is injected with a number of objects that are initialized
before onCreate is called for the first time.
When my Activity finishes by invoking the finish method, it passes
through onDestroy before returning to the main "OS desktop" window.
I then invoke my application again, and onCreate is again called.
This time though my view remains the same as when finish was initially
called above.
Therefore, I am wondering if RoboGuice re-instantiates the injected
objects again? If not, is there a way for me to do this?
Thanks.
are you saying that these are not re-instantiated then?
when onCreate() is called ex. when you change phone orientation every object are injected once again. But if one of injected object is Singleton, the same instance of object will be injected. "Singleton" works in scope of whole application so the activity lifecycle does not ifluence on signleton objects.
Take a look at the Android activity lifecycle docs.
If onCreate is called by Android then a new instance of your activity was created and any non-singleton components will be instantiated, and all components will be injected by roboguice.
If you only need a single instance of a component you can make it a singleton. Just be cautious of memory use with singletons because they will live for the duration of the application process. So even if an activity has been destroyed but your app process is still running those singletons will be consuming memory.
Roboguice is just a wrapper around guice. If you are interested in pursuing other options for getting instances of classes take a look at Bindings, Scopes and Providers in guice.
Related
I use Dagger2 for android project
I have 2 scopes: ActivityScope and FragmentScope
I read some sample code and they say that define and use ActivityScope so the object will be destroyed with activity lifecycle. And because Activity and Fragment have different lifecycle, so we should have 2 scopes.
My question is:
Do I need to do something to let the code know that when I use ActivityScope, object should be destroyed with the activity lifecycle? Or the code automatically knows that when I build dagger and inject to Activity like this
((DeezFoodzApplication) getApplication()).getAppComponent().inject(this);
Do I need to do something to let the code know that when I use ActivityScope, object should be destroyed with the activity lifecycle?
No. The garbage collector will take care of it (unless you store it in some static variable).
Dagger doesn't know anything but how to create or inject your objects. It does not care about lifecycle, when or where you inject / create your objects, or how you store your components. There is no magic going on, ther is no service running, or some other hack involved. Components are just some java classes that know how to fill those fields in your Activity with objects. That's all.
If you don't store the component, it will be garbae collected after its use.
If you store the component in a field of your Activity / Fragment, it will be garbage collected with the Activity / Fragment after onDestroy
If you store the component in some static variable or pass it somewhere long-living then it will stay there until you null it or that object gets garbage collected. (Also your Activity / Fragment would probably leak) Avoid storing components in static variables.
It's just a normal object like any other, try not to overthink it. You can always check the generated source code or debug it as well.
I am new to android development.
So I have a question about activities.
On Google developer, they say you have to make a class which is inheriting from the class Activity.
So far so good. Now I am thinking an Activity is a class, which leads to my major problem.
So when activity is a class how can it invoke all the live cycle methods.
In Java, I learnt there must be an object of a class to invoke methods and actions. So when activity is not an object but a class, how is this possible.
Kindest regards
Jan
When a user starts your app the android operating system will instantiate an object based on your class which must be a subclass of Activity.
The operating system will use that object and call the lifecycle hooks (e.g. onCreate, onResume, ...) which you implented in your activity subclass when one of the related lifecycle events happens.
Here it is clearly mentioned under CREATING AN ACTIVITY header, that system calls the callback methods, based on which event has occurred. Suppose user is interacting with your activity, then using the object created by the OS for that activity, all the callback methods will be executed. Please refer.
My Android app has multiple activities. The MainActivity constructs a Dagger2 component in its onCreate() method and assigns it to a static variable so any class can call the static method MainActivity.getDaggerComponent() to then inject itself with dependencies.
The problem I'm discovering is that when I start up my VideoPlayerActivity, the MainActivity object sometimes gets its onPause() invoked. If this happens, the static component variable gets set to null. At a later point, VideoPlayerActivity needs to inject its dependencies, but there is no component so things blow up.
How does one ensure that a Dagger2 component is available at all times for all activities?
Initialize Dagger component in Application class or just statically. It might be that you're doing a very wrong thing trying to use dependencies of one Activity in another Activity. This might create memory leaks and in particular sounds like a design problem. What if your first Activity was already destroyed? Who will free up the Dagger instance? Why graph belongs to first Activity and not to the second one? What if user will enter your app from the second Activity - then first one won't be even initialized. And so on, and so on.
If you still need Activity instance, then you should use Activity specific component within the Activity and move everything else in global (Application wide) component.
I simple question but maybe a complex content. For example, I have this classes:
ActivityA.class
ActivityB.class
ActivityC.class
Singleton.class
Singleton is a singleton class pattern, for example:
public class Singleton {
static Singleton instance = new Singleton();
private Singleton();
List<HeavyObject> listaObjects;
}
I use this Singleton in any context (Activity).
My question is: Can Android release this class in any moment without release the current Activity? i.e., I'm watching Activity B, can Android destroy (release) my class Singleton or are the classes only unloaded when all the app is released?
Or maybe when an Activity is destroyed, because the classes are in the context of the Activities?
If there are no outstanding references to Singleton, as in any references are null, the garbage collection mechanism will destroy it once it does its rounds. This means that it will most likely be destroyed but not instantaneously once all references are null.
However, if even one Activity is using Singleton, it won't be released unless that Activity is destroyed
I'm assuming your Singleton.instance is in fact a static field (otherwise your example doesn't make much sense).
In that case, your Singleton lifetime will be tied to the lifetime of your application's process. The process lifetime starts when the first Activity of the process is invoked (or a call made to a service that the process implements.)
The process may be destroyed at any time after all the processes Activity's are stopped.
So if you have an Activity that is not stopped, the instance will remain. But if all the Activity's in your process are stopped, the process can be destroyed at any time. If your Activity gets started again, if the process has been destroyed in the meantime, the instance will have to be created again.
This is not my code. I just arrived at this site and am doing code review.
They have a class which is an extension of Dialog.
It has been defined as a singleton.
On the first call the context is passed to the getInstance method.
It instantiates the class passing the received context to the "super" within the constructor.
Then it saves it - same as in any singleton.
It then displays the dialog. After user interaction it starts a new activity and closes the dialog via "closeDialog".
However, it is still alive since the static holder for the instance is still there.
Will this then hold on to the activity that created it (and was passed on the "getInstance" call and into the "super()" when creating the instance)?
They keep the instance alive because they then use it for calls from other places and have values that need to be carried over.
I know this code stinks but I want to be sure that it does leak memory (the first activity) before I make them re-write it (or re-write it myself - which is more likely).
Yes it could. If the code starts other activities, then yes. If only the one activity is ever used, then most likely not. The reason being, dialogs must be instantiated with an activities context (it'll crash with the Application context). If that activity is set to be destroyed, garbage collection won't clean it up until all references to it are destroyed. If this singleton dialog lives outside the activity (which should be the case), then it'll continue referencing the activity and prevent GC from cleaning it up. You can read more about leaking contexts here: Avoiding memory leaks
As you stated the code is bad, and using a singleton dialog like that is just plain wrong (whether it leaks or not). There are better ways of maintaining data between states.
Instead of creating and holding Dialog inside Singleton class, build the dialog in that Singleton class but return Dialog instance to the caller class. So calling Activity will be responsible for dismissing Dialog and i believe there will not be memory leak.