Archive for category Objective-C

Alternatives to #pragma mark in Swift

Are you use to using the #pragma mark pre-processor directive in c/c++/objective-c and have found yourself stuck in Swift? If you don’t know why you should be using #pragma mark then I recommend this NSHipster article on #pragma mark.

In Swift use the // MARK: feature instead:

// MARK: This is the comment you want to end up in the jump bar.

Having said that, it is recommended that in Swift you should break up your code into logical units by the liberal use of extensions where possible.

So for example you could implement all the delegate methods that a class conforms to in a class extension, see this stack overflow Q&A and ignore the comments about // MARK: not yet being implemented.

As well as

// MARK:

there is:

// TODO:, and // FIXME:

And a last update via @TheCocoaNaut that // MARK: etc. all work in Objective-C as well.

Tags: ,

Nullability and Objective-C

I’m annotating an Objective-C framework for nullability to improve the interaction of the framework with Swift code. Annotating Objective-C code as I have found has helped a little to clarify my thinking.

I have religiously kept to the following pattern where I always check the return value of [super init]:

@interface Timer : NSObject
@property (assign) startTime;  

@implementation Timer  
  self = [super init];

  if (self)    
    self->_startTime = start;
  return self;

Now I question myself as to why am I checking whether self is nil here, because I’ve been reviewing Objective-C code for annotation for nullability.

There is no need to be checking for nil here, if [super init] returns nil when super refers to a NSObject object the program is going to crash in the very near future anyway.

I think sometime ago I was guided to follow this pattern always so that if I was to change the class that Timer inherits from then the pattern keeps you safe from potential changes in behaviour. Somewhere along the line I forgot this and this just became a pattern I followed.

The consequence now is that when annotating for nullability I’ve got to break the anxiety* that this causes me where I have to accept these checks for nil in many cases do nothing and I have to look beyond this test to determine if initialiser will return nil.

*Cognitive dissonance like this creates a strange anxiety for me that brings work to a halt. The writing of this blog post is the action that breaks the connection.

Useful looking external frameworks for iOS and OS X

Frameworks that work for both iOS and OS X

CocoaLumberjack by Ernesto Rivera. A logging framework. I use this.

Ensembles by Drew McCormack. A synchronisation framework for Core Data.

Extensible iOS and OS X animation library called pop. By developers at Facebook under BSD license.

Frameworks for OS X


Frameworks for iOS

PromiseKit by mcxl. Makes working with asynchronous design patterns easier.

Quadrilaterals on CALayer

Bridging AGGeometryKit with POP for amazing dynamics and animations.

Replacement for NSTimer

I’ve been looking around for a NSTimer replacement. Mostly to avoid needing to make sure the timer is running on a runloop and that your running the timer in a suitable mode. All of the replacements use gcd and queues.

I’ve found a number of possible replacements, but one in particular looks like the one to go for. The three others use the main thread and I want to get away from the main thread. It is easy enough to send a update ui message back to the main thread once the required work has been done.

I like the simplicity of this NSTimer replacement, it doesn’t require a new class instead everything is wrapped up nicely in a block and it will keep on firing until the object that it fires the doSomething message to no longer exists. What I don’t like is that the code is run on the main thread.

This nice simple timer class is also good, but it also runs on the main thread.

Finally I come to MSWeakTimer. I’m in the process of including it in my project so I’ll report back when I’m done. It is more complicated than the other timers but it is not dependent on the runloop or the main queue.

Report Back

MSWeakTimer seems to be working as expected. I needed to make a couple of small changes to get rid of warnings. I’ve got no warnings in my current project and I’m hoping to keep it that way.

Tags: , , ,

Cocoa coding conventions and guidelines

This is basically my notes of the documentation for Apple’s¬†Coding Guidelines for Cocoa. To remember anything of the coding conventions I needed to write stuff down for myself and as such I’ve decided to make a blog post from it, almost purely for my own personal reference. I have also included some of the guidelines from tips and techniques for framework developers.

Read the rest of this entry »

Objective-C & C Miscellaneous improvements via the LLVM Compiler

Tagged pointers.

In 64 Bit cocoa for small value like objects for NSNumber, NSValue, NSDate etc the object is stored in the pointer itself. In addressing modes the 4 least significant bits are unused for pointers to NSObjects. The least significant bit is used as a flag to indicate whether the pointer is tagged or not. If tagged the data is actually stored in the pointer. This is three times more space efficient and 100 times faster to allocate and destroy.
Read the rest of this entry »

Tags: , ,

Return type correctness – The instancetype keyword

Until the 10.9 SDK and the LLVM 5 compiler the following would not produce a warning or error:

NSDictionary *blah = [NSArray array];

The LLVM 5 compiler reports this as a warning.

previous SDKs make declarations like:

+ (id)array;

Read the rest of this entry »

Tags: , ,

Modules as a replacement for Pre-Compiled Headers

Using Xcode 5 and the 10.9 SDK or the iOS 7 SDK you can take advantage of the new compiler feature Modules.

The current #include/#import model for including Framework headers is both  inefficient and fragile. Fragile because if you #define a macro before including/importing a header file that macro can modify the interpretation of the Framework headers and if that macro is defined in some source files and not others the interpretation of the Framework header files will be different depending on source files including the framework.

Read the rest of this entry »

Tags: , , , ,

Strong reference cycles and blocks

If a block refers to a member of an object then the blocks takes ownership of the object. If the object has also taken ownership of the block to keep it alive for at least the lifetime of the object then this creates a strong reference cycle. Possible solutions are:

  • Create a local variable within the scope where the blocks is implemented or have something like a cancel method on the object that nils the member that is the one that owns the block.
  • Or you can use weak references in the scope where the block is implemented and then assign a strong reference within the block scope and check to see if the reference is nil or not before deciding on what work to do within the block.

Read the rest of this entry »

Tags: ,

Explicitly typed Enums.

Explicitly typed enums makes for better type checking and improved code completion.

With the 10.8 SDKs you get warned if you assign between different types of enums. Traditional C enums are implicitly int.
Covered in WWDC 2013 Session 404 – Advances in Objective-C and previsouly covered in depth during WWDC 2012 Talk 405 – Modern Objective-C.

Enums had been traditionally compiled like so:

enum { ABC, JKL, XYZ };
typedef NSUInteger MyEnum;

The new enum is:

enum MyEnum : NSUInteger { ABC, JKL, XYZ };
typedef MyEnum MyEnum;

There are some convenience macros that make it easier to declare enums, either simple values or bit mask options. To define an enum of numeric values you use following macro:

typedef NS_ENUM(NSUInteger, MyEnum) { ABC, JKL, XYZ };

And to define a bit mask enum with options you use:

typedef NS_OPTIONS(NSUInteger, MyOptions)
  kFaster = (1 << 3),
  kBetter = (1 << 4),
  kAwsome = (1 << 5)

This improves code completion and type checking.

Tags: , , , , ,