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...
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 an average iOS developer. The first design pattern that I saw heavily being used was Delegation pattern which was mostly being used for callback functionality.
Now that blocks are there in Objective C and I am seeing more and more libraries heavily using them and avoiding delegates, I am wondering, are blocks permanent replacement for delegate pattern using protocols ?
I recently used MKNetworkKit in a project, I created a wrapper class on top of it, the library is block based so all my code that would encapsulate a call to one of there block based code turned ot to be another block based code.
I found that it was very convenient initially, but was difficult to debug and modify as the code looked complex (callback inside callback inside callback!)
Any tips on when to use what and certain best practices ?
Delegates and blocks are both used for something to "call back" the result, usually to the thing that created it. There are some differences:
Using a delegate protocol, the method names you must implement to receive the callback are fixed. That means, if you need to receive callbacks from multiple possible actions using the same delegate protocol, you must somehow distinguish them. With blocks, there are no fixed names; you simply pass a block object with a particular signature. You can pass different block objects to different actions.
Delegate protocols often (but not always) contain more than one callback method, e.g. a "success" and a "failure" callback. Each block can only serve as one callback. Many libraries try to "combine" multiple delegate callbacks into a single block callback, by using multiple arguments, e.g. the block has two arguments (result, error), where if "error" is nil it corresponds to the original "success" callback, with "result" being the data; and if "error" is not nil, it corresponds to the original "failure" callback. Another option would be to give multiple blocks separately to the action (e.g. it has a "success block" property, and "failure block" property, which you can set). This is more general, and will work as a one-to-one replacement of a delegate protocol with any number of methods.
Memory management: Delegates are usually weakly-referenced, since the delegate is usually a "parent" object that owns the delegator. However, blocks are strongly referenced, since blocks are one-use things that are not needed anymore once passed to the delegator. However, if you think about it, it is not really different. With delegates, typically the delegate method will perform some action on itself (the parent object). With blocks, in order to do this, the block would need a reference to the "parent". It is then this reference that needs to be a weak reference, to emulate the memory management of the delegate pattern. With blocks, the parent object code has more control over how the delegate will reference it, because it sets up the block.
In conclusion, it is possible to systematically convert any API using a delegate protocol into one that uses blocks, with what I described above -- for each delegate method, add one block property on the delegator.
Protocols and the designated delegate objects they talk to are quite different than block-based code, which is usually used to encapsulating a task and/or shipping it off to GCD.
I do see one place in the Apple's Block documentation that appears to match some of the functionality that delegates provide:
Blocks are particularly useful as a callback because the block carries
both the code to be executed on callback and the data needed during
that execution.
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 read Apple's recommendation on exception usage and NSError usage:
Also, I read several similar stack overflow questions which discuss whether to use or not exception.
Exception Handeling in iOS
Using exceptions in Objective-C
Objective-C Exceptions
I am trying to figure out pros and cons of usage exception as error notification/handling method in iOS (Frankly, I am no satisfied with Apple's sentence (it says what to do, but it doesn't say why we should do it):
You should reserve the use of exceptions for programming or
unexpected runtime errors such as out-of-bounds collection access,
attempts to mutate immutable objects, sending an invalid message, and
losing the connection to the window server. You usually take care of
these sorts of errors with exceptions when an application is being
created rather than at runtime.
Exception usage pros:
It doesn't require to modify all intermediate code between error generating code and error handling code
It doesn't pollute arguments and return values for methods
Cons:
For all manually managed memory code we will have to be extra careful (we will need to wrap it in autoreleasing objects to make sure that resources are released).
We need to be careful with the border between our code and framework. If our exceptions leave our code, we could be in trouble (because frameworks may manually manage memory)
Did I miss anything? Are there additional cons/pros?
It looks like exceptions should be fine for library like code (when we have quite big amount of tightly packaged code, which doesn't communicate a lot with external systems/frameworks. And it looks like exception are hard to use for the code which actively interacts with other frameworks.
Does your experience prove this theory?
I appreciate any additional info on this subject.
tl;dr Exceptions should be used for fatal/non-recoverable/programmer error(s) only. Attempting to use them a la Java or other exceptions-are-recoverable environments will result in code that is more fragile, harder to maintain, and difficult to refactor while also limiting your ability to leverage system frameworks.
Con: If you use exceptions for flow control and/or recoverable errors in your code, your code will be, by design, different from Apple's design patterns.
End result?
• You can't use Apple's APIs at all in your code unless the border between your code and Apple's always isolates the exception behavior
• Every time your refactor, you'll have to refactor a mass of exception handling code
• Many things that should be trivial will be very complex; for example, you won't be able to put your objects into an enumerable collection and enumerate them without that enumeration -- block, for loop, whatever... -- also having exception processing at the boundaries.
Consider:
NSArray *a = #[yourExceptionfulInstance, yourExceptionfulInstance, yourExceptionfulInstance];
#try {
for(id k in a) { [k doSomething]; }
} #catch(...) {
}
If doSomething might raise, for any reason, the above is violation of the documented design patterns of the framework because you'll be throwing an exception across frames within Apple's framework(s).
That is one mighty big con. Big enough that I can't imagine a set of pros to outweigh it.
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.