Hello, I was able to come up with a small framework to handle all types of issues(phone calls/orientation changes etc), and it is behaving pretty well. Thanks Mark/Maher/Dianne.
There is another question I wanted to ask which I thought I might utilize in my framework.(Sorry for a big message again) Basically now I have a mediator object which acts as a decoupling layer between Activity and AsyncTask. Currently, onPostExecute method(of async task) I get hold of the reference of mediator object and do a call back on it, which in-turn gets hold of activity and copy the results to the view components. Now "Can I use a handler as a means of communication between async task (onPostExecute method) and the mediator i.e. rather than calling a method on mediator directly in onPostExecute, just get hold of the reference of the handler(originally instantiated and handleMessage defined in the mediator and stored in a static map) from the static map in the onPostExecute() method and call sendMessage on it. This should in-turn invoke the handle message on the mediator, and in-turn can give loose coupling between async task and mediator. (FYI: The static map approach I am using to cache the references to handle activity destruction process, rather than going through onSaveInstanceState route). Does the above startegy makes sense? The Android documentation for handler says "There are two main uses for a Handler: (1) to schedule messages and runnables to be executed as some point in the future; and (2) to enqueue an action to be performed on a different thread than your own". Basically, if i understand it correctly, handler is used for communicating between two different threads Now, can there be (3) scenario(as I described above) where it can be used in the same thread but between two different objects(working as a callback mechanism). If yes, then if I make a call to sendMessage, will that immediately call handleMessage or will it still(even though we just have one thread) put it in a messagequeue and will invoke handlemessage when its turn come(as it does in case when we are communicating between two different threads). The reason why I asked this is(it is another question ofcourse) a.) When I just make a call to mediator.process method(and no handler) from postexecute, and suppose the user changes the orientation before the the mediator.process method exits, it still maintains the sanity i.e. the activity does not get recreated untill the method exits, because postExecute gets called on same thread so any other call to destroy activity even by android framework waits untill the postexecute (because I call mediator.process in it so it becomes part of postExecute) method exits, and hence atomicity is maintained and the logic does not mess up. b.) So If I use handler approach, will the steps be: 1.) Will the call inside the onPostExecute method to sendMessage on handler be blocking call or will the postExecute method exit immediately. 2.)if its a non-blocking call--> Then when onPostexecute method exits, and say orientation changes then can i be assured(as in a.) above) that handlemessage call be made before the activity destruction(in which atomicity is maintained) or can it be made before(in that case things can get messed up) On Aug 5, 4:27 pm, Maher Ali <[email protected]> wrote: > Vikas, > > Maybe you can create a mediator for every activity type. > If an activity wants something from the server, it adds a job to this > mediator > passing its *this* as the key. > The mediator will then contact a server proxy that does the server > interaction async by default. The mediator can ask the activity to show a > busy signal or not (it depends.) > When the server finishes the job, it calls onSuccess on an object of an > anonymous class > passed by the mediator. The mediator then checks to see if the activity has > not been destroyed (the activity will cancel the job by removing its *this* > from the mediator's job list on its destruction.) > If it has (no entry for that activity,) it discards the server's result. If > not, it delivers the result > to the activity (to refresh, etc.) and removes the job from its list. > > Hope this helps. > > Regards, > Maher > > > > On Wed, Aug 5, 2009 at 1:49 PM, Vikas <[email protected]> wrote: > > > Hello David/Mark, > > > Thanks a lot for replying. > > > Since this use case is so common that any form based application needs > > it and I think a correct answer to this will avoid lots of pains and > > confusions for many people who are trying to write any enterprise > > level applications. > > > Let me just describe a very simple use case step by step(rather than a > > big paragraph above It is still big{sorry about that}) : I am asking > > now in a more general way. > > > I will take a two screen scenario. > > > Here are Requirements(Steps): > > 1.) Screen 1 --> Search Screen which has a zip entry editText field > > and a Find button next to it. > > 2.) Screen 2. --> Store List screen that will contain list of all > > stores existing in that zip code.(now if the user clicks on one of the > > stores he goes to details but I wont even go there lets have just 2 > > screen scenario). > > 3.) Screen 1 can also display a Validation error(this validation will > > be done at server) whether that zip code is valid or not and if its > > not Screen 1 will display error dialog. > > > 4.) Since we want to avoid multiple concurrent requests on screen, we > > want to popup progress dialog imediately as soon as user clicks find > > button and hide it as oona s the response comes back from server > > (whether its a validation error or valid results). > > > 5.) The communication to server is using HTTPClient and as soon as > > response is read(which will be an string xml) from server, a parser > > will get invoked which will convert this strng xml to a single > > business object(which will contain erro code in case of error or valid > > data in case no error occured). This whole http part plus parsing part > > should be a single atomic unit as both take time, so this becomes our > > single atomic long running process the result of that process will be > > a business object returned to the Screen 1. > > > 6.) As soon as Screen 1 gets this object progress dialog will get > > dismissed, then screen1 will peek into object if it find error code > > will show error dialog and if it does not find error code will extract > > valid data stuff it in Intent and the pass it to Screen2 which in turn > > extract this data and display list of stores. > > > 7.) Now Suppose say Screen 1 triggers this long running process(after > > the user hits find button) and is say still waiting on it following > > thngs may happen: > > > Case 1: User changes orientation(Activity will destroyed in this case) > > Case 2: A phone call comes in(Activity will go in background and may > > get destroyed by OS for any reason may be low memory) > > Case 3: Any other xyz scenario where activity can go in background and > > hence becomes a potential candidate for destruction. > > > Questions: > > > 1.) What is the right place to put this long runing task to, and > > remember this task or process (once complete) needs to communicate > > back to the Screen1(activity) too for two resons first closing the > > dialog box and second handing over the business object to it so that > > it can stuff it in intent (or in some other scenarios just use it some > > screen fields etc.). And this task should not get affected(i.e. should > > keep on running) in cases where activity gets destroyed by OS(3 cases > > mentioned above) > > > Is it Async Task or Local service or any third way?(And how will a > > newly created activity attach itself to this old long running process) > > > -->Going back to Dianne's reply(again I might be wrong here, I was > > serializing Async Task and not the thread which it creates in > > background so thats why my prototype worked, I agree u can not > > serialize a thread but I thought when u do asyncTask.execute creates > > another thread which does processing and then post result back to > > postExecute method so can we not serialize the task, again you do not > > have to answer it if it does not make sense but if u or mark or any > > other person can provide solution to the above UseCase in general that > > would be great. > > > I have to create 100 such screens and a solid foundation will go long > > way. > > > Thanks to all you guys in advance. > > > On Aug 5, 1:56 pm, Dianne Hackborn <[email protected]> wrote: > > > Well, using AsyncTask with serialization and parcelable is just plain > > wrong > > > -- you can't serialize an actively running thread. If you just want to > > have > > > some thread running in the background, and don't care if the system kills > > it > > > while your application is in the background, just keep a reference on it > > in > > > a static global, so whatever activity is currently running can get it. > > > > On Wed, Aug 5, 2009 at 10:45 AM, Vikas <[email protected]> wrote: > > > > > Any ideas? > > > > > On Aug 3, 5:08 pm, Vikas <[email protected]> wrote: > > > > > Hi Guys, > > > > > > I have a requirement where I have to read/parse some data from the > > > > > server(using HTTPConnection) and then display it on to the screen. To > > > > > avoid ANR issue I used AsyncTask to perform the above. Now in order > > to > > > > > avoid application crash in case the activity gets destroyed(either by > > > > > OS or if orientation changes or say on any incoming call-->where user > > > > > stays on the phone for long and for some reason OS destroys/recreates > > > > > the activity). Currently, I hols the reference of AsyncTask in my > > > > > activity and then provide a callback(the activity itself) to > > AsyncTask > > > > > so that I can pos back message to activity(like closing progress > > > > > dialog box).In order to avoid memory leaks on onPause I nullify this > > > > > activity reference in AsyncTask.Before onPause I save the AsyncTask > > > > > instance using onSaveInstanceState method but I have to use > > > > > putSerializable for that. I have read on the forums that > > serialization > > > > > method is slow, so my question is should I use parcelable > > approach(and > > > > > whether the converting AsyncTask to parcelable will be same as > > > > > creating any other object parcelable). or both these approaches are > > > > > totally wrong i.e. I should not be using both the above approaches if > > > > > no then what is the correct approach which gives maximum performance > > > > > benefits. No I read at one forum also on android blog(and in their > > > > > examples) where they suggest storing AsyncTask > > > > > using onRetainNonConfigurationInstance() method as that gives > > > > > performance benefits but I think that approach just works only for > > > > > cases where activity gets destroyed via orienattion changes but does > > > > > not cover other scenarios where activity gets destroyed because of > > > > > things like low memory, phone calls etc. > > > > > > I would really appreciate if anybody has any suggestions or ideas on > > > > > how to do it right(or if somebody can confirm that whatever I am > > doing > > > > > is right and I just have to choose between parcelable or > > > > > serializable?). I am able to get it working very well, its just that > > I > > > > > am not sure if it can cause any issue in production. > > > > > > This is such a common task and there is no good example for this and > > > > > looks like people are still scratching their heads on this. > > > > -- > > > Dianne Hackborn > > > Android framework engineer > > > [email protected] > > > > 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.- Hide quoted text - > > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
