Acknowledged
3 months ago
CIQQA-3101

bug: vivoactive6 unusable

setActionMenuIndicator

vivoactive6 is so unbaked, there are more bugs than things that work, that I decided to stop supporting it until (if ever) it'll be fixed.

see some of the bugs I already opened:

https://forums.garmin.com/developer/connect-iq/i/bug-reports/bug-vivoactive6-button-area-inconsistent-with-visual-in-simulator

https://forums.garmin.com/developer/connect-iq/i/bug-reports/bug-position-enablelocationevents-crashes-in-vivoactive6

There are lot more, but honestly I don't feel like putting more energy into opening bug reports when clearly Garmin again haven't tried anything out before releasing it.

I'll give a few clues here:

- setActionMenuIndicator(null) doesn't behave as it's supposed to according to the docs.
- in some cases calling setActionMenuIndicator multiple times crashes the simulator: https://forums.garmin.com/developer/connect-iq/i/bug-reports/bug-repeated-call-of-setactionmenuindicator-crashes-simulator
- setActionMenuIndicator as opposed to what it's name hints does not only enable or disable the indicator, but also enables or disables whether the swipe triggers onActionMenu. While I can kind of understand if this was a deliberate decision, I am not sure if it was, and I am not sure if it's a good idea that we can only have now menus on va6 if we also have this ugly thing on the screen. In other words it might be a good idea to make it possible to enable the event triggering onActionMenu without the need to display the indicator.
flocsy🤠
Parents
  • 3 months ago

    > I am not sure if it's a good idea that we can only have now menus on va6 if we also have this ugly thing on the screen

    I think that's absolutely intentional as clearly the purpose of the action menu indicator is to indicate that there's an action menu.

    > In other words it might be a good idea to make it possible to enable the event triggering onActionMenu without the need to display the indicator.

    If you want to have your own non-standard way of opening an action menu, nothing prevents you from responding to literally any input and calling showActionMenu() (as could've been done in the past.)

    Speaking of onActionMenu, the docs for onActionMenu are confusing:

    "Represents the Action Menu behavior.

    This will be triggered when action menu is pushed. Invoke WatchUi.showActionMenu to push an action menu."

    Yes, I get what was trying to be said here, but the meaning of "action menu is pushed" is completely different from "push an action menu" in the next sentence, so I think it's a very poor choice of words. Here there's two different meanings for "action menu" and two different meanings for "push[ed]".

    "Action menu is pushed" clearly refers to the action menu indicator UI element, while "push an action menu" refers to an action menu view.

    I don't have a good way to rewrite this, but I think it should be something along the lines of:

    "Represents the Action Menu behavior.

    This will be triggered will be triggered when the user swipes left on the action menu indicator. On some devices, the user can also tap on the action menu indicator or press START while the action menu indicator is visible [*]

    Invoke WatchUi.showActionMenu to push an action menu view."

    [*] It's unclear to me whether Garmin actually wants to trigger onActionMenu if the user presses START while the action menu is visible, on 5-button watches. This would match native behaviour, but it could also be limiting to devs who may want to use the START button for something else.

Comment
  • 3 months ago

    > I am not sure if it's a good idea that we can only have now menus on va6 if we also have this ugly thing on the screen

    I think that's absolutely intentional as clearly the purpose of the action menu indicator is to indicate that there's an action menu.

    > In other words it might be a good idea to make it possible to enable the event triggering onActionMenu without the need to display the indicator.

    If you want to have your own non-standard way of opening an action menu, nothing prevents you from responding to literally any input and calling showActionMenu() (as could've been done in the past.)

    Speaking of onActionMenu, the docs for onActionMenu are confusing:

    "Represents the Action Menu behavior.

    This will be triggered when action menu is pushed. Invoke WatchUi.showActionMenu to push an action menu."

    Yes, I get what was trying to be said here, but the meaning of "action menu is pushed" is completely different from "push an action menu" in the next sentence, so I think it's a very poor choice of words. Here there's two different meanings for "action menu" and two different meanings for "push[ed]".

    "Action menu is pushed" clearly refers to the action menu indicator UI element, while "push an action menu" refers to an action menu view.

    I don't have a good way to rewrite this, but I think it should be something along the lines of:

    "Represents the Action Menu behavior.

    This will be triggered will be triggered when the user swipes left on the action menu indicator. On some devices, the user can also tap on the action menu indicator or press START while the action menu indicator is visible [*]

    Invoke WatchUi.showActionMenu to push an action menu view."

    [*] It's unclear to me whether Garmin actually wants to trigger onActionMenu if the user presses START while the action menu is visible, on 5-button watches. This would match native behaviour, but it could also be limiting to devs who may want to use the START button for something else.

Children
No Data