Week 2 Questions and Answers

Topics

  • “Deprecated”

  • Storyboard or programmatic views

  • Mystery letters next to file names

  • Designated initializer

  • _instanceVariables in inits and setters


Question: When I look at Storyboard segues, there’s the word deprecated next to push segues. What does deprecated mean?

Answer: Apple will not be phasing out that features soon in the next release. It looks like they’re replaced the push segue with a show segue.


Question: Should I be learning to use the storyboard or learning to make views programmatically?

Answer: It depends on the usage. Storyboard is great for building views quickly and with little code. I was told that one major drawback is that it’s almost impossible to merge conflicts on storyboards. This means that when another programming changing the same view, one person’s changes will be lost. This can be mitigated by creating xib files for each classes and one owner per class. Storyboard tutorial for iOS 7.


Question: What are those A, C and M letters next to file names on the project Navigator in Xcode.

Answer: Those are the git version control symbols. A for added. C for conflict. M for modified. More here.


Question: Do I make the base initializer(init) or the custom initializer (initWithName:Birthday:Hometown:) make the designated initializer?

Answer: Use the custom initializer as the dedicated initializer. For the base initializer, use the dedicated initializer and pass in default values. More here. It saves repeated code and makes there one point of failure.


Question: Why should I use _instanceVariable in the init and setter methods instead of self.instanceVariable? I thought that we were supposed to always call methods.

Answer: For one, using self.instanceVariable in the setter will get an infinite loop because it will keep calling setInstanceVariable. There is a thing called key value observing (KVO) (awesome tutorial), which notices whenever the setter method is called for a property. In the init method, we don’t always want other people to know that we’re setting the property value.

Week 2 Mistakes and Lessons

Mistake: Thinking that tests in Specta run in order.

I was running into trouble with a test that setup a BeforeAll statement that initialized the objects and tested the initialized conditions without reinitializing the objects. The test would sometimes pass and sometimes fail. The reason was that another test was changing the variables before the test that tested the initialization was run.

Lesson: They do not! Make sure that the test resets the objects each time by using BeforeEach instead of BeforeAll.


Mistake: Designing apps for one screen size.

I was playing around with a craiglist type app before coming to the Flatiron School and was about to add the item page for each of the listings. In Xcode 5, the UI in the storyboard was in the shape of an iPhone 5s. In Xcode 6, this became a 600 x 600 point box. I learned that since there were now four screen sizes ( 3.5″, 4.0″, 4.7″ and 5.5″ diagonal), Apple wants apps to be able to support the different screen sizes. If you design the app for the 4.0″ screen, the constraints that Storyboard uses will be messed up for the other formats.

Lesson: Design for all four screen sizes. 


Mistake: Giving my classes confusing names.

Here are my class names for a project with a tableview and a detailed view.

ViewListingsTableViewController
Listing
ListingTableViewController
ListingTableViewCell

What’s the difference between the first and third controller? I couldn’t remember and ended up making the first one into ListingDetailsViewController.

Lesson: Make class names self documenting. 


Mistake: Not initializing an array and thinking that an array property is an empty array to begin with. 

If you don’t initialize an array, as in

NSArray *newArray = [[NSArray alloc] init];

(even if it’s a property) then, the new array property is nil and it will not be able to add things to it.

Lesson: Initialize and avoid nils.


Mistake: Staying late to finish something only to oversleep the next day. 

Lesson: Have a hard deadline for when to leave the office.


Mistake: Not selecting the storyboard as the main interface and not being able to see anything on the app.

Lesson: Make sure that General Settings > Deployment Info > Main Interface is not empty. Otherwise, nothing will show up.

Screen Shot 2014-10-11 at 8.26.05 PM

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;

and

@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;

and

@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>


Question:

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

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

[[NSMutableArray alloc] initWithArry:newArray];

Question:

//Should I use
[newString length];
//or 
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.