3

I'm having some trouble working out the logistics behind creating two records on separate objects that have a lookup relationship.

Lets say we're offline and want to create an Account, and then add a Contact. Since we're not able to connect to SFDC, we won't know what value to set in Contact.AccountId. Instead we create a field on the Contact soup, call it _accountSoupEntryId, that stores the value of _soupEntryId for the Account it is related to.

I'm unclear on what to do when we sync our soups up to Salesforce. I thought there would be some functionality that would assist with setting lookup fields for objects that are related as is described here.

I understand that the following has to occur:

  1. Accounts get created, and re-sync'd with their soup which will give them a proper Salesforce Id.
  2. Contacts get their AccountId field updated locally by looking up to the Account soup.
  3. Contacts are then able to be sync'd up to Salesforce.

Do I need to handle this manually?

Is this going to involve creating a custom sync target, or is there some functionality that I haven't found yet for assisting with this?

What about syncing down, is there an easy way to populate _accountSoupEntryId on the Contact when we Sync Down so that I don't need to handle displaying lookup fields differently based upon whether or not that particular soup entry is sync'd (e.g. has a proper Salesforce Id)?

  • 3
    Hi I have exact same question as you had posted here. Were you able to solve the problem? If so how? – sunny Jan 25 '17 at 15:47
  • @sunny I ended up handling it "manually" like I described above. I have a field in my contact soup definition called _AccountId that is used to hold the _soupEntryId of the Account the Contact is related to. When I run a "Sync Up" operation, I sync the Accounts first. Then I query the Contact soup to find any Contacts that have a value in _AccountId, but do not have a value in AccountId and update the AccountId field with the value of the newly sync'd account. Then the Contact soup can be sync'd. – frontendloader Jan 25 '17 at 18:45
  • Offline creation of records does indeed throw up many quirks, especially when you start down the related objects track. The route you've described seems to be the best fit for a hand-rolled solution. I work for MobileCaddy, an SDK built upon the SF Mobile SDK, and we utilise a simiar solution, but we also utilise more platform logic that allows these "proxy" Id fields to be automatically mapped over to real Ids, thus allowing the app dev to not worry about this extra work, and simply focus on the core business logic of the app. – Todd Halfpenny Feb 8 '17 at 0:35
1

Some functionality to handle this has been added in Mobile SDK v5.2. The docs on the website don't reflect this new functionality yet, but the PDF in the GitHub repository does. Ctrl+F for "ParentChildrenSyncDown" and "ParentChildrenSyncUp".

protected by Community May 27 at 18:09

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.