Re: Sharing Files Between My Apps via iCloud

2018-10-23 Thread Uli Kusterer 
AFAIK the .icloud files are placeholders iCloud creates for Finder to show 
while a file is still downloading (there will be a little indicator next to it 
in Finder list view showing it's still downloading.

You should probably just ignore those files and wait until iCloud has finished 
downloading.

Their content is probably just information needed to show the progress in 
Finder, if anything at all. Or it is partial file data, maybe with space 
already reserved for the final size.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

On 16. Sep 2018, at 20:27, Michal L. Wright  wrote:
> I have apps for Mac OS (myMacApp) and iOS (myIOSApp) that use the same file 
> format. The apps can synchronize files using WiFi or Dropbox.
> 
> Now I’m working on using iCloud for synchronization. I’m using the same 
> approach that works with Dropbox, which is:
> 
> 1. myIOSApp can read from and write to the app folder on Dropbox.
> 
> 2. If the file has not been previously synced, a copy can be written to 
> Dropbox for uploading to myIOSApp.
> 
> 3. Once copies of the file exist on both platforms, they can be synced after 
> one or both has been edited.
> 
> 4. If the copy in myIOSApp has been edited, that copy is written to Dropbox.
> 
> 5. In myMacApp, when the sync menu item is selected, myMacApp looks for the 
> file (by name) on Dropbox, downloads it and saves it with a temporary file 
> name.
> 
> 6. The temporary file is compared with the original, and any differences are 
> resolved.
> 
> 7. The temporary file is deleted from the Mac, and myMacApp writes the 
> resolved file to Dropbox.
> 
> 8. myIOSApp reads the resolved file from Dropbox.
> 
> I’ve gotten to the point that both myMacApp and myIOSApp can read from and 
> write to the same ubiquity container, using NSFileManager routines.
> 
> When myMacApp reads files from iCloud, the files have the correct file 
> extension, something like this: MyFile.xten
> 
> When myIOSApp running on the iPhone reads files that it wrote, the file names 
> are fine, but when reading files written by myMacApp, they look like this: 
> .MyFile.xten.icloud
> 
> I was thinking that I must be missing something regarding how entitlements or 
> info.plist were set up for each app, but it turns out that files written by 
> myIOSApp running on the iPad are treated the same way. And, myIOSApp running 
> on the iPad treats files that were written from the same app running on the 
> iPhone the same way.
> 
> The ubiquity container can be viewed in Terminal on the Mac by typing ls -r 
> "Library/Mobile Documents/iCloud~com~mycompany~myiosapp”
> 
> When the files are listed in Terminal, all I see are the file names, with 
> nothing to differentiate them based on which app wrote them, nor based on 
> which device they came from. None of them have the leading period or the 
> trailing .icloud.
> 
> I also use the following to create a listing of the files in the ubiquity 
> container:
> 
>   NSURL *iCloudURL = [[NSFileManager defaultManager] 
> URLForUbiquityContainerIdentifier:nil];
>   if (iCloudURL)
>   NSArray* fileList = [[NSFileManager defaultManager] 
> contentsOfDirectoryAtPath:iCloudURL.path error:NULL];
> 
> I step through the fileList array and use fprintf to show the paths. They 
> show the same problem with the leading period and trailing icloud.
> 
> Trying to work around the modified file names hasn’t produced any useful 
> results so far. If I read the files with the incorrect name, the content is 
> incorrect. If I strip off the the leading period and trailing icloud before 
> trying to read, the read fails.
> 
> I would appreciate any insights as to the cause of the problem and, of 
> course, it’s solution.
> 
> Thanks,
> Mike Wright
> 
> ___
> 
> 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/witness.of.teachtext%40gmx.net

___

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: XPC Question

2018-10-23 Thread Sandor Szatmari 

> On Oct 23, 2018, at 02:56, Uli Kusterer  wrote:
> 
>> On 18. Sep 2018, at 19:25, Alastair Houghton  
>> wrote:
>> Well, Cocoa has Distributed Objects, which you could use for this purpose.  
>> DO has some interesting behaviour (in particular, watch out - it can throw 
>> exceptions, even when calling methods that don’t normally do so), but it 
>> does let you send messages to objects fairly easily over a network.
> 
> From what I remember, DO also has some very ... interesting behaviour when it 
> comes to time-outs, and predictable timing, as well as dropped connections. 
> Basically, it mostly assumes a stable, near-instant network, and there's no 
> good way to recover from a dropped network, and no control over how long it 
> will take to recover from stalls etc. either.
> 
> In short, DO is intended for small LANs, so if you're planning to use it over 
> the internet ... don't.

Thanks, yes, I agree.  DO should only be considered for LAN operations.  Apt 
descriptions of its limitations and implementation restrictions.  We have had 
several 24/7 systems running, synchronized via DO since forever.  It is very 
reliable when done right.  If not, it can be a mess.

> If you need a fairly painless way for network communication, I'd suggest 
> creating your own mechanism on top of queues of message objects and keyed, or 
> better secure, archiving. You can always model things after XPC, with the 
> same method names etc.


This will, again, be for a controlled environment (local LAN).  Not sure what 
direction I’ll go at this point, but at least with the feedback I’ve gotten I 
can design something knowing I am not overlooking a newly introduced macOS 
native inter-machine RPC technology.

Thanks for your thoughts,
Sandor

> 
> Cheers,
> -- Uli Kusterer
> "The Witnesses of TeachText are everywhere..."
> http://www.zathras.de
> 
___

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

Dealing with an @available warning

2018-10-23 Thread James Walker 

I had some code like this

pInfo.orientation = NSPaperOrientationPortrait;

where pInfo is of type NSPrintInfo*.  When compiling with 
-Wunguarded-availability, I got a warning saying that 
NSPaperOrientationPortrait is only available on macOS 10.9 and later. 
So I wanted to change it to:


if (@available( macOS 10.9, * ))
{
pInfo.orientation = NSPaperOrientationPortrait;
}
else
{
pInfo.orientation = NSPortraitOrientation
}

But then I get an error, "assigning to NSPaperOrientation from 
incompatible type NSPrintingOrientation".  If I fix the error by adding 
a typecast to NSPaperOrientation, then I get a warning that 
NSPaperOrientation is only available on 10.9 and later.  Is there any 
way out of this roundabout, other than using a later deployment target?

___

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: Dealing with an @available warning

2018-10-23 Thread Saagar Jha 
What build command are you using? I’m not seeing any warnings with this code, 
compiled with clang -x objective-c -framework AppKit -Wunguarded-availability 
-mmacosx-version-min=10.9 - :

#import 

int main() {
NSPrintInfo *info;
if (@available(macOS 10.9, *)) {
info.orientation = NSPaperOrientationPortrait;
} else {
info.orientation = NSPortraitOrientation;
}
}

Regardless, if you really need a fix, you should be able to cast through 
NSInteger, instead of NSPrintingOperation, as a fallback.

Saagar Jha

> On Oct 23, 2018, at 15:01, James Walker  wrote:
> 
> I had some code like this
> 
> pInfo.orientation = NSPaperOrientationPortrait;
> 
> where pInfo is of type NSPrintInfo*.  When compiling with 
> -Wunguarded-availability, I got a warning saying that 
> NSPaperOrientationPortrait is only available on macOS 10.9 and later. So I 
> wanted to change it to:
> 
> if (@available( macOS 10.9, * ))
> {
>   pInfo.orientation = NSPaperOrientationPortrait;
> }
> else
> {
>   pInfo.orientation = NSPortraitOrientation
> }
> 
> But then I get an error, "assigning to NSPaperOrientation from incompatible 
> type NSPrintingOrientation".  If I fix the error by adding a typecast to 
> NSPaperOrientation, then I get a warning that NSPaperOrientation is only 
> available on 10.9 and later.  Is there any way out of this roundabout, other 
> than using a later deployment target?
> ___
> 
> 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/saagar%40saagarjha.com
> 
> This email sent to saa...@saagarjha.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: Dealing with an @available warning

2018-10-23 Thread Greg Parker 


> On Oct 23, 2018, at 3:01 PM, James Walker  wrote:
> 
> I had some code like this
> 
> pInfo.orientation = NSPaperOrientationPortrait;
> 
> where pInfo is of type NSPrintInfo*.  When compiling with 
> -Wunguarded-availability, I got a warning saying that 
> NSPaperOrientationPortrait is only available on macOS 10.9 and later. So I 
> wanted to change it to:
> 
> if (@available( macOS 10.9, * ))
> {
>   pInfo.orientation = NSPaperOrientationPortrait;
> }
> else
> {
>   pInfo.orientation = NSPortraitOrientation
> }
> 
> But then I get an error, "assigning to NSPaperOrientation from incompatible 
> type NSPrintingOrientation".  If I fix the error by adding a typecast to 
> NSPaperOrientation, then I get a warning that NSPaperOrientation is only 
> available on 10.9 and later.  Is there any way out of this roundabout, other 
> than using a later deployment target?

Dumb answer: use #pragma clang diagnostic to disable the guarded availability 
check on that line. Something like this:

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wunguarded-availability"
pInfo.orientation = (NSPaperOrientation)NSPortraitOrientation;
#pragma clang diagnostic pop

You should file a bug report against AppKit. I'm not sure there is any benefit 
to marking a plain C enum as unavailable. Use of a new enum would work fine 
when running on an old OS version.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


___

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: Dealing with an @available warning

2018-10-23 Thread James Walker 


___

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: Dealing with an @available warning

2018-10-23 Thread James Walker 


___

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: Dealing with an @available warning

2018-10-23 Thread Saagar Jha 

Saagar Jha

> On Oct 23, 2018, at 17:15, James Walker  wrote:
> 
> On 10/23/18 3:12 PM, Saagar Jha wrote:
>> What build command are you using? I’m not seeing any warnings with this 
>> code, compiled with clang -x objective-c -framework AppKit 
>> -Wunguarded-availability -mmacosx-version-min=10.9 - :
> 
> If you compile with a deployment version of 10.9, I don't know if it even 
> bothers to look at the else clause.  Try -mmacosx-version-min=10.8.

Oops, that was a typo. I meant -mmacosx-version-min=10.8. Either way, 
@available is checked at runtime, so both cases must be compiled anyways.

>> 
>> #import 
>> 
>> int main() {
>>  NSPrintInfo *info;
>>  if (@available(macOS 10.9, *)) {
>>  info.orientation = NSPaperOrientationPortrait;
>>  } else {
>>  info.orientation = NSPortraitOrientation;
>>  }
>> }
>> 
>> Regardless, if you really need a fix, you should be able to cast through 
>> NSInteger, instead of NSPrintingOperation, as a fallback.
> 
> I'm not sure what you mean by "cast through NSInteger", but if I say
> 
> info.orientation = (NSInteger) NSPortraitOrientation;
> 
> then there's an error, "assigning to NSPaperOrientation from incompatible 
> type NSInteger (aka long)”.

I’m not seeing that error at all, even with -Wall -Wextra. What flags are you 
using?

> 
>> 
>> Saagar Jha
>> 
>>> On Oct 23, 2018, at 15:01, James Walker >> > wrote:
>>> 
>>> I had some code like this
>>> 
>>> pInfo.orientation = NSPaperOrientationPortrait;
>>> 
>>> where pInfo is of type NSPrintInfo*.  When compiling with 
>>> -Wunguarded-availability, I got a warning saying that 
>>> NSPaperOrientationPortrait is only available on macOS 10.9 and later. So I 
>>> wanted to change it to:
>>> 
>>> if (@available( macOS 10.9, * ))
>>> {
>>> pInfo.orientation = NSPaperOrientationPortrait;
>>> }
>>> else
>>> {
>>> pInfo.orientation = NSPortraitOrientation
>>> }
>>> 
>>> But then I get an error, "assigning to NSPaperOrientation from incompatible 
>>> type NSPrintingOrientation".  If I fix the error by adding a typecast to 
>>> NSPaperOrientation, then I get a warning that NSPaperOrientation is only 
>>> available on 10.9 and later.  Is there any way out of this roundabout, 
>>> other than using a later deployment target?
> 

___

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: Dealing with an @available warning

2018-10-23 Thread James Walker 

On 10/23/18 5:36 PM, Saagar Jha wrote:


Saagar Jha

On Oct 23, 2018, at 17:15, James Walker > wrote:


On 10/23/18 3:12 PM, Saagar Jha wrote:
What build command are you using? I’m not seeing any warnings with 
this code, compiled with clang -x objective-c -framework AppKit 
-Wunguarded-availability -mmacosx-version-min=10.9 - :


If you compile with a deployment version of 10.9, I don't know if it 
even bothers to look at the else clause.  Try -mmacosx-version-min=10.8.


Oops, that was a typo. I meant -mmacosx-version-min=10.8. Either way, 
@available is checked at runtime, so both cases must be compiled anyways.




#import 

int main() {
NSPrintInfo *info;
if (@available(macOS 10.9, *)) {
info.orientation = NSPaperOrientationPortrait;
} else {
info.orientation = NSPortraitOrientation;
}
}

Regardless, if you really need a fix, you should be able to cast 
through NSInteger, instead of NSPrintingOperation, as a fallback.


I'm not sure what you mean by "cast through NSInteger", but if I say

info.orientation = (NSInteger) NSPortraitOrientation;

then there's an error, "assigning to NSPaperOrientation from 
incompatible type NSInteger (aka long)”.


I’m not seeing that error at all, even with -Wall -Wextra. What flags 
are you using?



Hmm, it appears to be because I'm using Objective-C++.  When I put that 
line in a .m file, there was no error.









Saagar Jha

On Oct 23, 2018, at 15:01, James Walker > wrote:


I had some code like this

pInfo.orientation = NSPaperOrientationPortrait;

where pInfo is of type NSPrintInfo*.  When compiling with 
-Wunguarded-availability, I got a warning saying that 
NSPaperOrientationPortrait is only available on macOS 10.9 and 
later. So I wanted to change it to:


if (@available( macOS 10.9, * ))
{
pInfo.orientation = NSPaperOrientationPortrait;
}
else
{
pInfo.orientation = NSPortraitOrientation
}

But then I get an error, "assigning to NSPaperOrientation from 
incompatible type NSPrintingOrientation".  If I fix the error by 
adding a typecast to NSPaperOrientation, then I get a warning that 
NSPaperOrientation is only available on 10.9 and later.  Is there 
any way out of this roundabout, other than using a later deployment 
target?






___

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