behavior delegate

I'm gearing up to migrate my app to (the single-button, touch-screen) VA-3 and am revisiting the way I have been using input/behavior delegates.

Is this a documentation bug or am I confused?
onPreviousPage ⇒ Toybox::Lang::Boolean
Represents the Previous Page behavior.

This is typically triggered by the down button (KEY_DOWN) or by a SWIPE_DOWN SwipeEvent on a touch screen.

but on the VA-HR it appears to be triggered by the swipe right gesture in the Sim and on the watch.

  • Be sure to check out
    Adapting You App to the vivoactive 3

    If you use things like onPreviousPage(), it's there so the app doesn't need to know the specific behavior on different devices. On the va-hr, you got SWIPE_RIGHT,SWIPE_LEFT, SWIPE_DOWN and SWIPE_UP, but on the va3, SWIPE_RIGHT is actually onBack, and SWIPE_LEFT seems that it does nothing., and on the original va, you only have SWIPE_LEFT and SWIPE_RIGHT.

  • Yes, thanks Jim, I've read the material, but that wasn't what I was asking.
  • I think "This is typically triggered by.." comes into play here, as there are exceptions as I mentioned. Such as the original vivoactive, the va-hr, things like the edge/oregon/rino where SWIPE_RIGHT/SWIPE_LEFT also come into play. Maybe more details in the UX Guide as to what is used on specific devices?
  • OK, let me rephrase the question:

    According to the API documentation of the BehaviorDelegate's onNextPage callback:
    This is typically triggered by the up button (KEY_UP) or by a SWIPE_UP SwipeEvent on a touch screen.

    On the VA-HR, watch and in the sim, contrary to the doco, I find that the onNextPage is triggered by a swipe left gesture, and on the ApproachS60 in the SIM, it is also triggered by a swipe left gesture.

    On the VA-3 in the Sim, the onNextPage is triggered by a swipe up gesture (matches the doco).

    So which behavior can I expect in the VA-3 watch: the ApproachS60/VA-HR or the VA-3 sim?






  • Expect what you see in the sim. On the va3, a right swipe triggers onBack (but there's a bug as it doesn't if you have a standard menu as the top view), and left swipe doesn't trigger anything (that "only has one button" thing) You will however see it acts a bit differently on the S60, as it's got a hard "back" button and acts like the va-hr.
  • So how do I programmatically distinguish between an ApproachS60 and a VA-3 when the behavior delegate responds differently?
    They are both ROUND and both touchScreen but the AS60 triggers the onNextPage with a swipe left but the VA-3 onNextPage is triggered by a swipe up

    Do I have to abandon the behavior delegate and do all my UI input handling with the raw InputDelegate?
  • @jim_m_58,

    If you use the methods of the BehaviorDelegate you won't have access to information necessary to make a nicely flowing UI. i.e., if you only implement onNextPage() you don't know what value to pass as dir in the call to Ui.switchToView(..., dir).

    @RaceQs

    There are a few options that I can think of quickly to solve this problem. Both solutions involve using a build exclusion. The brute-force way to do it would be to implement a derived Ui.BehaviorDelegate for each device (or device family) in separate files then exclude all of those that you don't want. The other way would be to implement a simple lookup table that will get the transition to use given a behavior and use that lookup table to do the right thing.

    Here is a quick overview of what I'm talking about. Here is a sample exclusions file (you would only need entries for all supported devices, but not necessarily all devices)...

    <!-- resources-vivoactive3/exclusions.xml -->
    <build>
    <exclude dir="../resources-approachs60" />
    <exclude dir="../resources-d2bravo" />
    <exclude dir="../resources-d2bravo_titanium" />
    <exclude dir="../resources-d2charlie" />
    <exclude dir="../resources-edge_1000" />
    <exclude dir="../resources-edge_520" />
    <exclude dir="../resources-edge1030" />
    <exclude dir="../resources-edge820" />
    <exclude dir="../resources-epix" />
    <exclude dir="../resources-fenix3" />
    <exclude dir="../resources-fenix3_hr" />
    <exclude dir="../resources-fenix5" />
    <exclude dir="../resources-fenix5s" />
    <exclude dir="../resources-fenix5x" />
    <exclude dir="../resources-fenixchronos" />
    <exclude dir="../resources-fr230" />
    <exclude dir="../resources-fr235" />
    <exclude dir="../resources-fr630" />
    <exclude dir="../resources-fr735xt" />
    <exclude dir="../resources-fr920xt" />
    <exclude dir="../resources-fr935" />
    <exclude dir="../resources-oregon7xx" />
    <exclude dir="../resources-rino7xx" />
    <exclude dir="../resources-vivoactive" />
    <exclude dir="../resources-vivoactive_hr" />
    <!-- <exclude dir="../resources-vivoactive3" /> -->
    </build>



    Then here is the code to add for each supported device. Note that the mappings will be different for some devices. You can gather what values to use by looking at bin/devices.xml in the SDK and looking at devices in the simulator.

    // see attached text file...


    For a device like the fr920xt, you'd have something like this...

    // see attached text file


    Then you'd need a derived Ui.BehaviorDelegate that would do the right thing using the TRANSITIONS map.

    // see attached text file


    Now you would just inherit from FriendlyDelegate and when an input event occurs, you'd get the appropriate transition for the device (assuming you've added the appropriate entries into the device-specific TRANSITIONS.mc file).

    It seems another way to do this would be to cache information about the BehaviorDelegate function that was invoked and then return false. The system will invoke the InputDelegate function, and you'll be able to use the parameter that is passed to determine which direction to swipe and then know what function to call back. That might look something like this...

    // see attached text file


    Travis
  • So how do I programmatically distinguish between an ApproachS60 and a VA-3 when the behavior delegate responds differently?


    If you really need to tell exactly what device is being used, you can always use this.

  • With the S60 vs the va3 there are a couple if things you can check at runtime. The S60 doesn't have OHR or SensorHistory as two examples. You can use build file excludes like travis mentioned. Using part numbers is a bit tricky, in that a new APAC variant for something may be added with a new part number and is a bit harder to maintain, and apps can be "auto-migrated" for a new APCA variant, so you may not even know when it happens.
  • I think the way to distinguish between an S60 and a VA-3 lies in System.getDeviceSettings where I can determine which buttons the device supports.
    The S60 has a BUTTON_INPUT_MENU whereas the VA-3 does not.


    the attached code (which the Forum prevents me from posting:mad:) is revealing :
    VA-3 :
    BUTTON_INPUT_SELECT
    VA-HR:
    BUTTON_INPUT_MENU
    BUTTON_INPUT_SELECT
    S80:
    BUTTON_INPUT_MENU
    BUTTON_INPUT_SELECT
    F5/Q5/F5X
    BUTTON_INPUT_MENU
    BUTTON_INPUT_SELECT
    BUTTON_INPUT_UP

    Interestingly, in the Simulator, the F5, Q5 and F5X show BUTTON_INPUT_UP but not BUTTON_INPUT_DOWN.
    Could I ask someone with one of those devices to test on the device please?