Remove Settings bundle

[kchitalia]

No description provided.

[kchitalia]

Adding SDK Assets as part of the template app.

[wmathurin]

Settings.bundle and Images.xcassets are in shared/resources.
And the template apps simply have pointers to them (and instead of having copies), we should do the same for SalesforceSDKAssets.xcassets.

[wmathurin]

Also is the settings.bundle removed from all the sample apps?

[kchitalia]

@wmathurin I will modify the way I have copied the SalesforceSDKAssets.xcassets.

I removed the settings bundle from RestAPIExplorer, SmartSyncExplorer, SmartSyncExplorerHybrid, AccountEditor, NoteSync. Am I missing any sample app?

Also, I was able to create a sample app using forceios, all 3 flavors - native, native_swift, and native_react and see my changes for the login view controller.

[wmathurin]

Those are all the sample apps we have in the iOS repo.

[bhariharan]

As @wmathurin mentioned, we probably want these to be symlinks to a common shared folder like Settings.bundle is/was.

[bhariharan]

I believe we have some special logic in SalesforceSDKManager for host changing from Settings.bundle, which can be removed, right @khawkins?

[khawkins]

Two places I see where the Settings bundle is still referenced:

1. build/build.xml, via the sdkAppSettingsBundleName property. It's not being used, though, so you should just be able to remove that property.
2. In the configuration of the SalesforceHybridSDKTestApp target of the hybrid SDK.

[khawkins]

So as @bhariharan mentions, there are some other areas of the SDK that we should clean up, in correlation with the removal of support for the Settings bundle login settings.

SFUserAccountManager

There are sections of support around the login host, for querying that value from the Settings app. In particular, [SFUserAccountManager appSettingsLoginHost] is called by [SFUserAccountManager loginHost] and [SFUserAccountManager updateLoginHost], to leverage any changes through that configuration.

SalesforceSDKManager

[SFUserAccountManager updateLoginHost] ripples up to SalesforceSDKManager, which checks for login host changes and the logout switch being set, in processLogoutAndUserSwitchSettings. This whole method can go away, since those settings will not otherwise be useful. This in turn impacts the handleAppForeground: and launch methods, but hopefully that refactor should be straightforward.

[kchitalia]

@khawkins Thanks for the pointers. I will refactor the code in those two places.

[khawkins]

@kchitalia Sure thing, let me know if you run into any questions with that, as I know my description is a bit open-ended. I forgot one related method: [SFUserAccountManager updateAppSettingsLoginHost:] can also go away. Basically, anything that uses the constants:

• kAppSettingsLoginHost
• kAppSettingsLoginHostCustomValue
• kAppSettingsLoginHostIsCustom

Up to and including those constants, can go away. And to be clear, [SFUserAccountManager updateLoginHost] can also go away. As can the SFLoginHostUpdateResult object definition, and any consumers. I'll let you know if I come across more. :) But the basic exercise is to just verify whether or not any of that related stuff is being used anywhere that seems like it still needs to be, and otherwise remove it all.