Learn to Code iOS Apps 3: Your First App

Discussion of the official tutorials published on raywenderlich.com. Please only discuss the official tutorials here - for general questions, use the General Discussion forum instead.

Learn to Code iOS Apps 3: Your First App

Postby rwenderlich » Wed Jan 30, 2013 11:00 am

This is the official thread to discuss the following blog post: Learn to Code iOS Apps 3: Your First App
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Ray Wenderlich
Blog: http://www.raywenderlich.com
Twitter: http://twitter.com/rwenderlich
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
User avatar
rwenderlich
Team Member
Site Admin
 
Posts: 2230
Joined: Thu Dec 23, 2010 4:14 pm
Has thanked: 28 times
Been thanked: 366 times

Re: iOS for High School Students: Making Your First iOS App:

Postby Tempesta » Wed Jan 30, 2013 9:21 pm

Well done, clear&easy, thanks! :-)

Question: which are the benefits/disadvantages of:

- IBOutlet UILabel *label;
- IBOutlet UILabel *timerLabel;

instead using these code lines (generated by the Assistant Editor):

- @property (strong, nonatomic) IBOutlet UILabel *timerLabel;
- @property (strong, nonatomic) IBOutlet UILabel *scoreLabel;

Can you suggest a simple "checklist" to follow when creating IBOutlets? ;-)
Thank you!
Tempesta
Hacker
 
Posts: 22
Joined: Sun Oct 07, 2012 9:10 am
Has thanked: 3 times
Been thanked: 0 time

Re: iOS for High School Students: Making Your First iOS App:

Postby MJaoudi » Wed Jan 30, 2013 10:35 pm

Hey Tempesta,

To explain this, I just want to be sure you know what a property is and what an instance variable is (usually shortened to ivar). Your first chunk of code you had was an example of an instance variable.

Code: Select all
IBOutlet UILabel *label;


Then there is something called a property.

Code: Select all
@property(nonatomic, retain) IBOutlet UILabel *label;


Now an instance variable is basically what a class will use to store its data. The information stored in that instance variable is private. No other class knows that data even exists. If it doesn't know it exists, then it cannot be changed or read outside that class.

Then you have properties. Properties allows the outside world to see that a specific ivar exists. It does that by automatically making something called getters and setters. Getters will read the value of data. Setters will set the value of data. So using properties you can have code like this:


Code: Select all
myObject.label = ….;
[myObject setLabel: … ];

newLabel = myObject.label;
newLabel = [myObject label];


An ivar by itself will be private. An ivar with a property will be public. However, you can write a property without an ivar. Then behind the scenes, the ivar will automatically be created for that property. So as a result, if I ever need to have some public data, I only make a property and not an ivar.

So in summary it boils down to this:

If you have data that you want to remain private: Make an ivar.
If you have data that you want to be public: Make a property.


For the project, I made everything an ivar because I didn't want to give the anything outside that view controller the ability to access the buttons and labels. In many cases you will need to make them public which is why the IBOutlet is generated to be a property.

I hope that helped! Let me know if I didn't make anything clear or if you have any more questions.
-Mike
MJaoudi
Team Member
Baby Hacker
 
Posts: 9
Joined: Wed Oct 12, 2011 7:51 pm
Has thanked: 0 time
Been thanked: 2 times

Re: iOS for High School Students: Making Your First iOS App:

Postby abigagli » Sun Feb 03, 2013 7:31 pm

If you have data that you want to remain private: Make an ivar.
If you have data that you want to be public: Make a property.


For the project, I made everything an ivar because I didn't want to give the anything outside that view controller the ability to access the buttons and labels. In many cases you will need to make them public which is why the IBOutlet is generated to be a property.

I hope that helped! Let me know if I didn't make anything clear or if you have any more questions.
-Mike


Hi Mike,
great tut, but I don't fully agree with the above statements.
Access control on internal state is not really controlled by making something an ivar or a property, but rather by "where" you declare/define the thing.
In your case, you actually put the ivars declaration in the interface section, which is just the most "public" place you could have come up to... ;)
I think, if you really wanted to have those button and labels hidden from the outside world, that you should have declared them either in the class extension that latest Xcodes define for you in the .m file (and there they can be either ivars or properties, remaining visible to the viewcontroller only) or directly (as ivars only) in the @implementation section.

What do you think?

Regards,
Andrea.
abigagli
Subscriber since Feb 10, 2014
n00b
 
Posts: 4
Joined: Tue Oct 25, 2011 8:37 pm
Has thanked: 0 time
Been thanked: 0 time

Re: iOS for High School Students: Making Your First iOS App:

Postby Tempesta » Mon Feb 04, 2013 5:43 pm

Hi Mike&Andrea,
let's see Mike's answer @Andrea's post! ;-) What do you think about trying to define a simple pattern that refers to basics concepts (ivars, @properties, @interface, etc.) in both .h and .m files? A sort of reminder-guide to follow step by step whenever someone gets some doubts about where something goes (or not)/where :-) Would be really appreciated! Something like this:

.h file (interface)
-----------------------
#import <UIKit/UIKit.h>

//Here goes...

@class DemoViewController; //this line only exists when...
@protocol DemoViewControllerDelegate <NSObject> //@protocol section only exists if... and if it exists, then at the beginning of the file, we must find @class
//Here goes...
@end

@interface DemoViewController : UITableViewController <ListOfClassDelegatesGoHere, OnlyIfWeConformToAClassDelegate> {
//Here goes...
}

//Here goes...

@end



.m file (implementation)
-------------------------------------
#import "DemoViewController.h"
@interface DemoViewController () //This block is needed if/when.. What is this used for?
//Here goes...
@end

//Hero goes...

@implementation DemoViewController{
//Here goes...
}

//Here we find methods described in the .h file but even methods that haven't been defined there, and we also find...
//Strongly recommened to use #pragma mark - Separators here


- (void)viewDidLoad { [super viewDidLoad]; //This "super" line is needed when/becauase... }

@end
Tempesta
Hacker
 
Posts: 22
Joined: Sun Oct 07, 2012 9:10 am
Has thanked: 3 times
Been thanked: 0 time

Re: iOS for High School Students: Making Your First iOS App:

Postby MJaoudi » Fri Feb 15, 2013 11:57 pm

abigagli wrote:
If you have data that you want to remain private: Make an ivar.
If you have data that you want to be public: Make a property.


For the project, I made everything an ivar because I didn't want to give the anything outside that view controller the ability to access the buttons and labels. In many cases you will need to make them public which is why the IBOutlet is generated to be a property.

I hope that helped! Let me know if I didn't make anything clear or if you have any more questions.
-Mike


Hi Mike,
great tut, but I don't fully agree with the above statements.
Access control on internal state is not really controlled by making something an ivar or a property, but rather by "where" you declare/define the thing.
In your case, you actually put the ivars declaration in the interface section, which is just the most "public" place you could have come up to... ;)
I think, if you really wanted to have those button and labels hidden from the outside world, that you should have declared them either in the class extension that latest Xcodes define for you in the .m file (and there they can be either ivars or properties, remaining visible to the viewcontroller only) or directly (as ivars only) in the @implementation section.

What do you think?

Regards,
Andrea.


Hey Andrea,

Yep that is a better way of organizing your code. :D Since it is a tutorial on making your first iphone app, I didn't want to introduce too many concepts at once.

-Mike
MJaoudi
Team Member
Baby Hacker
 
Posts: 9
Joined: Wed Oct 12, 2011 7:51 pm
Has thanked: 0 time
Been thanked: 2 times

Re: iOS for High School Students: Making Your First iOS App:

Postby MJaoudi » Sat Feb 16, 2013 12:34 am

Tempesta wrote:Hi Mike&Andrea,
let's see Mike's answer @Andrea's post! ;-) What do you think about trying to define a simple pattern that refers to basics concepts (ivars, @properties, @interface, etc.) in both .h and .m files? A sort of reminder-guide to follow step by step whenever someone gets some doubts about where something goes (or not)/where :-) Would be really appreciated! Something like this:


Sure! I really like that idea. I will start by filling in your template.
.h file (interface)
-----------------------
#import <UIKit/UIKit.h>

//Here goes...

@class DemoViewController; //This is called forward declaration. It tells the code that this class exists.
@protocol DemoViewControllerDelegate <NSObject> //You can use this section to create a custom delegate.
@end

@interface DemoViewController : UITableViewController <ListOfClassDelegatesGoHere, OnlyIfWeConformToAClassDelegate> {
//Place ivars here
}

//Place method declarations here and properties

@end



.m file (implementation)
-------------------------------------
#import "DemoViewController.h"
@interface DemoViewController ()
//This block is used to declare private methods
@end

@implementation DemoViewController
//Here we find methods described in the .h file but even methods that haven't been defined there, and we also find...
//Strongly recommened to use #pragma mark - Separators here


- (void)viewDidLoad { [super viewDidLoad]; //Super refers to the super class. In this case it is UIViewController. You have overwritten this method so it will no longer be called. That line will call the method that was overwritten. }

@end


Hope this helps! Let me know if you have any more questions!

-Mike
MJaoudi
Team Member
Baby Hacker
 
Posts: 9
Joined: Wed Oct 12, 2011 7:51 pm
Has thanked: 0 time
Been thanked: 2 times

Re: iOS for High School Students: Making Your First iOS App:

Postby lixcab » Sun Mar 03, 2013 6:37 pm

Such a fun tutorial. Thank you very much! I can't wait to start part 2! :D
lixcab
n00b
 
Posts: 1
Joined: Sun Mar 03, 2013 6:35 pm
Has thanked: 0 time
Been thanked: 0 time

Re: iOS for High School Students: Making Your First iOS App:

Postby Tempesta » Sat Mar 09, 2013 12:36 pm

Hi Mike,
thank you for your reply! ;-) I'm still confused about ivars location.

In "The iOS Apprentice 1, Getting Started" PDF (page 74) I found this "As of iOS5 we can add instance variables to the @implementation section instead, which is a better place for them."

Does this mean that can we completely forget to put ivars in the .h file and use it for @property and method declarations only?

Thank you ;-)
Alex
Tempesta
Hacker
 
Posts: 22
Joined: Sun Oct 07, 2012 9:10 am
Has thanked: 3 times
Been thanked: 0 time

Re: iOS for High School Students: Making Your First iOS App:

Postby MJaoudi » Mon Mar 11, 2013 5:36 am

Hey Alex,

Wow, I just realized that I forgot to put that in the template.

So in modern objective-c, you can place ivars in the .h file and the .m file. The decision all comes back to the private vs public. This is formally known as encapsulation. It is the idea that you want to expose as few details about the inner workings of a class as possible. You don't know how the buttons work, but you know how to use them and interact with them.

Anyways, things that you want to be publicly visible, you will put in the header file. When you have ivars in the header file, you cannot access or write to that data but as a human, you know that it exists in the class. Placing the ivars in the @implementation hides the variable from the public. It will also speed up compile times. So in most cases, placing the ivars in the @implementation section is better.

The only time you have to put the ivar in the header file is if you want the ivar to be inherited by a subclass. If you place the ivar in the .m file, it will not be inherited. Otherwise the @implementation sections works fine.

I hope that clears up some confusion. Let me know if there are any more questions I can answer!

-Mike
MJaoudi
Team Member
Baby Hacker
 
Posts: 9
Joined: Wed Oct 12, 2011 7:51 pm
Has thanked: 0 time
Been thanked: 2 times

Next

Return to Official Tutorials

Who is online

Users browsing this forum: Baidu [Spider] and 5 guests

cron