Apple is Wrong! (In this small way)

How should you section off your delegate (and datasource) methods? I have seen (so far) two ways that Apple does so in their templates:

  1. ‘Brief’ Format:

// MARK: - Table View

2. ‘SeparateComponentsWith ” ” ‘ Format:

// MARK: - Table view data source

What this misses:

  • Firstly, the idea of having a plain-English pragma mark does not make sense – we should not be reading the pragma marks — not when there is an immediately recognizable heiroglyph such as UISomeAPIiKnowBySight.
  • Secondly, this version…

// MARK: - UITableViewDataSource

…can be ⌘-clicked to take you to the docs and/or implementation of the API in question, which makes so much sense – put the instructions next to the tools in case they are needed.

So I change all boilerplate templates to conform their respective APIs. While those two reasons are not earth-shattering, they are compelling enough that I will not forget (or rather, can ‘re-derive’) which convention I adhere to, consistently. Consistency in coding is a very powerful contributor to readability, so sign me up.

So, who is going to let Apple know that they got this one wrong?


Link an Existing Project to GitHub

GitHub is amazing; I am eternally grateful to be born in an age where there is free, accessible, distributed version control software (Git), that is moreover  centralized/backed up in The Ether. But there sometimes is a slight hitch: Github creates the online repository, but Xcode creates the new project. How can I create a new project in Xcode that is simultaneously tracked in its own Github repo?

How to Create a new Xcode project + GitHub repo [almost]  Simultaneously

My solution is the same as associating an existing project with an existing repo.  This is my workflow:

  1. Create the project locally.(If you don’t know, try Treehouse or CodeSchool)
  2. Create the repo on GitHub. (again, Treehouse, or CodeSchool)
  3. Copy the repo’s SSH from GitHub. GitHub BlogPost media-1
  4. Initialize the local git repo, and add the remote to the local repo.

    //git remote add origin

    //git pull origin master

    //git push -u

  5. Pull, Push.
Screen shot of my Terminal
A linked repo is born!

How to Use Boolean Attributes in Core Data

Some Context

The data model of my current project started breaking after I versioned it to #7, rejecting my usage of Booleans. Part of my confusion was due to this selective, late-in-the-game breakage: booleans had been working fine up until now, and I hadn’t changed anything that I recall; #7 added a new transient attribute to a different entity. Shouldn’t they have been breaking from day 1?

I searched fruitlessly for “How to Use Boolean Attributes in Core Data” and variations on that theme, to no avail (excuse the redundancy).  Only after I had this explained to me in person did I realize that the answers were out there, obliquely (amongst the usual suspects: a Stack Overflow post, or this one, and in a few posts years old).

So you’ll forgive me if I broadcast and blast that phrase repeatedly, in the hopes of raising the SEO rankings for “How to Use Boolean Attributes in Core Data.” If you’re reading this, there’s a good chance you’re happy that I did. And if you’re unhappy, well, there are pills for that.


How to Use Boolean Attributes in Core Data


The Simple Way

  1. Check the “Use scalar properties for primitive data types” checkbox while auto-generating your subclasses.
  2. Grab a beer.

    "Use scalar properties for primitive values" checkbox
    The third screen in the process.

The Objective Way

  1. Instead of  YES and  NO , use  @YES  and   @NO .
  2. For control flow purposes (i.e., logical tests), call the  boolValue .



“The opposite of a fact is falsehood, but the opposite of one profound truth may very well be another profound truth.” –Niels Bohr

Do all AIBOs go to robot heaven? Do androids dream of electric sheep? Can Core Data keep track of profound truths? Yes, yes, and yes.

The limitation of scalars is that they must be, or not be, without question: 0/1, YES/NO. But opposite of ‘existence’ is not ‘death’ or ‘sadness’ or any something — it is non-existence.

In Objective-C, what indicates non-existence?  nil. If you need your attribute to have this capability, you need objects, such as NSNumber (ty CH for pointing this out).

Conversely, if you get errors with your boolean (see below), check to see if they are not actually NSNumbers. Two Things to be aware of then:

Thing #1: Setting the Entity’s value – You have added a boolean attribute to your entity in the data model, and had Xcode generate your model classes from it. You might think to code something like so:

You will probably get a warning along the lines of “makes pointer from integer without a cast.” This is because, as mentioned above, Core Data defaults to avoid booleans and other scalars, and so the attribute is stored as an NSNumber. Check your managed object header file (iOS 9: +coreDataProperties header), and you’ll see:

So instead, set the NSNumber like so:

Thing #2: Accessing the Entity’s value – In control flow statements, or wherever you are testing for the logical value of your boolean, you must always use the boolValue, because while  NO is ‘zip, zilch, 0’,  @NO evaluates to true (it exists)!

Instead, use boolValue:

Good hunting, peoples.


Favorite Xcode Shortcuts (an ever-expanding list)

This post has been a long time coming. And yet, it has not come. A shortcut here or there does not seem to merit a post entire, but the collective impact of each of these shortcuts has been of such deep and lasting workflow importance that overlooking it is surely a crime.

Solution: start the Journey of 1,000 Steps post, and add to it as new awesomeness comes to my attention.

Jumping Right In:

  • Expand/Collapse all folders/search results in the navigator panel: ⌘ + click the triangle (rather than click).
  • Expand/Collapse all curly-braced code in an editor panel: ⌘ + ⌥ + ⇧ + ← or →

My criteria, so far, include shortcuts that are part of your regular workflow, but are not [readily] visible on drop-down menus. As always, suggestions more than welcome!