For some odd reason NSOrderedSet does not appear to be implemented in iOS. Is there another object that gives similar functionality -- basically the ability to insert/remove objects randomly and access the first/last in sort order?
It seems to me that something like this would be needed in order to implement basic FIFO queues and the like.
Edit: I ended up doing an RYO solution.
One option is this open source data structures library:
http://dysart.cs.byu.edu/CHDataStructures/index.html
In that library is a CHOrderedSet
http://dysart.cs.byu.edu/CHDataStructures/interface_c_h_ordered_set.html
It's only dependency is NSMutableSet so it should work across all your iOS versions.
EDIT:
As Bourne pointed out above, it's also in iOS5 (reference):
The new NSOrderedSet collection class offers the semantics of sets,
whereby each element occurs at most once in the collection, but where
elements are in a specific order.
CHOrderedSet is a good option if you don't have a hard dependency on iOS5.
NSOrderedSet and NSMutableOrderedSet are not available in iOS 5. Here's the reference for anyone curious:
http://developer.apple.com/library/ios/#documentation/Foundation/Reference/NSMutableOrderedSet_Class/Reference/Reference.html#//apple_ref/occ/cl/NSMutableOrderedSet
Related
The doco explains what the NSArray sort methods are, but is anyone able to give a bullet point say on when/why you'd use a particular method? i.e. under what circumstances in you code would you use method XXX over method YYY. For:
sortedArrayUsingComparator
sortedArrayUsingDescriptors
sortedArrayUsingFunction:context
sortedArrayUsingSelector
See Collection Programming Topics: Sorting Arrays for more general information. If you're looking at the class reference documentation, be sure to check out the "Companion guides" that are listed for more practical, real-world advice on how the classes work.
Basically, sortedArrayUsingSelector: and sortedArrayUsingFunction:context: have been around since 10.0/iOS 2.0. They're not as flexible as the other methods which came later.
If you have an array of relatively simple objects, like NSNumbers or NSStrings, you could use [numbers sortedArrayUsingSelector:#selector(compare:)] to easily sort the objects.
If, on the other hand, you have a more complex model object that has multiple properties, such as age, name, date, NSSortDescriptors work well. Those were added in OS X 10.3/iOS 2.0. The allow you to do something like first sort by age, then by name, and then by date.
c
I'm building some sorft of treeview on iOS. It should basically contain simple items/objects and their positions. I thought I could use NSMutableDictionary where NSIntexPaths would be keys. Is that sound idea? Would it make me worth while when navigating through tree?
I wouldn't recommend it as your tree would never be sorted. Reconstructing the tree or iterating along the branches would be very slow.
iOS doesn't have NSTreeNode, but you can use that as a model and try to reimplement that on your own (it's not too hard).
When I work with UITableViewControllers - especially when using NSFetchedResultsController - I find myself repeating a lot of base functionality on every controller. Which I hate. I'd much rather love to write these methods once and keep it all neat and tidy.
So I was wondering: What do you guys do to not repeat yourself writing UIViewControllers. How do you DRY up your code. Inheritance, protocols, whatever.
Thanks! Looking forward to your answers.
(Since this question doesn't have a definitive answer, I will accept the one I find the best.
Is that the way to do it?)
You can write your own controllers with the basic functionality and then subclass and reuse them. Check the CoreDataTableViewController class that was built for the Stanford iPhone Application Development course -> http://www.stanford.edu/class/cs193p/cgi-bin/drupal/node/167
One technique is to subclass your own subclass. This, modularizes and isolates the differences nicely, however it generates a lot of classes and files, which some find harder to read.
Another technique, which you can use when you want to create a bunch of almost identical controllers with just slight differences, is to give one class a "type" parameter or instance variable. Set the controller's type when you init a controller, and use the controller's type in "if" or switch statements (etc.) to select between slight differences in controller behaviors at run-time. This can help keep all the differences more compactly located in source code.
I made this new Core Data wrapper for iOS in Swift - https://github.com/tadija/AERecord
It has Swift version of CoreDataTableViewController, and CoreDataCollectionViewController also.
Beside that you can use it to setup Core Data stack like this:
AERecord.setupCoreDataStack()
Access context for current thread like this:
AERecord.defaultContext
Save context like this:
AERecord.saveContext()
Create fetch requests like this:
NSManagedObject.create()
NSManagedObject.firstOrCreateWithAttribute("city", value: "Belgrade")
NSManagedObject.deleteAll()
let predicate = ...
NSManagedObject.firstWithPredicate(predicate)
NSManagedObject.allWithAttribute("year", value: 1984)
And much more... I hope it will be useful for someone.
I'm getting up to speed with the new APIs introduced in OS 3.0, especially the cool new improvements to Core Animation (mostly on CALayer etc...). Now I'm trying to figure out how to use CAGradientLayer. It looks simple at first, but the NSArray it requires for the colors property must contain CGColorRef (according to the header file). I've tried casting to (id), but then the NSArray seems to contain NSCFType objects, which doesn't sound good.
Anybody figured how to use it or could point to some good code samples?
Thanks
Even though the NSCFType objects in the array "don't sound good", you are supposed to use CGColorRefs directly in the array. The same principle applies here as for the animation question I asked a while back. The examples I've seen for using this class all employ arrays of CGColorRefs.
I am wrapping up an application where I am using a lot of Dictionary classes to store Function and Action delegates. I am now refactoring my project a bit and cleaning code. My question is where do or would you put your Dictionary classes in your project structure? Right now, they are located within the calling class source files but I was wondering if I should create a separate source file to store all my Dictionaries. I hope this is enough information. Please forgive me if it is not. Thanks.
I would organize the dictionaries in the same way as the rest of the code; group related functionality together, and separate unrelated functionality.
In addition, I'd look at how the delegation dictionaries are used. If your usage pattern is always to retrieve a delegate and immediately invoke it, then I'd wrap that behavior into a class with a "do-the-right-thing" method. Then each such class can be named by the domain concept it represents.
For example, if you had a dictionary which mapped US state abbreviations to a sales tax calculation, then you could wrap all of that into a class with a "compute sales tax" method taking a state code and subtotal as arguments. The fact that it's using a dictionary to look up the right computation scheme then becomes a hidden implementation detail.
Normally, the Dictionary class would be a thing unto itself (a library) and your various users would create instances of it.
If need be, they might specialize / sub-class it, but this should be rare.
Maybe the question you really should be asking yourself "why do I have multiple Dictionary classes"?