I'm implementing the new WCSessionDelegate methods to support multiple device pairing.
- (void)session:(WCSession *)session activationDidCompleteWithState:(WCSessionActivationState)activationState error:(nullable NSError *)error;
- (void)sessionDidBecomeInactive:(WCSession *)session;
- (void)sessionDidDeactivate:(WCSession *)session;
I'm a bit unsure about how these methods will work with older versions of iOS and watchOS (the Simulator is proving very unhelpful).
My assumption is that these methods will replace the behaviour controlled through the method below, and I can exclude it?
- (void)sessionWatchStateDidChange:(WCSession *)session;
Has anyone had experience with supporting combinations of older iOS and watchOS devices with these new methods?
The new session activation methods don't replace the state change method. You will continue to receive state change notifications for the active watch since some property changes may not be related to the watch being switched.
For example, the user may install or delete the companion watch app, or enable or disable the complication on the currently active watch.
Supporting older versions of iOS:
The delegate methods themselves won't get called on older versions of the OS. You merely need to ensure you don't access any properties or call any methods which would only be available on newer versions of the OS.
You should use #if available to dynamically check the OS version that your app is running on (since activationState is only available since 9.3).
Here's an example demonstrating how you could support multiple versions of iOS:
private func isValidSession() -> Bool {
if #available(iOS 9.3, *) {
guard let session = session where session.activationState == .Activated && session.paired && session.watchAppInstalled else {
return false
}
} else {
// Fallback on earlier versions
guard let session = session where session.paired && session.watchAppInstalled else {
return false
}
}
return true
}
Sample code:
Apple has also provided QuickSwitch sample code which you may find helpful in supporting or experimenting with watch switching.
Related
I need to make a request from my code where one of the parameters is if the device supports NFC or not. I don't use the NFC capability in my app. I have tried
import CoreNFC
...
guard NFCNDEFReaderSession.readingAvailable
But this check fails for even supported devices. Is checking this way unsupported if there is no intention to use it in the app and is adding keys in entitlements and info plist the only way to go? Thanks in advance.
Try this:
import CoreNFC
in viewDidLoad check if NFC is available:
if #available(iOS 11.0, *) {
if NFCNDEFReaderSession.readingAvailable {
print("NFC is avaiable")
}
else {
print("NFC is NOT avaiable")
}
}
I have an iOS application that is providing Document Picker feature working perfectly on iOS 10 but that on iOS 11 always calls the documentPickerWasCancelled: with this message in logs:
[UIDocumentLog] UIDocumentPickerViewController : didPickDocumentURLs
called with nil or 0 URLS
I'm correctly calling dismissGrantingAccessToURL: with a valid NSURL on the provider extension but it never calls the documentPicker:didPickDocumentsAtURLs: on the other side.
I think I'm missing something, can you give me an explanation for this bad behaviour?
I'm having the same problems. Unfortunately I think the explanation is a bug or backwards-incompatibility in iOS 11. According to the documents it should be enough with a Document Picker extension:
"The Document Picker View Controller extension can perform import and export operations on its own. If you want to support open and move operations, you must pair it with a File Provider extension."
https://developer.apple.com/documentation/uikit/uidocumentpickerextensionviewcontroller?language=objc
And indeed this worked fine in iOS 10 and earlier. iOS 11 was probably meant to be backwards compatible with the existing FileProvider-less DocumentPickers, but seems it's not. Or perhaps they forgot to update the documents.
Instead, one can implement the new updated File Provider that gives access to your files via the standard document browser UI:
https://developer.apple.com/documentation/fileprovider
This does work with an iOS 11 FileProvider backing the iOS10 picker. You probably want to create a new FileProvider using the new Xcode template, then use :
#available(iOSApplicationExtension 11.0, *)
on the FileProviderItem and FileProviderEnumerator classes, then :
if #available(iOSApplicationExtension 11.0, *) {
in the methods on your FileProviderExtension
I find that my iOS 10 picker does correctly call this method, but note the completionHandler?(nil) was required to make it work. By default, the template for iOS11 inserts a completion that reports a failure. This code works for me:
override func startProvidingItem(at url: URL, completionHandler: ((_ error: Error?) -> Void)?) {
completionHandler?(nil)
// completionHandler?(NSError(domain: NSCocoaErrorDomain, code: NSFeatureUnsupportedError, userInfo:[:]))
}
However, that isn't the end to this iOS10/11 incompatibility. If you make an iOS10/11 compatible file provider, it won't run on some iOS10 devices as far as I can see. I can run or debug mine on a 32-bit iOS device, but the FileProvider crashes on a 64-bit iOS 10 device with this error:
dyld: Library not loaded: /System/Library/Frameworks/FileProvider.framework/FileProvider
Referenced from: /private/var/containers/Bundle/Application/61BBD1A7-EA1E-4C10-A208-CA1DFA433C8D/test.app/PlugIns/testFileProvider.appex/testFileProvider
Reason: image not found
I am working on an app that is close to launch but uses the ABAddressBook framework. With the deprecation of ABAddressBook in iOS9, do I need to check the user's iOS version, and use ABAddressBook for pre iOS9 users, and CNContact for iOS9 users?
How is everyone else handling this? I haven't been in a situation like this before.
I have also been dealing-with and researching this issue, what I've opted to do is as you suggest; check the users iOS version doing something like the following:
NSString *version = [[UIDevice currentDevice] systemVersion];
BOOL isVersion8 = [version hasPrefix:#"8."];
BOOL isVersion7 = [version hasPrefix:#"7."];
//...
...continuing based on the versions you've decided to support for your app.
Then I do a check to either use the Addressbook framework for earlier than iOS 9, and Contacts framework for iOS 9 and beyond.
if(isVersion7 || isVersion8){
//Use AddressBook
}
else{
//Use Contacts
}
That's the best way I could think to deal with this deprecation business...
Deprecated doesn't mean removed. Just make linking to both frameworks as optional and start to design data workflow that can handle both frameworks. Also please mind that CNContact is new and full of bugs.
Once you think your app is refactored and iOS evolved to 9.1 give it a green light
How to know if system supports functionality
1) Check if the class exists
if(NSClassFromString(#"CNContact")) {
// Do something
}
For weakly linked classes, it is safe to message the class, directly. Notably, this works for frameworks that aren't explicitly linked as "Required". For missing classes, the expression evaluates to nil.
2)
#ifned NSFoundationVersionNumber_iOS_9
#def NSFoundationVersionNumber_iOS_9 NUMBER
#endif
if (floor(NSFoundationVersionNumber) <= NSFoundationVersionNumber_iOS_9) {
// Use address book
} else {
// Use contact framework
}
Run the app in simulator to find the NSFoundationVersionNumber constant
if #available(iOS 9, *)
{
// iOS 9 - CNContact
}
else
{
// iOS 8 - ABAddressBook
}
This is the right way to check.
With WatchKit you have your app that runs on the phone, and the watch app that runs as an extension.
If you create a library that contains common code to be used in both the phone app and the watch extension, is there a way to tell if the code is running in the phone app or the watch extension?
I.e.
if ([self isRunningInWatchExtension]) {
NSLog(#"this is running on watch");
} else {
NSLog(#"this is running on phone app");
}
- (BOOL)isRunningInWatchExtension {
???
}
In target conditionals there are some conditionals that may help you,
#if TARGET_OS_WATCH
//do something for watch
#else
//do something for ios ==> assuming you only support two platforms
#endif
I've accomplished this by checking the bundle identifier:
if ([[[NSBundle mainBundle] bundleIdentifier] isEqualToString:kAppBundleIdentifier]) {
// Running in main app
}
else if ([[[NSBundle mainBundle] bundleIdentifier] isEqualToString:kWatchBundleIdentifier]) {
// Running in extension
}
This can be easy if you are calling any custom methods in your common framework class. You just need to add additional method parameters to method. And if you are calling this method from iOS app or Watchkit app then add appropriate key-value pair to dictionary for parameters. And compare this in your framework methods.
To determine this from init or any other method then you can still get to know by this code,
NSLog(#"%#",[NSThread callStackSymbols]);
So, you need to parse this string and get appropriate target names. If it is called by iOS app then you will get 'UIKit' string and from watch kit app extension you will get 'YourApp WatchKit Extension' string somewhere. You can also refer this SO answer for parsing this string and compare it - https://stackoverflow.com/a/9603733/602997
I am developing an application that I want to run on both iOS4 and iOS5 but for users of iOS5 I want to use an iOS5 feature as part of the interface (iOS4 users will get something less exciting). My question is what is the procedure for checking the availability of a particular OS on a device. My understanding is that I don't check the OS version but rather the availability of a particular class, can anyone help me out of the best way to do this ...
Isn't iOS 5 under NDA?
Anyway, to check if a feature exists then try this:
if (NSClassFromString(#"UIStepper")) {
//enter code here
} else {
//enter code here
}
Customise to your needs.
EDIT: iOS 5 is now released so I can now add "UIStepper" to my code.
iOS5 is under NDA so i wouldnt mention any new classes that may or may not exist. However the following code should do what you want. It's lifted from the docs.
if ([UINewClass class]) {
// Create an instance of the class and use it.
} else {
// Alternate code path to follow when the
// class is not available.
}
This uses Weak Linking and therefore requires that the new class (UINewClass) to be in the SDK you are using to compile. It is a relatively new feature introduced in iOS 4.2 and might not be supported by all the frameworks. A workaround is to use the older style (from the same link as above):
Class cls = NSClassFromString (#"UINewClass");
if (cls) {
// Create an instance of the class and use it.
} else {
// Alternate code path to follow when the
// class is not available.
}
Class stepperClass = NSClassFromString(#"UIStepper");
if (stepperClass) {
// class is available, use it
} else {
// class not available, don't use it or use something else
}
If you're trying to get the UIStepper to gracefully degrade in 4.x, you cannot only use
if( NSClassFromString(#"UIStepper") )
Instead, you must also check for a UIStepper-specific selector having a response. As Harry Wood suggested in the comment under Bo A, a good way to do it is:
if( NSClassFromString(#"UIStepper") && [theStepper respondsToSelector:#selector(setValue:)] )
This solved the issue of my app crashing under iOS 4.x.
Harry Wood helped me solve the issue I was seeing, and I would like him to get the credit.