4

I have a workflow with several screens with different questions and answer-options. So there is a question on screen 1 and the user makes his choise -> the user hits the continue button -> screen 2 opens with another question -> user makes his choice and continues -> screen 3 opens etc...

But actually I'm not sure which is the best way to implement this behavior in consideration of a good maintainability and clearness. I think they are at least three options:

  1. Every screen gets its own activity and layout file and I pass the choosen data trough intents.

  2. 1 Activity and different fragments, each fragment has its own layout. If the continue button is pressed, the fragment will be replaced with the next fragment.

  3. 1 Activity and different layout files. Just the layout gets replaced and everything else is handled in the activity.

Actually I already started implementing with option 2.) but I don't know if this is not "too much".

The Android API guidelines say that you should use Fragments for multipane UI and for reusability. But actually I don't want to build a multipane UI in this case and the fragments are not reused. So maybe 3.) is the way to go? Or even 1.)?

Tomasz Jakub Rup
  • 10,502
  • 7
  • 48
  • 49
spcial
  • 1,529
  • 18
  • 40
  • 1
    it purly depend upon your application need. If you have fixed number of screens which will never change in future then I would suggest to go for option 1 or 2. I don't suggest to go for option 3 In that you need to manage backstack manually – Ketan Parmar Dec 08 '15 at 08:04

1 Answers1

4

I would choose your option # 3. The reasons are:

  • Activity takes some memory compared to fragment or layouts. The interface between activities and fragments is a bit awkward, though I got used to it. I don't recommend it for your case.
  • I like fragments. However if all the fragments are similar in looks/feel, then why take the computer time for hiding/showing or replacing them. The reason for fragments is stated in Google web page like at Building a Flexible UI. I don't think you need a flexible UI as said in Google's intention.
  • I would suggest one Activity, at least one Fragment for all the questions/answers. You simply use one layout to change text/content. If the UI is different, then replace the layout with another. It's quite normal for an Android app to have so many different layouts anyway. Android takes some memory to load layouts but it's quite fast and efficient.

For option 3 design: You can use the inflate() method to load a certain layout and to replace one. A good example at SO link @ Android layout replacing a view with another view on run time

Community
  • 1
  • 1
The Original Android
  • 6,147
  • 3
  • 26
  • 31
  • I think the same, that option #3 would possibly be the most convenient (in terms of performance at least) option. How would you handle backstack etc.? I thought about a simple "state machine" holding the current state. So if state is "2" then load screen "2".. if back button is pressed go one state back etc...or is there an easier way to implement "states"? – spcial Dec 08 '15 at 10:59
  • @spcial, I would not use the fragment Backstack because that's only good when user wants to go back to the previous question, which may not be allowed. The Android states, in my view, is used mainly for fragments and activities. So in this case, simply use the "state machine" code design (not the Android version), and that should be simple and not so technical. – The Original Android Dec 09 '15 at 00:53