I am maintaining a simple Android kotlin app that only has one MainActivity.
The app has a lot of images. We want to reload the data and images when user navigate away and then return to our app, this works so far:
override fun onResume() {
super.onResume()
tryToLoadDataAgainAndReloadAlotOfImageViews()
}
However this produces one unpleasant side effect, for example:
User launch the app
onResume fired, we load data and refresh all images (corrrect)
App shows permission dialog to grant GPS locations
User click accept
permission dialog dismisses
onResume fired again, all data reloaded and images reloaded again.
This will looks like a glitch as all images are reloaded twice in a short period of time.
I understand that I may set booleans here and there before showing permission dialogs to resolve this, but it feels like a hack and possibly buggy code.
Is there any elegant way to resolve this? For example, detecting onResume is coming from another app, or coming from internal permissions dialogs?
We want to reload the data and images when user navigate away and then return to our app
What do you mean by this exactly? Are you talking about the app disappearing from the screen? (e.g. the user switches to another app, or hits the home button, or turns off the screen.) If so, do your refreshing in onStart instead of onResume, then it'll only fire when the app becomes visible again.
But if you want to handle things like multi-window mode, where your app is visible but might not have focus, then you'll need to look into detecting that when your app hits onPause, and maybe storing a flag onResume can check.
Basically Android's Activity and Fragment lifecycles have a couple of paired callbacks, onPause/onResume and onStop/onStart.
When your app is no longer in the foreground, but still visible, it moves to the PAUSED state. If it remains visible, but then moves to the foreground, it moves from PAUSED to RESUMED by calling onResume. This is what's happening with your dialog - because it's displayed over your Activity, the Activity is paused until the dialog is dismissed, at which point it calls onResume. So what's happening is by design!
But if your app is becoming invisible (i.e. it's not on the screen anymore) then it first moves to the PAUSED state (if it's not already), and then it moves to STOPPED and you get the onStop callback. When it returns to the foreground, onStart will be called, followed by onResume. (This is also what happens when the Activity/Fragment is (re)created of course!)
So you need to handle things in the appropriate lifecycle callback. It sounds like your needs are better met by having this stuff handled in onStart, since that only gets called when the Activity/Fragment appears. onResume can be called more often, since it's possible for the component to enter the PAUSED state (onResume is called when it's "unpaused") without moving to the STOPPED state - like with dialogs.
Like I said, if you want to handle multi-window mode that's more complicated, and the lifecycle behaviour depends on API level, so you'll have to look into that!
You can use the isFinishing method to check if the activity is in the process of finishing before calling tryToLoadDataAgainAndReloadAlotOfImageViews() in onResume()
try using Glide.
dependencies :
//Glide
implementation("com.github.bumptech.glide:glide:4.12.0")
kapt("com.github.bumptech.glide:compiler:4.12.0")
As per the official documentation
Glide is a fast and efficient open source media management and image loading framework for Android that wraps media decoding, memory and disk caching, and resource pooling into a simple and easy to use interface.
Related
When a user enters an activity on my app I want to perform some logic during onStart and possibly launch a second activity before letting the user see the first activity (think of this as a pin protected activity)
I have a small issue where the contents of the first activity are shown for a second before the second activity is started. This happens when the user uses the home button to get out and in to the app. Is there a way to prevent the first activity to be visible at all before performing the logic validation?
This is more of a "design" solution to your problem and not clear if it'll work for you. I had something similar in the app I'm working on. What I did instead, was to create an interstitial Activity that resembled the same starting state (i.e. not yet completely loaded) of the Activity (Pin-protected Activity in your case) that is about to be started. Once I'd made my appropriate decision about whether or not I could go on, I just navigated to that initial Activity. In your case, I could see you making the decision on this interstitial Activity, and then navigating to the Pin-protected Activity or to the other one if conditions were not met properly.
The only downside to this approach is that the app does a quick flash with the additional Activity, but I think the increased separation of logic is worth it.
I have a MainActivity and a second Activity which has an EditText. I want that the content of EditText always gets saved. However I don't want a EditTextChangedListener which writes a file after 1 char has changed.
What is a good solution? I thought about onPause or onBackPressed.
What about the home button? I think the app remains open, so is there any need to save? And what about other interrupts like phone calls? Does onPause catch all that?
Thank you.
Yes onPause gets called whenever your app gets interrupted or goes to background check Activity life cycle
A good solution is to include such logic in the onPause() method. It will always be called in all situations. This is what the developer documentation says:
you should use the onPause() method to write any persistent data (such as user edits) to storage.
One thing you should keep in mind is that this method may be called more frequently than desired, for example, when your screen light goes off (some ppl have 15sec screen light timeouts). So, you should not put in too many expensive operations inside there.
As for pressing of home button, it is recommended that you save the data (at onPause()). The reason is that your activity is in the background but it may get destroyed. The system may destroy the activity if it needs to reclaim the memory. (For example you start too any other apps afterwards and put them all in the background) From the documentation:
Stopped: The activity is completely obscured by another activity (the
activity is now in the "background"). A stopped activity is also still
alive (the Activity object is retained in memory, it maintains all
state and member information, but is not attached to the window
manager). However, it is no longer visible to the user and it can be
killed by the system when memory is needed elsewhere.
No. The correct answer here is to listen for the "return" key event. That signifies that the user has completed input to the field, and trigger the save of the field contents to the file. It's useful in many other circumstances too.
See this answer: Android Use Done button on Keyboard to click button
Peter.
I've got an app that is complete, apart from the lifecycle that, guiltily, I left as last.
Things seem to work good in all cases, but one:
When I pause the app by pressing the power button, it correctly pauses and restarts when resuming.
When I rotate the screen it correctly resizes.
When I pause AND THEN rotate the screen, its behaviour is different and the app resets.
Now, obviously it's a problem of my internal code, but to help me in the debugging, I would like to understand what's the difference between the three lifecycles. Or better, if the THIRD example is some how different from the first two.
With debugging I saw that all of three do this (I resemble by mind, I hope to be right):
onSaveInstanceState()
onPause()
onStop()
onStart()
onResume()
Is it right? Or do I miss some lifecycle steps in the third example, above?
Thank you.
Please specify what you mean by the app resets.
When you press the power button, most likely your app stops. That's why you see onStart() being called after stopping (not: pausing) your app.
Given that, is it really the case that the third scenario you describe is a combination of the first two? In other words, how do you pause your app in the third scenario?
Update Regarding your comment: There is a difference between your Activity being stopped and your Activity being destroyed.
Rotation is a configuration change. In this scenario, your Activity is going to be destroyed and re-created. You can handle this case separately if you must (it depends) through the onRetainNonConfigurationInstance() callback and the getLastNonConfigurationInstance() method. Android will call onPause(), onStop(), onRetainNonConfigurationInstance() and onDestroy() in this order, and then continue with onCreate() etc and it will not handle any events in the meantime so that they won't get lost.
Most likely, some of your code is located in the wrong callback, such that in the third scenario, something does not get initialized/attached/... This is really hard to tell without the code and the exception (if it is an exception).
I suggest you proceed as follows.
Complete your understanding of the lifecycle and be precise (creation, start, restart, resume, pause, stop, destroy)
Complete your code to override the other lifecycle callbacks as well with log messages (don't forget to call the super class' callback) and analyze pause, stop, rotation and combinations
Identify the point of the crash
Analyze the life cycle of the objects involvedd in the crash in conjunction with the Activity lifecycle
Or you can post some code and the exception here, of course.
Update 2 I have made a test on an AVD. I have observed the following:
When the AVD is in landscape orientation, and I press the power button, my app receives a configuration change to portrait orientation (presumably because the portrait-orientation-only lock screen takes over). Pressing power again and unlocking the AVD, the app receives a configuration change again back to landscape orientation.
While not solving your issue, it goes to show that code must be carefully placed in the respective callbacks, because in the case above, while being re-created, the Activity will still not be shown.
Drop me a comment if you update your question.
Hi you can check the documentation regarding Managing the Activity life cycles in android .
When orientation changes Activity is re-created.
Add android:configChanges="keyboardHidden|orientation" to your activity in the manifest.
I have an Activity that should only get created once. That is, onCreate can only be called once. If it's called again, I want the Activity to do nothing.
Is it advisable to do the following?
protected void onCreate(Bundle savedInstanceState) {
this.setTheme(android.R.style.Theme_Translucent_NoTitleBar_Fullscreen);
super.onCreate(savedInstanceState);
if(onCreateWasCalledAlreadyBoolean) {
setResult(RESULT_OK);
finish();
return;
}
//Do other stuff here
}
I assume you understand how the activity life cycle works. I mean, you are not trying to avoid something that does not apply here (thinking that onCreate may be called multiple times whenever it just onRestarts etc.).
Technically, it's perfectly fine.
However, you should be worrying more about why you need to call your activity ("A") again if it shouldn't be created at all, if that's what you're thinking.
If you've caught yourself checking if your activity A was already "called" (?), this could mean the previous activity ("B") has a mistake in the logic flow of the app, and that B instead should be checking if it must in fact start that activity A. I mean, if you need to decide if you must call an activity, check before starting it.
I don't think that's applicable if you're restarting the activity (e.g.: go Home, then navigate back), but then again you should be restarting it from where you left (B for what I can tell). You won't be navigating back to A. And you didn't give much detail, so I'd guess this is some kind of splash screen, like evilmage93 said.
If that's indeed some kind of splash screen, I would advise to show it whenever the user navigates back all the way to remove your app from the task stack (contrary to his advice). In other words, whenever the user restarts the app from its "front door".
Although that's ultimately a design decision, I prefer to see the splash screen whenever the app is being loaded ("entered") in the stack for the first time, and it should work fine if you (obviously) finish A before calling B (the splash screen is supposed to finish itself when done, even in its first run). It's a matter of consistency: the same app should behave the same way whenever the user performs the same task (start app from its "front door").
Still, I answered your question covering some general aspects because you asked in such way.
// edited:
Finally, by looking at that onCreateWasCalledAlreadyBoolean I'm afraid you may be trying to reinvent part of the activity life cycle mechanism. In this case, don't: proceed with your regular activity logic because the user expects that behavior. Generally I wouldn't advise people to break the normal loading of an activity just because it was killed and restarted by the system.
I don't see why not. Wouldn't it be simpler to not restart the activity at all though?
What are you worried about NOT being okay? Performance..Uncaught exceptions..Code clarity?
I am trying to detect if my app became active from multi-tasking and display a dialog.
The use-case is something like this: User is using the app -> Hits the home button -> Does something -> User taps on the app again
As expected, the last activity the user was on is being shown.
I want to display a dialog when this happens. I used onRestart() for the same and it works. Only problem is, even when the user goes to some activity in the app and then hits back, the dialog is being displayed.
I went through the activity lifecycle several times, but couldn't figure out the solution. Any ideas?
Well, you can tell the foreground application using the technique outlined in Determining the current foreground application from a background task or service: look for getForegroundApp. You could run a timer that checks periodically to see if the app is foreground, and if its not then set a variable after a suitable delay (to make sure you don't happen to hit it in the wrong order when switching Activities). Clear the variable in onStart, and if onCreate of the rooth Activity is ever called you know that the app just became Active.
I achieved this by setting a flag in Shared Preferences in onStop() and cleared it in onDestroy().
Then I overrided the Back button to clear the flag whenever it is pressed. This solves the problem I had stated.
Now in onRestart(), if the flag is true.... I display the dialog.
I know it is not the most elegant solution but does the job! Hope this helps somebody.