Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm following the Stanford Developing iOS 7 course 2013 2014 on iTunes U (just for your info) and I'm having some general questions on the Objective C language. Thanks for your help!
Question 01
This is what I understood about #synthesize:
With the newest versions of Xcode there is no need to perform #synthesize for declaring a setter or a getter. It is done automatically for the programmer if the getter and setter is kept at default. However I have been taught I need to declare the synthesize when overrides BOTH the getter and the setter.
My question is: why only when BOTH are being overriden? It should make more sense to me you would need to declare the synthesize already when only one needs to be overridden?
Question 02
- (void)addCard:(Card *)card atTop:(BOOL)atTop;
- (void)addCard:(Card *)card;
Are 2 different public methods used in the course I'm following.
Question: Am I required to state these two as 2 individual methods. Couldn't I just use the first one, whilst specifying 2 different blocks of code to perform, by an IF ELSE clausule whether the BOOL is YES or NO? Wouldn't that be exactly the same outcome?
Question 03
Having a rather simple program with just a single view, I noticed I do not need to publicly specify any methods in my viewcontroller.h. I reckon this only would be needed if your program is more complex and contains several MVC where the controllers would need to "speak" to each other. Is this a right assumption to make, generally speaking, when making a proper MVC based program?
I thank you for your time and effort. Excuse me if my questions seem basic or do not make complete sense. I'm on the iOS learning path stage 1, with little OOP experience.
Question 1:
You are right about this. If you override the getter and setter then you need to #synthesize the property. I'll have to have a further look for why though.
Question 2:
Yes, you could just have the first method. However, the second method is there as a convenience and would normally contain code something like this...
- (void)addCard:(Card *)card
{
[self addCard:card atTop:YES];
}
Then the designated method would do something like...
- (void)addCard:(Card *)card atTop:(BOOL)atTop
{
if (atTop) {
// something to add card to top.
} else {
// something to add card at bottom.
}
}
i.e. it just routes the method call to the "designated" method but uses a default value for the BOOL.
Question 3:
The .h file is there as an interface file. It would be similar to a set of web services on a server. The class can do all sorts of stuff internally but it only needs to declare stuff in the .h interface file if something needs to access them externally.
For instance, you might have a class called Car. It might have a button called accelerator that would access an internal method and increase the speed. None of this needs to be exposed to external classes.
However, the same car might have a property called colour or a method called addFuel. These would need to be available externally so the user can see the colour and add fuel. These both need to go in the .h file.
I hope that makes sense.
Question 1: I have been taught I need to declare the synthesize when
overrides BOTH the getter and the setter. My question is: why only
when BOTH are being overriden? It should make more sense to me you
would need to declare the synthesize already when only one needs to be
overridden?
Once you use #synthesize you are using the setter/getter provided by the compiler. If you create your setter/getter without synthesize then you need to write both the methods, if you have readwrite property.
Question 2: Am I required to state these two as 2 individual methods.
Couldn't I just use the first one, whilst specifying 2 different
blocks of code to perform, by an IF ELSE clausule whether the BOOL is
YES or NO? Wouldn't that be exactly the same outcome?
Yes it is good to have two different methods. As these two vary on the parameters and the caller will know what is happening inside the method. If you wish to put if-else, for this you will require an ivar or a global value to check, but if you pass the BOOL no need for it.
Question 3: Having a rather simple program with just a single view, I noticed I do
not need to publicly specify any methods in my viewcontroller.h. I
reckon this only would be needed if your program is more complex and
contains several MVC where the controllers would need to "speak" to
each other. Is this a right assumption to make, generally speaking,
when making a proper MVC based program?
Even though you don't have any complex but always follow the architecture of MVC.
The controller in iOS programming usually refers to the view controllers. Think of a view controller as a bridge between the model and your views. This controller interprets what is happening on one side and uses that information to alter the other side as needed. For instance, if the user changes some field in a view, the controller makes sure the model changes in response. And if the model gets new data, the controller tells the view to reflect it.
Question 01
(edited) You need #synthesize to tell the compiler to create the ivar (eg. _myString) for you. You could also declare the ivar manually.
Question 02
You could just declare the first one yes. In fact the second one just a shorthand method, providing a default value for atTop. In most cases, you would implement the method exactly as you explained:
- (void)addCard:(Card *)card atTop:(BOOL)atTop {
if (atTop) {
// atTop == YES
}
else {
// atTop == NO
}
}
- (void)addCard:(Card *)card {
[self addCard:card atTop:YES]; // or atTop:NO, depending of the default value you want to use
}
Question 03
Again, yes. Your view controllers should expose as little properties and methods as possible, and make public only things that should be available for the rest of the application to use. So in the case of the single VC / single view program, having an empty VC interface is normal.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
When I was learning other languages such as Java, all the sample code tells you that you should always mark a field private. And the methods that do the internal stuff are also marked private or protected.
But when it comes to Swift, I see that the sample code from a lot of the tutorials (such as raywenderlich.com) seldom marks something as private. They just leave it internal (without adding any modifiers).
In contrast, all the android tutorials mark some of the fields as private and provide no getters or setters for them.
For example, I read this search bar tutorial a while ago:
https://www.raywenderlich.com/113772/uisearchcontroller-tutorial
When I was reading through it, I was thinking about: "Why did you not mark this private?"
let searchController = UISearchController(searchResultsController: nil)
I mean, it does not make sense for other classes to access the search controller of my VC. It's mine!
Question:
Why don't most, if not all tutorials provide sample code that contains private properties? Is it because iOS is more secure or something? Should I mark suitable stuff as private in production code?
I hope this is not too opinion based. In Java, you will never make a field public, right? That's just a fact - you should not make fields public. So please don't close as opinion based, it's not.
Why not everything private? There are several really common scenarios that I've seen that always favor having the variable either internal or public.
Delegate methods:
func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
let cell = tableView.dequeueReusableCellWithIdentifier(
myCellID,
forIndexPath: indexPath);
return cell;
}
This method will be called not internally by you, but rather by the iOS system that manages and displays the tableView. The delegation pattern is widely used within iOS development.
Data exchange between two ViewControllers, where you simply want to set the other ViewController's field:
class MyVC1: UIViewController {
var flagShouldUpateColors = false {
didSet{
// some stuff
}
}
}
Then at some point you want to notifiy this ViewController that the flag should be set to true. You do that my simply acccessing it's field.
Also selectors. When I register an instance of a ViewController for some notification, I pass the name of a method that I have within the very same ViewController. It is to be called when the notification triggers. Basically what the code says is "please call this method for me when this occurs". If you say call this private method when this occurs, it wouldn't make sense would it ? How is the caller supposed to call it(aside from reflection and other unoptimized ways). Here is example:
override func viewDidLoad() {
NSNotificationCenter.defaultCenter().addObserver(
self,
selector: #selector(self.doStuffWhenEnterForeground),
name: UIApplicationWillEnterForegroundNotification,
object: app)
doStuffWhenEnterForeground();
}
func doStuffWhenEnterForeground() {
}
Main difference between Java and Swift is in properties.
Java has no concept of properties. It has fields and if you want to allow public access to those fields you can either access them directly or through getter/setter methods.
If you create public field that needs to be protected later on you will have to use methods and thus your public API will be changed - fields are accessed without parens and methods with them.
Swift is different in that regard. You can protect your field access with getter/setter at any point without changing API. So if you have field that is part of public API you can just leave it as is (without making it private) and without having getter/setter methods attached to it.
Encapsulation in Java and Swift are of the same importance. What differs is how it is achieved (implemented). Since there is no pressure for premature encapsulation in Swift and it is only matter of adding visibility specifier when appropriate there is some lack of discipline in adding those in tutorial code where main purpose is not enforcing encapsulation, but teaching some other concepts and how-to's.
Why don't most, if not all tutorials provide sample code that contains private properties? Is it because iOS is more secure or something? Should I mark suitable stuff as private in production code?
Probably because it's simpler, save few keystrokes and doesn't add unnecessary overhead to understanding the main theme of tutorial.
Should I mark suitable stuff as private in production code?
Yes, you should do it for the same reasons you would do it in Java. Notice 2 things, however:
There is no such thing as protected.
Access modifiers in Swift work differently compared to many other languages. private restricts access to variable or function to file where it was declared, regardless of who will access them. Thus, if you have 2 classes declared in the same file, they both can see private fields of each other. On the other hand, you can't see private fields even from extension of that class if this extension in other file. It looks strange at first and you just need to get used to it.
So I've read about delegate explanation and practices a lot, but I still seem to not get it, I have specific questions and I would love to have some insightful simple answers.
Why use delegate over instance method? In UIAlertView why not just make – alertView:clickedButtonAtIndex: an instance method that will be called on my UIAlertView instance?
What is the delegate property? why do I have to make delegate property and define it with that weird syntax #property (nonatomic, strong) id <ClassesDelegate> delegate
Is delegate and protocol are two faces for a coin?
When do I know I should implement delegate in my app instead of direct calling?
Is delegate used as much and as important in Swift?
What gets called first and why? The method in the class who made himself a delegate? or the delegate method itself in class where it is declared?
Thank you for taking the time to go through this, I am desperately looking for a clear and helpful answers to my questions, feel free to give example or cover some related topic!
The advantage of delegation is Dependency Inversion.
Usually code has a compile-time dependency in the same direction of the run-time calling dependency. If this was the case the UITableview class would have a compile-time dependence on our code since it calls our code. By using delegation this is inverted, our code has a compile-time dependency on the UITableview class but the UITableview class calls our code at run-time.
There is a cost involved: we need to set the delegate and UITableview has to check at run-time that the delegate method is implemented.
Note: When I say UITableview I am including UITableviewDelegate and UITableviewDatasource.
See: Dependency inversion principle and Clean Code, Episode 13.
Maybe a real life example can better describe what's different in the delegation design pattern.
Suppose you open a new business, and you have an accountant to take care of the bureaucratic stuffs.
Scenario #1
You go to his office, and give him the information he needs:
the company name
the company # number/id
the number of employees
the email address
the street address
etc.
Then the accountant will store the data somewhere, and will probably tell you "don't forget to call me if there's any change".
Tomorrow you hire a new employee, but forget to notify your accountant. He will still use the original outdated data you provided him.
Scenario #2
Using the delegation pattern, you go to your accountant, and you provide him your phone number (the delegate), and nothing else.
Later, he'll call you, asking: what's the business name?
Later, he'll call you, asking: how many employees do you have?
Later, he'll call you, asking: what's your company address?
The day after you hire a new employee.
2 days later, he'll call you asking: how many employee do you have?
In the delegation model (scenario #2), you see that your accountant will always have on demand up-to-date data, because he will call you every time he needs data. That's what "don't call me, I'll call you" means when talking of inversion of control (from the accountant perspective).
Transposing that in development, for example to populate a table you have 2 options:
instantiate a table control, pass all the data (list of items to display), then ask the table to render itself
instantiate a table control, give it a pointer to a delegate, and let it call the delegate when it needs to know:
the number of rows in the table
the data to display on row no. n
the height the row no. n should have
etc.
but also when:
the row no. n has been tapped
the header has been tapped
etc.
Firstly, don't feel bad that all if stuff isn't clear yet. This is a good example of something that seems tricky at first, but just takes time really click. That will happen before you know it :-). I'll try and answer each of your points above:
1) Think of it this way - the way UIAlertView works now, it allows Apple to “delegate” the implementation of the alertView:clickedButtonAtIndex: to you. If this was an instance method of UIAlertView, it would be the same implementation for everyone. To customize the implementation would then require subclassing - an often over relied upon design pattern. Apple tends to go with composition over inheritance in their frameworks and this is an example of that. You can read more on that concept here: http://en.wikipedia.org/wiki/Composition_over_inheritance
2) The delegate property is a reference to the object which implements the delegation methods and whichs should be used to “delegate” those tasks to. The weird syntax just means this - a property that holds a reference to an object that adheres to the protocol.
3) Not quite - delegation leverages protocols as a means for it’s implementation. In the example above, the is this the name of a protocol that an object which can be considered a delegate for that class must adhere to. It is inside that protocol that the methods for which a delegate of that class must implement are defined. You can also have optional protocol methods but that’s a different topic.
4) If I understand the question correctly, I think a good sign that you may want a delegate to be implemented instead of simply adding instance methods to your object is when you think that you may want the implementation of those methods to be easily swapped out or changed. When the implementation of those methods changes considerably based on where/how the functionality your building is being used
5) Absolutely! Objective-C and Swift are programming languages and the delegation pattern is an example of a design pattern. In general design patterns are hoziontal concepts that transcend across the verticals of programming languages.
6) I’m not sure I understand you exactly but I think there’s a bit of misunderstanding in the question - the method does not get called twice. The method declared in the delegate protocol is called once - typically from the class that contains the delegate property. The class calls the delegates implementation of that property via something like:
[self.delegate someMethodThatMyDelegateImplemented];
I hope some of this helped!
Sometimes you want your UIAlertView to work different in different contexts. If you set your custom UIAlertView to be delegate of itself it has to provide all those contexts (a lot of if/else statements). You can also set seperate delegate for each context.
This way you say to your compiler that every class (id) which implements protocol ClassesDelegate can be set to this property. As a side note it should usually be weak instead of strong to not introduce reference cycle (class A holds B, and B holds A)
Protocol (interface in other languages) is used to define set of methods which should be implemented by class. If class conforms to the protocol you can call this methods without knowledge of the specific class. Delegate is pattern in which class A delegates some work to class B (e.g. abstract printer delegates his work real printer)
When you need few different behaviours which depends on context (e.g. ContactsViewController needs to refresh his list when download is finished, but SingleContactViewController needs to reload image, labels etc.)
It is one of the most fundamental patterns in programming, so yes.
It's the same method
You can't just add a method to UIAlertView, because you don't have the source code. You'd have to subclass UIAlertView. But since you have more than one use of UIAlertView, You'd need several subclasses. That's very inconvenient.
Now let's say you use a library that subclasses UIAlertView, giving more functionality. That's trouble, because now you need to subclass this subclass instead of UIAlertView.
Now let's say that library uses different subclasses of UIAlertview, depending on whether you run on iOS 7 or 8, and UIAlertview unchanged on iOS 6. You're in trouble. Your subclassing pattern breaks down.
Instead, you create a delegate doing all the things specific to one UIAlertview. That delegate will work with the library just fine. Instead of subclassing a huge and complicated class, you write a very simple class. Most likely the code using the UIAlertview knows exactly what the delegate should be doing, so you can keep that code together.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm a student in a internship, and i'm learning Objective-C in order to develop an IOS application. They already had an existing base of code, but some part of the code give me problems.
As the previous developer isn't in the company anymore, and because no one else know about Objective-C, no one can answer some of my questions about how the application is built, so I can't determine if it is that i don't understand, or if it's just bad practices.
Here are these questions :
1°) In some classes, i found code like this :
- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated] }
This code is useless, right ?
2°) In like 9/10 methods in the project, they return (void). Is it a common pratice in Obj-C (because everything is a pointer) ?
3°) Sometimes there is the interface declaration in both header and messages files. I guess it's because you want to declare only a part in header for a future include, and to have a "private" part. But in a file, i find the following code :
In header :
#interface WebViewController : UIViewController
#properties ...
#end
In Msg file :
#import ...
#interface WebViewController ()
#end
#implementation WebViewController ...
What's the point declaring a void interface a second time in the msg file ?
4°) More, in another class, the interface is declared a second time too, but a method is defined (in the msg file). What's the point as the method is defined bellow, and is not declared in the header file ?
thank you in advance
Welcome to Objective-C :)
Not necessarily. The super class may have specific behaviour defined in it's own method implementation that would cause an issue if you didn't call it. Overriding methods means the super classes own method won't be called by default.
Added from comment: Of courser if you didn't override it then the superclass definition would get called just fine. There are 2 common reasons why you would find it overridden:
a. It's in the Xcode template so it has always been there and not been removed
b.it used to have other content but it was deleted and the method call left behind.
Yes. Although you don't explicitly return void in the method, you do need to specify some return type. If you're not returning anything then void is the right value. It's found commonly in obj-c classes as the method may respond to being called by mutating an internal ivar or property and not require a return. Alternatively the result might be to send a notification so a return value is not needed. Increasingly the use of block-based completion handlers replaces explicit value return as a way to respond to the contents of a method.
Yes, it's to give a private interface that you don't want exposed. In the case where there's nothing in the private interface it's probably there because it came with the template code from Xcode and no one removed it. You can ignore or remove.
For the one you mention with a method, while it's not required to declare private methods in an interface it makes sense from the point of view of writing readable code (a strongly endorsed concept in obj-c). Since the compiler will remove any unnecessary code it makes no difference to declare it and makes the task of reading the code and understanding the class that much easier when you or someone else returns to it later. It's a also a good place to put documentation in comments as it groups it all together.
Hope that helps. Check out the Objective-C programming guides from Apple to for more best practice tips.
1). Yes you can delete this method
2). It depends upon your requirement, whether you want a return type or not. e.g.
- (BOOL)isEmptyOrNull:(NSString*)str;
3). These are called extensions, you can read more about it here http://rypress.com/tutorials/objective-c/categories.html
Extensions are used to hide the methods from out side world(by saying hide I mean you can't find those methods with your eyes)
4). Methods define in implementation file are not visible to a programmer, it's just like private methods in java but in ObjC there is no such thing like private method. Read this thread for private methods Best way to define private methods for a class in Objective-C
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
From what I can understand setters and getters are used to set variable values from outside of the class scope. This seems useful as you may want to hide code using encapsulation.
However surely this method goes against encapsulation theory as you are injecting and manipulating values from outside of the class?
When are the correct times to use setters and getters in OOP? (any analogies would be great)
Are they defined in the main file or the interface file? As it seems like you would want to define a setter and getter in the .h file as you then set the variable's actual use in the .m file.
Lastly, why do you see getter methods simply returning the variable that they are getting? surely this is already done by the main file implementation.
Overall I just want a real clarification of getters and setters and why they are so useful.
Thankyou
If you have both - setter and getter - for one variable, it is true, that you can change it outside your class.
There is right question - why to do that?
Because of reusability and "agility" of your code.
1)Checking for right input
If you want to set age of person, you can check if the value is greater than zero in setter.
2) Reusability
Imagine that you create program which (among others) connect to server, receive array of bits and it creates integer from that array. Then you do something with that integer, you set this value from several places.
But server changes sending from little-endian to big. If you used setter and getter, you can change setter to transform it right before saving it. Or you can change your getter for giving right output.
Let's say there's no "wrong" time to use setters and getters because they give you additional control (memory management etc). As libik mentioned validation of values is really important to prevent your program from "falling" into an inconsistent state no matter if you set a self-calculated value or user input. And using setters often does not just mean storing a value in an ivar but might lead to other actions being necessary when setting a value. Hiding code is important as you don't want to make all actions behind the scenes obvious to public. And a setter also gives you the chance to return e.g. a boolean value representing if the value could be set properly or not.
A getter gives you the oppurtunity to lazily instantiate an object "on demand" if it hasn't been done yet instead of always creating objects supposing they could be needed later.
- (Object *) myObject {
if (!_myObject) {
_myObject = [[Object alloc] init];
}
return _myObject;
}
It's up to your needs whether you define your setters and getters in the interface of the .h or .m file. There might be a case in which you want your setter to be private (in .m file) and only make your getter public because the value is beeing changed inside your implementation depending on certain state changes or vice versa.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I know iOS Runtime is powerful and I have a question: where should we use runtime?
For example, I find many articles will discuss about class & method swizzling. And in which case should I use it?
I also google it and find it is widely used in jailbroken development. However, I'm a non-jailbroken developer, please don't cover jailbroken~
Thanks!
It's a very general question. The runtime is a library linked with your programs that implements part of Objective-C so it may show up anywhere. If you have to ask, don't use it. But FYI here are some common uses:
Swizzling
Swizzling is the exchange of the identifiers of two methods so they point to each other’s implementations. Both methods are still available.
It's useful to use swizzling instead categories to preserve the original implementation of the method, and to avoid having two categories overriding the same method (the result would be undefined).
See https://stackoverflow.com/a/8636521/412916 for a list of dangers.
Dynamic methods (sort of)
See https://stackoverflow.com/a/13646650/412916
Associative references
An associative reference is a way to add an instance variable to an object without changing its code. The associative reference is automatically removed when the object is deallocated.
Google it.
Introspection
Introspect the properties of the classes. For example to map between JSON and a plain class of your model. I guess Mantle and the Overcoat wrapper are examples of this.
You should read the Objective-C Runtime Programming Guide.
Using emoji as a method name
This is probably the most important use. The code is not mine and I don't remember the original author.
#include <objc/runtime.h>
#import <Foundation/Foundation.h>
#interface A: NSObject
#end
#implementation A
void pileOfPoo(id self, SEL _cmd) {
NSLog(#"💩");
}
+ (BOOL)resolveInstanceMethod: (SEL)name {
if ([NSStringFromSelector(name) isEqualToString: #"💩"]) {
class_addMethod([self class], name, (IMP)pileOfPoo, "v#:");
return YES;
} else return NO;
}
#end
int main(int argc, char *argv[]) {
#autoreleasepool {
A *a = [[A alloc] init];
SEL aSelector = NSSelectorFromString(#"💩");
[a performSelector: aSelector];
}
return 0;
}
Generally it shouldn't be used. When it is used it should be done with great care as the risk of breaking everything is high when you make a mistake. Usually it should only be done in well used code, preferably maintained as an open-source project so that many people check the validity.
It's not only used for jailbreak, but it does generally involve private classes / methods and allows you to workaround / expand limitations in the APIs. But it can also be used to expand by, for example, inserting your own class as an observer in some relationship so it can take some action and then forward the information to the 'true' observer (AFNetworking used to do this).
Generally you should use features like categories or standard subclasses to add functionality.
Method swizzling in runtime is a good measure to 'hook' methods whatever you want. Why do we need hooking? There are all kinds of application of hooking, such as user behavior statistic, automatic serialization and so on.
Here we take user behavior as a sample. With help of method swizzling, we can hook 'viewWillAppear' method in any UIViewController subclass. That means we can know when 'viewWillAppear' is called and thus we can inject user behavior codes(e.g. page visiting count, page visiting duration) before or after 'viewWillAppear' method. In summary, with help of method swizzling, we can easily make user behavior statistic realized. Other kinds of application are the same.