iOS for High School Students: Making Your First iOS App: Part 1/2

[rwenderlich]

This is the official thread to discuss the following blog post: iOS for High School Students: Making Your First iOS App: Part 1/2

[Tempesta]

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!

[MJaoudi]

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

[abigagli]

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.

[Tempesta]

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

[MJaoudi]

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. Since it is a tutorial on making your first iphone app, I didn't want to introduce too many concepts at once.

-Mike

[MJaoudi]

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

[lixcab]

Such a fun tutorial. Thank you very much! I can't wait to start part 2!

[Tempesta]

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

[MJaoudi]

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