D Writing Swift Applications Using the iOS Client SDK
You can also use the Oracle Mobile Cloud Enterprise iOS client SDK with Swift applications.
Here are the general steps you take to work with Swift and the client SDK, using Xcode as your IDE:
-
Add the bridging header files.
-
Add the SDK header files and libraries.
-
Add the Objective-C linker flag.
-
Compile and link your app using the iOS client SDK as you would any other iOS project in Xcode.
Note:
Using the SDK with Swift has all the same dependencies as using the SDK with Objective-C. For the list of dependencies, see Libraries and Dependencies.For more information on how to work effectively with Swift and Objective-C, see Apple’s documentation: https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithObjective-CAPIs.html.
Adding the Bridging Header File
You need to use a bridging header file to import the header files of the Objective-C public classes that your Swift app calls. All of the available public classes in the OMCe client SDK can be found in the SDK’s include
folder.
To create a bridging header file in Xcode:
Adding the SDK Headers and Libraries to a Swift App
The set of headers and libraries you add depends upon which of the client SDK’s static libraries you include in your app. At a minimum, you need the libOMCCore.a
and libIDMMobileSDK.a
libraries.
Using SDK Objects in Swift Apps
The rules for converting from Objective-C to Swift are well described in the Apple documentation. For general information on the relationship and usage of these two languages together, be sure you look there.
Watch out for the following:
-
The auto-complete feature of the Code Editor in Xcode generally works well enough to get you the mappings. However, sometimes it puts the a label in the first parameter that isn’t supposed to be there. Watch for it if you’re using auto-complete.
-
When Objective-C
init
methods come over to Swift, they take on native Swift initializer syntax. This means theinit
prefix is sliced off and becomes a keyword to indicate that the method is an initializer. See the Apple documentation for complete details. -
Pay special attention to the
!
and?
optional parameter specifications, as well as any parametrized types in the declarations. The optional types are auto-determined by the compiler when mapping Objective-C to Swift.
You should be able to compile and run your mobile app using Swift and the OMCe client SDK on both the Xcode Simulator and an actual device.
Here’s an example of Objective-C and the comparable Swift code that uses the OMCe client SDK.
The following Objective-C code to register a device token for Push notifications:
// Get notifications sdk object
OMCNotifications* notifications = [[appDelegate myMobileBackend] notifications];
// Register device token with MCS server using notifications sdk
[notifications registerForNotifications:[appDelegate getDeviceTokenData]
onSuccess:^(NSHTTPURLResponse *response) {
NSLog(@"Device token registered successfully on MCS server");
dispatch_async(dispatch_get_main_queue(), ^{
// Update UI here
}) ;
}
onError:^(NSError *error) {
NSLog(@"Error: %@", error.localizedDescription);
dispatch_async(dispatch_get_main_queue(), ^{
// Update UI here
}) ;
}];
might be written in the following way in Swift:
@IBAction func registerForPushNotifications() {
// Get notifications sdk object
let notifications = appDelegate.myMobileBackend().notifications();
// Get device token first, and assign it here
let deviceTokenData:NSData! = nil;
// Register device token with MCS server using notifications sdk
notifications.registerForNotifications(deviceTokenData, onSuccess: { (response:NSHTTPURLResponse!) in
NSLog("Device token registered successfully on MCS server");
dispatch_async(dispatch_get_main_queue()) {
// Update UI here
}
}) { (error) in
print("Error: %@", error.localizedDescription);
};
}