Re: Core Data or not
> Little different perspective, Core Data tends to work drop dead easy for > simple stuff. Small data set with simple functionality should work straight > out of the box easy. > > And there is nothing wrong with creating a manual array of managed objects > from a Core Data result set. Currently I have an NSTableView tied to an NSArrayController. I manually populate the array controller as needed with items from my master array. With Core Data it seems the NSArrayController would be tied to the Managed Context and while I could apply a predicate to filter the array controller, manually populating it would be slow. For example, I would need to add items with ID# 204, 765, 983, 124, and 458 to the array. This seems like with Core Data it would be 5 different fetches. Or is there some efficient way to fetch these 5 items in one request? ___ 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: Core Data or not
> On 6 Aug 2016, at 12:46 AM, Trygve Inda wrote: > > I am considering moving an app[…] > Everything > works. So my question is: what is your motivation? Is it underperforming? Is it just idle curiosity, restlessness, too much time on your hands, or some other state of mind? While I have some sympathy for any of these “reasons”, they’re not usually a good reason for rewriting valuable code that works. For those cases, creating a new project that allows you to explore them hamlessly is likely a better idea. IIABDFI. —Graham ___ 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: Core Data or not
Little different perspective, Core Data tends to work drop dead easy for simple stuff. Small data set with simple functionality should work straight out of the box easy. And there is nothing wrong with creating a manual array of managed objects from a Core Data result set. I personally wouldn't stray from Core Data until you hit pain points, performance problems or functionality limitations. Core Data is like autolayout in that, it generally works very well for simple things (which it sounds like you're after). Just my $0.02, Luther On Fri, Aug 5, 2016 at 3:57 PM Quincey Morris < quinceymor...@rivergatesoftware.com> wrote: > On Aug 5, 2016, at 07:46 , Trygve Inda wrote: > > > > Somehow this seems easier to do without Core Data. > > If you’ll accept my opinion as commentary and not anything more dire, I’d > say that your proposed course of action is based on several clearly > undesirable options: > > 1. For 5,000 records, I don’t think there’s enough data to justify using > Core Data at all, given the amount of development pain you can expect. Core > Data is famous for pain. Your project may be the exception, where > everything goes smoothly and Core Data brings a smile to your face, but I > wouldn’t bet on it. > > 2. For 5,000 records, you do need a storage solution. If non-local storage > is possible, then I’d suggest you look very seriously at CloudKit. It’s > what Apple did *instead* of making Core Data usable for mere mortals. You > may still need some kind of local persistence, but if only a few hundred > records are needed locally, keeping them (or enough of their properties to > populate your table view) in RAM may be enough. > > 3. If you must have local persistent storage, then I’d suggest one of the > 3rd party databases. I recommend these behind CloudKit only because over > time 3rd party libraries tend to embroil you in update compatibility woes, > whereas sticking with Apple software means you know where you stand with > updates and backward compatibility. > > 4. NSXxxController is a glue object, which exists only to let you avoid > writing code that’s largely boilerplate. IMO it’s a terrible mistake to it > them as an app *design* element. These classes are pure implementation. > > 5. The NSXxxController functions of sorting and filtering have their > counterparts in Core Data and also in any decent persistent storage system > that has database-like semantics. No need to think about NSXxxController. > > 6. Depending on what is involved with your “interestingness” property (the > one that defines the subset of 200 or so records), you may be able derive > it in the NSTableView data source (by logically combining two groups of > records), or by providing a derived property, or by using Core > Data/database fetch predicates, or by storing something in the database > itself. What you do depends on the complexity of the property, but none of > the options need NSXxxController. > > ___ > > 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/lutherbaker%40gmail.com > > This email sent to lutherba...@gmail.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data or not
On Aug 5, 2016, at 07:46 , Trygve Inda wrote: > > Somehow this seems easier to do without Core Data. If you’ll accept my opinion as commentary and not anything more dire, I’d say that your proposed course of action is based on several clearly undesirable options: 1. For 5,000 records, I don’t think there’s enough data to justify using Core Data at all, given the amount of development pain you can expect. Core Data is famous for pain. Your project may be the exception, where everything goes smoothly and Core Data brings a smile to your face, but I wouldn’t bet on it. 2. For 5,000 records, you do need a storage solution. If non-local storage is possible, then I’d suggest you look very seriously at CloudKit. It’s what Apple did *instead* of making Core Data usable for mere mortals. You may still need some kind of local persistence, but if only a few hundred records are needed locally, keeping them (or enough of their properties to populate your table view) in RAM may be enough. 3. If you must have local persistent storage, then I’d suggest one of the 3rd party databases. I recommend these behind CloudKit only because over time 3rd party libraries tend to embroil you in update compatibility woes, whereas sticking with Apple software means you know where you stand with updates and backward compatibility. 4. NSXxxController is a glue object, which exists only to let you avoid writing code that’s largely boilerplate. IMO it’s a terrible mistake to it them as an app *design* element. These classes are pure implementation. 5. The NSXxxController functions of sorting and filtering have their counterparts in Core Data and also in any decent persistent storage system that has database-like semantics. No need to think about NSXxxController. 6. Depending on what is involved with your “interestingness” property (the one that defines the subset of 200 or so records), you may be able derive it in the NSTableView data source (by logically combining two groups of records), or by providing a derived property, or by using Core Data/database fetch predicates, or by storing something in the database itself. What you do depends on the complexity of the property, but none of the options need NSXxxController. ___ 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: Need some NSComboBox debugging help
On Aug 5, 2016, at 07:03 , Keary Suska wrote: > > One would think that it either has to do with the assignment of the delegate > or the assignment of the outlets/properties of the delegate, or both. I would add one other thing to this “smells like” list: duplicate controls. If you somehow ended up with a pair of identical controls superimposed in each (or even some) of the 8 locations, but only one of each pair has a delegate or outlet connection, you’d expect inconsistent behavior along the lines you describe. Sometimes everything might seem to work fine, depending on how the first responder status jumped between controls. ___ 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
How to perform CoreData deletion in the background?
I have an app running only on iPad right now that uses CoreData. From time to time, I receive updated data from the server which forces me to clean up my local database. I would like to be able to delete small chunks of data in the background but I don't find any appropriate key for UIBackgroundModes. Anybody ever had to do something similar? What did you use? The app is for enterprise distribution so I don't have to worry about the app being rejected for using the wrong key for UIBackgroundModes but I'd like the system to give time to my app as much as possible. Any idea or suggestion gladly accepted! -Laurent. -- Laurent Daudelin laur...@nemesys-soft.com AIM/iChat/Skype:*LaurentDaudelin* http://www.nemesys-soft.com/ Logiciels Nemesys Software ___ 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
Core Data or not
I am considering moving an app to Core Data. Currently it manages an array of InterestingObjects. I use NSArrayControllers and TableViews. Everything works. I have two cases: 1. I have one array of all InterestingObjects and I set different predicates on the array controller to show only those matching the predicate in a table. (Think of this as an iTunes smart folder) 2. I manually insert some of the InterestingObjects into an array controller to be shown in a table. (Think of this as an iTunes user-defined folder - just dragging in random songs) #1 seems easy to migrate to Core Data as the table will be bound to my managed object context and I can use predicates to show different subsets. How can I effectively do #2? Each InterestingObject has an identifier that is a UUID so I could make a predicate that just lists all the InterestingObjects I am colleting. Will that be effective with perhaps hundreds of objects? Without Core Data it is easy to just go through the array and pick out a hundred, add them to a different array and display them. Basically I have a core data store of 5,000 InterestingObjects. I have a list of 200 UUIDs (remember, each InterestingObject has a UUID) and I need to list these 200 InterestingObjects in a table. In some cases I need to combine them, so how is the best way with Core Data to show a table of: - all the InterestingObjects where name= "Joe" - plus all the InterestingObjects with these 200 UUIDs I hope this is clear. Somehow this seems easier to do without Core Data. Thanks. ___ 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: Need some NSComboBox debugging help
> On Aug 4, 2016, at 11:34 PM, livinginlosange...@mac.com wrote: > > I have 8 NSComboBoxes in my application organzied into 4 pairs, each pair > sharing an NSComboBox delegate. I have had some users periodically say that > the combo-boxes get confused. ComboBox A will wrongly display ComboBox B’s > data. I have scoured my code for an places where I might perform an > assignment as opposed to performing an equality comparison. I have a hard > recreating this event. More often than not, I experience my combo boxes not > working. I’ll restart and everything will be fine. Not be able to repeat the > issue is the biggest problem. > > My next step to solve this issue will be to catch the popupwillopen > notifications so I can re-set the delegate. > > Does anyone have any ideas on how to solve this issue? There is not much anyone can help without seeing code. One would think that it either has to do with the assignment of the delegate or the assignment of the outlets/properties of the delegate, or both. Could be a memory issue, which makes more sense for crashes, but is one way objects can trade places. I would log every delegate assignment and outlet/property assignment, as well as every time each object in question is created and destroyed to see if the object addresses stay consistent or change when there is some event (like the crashes you experience). I would also make sure to set the delegate to nil when you expect the delegate to be destroyed, and outlets/properties of combo boxes to nil when they are expected to be destroyed. HTH, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" ___ 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