Page Views & Stack

The way I do it is I only have a single view, and a variable as to what to display in the view. (a "page number") You'll see the basics in the "primates" sample in the SDK.

On up/down actions, I increment/decrement the page number as needed, then call Ui.requestUpdate() to display the page. Nothing gets pushed/popped in the basic loop.

Yes, this is definitely something that you can do.

If you want the interaction with the user to be a dive (you want to show more details on a given subject), you'd typically use Ui.pushView() to go deeper and Ui.popView() to go shallower. If you want to move around at the same level, you'd use Ui.switchToView().

As an example, imagine that you were making a Fandango app. Assume that the initial view showed the name and distance to the closest theater. A normal interaction would be to use up/down buttons or swipes to change the active theater (stay at the same depth). Once the right theater is selected, pressing enter/start/stop or tapping the screen would go to the movie list and times for that theater (deeper), and pressing or swiping back would return you to the theater list (shallower). You'd probably have similar functionality for the movie list (enter/tap would show ratings and a summary, back would return you to the movie list).

You can do it Jim's way. For simple applications it works fine, but when your application gets more complex you either end up with one view that has tons of logic in it for what to display, or you have some external state management classes that duplicate the functionality of the view/delegate stack. You also lose out on the view slide in look and feel that is provided for the native views (yes, you can re-implement it, but you shouldn't if the functionality is already there).

Travis

Travis and Jim,

Thanks for the great replies. This makes sense. Fandango and Primates both are good parallels. My app will have 3-5 top level pages (only 1 would be similar to existing functionality, balance would be novel and probably each require different layouts / views). For any page, it will be possible to drill down (like theater > movies > movie details); push and pop make perfect sense here. Cycling through top level screens, the index makes sense.

Want to explore Travis' point about simple vs complex; I suspect I only partially understand. Let's imagine 3 pages with 3 very different views and very different sets of drill down functionality (following on your Fandango metaphor, almost like top level is movies on one top-level page, restaurants on a second top-level page, and gyms on a third top-level page. If I have separate page views (as in primates, but each much different) and unique/separate delegates for each top level page (vs a single delegate (DetailsDelegate) as in primates), do I avoid the issues of redundant functionality and of a complex external state management monolith; feels like it would.

Still not sure I understand well enough about the native views; probably need to explore native view further. I'd love to implement my app as a data field or widget, but the constraints there are too limiting. So, I think I'm relegated to replicating some native functionality (e.g. tracking running to a fit file; displaying basic fields like time, pace, HR, etc.)... and then putting the novel content on other pages (2 3, etc.) that I can cycle to either user directed or based on certain conditions being met along run. Can you point me to best reference(s) / examples for brushing up on native views and implementing some basic native functionality.

Best regards,

Bill

Want to explore Travis' point about simple vs complex; I suspect I only partially understand.

Yes, it sounds like you understand. Essentially, the view/delegate will be part of an implicit state machine (if the top view on the view stack is a GymDelegate, you are implicitly in the state that deals with viewing gyms). If you were to do the whole application with a single view/delegate pair you'd need to keep track of what state the application is in (is the user currently viewing a gym), typically with an enumerator or an actual state machine.

Still not sure I understand well enough about the native views; probably need to explore native view further.

If you have specific questions, feel free to ask. I'm happy to help.

I'd love to implement my app as a data field or widget, but the constraints there are too limiting.

Widgets aren't actually all that limiting. For the most part they have the same limits as an application. The big differences are memory limits and slightly different usage... A widget should display useful information in the initial view, and the user will be required to dive into your widget before they can access additional information and will be subject to an automatic timeout.

So, I think I'm relegated to replicating some native functionality (e.g. tracking running to a fit file; displaying basic fields like time, pace, HR, etc.)... and then putting the novel content on other pages (2 3, etc.) that I can cycle to either user directed or based on certain conditions being met along run.

I have worked on an application that did this. You will likely have to compromise on features that are built into the native apps because you just won't have the available memory to implement them all. If you can get by without user input (at least for some devices), you might be able to do what you want as a data field and settings defined outside the application.

Can you point me to best reference(s) / examples for brushing up on native views and implementing some basic native functionality.

The sample programs do a pretty good job of this. The MO2Display sample might be a good place to look.

Travis