Tag Archives: Blocks

How to read MFi Controller input in iOS

Nimbus ControllerI bought a SteelSeries Nimbus controller the other day. It’s Made For iOS (MFi) and supported by many games, including those on OS X and tvOS.

Seriously, it’s a phenomenal controller! Naturally I wanted to see how easy (or difficult) it was to use it in my own projects.

Turns out that for game developers, it’s not that tough to make it work – thanks to Apple’s great GameController Framework that was introduced in iOS 7.

Here’s how I did it, following Apple’s document called Game Controller Programming Guide.

Continue reading





How to avoid “Capturing ‘self’ strongly in this block is likely to lead to a retain cycle”

I was trying to update a UILabel from inside a block the other day, and was puzzled by the above Xcode warning: “Capturing ‘self’ strongly in this block is likely to lead to a retain cycle”. The full code looked like this:

 

self.mainController.controllerPausedHandler = ^(GCController *controller){

        // triggers a warning
        [self displayMessage:@"Pause Button"];

    };

As it turns out, the trouble was that a block executed in self cannot capture a reference to itself (self) without there being a never ending loop involved. It’s probably to complicated for me to understand and/or care about, but thankfully there’s a relatively easy way to correct this problem.

Continue reading





How to handle device rotation since iOS 8

Back in the iOS 5 days, there was a method called shouldAutorotateToInterfaceOrientation. Since iOS 8 we’re no longer meant to use that, and instead use a much better technique: size classes.

In a nutshell, iOS 8 and above will call the viewWillTransitionToSize method on your UIViews. This looks a bit more complex than it actually is, because it contains two optional blocks:

Continue reading





How to create alert views and action sheets in iOS 8

Screen Shot 2015 09 28 at 23 37 12

Up until iOS 7 we could use the UIAlertView and UIActionSheet classes to bring up alerts and action sheets respectively. As of iOS 8 those classes are deprecated. Although they still work, we’re encouraged to use the UIActionController class instead. Here’s how to use it.

The main difference is that both of the old classes have been converged into one, so now we simply tell the alert controller how we want to bring up the information.

While the old classes used a delegate protocol so we could react to the outcome of user interactions, the UIActionController class uses completion blocks, making our coding efforts a little easier. All we have to do is create an action, specify things like title, subtitle and appearance, and add a block that shall be executed upon completion.

Here are three examples.

Continue reading





How to create an Alert View in Cocoa

Much like a UIAlertView, you can run an NSAlert on Mac like this:

// run a modal alert
NSAlert *alert = [[NSAlert alloc]init];
[alert addButtonWithTitle:@"Excellent"];
[alert setMessageText:@"This is your message."];
[alert runModal];

Or, if you prefer a much simpler one-liner you can use NSRunAlertPanel:

NSRunAlertPanel(@"Title", @"This is your message.", @"OK", nil, nil);

Your App Icon will be displayed in the window. Here’s an example:

Screen Shot 2014-05-01 at 18.20.43

The result will be the same: a separate modal window is brought up, waiting for the user to dismiss it with any of the buttons. The latter method will return an NSInteger to indicate which button was pressed.

Alert Sheets

Instead of the Alert Panel, we can also run an Alert Sheet. The functionality is the same, but instead of being a floating window the Alert Sheet is attached to your main application window. This is what it looks like:

Screen Shot 2014-05-03 at 10.10.31

You can create Alert Sheets like this:

NSAlert *alertSheet = [NSAlert alertWithMessageText:@"Title goes here." defaultButton:@"OK" alternateButton:nil otherButton:nil informativeTextWithFormat:@"And your message goes here goes here. Nice."];
    [alertSheet beginSheetModalForWindow:self.window modalDelegate:nil didEndSelector:nil contextInfo:nil];

The above method relies on a delegate to be called so you can evaluate which button was clicked. Alternatively – if you prefer blocks and evaluate the result right there and then – you can call the Alert Sheet with

[alertSheet beginSheetModalForWindow:self.window completionHandler:^(NSModalResponse returnCode) {        
    // check returnCode here
}];




How to execute a method on another thread using Grand Central Dispatch

Everything in your iOS app happens on “the main thread” by default. It’s like at the hairdresser’s – one thing after another. Since iOS 4 however you can execute things “asynchronously” by using Grand Central Dispatch. With it comes another phenomenon called Blocks.

To make use of this feature you need to

  • define your own dispatch queue (dispatch_queue_t)
  • create your own dispatch queue (giving it a reverse DNS identifier)
  • wrap what you want to execute inside block

The syntax for this looks a bit odd and not like Objective-C, because those are “classic” C statements. As for Blocks: think of them as an anonymous function call. They allow you to specify how the background queue should react after the execution of your method has finished on the other thread.

Let’s see how this works. First define the queue, just under all those import statements will work fine:

dispatch_queue_t specialQueue;

When you’re ready to use it, give it an identifier and add an execution block:

specialQueue = dispatch_queue_create("com.versluis.specialapp", NULL);
dispatch_async(specialQueue, ^{ [self yourMethod]; });

The identifier will show up in log messages and Instruments if applicable. The block is executed at the end of the operation, on your “specialQueue”. It’s a great place to asses success or failure.

Note that UI Elements can only be updated from the main thread, so don’t change any labels from that “specialQueue”. You can however dispatch things specifically from the main queue while in your own queue:

dispatch_async(dispatch_get_main_queue(), ^{ application.networkActivityIndicatorVisible = NO; });

Here we switch off the network indicator while we’re in our own queue, by dispatching this statement on the main queue.