Ask Backendless to Upate DeviceRegistration Table with User Relationship

iOS
1

In the docs it says
*

Backendless automatically links registered device with the currently logged in user. Suppose your app registers the device for push notifications. If there is a logged in user at the time when the device is being registered, Backendless creates a relation between the device and the user in the database (via a 1:1 relation):

That works well, but if the user is not logged in at the time of deviceRegistration (in the App Delegate method - didRegisterForRemoteNotificationsWithDeviceToken) is there a way I can call this method again AFTER a user has logged in or registered so that the relationship is established between the device and the user at runtime. It looks to me the only way currently to establish the relationship on backendless is for the user to stop the application and then restart the application thus triggering the App Delegate method to be triggered again with the newly logged in user.

This may not be a pure backendless question, but perhaps you can guide me on how I could update the DeviceRegistration table to be updated with this user relationship if I have the scenario the user logs in. I really would like to be able to say something like ‘hey Backendless the user has logged in can you please update the deviceRegistratin table accordingly…’

Hopefully I have explained that well enough?!

2

Hi,

unfortunately, so far we have no opportunity to automatically link them after login, but you can do it yourself in at least two ways:

  1. make an unregister, login and then register
  2. using Data Service and establish relationship manually using API.

Regards,
Stanislaw

3

Hi Stanislaw,

Thanks for your reply

OK, I didn’t realise you could use DeviceRegistration table like a normal table?

So once a user logs in we can then create manually a relationship between the user and the deviceRegistration table using the user objectId in user.setRelation to establish the relationship?

Also, quick side question - does this almost mean we can add custom columns to deviceRegistration table or is this not advised?

Mike

4

Yes, you could use DeviceRegistration table like a normal table (with the exception of some of the nuances associated with the fact that this table is part of system - for example, it cannot be deleted or renamed).

So once a user logs in we can then create manually a relationship between the user and the deviceRegistration table using the user objectId in user.setRelation to establish the relationship?

Yes, exactly.

does this almost mean we can add custom columns to deviceRegistration table or is this not advised?

Yes, you can add custom columns to this table and use them according to your goals.

Regards,
Stanislaw

5

Thanks Stanislaw, perfect.

7

Hi Stanislaw

Weird error here when writing above code:
let dataStore = self.backendless?.data.of(DeviceRegistration().ofClass())

results in
Optional(FAULT = ‘1009’ [Table not found by name 'Table not found by name ‘DeviceRegistrationDto’. Make sure the client class referenced in the API call has the same literal name as the table in Backendless console’

Weird hey? Where does DeviceRegistrationDto come from?

My DeviceRegistration class is
import Foundation

@objcMembers
class DeviceRegistration : NSObject  {
    
    var objectId : String?
    var userId : String?
    var deviceId: String?
   
}
8

Hello,

The DeviceRegistration table doesn’t support class approach modification in iOS-SDK but you can use dictionary approach to modify your objects, e.g.

let deviceRegistrationStore = Backendless.sharedInstance().data.ofTable("DeviceRegistration")
        
deviceRegistrationStore?.findFirst({ deviceRegistration in
    if var deviceRegistration = deviceRegistration as? [String : Any] {
        deviceRegistration["userId"] = "USER_ID"
        // update
        deviceRegistrationStore?.save(deviceRegistration, response: { updatedDeviceRegistration in
            // handle response
        }, error: { fault in
            // handle fault
        })
    }
}, error: { fault in
    // handle fault
})

Regards,
Olha

9

Ah I wondered if that was the case. I tried the dictionary approach and yes can confirm that works so all ok. Thankyou.