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
Today, I got a link to a long list of coding guidelines, proclaiming to be "code commandments". A good read, and full of new insights to me. Among the list, somewhere along 25% of the scrollbar, I come across something new to me: Implicit data member creation.
Although every tutorial, book and video I've read or watched about Objective-C always performs the triad of NSNumber *number | #property NSNumber *number | #synthesize number, these commandments now tell me I can simply omit the first step (data member declaration in the interface) because #synthesize will create one on the fly. Say what!?
With a little disbelief I deleted several of my data member declarations, and indeed, my app still works like a charm. Less typing, less reading, less chance for typos.
Sounds to me like a win-win-win, but is it really good practice?
I'm asking this question out of pure disbelief that all the tutorials, books and videos are teaching the wrong lesson, at least too much of it, or that I've been not paying attention in class...
Cheers,
EP.
Edit: Although I copied the expression "data member" from the linked post, it is more commonly described with the word "ivar", just a good one to have in here for search friendliness. This also takes care of my former confusion over property/ivar/member naming :).
Synthesized instance variables are a feature of the modern Objective-C 2.0 runtime. This means they're available on x86_64, on ARM, and as of Xcode 3.2, on the iPhone Simulator. It means exactly what you suggested - you can omit the ivar declaration, and the #synthesize line will generate the ivar for you. The performance of this is exactly the same as declaring the ivar explicitly, but it has the very important benefit of not polluting your header file with private implementation details.
I have begun the practice of removing synthesized properties from the Objective-C classes I create. The primary reason for this is because there is a distinct difference between:
self.myNSObject = [NSObject new];
and
myNSObject = [NSObject new];
Specifically, if myNSObject is declared as a #property(retain, ...) the former line will result in a retainCount of 2 while the latter will result in a retainCount of 1. This means that unless you are extremely careful about every assignment to myNSObject you run the risk of getting your retain/release balancing wrong.
The other reasons you specify are also very valid. There is a lot going on in the synthesized routines that my brain doesn't account for when I'm reading the code I've written, so a lot is taking place behind the scenes that I'm not thinking of yet am accountable for. It's for very a similar reason I've abandoned Apple's Interface Builder.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Ive searched around and can't find any answers that aren't related to C++, which isn't the exact same thing. I have a game and I keep an NSMutableArray of my sprites for certain categories because there are too many of them and they appear/dissapear too often to keep references to every single one of them, and also the number of them varies. so they are stored in an array.
In my didBeginContact method I grab the contact.bodyA.node object and pass it into a mehtod I've written called getSprite which enumerates over the array of objects I have, finds the one that matches and returns that one as an SKSpriteNode so I can use SKSpriteNode-specific methods such as animateWithFrames and such. However, I use this method pretty frequently and I'm wondering if doing something like:
SKSpriteNode *sprite = (SKSpriteNode*)[contact.bodyB.node parent];
Is acceptable as well, and then just using that pointer to refer to my object. It works, but I don't know if it will cause memory leaks or other problems. Any suggestions? (the reason I used the parent method is because the sprite I'm actually after is the parent of the one involved in the collision).
I assume you're using ARC. The local pointer to the object is a strong pointer by default, since you didn't specify anything differently. So that object is guaranteed to not be destroyed during the scope in which your local sprite pointer exists. It will not maintain a strong reference beyond that scope. The NSMutableArray also maintains a strong reference to to the objects it contains, so while they are in that array, the objects will not be destroyed.
As far as memory leaks go, this shouldn't cause any problems. It should also be more performant since it's a direct link back up to the sprite, rather than iterating and searching for the correct sprite. I don't see any reason why you couldn't do that, besides the fact that is might affect future plans for your game since the parent relationship of the object becomes part of the logic when is probably shouldn't be, but if you centralize that code so it's easy to change if you ever change the hierarchy of your sprites it should be fine.
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 have read a lot of topics about the atomic and nonatomic attributes in Objective-C, and I understand that atomic means thread safe and therefore nonatomic is faster. But the main problem is that I don't understand what are threads at all and how they are being expressed in the code. Are they kind of methods? And I also noticed that most of the properties are nonatomic, why is that? I saw that threads may access setter or getter of a property simultaneously, how is this possible and how is this being expressed in the runtime? Also as a newbie programmer should I prefer atomic or nonatomic?
I have searched in a lot of questions regarding this but none has actually answered my question.
As Martin points out, people generally don't rely upon the atomic qualifier because that does not (generally) ensure thread-safety. The critical observation is that one must properly synchronize changes to variables as discussed in the Synchronization section of that Threading Programming Guide that Martin pointed you to.
So, in answer to your question, you probably should generally employ nonatomic (it's a little faster than atomic), but then determine which of the various synchronization techniques (serial queue, NSLock, NSRecursiveLock, #synchronized, etc.) as part of your broader thread-safe system design. In some cases, atomic might be part of that solution (as the Synchronization - Atomic Operations section of the Threading Programming Guide points out that atomic operations are "a simple form of synchronization that work on simple data types"), but as you're often dealing with objects, not simple data types, then atomic is likely to be insufficient.
As an aside, if you're diving into multi-threaded code for the first time, I might also suggest that you check out the Concurrency Programming Guide which talks about a slightly easier way to write multithreaded code without needing to get into the weeds of NSThread. You can either use dispatch queues (Grand Central Dispatch) and operation queues (NSOperationQueue).
Some additional references:
WWDC 2012 video Building Concurrent User Interfaces on iOS shows a practical example of operation queues;
WWDC 2012 video Asynchronous Design Patterns with Blocks, GCD, and XPC gives a bit of background on common asynchronous design patterns using Grand Central Dispatch (and XPC).
There are lots of other WWDC videos on the topic, but those might be two good ones to start with.
what are threads at all and how they are being expressed in the code.
Seriously, this is a big topic. So here are some thought and a specific answer to last question.
Actually, not all programs need concurrency, so I'd say if you haven't found a requirement for it in your application, you're free to relax. Then it won't matter if your properties are atomic or not.
Also as a newbie programmer should I prefer atomic or nonatomic?
As a newbie programmer, I'd say leave them as default. If they are fully synthesized, compiler will honestly synthesize an atomic getter and setter for you. There's nothing wrong with that, and certainly you shouldn't "try to make them faster" until you profiled the application and found that to be an issue.
If you provide methods for your properties yourself, your properties will actually be nonatomic, but I'm not sure marking them as such is worth the effort. Try to do that in code that is likely to be re-used by other people.
In some cases the compiler forces you to declare that the properties are nonatomic (when you pair a custom setter with synthesized getter or vice-versa). Well, in those cases go ahead and do that.
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
When one uses ARC, this means we can forget about memory management related tasks right? e.g., like deletion/release of the memory we allocated etc.
Two places I know we may need to interfere is retain cycles, and one should use __weak before Outlet ivars in class definitions (if these outlets are not top objects in object hierarchy of the XIB).
Is there something else I have to consider?
Things have changed.
You should still stick to some pattern related to memory managment / ARC. You won't retain, release, autorelease and dealloc any more.
New:
You would still overwrite a dealloc method and nil all strong references. That is not really required but can be done. But you would not call [super dealloc] any more.
You will declare properties as strong or weak depending on whether you take ownership or not.
If you want to get rid of an object in a way that the memory is freed up, then you have to nil all strong references to that very object. Each strong reference corresponds to one retain. But you cannot call retain on those objects.
You cannot call undeclared methods any more (Without ARC this will generate a compiler warning, with ARC it is an error.)
You get warnings when using variable selectos (That is using variables of SEL type and perform those on objects) and you should never do that with methods that might have an implact on the retain count (such as alloc).
And you still have plenty of chances of making errors when you interface with areas of the framework that do not ARC, such as core functions.
So it is far away from "forget about" but applying the ARC patterns is less work and less error prone than the former MRC patterns.
When using ARC you dont have to use dealloc/autorelease. so, YES you can forget deletion release etc.
The only thing to consider is strong reference cycles, like the one you mentioned here.
Another example is when you use delegate objects.
You can also refer apple's documentation
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
#property #synthesize
I'm a little confused on the 2 methods, could someone please explain them to me?
What do they do, and why are they better than just using -(void)variable; and -(void)variable{}?
It's just a more convenient way to define standard getter/setter methods for your variables, because writing all over and over again simple standard getter and setter methods can be a real pain in the ... And properties provide an easy way to memory management (e.g. strong, nonatomic and so forth).
What do they do
They declare and implement property accessor methods (the getter and setter), respectively. #property declares, #synthesize tells the compiler to issue an autogenerated implementation for the declared methods.
why are they better than just using -(void)variable; and -(void)variable{}?
Because they're shorter, so more concise and make code more readable. Also, they have no errors in themselves - if you were to write a bunch of accessor methods, I'm sure you'd eventually miss something and you couldn't for the love of God tell where a mysterious segmentation fault came from. This doesn't happen with declared properties (so they are called).
One minor caveat is that old Objective-C compilers don't support declared properties. It might be the case (although there's very little chance for it) that one day you'll need to compile your code with an old compiler and it would be impossible because of this syntax. But again, this is very unlikely to happen.
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 8 years ago.
Improve this question
I'm new with Objective C and am not an uber programmer anyway but one thing I find odd is that it won't throw errors sometimes when objects are declared not initialized.
I just ran into this again - I had some setup stuff to be done in so I put it in an init function - but the class is a UIViewController that is wired up in the storyboard. So init was never called - and that's my error - (lots of NSObject derived classes in the project and I rushing and just tossed that in to test some things).
But my methods that were making calls to the instance that was supposed to have been set up in int didn't throw errors - it just that the values I was expecting were nil.
Isn't that sort of odd that that sort of stuff would fail silently?
You've got two separate issues here, both quite common for beginners.
Your init was never called because it's the wrong method entirely. It's not the designated initializer for a view controller, and in any case a view controller from a nib or storyboard gets initWithCoder:. So it's up to you to have a sense of what method will be called and when.
Messages to nil return nil with no error. This is a deeply entrenched feature of Objective-C and isn't going to change. There is often quasi-religious debate about it, and there are some clever ways around it, but that's neither here nor there really. Basically it's up to you to use lots of NSLog and lots of nil-checking (NSAssert is a great thing to use for this), especially during early stages.
Not odd at all. That's how Objective-C has always worked. Messages to nil simply do nothing.
It is strange, but that's how Obj-C was designed. Actually, from Obj-C perspective, the code did not fail (silently). Everything was correct.
In Obj-C you can alwyas send messages to ("call methods on") nil.
init is just another message ("method"), not a constructor. It's not needed to create and use an object. You can understand Obj-C only as a thin layer over C language. C language won't report if you haven't called a function on a struct, either.