Communication View/Delegate(/Controller)

Hi guys,

I am currently working on my first widget for Fenix 5 smartwatches and it is kind of working already. But I have a few questions about the general approach for app structures. I think I have understood how the delegation pattern is implemented in MonkeyC. Basically whenever a view can be defined the second array element can be passed as the delegation object that handles user input. Now the questions are:

1. what about the concept of controllers. I have found some examples "hacking" around to have a central object "controlling" the app (or app screen, which I would prefer), but this seems to not be a standard concept in MonkeyC, or am I missing something?
2. Communication between view and delegate: when a user does some input on the current app screen, what is the best way to tell the view to do something? A very simple example in my case is, I have one view containing a big text box (bigger then the screen height) and I would like to scroll down the text when the "page down" button is pressed. I am able to capture the key but how to tell the view to take action from the delegate object?
3. Is it possible to access the delegate from the view?
4. another topic: what buttons can be captured from the first widget screen? At the moment I have found "onSelect" and "onMenu" to be working. Is there any other button that can be used?

Thanks!

Bye

MoxyRoger over 7 years ago

For #3, You can pass the view in to the delegate when the view is pushed.

function getInitialView() {

        var view = new MyView();

        var delegate = new MyDelegate(view);

        var transition = Ui.SLIDE_UP

        Ui.switchToView(view, delegate, transition);

    }

In the delegate, use the initialize function to receive the view.

function initialize(_view)

        view = _view;

}

Then you can call a function or access a variable in the view from the delegate.

view.MyPageUpFunciton()

Talkabout over 7 years ago

For #3, You can pass the view in to the delegate when the view is pushed.

function getInitialView() { var view = new MyView(); var delegate = new MyDelegate(view); var transition = Ui.SLIDE_UP Ui.switchToView(view, delegate, transition); }

In the delegate, use the initialize function to receive the view.

function initialize(_view) view = _view; }

Then you can call a function or access a variable in the view from the delegate.

view.MyPageUpFunciton()

Yes, I saw this approach also. From other programming languages based on MVC I know that there controllers are taking also the role of the delegate objects. So maybe here in MonkeyC this could also be a valid approach, to simply instanciate the controller object passing the view instance to it and then pass it as delegate. The only disadvantage I can see here is the fact that in such a case the controller must inherit from the delegate base class (in my case the BehaviorDelegate). Would be much better if the class would need "only" to implement a specific interface to take the role of a delegate. That way a controller could handle all kinds of delegations... But fine then, I will try to do it that way, thanks!

Bye

travis.vitek over 7 years ago

In a well-designed application, it seems that the delegate should translate input events to actions and do nothing else. If this fits with your idea about how it should work, there is nothing wrong with throwing an additional class into the mix (other than the memory that it takes up).

It sounds like the design you are thinking of would look something like this...

+---------------+    +---------------+

|      View     |    | InputDelegate |

+-------^-------+    +-------^-------+

        |                    |           

        |                    |        

+-------+-------+    +---------------+    +---------------+   +---------------+

|    MyView     |    |   MyDelegate  +--->|  MyController +-->|    MyModel    |   

+---------------+    +---------------+    +---------------+   +---------------+

The controller is an independent class that does not necessarily inherit from anything from the framework. Your delegate class interprets input events and invokes methods on the controller. The controller notifies the model of changes of application state. The model manages the application state (business logic) and creates/pushes/pops new views, and the view class is dumb and just displays stuff. Technically the model would need a reference to the controller or the controller would have to be global so that the model can pass off the existing controller to new delegates when they are created, but that should not be a problem.

Travis