I have a page that shows item details, and can be pushed infinitely to keep looking at new data. I need to disable the cache for this view so that it will not keep storing listeners and html for potentially a large amount of nav pushes through history.
Is there a view-cache=“false” equivalent in Ionic 2 that will prevent the component from being cached?
Thanks for any help!
Hi, you can use the ionViewDidEnter function as discribed in the documents.
ionViewDidEnter Runs when the page has fully entered and is now the active page. This event will fire, whether it was the first load or a cached page.
EDIT: I mean ionViewDidEnter not ionViewWillEnter(if that is any help…)
Thanks S.G. I’m using ionViewWillEnter and it is working fine. The issue is that ionic is continuing to cache every page as the user continues to push() new pages, which adds to memory and event listener heap. Eventually the app is taking 10 seconds to respond to events.
I need Ionic to not cache the pages after they are no longer the active page, so that the memory / event listeners heap doesn’t increase everytime. This was possible with the ion-view cache=false in v1.
Thanks!
If you don’t ever want to return to these old pages, can you achieve your goal using setRoot instead of push?
This is my user’s navigation path:
home => shelf => item1 => item2 => item3 …=> item15
They need to be able to hit back and traverse through these items again. However, the app doesn’t need all these pages to be sitting in memory with active event listeners ad nasuem. They should be able to pop() back and have the page reload its data as if it was new because it wasn’t caching the template and listeners.
Slicing the history state to only keep a max history entries also doesn’t work, because the user needs to be able to traverse back through the pages.
Is the answer that ionic does not provide support for dumping the cache of pages while keeping their history entries intact anymore?
If event listeners are your primary concern, you can set them up in ionViewWillEnter and tear them down in ionViewWillLeave. I frequently do that with subscriptions to observables. My understanding is that if you want pushed pages to be destroyed, you must explicitly pop them, although I am not positive about this.
It seems the template state that is causing all the listeners, they are all still in the digest loop, not any custom ones i’ve set.
I get that this isn’t a huge deal for apps, but for the progressive web it would seem that there should be a way to say "don’t cache this " so that its not sitting in memory just because there is a history state attached to it, but maybe i’m the crazy one here. Surely Amazon doesn’t cache every page as you click through each item page to the next, while also maintaining a history of traversing back through your navigation history.
Hi!
I have a similar problem!
I have an app that is based on tabs and I want that when I choose one of that tabs, when I return to the first one it will reprocess all that page, instead of using cached memory.
Do anyone have an idea how to do it?
Thanks
Checkout the life cycles.
ionViewWillEnter(){
// your code here
}
Thank you for your help, but that doesn’t work.
If you have previously load one tab, when you return to that tab it will not be reloaded, and everything that you put inside ionViewWillEnter or other lify cycle method will only be processed when you click a seconde time on that tab.
have you got any work around? i also facing same issue
You need to remove the pages from nav stack. You may refer the below discussion or search for removing pages from navigation stack.
https://forum.ionicframework.com/t/navcontroller-remove-pages-from-history-to-improve-navigation/76951
2 years later… has anyone figured this out? I am having troubles with Cypress finding target elements in multiple of these hidden zombie pages in ion-router-outlet; It seems like it would be nice if we could just not cache them!
I am just amazed how this isn’t being addressed in some way by Ionic. The Ionic life cycle hooks are not sufficient for covering all use cases. Yes, you can use them to clean after yourself but let’s not forget that these are specific to page components. This enforces you to move functionality/state–that you might normally keep in a child component–in your pages which undermines encapsulation.
In my case, I want to recreate a page every time the user navigates to it due to security reasons and it is vital to not keep it cached in memory. I am sure that there are plenty of other uses cases which make feature like this absolutely valid and valuable to the developer.
That’s a pretty strong statement. Personally, I would much rather prefer that frameworks have the absolute freedom to handle lifecycle management as they see fit to improve performance and resource usage. Unfortunately, it seems impossible to satisfy both of us, so perhaps we can solve your problem some other way.
My basic take on mobile app security is that anything “vital” needs to be done on servers under my control, but to flesh that out a bit, the first big division among threats is whether or not you trust the device owner / user.
If you don’t trust the device owner, then absolutely nothing you try to do on the device can be secure. Our blackhat could be running it in an emulator that can step through your code, change internals at will, and see any secrets that are baked therein. So if that’s the situation you’re in, I think you need to redesign the protocol so that everything “vital” happens on the server.
If you do trust the device owner, then the biggest next class of problems is “OK, what happens if blackhat steals our user’s phone?”. Let’s say that’s where you are, because that’s the only place that we can do anything in the mobile app code. The next question is “can we trust the device lockcode?”. Here’s where most of the security/usability tradeoffs come in. Deciding to trust the device locking system allows you to relax a bit, as you can use things like Ionic Secure Storage or other similar systems that store sensitive information in OS-locked vaults. If you can’t trust the device lockcode, then I would recommend having the user enter a passphrase at app startup and using a KDF such as bcrypt to derive a symmetric encryption key.
So I’m trying to imagine what could possibly be on your super-sekrit page, and my best guess is something like a one-time-password. If it’s something like that, then you could ping the server upon navigating away from that page, telling it to invalidate the token. Combine that with a server-side timeout, and you’ve defanged any problems that could come from having the OTP redisplayed.
TL;DR: I think there should be a way to design away your problem, and if you would like to continue the conversation about how to do that, it would be extremely useful to know exactly what’s on this secret page, and what the exact threat scenario you’re concerned about is.
It’s a page that collects sensitive information which must be cleared/destroyed upon navigation. I am well-aware that I cannot trust the client. It’s just that this behavior resulted in a bug that could’ve gone unnoticed for a quite a while. The problem is already solved and I am currently experimenting with a general solution that should hopefully cover most of, if not all of, my use cases. Anyway, thank you for the offered help.
Nevertheless, I still think that this is something that will be valuable to the developer. I am not saying that Ionic should change its default behavior, but having an option to instruct it to just “don’t keep in state, if not visible” when needed will be a great tool to have.
I realize that frameworks are in a way “forcing” you to use certain programming patterns. In the end, that’s one of their tasks. But, I somehow fail to see how this specific behavior (or the inability to alter it) is predisposing to a necessarily good design considering the lengths that you should go in order to achieve something that can be ultimately done with a single line of code. Maybe it’s just me and my subjective opinion …
What I would do in that case would be to keep the wellspring of the sensitive information in a service, expose it as an Observable, and then upon whatever the “burn” signal is, push out a dummy “empty” value. That way, if the page gets cached, it gets cached in a “dormant” state with no sensitive information.
I guess that depends on how one defines “good design”. To me, part of “good” app design is staying in my lane so that the framework can handle the gnarly concepts of ownership and lifecycle management that have plagued humanity since malloc was invented.
It could still be done with a single line of code if you move the source of truth out of the page.
And to be clear, I’m not arguing that my subjective opinion is somehow inherently superior to your subjective opinion. It does, however, appear to be different on this topic.
I can say the same. I am not arguing that mine is better. I am expressing an opinion that we should be given the option rather than doing it “this way” or “that way”. Your point is that the framework should be in charge of it and to some extent–I agree. Certain things should be kept away from the hands of the developer, that’s fair. Rather, we are arguing where the line between “Developer can alter that” and “Framework should take care” must be drawn.
It’s not about storing/supplying data. In my specific case, I am using some global event handlers that I would like to just eradicate, if the component is not visible. I don’t want them to be part of a separate entity, I want them inside the component. Yes, these components can be designed differently. Yes, if we take into account this Ionic behavior, the components must be pure, dumb as possible. Sure, that has its own benefits and applications. What I don’t agree with is that this should be The Ultimate Way of doing things.