Re: UITableView's tableFooterView and autolayout
Hi Torsten,
On Jun 11, 2014, at 6:26 AM, Torsten Curdt tcu...@vafer.org wrote:
So what's the story with tableFooterView and tableHeaderView and
autolayout? I am trying to put a label into a footer.
I have had luck with code like the following:
- (void)viewDidLoad
{
[super viewDidLoad];
self.headerView = [[MyView alloc] initWithFrame:CGRectZero];
}
- (void)viewDidLayoutSubviews
{
[super viewDidLayoutSubviews];
CGRect frame = CGRectZero;
frame.size.width = self.tableView.bounds.size.width;
frame.size.height = [self.headerView
systemLayoutSizeFittingSize:UILayoutFittingCompressedSize].height;
if (self.tableView.tableHeaderView != self.headerView ||
!CGRectEqualToRect(frame, self.headerView.frame))
{
self.headerView.frame = frame;
[self.headerView layoutIfNeeded];
self.tableView.tableHeaderView = self.headerView;
}
}
- Sebastian
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: UITableView's tableFooterView and autolayout
On Jun 11, 2014, at 9:41 AM, Torsten Curdt tcu...@vafer.org wrote: Thanks but there you are setting the frame yourself. The idea was to use constraints. Usually you would pin them to the superview. But in this case... My solution uses Auto Layout constraints to get the appropriate size for the header view using systemLayoutSizeFittingSize. Given how UITableViews work when coupled with Auto Layout I believe you do have to set the frame yourself but you can determine what the frame should be using Auto Layout constraints. You can not use Auto Layout to *position* the header or footer view, but you can use Auto Layout to layout any views within that header or footer. If I understand your original situation, you probably want to use a UIView container for your label and then position that label within its container using Auto Layout. - Sebastian ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Unbalanced calls to begin/end appearance transitions for UIViewController
On Thu, Apr 24, 2014 at 6:22 AM, Torsten Curdt tcu...@vafer.org wrote:
Based on the Apple documentation I came up with the following method
to switch between controllers in a containment controller.
But when there is an oldC I am getting Unbalanced calls to begin/end
appearance transitions for ... on the console.
- (void) showController:(UIViewController*)newC
withView:(UIView*)contentView animated:(BOOL)animated
{
snip
[contentView addSubview:newC.view];
snip
}
Try it again without this addSubview call.
transitionFromViewController:toViewController:duration:options:animations:completion:
automatically adds the new view, performs the animation, and then removes
the old view. In your logic that does not call
transitionFromViewController:toViewController:duration:options:animations:completion:
you will have to do this yourself.
- Sebastian
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Why so many public properties all up in my grizzle?
On Thu, Mar 22, 2012 at 6:39 PM, G S stokest...@gmail.com wrote: On Mon, Mar 19, 2012 at 1:35 PM, Sebastian Celis li...@sebastiancelis.comwrote: 1) Embrace @properties...Exposing _ivars in header files is gross. You never want people to access them directly, so don't make those declarations public at all. 2) Technically, nothing is truly private in Objective-C, so let's stop trying to completely prevent people from using private APIs. contradiction++ I think you misunderstood. My point on (1) was that directly referencing ivars of other classes with the - operator is generally frowned upon in Objective-C. For one, you miss out on KVO that way. It is generally much more accepted to use real Objective-C methods and properties. Because of this, putting ivars in a *public* header file is strange and just clutters up what could otherwise be a clean, compact public interface declaration. My point on (2) was to just try and steer the conversation away from where it had been headed, which was an expansive discussion on how Objective-C handles public / protected / private methods and properties. Yes, private methods aren't really private. I can always use NSInvocation to call your private methods if I really want to. What I think is much more interesting is finding the best way to create compact, readable public header files that API consumers can reference while still finding good ways to use both traditionally private and protected methods in your class and subclasses. I just want to keep those out of the public header file — not to *prevent* you from using them, but just to communicate to you that you should try to avoid them. - Sebastian ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why so many public properties all up in my grizzle?
On Mon, Mar 19, 2012 at 2:27 PM, Brian Lambert wrote: Is there a way to declare ivars in the .M file AND have them accessible from Objective-C Category files for the class? I will tell you how we handle public, private, and protected ivars and properties. The route we decided to take was influenced by a number of overall design goals: 1) Embrace @properties. Properties are great. They make memory management easier, they work with ARC, and they force us to document our code and think about relationships between objects (weak vs strong, atomic vs nonatomic). Exposing _ivars in header files is gross. You never want people to access them directly, so don't make those declarations public at all. Exposing _ivars without properties in .m files is also gross, as it is not clear whether those relationships are supposed to be strong or weak. 2) Technically, nothing is truly private in Objective-C, so let's stop trying to completely prevent people from using private APIs. Let's just adopt a convention that is clear and lets people know that if they use private APIs they do so at their own risk. 3) Protected and private APIs (including ivars) should not autocomplete most of the time in Xcode, so they should not be in the public header file at all. We want the header file to be clear, concise, and very readable. Given those decisions, here is how we currently do things: * Public ivars are always declared as properties in the class header file. The _ivar should not be declared in the header file at all. Let the synthesizers declare them in the .m file. _ivars needlessly complicate the public header files for your classes, so keep them out. * Don't be afraid to mark many of your public properties as readonly. You can always override the property declaration as being readwrite in a class extension in the .m file. * Private ivars are declared as private @properties in the .m file. Again, let the synthesizers actually declare the _ivar. Don't declare the _ivars yourself, as it won't be immediately clear whether the references are supposed to be strong or weak. Use properties! * Protected methods and properties are tricky. We want subclasses to be able to access these directly, but we don't want API consumers to see them when autocompleting in Xcode or when looking at the public header file. So, we decided to do what Apple does with UIGestureRecognizerSubclass.h. We create a special header file that defines all of the protected properties and methods of a class using a category. Then, any subclass implementation files can import this file to easily access those protected APIs. Yes, nothing is stopping a bad developer from importing this header file and using protected APIs when they shouldn't, but they are hidden in a different file and appropriately documented so that developers don't accidentally use them. There are many ways to handle public, private, and protected APIs in Objective-C. We have found this to be a clean approach that works for us. - Sebastian ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Device/Resolution independent positioning of GUI items on iOS
On Mon, Mar 19, 2012 at 2:59 PM, Alex Zavatone wrote: In the current project that I'm tasked to repair from the previous two programmers, I've come across a load of UI elements that have been hardcoded in place with the approach of: Just define the CGRect and we're all good. Nothing is laid out in an xib file and sometimes the views are hardcoded or hardcoded relative to the rect/bounds of another view. As Brian mentioned, this is really ok. We do a ton of layout in code and we try to follow these conventions: * Layout your views as much as possible in viewDidLoad or viewDidLayoutSubviews (iOS-5-only). * When you layout your subviews, do so given the current size of your superview. Don't hardcode your view's width to be 320 just because you are doing iPhone development and you know your subview takes up the entire width of your screen. If you know that your view should be the entire width of the superview, set the width to be the current width of the superview. * Always set appropriate autoresizing masks. In the previous example, you would most certainly want to set the subview's autoresizing mask to UIViewAutoresizingFlexibleWidth. If you also want that view to stick to the top of the superview you would instead set it to (UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleBottomMargin). This is no different than what you would do in a XIB file, it is just in code, instead. - Sebastian ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: asynchronous nsurlconnection in nsoperation
On Wed, Mar 21, 2012 at 10:59 AM, Ariel Feinerman arielfap...@gmail.com wrote: I wish to insert an asynchronous NSURLConnection into non-concurrent NSOperation Hi Ariel, MBRequest does this. It is done by forcing the operation's runloop to continue running while the network connection is in progress. I would recommend looking though the source code. Specifically, take a look at MBURLConnectionOperation. https://github.com/mobiata/MBRequest https://github.com/mobiata/MBRequest/blob/master/Classes/MBURLConnectionOperation.m - Sebastian ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSFetchedResultsController with custom NSSortDescriptor
Hello, I am using an NSFetchedResultsCountroller to execute a query against a Core Data database backed by a sqlite data store. I would like to sort the results by an NSString property of my NSManagedObject. However, if the property is nil or an empty string, I would like those results to appear at the end of my UITableView instead of the beginning. (Think sorting in iTunes by artist. I want the songs with no artist to appear at the end instead of the beginning of my list.) The first thing I tried to do was to create a category on NSString and create a new comparison method which would sort exactly how I want. This did not work and gave me the following error message: *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'unsupported NSSortDescriptor selector: myComparisonMethod:' I believe this is because the sorting is done by the database and Core Data has a very explicit list of allowed selectors for NSSortDescriptors in my situation. The second solution I considered involved manually sorting the results in-memory. However, that would make me lose out on a lot of NSFetchedResultsController functionality as I would no longer be able to use it for UITableView sections or automatic updating of edited NSManagedObjects. That also seems inefficient as NSFetchedResultsCountroller doesn't necessarily bring all of the results into memory at the same time and only loads objects on an as-needed basis. The final solution I considered involved modifying the data stored in the database such that instead of storing nil or blank for this property, it would instead store something that would most likely sort to the end of the list (like @). This, however, seems like a big hack and would necessitate changing a lot of my code to account for this. That, and I do not like the idea of messing with the data in my database just to get this sorting problem to work. Finally, I thought about using two NSFetchedResultsController instead of one. One for all entities that have this property set, and one for all that do not. I'd prefer not to do this as it would overly complicate a lot of my code. If I could just get the data to come back sorted correctly, all of my existing code would just work. However, of all the ideas I've had so far, I think that this one is the best. Am I missing something here? Is there a better way to perform this kind of sort? Does anyone have any recommendations? Maybe there is a way to use two NSSortDescriptors? One that will first sort on the emptiness of the property and a second that will sort on the property itself? Many thanks, Sebastian ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSFetchedResultsController with custom NSSortDescriptor
Well, I sort dynamically on different properties so an explicit sortIndex wouldn't be ideal. But the lack of normalization just might work. I could create a boolean field which basically acts as 'hasProperty'. I can then hook into -willSave of the NSManagedObject to set that to YES or NO appropriately. This would give me an easy sort that the database should be able to handle just fine. Thanks, Sebastian On Wed, Aug 19, 2009 at 11:06 AM, Kyle Sluderkyle.slu...@gmail.com wrote: You're going to need to do an in-memory sort of these objects. Your suspicions about Core Data sorting are correct: when using the SQLite store, it sends the sorting off to the database backend, where it's far more efficient to do. Have you thought instead of sorting on a dependent property of your objects? Maybe create an integer property sortIndex that is updated when other properties are updated. This is where you need to shut up the part of your brain that complains about normalization. :) --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Programmatically Accessing Core Data Localization Strings
Hello, I have a strings file defined for my Core Data model. As such, my Data.xcdatamodel file has a corresponding DataModel.strings file. This seems to work great for auto-generated messages, but now I have a need to access these localized strings programmatically. NSLocalizedString does not seem to find them, and the localizationDictionary property of my NSManagedObjectModel is often nil (the documentation states that this is loaded lazily). How can I go about localizing the names of my properties and entities from code? I could theoretically duplicate all of my DataModel.strings strings into my applications main strings file. However that really doesn't seem ideal. Do I have a better option? Thank you, Sebastian ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Programmatically Accessing Core Data Localization Strings
Perfect! Thanks! - Sebastian On Mon, Jun 22, 2009 at 9:36 PM, Nick Zitzmannn...@chronosnet.com wrote: On Jun 22, 2009, at 7:56 PM, Sebastian Celis wrote: I have a strings file defined for my Core Data model. As such, my Data.xcdatamodel file has a corresponding DataModel.strings file. This seems to work great for auto-generated messages, but now I have a need to access these localized strings programmatically. NSLocalizedString does not seem to find them, and the localizationDictionary property of my NSManagedObjectModel is often nil (the documentation states that this is loaded lazily). How can I go about localizing the names of my properties and entities from code? Use NSLocalizedStringFromTable() with DataModel as the name of the table. Nick Zitzmann http://www.chronosnet.com/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Core Data, to-many relationships, and object graph consistency
Hello, I am having difficulty understanding how to work with a fairly simple Core Data model involving to-many relationships and their inverses. Imagine the following entities, attributes, and relationships: * Book - title (NSString* attribute) - author (NSString* attribute) - tags + to-many relationship to the BookTag entity + inverse is the 'book' relationship + delete rule is 'Cascade' * BookTag - book + to-one relationship to the Book entity + inverse is the 'tags' relationship + delete rule is 'Nullify' - tag + to-one relationship to the Tag entity + inverse is the 'bookTags' relationship + delete rule is 'Nullify' * Tag - name (NSString* attribute) - bookTags + to-many relationship to the BookTag entity + inverse is the 'tag' relationship + delete rule is 'Cascade' It is a simple tagging model. I want to be able to create tags and assign them to books. It makes sense to break BookTag and Tag into two separate entities so that I can easily query for all books that contain a certain tag, as well as all of the tags defined in the system. First question: do the details of this model make sense for the data? Some of the inverse relationships (like Tag.bookTags and BookTag.book) seem unnecessary, but from what I have read, 99% of the time you really want to model an inverse for every relationship. And are the delete rules correct? They all make sense to me but I wanted confirmation on the delete rules for the BookTag relationships. Does nullify make sense for both of them? Now that I have described the model, I would like to get to the heart of this e-mail. I am having difficulty understanding how consistency in the object graph is maintained for these entities and relationships. For example, the following code seems strange to me: SCBook *book = [NSEntityDescription insertNewObjectForEntityForName:@Book inManagedObjectContext:managedObjectContext]; [book setTitle:@1984]; [book setAuthor:@George Orwell]; SCTag *tag1 = [NSEntityDescription insertNewObjectForEntityForName:@Tag inManagedObjectContext:managedObjectContext]; [tag1 setName:@scifi]; SCBookTag *bookTag1 = [NSEntityDescription insertNewObjectForEntityForName:@BookTag inManagedObjectContext:managedObjectContext]; [bookTag1 setTag:tag1]; [bookTag1 setBook:book]; SCTag *tag2 = [NSEntityDescription insertNewObjectForEntityForName:@Tag inManagedObjectContext:managedObjectContext]; [tag2 setName:@dystopian]; SCBookTag *bookTag2 = [NSEntityDescription insertNewObjectForEntityForName:@BookTag inManagedObjectContext:managedObjectContext]; [bookTag2 setTag:tag2]; [bookTag2 setBook:book]; From what I understand, Core Data should automatically maintain consistency in my object graphs, correct? So then why does [[book tags] count] equal 1 at this point? Shouldn't both of these BookTag entities exist in the [book tags] set? Even if I re-fetch this particular book entity, the count of the tags set is still 1. However, saving this data and then relaunching the app or calling [managedObjectContext reset] appears to rectify this, allowing me to see both SCBookTag objects in the [book tags] set. On the other hand, if I remove the [bookTag1 setBook:book] and [bookTag2 setBook:book] lines and instead write: NSMutableSet *theTags = [book mutableSetValueForKey:@tags]; [theTags addObject:bookTag1]; [theTags addObject:bookTag2]; Now, [[book tags] count] equals two! What about this situation am I not understanding correctly? What is the correct way to do this? It seems as though forcing me to use mutableSetValueForKey is strange, especially because I would then have to do this for the Tag.bookTags relationship as well instead of simply calling [bookTag1 setTag:tag1]. In general, these particular entities and relationships are giving me a lot of grief. For example, I have test code that can add new Tag and BookTag objects to an existing book and save them to the persistent store. I also have test code that can successfully delete existing Tag and BookTag objects. However, when I run both pieces of test code at the same time (add a new BookTag and delete an existing BookTag) and try to save , I get an error stating that there is a dangling reference to an invalid object (a BookTag object). I have a feeling that my misunderstandings above and the manner in which I am creating my objects is causing inconsistencies in my object graph which are then manifesting in this particular situation. Does anyone have any advice that would clarify things and put me on the right track? Thank you, Sebastian ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at
Re: Core Data, to-many relationships, and object graph consistency
On Mon, Jun 15, 2009 at 2:56 AM, Quincey Morrisquinceymor...@earthlink.net wrote: What implementation of the 'tag' and 'book' properties are you using? (That is, how are setTag and setBook defined?) I am just using @property and @dynamic to define all of these. SCBook.h: @property (nonatomic, retain) NSSet *tags; // This is the Book-BookTag relationship. SCBook.m: @dynamic tags; SCBookTag.h: @property (nonatomic, retain) SCBook *book; @property (nonatomic, retain) SCTag *tag; SCBookTag.m: @dynamic book; @dynamic tag; SCTag.h: @property (nonatomic, retain) NSSet *bookTags; SCTag.m: @dynamic bookTags; (It's a bit confusing, btw, that you've called the Book-BookTag relationship 'tags' instead of 'bookTags'.) Sorry. I'd change how I talk about them now but I fear that would just lead to more confusion. You should double check that everything is correctly defined in your managed object model. Make sure, for example, that it shows that the inverse relationships are recognized as inverses. Also, check any validation conditions on your attributes. For example, if your Book-BookTags to-many relationship has a cardinality range of 0-1, you probably aren't going to get the results you expect. Yeah, I initially had the same thought and I have checked and double checked the data model. The inverses all look good, and all the validation conditions are very lax. The only one I have set is to ensure that a Tag must have at least one BookTag under the bookTags relationship. However, based on your description, it actually sounds more like you have a memory management problem. Are you using garbage collection? If not, are you sure you're retaining objects appropriately? I am not using garbage collection. Do I actually need to retain anything in the code example in my original message? From creating the SCBook to calling [[book tags] count] I am not retaining anything, but I was under the impression that I did not have to since this would all happen before the autorelease pool empties itself. I went ahead and tried retaining all of them in my example and [[book tags] count] is still 1. Whatever gives you an actual error message is your best attack point for solving your problem. Yeah, I spent hours tying to determine why I was getting a dangling reference to an invalid object error when deleting an existing BookTag and adding a new BookTag in the same commit. I kept trying to simplify the scenario and then started to notice that even the initial creates were not acting as I expected. I eventually decided that adding two BookTags was still causing me to scratch my head, and because that seemed like a really simple scenario, I thought I would start there. Do you have any suggestions for how I would approach the dangling reference error? It points to the BookTag object I deleted (both Book and Tag in that object point to nil). I definitely call [managedObjectContext deleteObject:bookTag] but I guess that somehow, somewhere in the object tree someone still has a reference to it. It was this that caused me to think that my model was incorrect in how the object tree is constructed. You can use the debugger to examine your object relationships. When you add the second object to the relationship (from either end), are the first object's relationships getting clobbered, or are the second objects relationships not being set up properly? The debugger is telling me that all of the relationships look fine except for the Book-BookTags relationship. The set of BookTags only contains the first BookTag object I created (scifi, in my example). The 'dystopian' tag, on the other hand, is not there. However, the relationships all look fine in the tag2 and bookTag2 objects. bookTag2 points at both the book and tag2, and tag2 points at bookTag2. It's all very strange. You can also try calling [moc processPendingChanges] before checking to see if the desired inverse relationships were set up. I don't recall ever having to use it in such circumstances, but I may be misremembering the sequence of events. Yeah, I did try calling that before [[book tags] count], but sadly it made no difference. Thank you very much for the time you have spent helping me thus far. This issue is really killing me. - Sebastian ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data, to-many relationships, and object graph consistency
I believe I found my issue. In my SCBook class I was overriding didChangeValueForKey:withSetMutation:usingObjects: so that I could store an NSString containing a comma-separated list of tags associated with the book. Apparently this is a very bad way to do it. I missed the big warning in the documentation which states that this method should not be overridden. What is the correct way to do this from inside of the SCBook class? Thanks, Sebastian ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data, to-many relationships, and object graph consistency
On Mon, Jun 15, 2009 at 12:58 PM, Quincey Morrisquinceymor...@earthlink.net wrote: If the comma-separated list is just for display in the user interface, you could generate it on the fly. Use 'keyPathsForValuesAffectingTagList' (or whatever) to ensure that the proper KVO notifications get sent when the underlying bookTag objects change. If you really want to store the comma-separated list, you can write your own set accessor overrides (addTagsObject, removeTagsObject, addTags, removeTags) and rebuild the string in the accessors. The only trick here (apart from following the documented pattern for writing the accessors) is to realize that the accessors are also called at undo time, so accessors with a side effect of updating a different property can be problematical unless you're careful. Thanks for all of your help. For now I think I will stop caching the comma-separated list. I was also caching a sorted array of the tags, but I think I can just compute those whenever they are requested, which should not be that often, anyway. If I run into a performance issue with this code later, I can look at it then. Just seems strange that I can't have my managed object observe itself for changes to a particular attribute / relationship. - Sebastian ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
