How to check if the value was saved


#1

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)

here is the snippet :

 if(data.code == 200){
    console.log('success');
     this.storage.set('phone',this.cLog.value.phone);
    this.navCtrl.push(this.customer,{phone : this.cLog.value.phone});
    
  }

#2

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.


#3

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


#4

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?


#5

no , but I didn’t find a working way to transfer the phone number with navParams


#6

OK, let’s ditch storage, then. What did you try with NavParams and how did what happened differ from what you desired?


#7

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 ?


#8

I would use a shared service for this.

interface User {
  phone: string;
  // whatever else
}

LoginPage {
  constructor(private _auth: AuthService, private _uisvc: UserInfoService, private _nav: NavController) {}
  login(): void {
    this._uisvc.getUserInfo(this.form.whatever).subscribe((ui) => {
      this._auth.user = ui;
      this._nav.push(DashboardPage);
    });
  }
}

AnyOtherPage {
  constructor(private _auth: AuthService) {}
  doSomething(): void {
    relyOn(this._auth.user);
  }
}

AuthService {
  user: User;
}

UserInfoService {
  constructor(private _http: Http) {}
  getUserInfo(whatever): Observable<User> {
    return this._http.get(url + whatever).map(rsp => rsp.json());
  }
}

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.


#9

I didn’t understand the code or how to use it , is there a reference I can refer to or a simpler solution ?
thanks !


#10

Didn’t understand which code? The code posted in this thread, or the one linked to about using subscriptions?


#11

the one you posted in this thread


#12

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.


#13

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


#14

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.


#15

I don’t understand how the shared instance work actually it’s not about the names in the code. I’ll do some search to try to understand hoe it works.


#16

Here’s the official DI documentation.

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.


#17

ummm I think I understood the concept now !
thank you so much <3