Layout vs View vs Redrawing; Separation of UI and Computation;

Former Member over 8 years ago

Hello folks,

I'm new to Monkey C and Garmin watches in general.

I'm coding a public transport monitor widget and am currently trying to determine what the correct or best way to handle different views is.

Like as far as I understood it a widget has to have something like a start screen and after "entering" the widget (subquestion: What is the correct event there actually? I read like two sentences about an enterWidget Behaviour but did not manage to catch it?) one can basically do all the things an app could do, view/ui wise.

So my question is, after having entered the widget, what is the correct way of changing displayed content. When should I just redraw stuff in onUpdate, when should I set a complete new Layout and when should I push a completely new view?

Actually, one more question, if a make multiple view classes like in the sample "UserProfile" where would I do my requests, computation etc.? (Like I want to split the UI/view from the computation part.)

While thinking and planning the widget I noticed that, if I manage to code this with a well structured, object oriented approach it could serve as a codebase for many other widgets that get information from the net and want to display different views etc.

Every help is greatly appreciated.

Thanks. :)

Regards,

Christian

travis.vitek over 8 years ago

Like as far as I understood it a widget has to have something like a start screen and after "entering" the widget

Typically a widget would use a behavior delegate and respond to BehaviorDelegate.onSelect(). You can't really respond to the other events of the behavior delegate (onNextPage(), onPreviousPage(), onNextMode() and onPreviousMode() are not called for the initial view of a widget. Once you push a view, you can respond to input events like a regular application.

what is the correct way of changing displayed content. When should I just redraw stuff in onUpdate, when should I set a complete new Layout and when should I push a completely new view?

It really depends on your application. You could use a single view class that directly does drawing differently based on context, it could delegate to another class for this, or you could use a different view class entirely. The simple way seems to be to use a new view.

if a make multiple view classes like in the sample "UserProfile" where would I do my requests, computation etc.? (Like I want to split the UI/view from the computation part.)

Again, depends on your application. Simple applications put lots of business logic into the view. It seems better to implement a Model-View-Controller pattern and put all of the business logic into the Model, and to drive the Model from from the Controller (the Ui.BehaviorDelegate class).

If you are doing web request stuff, it is sometimes useful to implement some sort of transaction class that encapsulates the web request and OAuth handling and drives the view.

Travis

gasteropod over 8 years ago

The one problem I have found with pushing views is that there is no way to pop more than one view at a time, therefore if you are a couple of views deep and you want to quit, back to the start you cannot. Therefore I have at times used a second view in a widget to take you off the main page to allow access to up/down buttons, but then changed the content on this second view so I can jump back several logical views with a single operation.

travis.vitek over 8 years ago

The one problem I have found with pushing views is that there is no way to pop more than one view at a time

In the past, calling Ui.popView() for every view to pop has worked. The only caveat to this is in the MenuBehaviorDelegate.onMenuItem() handler for a menu. If you want to pop the view under the menu you are currently in, you need to pop twice, once for the the menu and then once the view. The automatic view pop behavior of the menu is disabled if you push/pop views from that handler.