Background.registerForTemporalEvent update problem.

Hello, I have a question and I would like to ask for your help if possible.
Here I will describe my problem in more detail.
I am making a WatchFace (only for myself), I use OpenWeatherMap as a provider for weather data.

When I try to call Refresh weather, sometimes it only updates after an hour.
Is there any way to detect that the weather update failed and call it immediately (back)? I know that Background.registerForTemporalEvent
can only be called every five minutes, but I don't know how to call the update request back.
The weather refresh interval is set by myself via Application.Properties.getValue("WU")
Before I wrote to this forum, I tried to find a solution that would be useful but unsuccessfully.

Here I am attaching my code that I am using:

var lastTime = Background.getLastTemporalEventTime();
var nextEvent = lastTime != null ? lastTime.add(new Time.Duration(5)) : Time.now();
Background.registerForTemporalEvent(nextEvent);
System.println("WU =  5 min.");
}
            } else {
            
            }   
  Background.registerForTemporalEvent(new Time.Duration(Application.Properties.getValue("WU") * 60));
System.println("WU User."+ Application.Properties.getValue("WU"));
            }
        }

Thank you

  • Hello. Thank you for the explanation and clarification of how everything works. I would definitely be more excited about the option - a function that evaluates whether it is A or B, but I am not as good a programmer in MonkeyC as you are.
    It is clear that you have a wealth of experience in this area, which is invaluable.

    For now, I have to make do with what I have (what you suggested). Yes, as you write, when the network is disconnected, it is inefficient to send requests every five minutes, but on the other hand, it can also be used effectively, that if you do not receive data after an interval of five minutes, a small icon or inscription appears on the watch display, notifying you that you are out of the network.

    It would be good to see at least the option you describe in the tutorial, but it is your time and no one will pay you for it, so I am not forcing you to do anything. I have been looking for a WF in the store for a long time that would meet the criteria I needed, but I have not found it. That's why I decided, even though I have a different profession, to dedicate myself to creating my own WF.

    Thank you again for your great help.

  • a function that evaluates whether it is A or B,

    To be clear, I meant that A and B are different possibilities for how backgrounding works in general, not that I think A would be true sometimes and B would be true in other cases.

    I think B is true, and I think you think A is true.

    If B is true then you should probably get what you want: when the network state changes from disabled to enabled, the next temporal event should happen as soon as possible (either now or 5 minutes from the previous temporal event.)

    Either way I think it is unnecessary to change the update interval to 5 minutes.

    Honestly, I am not 100% sure as I've only played with backgrounding with some simple apps in the sim and real device. The way to determine which one is true would be to test extensively on a real device.

    As far as writing a function goes, I guess you could write a function to somehow notify yourself that a temporal event was triggered (change some part of the display) or you could log the temporal events with println. Or you could just observe how long it takes for the weather to update.

    It is clear that you have a wealth of experience in this area, which is invaluable.

    I am not really the biggest expert in all things Connect IQ, I just apply my skills as a software developer in my day job to Connect IQ as a hobby.

    As I said, I haven't written a "real app" that uses backgrounding, just played with some test apps.

    Yes, as you write, when the network is disconnected, it is inefficient to send requests every five minutes, but on the other hand, it can also be used effectively, that if you do not receive data after an interval of five minutes, a small icon or inscription appears on the watch display, notifying you that you are out of the network.

    When the network is disconnected (meaning connectionAvailable / phoneConnected is false), it's impossible for network requests to succeed, so it doesn't help to at all to send requests every 5 minutes. All of those requests will fail.

    It might be ok to try to send those requests anyway (if that makes the code simpler), but there's seemingly no reason to change the update period to 5 minutes.

    You can already display an icon on the watchface to show that the network (or rather, bluetooth) is disabled, without even trying the requests.

    Many CIQ watchfaces show a bluetooth connected/disconnected icon based on phoneConnected. (Notice that they don't typically show connectionAvailable, as bluetooth is of primary importance to most users. Wi-Fi is rarely available to CIQ on watches, as it's only active in some limited cases.)

    I just don't see the point, but since you requested that behaviour, that's what I put in the sample.

  • Here's a whole writeup about backgrounding

    https://developer.garmin.com/connect-iq/connect-iq-faq/how-do-i-create-a-connect-iq-background-service/#howdoicreateaconnectiqbackgroundservice

    And a very simple example with lots of comments in the thread including using makeWeubRequest calls.  This sample doesn't do any sort of comm, but shows the basics.

    https://forums.garmin.com/developer/connect-iq/f/discussion/5287/very-simple-sample-of-a-watch-face-with-a-background-process

    This one is a bit more complex as it uses BLE and a sensor to get weather info in the background:

    https://forums.garmin.com/developer/connect-iq/f/discussion/8182/a-very-simple-wf-with-a-background-that-talks-ble-to-the-thingy52

    For me, I default to every 15 minutes for requesting weather data in widgets and watch faces, but the user can make that shorter or longer, and if there is an error getting the data, I show the last good data I've seen (usually including the time of the data) for up to 4 hours.

    I can lose the phone connection by just microwaving my coffee when a request is being made, but still have the last data, and the next request will be in a few minutes.  Based on the provider as well as the specific weather station, it could be that the data isn't updated that often anyway