All content created during this period will not be available/restorable after December 11.
We apologize for the inconvenience, but we to take this action to improve and maintain the SAP Community wiki performance.
Please plan your tasks accordingly.
This article aims at helping an iOS developer to get started with a simple 'application' which the following
This helps the application developer to get a hang of the flow off the application as the subsequent calls will be similar to the first GET call. What will not be covered in this article is the parsing functionality as that by itself a topic good enough for another blog or a wiki. Also this article assumes that the application developer is not a complete novice to the iOS development environment. The assumptions made are not huge as this article touches upon important configurations that need to be made to the project.
This article is for the already release 2.1 version of the SUP-ODP online mobile solution. The version of the XCode IDE used for demonstrating the example will be 4.2 (iOS5 SDK), but the deployment target for the project will be iOS version 4.2 and above.
As mentioned before, every single detail about setting up the project will not be covered in this section. This section will talk more about how to get the client libraries from the Mobile SDK client installer and how to set the project by including all the necessary files from the client libraries.
The User registration process involves activities from the server side as well as the client side. The administrator of the SUP-ODP server has to make sure that the following things are already taken care of before the client tries to register a user automatically with the server. The below topics will not be explained in great detail here. This article is purely dedicated for client development.
Once these are in place, the application can be coded for user registration. One thing to be noted here is that all the values will be hard-coded against the function calls and there will be no much UI interaction involved.
For User registration API, include the "LiteSUPUserManager.h" header file.
In the .m file of the main view controller, the code can be put under the '(void)viewDidLoad' event so that the code gets executed when the view loads. The code is as below.
Once you run the application with this code, provided the right values are passed, the user is successfully created on the server and the connection successfully established. If there are any errors, the exception block in invoked and showing an error message the control returns from the code.
A few things to be noted here are that the string literals @"APPLICATIONID", @"SECCONFIG" should match with the Application ID and the security configuration that have been created on the server case-sensitive. And the User should have an account with the Security configuration authentication provider and the back-end gateway with the password that is passed satisfying the conditions for that particular security configuration.
There is another addition in the above function call, namely the 'Vault Password'. By passing this to the function call, the application developer completely hands over the responsibility of storing sensitive data like the password to the ODP framework.
DISCLAIMER : Since this is a demonstration of the sample application, we are hard-coding the values against the input parameters. The same should not be done in case of a productive application, more so with a parameter like password.
If the user registration returns successfully, then the control comes to the next piece of code written after the above code. In all other error cases, the control moves out of this block because of the 'return' statement in the exception block.
For data fetch, we use a factory class called the "SDMRequestBuilder" to instantiate an object of the type the protocol "SDMRequesting". Hence we import both the header files "SDMRequesting.h" and the "SDMRequestBuilder.h".
Once the imports are done, the code for the data fetch will be written immediately after the above piece of code for user registration. In total, the code will wholly look like below.
From the code above, if we focus on the data fetch code we can notice a few things.
Since the request is a synchronous call, there is a waiting period before the request finishes and once it finishes, the control immediately comes to the next line where we check for any errors caused during the framework execution and return from the execution if any.
The last 2 lines are an example that the response can either be fetched in the format of a string or a binary stream, however the developer deems appropriate.