I am using iOS sdk 3.0. I have created a custom user sublclass as explained in http://devcenter.kinvey.com/ios-v3.0/guides/users#CustomAttributesCustomUserObject

below is my SDK initializatin code in appDelegate:

aKinvey.sharedClient.userType = CustomKinveyUser.self

       Kinvey.sharedClient.initialize(

            appKey: "kid_xxxxx",

            appSecret: "my-app-secret"

        )

The CustomKinveyUser class looks like:

class CustomKinveyUser: Kinvey.User {

    var profilePicURL: String?

    override func mapping(map: Map) {

        super.mapping(map: map)

        profilePicURL <- map["profilePicURL"]

    }

}

At some point in the app, after I have a logged-in session,  I am doing this - 

 guard let user = Client.sharedClient.activeUser as? CustomKinveyUser else {return}

The above line works and user is non-nil and is of type CustomKinveyUser

if and only if I have signed in during that particular launch of the app.

However, in subsequent app launches if I  already have a signed-in session, Client.sharedClient.activeUser returns a non-nil object as expected, but the class type is the base user class (Kinvey.User) instead of CustomKinveyUser and so the downcast fails (i.e the as? CustomKinveyUser part returns nil) 

captured from the xcode console:

(lldb) po Client.sharedClient.activeUser

▿ Optional<User>

  ▿ some : <__KNVUser: 0x7fdf34e829d0>

Hi Pravav,

If it helps, here is a fix:

The culprit is this line in initialize(  with all params ) func  in Client.swift

let user = Mapper<User>().map(JSON: json) 

 It ignores the `userType` while unarchiving the saved user and always instantiates the saved JSON using Kinvey.User class.

Replacing it by what is done in the API-response parsing flow in (JsonResponseParser's parseUser function) fixes the problem:

 let map = Map(mappingType: .fromJSON, JSON: json)
 let user = userType.init(map: map)
user?.mapping(map: map)

Hi All,

The fix suggested I have found to not work when calling customUser.logout(), nothing happens.

Hey Pranav,

I noticed that Niraj's fix is not in the latest version released about a week ago, 3.3.7. Is a fix in the works for that or should one of us create a pull request?

Any update on this issue?  I am still unable to use CustomUser on the initial viewController if the user is not forced to login every time.  Downcasting the User to a CustomUser only works when logging in.

Thanks,

James

Thanks for looking into it, Pranav.

The above code works because you are checking for the type returned by Client.sharedClient.activeUser right after logging in. It will return CustomUser if you call it any time in the future unless you kill the app.

What I am doing on every cold launch of the app is I am checking the value returned by Client.sharedClient.activeUser and only if activeUser is nil, I am showing the login screen and calling User.login().

This is a very common use case ( require users to login only if can't find saved credentials)

To reproduce the problem I am seeing, you'll have to check for activeUser before making your  login call ( and skip the login call if activeUser is not nil) :

if let activeUser = Client.sharedClient.activeUser {
  if let customUser = activeUser as? CustomUser {
      print("Yeah! We have an activeUser:  \(activeUser) and it is of type CustomUser. We can skip the call to Login")
   } else {
      fatalError("We have an activeUser: \(activeUser) but it's not of type CustomUser")
   }
} else  {
   User.login(username: "mind1", password: "mind1") { user, error in
            if let user = user as? CustomUser {
                //the log-in was successful and the user is now the active user and credentials saved
                //hide log-in view and show main app content
                print("User: \(user)")
                print(user.address)
                guard let user1 = Client.sharedClient.activeUser as? CustomUser else {return}
                print(user1.address)
}

If you do a clean install of you app with the above code, then it will call User.Login in the first run because activeUser will be nil.

 However, if you kill the app and re-run it, you'd expect it to print "Yeah! We have an activeUser: ....", but instead it will go to the else part to abort your app with the fatalError.

I dived a bit into Kinvey SDK's implementation of custom User class and it seems this problem has to do with the difference between how the User object is retrieved from its in-memory version VS its archived version (version that is persisted and un-archived on app launch). After a successful User.login() call, the SDK respects the type set in sharedClient.userType and instantiates the correct sublcass to assign to activeUser. This is somehow not true when after you initialize the SDK on cold app launch. In that case, sharedClient.userType is not respected.

I hope this explains the problem.

Thanks again for working on it.

I am pretty sure calling User.get( ) would work, but it's a workaround at best which isn't ideal.

Consider the practical use case - If users have logged in previously, I would like to give them the logged-in experience immediately on subsequent app launches instead of waiting for a network call to complete

IMO the class mismatch is clearly a bug. I request to forward it to the appropriate team/dev.

I would be glad to come up with a fix too!

Niraj's fixed worked. Thank you!

It seems like Nirajs and Sagar Patel's solution no longer works with the latest 3.5.0 SDK.

Does anyone else have a solution?

Even with the latest iOS Kinvey SDK version 3.5.0, this problem still exists....that is, getting the Kinvey.sharedClient.activeUser still  doesn't return the custom User object if the app is killed (only works after a fresh login).