Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

forceTouchCapability returning nil

I am trying to incorporate some 3D touch into an application and I've run into a weird issue where the forceTouchCapability check is returning nil on viewDidLoad but not in viewWillAppear/viewDidAppear.

I'm aware that this is only available on iOS 9+ so I've added checks to verify that the traitCollection property on the view controller responds to forceTouchCapability as in the following:

- (void)loadView {

   self.view = [[MyView alloc] init];
}

- (void)viewDidLoad {

   [super viewDidLoad];

   // Checking the force touch availability here
   if ([self.traitCollection respondsToSelector:@selector(forceTouchCapability)] &&
        self.traitCollection.forceTouchCapability == UIForceTouchCapabilityAvailable) {

       // This won't get called because forceTouchCapability is returning nil 
       // which corresponds to UIForceTouchCapabilityUnknown
       [self registerForPreviewingWithDelegate:self sourceView:self.view];
   }
}

In LLDB with a breakpoint at the if statement, entering po [self.traitCollection forceTouchCapability] returns nil which corresponds to UIForceTouchCapabilityUnknown. However, the traitCollection itself is not nil.

According to the documentation for UIForceTouchCapabilityUnknown:

UIForceTouchCapabilityUnknown: The availability of 3D Touch is unknown. For example, if you create a view but have not yet added it to your app’s view hierarchy, the view’s trait collection has this value.

Has the view not been added to the hierarchy by this point?

I'm curious if anyone has run into this issue before and how to work around this? I would like to avoid adding this in the viewDidAppear as this can get called quite a bit.

If it helps, I'm running this on a 6S on iOS 9.1 with Xcode 7.2

like image 988
ajfigueroa Avatar asked Dec 16 '15 17:12

ajfigueroa


2 Answers

I've also seen this issue, and found that the easiest way to check whether the device can support force touch or not is doing it via the screen instance. This kinda makes sense because the capability is a property of the screen. Doing it this way means you don't have to worry about the lifecycle of a viewcontroller or a view.

func canForceTouch() -> Bool
{
  if iOS9OrHigher // pseudocode, a function that makes sure u only do this check on ios9 or higher
  {
      return UIScreen.mainScreen().traitCollection.forceTouchCapability == .Available
  }
  return false
}
like image 93
Skela Avatar answered Oct 08 '22 02:10

Skela


The view hasn't been added to the View Hierarchy yet. You can see this easily by checking for a superview in the debug console

(lldb) po self.view.superview
nil

If that's what you're seeing, the view hasn't been added to a hierarchy yet: so you have to put your check elsewhere.

This is kind of confusing because in Apple's ViewControllerPreview sample app it's in viewDidLoad. But it really should in traitCollectionDidChange:, because then you're sure that the view has been added to the app's hierarchy.

This is the code I use (works on iOS 8, if you don't need to support that feel free to move the outer conditional).

- (void)traitCollectionDidChange:(UITraitCollection *)previousTraitCollection {
   [super traitCollectionDidChange:previousTraitCollection];

   if ([self.traitCollection respondsToSelector:@selector(forceTouchCapability)]) {
       if (self.traitCollection.forceTouchCapability == UIForceTouchCapabilityAvailable) {
           // retain the context to avoid registering more than once
           if (!self.previewingContext) {
               self.previewingContext = [self registerForPreviewingWithDelegate:self sourceView:self.view];
           }
       } else {
           [self unregisterForPreviewingWithContext:self.previewingContext];
           self.previewingContext = nil;
       }
   }
}

The added benefit to this is that your view will be registered/unregistered if the user changes their 3D Touch settings while the app is running.

like image 40
bpapa Avatar answered Oct 08 '22 03:10

bpapa