• Replies 7 replies
  • Subscribers 19 subscribers
  • Views 382 views
  • Users 0 members are here
Options
Related

Questions regarding onPress and Complications.exitTo(complicationID)

beva
1 month ago

1) Is there an alternative for onPress on none touchscreen devices? I expect so and that it also would raise the onPress event, but with Garmin I don't know for sure. If it can be triggered with use of the buttons, how does it work. I use it to toggle display modes. If it's not possible I need to add an option to my settingsmenu.

2) Complications.exitTo does not work while the watchface is not on screen as I don't use background services. When I start an activity I go back to the watchface as it has more valuable information for me. The activity app however claims focus whenever it likes, so my Complications.exitTo will not be executed (I use it when a certain value passes a set max value). Is there a user setting to force apps not to take focus?

That's all for now. Thanks in advance.

  • 1 month ago

    1) no

    2)  that's how it works. If you go to your watchface from within an activity, onPress does nothing.

  • 1 month ago in reply to jim_m_58

    Thanks I'll add some settings.

    Actually onPress works great and exitTo also does besides an active activity app with the watch face on the foreground (I tested this). It just does not work when the watchface is not on the foreground, I don't have a problem with that. I guess I could solve it to use background services and trigger exitTo from a complicationupdate, but that would use more battery as I understood.

    What another app imho should not do is taking control with no reason when a user went back to the watchface. So I wonder if there is a user/system or app setting to prevent that, but I doubt it. 

  • 1 month ago in reply to beva

    Adding a background service won't do anything  It won't handle onPress.  Even if it did, it runs at most every 5 minutes for at most 30 seconds at a time

  • 1 month ago in reply to jim_m_58
    jim_m_58 said:
    2)  that's how it works. If you go to your watchface from within an activity, onPress does nothing.

    That's not what beva is saying. beva is saying that they call Complications.exitTo() when something else happens in their watchface (not onPress()), and the problem is that if you return the watchface from an activity, the watchface doesn't stay on the screen forever - eventually the watch will return to the activity screen (at least on some devices, I guess - on my fr955, the watchface doesn't seem to timeout even if an activity is active.)

    jim_m_58 said:
    Adding a background service won't do anything  It won't handle onPress. 

    If you read carefully beva said exitTo(), not onPress() (in the hypothetical background service)

    (Nonetheless, I'm pretty sure neither System.exitTo() nor Complications.exitTo() will work from a background service)

    beva said:
    I guess I could solve it to use background services and trigger exitTo from a complicationupdate, but that would use more battery as I understood.

    If your app was a device app and not a watchface, you could've used Background.requestApplicationWake() to prompt the user to wake your app's foreground "process".

    As your app is a watchface, you *may* have one alternative: the new Notifications module/feature in CIQ 5.1.0.

    As per the Notifications SDK sample, a notification can be sent from the background or foreground - it displays a full-screen message (similar to native notifications, except icon and text only), along with a menu of actions specified by your app.

    When the user selects an action or dismisses the notification, the foreground app is notified.

    I don't *think* this will force the watchface to be displayed (although I haven't tried it and you could always test this for yourself), *but* you could ask the user to manually return to the watchface in the notification message. (Yeah, maybe not the best user experience.)

  • 1 month ago in reply to jim_m_58
    jim_m_58 said:
    2)  that's how it works. If you go to your watchface from within an activity, onPress does nothing.

    btw onPress does work for both CIQ and native [*] watchfaces, during an activity, as long as touch is enabled for the activity. At least that's how it works on my fr955.

    Perhaps you only tested with activities where touch was disabled.

    [*] inb4 "native watchfaces don't use CIQ so onPress is irrelevant". To be more precise I mean that during an activity (with touch enabled), a CIQ watchface still supports onPress and a native watchface still opens the associated glance/app when the user long presses a complication

  • 1 month ago in reply to FlowState

    I think it depends on the device.

  • 1 month ago

    It looks like (on the Venu 3) with the acitivity application running in it's main screen, it keeps in the watchface on top after swiping back to the watchface. I monitor a value and if it exceeds (without onpress) it pops up the associated glance with the activity running, if the watchface is on top. The activity now only takes back control if it needs to. I guess it might differ per activity as well. But there are scenario's where my interaction design is working how I'd expect it to :) .