Thanks for the explanation. That makes sense. Here's a way to address it:
class MyComplexProcess {
// process state variables
doBlockA() { ...// saving state in the object's fields instead of local
method variables }
doBlockB() { .. }
}
Instantiate a MyComplexProcess object with scope inside the Activity object.
Replace { block A } with myCP.doBlockA() and replace { block B } with
myCP.doBlockB(). You also need to save MyComplexProcess state for the
Activity lifecycle. The Activity can be covered by a notification, the user
starting another Activity, or the process getting killed - all while your
application's dialog is being displayed. Fortunately, the dialog itself will
be restored by Android.
I would agree that a straight procedural pattern is simpler. However, in
just about all UI-centric applications (especially those needing to co-exist
with others), you need to break down the seemingly sequential code into
steps.
--
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
