Since the prior SDK release, we have worked on refining the functionality used by the prod.ly iOS app. In particular, we wanted to allow users to browse the global timeline and search for products without having to be logged in.
- FIXED: Social Signin form should have same modal presentation style as login form
- FIXED: Ignore language “mul” from custom keyboards
- ADDED: Dismiss keyboard on login screen by tapping outside of text fields
- ADDED: Changing Lists now also sends notifications
- ADDED: SDK now shows login flow following user actions that require it
- ADDED: Ability to set custom login message
- ADDED: you can set the tint color on all of the SDK UI to suit your color scheme
On most test fields, the SDK keeps track of the input language so that we can properly tag the language for user-generated content, like product infos, opines etc. This approach had a problem with third-party keyboards, like SwiftKey. Those are specifying what locale they are for, via their info.plist. Because this does not allow for language switching common practise is to specify “multiple languages” (in short “mul”) which threw us off. This means that for these users that do use multi-language custom keyboards we need to use the preferred user language instead.
A neat feature is that developers can now set the global tint color of the UI provided by the SDK. This way you can have all these view controllers also match with the color scheme of the rest of your app. This is very useful for apps that leverage ProductLayer product data to build niche apps for specific product categories or even brands.
The big addition in this SDK release is the ability of the SDK to automatically request a login (on iOS) if the user does something that requires authentication. This way developers using the SDK no longer need to care if they need to present the login or not. They simply use the SDK functions they like and the SDK will take care of the rest.
PLYServer is now referencing UI classes on iOS for the on-demand login. This caused a bit of a headache in the pod spec. The Core spec didn’t include the iOS classes and so linting it would fail. But we couldn’t just add a dependency to ProductLayerSDK/iOS subspec because then we would end up with a circular dependency which CocoaPods does not know how to deal with. So we ended up merging the iOS things into the Core spec. This way you still can use the SDK on OS X, but there are no building issues any more.
We enabled building of a module for the iOS framework, which made it necessary to rename the umbrella header to be the same name as the framework: ProductLayerSDK.h. Because of these changes the SDK should also now play nice with Swift apps.
The SDK update is available via CocoaPods and tagged on GitHub.