I've thought about this -- basically have the main application logic run in a "secondary" thread and send events/messages to the UI thread to put screens up, etc. Basically the UI routines would be subroutines invoked via an RPC protocol from the other thread.
I think it's conceptually doable and would make for more comprehensible code, but it would run afoul of Android's scheme for shutting down parts of apps when it needs the space, among other things. On Oct 5, 1:50 pm, note173 <[email protected]> wrote: > Is there a way to manage application activities by hand, like this: > user activating an application from menu, it does some initialization, > then creates some activity (is it necessar y to declare all activities > in the application manifest?), and listens to it's events. On some > event application decides to close one activity and open another - so > it contains all the application logic. > Didn't found anything like this in examples, they all have all the > logic in the activity classes. > Maybe I need to user Services? > (Maybe I don't understand right, what an activity represents. For me > it's like window in windows, or Displayable in j2me) > > I'm very new to android development, trying to understand the basics. -- 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
