AsyncTask and screen rotation

5884 views
Skip to first unread message

Bret Foreman

unread,
Sep 10, 2010, 11:13:21 AM9/10/10
to Android Developers
Is there a standard pattern for handling a running AsyncTask with
screen rotation? My AsyncTask runs for about 10 seconds. I could call
AsyncTask.cancel in the Activity's onDestroy method and restart the
task in onCreate but that would waste cycles, bandwidth, and user
time. I'm guessing there is a better way.

Mark Murphy

unread,
Sep 10, 2010, 11:20:09 AM9/10/10
to android-d...@googlegroups.com

Option #1: Don't have Android do the normal destroy/recreate cycle.
Add an android:configChanges attribute to your manifest for this
activity, and override onConfigurationChanged() to fix up your UI.
This keeps the same Activity instance, and so your AsyncTask should be
fairly happy. Here is a project that has this setup, though it does
not use an AsyncTask:

http://github.com/commonsguy/cw-android/tree/master/Rotation/RotationThree/

Option #2: Make the AsyncTask either a public top-level Java class
(not an inner class) or static inner class of the Activity. Manually
associate the Activity with the AsyncTask via a constructor parameter
in your AsyncTask instance. Associate the new Activity instance with
the AsyncTask after the rotation. You can see an example of this
technique here:

http://github.com/commonsguy/cw-android/tree/master/Rotation/RotationAsync/

Option #3: I think droid-fu may have some stuff related to this in
their library.

Personally, I'd use option #1.

--
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

Maps.Huge.Info (Maps API Guru)

unread,
Sep 10, 2010, 11:21:46 AM9/10/10
to Android Developers
You can handle screen rotation yourself or block it from restarting
your app by adding this (along with other code) in the manifest:

android:configChanges="orientation"

Search the docs for that.

-John Coryat

Bret Foreman

unread,
Sep 10, 2010, 11:56:49 AM9/10/10
to Android Developers
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.

Romain Guy

unread,
Sep 10, 2010, 12:46:20 PM9/10/10
to android-d...@googlegroups.com
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.

> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-d...@googlegroups.com
> To unsubscribe from this group, send email to
> android-develop...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>

--
Romain Guy
Android framework engineer
roma...@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

Dianne Hackborn

unread,
Sep 10, 2010, 12:50:08 PM9/10/10
to android-d...@googlegroups.com
On Fri, Sep 10, 2010 at 9:46 AM, Romain Guy <roma...@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
hac...@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.

Maps.Huge.Info (Maps API Guru)

unread,
Sep 10, 2010, 12:53:14 PM9/10/10
to Android Developers
> 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.
>

What if that AsyncTask is downloading a file? Interrupting it,
regardless of how nicely done, would be a bad thing wouldn't it?

-John Coryat

Mark Murphy

unread,
Sep 10, 2010, 1:04:09 PM9/10/10
to android-d...@googlegroups.com
On Fri, Sep 10, 2010 at 12:46 PM, Romain Guy <roma...@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.

Dianne Hackborn

unread,
Sep 10, 2010, 1:05:41 PM9/10/10
to android-d...@googlegroups.com
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
hac...@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.

Dianne Hackborn

unread,
Sep 10, 2010, 1:08:11 PM9/10/10
to android-d...@googlegroups.com
On Fri, Sep 10, 2010 at 10:04 AM, Mark Murphy <mmu...@commonsware.com> wrote:
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
hac...@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.

Mark Murphy

unread,
Sep 10, 2010, 1:13:36 PM9/10/10
to android-d...@googlegroups.com
On Fri, Sep 10, 2010 at 1:08 PM, Dianne Hackborn <hac...@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! :-)

Romain Guy

unread,
Sep 10, 2010, 2:17:21 PM9/10/10
to android-d...@googlegroups.com
> 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.

Message has been deleted

Eric Mill

unread,
Sep 10, 2010, 3:01:45 PM9/10/10
to Android Developers
I eventually made my own best practices for AsyncTasks that survive
screen flips and can even maintain progress dialogs if needed, and
it's all very robust and reasonably clean - but it took a lot of
iteration and investigation.

Storing an AsyncTask is "not hard" if you understand what is
happening, but for people just getting into the Android system,
understanding that screen flips destroy Activity references and create
new ones is not trivial. It's actually really confusing and setting
it all up right is pretty delicate.

At my workplace, I'm porting an Android app over to the Windows Phone
7 platform. Many things about WP7 development are new, some are
frustrating, but there's one notably easy thing about it, which is
this exact problem. Their WebClient class automatically handles
network calls in a background thread, and you can give it a lambda or
named function as a callback to run on the UI thread once it's done.
Survives screen flips just fine, no worries about it being killed. It
Just Works(tm).

I understand that Android is a very different system than WP/
Silverlight, with different considerations that elevate the complexity
of managing all the different fedeated components of an application -
but don't write off managing AsyncTasks as "not hard". It's very hard,
and other systems make it look glaringly so.

-- Eric

On Sep 10, 2:33 pm, Dimitris <dnkou...@gmail.com> wrote:
> Wow thank you, I've been finally waiting for some clarification
> regarding how safe it is when updating the instance of the Activity in
> a task.
>
> This should be well documented and perhaps an example should be
> provided.
>
> On Sep 10, 10:13 am, Mark Murphy <mmur...@commonsware.com> wrote:
>
>
>
> > 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/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy

Bret Foreman

unread,
Sep 10, 2010, 3:36:17 PM9/10/10
to Android Developers
It seems like AsyncTask could be patched up pretty effectively with
attach(String threadTag) and dettach(String threadTag) methods. You
would call dettach with a user-provided tag from your Activity's
onDestroy method and call attach with the same tag. If attach returns
false then you know there was no background thread with that tag and
you start the AsyncTask in your onCreate. If it returns true then you
know that the AsyncTask now knows about the new parent thread and also
know that you don't have to restart the task in you onCreate. Anyone
see any problems with this enhancement?

Indicator Veritatis

unread,
Sep 11, 2010, 4:55:17 AM9/11/10
to Android Developers
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:
> Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy

Lance Nanek

unread,
Sep 11, 2010, 5:36:52 AM9/11/10
to Android Developers
> 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.

Kostya Vasilyev

unread,
Sep 11, 2010, 6:10:08 AM9/11/10
to android-d...@googlegroups.com
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

Mark Murphy

unread,
Sep 11, 2010, 7:05:04 AM9/11/10
to android-d...@googlegroups.com
On Sat, Sep 11, 2010 at 6:10 AM, Kostya Vasilyev <kman...@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.

--

Kostya Vasilyev

unread,
Sep 11, 2010, 10:00:43 AM9/11/10
to android-d...@googlegroups.com
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.

davemac

unread,
Sep 12, 2010, 12:47:12 PM9/12/10
to Android Developers
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

Mark Murphy

unread,
Sep 12, 2010, 1:02:17 PM9/12/10
to android-d...@googlegroups.com
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/

> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-d...@googlegroups.com
> To unsubscribe from this group, send email to
> android-develop...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>

--

Android Training...At Your Office: http://commonsware.com/training

Eric Mill

unread,
Sep 12, 2010, 2:26:25 PM9/12/10
to Android Developers
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.

-- Eric

On Sep 12, 1:02 pm, Mark Murphy <mmur...@commonsware.com> wrote:
> 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/Rotation...
> Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy

Mark Murphy

unread,
Sep 12, 2010, 2:29:33 PM9/12/10
to android-d...@googlegroups.com
On Sun, Sep 12, 2010 at 2:26 PM, Eric Mill <kproj...@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.

--

Indicator Veritatis

unread,
Sep 12, 2010, 6:29:51 PM9/12/10
to Android Developers
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:)

Lance Nanek

unread,
Sep 12, 2010, 8:23:06 PM9/12/10
to Android Developers
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.

Dianne Hackborn

unread,
Sep 12, 2010, 9:58:40 PM9/12/10
to android-d...@googlegroups.com
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.

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-d...@googlegroups.com
To unsubscribe from this group, send email to
android-develop...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en



--
Dianne Hackborn
Android framework engineer
hac...@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.

Bluemercury

unread,
Sep 22, 2011, 10:26:43 AM9/22/11
to android-d...@googlegroups.com
Hi there! CAn you share your code for this combination? Right now im using an async task in my parent activity to launch threads, i also have a custom header with a progressbar(indeterminate) where my threads change its state. Right now this seems to be working, but the problem arises when i rotate the phone. Im trying to use the onConfigurationChanged method to deal with the image on the custom header that is different for the landspace layout, i and i seem to have managed it. The problem is the screen layouts, i cant seem to make them appear like when the activity is recreated again....


Bluemercury

unread,
Sep 22, 2011, 10:34:22 AM9/22/11
to android-d...@googlegroups.com
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....
Reply all
Reply to author
Forward
0 new messages