My app interfaces with a Bluetooth peripheral. When the peripheral wants to shut down, can I clean up the app simply by calling my Activity's own onPause() and onStop() methods? Is the fact that they call the superclass's methods likely to cause any problems?
The idea would be to call finish() after that.
Technically, yes, you can. What you should be asking is "Should I"? Which the answer is no.
Like you've mentioned, since they do call the superclass methods, there is some extra Android OS cleanup magic that happens. It may result in a successful case once in a while, but it's not guaranteed. There is a lot of things that happen in the backround that you don't want to fool with. Don't reinvent the wheel.
If there is code that is ran within the onPause and onStop methods that you would like to use elsewhere, I would create a function called cleanupBluetooth and the onPause and onStop would call and anywhere else it needs to.
If you need to actually call the onPause and onStop methods because you need to stop and halt the activity, you can do that by calling finish() (how to use finish()). The finish() method will call the appropriate Android OS magic that's needed to be called.
You can call them manually, but you shouldn't let Android do it itself when it needs to. If you wish to call those activities, you are likely not really wanting the activity any more, so you can just call finish and then android will call the relevant methods based on the activities life cycle.
You can find more info about the activity life cycle by going here
OnPause() is also a method in your activity and it will likely normal method. It overrides method of activity and you can call it from anywhere in activity and from interface also.
Related
In my android app (written in kotlin) I would like to do some data saving when my activity is destroyed. But I have a problem. I've done researching and found out that onDestroy() and onStop() methods are not guarantied to be called. So practically my activity can be destroyed without calling onDestroy() method which would be disaster for me.
Please, does anyone have some gentle solution for this problem?
Some additional information:
The purpose of overriding onDestroy is if you need to clean up leakable resources, like something that uses native memory or a spawned Thread that is holding onto object references. It will never "become safe" like you suggested in the comments because using it as a hook for saving state is not its purpose. The reason it is not guaranteed to be called is that if the OS is shutting down your application completely, the entire heap of memory for your app is released, in which case it would be redundant to call it.
The majority of apps should never need to override it because most apps don't allocate memory directly, and there are better techniques for handling asynchronous work than spawning Threads directly.
You are right about onDestroy()
do not count on this method being called as a place for saving data!
For saving state you should use onPause(), onSaveInstanceState() or
onStop() - which gets called as soon your Activity is no longer visible to the user.
Can the android lifecycle methods be called manually or if you try that you will get an exception or something like that? If it is possible to call them manually without any problems will they run in order ? i.e. If I call on stop() while the activity is in the foreground, will onPause() run first as it should?
No, it is never safe to manually call any on method - those are meant to be called only by the managing system.
One scenario where an activity does not go through its full life cycle is where there is a requirement to make a decision (may be via an if condition inside onCreate()) and kill the activity immediately by calling Finish() inside the onCreate() method itself. onDestroy() is called after onCreate() when this happens.
This clearly is a deviation from Activity lifecycle. My question is
1) Why is such behavior allowed by Android? Any possible reasons for this?
2) Are there any other ways that this kind of decision making functionality be implemented? Are there any built in facilities like say a widget or background method who does this for the programmer?
Activity is not going through the documented life cycle of onCreate() OnStart() onResume() onPause() onStop() and then onDestroy() is bypassed to make it onCreate() and then onDestroy() without other methods
It is going through the portion of that lifecycle that is appropriate for the situation. Quoting the documentation: "The visible lifetime of an activity happens between the call to onStart() and the call to onStop()". Hence, in situations like this, where the activity is never visible, there is no need to call onStart(), onResume(), onPause(), and onStop().
From a programmer's perspective these kinds of exceptional cases always add to complexity of learning something
These sorts of complexities are commonplace in software development for pretty much any platform and environment.
So, I wanted to know if there was any valid reason behind allowing something like fall to finish() inside onCreate().
Nobody but you knows what you would consider to be "any valid reason".
Most likely, this as an optimization path, to save on CPU time, battery, and possibly some memory, by skipping unnecessary work. Please bear in mind that Android was designed around hardware from a decade ago, where mobile CPUs had ~1% of the processing power of today's devices, let alone devices that may arise in the future.
When you navigate from one activity to another and you don't need the first activity to be living anymore (like a splash screen), you might be calling the following from somewhere in the first activity:
Intent intent = new Intent(FirstActivity.this, SecondActivity.class);
startActivity(intent);
finish();
And if you don't call that finish method and allow that splash screen to be in resumed state. What happens when you press the back button from your SecondActivity? You will see the splash screen again! Imagine how horrible that would be. The intention of this Android framework is not to make you pass through all the lifecycle methods of an Activity, but to provide you whatever facilities that you need in your app. I think this example can help you understand why such behaviour is not allowed by Android.
As understood from other answers for this question, activities are designed in such a way that they need not go through or invoke all the methods in its life cycle.
Common situations where programmers design activities that do not pass though its full life cycle are like, requirement to display a splash screen. Another requirement is for any any task that does not require a UI at all, and finish() is invoked inside the onCreate() method itself. In this case, as the question suggests, onDestroy() is called immediately after onCreate() without invoking other intermediate methods of activity life cycle.
However, I am not sure about android providing any widgets for any such specific tasks, but it always makes sense to perform any such non-UI tasks in a service rather than an activity whenever possible. It is up to the programmer to decide what is apt for a given requirement.
How to avoid calling onCreate method after incoming call or any other idea about this in android version 2.1?
When an activity restarts, it bypasses onCreate() so you don't have worry about that.
That's assuming of course that the Activity wasn't killed because of some lack of memory. Of course, if the process was killed, you'll have to reinitialize everything again anyway, so that's the behavior you'll want.
Check out the Activity lifecyle again:
http://www.androidjavadoc.com/1.0_r1_src/android/app/doc-files/activity_lifecycle.png
I want to execute some functions when the program is exited by hitting the back button.
This is now done by onDestroy() which works in every case but one. When coming back from another activity in some cases on exiting the program, onDestroy is not called.
I know that in theory onDestroy should only be called when Android closes the app due to low memory, but for me, onDestroy works always and only in a very special case it does not.
Using onPause or onStop does not work because I only want to call the function when the program is exited but not when just another activity is called.
So is the last way to catch the back-button-click and call the function there? Or is there any other solution?
Tactically, use onBackPressed().
Strategically, reconsider your architecture. A well-written activity should not care if onDestroy() is called, as it is guaranteed to NOT always be called. For example, Android can terminate your process whenever it wants (e.g., extreme low memory conditions). The fact that you need onDestroy() to work reliably suggests there are problems that should be resolved.