I am writing a small program for a data structures class that basically stores member objects. One of the things the user needs to be able to do is delete and add new users. That being said, I use an arraylist to hold my objects and then I clone it so that I can have two arraylists sorted in different ways. Changing object fields in one list DOES change them in the other but when I delete an object from one arraylist, it still stays in the other. What would be the best method to completely delete that member object from all arraylists?
A good way would be to write a helper method that would remove the element from each of the array lists, and use that method for the removal.
Related
I've created a model that has mainly a nested array of custom objects for use in a split-view (both UITableViews) "to-do" list type app. The left (master) is the lists of lists and the right (detail) is the lists :) Some other variables are kept in some of the classes like isSelected, isExpanded...
All of these classes implement NSCopying protocol. When I make a copy of a master list item and change the copy's name that works, but if I change anything in the detail list item belonging to that master list item, it changes in both the copy and the original. So I guess my question is how do I create a deep copy of a master list item. I thought by making them all implement NSCopying protocol it would automatically do this. I I really don't know what to put for code with so anything you need just ask.
Take a look at NSKeyedArchiver - you can archive your array of arrays, unarchive it, and you have a deep copied clone.
(Of course this only works if all your objects support archiving.)
how do I create a deep copy of a master list item
By implementing the deep copy logic in your own code. Deep copies are typically -- sometimes, but generally not -- more than just doing a copy of every object in the collection and everything it is connected to. Outside of property lists, anyway, which do support deep copies, but are limited to very simple, non-cyclic object graphs.
So, you would iterate the collection and copy each item in the collection, as needed. While implementing copyWithZone: may seem reasonable, a deep copy is often done by manually instantiating new instances and setting the various attributes based on the original as needed, copying where required.
-(MyClass)deepCopy {
MyClass* theCopy = [self mutableCopy];
for (MyElementType* element in self.dataContainer) {
MyElementType* theCopiedElement = [element deepCopy];
[theCopy somehowInsertThisElementInTheRightPlace:theCopiedElement]l
}
return theCopy;
}
Obviously, there's a bit of magic involved in that 5th line -- exactly how you do it depends on how the subsidiary data items are attached to your object. But there are really only 3-4 basic scenarios. Recursion naturally handles everything else.
(And note that you can be "smart" and not copy immutable objects, etc.)
(Also note that you can create "categories" for NSMutableArray and NSMutableDictionary.)
Using Visualworks (Cincom Smalltalk), and a List widget, how does one use a SortedCollection along with SelectionInList? For instance, how do I initialize a SelectionInList with a SortedCollection?
I'm confused about the process, and I can't find any good documentation about how to proceed.
just like that:
aSelectionInList list: aSortedCollection.
the selection in list is an object that manages a selection and a list, it doesn't actually care too much about what kind of collection you pass as a list, as long as it is sequencable (i.e. responds to #at:)
You really want to use List all the time in SelectionInList objects. The reason is that List manages its dependencies itself in an instance variable. Other kinds of collections manage their dependencies using a system-wide Dependencies collection. This means that if your window shuts down unexpectedly you could be left with garbage in the Dependencies collection that still holds onto your entire Window structure and prevents it from being garbage collected. I've seen images grow to huge sizes because of this.
If you use a List, you can always sort it in place by using the sort or sort: methods. If you ever need to add elements to the list, you can just add them at the end and re-sort.
I 'm learning about Objective - C by developing a contacts app. I'm not using Core data or the Address book API, as this is just for learning. So each contact is an object which is stored in a master NSArray. Users can create groups of contacts where each group stores the appropriate contact objects in an NSArray. The problem I'm facing is when a contact is deleted from the master array , I have to manually remove it from all the groups as NSArray retains its objects. Is there a better way around this?
As you are learning, i suggest:
Simple:
Have your application only contacts list, adding/editing/deleting a contact from a single master list. You can also save & retrieve list from plist in documents directory.
You will be learning: plist, tableView, navigation, viewControllers, maintaining data from & within array.
Realtime:
You can use a sqlite database, with 4-5 tables. Each having Contacts, Groups, Address, Website and many other if you like to have. All the tables with interlinked with a reference of row id's. Which definitely help you learn many things, apart from the above mentioned.
Dont copy objects into multiple arrays. Add the same object to multiple arrays using the same pointer to the original object. Maintain pointers to the arrays and remove the same object from all the arrays at once. If you want to implement isEqual make it use == pointer equality.
Copying the same object for the purposes of storing in collections only creates headaches for yourself. Immutability is a nice feature, but actual identity across the system is a better one especially in a pointer based language.
I just ran into a major issue for me with NHibernate. I have 2 objects, each with a collection of things. I need to move one thing from the collection from Object A to the collection of Object B. I get an error about a deleted object because, I believe, NHibernate attempts to delete the thing from the collection of Object A when it needs to keep it for Object B.
From a DB standpoint, it's just a matter of updating the "parent" property to the new object (Object B). But with the collections, I am not really sure what do to...
Is there a well-known procedure to move objects from one collection into another one in NHibernate?
Thanks in advance for any help.
Regards,
Eric.
I'm assuming that you are using Cascade in the mapping for the class represented by objects A and B, i.e., A and B are both instances of some class X, and X's mapping contains a cascade attribute on the collection containing the object to be transferred.
Given that assumption, this may help.
If you want to be able to transfer the object from one collection to the other, you need to consider whether the thing that is being moved should have an existence that is independent of the two collections.
If the transfer object doesn't get saved on its own, you will run into problems when you do the transfer because the transfered object is already known to the session.
There are two ways out that I can think of. The better of the two is probably to treat the transfer object as an independent object which is saved on its own to the db (i.e, doesn't rely on Cascading in the mapping of the objects with the collection). Conceptually, this makes sense because if you can transfer it from one collection to the other that implies that somehow it is independent of the two objects having the collections. It does mean that you could end up with orphans.
If you want to stick with using cascade in the mappings, then you will need to remove from object A in a different transaction than the add to object B. I suspect that isn't what you want to do.
Have you tried mapping using
cascade="all-delete-orphan"
I have a "parent" Obj-C object containing (in a collection) a bunch of objects whose instance variables point to one another, possibly circularly (fear not, no retaining going on between these "siblings"). I write the parent object to XML, which of course involves (among other things) writing out its "children", in no particular order, and due to the possible circularity, I replace these references between the children with unique IDs that each child has.
The problem is reading this XML back in... as I create one "child", I come across an ID, but there's no guarantee the object it refers to has been created yet. Since the references are possibly circular, there isn't even an order in which to read them that solves this problem.
What do I do? My current solution is to replace (in the actual instance variables) the references with strings containing the unique IDs. This is nasty, though, because to use these instance variables, instead of something like [oneObject aSibling] I now have to do something like [theParent childWithID:[oneObject aSiblingID]]. I suppose I could create an aSibling method to simplify things, but it feels like there's a cleaner way than all this. Is there?
This sounds an awful lot like you are re-inventing NSCoding as it handles circular references, etc... Now, there might be a good reason to re-invent that wheel. Only you can answer that question.
In any case, sounds like you want a two pass unarchival process.
Pass 1: Grab all the objects out of the backing store and reconstitute. As each object comes out, shove it in a dictionary or map with the UID as the key. Whenever an object contains a UID, register the object as needing to be fixed up; add it to a set or array that you keep around during unarchival.
Pass 2: Walk the set or array of objects that need to be fixed up and fix 'em up, replacing the UIDs with objects from the map you built in pass #1.
I hit a bit of parse error on that last paragraph. Assuming your classes are sensibly declared, they ought to be able to repair themselves on the fly.
(All things considered, this is exactly the kind of data structure that is much easier to implement in a GC'd environment. If you are targeting Mac OS X, not the iPhone, turning on GC is going to make your life easier, most likely)
Java's serialization process does much the same thing. Every object it writes out, it puts in a 'previously seen objects' table. When it comes to writing out a subsequent reference, if it's seen the object before, then it writes out a code which indicates that it's a previously seen object from the list. When the reverse occurs, whenever it sees such a reference, it replaces it on the fly with the instance before.
That approach means that you don't have to use this map for all instances, but rather the substitution happens only for objects you've seen a second time. However, you still need to be able to uniquely reference the first instance you've got written, whether by some pointer to a part in the data structure or not is dependent on what you're writing.