matrixprojects.net - objective-c Posts

Debugging gesture recognizers

Thu, 01 Jan 2015 14:30:00 +0000

Recently I was trying to figure out why pan gestures weren’t being picked up. The case I was dealing with was a collection view that did not respond to swipe gestures near the edges of the screen.

After consulting with a colleague and looking up some documentation based on his advice, I found the conflict was partially due to the interativePopGestureRecognizer that lives within the UINavigationController. For background, this gesture recogniser was introduced in iOS 7 to allow swiping back to previous view controllers in the navigation controller’s stack.

Disabling it helped solve some of the conflicts.

self.navigationController.interactivePopGestureRecognizer.enabled = NO;

But doing a quick google would have told you that, the reason for this post is another trick I picked up along the way. I wanted to see if there was a way to get a list of gesture recognizers that were conflicting.

The way to do that is to register as a delegate to any of the gesture recognizers that are part of the conflict and implement the following method.

- (BOOL)gestureRecognizer:(UIGestureRecognizer *)gestureRecognizer
shouldRecognizeSimultaneouslyWithGestureRecognizer:(UIGestureRecognizer *)otherGestureRecognizer
{
    NSLog(@"Gesture Recognizer 1 = %@", gestureRecognizer);
    NSLog(@"Gesture Recognizer 2 = %@", otherGestureRecognizer);
    return YES;
}

This method will let you know exactly which gesture recognizers are being activated. One challenge with this was that the only gesture recognizer I knew about was the pan gesture recognizer on the collection view, but unfortunately attempting re-assign the pan gesture recognizer on a collection view will result with an assertion failure

*** 
Terminating app due to uncaught exception 'NSInvalidArgumentException', 
reason: 'UIScrollView's built-in pan gesture recognizer must have its scroll view as its delegate.'
***

The way I got this to work without too much hackery was to simply add another gesture recognizer to the edges - UIScreenEdgePanGestureRecognizer was perfect for this.

UIScreenEdgePanGestureRecognizer *gr = [[UIScreenEdgePanGestureRecognizer alloc] initWithTarget:self action:@selector(didSwipe:)];
    gr.delegate = self;
    gr.edges = UIRectEdgeLeft | UIRectEdgeRight;
    [self.view addGestureRecognizer:gr];

2014-12-29 17:08:27.707 TestProject[1678:34518] Gesture Recognizer 1 = UIScreenEdgePanGestureRecognizer: 0x7f9789d7fae0; state = Failed; delaysTouchesBegan = YES; view = UIView 0x7f9789cbb5f0; target= (action=didSwipe:, target=TestViewController 0x7f9789d96c50)
2014-12-29 17:08:27.707 TestProject[1678:34518] Gesture Recognizer 2 = UIPanGestureRecognizer: 0x7f9789c8e610; state = Began; view = UILayoutContainerView 0x7f9789c7c0c0; target= (action=_swipe:, target=UIPopoverController 0x7f9789c8b8d0)

And there you have it, a quick way to check out which gesture recognisers are causing you grief!

Xcode Tips : Organising your code

Sun, 02 Jun 2013 18:30:00 +0000

Using Pragma Mark

Xcode is by far the best IDE I’ve ever used for development and one of my favourite features is the ability to get the source code within a file organised into categories using #pragma mark - Category.

Why?

It makes it easier to read and navigate through your own source code.
If you and your team agree on a particular convention to follow, it will also make it easier for you to navigate through code written by others.
When organising your code, you will end up grouping related methods together so they fit the category they are listed under. This will allow you to easily isolate these method groups into separate classes if required at a later time.

Grouping

I usually make a category for each of the following items, but it’s really up to your personal preference as to what and how you choose these category groups. The idea here is to just group related methods together to keep the code easy to follow.

Constants
Init / Setup Methods
View Life-cycle (in UIViewController for example)
Overrides (Subclass method overrides)
Public Methods
Private Methods
Protocol Methods
Class Methods

Here’s what it looks like

From the jump bar you can view all the categories and methods within a file.

Code Snippets Shortcut

I found having to type in #p - then wait for autocomple to fill in the rest of pragma, and then typing mark - my title to be a bit mundane (what can I say - I’m a bit lazy). So I’ve made my own code snippet to speed up the process.

Creating a code snippet

1) First expand the utilities sidebar

2) Open the Code Snippet tab at the bottom

3) Now somewhere in your source file type in #pragma mark - <#title#>

4) Select the entire line and drag it to the code snippet area in the sidebar. If that works you should see a popup similar to the one below.

5) Fill in an appropriate title and summary

6) The completion shortcut is what will be used to trigger the snippet from the autocomplete menu so choose something short that does not conflict with any of your other snippets.

7) For the completion scopes you want to add

Top Level
Class implementation

8) Click Done and your Done!

Seeing your shortcut in action

In your source file start typing in your shortcut and you should see your new snippet appear in the auto complete menu.

On selecting it or pressing the return key, #pragma mark - will be filled in and the cursor will be in right position ready to type in the category title.

Additional Notes

So it seems there is a bug with Xcode which prevents the first pragma mark from appearing in the list if your implementation or interface does not make use of the braces (see link). The work around is to simply add the braces.

iOS Tips: Debugging UI

Sat, 30 Mar 2013 16:00:00 +0000

So you’ve been working on some fancy UI for your app and you’ve just ran into a little niggle. Something doesn’t look quite right, not in the right place or you just can’t see it anywhere!

Here are two techniques I regularly use to troubleshoot any view related issues.

1) Setting a Border

This may sound basic, but it is tremendously useful. Having borders around the views helps visualise their boundaries. This is especially useful when dealing with images or icons with paddings, this can help you figure out why an icon has more space that it should have.

Is it the icon itself? or maybe it is the layout logic used for that icon?

I find including the following category to my .pch file really handy as it saves me from including QuartzCore, setting a border width and color on every view I want to outline, only to remember to remove them all once I’m done.

UIView+Debugging.h

@interface UIView (Debugging)

- (void)setBorderColor:(UIColor *)color;
- (void)setBorderColorOnSubviews:(UIColor *)color;
- (void)setRandomBorderColor;
- (void)setRandomBorderColorsOnSubviews;

@end

UIView+Debugging.m

#import "UIView+Debugging.h"
#import QuartzCore/QuartzCore.h

@implementation UIView (Debugging)

- (void)setBorderColor:(UIColor *)color
{
    self.layer.borderWidth = 1.0f;
    self.layer.borderColor = color.CGColor;
}

- (void)setBorderColorOnSubviews:(UIColor *)color
{
    for (UIView *subview in self.subviews)
    {
        [subview setBorderColor:color];
    }
}

- (void)setRandomBorderColor
{
    [self setBorderColor:[self randomColorFromSet]];
}

- (void)setRandomBorderColorsOnSubviews
{
    for (UIView *subview in self.subviews)
    {
        [subview setBorderColor:[self randomColorFromSet]];
    }
}

- (UIColor *)randomColorFromSet
{
    NSArray *colors = @[ [UIColor blackColor],
                         [UIColor darkGrayColor],
                         [UIColor lightGrayColor],
                         [UIColor grayColor],
                         [UIColor redColor],
                         [UIColor greenColor],
                         [UIColor blueColor],
                         [UIColor cyanColor],
                         [UIColor yellowColor],
                         [UIColor magentaColor],
                         [UIColor orangeColor],
                         [UIColor purpleColor],
                         [UIColor brownColor]];
    
    NSUInteger index = ( arc4random() % colors.count );
    
    return colors[index];
}

@end

And to use it simply:

[myView setRandomBorderColor];

2) recursiveDescription

recursiveDescription is a hidden method that can be used from the debugger (as per this link). This will print out the full view hierarchy starting from the view this method is called on.Simply place a breakpoint at the end of viewDidLoad or viewWillAppear of a UIViewController for example, and type in the following command in the debugger.

po [[self view] recursiveDescription]

iOS Tips: Don't use 'description'

Sun, 18 Nov 2012 12:00:00 +0000

What is wrong with the following piece of code ?

@interface MyArticleClass : NSObject

@property (nonatomic, strong) NSString *title;
@property (nonatomic, strong) NSString *description;

@end

The title of this post has already given this away. We can’t use description as a property name and here’s why.

NSObject already has a description method which by default returns a string with the object name and memory address. Subclasses can override this method to return a more descriptive string. This can help print out useful information to aid debugging when using NSLog or the po in the debug console.

Having a description property on the subclass MyArticleClass in the example above is just asking for trouble. The code will have no issues compiling, it will probably work fine until you use it with core data. See this stackoverflow link. The general rule is to avoid using property names of methods or properties declared in parent classes unless its specifically to override them.

That being said, do make use of description to aid your debugging

Interface

@interface MyArticleClass : NSObject

@property (nonatomic, strong) NSString *title;
@property (nonatomic, strong) NSString *articleDescription;

@end

Implementation

@implementation MyArticleClass

- (NSString *)description
{
    return [NSString stringWithFormat:@"MyArticleClass: %p %@ - %@",self, self.title, self.articleDescription];
}

@end

Usage

MyArticleClass *article = [[MyArticleClass alloc] init];
article.title = @"iOS Tips";
article.articleDescription = @"The first iOS tips post!"; 
NSLog(@" %@ ", article);

Result

MyArticleClass: 0x74d5920 iOS Tips - The first iOS tips post!