When to create activities/display areas (regarding mobile phone support)?

[Jens]

Hi,

imagine an app where you have to select something (e.g. a person, customer, database, or more general a context) and based on that selection a menu is presented. In a desktop version of that app the "context selection" and the "menu area" are always visible side by side because there is enough space and thus they are not implemented as activities.

Now for a mobile phone version the "context selection" and the generated menu should be shown sequential/step-by-step because of the screen size constraints. Does this mean that I have to convert the "context selection" and the menu (even if it would be a static menu) to activities because thats the cleanest way to rearrange the "UI flow" based on activities/places?

So can I say, as a rule of thumb, whenever I see areas/views in my desktop app that are displayed at the same time but may be rearranged for tablets/mobil phones I am better off using display areas/activities for them, even if the content is pretty static and the activity is a no-brainer? And only if I have content that is static and should be displayed all the time on all possible devices (or not at all on a specific device) its save to not use Activities?

Its just a question of understanding, because before thinking about a mobile phone version I thought there is no need using display areas/activities for static views like menus. But now it seems like you need them if you want to change the UI flow.

-- J.

[Thomas Broyer]

On Monday, December 12, 2011 5:26:58 PM UTC+1, Jens wrote:

Hi,

imagine an app where you have to select something (e.g. a person, customer, database, or more general a context) and based on that selection a menu is presented. In a desktop version of that app the "context selection" and the "menu area" are always visible side by side because there is enough space and thus they are not implemented as activities.

Now for a mobile phone version the "context selection" and the generated menu should be shown sequential/step-by-step because of the screen size constraints. Does this mean that I have to convert the "context selection" and the menu (even if it would be a static menu) to activities because thats the cleanest way to rearrange the "UI flow" based on activities/places?

Strictly speaking, you don't "have to", but I'd do it anyway. Note that it depends how you want the "back button" to behave: if it should move you from the menu to the "context selection", then you'll be using 2 distinct places, so it'd be easier to use activities as they share the same display area as the other activities in your app.

So can I say, as a rule of thumb, whenever I see areas/views in my desktop app that are displayed at the same time but may be rearranged for tablets/mobil phones I am better off using display areas/activities for them, even if the content is pretty static and the activity is a no-brainer? And only if I have content that is static and should be displayed all the time on all possible devices (or not at all on a specific device) its save to not use Activities?

Its just a question of understanding, because before thinking about a mobile phone version I thought there is no need using display areas/activities for static views like menus. But now it seems like you need them if you want to change the UI flow.

Yes and no: there's a difference between using activities for these "static parts" on the "mobile version" of your app, vs. changing your "desktop version" to using activities there too. If activities don't make sense on desktop, then don't use them. If you want to share code with the mobile app, you can do so by using the same widget; or if you use MVP and want/need to switch the view depending on the form-factor while sharing the presenter code, then simply make your presenter *not* an activity (and wrap it in an activity on the mobile app).