| Overview | Backend | App Configuration | Android | iOS |
| MBO iOS App | OData iOS App |
OData iOS Content:
On-boarding
We are now ready to embark on the migration process. When it comes to migrating the mobile application built using the MBO Object API, there are 2 approaches a developer can take. In the first approach, you make a copy of the existing mobile application and then replace the MBO Object API methods with the harmonized OData SDK methods. In the second approach, you start with a completely new project and use the harmonized OData SDK methods for all the business logic – You then copy and paste UI code snippets from the existing MBO mobile application into the newly created application.
At first glance, you might think that the first approach is a significantly easier proposition. Simply replace MBO Object API methods with the harmonized OData SDK methods. However, that is not the case. We strongly recommend the second approach. Start with a new project and use the harmonized OData SDK methods for all the business logic. Copy and paste UI code snippets to speed up the development process. There are a number of reasons why the second approach is preferred over the first approach. Below is a partial list of reasons…
Start from existing project | Start from new project |
On-boarding differs significantly. Would require a rewrite of the onboarding process | Harmonized SDK offers MAFLogonComponent that greatly simplifies on-boarding |
No concept of Offline Store. Would require completely new code | Offline Store code integrates well with MAFLogonComponent |
MBO Object API libraries need to be replaced with harmonized OData SDK | Harmonized OData SDK libraries need to be added |
READ operations differs significantly. For example, READ is synchronous. Lot of code needs to be replaced with new code | All operations are asynchronous. New code can be added easily |
Binding to UI controls not so easy since SUPObjectList object is returned for most READ operations. This SUPObjectList object is not defined in harmonized OData SDK | New code to bind to UI controls can be easily added. Id<SODataEntitySet> is returned for most READ operations |
In this blog, I will talk about the on-boarding process. There are other blogs out there that already talk about the on-boarding process. The blog by Ken is a good place to start for iOS on-boarding. There are also sample applications and ‘How To… Guides’ that walk you through the on-boarding process. I will try to not repeat much of what is in the blog already. By now, you already know the importance of the on-boarding process, so I will skip that and get right into the step-by-step instructions on on-boarding.
Creating a new project
Follow the steps in this link to create a new project. One important step missing in some of the ‘How To… Guides’ already published is to set the OtherLinkerFlags. Be sure to set the following flags: -ObjC and –all_load for the OtherLinkerFlags.
Creating the logon handler class
To keep the code clean, a central logon handler class should be created and used for MAF logon related work. This class must adopt the MAFLogonNGDelegate protocol and implement the methods specified in the protocol. It is recommended to implement this central logon handler class using the singleton pattern. It makes it easy to share data between different parts of code without having to pass the data around manually.
+ (instancetype)shared { static id _shared = nil; static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ _shared= [[MAFLogonHandler alloc] init]; });
return _shared; } |
The MAFLogonComponent (most common reusable component of the Mobile Application Framework MAF) greatly simplifies the on-boarding process. We strongly recommend that you use the MAFLogonComponent for the on-boarding process. It even provides the UI necessary for the login process and it is highly customizable. You can however, create your own UI based on your business needs.
The singleton instance of the central logon handler class is then used to present the logon screen to the user in the applicationDidBecomeActive method of the AppDelegate class.
- (void)applicationDidBecomeActive:(UIApplication *)application { // Execute logon operation to automatically present logon screen if needed. [[MAFLogonHandler shared].logonManager logon]; } |
Handling logonFinishedWithError
This delegate method is called when logon is complete. If there is no error, then on-boarding is successful. At this time, call the configureManager method to configure the HttpConversationManager instance.
-(void) logonFinishedWithError:(NSError*)anError { if (!anError) { [[self.logonManager logonConfigurator] configureManager:self.httpConvManager]; } else { NSLog(@"logonFinishedWithError:%@", anError); } } |
On-boarding is greatly simplified with the MAFLogonComponent. I have attached a sample application that on-boards a device using the steps outlined above. Please let me know if you have any questions.
Our next step in the migration process is to create an Offline Store.
- SAP Managed Tags:
