What's the best practice to communicate from the foreground app to the background app?

With Background.exit({...}) it is very easy and convenient to communicate background -> foreground. But is there a way to do the other way: foreground -> background. Kind of sending a job or a message?

Top Replies

jim_m_58 over 2 years ago +3 verified

The only way to pass info into the background service is to use Application.Properties or Application.Storage. In general, I only use Properties if there is are settings associated with it.

All Replies

+1 jim_m_58 over 2 years ago

The only way to pass info into the background service is to use Application.Properties or Application.Storage. In general, I only use Properties if there is are settings associated with it.

0 flocsy🤠 over 2 years ago

This is a horrible design! Why don't they fix it?

I mean OK, in the foreground: I add some data to the storage or property, then trigger a temporal event.

Then in the background: I read the data, do the job, and then I can't even delete the data, I need to pass something back to the foreground in order for it to be able to delete the data, that in the 1st place I only needed to communicate ...

0 flocsy🤠 over 2 years ago in reply to flocsy🤠

Even worse: There's not Timer in datafields, so if there are 2 "jobs" in my queue, I can't send the 2nd one (it's calling

Communications.makeWebRequest, but I have to wait until the 1st request finished, as far as I understand) and I can't use Timer to retry in a few seconds. So what am I supposed to do? Is there a way to sleep? Or should I call some "heavy" function? What's the slowest function you know that can be called from a datafield's background app? ;)

0 FlowState over 2 years ago in reply to flocsy🤠

flocsy🤠 said:
This is a horrible design! Why don't they fix it?

Evergreen comment

0 jim_m_58 over 2 years ago in reply to flocsy🤠

See Storage.deleteValue() in the API doc. You should be able to use it in a background service on some devices. Not sure why you want to, as in general, the background can run more than once when the main app isn't running.

0 jim_m_58 over 2 years ago in reply to flocsy🤠

No, you have to wait at least 5 minutes for another temporal event can run and manage your second request that does comm.

Think about this case. You have a background service that does a makeWebRequest, but in the callback you see a -104 status ("no phone") (or any error).

It's 5 minutes before you can try again

0 flocsy🤠 over 2 years ago in reply to jim_m_58

Thats true (and thanks for letting me know, 'cause I forgot) but what about the good case, when everything works, and I only need to wait for the 1st request to finish (successfully) in order to be able to send the 2nd request. For that I should not need to wait for 5 minutes.

0 flocsy🤠 over 2 years ago in reply to jim_m_58

Well, that would help if my app wasn't targetting CIQ 1.2.0 apps. Because of that I still need to have some solution for the older devices (or remove this feature from them)

Why I need to remove stuff from Storage? Because I put there "jobs", so when I successfully finished them they need to be removed, otherwise the next time the onTemporalEvent is called it executes them again. Plus the storage is only ever growing...

0 jim_m_58 over 2 years ago in reply to flocsy🤠

It's really not that hard if you undersant things and design your code accordingly. I have a couple of background services that do this.

Make request 1, and if in the callback, if the status is good, make request 2, and in the callback for that, if all went well, return the data With BackGround.exit()

You seem to be missing some basics in how background services work

0 flocsy🤠 over 2 years ago in reply to jim_m_58

This part almost works (for some reason onBackgroundData is no longer being called after I call Background.exit(nonNullValue)). The problem is in the function that is calling makeWebRequest, because it is possible that 2 jobs are being sent very close to each other, so the 1st job isn't finished yet when the 2nd arrives, and in that case I can't call makeWebRequest as far as I know, so I'm to "wait" which in this async world would be to use Timer if it was allowed in a datafield... Now I just call itself again and again...