Do you have a strategy (an app-internal architecture, a design
pattern?) that helps you structure your app's use of asynchronous/
callback operations like startActivityForResult() and bindService()?
Dealing with asynchronous events is standard for GUI code, but this
goes beyond that into code where you pretty much know the sequence of
events. And unlike, say, a desktop environment, you usually don't have
the option of blocking and unblocking a thread to hide the
asynchronous operation in the middle of some straight-line code.
With a typical startActivityForResult() for example, you have some
code for preparing the request Intent ("prepare-request"), some code
for interpreting the result Intent ("interpret-result"), and some code
for what to do next ("do-next"). And the do-next chunk typically
involves yet another asynchronous/callback operation.
In my first attempt at coding a use of startActivityForResult(), I had
onActivityResult() call methods in the parent Activity. I couldn't
follow my own code -- the flow of control from prepare-request to
interpret-result to do-next was just not apparent in the code! In
another callback situation, I used an anonymous inner class for my
TextToSpeech.OnInitListener, but found it similarly hard to see the
flow of control implicit in my code.
I've experimented with trying to encapsulate prepare-request and
interpret-result for a particular sub-Activity in a single class, and
passing in do-next chunks using the Command pattern, but it's
debatable whether that was any improvement.
Can you point me at better approaches for structuring this async/
callback code?
Mark
--
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
