app flow (menu-implementation) advice question

In my app, I want to present the user with a series of multiple-selection options (menus with more than two choices), and THEN present the user with the main app screen.

Think of a GPS app which shows your position in lat lon. Now lets say I want to incorporate a number of menus (over five) before we get to the main "running" screen. In one menu lets say I want to ask the user if they want to view the GPS coordinates in lat/lon, lat/lon decimal, or MGRS. In another menu lets say I want to ask the user if they prefer a black, blue or white background. All of these menus I want to present to the user in quick succession before the main "running" screen occurs. Similarly, the app will not start to record the tracks of the user until the user has passed through all these menus, and depending upon the menu selections will operate one way or another in the main "running" screen. That's my example.

Now, can anyone give me some advice on how to go about organizing my program, or my program flow, to best support this goal?

I'll be honest I am not very familiar with the words "push" "pop" or "MVC" architecture. I tried to implement a double-nested confirmation dialog that asked the user if they wanted to quit, and afterwards presented the user with a "do you want to save" confirmation... and I had difficulty implementing it in the garmin monkey C architecture, and I had to use a bulky work-around involving the use of a timer. I hope to not use that ghastly solution in this future app I will develop.

Are there any samples around which demonstrate how the program could go through a few phases (first phase get answers from user, second phase display output in main "running" screen)?

I would assume this might be a sample architecture:

start --> get input phase --> main running phase --> quiting phase/end



in "get input phase"

-present with menu A (blue, black or white background)

  ... if user presses "back" goes to previous menu

  ... if user selects color, assigns it to variable, loads menu B



-present with menu B (lat/lon,   lat/lon decimal,   MGRS)

  same as before, saves to variable, if user presses back, goes back to menu A



- (if lat/lon decimal) present with menu C  (how many decimal digits to display)   <- for example

  lets user input a digit between 3 and 5



- (if MGRS selected) present with menu D  (how many digits of precision to display)

  let user pick integer between 6 and 8



and so forth...



followed by the main "running" screen

- show GPS coords as specified from previous user input

Specifically, any idea how I could best load the menus, in a Garmin app? I am examining the Menutest sample app.

I think I will use a variable which prevents the tracks from recording and prevents the app from "running", until the user answers these menu questions, and thus control the app flow. I am not sure I will be able to incorporate nested menus since my menus may need to include data input (not simple abc menu choices),

So I would present with one menu, and once that was complete, remove that menu from memory, and then present the user with another menu separately... Would it be best to do it this way or should I link the menus together and stack them up so the popping of one automatically loads another? (if that makes sense?)

also I wish to present the user with menu options which contain text loaded from string values in settings... hmm

thanks for any advice concerning this!!!

Top Replies

jim_m_58 over 8 years ago +1

For some of the things, maybe look at using app settings? If it's not something that the user may change each time (such as degree vs MGRS or background color) you really don't have to have the logic…

All Replies

jim_m_58 over 8 years ago

For some of the things, maybe look at using app settings? If it's not something that the user may change each time (such as degree vs MGRS or background color) you really don't have to have the logic in your app at all.

If you want some things setable in the app itself, consider this:
When the app starts, you probably want to do something like wait for a GPS lock before you allow recording to start. While waiting, display the last-used values (the object store can be used for this). While on this screen, start will start the recording, but with menu, you can go into the menus to change the values if needed. If the options are fine for the user, all they do is press start when they run the app, and no interaction with the menus is needed.

To see an example of both, look at my Hike2 app. Many things are configured with app settings (degress vs MGRS is just one of the things), but before recording starts, the user can use the menu button and switch between recording a walk or a hike, select a white or black background, etc., and the selected option is saved and is the default the next time the app is run.

mqbfxw over 8 years ago

Thanks I will do this.

I will still look to have the program only let the user "start the activity and recording" after GPS is up to snuff, and also they have picked a routine... but I think you're right the majority of settings are best left in a settings menu that the user can peruse if they want.

Thanks a lot! I don't think I would have come to this conclusion had I not asked it.. so it may have seem like a silly question but my app will be better for it!