The question is more conceptual than coding-related.
I have an app with Activity A and B.
I call an AsyncTask from Activity A, while the call is being made, I don't want to block the user showing the progressdialog, so my user can freely move around the application without getting bored of waiting.
Now, the query is AsyncTask or lets say a Service is being called from Activity A which is responsible for downloading some kind of data from the server. While the call is being made, the user has changed the Activity and Activity A has gone to background.
Now, while the user is freely moving around the application, he just wants to come back to Activity A to check the download status,(which is something lets say I set some data to my TextView).
Now the question is, once the download is over , while my Activity A is still in background, my UI should be updated while Activity is still in background. This way the user feels he gets the data before he switches to Activity A.
Is this possible, if so how?
Summarizing my question, can I update the UI of an Activity while it is still in background with the Asynctask or Service which the Activity invoked to fetch data from server.
One post suggested that ideally I need to update the **UI in onResume(). My question is, is this the only approach?
once the download is over , while my Activity A is still in background, my UI should be updated while Activity is still in background. This way the user feels he gets the data before he switches to Activity A.
It isn't possible. You see, the Activity has to pass through the onCreate() and onResume() callbacks for the UI to be changed.
Also, you should be using a bound Service to update the Activity when it returns to the foreground.
onResume() would be the best approach. You may save the changes in a SharedPreferenes or Pass the data using Intent and show the changes before the UI is visible.
Another approach would be running a service and checking if the activity is visible. If its visible immediately update the UI or wait until user visits the activity. To check if the activity is currently visible see here,
How to check if activity is in foreground or in visible background?
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 app that uses webscockets, and when the app goes to backgroud i need after a x amount of seconds to disconnect the websckets and change the current activity to the lobby activity.
I have a singleton that extends Application and implements
ActivityLifecycleCallbacks, each activity is registered on registerActivityLifecycleCallbacks.
The problem is that when the app is in background and i call the lobby activity, the new activity calls all Activity Lifecycle Callbacks, like onActivityCreated, onActivityStarted, onActivityResumed and then onActivityStoped, and that behavior forces my to do a bunch of checks to see if the lobby activity is called on background or on foreground.
Is there a way to do this without that behavior, like to put the activity on hold ready to start on app resume?
And i prefer not to call the new activity when the app resumes it feels jerky, because you see the last open activity and then you see the change to the lobby activity.
Sorry for the long question.
You should use a Service to achieve that you want
Visit http://developer.android.com/guide/topics/fundamentals/services.html
Hope this will help :)
I have an App with 2 activities A -> B. From B the user can update data being displayed by A, so I want A to show fresh data when the user navigates back (actually not so simple, some network involved so data can be updated at any time).
The activities are listening to ddbb changes so the views can be updated when data changes. Problem is data can change while activities are in background, so I am not sure when and how i should listen for changes. I can think of two approaches:
Listen for changes during the whole Activity lifecycle (onCreate - onDestroy) and just update the views when the data changes. This will update views from background activities.
Listen for changes only when the Activity is being active or displayed (between onStart/onStop or onResume/onPause) and force a view update every time the activity comes to the foreground (since changes might have happened while activity wasn't listening).
Mixed approaches; keep the listeners the whole lifecycle but only update views when activity comes to foreground.
Im not sure which is the correct way to handle data observing while in background.
Option 2 sounds more reasonable, but having to update the views when the activity comes to foreground may lead to UI lag right when the user starts interacting with the activity.
Option 1 will cause a lot of updates every time data is updated.
Thoughts on this?
You can choose any of the three options that suits your particular use case. Though I will say that the conventional use is with start/stop. onStart says that the activity is visible to the user in some way (either fully or partially) and onStop says that the activity is definitely not visible. So if you don't care to update the UI while the activity is not showing at all, use these lifecycle states.
You just may need to be prepared to capture data that you may have missed while the activity was stopped before it gets started again (for example, if the user pressed the home button, then came back to the activity via the task switcher. So performing your query again and rebuilding the contents of views from scratch may be necessary.
I've got the following problem. In my app I'm loading data in an AsyncTask. The problem is, when the user now clicks on the icon to open the Navigation Drawer and opens up another fragment the app crashes. When the AsyncTask is finished the app doesn't crash. The problem that is encountering is, that when I switch the fragment (The fragments are always the same, just with another content dependent on the NavigationDrawer Item click) the app crashes.
I guess the problem is, that the async task isn't finished, I'm calling the same fragment again want to display different data.
So what would be my approach to handle this? Use for every different view a different fragment? I thought using the same fragment every time is much easier, since it's just displaying different data but the structure, layout etc. is all the same. Just the data that it gets is different.
I also thought about somehow "blocking" the user from doing any other actions while the asynctask but still show him that the app is processing. But that would be not the definition of an AsyncTask.
How would you approach it? Use different fragments for every different display? Or how? Block somehow? If a user clicks on an item of the navigation drawer the asynctask needs to stop all its actions (if some are done) and then restart doing all the actions. Is there a way to do it?
Please note that the fragment where the async is executed and the activity where the fragments are called are in two different files
You can either block the screen with a loading screen (not that good UX wise...) or you could cancel the asynctask when you change the fragment, in the destroy or detach method.
You didnt show the errors, but I would guess that the app crashes because you are trying to acess something in the asynctask onPostExecute method and it is no longer available...
I guess that it crashes because your AsyncTask is sending data to a class instance that doens't exist.You should change the Class that receives callbacks from asynctask. Anyway i can't give you a better answer till i will see your real code of AsyncTask ( at least onPostExecute() and onProgressUpdate())
use intent service to do that ask task means call ask task in a intent service that one is capable to handle background task without hang UI
I want to build a "smart downloader" that can download images in background (using AsyncTask).
There are two Activity, A and B. In activity A, I can choose the image list I want to view, (first download if not have been download once). Then enter activity B, here I launch a asynctask to download the image in background and in the UI thread, show the image to the user.
there are some large list that may take minutes to finish downloading. One tricky problem is when the asynctask is still downloading the list, the user may exit activity B (come back to activity A. (I know the asyntask will still continue working even if activity B is destroyed).
But if at this time user choose another list to view (then enter activity B). I want to stop the previous task for a while, began to downloading the new list first, and then the old list.
My thoughts to do that is retrieve the previous asynctask and modify the downloading order. But I don't know how to retrieve the asynctask, I have search some questions about recreate asynctask, but they are all about after re-configuration (like rotate the screen). is there a way to retrieve the background working asynctask, after i destroy the activity and recreate it.
Thanks!
Once you destroy an Activity, the AsyncTask is gone. For this reason, AsyncTasks are not the optimum solution if you want to avoid running the background operation from scratch.
I think you should structure your app to download images using an IntentService. In activity A, choose the image list. Once it's chosen, fire off an IntentService to download the images. Once the IntentService is done, it can notify the user that the operation is complete or send a local broadcast message back to the activity. In either case, even if the user has navigated away from the activity, the work hasn't disappeared. If the activity was destroyed, you can figure out if the download is done, and if so, display the images. If it's not done, you can put up an activity indicator.