onBackgroundData not called

I searched the forum, and read all the old threads related to onBackgroundData, but I can't find out why it's not working.

(:background)
class MyServiceDelegate extends System.ServiceDelegate {

	function initialize() {
		Background.exit("this works");
	}
	
	function onTemporalEvent() as Void {
		log("onTemporalEvent");
		// Background.exit("test1");
		doTheWork();
		// Background.exit("test2");
	}
}

My problem is that onBackgroundData is not being called after I call Background.exit(non null String or Number); The only place where it works is when I call it from the constructor of the ServiceDelegate, which of course makes no sense, because then the job didn't even start yet, but at least it proves that the onBackgroundData in the foreground app is OK.

When I call Background.exit("str") from anywhere else (my real place is the onReceive callback of makeWebRequest, but even if I call it from the beginning of onTemporalEvent) onBackgroundData is not called. What can be the culprit?

SDK 4.1.7, simulator, fr255, datafield

  • 1. Of course you call ServiceDelegate.initialize()?

    2. I use dictionary in exit and it runs well, so first try putting string/num into dictionary.

    3. From time to time background hangs so close/run sim.

  • 1. Not any more, i removed it 'cause i didn't see any difference (besides sparing some bytes of code). Is it necessary to call?

    2. I'll try tomorrow

    3. I see that onStop still logs and at the next temporal event background (new process i suppose) runs so i don't think it hang.

  • How are you testing this?  This has consistantly worked for me and many other for 5 years.  Are you forgetting the "every 5 minutes at most rule?  Log when onTemporalEvent is called so you can see when things happen.

  • 1. I've noticed you don't call it. You save a few bytes but don't know if based class need initialize something. So you can expect strange behaviours.

  • You all miss the point IMHO:

    1. added back ServiceDelegate.initialize(); but it's the same

    2. the point is that all the 5 minutes rule, etc is nice but if that would be part of the problem then what wouldn't be called would be the "BackgroundApp".initialize() or "BackgroundApp".getServiceDelegate() or MyServiceDelegate.onTemporalEvent(). But those are called. What is not called is "ForegroundApp".onBackgroundData() after I call Bacground.exit("foo") in the background app.

  • Have you already tested exit with dictionary?

  • I've had zero issue returning a dictionary, number, string or array with Background.exit(), with or without comm involved.

    As have many others.  It's got to be something about the app.

  • I kind of agree, but I can't find what's the difference between when I call Background.exit("x") in MyServiceDelegate.initialize (when it works) and in MyServiceDelagate.onTemporalEvent (when it doesn't work)

    Note that even when I comment out the call to doTheWork() it doesn't work.

  • Is the pretty printer involved. or is your code being compiled as written?  That's something that could be different for you and everyone else.  Background.exit() is really basic, and had been working for others for years.

  • From further investigation it looks like this doesn't work in exactly the scenarios that I use: when in the background app I send a web request (either from "Background"AppBase.onAppUpdate or ServiceDelegate.onTemporalEvent) and I want to wait for the response (who doesn't want?) and so I only call Background.exit from the onReceive callback of Communications.makeWebRequest, THEN "Foreground"AppBase.onBackgroundData isn't called.

    I am sure that there's something I don't do right, or I don't understand how this is supposed to work, because in my mind the only reason for having Background.exit in the SDK is to let the background app wait for the webrequest's response, and only stop the background app after the response is received AND pass the data back to the foreground app.

    No, pretty printer is not involved, I am testing it in the simulator on fr255, with the regular garmin compiler only, no optimization.