QuickBlox user sign up and creating a custom table

问题:

I'm supporting a "gender" field for mobile user registration (iOS). To do so I employ a custom table (named UserResourceTable, URT) to store the gender field (integer), and I rely on the owner of the table being the user to look up the corresponding URT table for each user.

Tell me if the following scenario is an correct implementation.

On user signup to the service, I have an designated pre-existing app account which create the user account (presumably because someone has to login to the service to create the account in the first place, right?). Simultaneously, I want to create the URT and store the gender field. That requires at least two passes to the QuickBlox server, one to create the user account, and one to create the URT table.

However if I create the URT with the pre-existing app account, the owner is going to be that account instead of the mobile users. Is then the correct registration sequence be that the user log in first, and then to create the URT? Or is there a way to assign the ownership to another account? The three HTTP requests for me seems a little excessive, I'm afraid that (1) it may take too long, or (2) if something went wrong I'll be in a inconsistent state, and I need to ask the user for the gender again on the user's next log in.

回答1:

On user signup to the service, I have an designated pre-existing app account which create the user account (presumably because someone has to login to the service to create the account in the first place, right?).

To create new user you actually don't need pre-existing app account which create the user account. According to QuickBlox iOS documentation - you can create user with Application session token (not User session token) http://quickblox.com/developers/IOS#A_couple_of_words_about_Authentication_and_Authorization

However if I create the URT with the pre-existing app account, the owner is going to be that account instead of the mobile users.

You are right, this is bad solution

I see 2 ways how to do this:

1) Use CustomObjects to store gender (as you propose).

In this case you need to perform 3 queries:

1. User Sign Up
2. User Sign In
3. Create CustomObjects record

2) Use Users tags API

In this case you need to perform only 1 query - User Sign Up:

QBUUser *user = [QBUUser user];
user.email = @"[e-mail]";
user.password = @"qbuserr345";
user.tags = @[@"male"]; // or female

[QBUsers signUp:user delegate:self];

To retrieve all 'male' users or 'female':

[QBUsers usersWithTags:@[@"male"] delegate:self];