Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trial
Justin Black
24,793 PointsWhy store the random color in a variable?
Having not finished the video just yet, but having a little knowledge of iOS development in Objective C. Why are we instantiating an entire variable for the random color? Makes no sense to me.
Instead, doing something like this:
@IBAction func showFunFact() {
funFactLabel.text = factBook.randomFact()
view.backgroundColor = colorWheel.randomColor()
funFactButton.tintColor = view.backgroundColor
}
Works just the same, without the potential added expense in memory of the new variable when it's temporary. Instead just reading the getter of our views background in order to set the tint of the button itself.
Any specific benefits to potentially wasting memory for a temporary value? This can become problematic, in say an older application that is not utilizing ARC and you forget to deal with the release/retain lifecycle manually.
2 Answers
Pasan Premaratne
Treehouse TeacherThe simple answer is because we dont want to introduce too many concepts at once. The large majority of our student base come from zero programming experience and this is the very first course on developing an app. Introducing static methods when people are still trying to understand OOP can get overwhelming.
I think the misconception is viewing Treehouse content as tutorial series rather than a learning path that introduces concepts slowly over multiple courses. The simple fact of mentioning ARC, pointers, and lifecycles assumes a lot of programming background.
Hope that makes sense. You will see a lot of this as you go through our content because we're not just teaching students how to make iPhone apps, we're also teaching them basic programming skills.
landonferrier
25,097 PointsJustin, you bring a very good point to the table. When coding advanced features or having a code file reach 1,000 lines or more, simplifying the code can make all the difference in the world for the computer and for your eyes. For example, here is one line of code that can be split over several with nesting:
UIImage *myNewImage = [UIImage imageWithData:[NSData dataWithContentsOfURL:[NSURL urlWithString:@"A Random String!"]]];
or
NSURL *url = [NSURL urlWithString:@"A Random String!"];
NSData *data = [NSData dataWithContentsOfURL:url];
UIImage *image = [UIImage imageWithData:data];
As the second solution would work, it declares two more pointers in memory that the first solution doesn't. Over time, an app would use more memory and even lead to strong reference cycles. Automatic Reference Counting makes doing the second solution easy and clean removing all the retain and release messages. With simple code, you will have to decide what you are able to read better.
If you have any questions, feel free to ask!
Justin Black
24,793 PointsJustin Black
24,793 PointsPasan Premaratne makes absolute perfect sense to me. I often forget that not everyone in the world has been programming for over 20 years. I did learn a lot from the Objective C classes which helped me to build a very indepth app ( essentially a full on mobile only social network ) that is now being redone in swift.
Coming from a 20 year background in programming with exp in basic, pascal, c#, and even a little assembly and moving into more of the modern web age as well ( javascript, php, perl, ruby, etc ) I think it gives me an advantage in learning, as most of the principals are the same just need to really learn the syntax differences and functionality nuances.