Dilemna : prevent StackOverflowException or improve user experience ?

Question

Hi All,

In my application, I have 2 list activities which can start one or the other by clicking on their items.

|--Activity1--|           |--Activity2--|           |--Activity1--|
|   item11    | ->click-> |   item21    |           |   item21    | ->click-> ...
|   item12    |           |   item22    | ->click-> |   item12    | 
|   item13    |           |   item23    |           |   item13    |
|-------------|           |-------------|           |-------------|

So if the user clicks too much, he can fill all the stack and the system will throw a StackOverFlowException won't it ?

The solution I chose then was to tag these 2 activities with noHistory="true", but now I regret that the user can't navigate between these 2 activities with the back button.

Can someone help me to find a better alternative ?

Thanks in advance

EDIT: to be more comprehensive, let's explain what is this activity workflow goal :

I have a database which store a list of names linked to a list of days in a year. A name can be linked to multiple days, and same thing a day can be linked to multiple names.

the database schema 

|  names  |---< n, m >---|  days  |

So this activity workflow is a kind of database navigator :

• Activity1 is the NameListActivity, it displays a list of names linked to a specific day.
• Activity2 is the DateListActivity, it displays a list of days linked to a specific name.

When user clicks on an item (a name) of the NameListActivity, the DateListActivity is started with the list of days linked to the clicked name.
And same thing, when user click on an item (a day) of the DateListActivity, the NameListActivity is started with the list af names linked to the clicked day.

Answer 1

I don't see why removing the ability to go the Activity1 from Activity2 would deteriorate the user experience. I believe that you mentally create a hierarical list in your head when you navigate this type of menus, so when clicking on item22 I would get confused if I was sent back to Activity1.

I need more details about the content of the menus to suggets another design, but you might be best of rethinking the menu system.

Answer 2

What you need to do is to store the history in some structure, rather than relying on the stack to maintain it for you. Then you can maintain your good user experience and not blow the stack.

Answer 3

So if the user clicks too much, he can fill all the stack and the system will throw a StackOverFlowException isn't it ?

No, it won't.

Answer 4

Try to remove this noHistory="true" and instead put android:launchMode="singleTask" http://developer.android.com/guide/topics/manifest/activity-element.html#lmode But Mark @commonsware you'll be fine as it is.

Answer 5

I'm having similar problems with my application. Seems that the problem lies in number of nested views for each activity. So, if you have, for instance:

tab->
    linear layout->
        text,
        linear layout->
             text,
             scroll->
                  text,
                  linear layout->
                       image, 
                       text

and maybe several more nestings, the odds that you'd get stack overflow after getting from such view to a similar one and back several times (in my experience) are high. Check the nesting with hierarchyviewer (android-sdk/tools). Also tell me if you fix the problem, because I still don't know how to fix it...

Answer 6

As I understand it, Android's "stack" of activities isn't a "stack" in the traditional sense, and memory is managed in a more intelligent way. The activities stack actually goes on the heap, and the OS will kill the activities lower on the stack if it needs to.

I would say the worst that will happen is you lose some old history.

If you want to test it, allocate a large amount of memory in each activity so that 5 or 6 will fill the available memory, then try it.

Answer 7

commonsware is correct. You won't have to worry about a stack overflow. :) However, you can design the app to clear the stack to avoid the situation you described. Look into Clearing the Stack, specifically the use of clear top.