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
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 rot
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
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
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 Serv
On Sun, Sep 12, 2010 at 2:26 PM, Eric Mill 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 prese
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 1
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 wrote:
> So we could use something as s
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.setConte
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 u
On Sat, Sep 11, 2010 at 6:10 AM, Kostya Vasilyev 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.
>
> T
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 poi
> 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 serv
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 th
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 wa
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
happenin
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 wrote:
> On Fri, Sep 10, 2010 at 1:08 PM, Dian
> 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
On Fri, Sep 10, 2010 at 1:08 PM, Dianne Hackborn 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 s
On Fri, Sep 10, 2010 at 10:04 AM, Mark Murphy 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()
>
>
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 i
On Fri, Sep 10, 2010 at 12:46 PM, Romain Guy 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:
> 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
On Fri, Sep 10, 2010 at 9:46 AM, Romain Guy 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
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,
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 messag
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
--
You received this message because you are subscribed to the Google
Groups "Android
27 matches
Mail list logo
