ngOnInit runs once during component initialization and then the page is stored on the stack. So only ionViewWillEnter and ionViewDidEnter fire after that when navigating back to the page.
If I close the app on my iOS or Android device and then open it again ngOnInit runs. So obviously the stack is cleared when the app is closed.
If I leave the app for a few days and come back?
Sometimes it seems that ngOnInit runs although I can’t be 100% sure. Is there a time limit and then the page expires or something or the app is closed by the OS after a period of not being used?
I reload some data on the ngOnInit and I would like to know in which situations this reloads.
Also when are the variables in services cleared.
This seems to happen when the app is closed and reopened, does it happen any other time?
I don’t mean this to sound dismissive or disrespectful, but IMHO you don’t actually want to know this.
The reason I say that is that today’s answer might not be tomorrow’s answer, and once I “know” how things work today, I tend to (sometimes subconsciously, even) rely on the implementation details, which is a recipe for confusing bugs of the “damn, this always used to work” variety.
ngOnDestroy are paired. You can rely on the fact that (if you implement both), neither will be called twice in a row without an intervening call to the other. That’s pretty much it.
You’re probably tired of seeing me flog this post, but I think you will be happier in the long run if you manage your data flow independently of Angular lifecycle events. Lifecycle events are about view-layer concerns, and IMHO it’s therefore awkward to try to force them into playing roles in model-layer-land.
All of that being said, if you’re still reading, yes, you’re basically right, and it’s not totally predictable.
The OS can reap your application at its sole discretion, if it decides it can better use the resources your app is consuming. You can subscribe to
resume events to catch this. I sometimes do this, in order to “re-launch” things that are done only at launch time when the app is resumed. There is no explicit time limit - it’s all at the whim of the OS process scheduling.
pause will also vaporize and re-instantiate services.
Thanks. I do use the model in your post for most of my data.
This was almost static data. Very rarely updated so I didn’t bother to watch it.
I was performing a few actions such as subscribing to push notifications etc on the ngOnInit but that meant if a user logged out and a new user registered they the ngOnInit would not fire and they would not get the push notifications.
Anyway I am taking your advice and moving it to be more driven from the data.
I use Firebase so for a lot of my data I listen for any changes and then the updates are automatically propagated through the app. However this can get expensive due to the cost of reads.
For example the data I was loading on ngOnInit was the appSettings which rarely change.
I am now listening to this data in Firestore so it is always up to date and propagated through the app pages by observables / subjects similar to your example.
However if a 3 separate changes are made and there are 10,000 users with the app open this will cost me 30,000 reads.
The user never really logs out so I guess another option would be to refresh the data once a week or once a day. I can’t really think of a user or data event that could be used to load the data.
Ideally it would be refreshed when the user uses the app again after a certain period of time away.
I think you may have just answered your own question.
You could create some sort of
ActivityService that keeps an internal timer that is reset each time the user “does something”. If the timer ever gets up to N, then go hit the backend and collect the latest settings.
RxJS has some operators that could be wrangled into doing this: it’s sort of similar to “how do I debounce keyboard inputs so that my search function doesn’t spam my backend?”.