NSFileWrapper

[Peter Hudson]

Hi All

Our users have now decided to push the bounds of the system - resulting in file 
sizes that are getting to large for comfort.

It would be possible to fairly easily split the current file format into two 
and store it as two separate units.  This is a particularly interesting 
solution as half the data rarely changes.  It would however be neccessary for 
the two files to be handled transparently, by the user, as one unit.

I have been looking over the docs for NSFileWrapper.  I can’t see if it is 
possible to construct a file wrapper that presents itself to the user as ‘one 
file’ complete with icon - and hides the multiple files in the wrapper. 

Any suggestions / pointers  gratefully recieved !

Peter
___

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

Overriding custom KVC methods in Swift?

[Daryle Walker]

I just looked through the Key-Value Coding Programming Guide, and I’m wondering 
what the prototypes are of the name-customized methods for your properties in 
Swift.  Since the KVC protocol is informal, getting the names and/or types 
wrong doesn’t mean an error, but that your implementation is ignored and 
default handling is done.

For instance:

//=
   func validateBody(ioValue: AutoreleasingUnsafeMutablePointer) 
throws {
   guard let newBody = ioValue.memory as? NSString else {
   throw NSCocoaError.KeyValueValidationError
   }

   let errors = self.dynamicType.problemsValidatingBody(newBody as String)
   if !errors.isEmpty {
   throw errors.first!
   }
   // Else: do nothing
   }
//=

is this the correct signature to KVC-validate a property named “body” in Swift?

(Incidentally, is that a good implementation?)

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT 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: NSFileWrapper

[Mike Abdullah]

It sounds like you want your file format to be what is known as a “package”. 
It’s a directory, but is (mostly) presented as a single file.

NSFileWrapper is an API for working with files, it does not directly control 
whether something is a package or not. It just happens to be the most 
convenient API in Cocoa for working with packages and documents, and so 
NSDocument has built in support for that.

Mike.

> On 4 Jun 2016, at 12:01, Peter Hudson  wrote:
> 
> Hi All
> 
> Our users have now decided to push the bounds of the system - resulting in 
> file sizes that are getting to large for comfort.
> 
> It would be possible to fairly easily split the current file format into two 
> and store it as two separate units.  This is a particularly interesting 
> solution as half the data rarely changes.  It would however be neccessary for 
> the two files to be handled transparently, by the user, as one unit.
> 
> I have been looking over the docs for NSFileWrapper.  I can’t see if it is 
> possible to construct a file wrapper that presents itself to the user as ‘one 
> file’ complete with icon - and hides the multiple files in the wrapper. 
> 
> Any suggestions / pointers  gratefully recieved !
> 
> Peter
> ___
> 
> 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/mabdullah%40karelia.com
> 
> This email sent to mabdul...@karelia.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: NSFileWrapper

[Peter Hudson]

Hi Mike

You're right - I want the behaviour of a package. Do you happen to know how I 
can achieve it?   I had presumed it might be some mix of flag setting at system 
level. If for example i set the extension on an NSFileWrapper to   .bundle i 
get some of what I need - but I cant find out how to ‎get an icon of my 
choosing associated with it. 

Peter

  Original Message  
From: Mike Abdullah
Sent: Saturday, 4 June 2016 17:12
To: Peter Hudson
Cc: cocoa-dev@lists.apple.com List
Subject: Re: NSFileWrapper

It sounds like you want your file format to be what is known as a “package”. 
It’s a directory, but is (mostly) presented as a single file.

NSFileWrapper is an API for working with files, it does not directly control 
whether something is a package or not. It just happens to be the most 
convenient API in Cocoa for working with packages and documents, and so 
NSDocument has built in support for that.

Mike.

> On 4 Jun 2016, at 12:01, Peter Hudson  wrote:
> 
> Hi All
> 
> Our users have now decided to push the bounds of the system - resulting in 
> file sizes that are getting to large for comfort.
> 
> It would be possible to fairly easily split the current file format into two 
> and store it as two separate units. This is a particularly interesting 
> solution as half the data rarely changes. It would however be neccessary for 
> the two files to be handled transparently, by the user, as one unit.
> 
> I have been looking over the docs for NSFileWrapper. I can’t see if it is 
> possible to construct a file wrapper that presents itself to the user as ‘one 
> file’ complete with icon - and hides the multiple files in the wrapper. 
> 
> Any suggestions / pointers gratefully recieved !
> 
> Peter
> ___
> 
> 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/mabdullah%40karelia.com
> 
> This email sent to mabdul...@karelia.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: NSFileWrapper

[Jens Alfke]

> On Jun 4, 2016, at 9:18 AM, Peter Hudson  wrote:
> 
> You're right - I want the behaviour of a package. Do you happen to know how I 
> can achieve it?   I had presumed it might be some mix of flag setting at 
> system level. If for example i set the extension on an NSFileWrapper to   
> .bundle i get some of what I need - but I cant find out how to ‎get an icon 
> of my choosing associated with it. 

It’s part of the document-type declaration in your app’s Info.plist.

I wouldn’t recommend NSFileWrapper for large files, because it reads all of a 
file into memory. The same goes for the usual file-I/O convenience methods on 
NSData, NSString. etc. — for some reason the Foundation APIs have always been 
biased toward reading/writing entire files. This is very convenient, but not 
scaleable.

If your app’s performance is suffering because of large files, then use streams 
instead, and try to only read the part of the file that’s necessary. Or use a 
database like SQLite, which can easily handle terabyte-size files. (If you 
don’t want to deal with SQL queries, there are simpler key/value databases like 
LevelDB, LMDB, Kyoto Cabinet and Berkeley DB.)

—Jens
___

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: Overriding custom KVC methods in Swift?

[Quincey Morris]

On Jun 4, 2016, at 07:10 , Daryle Walker  wrote:
> 
> Since the KVC protocol is informal, getting the names and/or types wrong 
> doesn’t mean an error, but that your implementation is ignored and default 
> handling is done.

Well, there’s the same danger in Obj-C code, too. However, the clang compiler 
will actually suggest property-specific KVC method signatures via autocomplete.

>   func validateBody(ioValue: AutoreleasingUnsafeMutablePointer) 
> throws {

> is this the correct signature to KVC-validate a property named “body” in 
> Swift?

I think so. Since it’s unlikely you arrived at this by guesswork, you likely 
got it via autocomplete for ‘validateValueForKey’ and modifying the result. 
This seems like the correct thing to do. (You could also submit a bug asking 
for the clang autocomplete behavior.)

> (Incidentally, is that a good implementation?)


It looks OK. The only objection I would have is unrelated to validation. 
Instead of this code:

>   if !errors.isEmpty {
>   throw errors.first!
>   }


I’d suggest this:

>   if let firstError = errors.first {
>   throw firstError
>   }

Using the IUO operator (in “errors.first!”) seems to be regarded as a bit of a 
code smell, especially when there’s a natural alternative using optional 
binding. Also, the second version has one less method call, which saves the 
lives of a couple of electrons that would otherwise be sacrificed to your app.

___

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: NSFileWrapper

[Peter Hudson]

Hi Jens

“If your app’s performance is suffering because of large files, then use 
streams instead, and try to only read the part of the file that’s necessary.”

Could you point me at some material about this technique ?  It sounds very 
interesting.

I will check out the database approach as well.  I have steered clear of using 
databases as our users are mostly individuals with little or no tech support. 
The idea has always been to keep things simple and maintenance free.

Peter








> On 4 Jun 2016, at 17:42, Jens Alfke  wrote:
> 
> LevelDB

___

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: NSFileWrapper

[Jens Alfke]

> On Jun 4, 2016, at 9:51 AM, Peter Hudson  wrote:
> 
> “If your app’s performance is suffering because of large files, then use 
> streams instead, and try to only read the part of the file that’s necessary.”
> Could you point me at some material about this technique ?  It sounds very 
> interesting.

At a low level, you can use NSStream to read/write files. Or just use the C 
standard library (fopen, fread, etc.)

At a high level, I can’t say that much since I don’t know what your file format 
is. If it’s something like an NSArchive, there’s no alternative to reading the 
entire file at once. If it’s an XML property list, you could use NSXMLParser to 
stream it and pick out just the parts you need, although this also gets 
expensive if you have to keep parsing the file over and over to read different 
parts.

> I will check out the database approach as well.  I have steered clear of 
> using databases as our users are mostly individuals with little or no tech 
> support. The idea has always been to keep things simple and maintenance free.

You’re thinking of a database _server_ like MySQL or MongoDB. Those run as 
separate processes and require administration.  The databases I mentioned are 
embedded: they’re just libraries that you link into your app, which read and 
write a data file (or a directory in LevelDB’s case.) To the end user it’s no 
different than any other file format. 

Any Core Data app stores its documents this way, using SQLite by default. There 
are also zillions more apps that use FMDB (an Objective-C wrapper around 
SQLite) or just SQLite directly. Going with that does require that you learn 
about relational databases and SQL syntax, though. Another option is Realm, a 
very popular mobile database with a nice Obj-C or Swift API.

(There’s also the project I work on, Couchbase Lite, which fits in this 
category. It has some more overhead, though, because it also performs full 
multi-master data sync with servers or peers. This is awesome if you want that 
feature, but if you’re just getting started with databases it adds to the 
learning curve.)

Thinking through all the DB options, I’d suggest you look at Realm 
(http://realm.io). It’s very easy to understand even if you don’t know 
databases, and the APIs are easy to use. The drawback is that it will probably 
require that you rethink and re-implement your data model layer based on its 
persistent object model.

If you don’t want to refactor that much, see whether there are any good Cocoa 
wrappers around LevelDB, LMDB or RocksDB. (I’m skipping over Kyoto Cabinet 
because I just remembered it’s GPL-licensed, and you probably want to stay away 
from that.) They’ll provide a simple API that looks like an dictionary that 
maps strings to binary data. Then you can break your data into small bits and 
read and write them independently.

—Jens
___

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 implement a control/view that maps to a "String?" (in Swift)

[Daryle Walker]

I guess I could implement a “String” property with a NSTextView.  What about a 
“String?” though.  NIL and empty strings are distinct in the model, and I’ll 
like to reflect that in the document window too.  (Although no one but me would 
pick a NIL option over an empty text-view and string.)  I was thinking of a 
tab-view, one pane with the text view, and the other with a placard saying 
there is no text section yet and a button to add one.  (I would have a menu 
item to remove the section, to edit the other way.)

Is this a good way to present in the window?  Any gotchas?  (Oh, this is on OS 
X and I’m using storyboards.)

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT 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

Sorry to ask again, but maybe I'm asking the question incorrectly. Remote Notifications outside app delegate.

[Alex Zavatone]

When registering for push notifications, the success or failure methods are 
sent back to the application delegate in these methods

- application:didRegisterForRemoteNotificationsWithDeviceToken:
– application:didFailToRegisterForRemoteNotificationsWithError:

Is it possible to "catch" these from a place that is not the application 
delegate?  

I'm seeing if it's possible to get these events from within a framework, since 
the application delegate is outside of our direct control.  

I'm wondering if (man, I detest the term) method swizzling of the app delegate 
would work or possibly modifying the methods of UIApplication at runtime to 
pipe the methods to a class in the framework?

Initially, i'm going to add them to the UIApplication but I'd like to have a 
nice little self enclosed framework that is able to handle them.

With VOIP push notifications, being able to be handled outside the app 
delegate, those look like something to consider, but not for now due to back 
end considerations.

Thanks again.  

Alex Zavatone
___

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: Overriding custom KVC methods in Swift?

[Daryle Walker]

> On Jun 4, 2016, at 12:44 PM, Quincey Morris 
>  wrote:
> 
> On Jun 4, 2016, at 07:10 , Daryle Walker  > wrote:
>> 
>> Since the KVC protocol is informal, getting the names and/or types wrong 
>> doesn’t mean an error, but that your implementation is ignored and default 
>> handling is done.
> 
> Well, there’s the same danger in Obj-C code, too. However, the clang compiler 
> will actually suggest property-specific KVC method signatures via 
> autocomplete.

And that the Obj-C versions of the prototypes are in the guide, which hasn’t 
been updated for Swift.

>>   func validateBody(ioValue: AutoreleasingUnsafeMutablePointer) 
>> throws {
>> 
>> is this the correct signature to KVC-validate a property named “body” in 
>> Swift?
> 
> I think so. Since it’s unlikely you arrived at this by guesswork, you likely 
> got it via autocomplete for ‘validateValueForKey’ and modifying the result. 
> This seems like the correct thing to do. (You could also submit a bug asking 
> for the clang autocomplete behavior.)

Actually, that’s what happened, but only as I was typing in my first guess.  It 
was the same except I mapped, based on the Swift w/ Cocoa & Obj-C guide, the 
“id *” in the KVC guide to a “UnsafeMutablePointer”.  Anyone know 
why it’s different?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT 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: Overriding custom KVC methods in Swift?

[Quincey Morris]

On Jun 4, 2016, at 12:54 , Daryle Walker  wrote:
> 
> It was the same except I mapped, based on the Swift w/ Cocoa & Obj-C guide, 
> the “id *” in the KVC guide to a “UnsafeMutablePointer”.  Anyone 
> know why it’s different?

It’s not unusual that the property being bound to can take a nil value, so I 
guess you need to allow for that case in the validation routine.

___

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: Sorry to ask again, but maybe I'm asking the question incorrectly. Remote Notifications outside app delegate.

[Quincey Morris]

On Jun 4, 2016, at 12:44 , Alex Zavatone  wrote:
> 
> I'm wondering if (man, I detest the term) method swizzling of the app 
> delegate would work or possibly modifying the methods of UIApplication at 
> runtime to pipe the methods to a class in the framework?
> 
> Initially, i'm going to add them to the UIApplication but I'd like to have a 
> nice little self enclosed framework that is able to handle them.

So, in effect you want to perform a code injection attack on the app which you 
don’t control?

Why not provide some initialization methods for the framework that are given 
the results of those delegate methods. That way you are being an honest 
citizen, because it’s explicit what functionality the framework is designed to 
control. It imposes the need for a few lines of glue code in the app delegate, 
but if that code doesn’t do it, it’s not your fault.

___

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: NSFileWrapper

[Peter Hudson]

Jens

Thanks for these notes - extremely helpful.
I think I will kick off with Realm and see where I get too.

Peter



> On 4 Jun 2016, at 20:36, Jens Alfke  wrote:
> 
> 
>> On Jun 4, 2016, at 9:51 AM, Peter Hudson > > wrote:
>> 
>> “If your app’s performance is suffering because of large files, then use 
>> streams instead, and try to only read the part of the file that’s necessary.”
>> Could you point me at some material about this technique ?  It sounds very 
>> interesting.
> 
> At a low level, you can use NSStream to read/write files. Or just use the C 
> standard library (fopen, fread, etc.)
> 
> At a high level, I can’t say that much since I don’t know what your file 
> format is. If it’s something like an NSArchive, there’s no alternative to 
> reading the entire file at once. If it’s an XML property list, you could use 
> NSXMLParser to stream it and pick out just the parts you need, although this 
> also gets expensive if you have to keep parsing the file over and over to 
> read different parts.
> 
>> I will check out the database approach as well.  I have steered clear of 
>> using databases as our users are mostly individuals with little or no tech 
>> support. The idea has always been to keep things simple and maintenance free.
> 
> You’re thinking of a database _server_ like MySQL or MongoDB. Those run as 
> separate processes and require administration.  The databases I mentioned are 
> embedded: they’re just libraries that you link into your app, which read and 
> write a data file (or a directory in LevelDB’s case.) To the end user it’s no 
> different than any other file format. 
> 
> Any Core Data app stores its documents this way, using SQLite by default. 
> There are also zillions more apps that use FMDB (an Objective-C wrapper 
> around SQLite) or just SQLite directly. Going with that does require that you 
> learn about relational databases and SQL syntax, though. Another option is 
> Realm, a very popular mobile database with a nice Obj-C or Swift API.
> 
> (There’s also the project I work on, Couchbase Lite, which fits in this 
> category. It has some more overhead, though, because it also performs full 
> multi-master data sync with servers or peers. This is awesome if you want 
> that feature, but if you’re just getting started with databases it adds to 
> the learning curve.)
> 
> Thinking through all the DB options, I’d suggest you look at Realm 
> (http://realm.io ). It’s very easy to understand even if 
> you don’t know databases, and the APIs are easy to use. The drawback is that 
> it will probably require that you rethink and re-implement your data model 
> layer based on its persistent object model.
> 
> If you don’t want to refactor that much, see whether there are any good Cocoa 
> wrappers around LevelDB, LMDB or RocksDB. (I’m skipping over Kyoto Cabinet 
> because I just remembered it’s GPL-licensed, and you probably want to stay 
> away from that.) They’ll provide a simple API that looks like an dictionary 
> that maps strings to binary data. Then you can break your data into small 
> bits and read and write them independently.
> 
> —Jens

___

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: NSFileWrapper

[Markus Spoettl]

On 04/06/16 18:42, Jens Alfke wrote:

I wouldn’t recommend NSFileWrapper for large files, because it reads all of a
file into memory.


I find this comment to be very misleading.

Part of the reason why packages are so great (apart from being supported by 
NSDocument/AppKit as a method to store document data) is because you can 
partition the data into many many files. If you have data that's too big, split 
it up into multiple files. And what is large anyway?


When you open such a package document, NONE of the individual file's contents 
are read, you have complete control over what individual file you read and when. 
Likewise with saving, you never have to store everything from scratch (you can, 
but you don't have to). If you have unchanged data you just let the API know (by 
reusing the wrappers you got when the file was opened).


I'm a fan.

Regards
Markus
--
__
Markus Spoettl
___

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: NSFileWrapper

[Quincey Morris]

On Jun 4, 2016, at 14:10 , Markus Spoettl  wrote:
> 
> you have complete control over what individual file you read and when

That’s fine for documents where it’s helpful not to have to read files only to 
write them out unchanged on a save.

It doesn’t really help when you need to read large amounts of data. The problem 
is that NSFileWrapper doesn’t AFAIK have any API to get already-read files out 
of memory. In terms of eventual memory usage, it’s the same whether you read 1 
large file or 100 small ones.

Compounding this problem is that it’s typical for the file data to be an 
archive, which means that when you unarchive it you’re using twice the memory — 
once for the archive (a NSData object retained by the file wrapper) and once 
for the re-created objects.

This is mitigated in common use, because the files can often be mapped rather 
than read via I/O APIs, so they use address space, but not necessarily much 
memory.

I find the documentation lacking in this regard, because it fails to 
distinguish between large documents that only need to be read selectively, 
usually, and large documents that need to be read partially. NSDocument has API 
for the latter, but it’s buried pretty deep.

___

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: Sorry to ask again, but maybe I'm asking the question incorrectly. Remote Notifications outside app delegate.

[Quincey Morris]

On Jun 4, 2016, at 14:14 , Alex Zavatone  wrote:
> 
> Currently, the hosting app just needs 1 line of code to start up and use a 
> whole app that is within the framework.  Not being able to get the APNS token 
> within our framework makes it harder to …

So why can’t the 1 line be in the app’s 
application:didRegisterForRemoteNotificationsWithDeviceToken: delegate method, 
with an extra parameter that’s the APNS token?

I understand the appeal of providing a framework that’s self-contained in all 
its details. At the same, part of the reason we’re so deep in security doo-doo 
in the last 20 years is blindly trusting 3rd party components that do dangerous 
things without announcing the fact.

In fact — and please take this as a theoretical point, since I doubt you’re 
interested changing course at this late date — there’s an argument that says 
you should handle *your* APNS notifications in a separate process (either a 
background app or something like an XPC process).

FWIW

___

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: NSFileWrapper

[Daryle Walker]

> On Jun 4, 2016, at 12:18 PM, Peter Hudson  wrote:
> 
> Hi Mike
> 
> You're right - I want the behaviour of a package. Do you happen to know how I 
> can achieve it?   I had presumed it might be some mix of flag setting at 
> system level. If for example i set the extension on an NSFileWrapper to   
> .bundle i get some of what I need - but I cant find out how to ‎get an icon 
> of my choosing associated with it.

You’ll have to work at it; it won’t be completely transparent to your users to 
experience nor you to program.

The “.bundle” extension is already in use for system plug-ins.  You have to 
come up with a new extension.  For instance, if you’re already using “.xyz” for 
you single-file format, you could use “.xyz-pkg” for your package format.

In the section of your Info.plist that describes the single-file format, add 
another file type for the new package format.  You can have both point to the 
same NSDocument subclass to handle opening/saving.  Of course, you have to 
change your reading method to detect which file object you got.  You should 
give the users the option to save (as) in either format, and have your writing 
methods reflect that.

I think you mark your new file format’s package flag in the Info.plist.  (I 
don’t know if that’s compatible with the two file formats sharing a NSDocument 
subclass.)  As Mike said, use the NSFileWrapper APIs to create the enclosing 
folder (with your new extension to mark it as a package) and the files within.  
Also look at NSFileHandle, NSFilePresenter and NSFileCoordinator.

You don’t have to go database overkill if you don’t want to.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

> Peter
> 
>   Original Message  
> From: Mike Abdullah
> Sent: Saturday, 4 June 2016 17:12
> To: Peter Hudson
> Cc: cocoa-dev@lists.apple.com List
> Subject: Re: NSFileWrapper
> 
> It sounds like you want your file format to be what is known as a “package”. 
> It’s a directory, but is (mostly) presented as a single file.
> 
> NSFileWrapper is an API for working with files, it does not directly control 
> whether something is a package or not. It just happens to be the most 
> convenient API in Cocoa for working with packages and documents, and so 
> NSDocument has built in support for that.
> 
> Mike.
> 
>> On 4 Jun 2016, at 12:01, Peter Hudson  wrote:
>> 
>> Hi All
>> 
>> Our users have now decided to push the bounds of the system - resulting in 
>> file sizes that are getting to large for comfort.
>> 
>> It would be possible to fairly easily split the current file format into two 
>> and store it as two separate units. This is a particularly interesting 
>> solution as half the data rarely changes. It would however be neccessary for 
>> the two files to be handled transparently, by the user, as one unit.
>> 
>> I have been looking over the docs for NSFileWrapper. I can’t see if it is 
>> possible to construct a file wrapper that presents itself to the user as 
>> ‘one file’ complete with icon - and hides the multiple files in the wrapper. 
>> 
>> Any suggestions / pointers gratefully recieved !
>> 
>> Peter


___

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: Sorry to ask again, but maybe I'm asking the question incorrectly. Remote Notifications outside app delegate.

[Alex Zavatone]

On Jun 4, 2016, at 4:53 PM, Quincey Morris wrote:

> On Jun 4, 2016, at 14:14 , Alex Zavatone  wrote:
>> 
>> Currently, the hosting app just needs 1 line of code to start up and use a 
>> whole app that is within the framework.  Not being able to get the APNS 
>> token within our framework makes it harder to …
> 
> So why can’t the 1 line be in the app’s 
> application:didRegisterForRemoteNotificationsWithDeviceToken: delegate 
> method, with an extra parameter that’s the APNS token?

I'm looking to minimize the complexity of this from the point of view of people 
who need to use the framework.

> 
> I understand the appeal of providing a framework that’s self-contained in all 
> its details. At the same, part of the reason we’re so deep in security 
> doo-doo in the last 20 years is blindly trusting 3rd party components that do 
> dangerous things without announcing the fact.

We would be announcing the fact.

> 
> In fact — and please take this as a theoretical point, since I doubt you’re 
> interested changing course at this late date — there’s an argument that says 
> you should handle *your* APNS notifications in a separate process (either a 
> background app or something like an XPC process).
> 
> FWIW

Well, this is on iOS if I neglected to mention.  
___

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: Sorry to ask again, but maybe I'm asking the question incorrectly. Remote Notifications outside app delegate.

[Alex Zavatone]

On Jun 4, 2016, at 3:14 PM, Quincey Morris wrote:

> On Jun 4, 2016, at 12:44 , Alex Zavatone  wrote:
>> 
>> I'm wondering if (man, I detest the term) method swizzling of the app 
>> delegate would work or possibly modifying the methods of UIApplication at 
>> runtime to pipe the methods to a class in the framework?
>> 
>> Initially, i'm going to add them to the UIApplication but I'd like to have a 
>> nice little self enclosed framework that is able to handle them.
> 
> So, in effect you want to perform a code injection attack on the app which 
> you don’t control?

Well, that's what I'm asking!  Do I?  Or is there a better method?

It's not an "attack", it's a feature.  

> 
> Why not provide some initialization methods for the framework that are given 
> the results of those delegate methods. That way you are being an honest 
> citizen, because it’s explicit what functionality the framework is designed 
> to control. It imposes the need for a few lines of glue code in the app 
> delegate, but if that code doesn’t do it, it’s not your fault.
> 

Well, this is functionality that I am trying to add as part of the framework.  
The limitation to having these methods within the appDelegate makes this 
framework a much less modular solution.

Currently, the hosting app just needs 1 line of code to start up and use a 
whole app that is within the framework.  Not being able to get the APNS token 
within our framework makes it harder to pass it back to our servers without the 
involvement of someone else putting the required calls back to our framework in 
the appDelegate of their app.

That and responding to remote notifications as well.

The idea of the framework is to have our app as a self contained module to run 
in any other app.  Not being able to handle push notifications from within our 
framework is a less than elegant solution.

To be honest, our app is only ready for push notifications after a few round 
trips to get data from a server.  And then when notifications come in, we don't 
want the hosting app to have to handle them, because well, they are for the 
framework.  

I trust that we're also going to have a few issues with custom URL schemes as 
well, which we also respond to.


___

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: NSDocument not displaying save prompt on dirty document

[livinginlosangeles]

Ok. The issue was that the auto-save prompt had disappeared when I was closing 
a dirty nsdocument. I added a nswindowcontroller to my nsdocument using 
addWindowController. I needed to add setShouldCloseDocument to my main 
nswindowcontroller, otherwise my document wouldn’t show the prompt.

Patrick  
___

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: NSFileWrapper

[Chris Ridd]

> On 4 Jun 2016, at 23:02, Daryle Walker  wrote:
> 
>> On Jun 4, 2016, at 12:18 PM, Peter Hudson  wrote:
>> 
>> Hi Mike
>> 
>> You're right - I want the behaviour of a package. Do you happen to know how 
>> I can achieve it?   I had presumed it might be some mix of flag setting at 
>> system level. If for example i set the extension on an NSFileWrapper to   
>> .bundle i get some of what I need - but I cant find out how to ‎get an icon 
>> of my choosing associated with it.
> 
> You’ll have to work at it; it won’t be completely transparent to your users 
> to experience nor you to program.
> 
> The “.bundle” extension is already in use for system plug-ins.  You have to 
> come up with a new extension.  For instance, if you’re already using “.xyz” 
> for you single-file format, you could use “.xyz-pkg” for your package format.

Are you sure that’s true? Apps like OmniGraffle have a flat file format *and* a 
bundle format, both using the .graffle extension. In OmniGraffle Pro's document 
inspector you can switch between formats.

If you have the app or a demo you can investigate its Info.plist.

Chris
___

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: NSFileWrapper

[Graham Cox]

> On 5 Jun 2016, at 8:02 AM, Daryle Walker  wrote:
> 
> You have to come up with a new extension.  For instance, if you’re already 
> using “.xyz” for you single-file format, you could use “.xyz-pkg” for your 
> package format.


You can use the same extension and leave it to your app to figure out which 
it’s actually dealing with - the extension is only used to map the file to an 
app that can open it - after that the file will be passed to NSDocument as a 
NSFileWrapper whatever its contents - packagae or flat file. Your app can then 
determine which it is based on some private knowledge about its structure.

Alternatively, make up a  new extension - the amount of work for your app is 
about the same, so the question is whether you want to disguise the change for 
end users.

—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: NSFileWrapper

[Peter Hudson]

Hi All

Many thanks to everyone who has contributed to this thread on NSFileWrapper.

I have enough insight now  to do some work to see what works.

Again, thanks to everybody !

Peter

___

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: NSFileWrapper

[Charles Srstka]

> On Jun 5, 2016, at 1:27 AM, Graham Cox  wrote:
> 
> 
>> On 5 Jun 2016, at 8:02 AM, Daryle Walker  wrote:
>> 
>> You have to come up with a new extension.  For instance, if you’re already 
>> using “.xyz” for you single-file format, you could use “.xyz-pkg” for your 
>> package format.
> 
> 
> You can use the same extension and leave it to your app to figure out which 
> it’s actually dealing with - the extension is only used to map the file to an 
> app that can open it - after that the file will be passed to NSDocument as a 
> NSFileWrapper whatever its contents - packagae or flat file. Your app can 
> then determine which it is based on some private knowledge about its 
> structure.
> 
> Alternatively, make up a  new extension - the amount of work for your app is 
> about the same, so the question is whether you want to disguise the change 
> for end users.
> 
> —Graham

My favorite way to deal with bundle documents is to just override 
readFromURL:ofType:error:, make an NSBundle from that, and load things lazily 
as needed.

Every time I’ve ever tried to use NSFileWrapper, I’ve always ended up having to 
switch to something else because of the memory issue that Jens mentions. Never 
really understood the point of that class.

Charles


___

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