registering results in no currentuser

Using the iOS SDK it seems that calling registering doesn’t set or persist the current user. This appear to be because the code doesn’t call onLogin: or onUpdate: even though registering is clearly a login.

This should be corrected.

At the moment the code appears to force me to register the user and then login again explicitly in order to have the current user actually persisted and thus so I can continue to make logged in requests to the server…

I see that SDK v 3.0.22 made the currentUser on the user service editable where it was previously read-only. Does that mean that the intention is that when registering clients should now set the current user and then call setPersistentUser ?

It would really help to have a little documentation around this, and / or making the APIs a bit more open and flexible. getPersistentUser and setPersistentUser both taking no parameters and returning a BOOL is rather counterintuitive…

  1. No, currentUser must ONLY be set via login (simple, FB, Twitter or Google).

  2. getPersistentUser retrieves a local copy of currentUser (if isStayLoggedIn == true),
    setPersistentUser makes a local copy of currentUser (if isStayLoggedIn == true),
    resetPersistentUser removes a local copy of currentUser (if isStayLoggedIn == true), and sets isStayLoggedIn = false. But usually you should not use this calls, you need only to switch on/off the stay logged in mode, for example:

Backendless.sharedInstance().userService.setStayLoggedIn(true)

The problem is that even if you call stayLoggedIn before calling registering (to create a new user) that new user isn’t logged in afterwards. Sure, in some cases you want to be able to create a new user and not be logged in as that user afterwards, but in 99% of the cases (certainly on a mobile device) you do want to be logged in as that user after it’s been created.

Wain, you could call ‘login’ just after ‘registering’, what is a problem?

I can, and will. It isn’t ideal as it makes another network request and DB hit, which is slow. All of the required data is already on the client if only there was a call to make to set the current user…

Registering is not a login, it only may look so from the UI perspective. These are the two different operations, so they can’t be merged into one API call.