views:

32

answers:

1

I'm developing an Activity that does some of its own state management. I'm trying to differentiate the following onResume cases:

  1. New launch
  2. task switch (home button long-click)
  3. resume after other activity in the same application
  4. wake-up after sleep
  5. orientation change

Is there something in the Activity's intent, or elsewhere, that can help me differentiate these?

For the curious and some context... I'd like to preserve my internal history stack on 4 & 5. On cases 2 & 3, I would preserve the same current page, but erase the history (allow the normal back button functionality to take over at that point). Case 1 would initialize to the activity's internal start page (and can be detected easily enough with some help from ocCreate).

+1  A: 

Is there something in the Activity's intent, or elsewhere, that can help me differentiate these?

Item #4 has nothing to do with onResume(), AFAIK.

Item #5 would be better handled via android:configChanges and onConfigurationChange() though you could "detect" it by returning something from onRetainNonConfigurationInstance() and seeing if it is there in onResume() via getLastNonConfigurationInstance().

The others aren't just three cases, but probably twice that, once you start taking into account things like "being kicked out of memory to free up RAM" as a possibility.

Off the cuff, it feels like you made some unfortunate architectural decisions ("internal history stack...erase the history...allow the normal back button functionality to take over at that point"). Android is designed around lots of cheap activities, and you appear to be violating that precept. You are welcome to do so, but bear in mind that Android support for your chosen pattern may be limited.

CommonsWare
Prior to reading this, I had implemented the onConfigurationChange() hooks to preserve history across orientation changes. That seems to be working.After testing, you seem to be correct about #4.Leaving #1 and #2, which are handled in the same manner, clearing the internal history stack.As for being kicked out of memory, I feel that is a valid case to clear the history stack and treat the new launch for what it is, a new Application instance with an empty internal history.
Anm in LA