Im learning how to do drag and drop to allow ordering of items in an NSOutlineView. (Its my first time using NSPasteboard).
From the slightly related examples I found online, it seems you use:
[pasteboard setData: data forType: #"myapptype"];
What should be put into the NSData when you are doing a move. The samples put an archived version of the object as the data.
The object attributes could possibly change while the item is being dragged, so doest it make sense that instead I stuff a pointer to the object in there?
No, you generally don't want to stuff a pointer to an object onto the pasteboard.
The pasteboard has to have (basically) one of two types of things on it: data, or a promise to provide the data when asked for it. The pasteboard's lifetime is potentially (and likely) far longer than the lifetime of your application. So imagine this scenario:
User copies some data. You put a pointer to your object on the drag.
User quits your program. Your object is deallocated.
User starts up another instance of your program and hits paste.
Likely outcome: you crash when the second instance of your program dereferences an invalid pointer.
What data actually needs to go on the pasteboard can be very specific to your program, but you generally speaking don't want to put 'live' data on there. It's in your best interests to archive. You may find NSCoder useful for doing simple archiving.
I will carve an exception here and say one could conceive of doing pointer stuff if it was only ever done for drag and drop (since I don't think you can do the drag without the program still running) and if you cleared the drag pasteboard when you quit the program. But it's not a best practice, and I would say that if you're not very experienced and very aware of the pitfalls, it's a risky technique.
Related
I am tying to understand the example in the apple docs for deep copying an array of dictionaries Here.
In Listing 3 A true deep copy
The example shows
NSArray* trueDeepCopyArray = [NSKeyedUnarchiver unarchiveObjectWithData:[NSKeyedArchiver archivedDataWithRootObject:oldArray]];
Notice there is no copy, mutable copy , or autorelease operators, so I am struggling to understand how this is a copy and how it gets released. In fact, if I release my implementation, it will crash. It does however work as expected, and there does not appear to be any abandoned memory using it as the example shows.
I looked the the NSUnarchiver class reference and it mentions that the unarchiveObjectWithData method creates a temporary copy of the object(s)?
Does this mean the proper implementation then is to allocate and init the new array rather than just assigning the pointer so it can be released?
Thanks in advance.
They are doing a deep copy by doing a full archival pass on the object graph. Using NSArchiver enables things like automatic cyclic reference management and the objects can choose not to encode things like their delegate or they can hook stuff back up on unarchival.
For all intents and purposes, it is archival by saving something to disk and then reading it back in as a new document. Only, instead of the disk, it is just stored in memory all the time.
It is slow, very expensive, and totally inappropriate for anything but when you very occasionally need to duplicate a complex object graph completely.
unarchiveObjectWithData: returns an auto-released object. If you using MRC, you need to retain it if you want to keep it. But, a better solution would be to move to ARC.
You are crashing on retain (or shortly after) because you did not respect Apple's stated memory management rules, which can be found here: https://developer.apple.com/library/prerelease/ios/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html
Did you get the object from a method that contains alloc, new, copy or deepCopy in its name? No, then it is not your responsibility to release it.
Do you want to hold on to this object? If so, it is your responsibility to retain it.
As to why this code snippet results in a deep copy, you should read again what the archiver classes do. They don't deal with your objects, they deal with "descriptions of the contents of your objects". You might just as easily have done a "json import of the result of a json export" or an "xml import of an xml export".
I have a situation where I must generate a sequence of objects, and pass them back to an application one at a time (think block-based, or fast enumeration).
However, each object is going to be relatively expensive to generate, so I am looking for ways to avoid this cost.
It happens to be the case, that given one object of the sequence, the next one can be efficiently generated by a simple modification of the former. For this reason, it is tempting to "cheat" by only ever creating one object, and then keep passing that same object back to the application, and only carrying out the "cheap" modification "behind the scene" at each step in the sequence.
The problem is, of course, that the application may choose to (and it should be allowed to) store a reference to some, or all of the objects somewhere else. If it does that, the "illusion" of a true sequence of unique objects breaks down.
If Objective-C allows it, a neat way of solving this problem would be to detect when the application actually does store references elsewhere, and whenever that happens, replace the object by a copy of itself, before applying the modification that produce the next element in the sequence.
I don't know what the official name of this idiom is, but we could call it "copy on write if leaked", "copy on write if shared", or simply "copy on write".
My question is then: Does Objective-C, with ARC enabled, allow for such an idiom to be implemented?
And, is it even the right way to solve this kind of problem in Objective-C?
I did notice that with ARC enabled, there is no way I can extract the reference count from an object, nor override the methods that increment and decrement it.
EDIT: I have noticed that there is a copy attribute that can be applied to properties, but I have a hard time figuring it out. Are any of you guys able to explain how it works?
http://clang.llvm.org/docs/AutomaticReferenceCounting.html#property-declarations
I try to authenticate my app with Twitter with following code: pastebin
However, if I remove the (useless?) loop line 23ff
for (ACAccount *acc in arrayOfAccounts) {
[acc accountType].identifier;
//Otherwise the identifier get lost - god knows why -__-
}
the acc.type becomes (null) when it gets executed further in
AccountHandler checkAccountOf:acc. If I leave the loop in, the type is correctly set.
I am pretty sure it has to do with the fact that I am in a block and then move on to the main queue, but I am wondering if I am doing something wrong? This loop does not look like sth I am supposed to have to do.
Something kinda similar happened here.
ACAccounts are not thread safe. You should use them only on the thread that they originate. And for this purpose you can read 'thread' as 'queue'.
While I've not seen formal documentation of that, if you NSLog an account you'll see that it's a Core Data object and the lack of thread safety on Core Data objects is well documented.
The specific behaviour is that a Core Data object can be a fault. That means that what you're holding is a reference to the object but not the actual object. When you try to access a property the object will be loaded into memory.
What Core Data is doing underneath is caching things in memory and returning faults until it knows that an object is really needed. The efficient coordination of that cache is what limits individual instances of the Core Data object that coordinates objects to a single thread.
If you do the action that should bring the object into memory on the wrong thread — which is what happens when you access identifier here — then the behaviour is undefined. You could just get a nil result or you could crash your application.
(aside: the reason that Core Data works like this is that it stores an object graph, so possibly 1000s of interconnected objects, and you can traverse it just like any other group of objects. However you don't normally want to pay the costs associated with loading every single one of them into memory just to access whatever usually tiny subset of information you're going to use, so it needs a way of providing a normal Objective-C interface while lazily loading)
The code you've linked to skirts around that issue by ensuring that the objects are in the cache, and hence in memory, before queue hopping. So the 'fetch from store' step occurs on the correct queue. However the code is nevertheless entirely unsafe because objects may transition from being in memory back to being faults according to whatever logic Core Data cares to apply.
The author obviously thinks they've found some bug on Apple's part. They haven't, they've merely decided to assume something is thread safe when it isn't and have then found a way of relying on undefined behaviour that happened to work in their tests.
Moral of the story: keep the accounts themselves on a single thread. If you want to do some processing with the properties of an account then collect the relevant properties themselves as fundamental Foundation objects and post those off.
I have an array of NSDictionaries and a NSDictionary iVar (*selectedDictionary) that points to one of the array's objects. *selectedDictionary points to a different object every time the user selects a different row in a NSTableView. Several GUI controls are binded to the selectedDictionary instance (IB).
I just want to make the NSDocument dirty (edited) every time the user alters the above controls. I think using Key Value Observing for ALL the objects in the array and all their kaypaths, is a bit insufficient. Any suggestions?
Thanks
NSDocument's support for marking a document as dirty comes directly from the NSUndoManager. The easiest way to change the document to dirty is to do an implementation of Undo, and this is basically going to mean doing the undo inside of the model class that the document is using (or the subclass of NSDocument if you choose to handle all storage directly in there).
Apple has documentation on this here:
http://developer.apple.com/library/ios/#documentation/cocoa/Conceptual/UndoArchitecture/Articles/AppKitUndo.html
Since you indicate you have an array of dictionaries, that's going to make it a bit more work to implement, but once you have nailed that, you'll be in good shape.
Alternatively, if you don't want to go with the freebie support provided by NSDocument and NSUndoManager, you can manually handle undo and use the updateChangeCount: method to modify the internal understanding of whether changes have occurred. This takes some work, and likely is a lot less useful than just setting up undo correctly.
As for the efficiency of observing all the objects in the array, I wouldn't worry about it unless you have profiled it and found it to be inefficient. KVO is really pretty darned efficient and we regularly observe multiple values in every element of arrays without seeing performance problems. You have to observe the array itself in order to handle adds and removes (assuming your arrays have this).
As far as I can tell, though, you have a selectedDictionary which is used to determine the other controls that are shown. In this case, you can use KVO to observe the value of selectedDictionary and when it changes, you can remove the observers from the previous selectedDictionary and add them to the keys in the current selectedDictionary. This is basically what bindings is doing in order to handle the display and setting, anyway.
One other consideration that I've used in the past is referenced in this StackOverflow post:
NSMutableDictionary KVO. If you look at my answer here, I outline a trick for getting notifications when a new key is added or an existing key is deleted. It also has the benefit of giving you a notification when there's any change. It's not always a great solution, but it does save some effort on coding the list of keys to observe.
Beyond that, you'll have to add every key you're expecting to have an effect on the saved state of the document.
Let's suppose I create a few objects and I add them to an array.
House *myCrib = [House house];
House *johnHome = [House house];
House *lisaHome = [House house];
House *whiteHouse = [House house];
NSArray *houses = [NSArray arrayWithObjects: myCrib, johnHome, lisaHome, whiteHouse, nil];
Normally, all House objects have a retain count of two, but they're being autoreleased once. After a while, I decide to release myCrib, even if I'm not the owner — I never retained or initialized.
[myCrib release];
The retain count should drop to zero and my object should be deallocated. My question now is: will this illegal action cause my app to work erroneously or even crash, or will NSArray simply delete my object from its list with bad consequences.
I'm looking for a way to maintain a list of objects, but I want the list to maintain itself. When some object disappears, I want the reference to it to disappear from my array gracefully and automatically. I'm thinking of subclassing or wrapping NSArray.
Thank you.
My question now is: will this illegal
action cause my app to work
erroneously or even crash, or will
NSArray simply delete my object from
its list with bad consequences.
Your array now has an invalid object pointer. There's no way to tell that the pointer is invalid just by looking at it, and the array isn't notified that the object has been deallocated. The problem isn't with the array, after all, the problem is with the code that improperly releases the object. So yes, the application will likely crash or otherwise behave incorrectly due to that bad pointer, and no, NSArray won't detect and deal with the problem for you.
I'm looking for a way to maintain a
list of objects, but I want the list
to maintain itself. When some object
disappears, I want the reference to it
to disappear from my array gracefully
and automatically.
If the objects in the list are all instances of a common class, you could define your own memory management methods that both retain/release the object and add/remove it from the list, or broadcast appropriate notifications in case there can be multiple lists. I suppose you could even override -retain and -release for this purpose, but I'd think long and hard about that before doing it, and document it well if you do; it's not the sort of thing that other developers would expect.
Another option might be Core Data. If you delete a managed object from the object graph, it'll disappear from any relationships. Strictly speaking, a to-many relationship is a set, not a list, but the difference may not be a concern for your purposes.
Update: I just noticed that you didn't tag your question ios. If you're working under MacOS X, you should definitely take a look at NSPointerArray. If you use garbage collection, NSPointerArray can be configured to use weak references and to replace references to collected objects with null references. This is exactly what you seem to be looking for.
You should not release myCrib if you are not the owner. To do so is a violation of the memory management guidelines and will make your code extremely difficult to maintain. I cannot stress enough that you absolutely should never do this under any sort of circumstance. You're asking for crashes; the array has declared ownership of the object, and you must not subvert that ownership in any way.
So the answer here is: your code is absolutely wrong and you should fix it. If you can't fix it, you should trash it and start over and keep rewriting it until you've come up with another way to achieve the same effect without subverting object ownership. I guarantee that it's possible.
If what you want is a weak-referencing array, then there are a couple ways you can do this (this was just asked a couple of days ago):
NSPointerArray - weakly references its pointers. When you use garbage collection, they're autozeroing (ie, the pointers get removed when the object is deallocated). Unfortunately, this is not available on iOS.
CFMutableArrayRef - you can specify a custom retain and release callback, or just not specify one at all. If you leave them out, the array will simply not retain the objects it contains. However, this does not automatically remove the pointer when the object is deallocated.
DDAutozeroingArray - an NSMutableArray subclass I wrote the other day to provide a weakly-referencing and auto-zeroing array that works on both Mac OS and iOS. However, I strongly encourage you to use this only as a last resort; There are probably much better ways of doing what you're looking for. https://github.com/davedelong/Demos
I'm looking for a way to maintain a
list of objects, but I want the list
to maintain itself. When some object
disappears, I want the reference to it
to disappear from my array gracefully
and automatically. I'm thinking of
subclassing or wrapping NSArray.
If I have understood right, what you want is an array of weak references. Then, you might be interested in reading this post.
You're asking for a crash here. Your NSArray will still have a reference to the object that now no longer exists -- and who knows what it will be pointing to after a while?
Subclassing NSArray might not be the answer either. It's a class cluster which, in short, means that it's harder to subclass than you might hope.
Not entirely sure how you'd implement this. Something like the element sending a notification when they're about to be deallocated which the array would then pick up. You'd need to be careful that you didn't leak or over-release your objects.
I created a wrapper class — in my code it's called a controller — which maintains the (mutable) array for me. I initialize the controller class in my view controllers — the place where I need them — instead of using an array directly.
No invalid code for me. :-p