What’s new in the SAP Cloud Platform SDK for iOS 3.0 SP01
Our next major version update is out and available for download at the usual places in the SAP Marketplace for customers and in the SAP Community for everybody. The content is identical, you may sometimes see patches being available on Marketplace a bit earlier than they show up on Community.
System Requirements, Installing, Upgrading
This new release is built with Xcode 10.1 and Swift 4.2. This version of Xcode has been around for a while now, so just enjoy an easy upgrade this time without any additional impact on your dev environment. At the time of writing this post, a new Xcode 10.2 beta, which includes Swift 5, just came out – we will of course ship a rebuild for this one in due course (and hope the best for binary and module compatibility coming with Swift 5).
Simply replace the Assistant in your /Applications folder and you’re good to go. Any apps that are managed in the Assistant can be upgraded by simply clicking on the project name in the overview list and selecting ‘Refresh’ from the right-hand side menu.
This will move your old frameworks into a Frameworks_old folder and also regenerate your proxy classes with the latest toolchain and move your old proxy classes aside into a ProxyClasses_OLD folder.
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 the Assistant.
If you paid close attention, you’ll have noticed that ‘Export Frameworks’ will give you more files than in the earlier release. We have added a new SAPML.framework (and additional dependencies needed for that). We’re not adding these frameworks to the apps generated by the Assistant to avoid having overhead in cases were you don’t consume the new functionality, but adding the new capabilities is easy and explained in the API docs.
In this release we provide text recognition capabilities based on a model that we ship with our SDK. The framework also comes with UI components implementing the Fiori for iOS design for easy consumption in your app.
We are curious to see what you will do with text recognition capabilities in your app and eager to hear what we should add next to our new framework.
Aside the OCR feature, we’ve added quite a few more nice improvements to our existing set of UI controls.
For maps, we now support rendering routes, showing details and points of interest along routes and drilling down into them.
Additionally, we made some enhancements on the editing feature of geospatial objects to improve the user experience when dragging and scrolling
You can also include location form cells that show geospatial objects
More chart types! You can now also use area, bubble, and scatter charts to visualize your data
The editable cells became more flexible; known structures can be nicely auto-formatted for better readability and if you want to support alternative input methods, you can show action icons now
The grid table now allows showing a summary row, typically used to show total sums or similar at the bottom of the table. We have improved our theming support, which now also works well for components during the onboarding flow. Some of our components got some extra attention and support accessibility even better now, including the pickers, switch, slider, and object cell.
All controls that include texts allow developers to provide their own strings, including localization to languages not delivered by us. In this release, we added quite a few new languages: Czech, Hungarian, Italian, Korean, Dutch, Polish, Romanian, Serbian, Slovak, Swedish, Turkish.
We added a couple new things to make the framework handling easier. It’s not needed (and nobody should be doing that anyway), to also push the framework binaries to your source code management system. Newly generated apps will have a default .gitignore file. There are two ways to add the frameworks back to a project if you’ve cloned it to your computer. You can either right-click in Finder and open the project with the Assistant, which will then add the frameworks back
or you simply run the build, we’ve now also added a script to the build phases that will copy the frameworks from the Assistant into your project if they’re not available. This script could also be used on build machines.
After our major overhaul last fall, we’ve focused a lot on rounding off some rough edges and incorporating feedback that we’ve received – tons of little things that aren’t worth mentioning individually, but you’ll notice the overall experience got a bit smoother in many places. Worth noting is that you can delete accounts again and also navigate directly into the Mobile Services Cockpit.
The generation process got a couple more configuration options as well that some of you have been waiting for a long time. You can now configure that for non-OData backend, the Assistant should not attempt to generate proxy classes
And for developers experienced with the SDK who want to start a new project from scratch and don’t need the master/detail views, but still want to leverage all the convenience of the onboarding flow implementation, you can now select exactly that onboarding-only option
The generated app structure has been improved even further as well. We have restructured the code so unrelated functionality is now split up cleanly into different classes, which should help understanding the structure of the generated app faster and also give good direction on how to organize your app. You’ll see some of these changes in the AppDelegate, but also how we initialize the OData data service. The app now has a lot more comments and also includes links directly into the SAP help pages so it is even easier to jump from the app into the related documentation. We’ve improved big time on the onboarding concept (more details below), the generated app of course consumes these new APIs and shows how to apply it in practice.
Foundation and Flows
Less visible, but equally important, we added new features to the Foundation framework as well.
For usage we’ve now made it very easy to respect the most restrictive of the server’s usage setting and the user consent choice – critical in times of data privacy rules and the attention this topic has. Respecting user choice is even easier, if you’re using the new user consent step in your onboarding flow definition.
The client log file size and number of files are now downloaded from the server, and when using the flows implementation also applied automatically. We’re also exposing the new network synchronization policy in the downloaded settings JSON so you can react properly on these settings in your app. When you’re not providing an app version manually, we now fall back to the application’s bundle version – which is very reasonable so you shouldn’t be required to bother at all anymore.
Keeping up-to-date with security, we’ve upgraded the used version of OpenSSL to 1.1.1a and also changed some of the cipher default settings to continue to be secure by default. We expose the SAML attributes of the currently logged in user now on the client, so you can leverage this for building role-specific features into your apps, e.g. We’ve also added a logout API so you can terminate user sessions programmatically.
Please carve out some extra time to read the latest docs around the new onboarding session manager and affiliated onboarding session. We realize the few pages of code we have generated into the app when using the Assistant were a bit hard to digest; we have improved this continuously and now distilled all the learnings from this into new APIs that factor our huge chunks of the boilerplate code into SDK components and leave you with a few delegates to implement so the onboarding flow can properly integrate into the rest of your app. The best way for getting started is just to have a look at a newly generated app – and of course all the details are in the docs. Check it out, it’s worth it; I’d even say investing the efforts and upgrading older apps to these new components and APIs will pay off big time in the long run, so go for it.
More flexibility when building offline apps – we have now APIs that allow removing unsent changes to an entity as well as removing individual entries from the error archive, which will in turn remove the dependent requests. With this fine-grained control you can give users even more control on what to synchronize back to the server.
During debugging, the ilodata tool will now print out contents of the request queue and defining queries – you wanted details, you got them.
We’ve also added a new API that you’ll love when you ever built an offline app; error handling is critical and we now allow interacting with the error archive and event log using proxy classes and strongly typed API.
The proxy class generation process in general has been optimized further to produce cleaner code and rely more on type inference in the generated classes. Not that you’d need to bother reading the code in these classes, but we like it clean also in the dark corners.
I cannot remember if we ever had a release where we didn’t do this, but again we improved error handling and error messages to give as much guidance as possible on how to handle potential problems and how to fix them.