The first service pack on top of our last major release is out. As usual, you can get it on SAP Marketplace or in the SAP Store. The comprehensive documentation gives you all the details, here are some of the highlights that we added.
Good news, this service pack won't require any updates to underlying technologies at your end. Xcode 9.1 and Xcode 9.2 have remained binary compatible on Swift frameworks, so if you are on either version, you can keep going also with the latest SDK. I trust by now you've made the move to Swift 4, so you'll be fine on that side, too. The Assistant itself continues to run on the current macOS version.
To upgrade from version 2.0, simply replace the Assistant in your /Applications folder. Any apps that are managed in the Assistant can be upgraded by simply clicking on the project name and selecting 'Refresh Frameworks...' from the context menu. Open the Assistant main menu and 'Export Frameworks...' to extract the new frameworks on your disk so you can copy them into any Xcode project not managed by Assistant.
Little (but maybe useful for some) enhancement - you want to also install the tools, but are of the opinion that /usr/local/bin really isn't the right place for them? Open the main menu and press Alt, this will give you 'Install Tools...' and you can pick the install directory.
The Assistant leverages some of the enhancements that happened since the last major release.
We now support connecting to existing translation hub projects. The Assistant shows a list of available translation projects and you can link your Xcode project to an existing translation project, or create a new one as you did before.
You'll also see the onboarding flow used slightly different per default in the generated app. The default is to now use the discovery service to bootstrap the application. This allows to load configuration into the app by looking it up via an email address. Each Mobile Services account comes with a test email domain that can be used. The Assistant shows that domain in the last step of the Assistant project creation flow.
And we also pre-fill the UI screen for most convenient testing.
You will also notice that if you immediately start the app after it has been generated, that you won't be asked for the passcode anymore. We've disabled the local default passcode policy in the OnboardingManager class (you'll find the place easily). We only pull the passcode policy from the server, per default it is turned off. If you log on to the Cockpit and configure a passcode policy before you onboard, you'll see the usual passcode / Face ID screen again. You can also re-enable the local passcode policy if you wish. What you will see, though, is the newly added EULA step that became part of the default flow.
We include translation of content of the onboarding and other UI controls in German, French, Spanish, and Portuguese. Of course you can still override all content explicitly in your app to add other languages or override the SAP translations. And, hey, the generated app has an icon now.
Read more on changes in Assistant and the generated app at https://blogs.sap.com/2018/01/30/latest-changes-in-sap-cloud-platform-sdk-for-ios-assistant-and-its-....
The new discovery service integration is explained in detail at https://blogs.sap.com/2018/01/30/sap-discovery-service-integration-in-sap-cloud-platform-sdk-for-ios....
The blog at https://blogs.sap.com/2017/10/27/sap-translation-integration-sap-cloud-platform-sdk-for-ios-2.0/ walks through the changes and improvements on the SAP Translation Hub integration.
We made various improvements around stability and ease-of-use on the foundation components. The biggest enhancements for SP01 happened in the authentication and security area. We do now support sharing data across apps and using different types of stores easily. You can now control conveniently where to store the data that is required/collected during onboarding and later in the app; the keychain, the secure store, or any other persistence provided by you. By putting data in the keychain, you can also share it across multiple apps that you're building. This way, users can onboard and authenticate in one app, and the credentials can be shared/reused in another app (if you've implemented it that way).
We also support the Swift 4 Codable protocol in our cache implementation now, and made the use of logging and log upload more convenient.
Ever got annoyed by invalid characters in OData metadata, e.g. forward slashes in namespaces, which prevented generation of proxy classes? We're now handling these situations more gracefully and became more tolerant to invalid endpoints, as long as we can still produce valid and compiling code for you. In some cases we also had name clashes with reserved keywords or duplicates within metadata that are prevented now. The new versions of our OData frameworks include various minor improvements towards supporting the full OData spec.
On the UI side, we've added bits and pieces to the existing controls, like the object cell, to cater for more scenarios that we've seen required in various application scenarios. Our map controls became a significant overhaul and polishing and look even better than before now
Additionally, we include a whole new set of controls to support data visualization in your app. This includes line and bar charts in various sizes to be used in different places. You can also implement single-tap interaction to allow users highlighting data points and getting more detail on them.
Here's some sample code that should help getting you started: https://blogs.sap.com/2018/01/31/data-visualization-controls-in-sap-cloud-platform-sdk-for-ios/.
We invested in improving the developer experience when designing your app in Interface Builder. An initial set of UI controls supports IBDesignable and gives a preview in Interface Builder when designing the screens of your app.
System Requirements and Upgrading
Good news, this service pack won't require any updates to underlying technologies at your end. Xcode 9.1 and Xcode 9.2 have remained binary compatible on Swift frameworks, so if you are on either version, you can keep going also with the latest SDK. I trust by now you've made the move to Swift 4, so you'll be fine on that side, too. The Assistant itself continues to run on the current macOS version.
To upgrade from version 2.0, simply replace the Assistant in your /Applications folder. Any apps that are managed in the Assistant can be upgraded by simply clicking on the project name and selecting 'Refresh Frameworks...' from the context menu. Open the Assistant main menu and 'Export Frameworks...' to extract the new frameworks on your disk so you can copy them into any Xcode project not managed by Assistant.
Little (but maybe useful for some) enhancement - you want to also install the tools, but are of the opinion that /usr/local/bin really isn't the right place for them? Open the main menu and press Alt, this will give you 'Install Tools...' and you can pick the install directory.
Assistant
The Assistant leverages some of the enhancements that happened since the last major release.
We now support connecting to existing translation hub projects. The Assistant shows a list of available translation projects and you can link your Xcode project to an existing translation project, or create a new one as you did before.
You'll also see the onboarding flow used slightly different per default in the generated app. The default is to now use the discovery service to bootstrap the application. This allows to load configuration into the app by looking it up via an email address. Each Mobile Services account comes with a test email domain that can be used. The Assistant shows that domain in the last step of the Assistant project creation flow.
And we also pre-fill the UI screen for most convenient testing.
You will also notice that if you immediately start the app after it has been generated, that you won't be asked for the passcode anymore. We've disabled the local default passcode policy in the OnboardingManager class (you'll find the place easily). We only pull the passcode policy from the server, per default it is turned off. If you log on to the Cockpit and configure a passcode policy before you onboard, you'll see the usual passcode / Face ID screen again. You can also re-enable the local passcode policy if you wish. What you will see, though, is the newly added EULA step that became part of the default flow.
We include translation of content of the onboarding and other UI controls in German, French, Spanish, and Portuguese. Of course you can still override all content explicitly in your app to add other languages or override the SAP translations. And, hey, the generated app has an icon now.
Read more on changes in Assistant and the generated app at https://blogs.sap.com/2018/01/30/latest-changes-in-sap-cloud-platform-sdk-for-ios-assistant-and-its-....
The new discovery service integration is explained in detail at https://blogs.sap.com/2018/01/30/sap-discovery-service-integration-in-sap-cloud-platform-sdk-for-ios....
The blog at https://blogs.sap.com/2017/10/27/sap-translation-integration-sap-cloud-platform-sdk-for-ios-2.0/ walks through the changes and improvements on the SAP Translation Hub integration.
Frameworks
We made various improvements around stability and ease-of-use on the foundation components. The biggest enhancements for SP01 happened in the authentication and security area. We do now support sharing data across apps and using different types of stores easily. You can now control conveniently where to store the data that is required/collected during onboarding and later in the app; the keychain, the secure store, or any other persistence provided by you. By putting data in the keychain, you can also share it across multiple apps that you're building. This way, users can onboard and authenticate in one app, and the credentials can be shared/reused in another app (if you've implemented it that way).
We also support the Swift 4 Codable protocol in our cache implementation now, and made the use of logging and log upload more convenient.
Ever got annoyed by invalid characters in OData metadata, e.g. forward slashes in namespaces, which prevented generation of proxy classes? We're now handling these situations more gracefully and became more tolerant to invalid endpoints, as long as we can still produce valid and compiling code for you. In some cases we also had name clashes with reserved keywords or duplicates within metadata that are prevented now. The new versions of our OData frameworks include various minor improvements towards supporting the full OData spec.
On the UI side, we've added bits and pieces to the existing controls, like the object cell, to cater for more scenarios that we've seen required in various application scenarios. Our map controls became a significant overhaul and polishing and look even better than before now
Additionally, we include a whole new set of controls to support data visualization in your app. This includes line and bar charts in various sizes to be used in different places. You can also implement single-tap interaction to allow users highlighting data points and getting more detail on them.
Here's some sample code that should help getting you started: https://blogs.sap.com/2018/01/31/data-visualization-controls-in-sap-cloud-platform-sdk-for-ios/.
We invested in improving the developer experience when designing your app in Interface Builder. An initial set of UI controls supports IBDesignable and gives a preview in Interface Builder when designing the screens of your app.
- SAP Managed Tags:
15 Comments
