Is it possible to unconditionally wake up my app from the background service?

I'm trying to develop a truly user friendly Alarm Clock application. I have my user interface just about where I want it to be, but I'm finding that it may not be possible to make it actually functional because I can't simply wake my app on demand from the background service and paly tones or vibrate for user attention.

Alternatively, is it possible to leave the app running but close all the Views and return to the watchface? (similarly to what music play apps appear to be doing) Then I could just use Timer() to monitor alarm times and trigger attention when needed, etc.

Top Replies

All Replies

  • You can use requestApplicationWake to ask the user if they want to open the main app.  You can't force it, as you don't know what the user is doing at the time.

    No tones or vibrations can be done in a background, but based in the device, requestApplicationWake may notify the user in some way.

    A background service runs without a view, but it can run at most every 5 minutes, and for at most, 30 seconds at a time.

  • so, pretty much useless for an alarm application. the user can't accept the wake request when they're sleeping

  • Nope. 

    Post a feature request in the bug reports forum. 

  • It doesn’t seem likely Garmin would ever add such a feature. It goes goes against philosophy of IQ not to allow things themselves to “take over” the watch. It might be chaos if Garmin allowed it. 

    (Apps can take over the device but the user makes the choice.)

  • Yes, but in theory it could be added in the future with some permission management system, so users would be able to install and use the app, and then when setting the "wake-up" the user would need to approve it.

    Even today it would be possible to add it with a less user-friendly way: a new permission that the apps that want to use this feature would need to add to the manifest. 

  • You are missing the point.

    Obviously, it’s possible.

    Newer developers sometime treat the Garmin devices as being “general purpose” computers that they can program anyway they want. The reality is that Garmin severely restricts what programs are allowed to do. One basic idea is that IQ programs enhance the device but can’t “take it over”’ in arbitrary ways. This preserves the behavior of the device. Developers need to get used to the limitations rather than try to work around them.

    Sure, Garmin could add it as a permission. That might just lead to many programs using it, which would be a mess (and a headache for Garmin).

  • Ultimately a requestApplicationWakeUnattended might not be against the philosophy that much, especially not if the 2 apps are written by the same author, it might just be an extension of the complication framework.

    It doesn’t seem likely Garmin would ever add such a feature. It goes goes against philosophy of IQ not to allow things themselves to “take over” the watch. It might be chaos if Garmin allowed it. 

    It's my hope if sufficient people keep requesting things like this we can come to a compromise. Power to the people, right?

    - Giving more power to a watch face (eg allowing it to vibrate x times a day) would be a solution for the OP. 

    - Making the requestApplicationWake function as intended (message accompanied by a vibration) would also be a solution for the OP.

  • I don't think it's just about new developers trying to work around the restrictions. It's about genuine features that many users want and ask for for years. I'm not talking about any specific feature or restriction, but in general.

  • Ultimately a requestApplicationWakeUnattended might not be against the philosophy that much, especially not if the 2 apps are written by the same author, it might just be an extension of the complication framework.

    Garmin has never shown any interest in providing this sort of behavior. 

    Power to the people, right?

    Not something IQ is really going for.

  • I don't think it's just about new developers trying to work around the restrictions. It's about genuine features that many users want and ask for for years. I'm not talking about any specific feature or restriction, but in general.

    Users don’t get it either. They often have less idea of the issues that features can lead to.