On 2 Dec 2012, at 01:00, Dave Fernandes wrote:
>
> On 2012-12-01, at 5:05 PM, Mike Abdullah wrote:
>
>> On 1 Dec 2012, at 20:21, Dave Fernandes wrote:
>>
NSPersistentDocument always creates a MOC of type
NSMainQueueConcurrencyType, even if it is created on a background thread.
>>>
On 2012-12-01, at 5:05 PM, Mike Abdullah wrote:
> On 1 Dec 2012, at 20:21, Dave Fernandes wrote:
>
>>> NSPersistentDocument always creates a MOC of type
>>> NSMainQueueConcurrencyType, even if it is created on a background thread.
>>> So as long as things don't go wrong during document openin
On 2012-12-01, at 5:12 PM, Mike Abdullah wrote:
> - is comprised of a single Core Data store
> - has a single managed object context
This definitely limits your options. But, is it necessary to support file
wrappers and iCloud? (Just trying to educate myself about how do
On 1 Dec 2012, at 20:12, Dave Fernandes wrote:
>
> On 2012-12-01, at 11:42 AM, Mike Abdullah wrote:
>> One way to look at it is that NSPersistentDocument pretty much painted
>> itself into a corner from day 1, and it's too messy for Apple to
>> untangle that.
>
> Can you
On 1 Dec 2012, at 20:21, Dave Fernandes wrote:
>> NSPersistentDocument always creates a MOC of type
>> NSMainQueueConcurrencyType, even if it is created on a background thread. So
>> as long as things don't go wrong during document opening, everything will be
>> the same as a document opened o
> NSPersistentDocument always creates a MOC of type NSMainQueueConcurrencyType,
> even if it is created on a background thread. So as long as things don't go
> wrong during document opening, everything will be the same as a document
> opened on the main thread forever after.
Whoops! I meant to
On 2012-12-01, at 11:42 AM, Mike Abdullah wrote:
> One way to look at it is that NSPersistentDocument pretty much painted
> itself into a corner from day 1, and it's too messy for Apple to untangle
> that.
Can you elaborate?
>>>
>>> Well it makes the assumptions that you
On 30 Nov 2012, at 23:05, Dave Fernandes wrote:
>
> On 2012-11-30, at 4:46 PM, Mike Abdullah wrote:
>
>>
>> On 30 Nov 2012, at 18:59, Dave Fernandes wrote:
>>
>>>
>>> On 2012-11-30, at 6:42 AM, Mike Abdullah wrote:
>>>
One way to look at it is that NSPersistentDocument pretty much
On 2012-11-30, at 4:46 PM, Mike Abdullah wrote:
>
> On 30 Nov 2012, at 18:59, Dave Fernandes wrote:
>
>>
>> On 2012-11-30, at 6:42 AM, Mike Abdullah wrote:
>>
>>> One way to look at it is that NSPersistentDocument pretty much painted
>>> itself into a corner from day 1, and it's too messy
On Sat, 1 Dec 2012 09:49:23 +1100, Graham Cox said:
>> Could be. But Apple could have provided a NSPersistentDocument2 class
>that people could opt into. But they haven't.
>
>Have you noticed that they never do this though? It must be some sort of
>policy because there are numerous examples wher
On 01/12/2012, at 9:01 AM, Sean McBride wrote:
> Could be. But Apple could have provided a NSPersistentDocument2 class that
> people could opt into. But they haven't.
Have you noticed that they never do this though? It must be some sort of policy
because there are numerous examples where a
On Fri, 30 Nov 2012 21:46:24 +, Mike Abdullah said:
>> Can you elaborate?
>
>Well it makes the assumptions that your document:
>
>- is comprised of a single Core Data store
>- has a single managed object context
>- works entirely on the main thread
>- only ever saves on top of itself, or to a
On 30 Nov 2012, at 18:59, Dave Fernandes wrote:
>
> On 2012-11-30, at 6:42 AM, Mike Abdullah wrote:
>
>> One way to look at it is that NSPersistentDocument pretty much painted
>> itself into a corner from day 1, and it's too messy for Apple to untangle
>> that.
>
> Can you elaborate?
Well
On 2012-11-30, at 6:42 AM, Mike Abdullah wrote:
>
> On 30 Nov 2012, at 01:16, "Sean McBride" wrote:
>
>> On Fri, 30 Nov 2012 00:43:36 +, Mike Abdullah said:
>>
>>> With all the different features of the document system these days, it
>>> can be pretty hard to slot them all in nicely with
On 30 Nov 2012, at 01:16, "Sean McBride" wrote:
> On Fri, 30 Nov 2012 00:43:36 +, Mike Abdullah said:
>
>> With all the different features of the document system these days, it
>> can be pretty hard to slot them all in nicely with Core Data. People may
>> find https://github.com/karelia/BSM
Well, if you are lobbying for features, IMHO, they should also at least
include simple migration.
On 11/29/12 7:16 PM, "Sean McBride" wrote:
> On Fri, 30 Nov 2012 00:43:36 +, Mike Abdullah said:
>
>> >With all the different features of the document system these days, it
>> >can be pretty h
On Fri, 30 Nov 2012 00:43:36 +, Mike Abdullah said:
>With all the different features of the document system these days, it
>can be pretty hard to slot them all in nicely with Core Data. People may
>find https://github.com/karelia/BSManagedDocument pretty handy for this
>(the real meat is in th
On 10 Nov 2012, at 21:36, Gordon Apple wrote:
> I don¹t know about iCloud, but I finally got file wrappers working for my
> NSPersistentDocument subclass. It wasn¹t easy. I use a separate folder for
> stored files, sibling to my coreData storage, in the same package. I based
> it losely on the
On 10 Nov 2012, at 18:28, Sean McBride wrote:
> On Sat, 10 Nov 2012 18:09:58 +, Luke Hiesterman said:
>
>> File wrappers don't make it inherently easier or harder to deal with
>> iCloud. File packages (which you would use file wrappers to represent)
>> can be elegant means of wrapping up doc
The wrapper functionality is a remnant of NSPersistentDocument but I don't use
it anymore. Thanks for your answers, this was helpful.
On Nov 10, 2012, at 1:28 PM, Sean McBride wrote:
> On Sat, 10 Nov 2012 18:09:58 +, Luke Hiesterman said:
>
>> File wrappers don't make it inherently easier
I don¹t know about iCloud, but I finally got file wrappers working for my
NSPersistentDocument subclass. It wasn¹t easy. I use a separate folder for
stored files, sibling to my coreData storage, in the same package. I based
it losely on the NSPersistentDocumentFileWrappers sample, then let my ³F
On Sat, 10 Nov 2012 18:09:58 +, Luke Hiesterman said:
>File wrappers don't make it inherently easier or harder to deal with
>iCloud. File packages (which you would use file wrappers to represent)
>can be elegant means of wrapping up document data because it allows for
>easy separation of disti
File wrappers don't make it inherently easier or harder to deal with iCloud.
File packages (which you would use file wrappers to represent) can be elegant
means of wrapping up document data because it allows for easy separation of
distinct components, and are usually recommended if they at all m
Does fileWrapper functionality make it easier or harder or is completely
irrelevant for iCloud document functionality? My app used to need the
fileWrapper functionality and it's still in there but I don't need it anymore
and I want to remove it all. Would it help me keep it?
Thanks
__
24 matches
Mail list logo