Week 1 Questions and Answers

Question: When should I explicitly write strong vs. weak when declaring properties in class interfaces?

In other words, what is the difference between

@property (strong, nonatomic) NSString *name;


@property (nonatomic) NSString *name;


And when do I use:

@property (weak, nonatomic) NSString *name;

Answer: I found the answer on Ry’s Objective-C Tutorial, which I think is an amazing reference, because it’s very well organized and comprehensive.

In short,

@property (strong, nonatomic) NSString *name;


@property (nonatomic) NSString *name;

are equivalent. However, the first version is better, because there is no doubt. (Learning iOS Development by Maurice Sharp et al. p.79)

An example of when to use weak is when two objects have each other in their properties.

A Person may have a

@property Computer *myComputer;

and a computer may have a

@property Person *owner;

but you would not want to have both properties be strong because it would cause a memory leak (the program will use memory and not give up the memory, slowing down the phone).

In this case, I would make the owner weak because the parent object is the Person and not the computer.

@property (weak) Person *owner;

Question: If I clone a branch from Github and the branch that I wanted was not moved to my local machine, what should I do to get that branch from the remote? 

Answer: git checkout -t origin/<branch name>


//Should I use
[NSMutableArray new];
[[NSMutableArray alloc] init];

Answer: It’s up to you. The latter is more consistent because sometimes you might

[[NSMutableArray alloc] initWithArry:newArray];


//Should I use
[newString length];

Answer: Dot notation is more readable, but opinions may differ, sometimes within the same person. Ex.

Dot notation in Objective-C: 100% Pure Evil

In Which I Embrace Dot Notation

Week 1 Mistakes and Lessons

Topics: Git/Github, Environment Setup, Objective-C basics (loops, methods), unit testing, NSArray, NSDictionary

Mistakes and Lessons

1. Mistake: Going directly into Xcode with a half-baked plan leads to a lot of spinning my wheels and rabbit holes.

What happens here is that I think I know what I want to do in my head, sort of, but I don’t have the steps explicitly worked out yet and so as I write, I concentrate on one part of the program and forget details that I hadn’t accounted for in the other parts. Any thing that I find myself doing is just spamming different code and praying for it to work. I’m using the computer to validate for me instead of having a plan and running code that I think will work.

Lesson: Know how to do a task without a computer before trying to tell a computer to do it.

2. Mistake: not paying enough attention to spelling.

Spot what’s wrong with this for loop:

for (NSinteger fiboCounter = 1; fiboCounter < numberInFiboSequence; fiboCounter++)
    NSNumber *currentFiboNumber = fiboNumbers[fiboCounter];
    NSNumber *previousFiboNumber = fiboNumbers[fiboCounter - 1];
    NSInteger nextFiboNumber =  [currentFiboNumber integerValue] + [previousFiboNumber integerValue];
    fiboNumbers[fiboCounter+1] = [NSNumber numberWithInteger:nextFiboNumber];

Yeah, that’s right. It’s the NSinteger in the first line. It should be NSInteger.   I was getting missing identifier errors for the fiboCounter, which totally didn’t make sense, because I had already initialized it (I thought).

Lesson:  Misspelling sucks, listen to Xcode.

3. Mistake: thinking that doing everything by myself is more original and superior to copying other people’s way of doing things.

First of all, pretty much nothing is completely original.

Everything is a remix of previous things made. Why would you want to ignore how other people are doing it anyway?

“If I have seen further, it is by standing on the shoulders of giants.” 

-Isaac Newton

Even this quote proves my point. Newton was a smart guy, probably on of the few that actually did make significant advances in science. Despite that, the idea of “shoulders of giants” wasn’t original to Isaac Newton. He was preceded 500 years earlier by Bernard of Chartres.

When I first approach a problem, multiple ways of solving the problem will appear in my mind. If I was working alone, I might implement one and then try another one. The benefit of having a class of people who are working on the same problems means that I can crowdsource other solutions from them. They can teach me smart methods that I didn’t even know existed and I can learn 19 new methods in the time it would take to learn one.

Pair programming is another great way to learn from classmates. I might have my way of doing it, but pairing means that I must contemplate another person’s way as I am still solving the problem and can follow it all the way through. An additional benefit is providing motivation to finish and having someone to celebrate with when we’re done.

Lesson: Solve the problem one way and then rely on my classmates to give me other ideas for solving the same problem. Even better, pair with another person to program it, especially late at night.