Re: Core Data or not

[Trygve Inda]

> 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

[Graham Cox]

> 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

[Luther Baker]

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

[Quincey Morris]

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

[Quincey Morris]

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?

[Laurent Daudelin]

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

[Trygve Inda]

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

[Keary Suska]

> 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