Hi
I have a login screen which register the phone number of the user , but the problem is that some times the new view get pushed before saving the value which cause some problems like(in testing some times when we login with one user and then login with another one , we get the data of the first user instead of the new one)
Assuming you’re retrieving phone out of the NavParams in whatever page this.customer refers to, the problem lies outside the code you have posted, because NavParams are synchronous.
Incidentally, I would not have page code looking at HTTP response codes (or interacting directly with storage, for that matter). That’s better done in a service that provides an Observable of some business object. Pages should not know where business data is coming from or going to. Their only concern is what is in the business logic objects and passing them to and from services.
the phone number is from a form in the same page , I tried to transfer the phone number to the customer page with navParams but I faced some problems that’s why I used storage instead
The #1 question you should ask yourself when considering “do I want to put this in storage?” is “do I want it to persist across app restarts?”. Do you?
the problem is that the next view is tabs view , to make it easier to understand :
I have a login screen , when the login success I navigate to the tabs page (to show the tabs and the pages ).
Now the problem here is how can I access the data from one of the pages while I navigated to the tabs page ?
My personal preference when dealing with login/logout is to handle it all in a subscription in the app component, so I never deal with the NavController at all. Details here if you want to consider that approach.
Hmm. The code I posted in this thread is simpler and more tailored to your exact use case than any generic reference I know of, but maybe either chapter 4 of the Tour of Heroes or the cookbook entry on component interaction would be useful? Look at the very last entry of the cookbook, and ignore defining custom providers on component trees, because you just want to have an app singleton, so you only put it in the app module.
Oh, and you’re going to have to trust me on this, but a shared service really is the simplest solution here. Storage, as you’ve discovered, comes with unnecessary synchronization complications.
yes I’m convinced that the shared service is a better solution , but I couldn’t understand your code , that’s why I asked for a reference.
I’ll take another look at the code
The “whatever” bits are because I don’t know what information you need to pass to your backend to get an authenticated User object. I assume it’s going to be something (like username/password) entered in a form on LoginPage. DashboardPage can use the idiom of AnyOtherPage to access the authenticated User object held in AuthService.
Imagine you’re trying to talk to people at a company. You say “I want the chief financial officer”, and the company gives you some person named Amy. You give Amy a camel. The next day somebody else shows up, asks for the CFO, and says “can you show me an animal?”. Amy shows them her camel.
That’s basically what is going on here. Each page that declares a public or private constructor parameter gets the object (Amy) who fulfills the type (AuthService = “chief financial officer”). The AuthService has a user property that is Amy’s camel. The LoginPage gives her the camel, and every other page can just inject public amy: CFO and see her camel. Angular’s DI system is responsible for making sure any time somebody asks for a CFO, they get Amy.