This question already has an answer here:
In Apple's Documentation for NSObject, what is the idea of the "receiver"?
(1 answer)
Closed 6 years ago.
I've been able to make sense of and use the API Reference fairly consistently so far, but the one thing that really irks me is that every time I run into this term, I basically have to ignore the definition in which it's used and figure out how the method/property in question works by applying it in code.
So can anyone clarify this matter for me?
When the iOS API Reference mentions a "receiver" (and it does this a lot), what is that term referring to?
Example of such a method description:
https://developer.apple.com/reference/uikit/uiview/1622442-convert
Converts a point from the receiver’s coordinate system to that of the specified view.
The receiver is the object on which a method is being invoked. For example, in this code:
let myView = UIView()
myView.convert(point, to: otherView)
The receiver of the convert(_:to:) method is myView.
This terminology comes from SmallTalk and Objective-C, where methods are called "messages" that you "send" to objects, and your objects "receive" them.
Related
This question already has answers here:
Xcode NSManagedObject subclass contains optionals when they are marked as non-optional
(4 answers)
Closed 4 years ago.
I set about an attribute it is NOT optional, but still when read value of it, it returns an optional variable, why?
What you set in your model may not directly correspond to what you have in your code. Consider that the model will work for multiple platforms (iOS, OSX) and for multiple languages (Swift, Objective-C).
Your classes are then autogenerated where in your case it seems you are using Swift. But they are subclasses of managed objects which are NSObject subclasses so on bottom you are on objectiveC. If I remember correctly all of these properties will be force-unwrapped which still means they are wrapped ergo optional when printed.
ObjectiveC has a bit different system of constructors and at some point each of the values/properties in an object will be null. Due to how CoreData works it might make sense to keep force-unwrapped values.
So a long story short: These two may not be as tightly connected as you believe. But you should not worry about that, if this breaks any of your functionality/code you should ask the question directly.
I have done a bunch of coding in swift and prefer to do a lot programmatically and I was wondering what the difference was between these two:
self.view.addSubview(someNewView)
view.addSubview(someNewView)
they both seem to work. Is one better for some reason? Are they actually that different?
If this is a dumb question or already answered it can be removed. Just a thought.
There's no real difference, although you may see the use of self more often from previously Objective-C developers. From the docs:
In practice, you don’t need to write self in your code very often. If
you don’t explicitly write self, Swift assumes that you are referring
to a property or method of the current instance whenever you use a
known property or method name within a method.
...
The main exception to this rule occurs when a parameter name for an instance method has the same name as a property of that instance. In this situation, the parameter name takes precedence, and it becomes necessary to refer to the property in a more qualified way.
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Methods.html
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
This question already has answers here:
Use of alloc init instead of new
(8 answers)
Closed 9 years ago.
Recently i was told Apple is discouraging the use of new, and google's iOS coding standards also has this to say:
Do not invoke the NSObject class method new, nor override it in a subclass. Instead, use alloc and init methods to instantiate retained objects.
Modern Objective-C code explicitly calls alloc and an init method to create and retain an object. As the new class method is rarely used, it makes reviewing code for correct memory management more difficult.
Why would it make reviewing code for correct memory management more difficult though?
I expect the reference to ease of code reviews merely meant that human readers of your code may not notice the word 'new' as their eyes scan over the code looking for alloc-init calls.
In Objective-C, the word 'new' is a shortcut for calling alloc and init. But then you cannot pass arguments; you are calling the no-arg constructor. If you later change your code in such a way that you now want to call one of the other constructors and pass arguments, you will need to change your "new" to an alloc-init. This is common enough that it is yet anothe reason to avoid calling 'new' in the first place.
There is no advantage to calling 'new' over calling alloc-init. The 'new' word is only in Objective-C because other languages such as Java use that keyword.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Objective-C - When to use 'self'
I needed a variable to be passed from one view to another so I made a property called StringC in the .h and accessed it using self.StringC (that part worked).
I also need some arrays that are accessible throughout the view but I'm using them differently.
For instance I have lvLabelArray and I'm using
self.lvLabelArray=[[NSMutableArray alloc]init];
and then later I'm using
[lvLabelArray addObject:LabelText];
Is there a difference between that and
[self.lvLabelArray addObject:LabelText];
?
Sorry I don't know the terms for those kinds of variables.
There is an important difference there.
self.attribute goes through the object's getter or setter function, as appropriate. That allows you to set up initial values, trigger update messages, or anything else.
Accessing "attribute" directly goes straight to the underlying variable, so you bypass all that. As a result, it's definitely the less-preferable way of working.
A common way of avoiding this confusion, and just plain mistakes, is to rename the underlying variable. Instead of just "#synthesize attribute", use "#synthesize attribute = _attribute". This will create the getter and setter methods as before, but they'll the underlying variable is named "_attribute". That means that trying to use "attribute" without "self" will trigger a compiler error.