Re: Sandboxing die.die.die

2012-08-30 Thread Mike Abdullah 

On 30 Aug 2012, at 05:10, John Bishop  wrote:

> On 30 Aug 2012 07:01:04 +0800, Roland King  wrote:
> 
>> 
>> On 30 Aug, 2012, at 6:34 AM, Alex Zavatone  wrote:
>> 
>>> But before anyone reads too far, I am making certain assumptions that may 
>>> indeed be false.  That iOS and Mac OS app Sandboxing is absolutely required 
>>> and you can't make apps without it enabled, whether the apps are destined 
>>> for the App store or not.
>>> 
>> 
>> For iOS it's true, always has been. For OSX it's not. If the app is for the 
>> store you must sandbox it, but you can distribute apps outside the store 
>> with no sandboxing at all and you have the intermediate step of signing with 
>> a developer id which doesn't require sandboxing but lets the user know apple 
>> knows who wrote the app. Use of iCloud on OSX requires the sandbox. 
> 
> Almost.  I believe use of iCloud is limited to apps from the Mac App Store, 
> which must be sandboxed whether including iCloud capabilities or not.  
> Sandboxing can be implemented outside the Mac App Store, but is rarely 
> (ever?) implemented because of the uh... "complexities" associated with the 
> technology at the moment. Those apps, sandboxed but delivered outside the Mac 
> App Store, which invoke iCloud APIs are reported to fail in the sandbox 
> because they don't include Apple's credentials in their code signature.
> 
> My personal opinion is that this restriction may eventually be relaxed by 
> Apple some day (don't hold your breath) if it becomes technically and 
> economically beneficial to do so simply by removing the Apple code signing 
> requirement in the OS.  I have no knowledge of plans or methods to accomplish 
> this... just a hunch.

You have filed a radar requesting this, yes?


___

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: Sandboxing die.die.die

2012-08-30 Thread Stephane Sudre 
On Thu, Aug 30, 2012 at 1:59 AM, Greg Parker  wrote:
...
> OS X does not require sandboxing. For apps that are not sandboxed, 
> traditional file access is unchanged. Mountain Lion's Gatekeeper can be 
> configured to require signed apps, but it does not enforce sandboxing.

Somehow, Gatekeeper can be configured to require sandboxed apps (and
only some of them actually).

When the option to only accept applications from the Mac App Store is
on, this somehow implies that the applications will (*) be sandboxed
(since they are to be sandboxed to be submitted to the Mac App Store).



(*) at the time of this writing, insert a "probably" since previously
non-sandboxed apps are still available through the Mac App Store.
___

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: On handling those lovely unrecognized selector sent to instance SIGABRTs

2012-08-30 Thread Mikkel Islay 
Hi Alex,

On 30 Aug 2012, at 05:03, Alex Zavatone wrote:

> And if you don't know that Symbolic Breakpoints even exist, or what they are 
> used for, how do you know that part of the documentation is where to turn to 
> to find a solution?
> If the issue is "I have no idea how to track down what crashed where with 
> these SIGABRTs", then well, why would I know to turn to the Breakpoint 
> Navigator to solve my problem?

The crux of the matter, I think, is that there exist an experience-gap between 
the people who develop Xcode and a certain proportion of its users.
Taking your compliant as an example: symbolic breakpoints, and the concept of 
setting them on exceptions in a debugger is not a Cocoa or Xcode-specific 
technique. For developers with a background in programming-languages and APIs 
where exception-handling is an integrated pattern, it will seem a natural thing 
to do. I imagine the Xcode-developer team has that background. However for 
developers with different backgrounds, e.g. with primary development-experience 
from UIKit/AppKit, it will be less obvious, because exception-handling patterns 
are much less used in code based on those frameworks.

In general, Xcode is used by developers in a continuum of experience-levels. 
With respect to Xcode-development,  a tension exist between advancing the state 
of the tools, and shoring up the users to use them effectively. I don't think 
what you suggest can be achieved effeiciently from within Xcode. It is much 
better addressed with training and improved documentation. Jens Afke mentioned 
better and more broad documentation of Xcode itself.To that I would add 
documentation that improves understanding of how the frameworks work, focused 
on the internals rather than the interfaces themselves. To some extent, it is 
also a community effort. Sites like Stack-overflow, exist for that purpose.

Having written that, I think your concerns are fair. Xcode is, in practice, the 
only tool variable for developing for Apple's platforms, and it should take the 
needs and wants of its users seriously. In general, I think it is. Consider how 
UIKit and certain core-concepts, are described several tiers of documentation, 
aimed at developers at different levels of expertise.

Mikkel
___

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

Apple Mach-O Linker Error

2012-08-30 Thread Geoffrey Goutallier 
Greetings Folks,


I am right now working on an iPhone project, and I submitted it without any 
problem several time to the App Store. Upon the last approval from Apple, I 
witnessed that it was not working as expected. So I changed a few minor things 
(but blocking the in-app purchase, so kinda important…), like changing the 
version #, build #, and moving a line outside of an 'if' statement.
But now, when trying to Archive my app, the build fail with the following error 
(Apple Mach-O Linker Error):

"(null): Linker command failed with exit code 1 (use -v to see invocation)"

from the console: 

Ld 
/Users/geoffrey/Library/Developer/Xcode/DerivedData/Generic-aqfasatrblaisracrrjosfxilxdw/Build/Intermediates/ArchiveIntermediates/Generic/IntermediateBuildFilesPath/UninstalledProducts/MyApp.app/MyApp
 normal armv7
cd /Users/geoffrey/Documents/Dev/iPhone/myapp
setenv IPHONEOS_DEPLOYMENT_TARGET 4.3
setenv PATH 
"/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
 
-arch armv7 
-isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk
 

-L/Users/geoffrey/Library/Developer/Xcode/DerivedData/Generic-aqfasatrblaisracrrjosfxilxdw/Build/Intermediates/ArchiveIntermediates/Generic/BuildProductsPath/Release-iphoneos
 

-L/Users/geoffrey/Documents/Dev/iPhone/MyApp/Classes/SDK/GoogleAnalytics 

-L/Users/geoffrey/Documents/Dev/iPhone/MyApp/Classes/SDK/AppVIPControllerLibrary
 

-F/Users/geoffrey/Library/Developer/Xcode/DerivedData/Generic-aqfasatrblaisracrrjosfxilxdw/Build/Intermediates/ArchiveIntermediates/Generic/BuildProductsPath/Release-iphoneos
 
-F/Users/geoffrey/Documents/Dev/iPhone/MyApp/Classes 
-F/Users/geoffrey/Documents/Dev/iPhone/MyApp 
-filelist 
/Users/geoffrey/Library/Developer/Xcode/DerivedData/Generic-aqfasatrblaisracrrjosfxilxdw/Build/Intermediates/ArchiveIntermediates/Generic/IntermediateBuildFilesPath/Generic.build/Release-iphoneos/Generic.build/Objects-normal/armv7/MyApp.LinkFileList
 
-dead_strip 
-fobjc-link-runtime 
-miphoneos-version-min=4.3 
-framework CrashReporter 
-framework Foundation 
-framework AVFoundation 
-lAppVIPController 
-framework AudioToolbox 
-framework StoreKit 
-framework UIKit 
-framework CoreGraphics 
-lz 
-framework CoreLocation 
-lxml2 
-framework SystemConfiguration 
-licucore 
-framework MessageUI 
-framework CFNetwork 
-framework MobileCoreServices 
-framework QuartzCore 
-framework MapKit 
-lsqlite3.0 
-lGoogleAnalytics 
-o 
/Users/geoffrey/Library/Developer/Xcode/DerivedData/Generic-aqfasatrblaisracrrjosfxilxdw/Build/Intermediates/ArchiveIntermediates/Generic/IntermediateBuildFilesPath/UninstalledProducts/MyApp.app/MyApp

ld: in section __TEXT,__text reloc 3: sectionForAddress(0x241C) address not in 
any section for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)

My project being versionned, I checked it out on the last revision that built 
(and was sent to the Store), but to no avail: it would not build either.

Interestingly, one of my frameworks had a '~' sign in Xcode's Project Navigator 
(where there is normally the 'M' sign saying that the file has been changed). 
It is not shown now, though...

I searched the internet unsuccessfully – 1 thread on StackOverflow, but still 
open: 

http://stackoverflow.com/questions/11942641/xcode-4-4-link-error

and spent almost 3 days on that damned problem. Any help will be greatly 
appreciated! :)

Thank you for your help and time !

Geoffrey

___

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: On handling those lovely unrecognized selector sent to instance SIGABRTs

2012-08-30 Thread Fritz Anderson 
On 29 Aug 2012, at 11:51 PM, Jens Alfke  wrote:

> There needs to be an Xcode manual.

A'h'm.

(And if anyone has criticisms, I'd be glad to know; I'm working on an ebook 
supplement.)

By the way…

> PS: And this is totally an xcode-users post, not cocoa-dev, so further posts 
> should probably go there.

I haven't seen anything on xcode-users for a couple of days. Mail sent to 
, assuming that that server does not comply with 
the RFC requiring postmaster addresses to be ignored.

— F


-- 
Fritz Anderson -- Xcode 4 Unleashed -- 


___

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

ASIFormDataRequest doesn't fetch responseString

2012-08-30 Thread Kévin Vavelin 
Hi there,

I try to fetch a responseString from my request and I just can't get it working 
well… Everything is good but my request is send in asynchronous mode and I used 
block for fetching my string. This method doesn't working well so I ask you if 
you can help me more ;)

Here's the code :

__block ASIFormDataRequest *request = [ASIFormDataRequest 
requestWithURL:[NSURL 
URLWithString:@"http://accident.monautosurlenet.fr/Handlers/IOS/Upload.ashx";]];
[request setDelegate:self];
[request setCompletionBlock:^{
NSString *string = [request responseString];
NSLog(@"%@", string);
}];
//adding my data
[request startAsynchronous];

Do you have an idea ?


Best regards,
Vavelin Kévin
Twitter | Blog | LinkedIn 
Entrepreneur
Developer OS X / iOS

___

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: Sandboxing die.die.die

2012-08-30 Thread Jeffrey Oleander 
Sandboxing die.die.die
Code-Signing die.die.die
Javascript die.die.die
Kludgey CPUs die.die.die
Bodyshopping die.die.die
(throwing hammer at hare-brained power-mad forces of evil)

Now, when can we cut the chains and get back to developing great apps?
___

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: Sandboxing die.die.die

2012-08-30 Thread zav 
Easy. When the exact items that we have issues with are addressed.

It's not that hard. Listen to the developers and fix what causes the most 
problems for them. 

You satisfy their needs and as a result have developers creating great apps 
easier and faster.

If you don't do this, then the focus from management is in the wrong place.


Sent from my Verizon Wireless BlackBerry

-Original Message-
From: Jeffrey Oleander 
Sender: cocoa-dev-bounces+zav=mac.com@lists.apple.comDate: Thu, 30 Aug 2012 
13:57:44 
To: 
Subject: Re: Sandboxing die.die.die

Sandboxing die.die.die
Code-Signing die.die.die
Javascript die.die.die
Kludgey CPUs die.die.die
Bodyshopping die.die.die
(throwing hammer at hare-brained power-mad forces of evil)

Now, when can we cut the chains and get back to developing great apps?
___

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/zav%40mac.com

This email sent to z...@mac.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: Sandboxing die.die.die

2012-08-30 Thread davelist 

But you're tilting at windmills here. This is not an official support channel. 
File Radars. And yes, we've had enough arguing about the effectiveness of doing 
that. You've spent far more time here and on the Xcode list complaining about 
losing fractions of a seconds waiting for animations to complete, etc. The time 
you lost there is minuscule in comparison to the time you've spent complaining 
about the issues on these mailing lists which does no good.

And many of us lose more than those fractions of a second hitting delete every 
time we see that one of your messages is just a rant.

Dave


On Aug 30, 2012, at 6:09 PM, z...@mac.com wrote:

> Easy. When the exact items that we have issues with are addressed.
> 
> It's not that hard. Listen to the developers and fix what causes the most 
> problems for them. 
> 
> You satisfy their needs and as a result have developers creating great apps 
> easier and faster.
> 
> If you don't do this, then the focus from management is in the wrong place.
> 
> 
> Sent from my Verizon Wireless BlackBerry
> 
> -Original Message-
> From: Jeffrey Oleander 
> Sender: cocoa-dev-bounces+zav=mac.com@lists.apple.comDate: Thu, 30 Aug 2012 
> 13:57:44 
> To: 
> Subject: Re: Sandboxing die.die.die
> 
> Sandboxing die.die.die
> Code-Signing die.die.die
> Javascript die.die.die
> Kludgey CPUs die.die.die
> Bodyshopping die.die.die
> (throwing hammer at hare-brained power-mad forces of evil)
> 
> Now, when can we cut the chains and get back to developing great apps?

___

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: CoreData UIManagedDocument saving/closing questions

2012-08-30 Thread davelist 

I asked the question in quote email two days ago with no response so let me try 
a related, but perhaps more concise/simpler question:

Is it even necessary to call -saveToURL:forSaveOperation:completionHandler in a 
UIManagedDocument subclass or will its autosaving mechanism take care of that 
at all times, including requesting extra time with a [[UIApplication 
sharedApplication] beginBackgroundTaskWithExpirationHandler: block when 
necessary. 

In other words, can I remove all calls to 
-saveToURL:forSaveOperation:completionHandler other than the one used to create 
a new file? I am not currently using iCloud.

The symptom I'm seeing is about 1% of the people who have purchased my app are 
losing the data files (they seem to have zero size). I can't reproduce it and 
I've been using the app for 8 months while developing it without ever seeing 
this. I don't know if it's a save issue or if perhaps something such as a 
required entity attribute not getting set that is leading to the zero length 
file.

I would be extremely grateful for any suggestions on how to track this down as 
I've temporarily pulled the app from the store until I can figure this out.

Thanks,
Dave



On Aug 28, 2012, at 10:17 PM, davel...@mac.com wrote:

> 
> This is on iOS 5 and higher. 
> 
> I have an iOS app that can open separate data files (one open at a time) 
> using a UIManagedDocument subclass. 
> 
> When I do a -saveToURL:forSaveOperation:completionHandler
> 
> do I need to that inside a: 
> 
> [[UIApplication sharedApplication] beginBackgroundTaskWithExpirationHandler:
> 
> block in case the application enters the background and will be terminated 
> before the save operation completes? Or does UIManagedDocument take care of 
> that for me?
> 
> Also, my app delegate's
> 
> - (void)applicationDidEnterBackground:(UIApplication *)application
> 
> do I need to call:
> 
> - (void)closeWithCompletionHandler:(void (^)(BOOL success))completionHandler
> 
> 
> and then reopen it in:
> 
> - (void)applicationWillEnterForeground:(UIApplication *)application
> 
> 
> Or can I just call:
> 
> -saveToURL:forSaveOperation:completionHandler
> 
> in 
> 
> - (void)applicationDidEnterBackground:(UIApplication *)application
> 
> without worrying about closing the file if the app is later terminated?
> 
> Thanks,
> Dave
> 
> ___
> 
> 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/davelist%40mac.com
> 
> This email sent to davel...@mac.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: IKImageBrowseView and QuickLook panel

2012-08-30 Thread Graham Cox 

Hi all,

According to the documentation for IKImageBrowserView:

> setCanControlQuickLookPanel:
> Specifies whether the view can automatically take control of the QuickLook 
> panel.
> 
> - (void)setCanControlQuickLookPanel:(BOOL)flag
> Parameters
> flag
> YES, if the view can display the QuickLook panel, otherwise NO.
> Discussion
> When the browser view displays the QuickLook panel it sets itself as the 
> QuickLook datasource. If the browser cells returned by the datasource return 
> items that are URLs or paths, then the QuickLook panel will display the image 
> at that location. Otherwise, the browser cell must implement theQLPreviewItem 
> protocol and return the requested URL for the custom cell.


My browser cells do return image URLs most of the time, and the QuickLook panel 
shows the image. I call -setCanControlQuickLookPanel with YES to enable this.

However, if the file that the cell refers to is an SVG file, I asynchronously 
parse the SVG to generate a thumbnail and return it to the browser as an 
NSImage instead. That works - my browser item returns the correct 
imageRepresentationType according to what sort of file it's dealing with.

However, SVG images are not displaying in the QL panel.

According to the documentation quoted, if my cells do NOT return a URL, I need 
to implement the QLPreviewItem protocol in order to return a URL directly. I do 
this, but the protocol method -previewItemURL is never called and the panel 
doesn't show the image, just an endlessly rotating 'waiting' thingy.

Is the documentation wrong? Has anyone made anything like this work?

I noticed an issue related to this where my browser view items were being 
passed some other object class to the -isEqual: method. Because these were a 
different class they didn't respond to a selector I use to compare the items 
(specifically, the -imageUID). I fixed that by checking it responds to 
selector, but it was a bit suspicious that the IKImageBrowserView was using a 
mix of objects internally, not just the items I had passed to it. Might be 
legit though, but not having the source to the browser view, I just don't know.

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