Enter Widget Behavior

One of the doc pages[1] refers to an "Enter Widget" behavior. Quote:


Enter Widget: This is a new behavior specific to the widget app type.


However, I'm not seeing it documented in the API docs for the BehaviorDelegate[2].

Does this behavior exist yet? If not, what's the best way to detect an "enter widget" action?

Thanks,

Rick


---------
[1] http://developer.garmin.com/connect-iq/developer-tools/user-experience-guide/

[2] http://developer.garmin.com/downloads/connect-iq/monkey-c/doc/frames.html#!Toybox/WatchUi/BehaviorDelegate.html
  • I was poking around in `bin/*.debug.xml` and noticed two interesting things:

    1) A field called `behavior`
    2) A const called `BEHAVIOR_NONE`

    Turns out, BehaviorDelegate events have a `behavior` attribute which is used for dispatching.

    When the screen is tapped, an event with `behavior=0` is emitted. So, looks like I should be able to do something like:

    function handleEvent(evt) {
    if (evt.behavior == 0) {
    // Enter Widget
    }
    return Ui.BehaviorDelegate.handleEvent(evt);
    }
  • I have doubts that you need to do this. I'm fairly certain that the documentation you are looking at is out of date or incomplete. I believe that all you need to do is handle the enter key press and push a view onto the view stack to enter a widget.

    Be patient. One of the ConnectIQ guys will have an answer tomorrow morning.

    Travis
  • So my goal was to use `BehaviorDelegate` so as to be as cross-platform as possible.

    And with `BehaviorDelegate`, it doesn't appear that you get `KeyEvent`, `ClickEvent`, or `SwipeEvent`s (I used `instanceof` to verify this).

    So if I'm going to handle the `Enter` key, I suppose I would need to fallback to using a regular `InputDelegate`.
  • Former Member
    Former Member over 10 years ago
    The "Enter Widget" behavior is something that has not been implemented yet. For now, you will have to detect the screen tap for VivoActive, and the enter button for the other 3 products. We hope to add the Enter Widget behavior in a future update.
  • Former Member
    Former Member over 10 years ago
    It's also worth noting that the BehaviorDelegate extends the InputDelegate so you can listen for onTap() and onKey() inside a BehaviorDelegate.

    //! A custom BehaviorDelegate that lets us use the next and previous
    //! page events as well as adding an onEnter() event.
    class MyBehaviorDelegate extends Ui.BehaviorDelegate {

    hidden var mDevice;

    function initialize() {
    mDevice = Ui.loadResource(Rez.Strings.device);
    }

    //! Use the basic InputeDelegate to detect the enter key for the fenix 3
    //! and Forerunner 920.
    function onKey(evt) {
    if (evt.getKey() == Ui.KEY_ENTER) {
    if (mDevice.equals("fenix3") or mDevice.equals("fr920xt")) {
    return onEnter();
    }
    }

    return false;
    }

    // Used to detect the start of the round on a vivoactive
    function onTap(evt) {
    if (mDevice.equals("vivoactive")) {
    return onEnter();
    }
    return false;
    }

    //! An enter event has occurred. This is triggered the following ways:
    //! - vivoactive: a tap occurs
    //! - fenix 3: the enter key is pressed
    //! - Forerunner 920: the enter key is pressed
    //! @returns True if the event is handled
    function onEnter() {
    return false;
    }

    }


    The BehaviorDelegate is missing some functionality right now but this is a good way to work around it.
  • Ken,

    Does it really make sense to check the device type before responding to events? Pressing the action key on the vivoactive seems to be equivalent to pressing the enter key on the other devices in every way. It also seems that the tap event would only come through on a device with tap support.

    Travis
  • Former Member
    Former Member over 10 years ago
    The device check probably isn't necessary. I ripped this code from an expanded example that we're planning to make public in the future. The sample in question has been developed over time so some of the code in it was added to prevent bugs from rearing their head in earlier, bug filled firmware.
  • Thanks Ken, that code example is incredibly helpful!