Hey guys, Funny I find this thread this morning.. I just posted to Mark Murphy's forum a similar question regarding multi-activity apps and how the life cycle is handled. My question was a little bit different, but similar to this. My main question was how do we handle the various life cycle methods in each activity. If I have a game with a splash screen, main menu, game screen, and high score screen.. at any one of those screens a call can come in, the user can hit back, hit home, etc. My understanding of what you say in this thread, and how I thought it would work is.. no matter WHAT button was pressed (or call come in, etc), the activity on top is PAUSED. When you come back to your app by any means, the paused activity regains control via onResume and such, and you continue where you left off. The exception is.. that Android itself might shut down your app for other apps if it needs to regain the memory your app is using. Therefore, it is up to the app to save it's state info, so that WHEN the user either uses the task list OR the icon in the drawer (or home screen) to launch your app, you can load that state and put the app back into the last place it was at when the PAUSE condition occurred. Is this not the case?
So my main problem with all this.. I understand for the most part how the methods are called and when.. but what I am having a problem with is how to save state and restore it... primarily because, in 2+ activity apps, it seems you have to duplicate all those methods in every activity. See, I love how Android works.. I think it's great..makes sense.. one foreground app runs, the rest sit their paused. Saves battery and makes sense. What I don't get is this notion of life cycle events for every single activity. It seems to me most OS/platforms have a single point of entry life cycle class.. where you would handle any life cycle event in one place. Sort of like a game loop in a game, where you handle all the things in one place to make the game go. I am trying to figure out.. if in my game, at the main menu the user hits BACK, does it go back to the splash screen.. or to the home/drawer and out of my app? Do I exit my game completely if they hit back, or does the user assume that hitting back or home does NOT exit the app, but simply pauses it so they can do something else? I've read two different methodologies regarding this. It seems that some people exit their app completely if you leave it... but you still don't have total control over that because if a call comes in, your app gets paused. You can at least detect home/back pushes and exit your app completely if you want. The other notion is to never exit your app. It stays running forever until Android shuts it down due to memory needs, or a user runs a Task killer to kill it. This seems so odd to me that this is the way to do things. In between that we seem to have some games or apps that actually provide an exit option, either by catching the back button at the main screen and offering the option to exit, or providing an exit/quit menu item that ends the app. To me this last one seems the right way to go for any app. Somehow, you should have an exit/quit, just like a real desktop app. This notion of letting it run forever and Android will manage all the app resources as needed.. I don't know.. I don't like it. What happens if you go to play a game that needs more resources..but Android in shutting down some apps, causes the game to hiccup? Not sure if Android would actually do that right in the middle of a running app or not, but I am curious what happens? The other dilemma to me is.. do we have to actually implement each activity with all those life cycle methods? Or do we put the process of saving state into a single say, static helper class, and in all the activites.. in their onSaveStateInstance and such, we refer to the same one helper method so that we're not duplicating code in various activities? I ask this also because I am wondering.. if I make a dialog activity, and the user hits back/home, call comes in, screen orientation changes, etc.. I need to save my state, then when the app starts.. in case say they changed screen rotation, it restarts the app. Where does it start from? The activity that was on top? Do I then have to reload all the state? Or do I just reload state for that one activity that is on top? If only the one on top (the dialog.. if it has any state)... when it's done and closes (or user hits back), does the underlying activity then get called to load it's state before it goes back to executing whatever method it would? I so far haven't found any info that explains how this multi activity/life cycle process works. I did ask Mark Murphy on his forum so Mark, if you're reading this, I apologize for a double post. I think it would be good for other developers to know in both places. :) Thanks all. On Wed, Jan 27, 2010 at 2:13 AM, ayanir <ayanir...@gmail.com> wrote: > Hello, > > I have a similar problem when I open the application from the Market. > > if I go from Activity A (LAUNCHER) to B, press Home key and re open > the application from the Home screen icon it come back to Activity B > (the last Activity) as it should. > but, if I open the application from the Market application, it open > Activity A. > what is the difference between these two and how can it always open > from the last Activity no mater how I open the application? > > Thanks > ayanir > > On Jan 26, 8:07 am, jotobjects <jotobje...@gmail.com> wrote: > > Yes it looks like we have got confused here about what happens when > > returning to the Home screen (perhaps your issue was the Eclipse > > "feature" mentioned in the thread?). > > > > In the interests of clearing up quite a bit of misinformation in this > > thread, this is the what actually happens: > > > > Re-launching the Activity from the Home screen returns to the same > > Task that initially started that Activity (the one where action=MAIN > > and category=LAUNCHER). But whatever Activity was on top of that old > > Task is again the foreground Activity (unless clearTaskOnLaunch is > > set). > > > > The Activity listed in the Manifest with category LAUNCHER is NOT the > > Activity that is active and setting singleTop is not necessary to get > > this standard behavior. Here is one place that this behavior is > > outlined - > > > > http://developer.android.com/intl/fr/guide/topics/manifest/activity-e... > > > > On Jan 25, 1:08 pm, Josh Hoffman <keshis...@gmail.com> wrote: > > > > > Thank you all for your help. I've tried some of the suggestions posted > > > here and it seems like the main thing that was stopping me was not > > > doing a full .apk build prior to each test. I implemented the > > > android:launchMode="singleTop" manifest flag, but that didn't actually > > > seem to get me my desired functionality. The only time I ever hit the > > > onNewIntent() execution block was if I hit home from Activity1 and > > > relaunched. Hitting home from Activity2 simply resulted in returning > > > to Activity1 on relaunch. > > > > > When I tested my app via adb install -l -r myApp.apk, the Android > > > application stack seemed to finally behave itself. If I hit home from > > > Activity2 and relaunch, I return to Activity2 exactly as I left it > > > (thanks largely to Matthias Kaeppler's Droid-Fu and BetterAsyncTask, I > > > might add). > > > > > Just wanted to post and say that my issues seem to be resolved thanks > > > to this new (if a bit cumbersome) development process of doing a full > > > apk build. Thanks again for all the help! > > > > > On Jan 24, 10:58 pm, String <sterling.ud...@googlemail.com> wrote: > > > > > > On Jan 25, 12:54 am, jotobjects <jotobje...@gmail.com> wrote: > > > > > > > If Activity1 and Activity2 are part of the same task and Activity2 > is > > > > > foreground when pressing the Home key, then I thought that choosing > > > > > that app on the Home screen would return you to Activity2. > > > > > > Something to remember is that "choosing that app on the Home > > > > screen" (or in the Launcher drawer) is really clicking on a shortcut, > > > > and that shortcut is specifically to the activity with this in your > > > > manifest: > > > > > > <intent-filter> > > > > <action android:name="android.intent.action.MAIN" /> > > > > <category android:name="android.intent.category.LAUNCHER" /> > > > > </intent-filter> > > > > > > It's also true (as another poster said) that installing your app from > > > > Eclipse can change what its default activity is. If you want to > > > > accurately simulate the behavior that your users will see, you need > > > > to build an APK as you would for release, install it through the > > > > command line, and see what that does. > > > > > > String > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
