iOS sometimes loses angular variables when resuming from the background

[trfletch]

@rapropos

That’s an improvement, but if you’re following the idiom of “only read from storage at startup”, there’s no need to wait on the write to storage.

Yes good point, I think when I wrote most of my write to storage methods a few years ago I probably just copied them from ones where I was reading from storage where I, of course, need to wait for it to read, I do have a couple where it writes that I do want to wait because I need to be sure the data has been written to local storage before the next action happens to prevent any data loss but on this occasion, as you say there is no need to wait.

@rapropos

While there’s nothing wrong with the code here, another option for jobSource’s type would be BehaviorSubject<Job | undefined>. asObservable is also not needed: you can simply return jobSource as an Observable<Job | undefined>, tsc will take care of enforcing attempts to pierce the implementation veil. I also dislike providedIn: 'root' because it makes it impossible to mock the service out for testing purposes.

Okay I will take a look at that, I wrote this method recently when migrating from Ionic 3 to Ionic 5 based on a recommendation (within a blog post) of using ReplaySubject rather than BehaviourSubject but I cannot remember the reasons they suggested ReplaySubject instead!

@rapropos

This is a good question, and why I recommend never exposing properties of services - only methods. If instead of allowing outside clients to access currentJob, if they had to go through a peekJob (which gives a snapshot) or watchJob (giving an Observable) method, then your service could have a chance to recognize the situation you’re running into, where its data has been lost out from under it, and recover seamlessly without the client ever being aware.

That makes sense so I guess it would mean modifying your peekJob example to check if it was undefined and if so return it from local storage? I assume this wouldn’t cause a problem the fact that local storage would be returning a promise that I would need to wait for?

@rapropos

The second post l linked previously exposes the trio of peek/poke/watch operations that I find convenient. The way you are using the data now could be easily adapted to just call peek once at construction. This gives you a snapshot - the upside is that you don’t have to manage any subscriptions; the downside is that updates cannot be pushed.

Do you recommend calling these within the “constructor” as opposed to within “ionViewWillEnter”? If so what is the reason for this? Do we know if the “constructor” of a page gets called when the App resumes from the background which I think “ionViewWillEnter” does? My concern is that the peek/poke/watch etc will also get lost when iOS does whatever it is doing that is causing my problem.

@rapropos

If you’re using Capacitor, you could look at appStateChange to receive notifications of your app being paused and resumed, which might offer you opportunities to refresh things from storage on returning to the foreground.

I am not using Capacitor but I do have the following within app.component.ts which I assume would do the same thing?

// When App resumes from background
    this.platform.resume.subscribe(() => {
      // do the stuff
   }