As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have seen different conventions for Objective-C (Cocoa/Cocoa Touch) of placing the curly braces.
The two that I have seen are:
- (void)dealloc {
[super dealloc];
}
vs.
- (void) dealloc
{
[super dealloc];
}
This confuses me because I would expect that for such a rather small community there should be only one convention.
Which one of the two is more common?
I don't think there's any canonical answer to this (whether speaking in terms of objective-c or any other language). Personally I prefer:
- (void)dealloc {
[super dealloc];
}
...but there are certainly a lot of people who prefer the alternate style, as well. As for which is more common, example code provided by Apple appears to prefer the first style (brace on the same line), so that would be a safe bet as the more common pattern. I do recall stumbling across an older Apple coding conventions document which recommended the second style (brace on the next line), however (but it also recommended using two spaces instead of 4 for indents, which makes that document garbage in my opinion). You might as well just pick your preference.
The only thing that I would recommend is that you should never mix both styles in a single source file. Pick one and stick with it. And if you're editing a third-party source file that uses one convention, follow that same convention instead of using the alternate format. Then at least your coding style will always be consistent per compilation-unit.
This is a pure style question and there is only one convention : choose the one you prefer.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am used to functional programming. Now writing for iOS I find myself using class methods (+) frequently, rather than creating instances (from -).
Usually I use class methods for small, recurring tasks - like sending async requests, updating database, storing/retrieving preferences etc.
Is this the right thing to do, or should I try to change my thinking more and start using instances instead? Is it even possible to avoid using class methods all together?
My best recommendation would be to look at how Foundation and Cocoa is doing and do it similarly. There is a place for class methods in Objective-C.
Some examples of class methods include
[UIView animateWithDuration:0.3 animations:^{
// Animation here...
}];
and
[NSURLConnection sendAsynchronousRequest:request
queue:[NSOperationQueue mainQueue]
completionHandler:^(NSURLResponse *response, NSData *date, NSError *error) {
// Handle response here ...
}];
There is a third alternative supported by Objective C for encapsulating functionality that does not need implicit access to instance variables - it is using "plain" C functions. Unlike class functions, "plain" C functions do not use virtual dispatch, which may be important in vary tight loops.
Note that class methods provide more functionality than, say, static methods of Java, C++, and C#: they support overriding, letting class method in base classes use more specific implementations in derived classes.
Class methods are used when you do not need any instance of the class, and your purpose gets served only by a method call of that like [[NSUserDefaults standardUserDefaults] synchronize];
In MRC
The alloc/init combination gives you an owning reference. That means you must release it later on. The classMethod returns a non-owning reference. You may not release it.
i.e.,
Person *firstPerson=[Person personWithName:#"AnoopVaidya" address:#"India"];
In ARC, for the above there is not such differnce.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am a complete newbie when it comes to programming, I've focus most of my youth on design, CSS/HTML and finally decided that I should take the leap to programming.
I've been reading Stephen Kochan's book "Programming in Objective C", I'm about 4 chapters in and wanted some clarification on the concepts of Object Oriented Programming. More or less the concepts of Objects, Classes, and methods using game development as an example.
So if we use Super Mario Bros as an example, disregarding the fact that the game was most likely not developed using Objective C.
From my understanding...
So if "piranha plant" was the class...
Would a chomping piranha plant and fire spitting piranha plant both be objects of that class (piranha plant)?
Would you then apply methods to those objects like:
Chomping Piranha Plant (object):
Raising up/down from pipe
Bites
Fireball Piranha Plant (object):
Raising up/down from pipe
Shoots Fireballs
...?
Am I completely misunderstanding this concept?
Thanks for the help!
Chomping and Fire-spitting piranha plants are specializations or refinements of the basic piranha plant; they would most likely be subclasses. A subclass can do everything the superclass can do, but has some special tricks of its own.
Since both these types move themselves up and down in their pipes, that would be a method on the base piranha plant class; this is behavior that all pirahna plants share. Whatever weird thing they do once they pop up might also be a method on the parent class, which would be overridden by each child class, something like this:
#interface PiranhaPlant : NSObject
// Declare properties, other methods...
- (void) ascendFromPipe: (NSRect)pipeFrame;
- (void) doThingThatIDoOnceFullyExtended;
#end
#implementation
//...
- (void) ascendFromPipe: (NSRect)pipeFrame
{
// ...drawing/animation stuff
[self doThingThatIDoOnceFullyExtended];
[self descendIntoPipe];
}
- (void) doThingThatIDoOnceFullyExtended
{
return;
}
//...
#end
#interface FireSpittingPiranhaPlant : PiranhaPlant
#end
#implementation FireSpittingPiranhaPlant
- (void) doThingThatIDoOnceFullyExtended
{
[self spitFireball];
}
#end
And likewise for other subclasses.
You would then instantiate individual piranha plants, of whichever class, to populate individual pipes. They would each behave according to their class's definition -- one chomps, one spits fire, one jumps entirely out of the pipe and chases Mario around.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The performance overhead of calling methods/properties in Objective-C is killing the performance of my iOS app; the Xcode profiler (aka, Instruments) attributes 70% of the latency to objc_msgSend, _retain, and _release.
In my code, so far, I make about 1100 calls to my XROpenGL class's instance method renderSprite(XRSprite) which is an overloaded method of renderSprite(XRSprite,int,int,int) which in turn invokes no less than five other methods, many of which access properties from XRSprite. As you can imagine, there's ALOT of messages being sent around.
Do I have any options apart from rewriting the critical sections of the code in C++?
Is that 6,600 calls per frame? I'll assume so for the sake of discussion, at 60 FPS for a total call count of 396,000 just for your explicit method calls. If you assume the pessimistic case, objc_msgSend's overhead (versus a C function call) is still only O(100) cycles. So on a modern iDevice you're looking at ~4% of your CPU time, very roughly. Not a huge deal. You might get a retain or two and corresponding releases for each call, but retain/release are relatively fast so we'd again be talking single-digit percentages. "Runtime overhead" of this nature of up to ~10% isn't considered egregious, generally, though it's not optimal.
So, the questions I have for you are:
Can you post your code?
Can you post more detailed profile information (e.g the exact breakdown between the various top 10 methods, as well as perhaps callstacks for the major ones)?
Are you sure the time is actually spent in objc_msgSend et al, and not merely in its children?
How many calls are you really making? As in measured, not assumed.
Can you use ivars instead of #properties, to remove some of the method calls?
Along those lines, are you caching the properties you do access when using them multiple times in one method?
Can you refactor to reduce the number of method calls, and/or use vanilla C functions for some things?
Obviously yes, you can rewrite key code in C++. But for mid-level drawing code you shouldn't have to; C++ is usually left to low-level constructs like vectors and quaternions and other such primitives.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I find myself often writing complex GCD / block based methods (comparable to the code snippet shown below).
How would you break up this kind of method in smaller
portions?
Would you rather GCD-enable the parsing methods in the managed
objects' code or would you rather keep the GCD code in the view
controller?
How can I run the NSURL request in the code below in the background
queue ([NSURLConnection sendAsynchronousRequest:request
queue:[NSOperationQueue mainQueue] When I use NSOperationQueue
currentQueue, the completion handler does not get called.
Use a C function or a instance method to delegate certain processes (such as saving to the XML file).
Definitely keep it in the object's code. You are breaking MVC too much as it is,
Don't use NSURLRequest, use AFNetworking or RestKit instead.
I would separate that so you can actually see the MVC design in it. So I would have:
The UIViewController
A Manager Class to handle the interactions between the UIViewController, the NSURLConnection and the XML Parser
A class to handle the NSURLConnection (or any 3rd party you would like).
A class to handle the XML Parsing and posterior writing.
To establish communication I would use delegation. This way you would have different blocks of work. So when you need to change the XML Parse, just switch the class; if you need to use this logic somewhere else, just switch the UIViewController. Keep it simple and clean.
P.S: Sometimes, no matter what you do, the code just is, by it's nature, complex, please use comments, you will thank yourself later...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
In #mmalc's response to this question he states that "In general you should not use accessor methods in dealloc (or init)." Why does mmalc say this?
The only really reasons I can think of are performance and avoiding unknown side-effects of #dynamic setters.
Discussion?
It's basically a guideline to minimize the potential for bugs.
In this case there is the (possibility) that your setter/getter may inadvertently make direct or indirect assumptions about the state of the object. These assumptions could be a problem when the object is in the midst of being setup or destroyed.
For example in the code below the observer does not know that 'Example' is being destroyed and could assume that other properties, which have already been freed, are valid.
(You could argue that your object should remove all observers before tearing itself down, which would be good practice, and another guideline to prevent inadvertent problems).
#implementation Example
-(void) setFoo:(Foo*)foo
{
_foo = foo;
[_observer onPropertyChange:self object:foo];
}
-(void) dealloc
{
...
self.foo = nil;
}
#end
It is all about using idiomatically consistent code. If you pattern all of your code appropriately there are sets of rules that guarantee that using an accessor in init/dealloc is safe.
The big issue is that (as mmalc said) the code the sets up the properties default state should not go through an accessor because it leads to all sorts of nasty issues. The catch is that there is no reason init has to setup the default state of a property. For a number of reasons I have been moving to accessors that self initialize, like the simple example below:
- (NSMutableDictionary *) myMutableDict {
if (!myMutableDict) {
myMutableDict = [[NSMutableDictionary alloc] init];
}
return myMutableDict;
}
This style of property initialization allows one to defer a lot of init code that may not actually be necessary. In the above case init is not responsible for initing the properties state, and it is completely safe (even necessary) for one to use the accessors in the init method.
Admittedly this does impose additional restrictions on your code, for instance, subclasses with custom accessors for a property in the superclass must call the superclasses accessor, but those restrictions are not out of line with various other restrictions common in Cocoa.
You answered your own question:
Performance may be a perfectly adequate reason in itself (especially if your accessors are atomic).
You should avoid any side-effects that accessors may have.
The latter is particularly an issue if your class may be subclassed.
It's not clear, though, why this is addressed specifically at Objective-C 2 accessors? The same principles apply whether you use declared properties or write accessors yourself.
It may be that the setter has logic that should run or perhaps the implementation used an ivar with name different from the getter/setter or perhaps two ivars that need to be released and/or have their value set to nil. The only sure way is to call the setter. It is the setter's responsibility to be written in such a way that undesirable side effects do not occur when called during init or dealloc.
From "Cocoa Design Patterns", Buck, Yacktman, pp 115: "... there is no practical alternative to using accessors when you use synthesized instance variables with the modern Objective-C runtime or ..."
In fact, for a class that comes and goes rather often (like a detail view controller), you want to use the accessor in the init; otherwise, you could end up releasing a value in viewDidUnload that you try to access later (they show that in CS193P...)
You can create the same problems by NOT calling the setter when allocating/deallocating.
I don't think you can achieve anything by using retain/release directly in init/dealloc. You just change the set of possible bugs.
Everytime you have to think about the order of property allocation/deallocation.