Any idea Guys?
On Aug 10, 11:58 am, Vikas <[email protected]> wrote:
> 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- Hide quoted text -
>
> - Show quoted text -...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
