Re: [android-developers] Re: AsyncTask and screen rotation
How do you something like this:
Heres my onCreate of the parent activity:
protected void onCreate(Bundle savedInstanceState) {
//set theme first for showing correct header
setTheme(getThemeId());
super.onCreate(savedInstanceState);
themeId=getThemeId();
//in case the screen will have a header
if(getThemeId()!=R.style.CustomThemeNoHeader){
requestWindowFeature(Window.FEATURE_CUSTOM_TITLE);
setContentView(getLayoutId());
getWindow().setFeatureInt(Window.FEATURE_CUSTOM_TITLE,
R.layout.custom_window_title);
//set text header
((TextView)findViewById(R.id.header_title)).setText(getWindowTitle());
progressRefreshState(getProgressBarstate());
}else
{
setContentView(getLayoutId());
}
//execute subactivity logic
initActivity();
}
And here's the onConfigurationChanged:
public void onConfigurationChanged(Configuration newConfig) {
super.onConfigurationChanged(newConfig);
ImageView header = (ImageView) this.findViewById(R.id.header);
LinearLayout container=(LinearLayout)findViewById(R.id.layout);
if(header!=null)
header.setImageDrawable(getResources().getDrawable(R.drawable.top_green_header_image));
//setContentView(getLayoutId())
if (newConfig.orientation==Configuration.ORIENTATION_LANDSCAPE) {
container.setOrientation(LinearLayout.HORIZONTAL);
}
else {
container.setOrientation(LinearLayout.VERTICAL);
}
}
The linearlayout variable is the id i gave to the xml linearlaouts for the
full screen but its not working correctly like if restart the activity
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: AsyncTask and screen rotation
That should work, so long as MyAsyncTask is a static inner class or a
regular standalone public class (not a non-static inner class). See:
http://github.com/commonsguy/cw-android/tree/master/Rotation/RotationAsync/
On Sun, Sep 12, 2010 at 12:47 PM, davemac davemac...@gmail.com wrote:
So we could use something as simple as the following?
�...@override
public Object onRetainNonConfigurationInstance() {
return myAsyncTask;
}
And in onCreate():
if( (myAsyncTask =
(MyAsyncTask)getLastNonConfigurationInstance()) != null)
myAsyncTask.setContext(this); // Give my AsyncTask the new
Activity reference
I added a setContext() method to MyAsyncTask which resets a local
member to be used in the on* callbacks to do UI work. I made
MyAsyncTask a completely separate class from my Activity class, and
the constructor requires a Context. This seems to work, and it seems
pretty easy to do. I realize that an AsyncTask has no chance of being
restarted the way a Service does if it comes to an untimely death. But
from the comments in this thread, I'm assuming that my Activity will
get a valid reference to the AsyncTask when it is restarted by a
Configuration Change. Yes?
- dave
On Sep 10, 1:05 pm, Dianne Hackborn hack...@android.com wrote:
On Fri, Sep 10, 2010 at 9:53 AM, Maps.Huge.Info (Maps API Guru)
cor...@gmail.com wrote:
What if that AsyncTask is downloading a file? Interrupting it,
regardless of how nicely done, would be a bad thing wouldn't it?
You don't need to interrupt it. See Mark's option 2. Just don't have it
tied to a specific activity instance.
If you want to have it associated logically with the activity, you can use
onRetainNonInstanceState() to transfer it between instances. (Though this
is intended as an optimization, and if you rely on this then you likely
won't get the proper semantics in other cases -- for example if the user
leaves your app and returns to it later it could easily get killed while in
the background and thus lose the active download. In fact you would also
have this same problem if you use android:configChanges for many of the same
reasons.)
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy
Android Training...At Your Office: http://commonsware.com/training
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: AsyncTask and screen rotation
On Sun, Sep 12, 2010 at 2:26 PM, Eric Mill kproject...@gmail.com wrote: Why wouldn't that work if it's a non-static inner class? Dave's solution is basically what I do, with the AsyncTask being a private (non-static) inner class of the Activity that uses it. Store it across screen flips, and then if it's present in onCreate, feed it the new context. Oh, technically, it'll work, but the inner class will then *also* hold an *implicit* reference to the old activity, which you don't want, as you'll leak memory. Since you're not using the implicit reference -- replacing it with the explicit one -- you want to use a static inner class. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training...At Your Office: http://commonsware.com/training -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: AsyncTask and screen rotation
Note that using android:process on a Service doesn't change its semantics w.r.t. its main thread. No matter what process it is running in, the lifecycle callbacks happen on that process's main thread, and you don't want to block the main thread. Running the service in a process that doesn't have UI may make the problem less visible, but it is still there. For example, the system will at various points ask your process to do something -- to call your service's onStart() or to dispatch a broadcast or various other things -- and if it isn't responsive to that then it will be considered not responding and dealt with. For stuff that isn't related to UI, this is just a little different: the timeout is a bit longer (currently 10s) and if an ANR does happen on user builds the process will be silently killed rather than annoying the user. On Sun, Sep 12, 2010 at 5:23 PM, Lance Nanek lna...@gmail.com wrote: The non-default situation I was thinking of was there not being anything like android:process=:remote on the service declaration in the manifest. Without any specific settings to prevent it like that one, setting an alarm for a PendingIntent from PendingIntent#getService will start the service on the same main/UI thread that the activities in the app run on. On Sep 12, 6:29 pm, Indicator Veritatis mej1...@yahoo.com wrote: But just as you say, that is by -default- that it is on the same process and thread. Now does anyone actually use it with that same process being an Activity? Often (though not always), it is launched by an Alarm, not by the main process hosting the UI thread in the first place. Then it is the Service that sends messages to the Activity that currently has the UI. Now since the whole purpose of AsyncTask is to provide communication and coordination between a UI thread and a worker thread (more conveniently than with java.lang.thread), it might make sense to use AsyncTask in a Service only if the Service itself has a UI thread. But although the docs you mention admit to this possibility, I am having trouble seeing why that would ever be good design. But knowing this group, if there are any such, someone will pop up out of the woodwork and show us:) On Sep 11, 2:36 am, Lance Nanek lna...@gmail.com wrote: peculiar problems in the way the classes are designed. Service by definition is already in the background, it HAS no UI thread, so why Services, by default, run in the same on process and on the main/UI thread. http://developer.android.com/reference/android/app/Service.html Note that services, like other application objects, run in the main thread of their hosting process. This means that, if your service is going to do any CPU intensive (such as MP3 playback) or blocking (such as networking) operations, it should spawn its own thread in which to do that work. On Sep 11, 4:55 am, Indicator Veritatis mej1...@yahoo.com wrote: Option 4 certainly sounds like it will work, but it suggests some peculiar problems in the way the classes are designed. Service by definition is already in the background, it HAS no UI thread, so why do I need an AsyncTask there at all? The whole point of the latter is to communicate between UI thread and worker thread. As for documenting what works, I hope Google takes your hint and documents what the right way to do this really is. After all, these are the same people who keep warning us that if it's not documented, then it is subject to change w/o notice. On Sep 10, 10:04 am, Mark Murphy mmur...@commonsware.com wrote: On Fri, Sep 10, 2010 at 12:46 PM, Romain Guy romain...@android.com wrote: Option #1 is a lot more intrusive. You lose the ability to automatically switch layouts, drawables, etc. Worst-case scenario: Step #1: Take your UI setup that is in onCreate() and move it to a separate method (e.g., setupViews()) Step #2: Call setupViews() from onCreate() Step #3: Call setupViews() from onConfigurationChanged() Done. ~4 lines of code. And it's the exact same code path that a destroy/recreate will go down, so it's not like this adds unusual performance overhead. There are certain circumstances where this may not work (e.g., GLSurfaceView and a game), but you needed to do extra work for those cases, anyway, to handle the destroy/recreate cycle. Saving and restoring an AsyncTask is not difficult. No, it's not. The question is: is it reliable? None of the AsyncTask documentation (class, article, etc.) covers this case. It *appears* that you can write an AsyncTask such that onPostExecute() or onProgressUpdate() will not be called in the middle of the activity transition. However, that's not documented and hence not guaranteed, and so while I'll describe a pattern that seems to work, I personally don't trust it any
Re: [android-developers] Re: AsyncTask and screen rotation
11.09.2010 12:55, Indicator Veritatis пишет: Option 4 certainly sounds like it will work, but it suggests some peculiar problems in the way the classes are designed. Service by definition is already in the background, it HAS no UI thread, so why do I need an AsyncTask there at all? The whole point of the latter is to communicate between UI thread and worker thread. A Service runs on the UI thread by default, so some kind of mechanism to push work to a background thread is still required. It can be a WakefulIntentService, or, just as easily, an AsyncTask (I imagine it takes care of acquiring a wake lock). It seems to me (and that's just my opinion) that onRetainNonConfigurationInstance / getLastNonConfigurationInstance is probably the easiest way for small, one-at-a-time async tasks, where UI feedback is supposed to be immediate. These two methods use plain Java objects, don't require serialization or parceling, so they are a good fit. The only issue is - switching UI references. OnRetail... can null them out before storing the task in a configuration object, and onStart / getLast... can store new UI references in the task. The task would also need to keep most recent progress state values, to be displayed in the newly created activity. -- Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: AsyncTask and screen rotation
On Sat, Sep 11, 2010 at 6:10 AM, Kostya Vasilyev kmans...@gmail.com wrote: It seems to me (and that's just my opinion) that onRetainNonConfigurationInstance / getLastNonConfigurationInstance is probably the easiest way for small, one-at-a-time async tasks, where UI feedback is supposed to be immediate. These two methods use plain Java objects, don't require serialization or parceling, so they are a good fit. The only issue is - switching UI references. OnRetail... can null them out before storing the task in a configuration object, and onStart / getLast... can store new UI references in the task. Given Ms. Hackborn's explanation of the message flow, I would agree with your assessment. Without that guarantee, though, I couldn't trust this model. The task would also need to keep most recent progress state values, to be displayed in the newly created activity. Actually, that shouldn't be needed. doInBackground() should be able to just call publishProgress(). Those messages will just get queued up until the new activity is ready. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: AsyncTask and screen rotation
11.09.2010 15:05, Mark Murphy пишет: The task would also need to keep most recent progress state values, to be displayed in the newly created activity. Actually, that shouldn't be needed. doInBackground() should be able to just call publishProgress(). Those messages will just get queued up until the new activity is ready. Provided that the worker thread publishes updates sufficiently often - yes. -- Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: AsyncTask and screen rotation
Option #1 is a lot more intrusive. You lose the ability to automatically switch layouts, drawables, etc. It might be fine now but it might come back to bite you in the future. It should always be your last resort. Saving and restoring an AsyncTask is not difficult. On Fri, Sep 10, 2010 at 8:56 AM, Bret Foreman bret.fore...@gmail.com wrote: Yeah, Mark's option 1 looks like the best approach for my application. Android should provide more infrastructure for this sort of thing because async web services are becoming almost universal and they always require something like this when they interact with the UI. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: AsyncTask and screen rotation
On Fri, Sep 10, 2010 at 9:46 AM, Romain Guy romain...@android.com wrote: Option #1 is a lot more intrusive. You lose the ability to automatically switch layouts, drawables, etc. It might be fine now but it might come back to bite you in the future. It should always be your last resort. Saving and restoring an AsyncTask is not difficult. For example, I was just answering a StackOverflow question where someone's app was breaking when the device was inserted into a dock, because in 2.2 there is a new dock configuration that changes at that point. You should *always* write your app to work correctly across a destroy/create. android:configChanges is only for optimization of certain very special cases; it is not an excuse to have a broken app. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: AsyncTask and screen rotation
On Fri, Sep 10, 2010 at 12:46 PM, Romain Guy romain...@android.com wrote: Option #1 is a lot more intrusive. You lose the ability to automatically switch layouts, drawables, etc. Worst-case scenario: Step #1: Take your UI setup that is in onCreate() and move it to a separate method (e.g., setupViews()) Step #2: Call setupViews() from onCreate() Step #3: Call setupViews() from onConfigurationChanged() Done. ~4 lines of code. And it's the exact same code path that a destroy/recreate will go down, so it's not like this adds unusual performance overhead. There are certain circumstances where this may not work (e.g., GLSurfaceView and a game), but you needed to do extra work for those cases, anyway, to handle the destroy/recreate cycle. Saving and restoring an AsyncTask is not difficult. No, it's not. The question is: is it reliable? None of the AsyncTask documentation (class, article, etc.) covers this case. It *appears* that you can write an AsyncTask such that onPostExecute() or onProgressUpdate() will not be called in the middle of the activity transition. However, that's not documented and hence not guaranteed, and so while I'll describe a pattern that seems to work, I personally don't trust it any further than I can throw your large Froyo lawn ornament. If somebody could give us the recipe that is guaranteed to work (i.e., works today, and is going to work in Android 2.3/3.0/Turbo System 5000), that'd be *wonderful*. Actually, I lied earlier. I'd choose Option #4: Option #4: Don't do the AsyncTask in an activity. Use a Service and have it do the AsyncTask, or use an IntentService if the sole purpose of the service is to do stuff in a background thread. In particular, an IntentService would be good for a download that you want to happen regardless of what may go on with an activity (e.g., Android Market downloading an APK), and so you don't need to worry about canceling it. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in London: http://skillsmatter.com/go/os-mobile-server -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: AsyncTask and screen rotation
On Fri, Sep 10, 2010 at 9:53 AM, Maps.Huge.Info (Maps API Guru) cor...@gmail.com wrote: What if that AsyncTask is downloading a file? Interrupting it, regardless of how nicely done, would be a bad thing wouldn't it? You don't need to interrupt it. See Mark's option 2. Just don't have it tied to a specific activity instance. If you want to have it associated logically with the activity, you can use onRetainNonInstanceState() to transfer it between instances. (Though this is intended as an optimization, and if you rely on this then you likely won't get the proper semantics in other cases -- for example if the user leaves your app and returns to it later it could easily get killed while in the background and thus lose the active download. In fact you would also have this same problem if you use android:configChanges for many of the same reasons.) -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: AsyncTask and screen rotation
On Fri, Sep 10, 2010 at 10:04 AM, Mark Murphy mmur...@commonsware.comwrote: Worst-case scenario: Step #1: Take your UI setup that is in onCreate() and move it to a separate method (e.g., setupViews()) Step #2: Call setupViews() from onCreate() Step #3: Call setupViews() from onConfigurationChanged() Done. ~4 lines of code. And it's the exact same code path that a destroy/recreate will go down, so it's not like this adds unusual performance overhead. There are certain circumstances where this may not work (e.g., GLSurfaceView and a game), but you needed to do extra work for those cases, anyway, to handle the destroy/recreate cycle. Except if you are *relying* on this for your semantics then your code is not correct. Saving and restoring an AsyncTask is not difficult. No, it's not. The question is: is it reliable? Yes it is. If it isn't documented, I'll make sure it is: we guarantee that no messages will be processed between onRetainNonConfigurationInstance() to the following onCreate(). Option #4: Don't do the AsyncTask in an activity. Use a Service and have it do the AsyncTask, or use an IntentService if the sole purpose of the service is to do stuff in a background thread. In particular, an IntentService would be good for a download that you want to happen regardless of what may go on with an activity (e.g., Android Market downloading an APK), and so you don't need to worry about canceling it. Yep in many cases this is actually what you want. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: AsyncTask and screen rotation
On Fri, Sep 10, 2010 at 1:08 PM, Dianne Hackborn hack...@android.com wrote: Yes it is. If it isn't documented, I'll make sure it is: we guarantee that no messages will be processed between onRetainNonConfigurationInstance() to the following onCreate(). Oh, that is absolutely fantastic to hear. I'd think it should be documented either on that method or here: http://developer.android.com/guide/topics/resources/runtime-changes.html Thankyouthankyouthankyou! :-) -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in London: http://skillsmatter.com/go/os-mobile-server -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: AsyncTask and screen rotation
Step #1: Take your UI setup that is in onCreate() and move it to a separate method (e.g., setupViews()) Step #2: Call setupViews() from onCreate() Step #3: Call setupViews() from onConfigurationChanged() Done. ~4 lines of code. Except you would have to make sure to destroy/recreate anything your Activity might have a reference to that would need a new configuration. Of course you can make it work, but you can easily break your solution in subtle ways. The only reason to handle orientation change yourself is if the destroy/create process is very heavy (webpage loading for instance.) And it's the exact same code path that a destroy/recreate will go down, so it's not like this adds unusual performance overhead. No it is not. You are keeping the same Activity instance and any state associated with it. It is very different. -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
