Re: Crash with UITableView reloadRowsAtIndexPaths:withRowAnimation:

[Luke Hiesterman]

You need to read the actual exception message. It's almost certainly telling 
you that the number of rows in the dataSource is different than what's expected 
based on the updates you've made. 

Luke

On Aug 21, 2012, at 11:49 PM, "Laurent Daudelin"  
wrote:

> iOS 5.0 simulator or device.
> 
> When I call this method like this:
>[[NSOperationQueue mainQueue] addOperationWithBlock:^{
>[self.tableView reloadRowsAtIndexPaths:[NSArray 
> arrayWithObjects:
>[NSIndexPath 
> indexPathForRow:0 inSection:0],
>[NSIndexPath 
> indexPathForRow:1 inSection:0],
>[NSIndexPath 
> indexPathForRow:2 inSection:0],
>[NSIndexPath 
> indexPathForRow:3 inSection:0],
>nil]
>  
> withRowAnimation:UITableViewRowAnimationNone];
>}];
> 
> the app crashes with a SIGTRAP:
> 2012-08-21 23:48:05.173 Erodr[15594:c07] *** Assertion failure in 
> -[UITableView _endCellAnimationsWithContext:], 
> /SourceCache/UIKit_Sim/UIKit-1912.3/UITableView.m:1046
> 
> However, if I send the same tableview reloadData, then all is fine.
> 
> What's wrong with my reloadRowsAtIndexPath:withRowAnimations:?
> 
> -Laurent.
> -- 
> Laurent Daudelin
> AIM/iChat/Skype:LaurentDaudelinhttp://www.nemesys-soft.com/
> Logiciels Nemesys Softwarelaur...@nemesys-soft.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/luketheh%40apple.com
> 
> This email sent to luket...@apple.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: Crash with UITableView reloadRowsAtIndexPaths:withRowAnimation:

[Laurent Daudelin]

Well, it's a little complicated. There are 2 sections in the table view. The 
first section has 4 cells always, no more, no less. They like static but since 
the second section of the tableview is dynamic, I cannot make the tableview 
with static cells. So, when I get the information to display in those 4 cells, 
I thought to call the reloadRowsAtIndexPath:withRowAnimation:. Note that I'm 
not adding or removing cells. Its just that when the tableview appears, the 
data hasn't been received from the server. I just wanted to minimize the reload 
that the table view would have to do because the second section is dynamic and 
when I get the data for the first section, I query the server for the data of 
the second section, so when I have the data for the cells in section 1, I just 
want to reload that section.

Is there something wrong in my reasoning? Since the connection to the server is 
asynchronous, it is possible that I might be changing the number of rows in 
section 2, but I'm only trying here to reload section 1. Maybe my reasoning is 
wrong, that would explain why it fails.

-Laurent.
-- 
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin 
http://www.nemesys-soft.com/
Logiciels Nemesys Software  
laur...@nemesys-soft.com

On Aug 22, 2012, at 00:02, Luke Hiesterman  wrote:

> You need to read the actual exception message. It's almost certainly telling 
> you that the number of rows in the dataSource is different than what's 
> expected based on the updates you've made. 
> 
> Luke
> 
> On Aug 21, 2012, at 11:49 PM, "Laurent Daudelin"  
> wrote:
> 
>> iOS 5.0 simulator or device.
>> 
>> When I call this method like this:
>>   [[NSOperationQueue mainQueue] addOperationWithBlock:^{
>>   [self.tableView reloadRowsAtIndexPaths:[NSArray 
>> arrayWithObjects:
>>   [NSIndexPath 
>> indexPathForRow:0 inSection:0],
>>   [NSIndexPath 
>> indexPathForRow:1 inSection:0],
>>   [NSIndexPath 
>> indexPathForRow:2 inSection:0],
>>   [NSIndexPath 
>> indexPathForRow:3 inSection:0],
>>   nil]
>> 
>> withRowAnimation:UITableViewRowAnimationNone];
>>   }];
>> 
>> the app crashes with a SIGTRAP:
>> 2012-08-21 23:48:05.173 Erodr[15594:c07] *** Assertion failure in 
>> -[UITableView _endCellAnimationsWithContext:], 
>> /SourceCache/UIKit_Sim/UIKit-1912.3/UITableView.m:1046
>> 
>> However, if I send the same tableview reloadData, then all is fine.
>> 
>> What's wrong with my reloadRowsAtIndexPath:withRowAnimations:?
>> 
>> -Laurent.
>> -- 
>> Laurent Daudelin
>> AIM/iChat/Skype:LaurentDaudelinhttp://www.nemesys-soft.com/
>> Logiciels Nemesys Softwarelaur...@nemesys-soft.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/luketheh%40apple.com
>> 
>> This email sent to luket...@apple.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: Implementing Manual KVO For Bitfields Set in Atomic Operations

[Andreas Grosam]

On 21.08.2012, at 22:35, Quincey Morris wrote:

> This doesn't make sense as it stands. You've declared properties that need 
> setters as well as getters, and the setters (which you didn't show code for) 
> will give you KVO compliance without any explicit will/didChanging.
Well, the description says it all, I think ;)

I put the "code" in only for illustration. Stupidly, I didn't wrote the 
property declaration correctly (just typed into mail). 

However, I think the text clearly states that I want to *retrieve* a *bool* 
value from *several* properties where the value for each property will be 
deduced from a set of bits from a common variable. The snippets show how the 
*getters* are implemented and how I set the ivar _state. There are no setters. 


The correct public property declaration should be:

@property (nonatomic, readonly) BOOL isFoo;
@property (nonatomic, readonly) BOOL isBar;

> 
> The only reason for coding will/didChange explicitly would be if you need to 
> do an end run around the setters -- either because you wish to coalesce 
> notifications for multiple property changes, or because you want to change 
> sets of bits that don't map directly to single properties.
With respect, there are other reasons, too. For example, you need to implement 
these methods manually if the property is declared in a super class and if that 
super class does not support KVO. An example would be property "isExecuting" 
from NSOperation if you implement a concurrent operation. In fact, I'm trying 
to implement the *required* manual KVO compliance in a subclass of NSOperation.

Another reason is, if you have a property that derives its value r from a 
function f(x) for which there is no inverse function f-1  (f, in a mathematical 
sense). In this case, there is no corresponding setter, since this function f 
is *not invertible*.

Example:

bool f(int x) {
return (x & 0x03) != 0;
}

This function f(x) is not bijective, that is there exists no invertible 
function. Or, in other words, given an output value r you cannot find a unique 
corresponding input x.


@property (readonly) R foo;

-(R) foo { return f(_x); }  

Since, f(x) is not bijective, then there is no:
-(void) setFoo:(R)r { ?? }


So in this case, when _x changes, I need to implement manual KVO.


This is exactly the problem I have, and which I described in my first post. The 
implementation of property getter -bar shows, that its function is not 
invertible. Thus, there can be no setter like:
-(void)setBar:(BOOL) 

and KVO needs to be implemented manually, when the dependent variable _state 
changes.


> Either way, KVO notifications are never "inside" the atomicity of the 
> properties, which means that the values passed in the notification (old or 
> new value) won't necessarily have any meaning in a multi-threaded environment.
Yes, and this is not what I strive to accomplish. Especially, I don't try to 
manage concurrency with KVO! I'm totally aware that when retrieving a state, it 
can already be stale. 

> It might be fine just to call both willChange and didChange after the bits 
> are actually changed.
OK, that's what my question was all about. If I do this, I especially don't 
want to receive change notifications when the state did not actually change, 
and furthermore, that the change dictionary in the notification method is 
correctly setup.

> 
> I have to mention, though, that it looks a bit like you're implementing 
> atomicity where you really need thread safety. But that may be just because 
> of details you've left out of your example code.

Atomic access is one approach which *may* ensure thread-safety, but it may not 
always effectual. In my case it is sufficient to access shared resources via 
atomic operations (it's just the _state ivar). 

The other reason using atomic operations is to prevent a method to be executed 
when the prerequisite of the current state is not given. Taken together, this 
makes the system thread safe.


Hopefully, I could express my problem more clearly.

Many Thanks for your input!


Regards
Andreas



___

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: iOS IB Object

[Fritz Anderson]

On 22 Aug 2012, at 12:03 AM, koko  wrote:

> I put an Object (the orange cube) into my xib and set its custom class.
> 
> I connected an action in the custom class to a UIButton.
> 
> Sometimes the action is called when the button is clicked but most of the  
> time there is a crash .. unrecognized selector sent to instance …hmm?
> 
> Wanting to move ahead I moved the action into a UIView and presto no more 
> crash.
> 
> I do this for OSX, use the blue object cube, assign custom class, connect 
> actions and outlets and all works feel.
> 
> So, what doI not know about iOS and a similar process? It is like the custom 
> class object does not exist.

If you don't retain a top-level NIB object in iOS, sooner or later it _won't_ 
exist. They are retain/autoreleased upon load, and if there is no strong 
reference, they get deallocated.

See 

 and search for "Managing Nib Objects in iOS."

— F


___

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: Implementing Manual KVO For Bitfields Set in Atomic Operations

[Scott A Andrew]

Why not have an update flags function and a set of booleans that represent the 
flags.


@interface someInterface {
   BOOL _isFoo;
   BOOL _isBar;
}

@property (nonatomic, readonly, assign) BOOL isFoo;
@property (nonatomic, readonly, assign) BOOL isBar;

-(void) updateFlags:(int)bits;

@end


Then in your m file.

@interface someInterface()

// these you can set in update flags to trigger KVO
@property (nonatomic, readwrite, assign) BOOL isFoo;
@property (nonatomic, readwrite, assign) BOOL isBar;

@end

@implement someInterface
@synthesize isFoo = _isFoo;
@synthesize isBar = _isBar;

-(void) updateFlags:(int)bits {
   BOOL newFoo = (flags & 0x3) != 0;

   if ((newFoo) != self.isFoo)
   self.isFoo = newFoo;

...
}

I wouldn't really worry about KVO being fired if value hasn't changed, unless 
its changing a lot. When ever the int changes you can call into updateFlags to 
update the BOOLs as needed which then fires off the KVO. You can use a 
temporary bool to check old against new if you want to selectively cause firing 
based on what has changed.

Scott

On Aug 22, 2012, at 3:31 AM, Andreas Grosam  wrote:

> 
> On 21.08.2012, at 22:35, Quincey Morris wrote:
> 
>> This doesn't make sense as it stands. You've declared properties that need 
>> setters as well as getters, and the setters (which you didn't show code for) 
>> will give you KVO compliance without any explicit will/didChanging.
> Well, the description says it all, I think ;)
> 
> I put the "code" in only for illustration. Stupidly, I didn't wrote the 
> property declaration correctly (just typed into mail). 
> 
> However, I think the text clearly states that I want to *retrieve* a *bool* 
> value from *several* properties where the value for each property will be 
> deduced from a set of bits from a common variable. The snippets show how the 
> *getters* are implemented and how I set the ivar _state. There are no 
> setters. 
> 
> 
> The correct public property declaration should be:
> 
> @property (nonatomic, readonly) BOOL isFoo;
> @property (nonatomic, readonly) BOOL isBar;
> 
>> 
>> The only reason for coding will/didChange explicitly would be if you need to 
>> do an end run around the setters -- either because you wish to coalesce 
>> notifications for multiple property changes, or because you want to change 
>> sets of bits that don't map directly to single properties.
> With respect, there are other reasons, too. For example, you need to 
> implement these methods manually if the property is declared in a super class 
> and if that super class does not support KVO. An example would be property 
> "isExecuting" from NSOperation if you implement a concurrent operation. In 
> fact, I'm trying to implement the *required* manual KVO compliance in a 
> subclass of NSOperation.
> 
> Another reason is, if you have a property that derives its value r from a 
> function f(x) for which there is no inverse function f-1  (f, in a 
> mathematical sense). In this case, there is no corresponding setter, since 
> this function f is *not invertible*.
> 
> Example:
> 
> bool f(int x) {
>return (x & 0x03) != 0;
> }
> 
> This function f(x) is not bijective, that is there exists no invertible 
> function. Or, in other words, given an output value r you cannot find a 
> unique corresponding input x.
> 
> 
> @property (readonly) R foo;
> 
> -(R) foo { return f(_x); }  
> 
> Since, f(x) is not bijective, then there is no:
> -(void) setFoo:(R)r { ?? }
> 
> 
> So in this case, when _x changes, I need to implement manual KVO.
> 
> 
> This is exactly the problem I have, and which I described in my first post. 
> The implementation of property getter -bar shows, that its function is not 
> invertible. Thus, there can be no setter like:
> -(void)setBar:(BOOL) 
> 
> and KVO needs to be implemented manually, when the dependent variable _state 
> changes.
> 
> 
>> Either way, KVO notifications are never "inside" the atomicity of the 
>> properties, which means that the values passed in the notification (old or 
>> new value) won't necessarily have any meaning in a multi-threaded 
>> environment.
> Yes, and this is not what I strive to accomplish. Especially, I don't try to 
> manage concurrency with KVO! I'm totally aware that when retrieving a state, 
> it can already be stale. 
> 
>> It might be fine just to call both willChange and didChange after the bits 
>> are actually changed.
> OK, that's what my question was all about. If I do this, I especially don't 
> want to receive change notifications when the state did not actually change, 
> and furthermore, that the change dictionary in the notification method is 
> correctly setup.
> 
>> 
>> I have to mention, though, that it looks a bit like you're implementing 
>> atomicity where you really need thread safety. But that may be just because 
>> of details you've left out of your example code.
> 
> Atomic access is one approach which *may* ensure thread-safety, but it may 
> not alway

Re: Sandboxing die.die.die

[Alex Zavatone]

Regarding Sandboxing on Mac OS or iOS, the situations I want to see addressed 
are these:

The app gets regularly updated.  Preferences must exist out side of the app.  
What easy and straightforward method that does not require the developer to 
jump through hoops supports preservation of app preferences when an app may be 
deleted or upgraded WITHOUT using "the cloud", as this is completely in 
violation of many companies' policies.

If you never ever submit apps to the app store, or you have your own managed 
app store and develop apps solely for the enterprise, and never mass market 
apps, then be it on iOS or Mac OS, you are expected to have access outside of 
the sandbox.  It is expected that you will have access to the device and 
different folders to create useful software.

Honestly, Sandboxing seems to be created by people who have written a few 
papers on security.  But the implications of Sandboxing mean that there will be 
less documentation for people to refer to and the restrictions placed on the 
developers mean that files in supported folders will be co-opted to serve as 
cookies or data structures that will outlast an app's deletion, thereby already 
bypassing the restrictions Apple is trying to impose.

Apple has created a royal PITA for developers who don't care about submitting 
apps to the general public, both on iOS and on Mac OS and created a much less 
useful environment in the process.  
 
If Apple limited the restricted folders to the System and Library folders off 
the root, this would be a whole lot less of a PITA.  Just let us write to the 
drive outside of the folders that contain the precious internal important bits. 
 Stop handcuffing your developers.



On Aug 22, 2012, at 2:54 AM, Kyle Sluder wrote:

> On Aug 21, 2012, at 11:02 PM, Jens Alfke  wrote:
> 
>> 
>> But then, I haven't tried sandboxing yet. It sounds almost like some 
>> exquisite form of BDSM: taking away all of your freedom and then making you 
>> beg to get little bits back. Does it come with safe-words?
> 
> Irrespective of everything else, this is indeed the model for sandboxing. 
> Because "you" is not normally synonymous with "the user", and the industry 
> has awoken to the reality that the user can not trust your motives to be 
> pure. Because in the face of a successful attack, "you" might not be the 
> author of the executing code either.
> 
> --Kyle Sluder
> ___
> 
> 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

[Jayson Adams]

On Aug 21, 2012, at 11:54 PM, Kyle Sluder  wrote:

> On Aug 21, 2012, at 11:02 PM, Jens Alfke  wrote:
> 
>> 
>> But then, I haven't tried sandboxing yet. It sounds almost like some 
>> exquisite form of BDSM: taking away all of your freedom and then making you 
>> beg to get little bits back. Does it come with safe-words?
> 
> Irrespective of everything else, this is indeed the model for sandboxing. 
> Because "you" is not normally synonymous with "the user", and the industry 
> has awoken to the reality that the user can not trust your motives to be 
> pure. Because in the face of a successful attack, "you" might not be the 
> author of the executing code either.

Ah, that explains why all of Apple's apps are sandboxed  Right.

__jayson
___

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

[Kyle Sluder]

On Aug 22, 2012, at 8:29 AM, Jayson Adams  wrote:

> 
> Ah, that explains why all of Apple's apps are sandboxed  Right.

The big ones are: Mail, Safari, Preview.

There have been legitimate problems with the rollout of sandboxing. It doesn't 
support certain interactions that are fundamental to some apps, and yet it was 
forced upon them by the MAS. Sandboxing errors are opaque, and code signing is 
cryptic.

But arguing against the basic premise of sandboxing is a fruitless endeavor. 
The user cannot and should not be forced to trust you to do the right thing.

--Kyle Sluder
___

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

[Alex Zavatone]

On Aug 22, 2012, at 11:40 AM, Kyle Sluder wrote:

> On Aug 22, 2012, at 8:29 AM, Jayson Adams  wrote:
> 
>> 
>> Ah, that explains why all of Apple's apps are sandboxed  Right.
> 
> The big ones are: Mail, Safari, Preview.
> 
> There have been legitimate problems with the rollout of sandboxing. It 
> doesn't support certain interactions that are fundamental to some apps, and 
> yet it was forced upon them by the MAS. Sandboxing errors are opaque, and 
> code signing is cryptic.
> 
> But arguing against the basic premise of sandboxing is a fruitless endeavor. 
> The user cannot and should not be forced to trust you to do the right thing.
> 
> --Kyle Sluder

Actually Kyle, when you're not catering to the mass market, but targeted 
clients, the user requires you to do the right thing.  

___

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

[Kyle Sluder]

On Aug 22, 2012, at 8:52 AM, Alex Zavatone  wrote:

> 
> Actually Kyle, when you're not catering to the mass market, but targeted 
> clients, the user requires you to do the right thing.  

And the OS enforceS that requirement on their behalf by sandboxing.

Thankfully we have Developer ID to provide an escape hatch and alternate 
distribution mechanism while the sandboxing implementation is fixed, but the 
basic concept of sandboxing is not going anywhere.

--Kyle Sluder

___

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

[Derek Chesterfield]

They can *expect* that you will do the right thing. But they can't be expected 
to *know* that you really are. 

On 22 Aug 2012, at 16:52, Alex Zavatone  wrote:

> 
> On Aug 22, 2012, at 11:40 AM, Kyle Sluder wrote:
> 
>> On Aug 22, 2012, at 8:29 AM, Jayson Adams  wrote:
>> 
>>> 
>>> Ah, that explains why all of Apple's apps are sandboxed  Right.
>> 
>> The big ones are: Mail, Safari, Preview.
>> 
>> There have been legitimate problems with the rollout of sandboxing. It 
>> doesn't support certain interactions that are fundamental to some apps, and 
>> yet it was forced upon them by the MAS. Sandboxing errors are opaque, and 
>> code signing is cryptic.
>> 
>> But arguing against the basic premise of sandboxing is a fruitless endeavor. 
>> The user cannot and should not be forced to trust you to do the right thing.
>> 
>> --Kyle Sluder
> 
> Actually Kyle, when you're not catering to the mass market, but targeted 
> clients, the user requires you to do the right thing.  
> 
> ___
> 
> 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/dez%40mac.com
> 
> This email sent to d...@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

iOS 5.0.1 vs. 5.1.x and MapKit Overlays.

[Alex Zavatone]

We've been able to track down a significant performance hit in drawing PNG map 
overlays on iOS devices, but only on iOS 5.1.x, while they rendered out rather 
quickly on iPads and iPods, but as soon as the mapKit overlay is drawn on a 
device running 5.1.x, the image simply chunks out over up to 13 seconds, where 
it would take 2 on under 5.0.1.

Has anyone seen this before?

Also, the rect size of the overlay drawing appears to have changed to a much 
smaller size with no code change on my part simply by running the app on a 
5.1.1 device.

Is there any way to specify the size of the size of the blocks that mapKit uses 
to chunk out the drawing of the overlay, or is this all figured out internally?

Of course there's a better method out there for doing what I'm doing, but I 
never expected performance to go from 2 seconds to 13 seconds simply by 
upgrading the OS.  

If any one wants to see this, I'll take and post a video, but this might block 
the ship of our product internally to about 7,500 people, so I'm a little 
interested in finding out how to resolve it.

TIA.
___

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

[Scott Ribe]

On Aug 22, 2012, at 9:52 AM, Alex Zavatone wrote:

> Actually Kyle, when you're not catering to the mass market, but targeted 
> clients, the user requires you to do the right thing.  

For some of us, that even includes contracts which put actual liability on us 
for failures, and require us to carry 7 figures' worth of insurance to cover 
that liability. So yes, in some cases, the user (and insurer) absolutely 
expects us to do the right thing.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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

[Alex Zavatone]

On Aug 22, 2012, at 12:00 PM, Kyle Sluder wrote:

> On Aug 22, 2012, at 8:52 AM, Alex Zavatone  wrote:
> 
>> 
>> Actually Kyle, when you're not catering to the mass market, but targeted 
>> clients, the user requires you to do the right thing.  
> 
> And the OS enforceS that requirement on their behalf by sandboxing.

Actually, it creates much more problems for us than it solves and forces us to 
bypass the sandbox, resulting in additional costs to our company that easily 
reach into the tens of thousands of dollars.

> Thankfully we have Developer ID to provide an escape hatch and alternate 
> distribution mechanism while the sandboxing implementation is fixed, but the 
> basic concept of sandboxing is not going anywhere.
> 

How does this help?

> --Kyle Sluder

___

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

[Alex Zavatone]

On Aug 22, 2012, at 12:01 PM, Derek Chesterfield wrote:

> They can *expect* that you will do the right thing. But they can't be 
> expected to *know* that you really are. 

Well, if I don't, I get fired.  That's enough motivation for me.


> On 22 Aug 2012, at 16:52, Alex Zavatone  wrote:
> 
>> 
>> On Aug 22, 2012, at 11:40 AM, Kyle Sluder wrote:
>> 
>>> On Aug 22, 2012, at 8:29 AM, Jayson Adams  wrote:
>>> 
 
 Ah, that explains why all of Apple's apps are sandboxed  Right.
>>> 
>>> The big ones are: Mail, Safari, Preview.
>>> 
>>> There have been legitimate problems with the rollout of sandboxing. It 
>>> doesn't support certain interactions that are fundamental to some apps, and 
>>> yet it was forced upon them by the MAS. Sandboxing errors are opaque, and 
>>> code signing is cryptic.
>>> 
>>> But arguing against the basic premise of sandboxing is a fruitless 
>>> endeavor. The user cannot and should not be forced to trust you to do the 
>>> right thing.
>>> 
>>> --Kyle Sluder
>> 
>> Actually Kyle, when you're not catering to the mass market, but targeted 
>> clients, the user requires you to do the right thing.  
>> 
>> ___
>> 
>> 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/dez%40mac.com
>> 
>> This email sent to d...@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

[Kyle Sluder]

On Aug 22, 2012, at 9:26 AM, Alex Zavatone  wrote:

> 
> On Aug 22, 2012, at 12:01 PM, Derek Chesterfield wrote:
> 
>> They can *expect* that you will do the right thing. But they can't be 
>> expected to *know* that you really are. 
> 
> Well, if I don't, I get fired.  That's enough motivation for me.

If fear of failure were enough to write bug-free code we could've replaced gdb 
with a firing squad a long time ago.

--Kyle Sluder
___

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

[Jayson Adams]

On Aug 22, 2012, at 8:40 AM, Kyle Sluder wrote:

> On Aug 22, 2012, at 8:29 AM, Jayson Adams  wrote:
> 
>> 
>> Ah, that explains why all of Apple's apps are sandboxed  Right.
> 
> The big ones are: Mail, Safari, Preview.

How about Finder? AddressBook?  Calendar? iPhoto?  Pages?  Numbers?  And. On. 
And. On.

> But arguing against the basic premise of sandboxing is a fruitless endeavor. 
> The user cannot and should not be forced to trust you to do the right thing.


I aren't arguing against that (not that I am in agreement either).  I am 
arguing against this statement:

> Because in the face of a successful attack, "you" might not be the author of 
> the executing code either.

That's Apple positioning for the reason behind sandboxing of developer apps but 
I mean really, if I'm a hacker I'm going to go after the biggest target out 
there (you know, Finder, AddressBook, Calendar, etc.).  I'm wouldn't waste my 
time with third-party apps when there are lots of other targets that come 
pre-installed on every single machine.

Best,


__jayson

Circus Ponies NoteBook - Introducing An App That Boosts Your Productivity
at Work or School, So You Get The Grades, Raises and Promotions You Want.

www.circusponies.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

[James Merkel]

Why not just codeSign an application? It will still will be able to be 
downloaded by anyone using the default security  setting: "Mac App Store and 
identified developers". It just won't be able to be in the App store (I guess).

Jim Merkel
___

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

[Alex Kac]

There are some MAS-only features such as Notification Center (I believe) and 
iCloud, so its quite nice to be able to use those features.

On Aug 22, 2012, at 2:42 PM, James Merkel  wrote:

> Why not just codeSign an application? It will still will be able to be 
> downloaded by anyone using the default security  setting: "Mac App Store and 
> identified developers". It just won't be able to be in the App store (I 
> guess).
> 
> Jim Merkel
> ___
> 
> 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/alex%40webis.net
> 
> This email sent to a...@webis.net

Alex Kac - President and Founder
Web Information Solutions, Inc.

“Don't forget until too late that the business of life is not business but 
living.”
-- B.C. Forbes,





___

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

[James Merkel]

Ok, for my particular application I don't see any need for iCloud or 
Notification center. For other applications, YMMV.

Jim Merkel

On Aug 22, 2012, at 12:51 PM, Alex Kac  wrote:

> There are some MAS-only features such as Notification Center (I believe) and 
> iCloud, so its quite nice to be able to use those features.
> 
> On Aug 22, 2012, at 2:42 PM, James Merkel  wrote:
> 
>> Why not just codeSign an application? It will still will be able to be 
>> downloaded by anyone using the default security  setting: "Mac App Store and 
>> identified developers". It just won't be able to be in the App store (I 
>> guess).
>> 
>> Jim Merkel
>> ___
>> 
>> 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/alex%40webis.net
>> 
>> This email sent to a...@webis.net
> 
> Alex Kac - President and Founder
> Web Information Solutions, Inc.
> 
> “Don't forget until too late that the business of life is not business but 
> living.”
> -- B.C. Forbes,
> 
> 
> 
> 


___

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

[Lee Ann Rucker]

On Aug 22, 2012, at 12:51 PM, Alex Kac wrote:

> There are some MAS-only features such as Notification Center (I believe) and 
> iCloud, so its quite nice to be able to use those features.

Notification Center is usable by any app; I'm using it and App Store isn't even 
a possibility at this point.
___

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

[Kyle Sluder]

On Wed, Aug 22, 2012, at 01:02 PM, Lee Ann Rucker wrote:
> Notification Center is usable by any app; I'm using it and App Store
> isn't even a possibility at this point.

I believe your app has to be code-signed. But any valid code signature
should work.

--Kyle Sluder
___

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

[James Merkel]

On Aug 22, 2012, at 1:27 PM, Kyle Sluder  wrote:

> On Wed, Aug 22, 2012, at 01:02 PM, Lee Ann Rucker wrote:
>> Notification Center is usable by any app; I'm using it and App Store
>> isn't even a possibility at this point.
> 
> I believe your app has to be code-signed. But any valid code signature
> should work.
> 
> --Kyle Sluder

However, I don't think you can self sign it can you?

Jim Merkel
___

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

[Stephane Sudre]

On Wed, Aug 22, 2012 at 5:18 PM, Alex Zavatone  wrote:
> Regarding Sandboxing on Mac OS or iOS, the situations I want to see addressed 
> are these:
>
> The app gets regularly updated.  Preferences must exist out side of the app.  
> What easy and straightforward method that does not require the developer to 
> jump through hoops supports preservation of app preferences when an app may 
> be deleted or upgraded WITHOUT using "the cloud", as this is completely in 
> violation of many companies' policies.
>
> If you never ever submit apps to the app store, or you have your own managed 
> app store and develop apps solely for the enterprise, and never mass market 
> apps, then be it on iOS or Mac OS, you are expected to have access outside of 
> the sandbox.  It is expected that you will have access to the device and 
> different folders to create useful software.

I don't see why you have to care about the Sandbox in the case you
describe. The only issue there could be so far at that time is you
would have to codesign/productsign your application/installation
packages for 10.8 and pay the Gatekeeper rent.

Moreover, Gatekeeper is so easy to work around when you have control
on the way your application is deployed (which you seem to have in the
case you describe) that you could even get away without
codesigning/productsigning your products for OS X 10.8.

___

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

[Graham Cox]

On 23/08/2012, at 1:18 AM, Alex Zavatone  wrote:

> Regarding Sandboxing on Mac OS or iOS, the situations I want to see addressed 
> are these:
> 
> The app gets regularly updated.  Preferences must exist out side of the app.  
> What easy and straightforward method that does not require the developer to 
> jump through hoops supports preservation of app preferences when an app may 
> be deleted or upgraded WITHOUT using "the cloud", as this is completely in 
> violation of many companies' policies.


Well, much as I hate the sandbox implementation (and note, that's the 
implementation, not necessarily the concept, though I believe that the concept 
as it stands isn't well thought-through) this particular aspect isn't a major 
factor.

Your preferences live in your sandbox, to which you have free access without 
jumping through any hoops, as long as you use the usual directory discovery 
APIs, or NSUserDefaults. Upgrades are not a problem. Deletion of an app could 
be a problem but AFAIK the sandbox for an app is not automatically deleted if 
you trash an app in Mac OS (in iOS, that's another thing, as you have only one 
means to trash an app and it deletes its sandbox). The sandbox itself is not 
inside your app bundle, it lives elsewhere, so you can trash the app and leave 
its sandbox behind. Since the sandbox is identified using the bundle ID, a new 
version of the app will inherit the old version's sandbox.

Where life is made difficult is with more general access to the file system, 
which is a perfectly legitimate thing to do. A user stores various media all 
over the file system and there is no reason why an app shouldn't have access to 
it. There are several "shoebox" type apps (iPhoto, iTunes, etc) that also 
manage media and it is perfectly reasonable for another app to want access to 
that data. Doing this in a manner that is consistent across OS versions, 
sandboxing, localizations and so on is extremely difficult if not impossible 
right now. Apple are severely handcuffing us on the sandboxing front, but are 
not giving anything back to sweeten the deal. If they provided a sanctioned API 
for accessing media consistently that would go a long way, for me at least, to 
accept sandboxing. Trying to work around this is proving impossible with the 
current sandbox implementation - there are too many opaque hacks in the system 
that mean you cannot trust the URLs you get from anywhere to actually point to 
the right place, and you also have to hard-code paths in your entitlements 
which are extremely fragile under both localisation and system updates. (For 
example, if I add a temporary entitlement to ~/Pictures/iPhoto Library, if that 
location changes, or is named differently, my app stops working. Note the name 
of the iPhoto Library did subtly change between 10.7 and 10.8 - the space is a 
different unicode character now).

The only bright spot in all of this is the fact that on Mac at least you have a 
channel other than the App Store to deliver apps, but since the App Store is 
responsible for 90% of our sales, it would be commercial suicide to leave it. 
So we're stuck.

The other aspect of this is that the way the App Store staff treat the 
developer in the face of sandboxing issues is seriously hurting developer 
relations and Apple's image. But that's a separate issue I suppose. I do 
remember a time when Apple's developer relations were second-to-none. Oddly, 
the company was on death's door at the time. Success (which we've all had a 
small part to play in) breeds contempt, it seems.

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

[Mike Abdullah]

On 22 Aug 2012, at 21:31, James Merkel wrote:

> 
> On Aug 22, 2012, at 1:27 PM, Kyle Sluder  wrote:
> 
>> On Wed, Aug 22, 2012, at 01:02 PM, Lee Ann Rucker wrote:
>>> Notification Center is usable by any app; I'm using it and App Store
>>> isn't even a possibility at this point.
>> 
>> I believe your app has to be code-signed. But any valid code signature
>> should work.
>> 
>> --Kyle Sluder
> 
> However, I don't think you can self sign it can you?

Yes you can. Apple recommend DeveloperID instead though these days. It’s $99, 
pretty easy. Just do it.


___

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

[Alex Zavatone]

Since the preferences folder lives in the app, the preferences are deleted when 
the app is deleted, or reinstalled.  That's what I've seen.

According to the docs, (and the scratch files in your /library folder if you 
use the simulator, everything is in the app and nowhere else.  If reality is 
different, I wonder why it conflicts with what the documentation says.

If "every app is an island", then I don't see how what you say an be true.  I 
hope you are right, however.

And restricting general access to the file system is a royal PITA.

On Aug 22, 2012, at 7:37 PM, Graham Cox wrote:

> 
> On 23/08/2012, at 1:18 AM, Alex Zavatone  wrote:
> 
>> Regarding Sandboxing on Mac OS or iOS, the situations I want to see 
>> addressed are these:
>> 
>> The app gets regularly updated.  Preferences must exist out side of the app. 
>>  What easy and straightforward method that does not require the developer to 
>> jump through hoops supports preservation of app preferences when an app may 
>> be deleted or upgraded WITHOUT using "the cloud", as this is completely in 
>> violation of many companies' policies.
> 
> 
> Well, much as I hate the sandbox implementation (and note, that's the 
> implementation, not necessarily the concept, though I believe that the 
> concept as it stands isn't well thought-through) this particular aspect isn't 
> a major factor.
> 
> Your preferences live in your sandbox, to which you have free access without 
> jumping through any hoops, as long as you use the usual directory discovery 
> APIs, or NSUserDefaults. Upgrades are not a problem. Deletion of an app could 
> be a problem but AFAIK the sandbox for an app is not automatically deleted if 
> you trash an app in Mac OS (in iOS, that's another thing, as you have only 
> one means to trash an app and it deletes its sandbox). The sandbox itself is 
> not inside your app bundle, it lives elsewhere, so you can trash the app and 
> leave its sandbox behind. Since the sandbox is identified using the bundle 
> ID, a new version of the app will inherit the old version's sandbox.
> 
> Where life is made difficult is with more general access to the file system, 
> which is a perfectly legitimate thing to do. A user stores various media all 
> over the file system and there is no reason why an app shouldn't have access 
> to it. There are several "shoebox" type apps (iPhoto, iTunes, etc) that also 
> manage media and it is perfectly reasonable for another app to want access to 
> that data. Doing this in a manner that is consistent across OS versions, 
> sandboxing, localizations and so on is extremely difficult if not impossible 
> right now. Apple are severely handcuffing us on the sandboxing front, but are 
> not giving anything back to sweeten the deal. If they provided a sanctioned 
> API for accessing media consistently that would go a long way, for me at 
> least, to accept sandboxing. Trying to work around this is proving impossible 
> with the current sandbox implementation - there are too many opaque hacks in 
> the system that mean you cannot trust the URLs you get from anywhere to 
> actually point to the right place, and you also have to hard-code paths in 
> your entitlements which are extremely fragile under both localisation and 
> system updates. (For example, if I add a temporary entitlement to 
> ~/Pictures/iPhoto Library, if that location changes, or is named differently, 
> my app stops working. Note the name of the iPhoto Library did subtly change 
> between 10.7 and 10.8 - the space is a different unicode character now).
> 
> The only bright spot in all of this is the fact that on Mac at least you have 
> a channel other than the App Store to deliver apps, but since the App Store 
> is responsible for 90% of our sales, it would be commercial suicide to leave 
> it. So we're stuck.
> 
> The other aspect of this is that the way the App Store staff treat the 
> developer in the face of sandboxing issues is seriously hurting developer 
> relations and Apple's image. But that's a separate issue I suppose. I do 
> remember a time when Apple's developer relations were second-to-none. Oddly, 
> the company was on death's door at the time. Success (which we've all had a 
> small part to play in) breeds contempt, it seems.
> 
> --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: Sandboxing die.die.die

[danchik]

A somewhat related question.  It seems that the gatekeeper is mostly 
concenrned with the signature on the installer package and not the software 
it installed.  If the package is signed by Apple Developer's Installer 
certificate, gate keeper does not complain (just askes to ok the 
installation) and then never sais anything about the app that was installed 
(though it is NOT signed by Apples Developer's Software certificate).


So is it important to sign the code as well and not just the package (from 
the usability and end user experience point of view)?



- Original Message - 
From: "Mike Abdullah" 

To: "James Merkel" 
Cc: 
Sent: Wednesday, August 22, 2012 4:44 PM
Subject: Re: Sandboxing die.die.die




On 22 Aug 2012, at 21:31, James Merkel wrote:



On Aug 22, 2012, at 1:27 PM, Kyle Sluder  wrote:


On Wed, Aug 22, 2012, at 01:02 PM, Lee Ann Rucker wrote:

Notification Center is usable by any app; I'm using it and App Store
isn't even a possibility at this point.


I believe your app has to be code-signed. But any valid code signature
should work.

--Kyle Sluder


However, I don't think you can self sign it can you?


Yes you can. Apple recommend DeveloperID instead though these days. It’s 
$99, pretty easy. Just do it.



___

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/danchik%40rebelbase.com

This email sent to danc...@rebelbase.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

[Graham Cox]

On 23/08/2012, at 10:02 AM, Alex Zavatone  wrote:

> Since the preferences folder lives in the app, the preferences are deleted 
> when the app is deleted, or reinstalled.  That's what I've seen.
> 
> According to the docs, (and the scratch files in your /library folder if you 
> use the simulator, everything is in the app and nowhere else.  If reality is 
> different, I wonder why it conflicts with what the documentation says.
> 
> If "every app is an island", then I don't see how what you say an be true.  I 
> hope you are right, however.
> 
> And restricting general access to the file system is a royal PITA.

Are you talking about iOS or Mac?

On iOS the sandbox *is* the app. On Mac it is not, so the results will be very 
different on the two platforms. In general, I'm talking about Mac. I've toyed 
with iOS development but haven't done anything in anger.

On Mac, an app's sandbox lives at ~/Library/Containers//...



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

text highlighting with CALayer and NSTextVew

[Koen van der Drift]

I'd like to add some custom text highlighting to my NSTextView, so I added the 
following code to the NSTextView init method:

CALayer *aLayer = [CALayer layer];
[self setWantsLayer: YES];
[self setLayer: aLayer];


Then I add the highlighting for a particular text range (aRange):

 self.layer.backgroundColor = CGColorCreateGenericRGB (0.2, 0.2, 0.1, 
1.0);
 self.layer.frame = [self.layoutManager boundingRectForGlyphRange: 
aRange inTextContainer: self.textContainer];

But it looks all garbled for the while view, not for the range, and I see the 
Xcode window text behind it.

What should I do to make this work?

attributes = [NSDictionary dictionaryWithObjectsAndKeys: [NSColor redColor, 
NSBackgroundColorAttributeName, nil]; 
[self layoutManager] addTemporaryAttributes: attributes forCharacterRange: 
aRange];  works, but I'd like to have some more control on how the text 
highlighting is drawn.


- Koen.


___

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

[Laurent Daudelin]

I think Graham is mostly talking about OS X while you are obviously on iOS, 
Alex….

-Laurent.
-- 
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin 
http://www.nemesys-soft.com/
Logiciels Nemesys Software  
laur...@nemesys-soft.com

On Aug 22, 2012, at 17:02, Alex Zavatone  wrote:

> Since the preferences folder lives in the app, the preferences are deleted 
> when the app is deleted, or reinstalled. That's what I've seen.
> 
> According to the docs, (and the scratch files in your /library folder if you 
> use the simulator, everything is in the app and nowhere else.  If reality is 
> different, I wonder why it conflicts with what the documentation says.
> 
> If "every app is an island", then I don't see how what you say an be true.  I 
> hope you are right, however.
> 
> And restricting general access to the file system is a royal PITA.
> 
> On Aug 22, 2012, at 7:37 PM, Graham Cox wrote:
> 
>> 
>> On 23/08/2012, at 1:18 AM, Alex Zavatone  wrote:
>> 
>>> Regarding Sandboxing on Mac OS or iOS, the situations I want to see 
>>> addressed are these:
>>> 
>>> The app gets regularly updated.  Preferences must exist out side of the 
>>> app.  What easy and straightforward method that does not require the 
>>> developer to jump through hoops supports preservation of app preferences 
>>> when an app may be deleted or upgraded WITHOUT using "the cloud", as this 
>>> is completely in violation of many companies' policies.
>> 
>> 
>> Well, much as I hate the sandbox implementation (and note, that's the 
>> implementation, not necessarily the concept, though I believe that the 
>> concept as it stands isn't well thought-through) this particular aspect 
>> isn't a major factor.
>> 
>> Your preferences live in your sandbox, to which you have free access without 
>> jumping through any hoops, as long as you use the usual directory discovery 
>> APIs, or NSUserDefaults. Upgrades are not a problem. Deletion of an app 
>> could be a problem but AFAIK the sandbox for an app is not automatically 
>> deleted if you trash an app in Mac OS (in iOS, that's another thing, as you 
>> have only one means to trash an app and it deletes its sandbox). The sandbox 
>> itself is not inside your app bundle, it lives elsewhere, so you can trash 
>> the app and leave its sandbox behind. Since the sandbox is identified using 
>> the bundle ID, a new version of the app will inherit the old version's 
>> sandbox.
>> 
>> Where life is made difficult is with more general access to the file system, 
>> which is a perfectly legitimate thing to do. A user stores various media all 
>> over the file system and there is no reason why an app shouldn't have access 
>> to it. There are several "shoebox" type apps (iPhoto, iTunes, etc) that also 
>> manage media and it is perfectly reasonable for another app to want access 
>> to that data. Doing this in a manner that is consistent across OS versions, 
>> sandboxing, localizations and so on is extremely difficult if not impossible 
>> right now. Apple are severely handcuffing us on the sandboxing front, but 
>> are not giving anything back to sweeten the deal. If they provided a 
>> sanctioned API for accessing media consistently that would go a long way, 
>> for me at least, to accept sandboxing. Trying to work around this is proving 
>> impossible with the current sandbox implementation - there are too many 
>> opaque hacks in the system that mean you cannot trust the URLs you get from 
>> anywhere to actually point to the right place, and you also have to 
>> hard-code paths in your entitlements which are extremely fragile under both 
>> localisation and system updates. (For example, if I add a temporary 
>> entitlement to ~/Pictures/iPhoto Library, if that location changes, or is 
>> named differently, my app stops working. Note the name of the iPhoto Library 
>> did subtly change between 10.7 and 10.8 - the space is a different unicode 
>> character now).
>> 
>> The only bright spot in all of this is the fact that on Mac at least you 
>> have a channel other than the App Store to deliver apps, but since the App 
>> Store is responsible for 90% of our sales, it would be commercial suicide to 
>> leave it. So we're stuck.
>> 
>> The other aspect of this is that the way the App Store staff treat the 
>> developer in the face of sandboxing issues is seriously hurting developer 
>> relations and Apple's image. But that's a separate issue I suppose. I do 
>> remember a time when Apple's developer relations were second-to-none. Oddly, 
>> the company was on death's door at the time. Success (which we've all had a 
>> small part to play in) breeds contempt, it seems.
>> 
>> --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

Re: Sandboxing die.die.die

[Alex Zavatone]

On Aug 22, 2012, at 8:12 PM, Graham Cox wrote:

> 
> 
> On 23/08/2012, at 10:02 AM, Alex Zavatone  wrote:
> 
>> Since the preferences folder lives in the app, the preferences are deleted 
>> when the app is deleted, or reinstalled.  That's what I've seen.
>> 
>> According to the docs, (and the scratch files in your /library folder if you 
>> use the simulator, everything is in the app and nowhere else.  If reality is 
>> different, I wonder why it conflicts with what the documentation says.
>> 
>> If "every app is an island", then I don't see how what you say an be true.  
>> I hope you are right, however.
>> 
>> And restricting general access to the file system is a royal PITA.
> 
> Are you talking about iOS or Mac?
> 

For the preferences issue, I am referring to iOS.


> On iOS the sandbox *is* the app. On Mac it is not, so the results will be 
> very different on the two platforms. In general, I'm talking about Mac. I've 
> toyed with iOS development but haven't done anything in anger.
> 
> On Mac, an app's sandbox lives at ~/Library/Containers//...
> 
> 
> 
> --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: Sandboxing die.die.die

[Todd Heberlein]

On Aug 22, 2012, at 4:37 PM, Graham Cox  wrote:

> Where life is made difficult is with more general access to the file system, 
> which is a perfectly legitimate thing to do. A user stores various media all 
> over the file system and there is no reason why an app shouldn't have access 
> to it.

Except this is how cyber espionage works.

The "Pretty Girls" calendar application is a Trojan horse that, upon reaching a 
certain date (i.e., after it is approved by Apple), starts reading your 
Word/Pages document and exfiltrating them off the system.

Or the "Special Draw" application has a vulnerability, a user reads in a 
malicious document, and a command & control agent is dropped on your system.

I put together a little demo and video demonstrating this last example (it's 
actually a dig at the antivirus/security industry):

Glowing Embers: The Myth of the Nation State Requirement
http://www.netsq.com/Podcasts/Data/2012/GlowingEmbers/


Unfortunately, I too have problems with the Mac App Store restrictions, 
including no privilege escalation, but I do not have a good solution to 
recommend. :-\

Todd

___

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

[koko]

On Aug 22, 2012, at 12:03 PM, Jayson Adams wrote:

> I'm wouldn't waste my time with third-party apps when there are lots of other 
> targets that come pre-installed on every single machine.

Here here.

We are dealing with the same issue as Graham and this is keeping one of our 
Apps out of the MAS for know.  I am anxiously awaiting Grahams's solution.

-koko

___

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

[Sean McBride]

On Thu, 23 Aug 2012 09:37:05 +1000, Graham Cox said:

>The only bright spot in all of this is the fact that on Mac at least you
>have a channel other than the App Store to deliver apps, but since the
>App Store is responsible for 90% of our sales, it would be commercial
>suicide to leave it. So we're stuck.

After reading your (well deserved) criticisms, I was going to say 'put your 
money where your mouth is', but I guess you can't.  :(  And that's telling.  
Apple knows they can get away with what they're doing.  Well, that's what 
happens when you lock yourself into a walled garden I guess. :(  It is a sad 
state of affairs, I agree.

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

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

[Yingshen Yu]

depends on what type of your installer is. 
For drag drop installation, you need sign the app.

-Jonny


在 2012-8-23，上午8:06，danchik  写道：

> A somewhat related question.  It seems that the gatekeeper is mostly 
> concenrned with the signature on the installer package and not the software 
> it installed.  If the package is signed by Apple Developer's Installer 
> certificate, gate keeper does not complain (just askes to ok the 
> installation) and then never sais anything about the app that was installed 
> (though it is NOT signed by Apples Developer's Software certificate).
> 
> So is it important to sign the code as well and not just the package (from 
> the usability and end user experience point of view)?
> 
> 
> - Original Message - From: "Mike Abdullah" 
> To: "James Merkel" 
> Cc: 
> Sent: Wednesday, August 22, 2012 4:44 PM
> Subject: Re: Sandboxing die.die.die
> 
> 
>> 
>> On 22 Aug 2012, at 21:31, James Merkel wrote:
>> 
>>> 
>>> On Aug 22, 2012, at 1:27 PM, Kyle Sluder  wrote:
>>> 
 On Wed, Aug 22, 2012, at 01:02 PM, Lee Ann Rucker wrote:
> Notification Center is usable by any app; I'm using it and App Store
> isn't even a possibility at this point.
 
 I believe your app has to be code-signed. But any valid code signature
 should work.
 
 --Kyle Sluder
>>> 
>>> However, I don't think you can self sign it can you?
>> 
>> Yes you can. Apple recommend DeveloperID instead though these days. It’s 
>> $99, pretty easy. Just do it.
>> 
>> 
>> ___
>> 
>> 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/danchik%40rebelbase.com
>> 
>> This email sent to danc...@rebelbase.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/yingshen.yu%40gmail.com
> 
> This email sent to yingshen...@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: Sandboxing die.die.die

[Yingshen Yu]

Besides, even if you use an installer, Mountain Lion is fine without app 
signed, however it still make sense to sign app to prevent your  app be 
modified by mal-ware or virus.

-Jonny


在 2012-8-23，上午8:06，danchik  写道：

> A somewhat related question.  It seems that the gatekeeper is mostly 
> concenrned with the signature on the installer package and not the software 
> it installed.  If the package is signed by Apple Developer's Installer 
> certificate, gate keeper does not complain (just askes to ok the 
> installation) and then never sais anything about the app that was installed 
> (though it is NOT signed by Apples Developer's Software certificate).
> 
> So is it important to sign the code as well and not just the package (from 
> the usability and end user experience point of view)?
> 
> 
> - Original Message - From: "Mike Abdullah" 
> To: "James Merkel" 
> Cc: 
> Sent: Wednesday, August 22, 2012 4:44 PM
> Subject: Re: Sandboxing die.die.die
> 
> 
>> 
>> On 22 Aug 2012, at 21:31, James Merkel wrote:
>> 
>>> 
>>> On Aug 22, 2012, at 1:27 PM, Kyle Sluder  wrote:
>>> 
 On Wed, Aug 22, 2012, at 01:02 PM, Lee Ann Rucker wrote:
> Notification Center is usable by any app; I'm using it and App Store
> isn't even a possibility at this point.
 
 I believe your app has to be code-signed. But any valid code signature
 should work.
 
 --Kyle Sluder
>>> 
>>> However, I don't think you can self sign it can you?
>> 
>> Yes you can. Apple recommend DeveloperID instead though these days. It’s 
>> $99, pretty easy. Just do it.
>> 
>> 
>> ___
>> 
>> 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/danchik%40rebelbase.com
>> 
>> This email sent to danc...@rebelbase.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/yingshen.yu%40gmail.com
> 
> This email sent to yingshen...@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: Sandboxing die.die.die

[Graham Cox]

On 23/08/2012, at 10:45 AM, Todd Heberlein  wrote:

>> Where life is made difficult is with more general access to the file system, 
>> which is a perfectly legitimate thing to do. A user stores various media all 
>> over the file system and there is no reason why an app shouldn't have access 
>> to it.
> 
> Except this is how cyber espionage works.
> 
> The "Pretty Girls" calendar application is a Trojan horse that, upon reaching 
> a certain date (i.e., after it is approved by Apple), starts reading your 
> Word/Pages document and exfiltrating them off the system.


Understood, but this is the problem with security in general - how to make 
something secure without inconveniencing legitimate use. It's a hard problem, 
look at how appalling airport "security" is for the 99.999% of legitimate 
users.

I'm not sure what the solution is, but I do feel that sandboxing as it has been 
implemented is a poor solution because it is inconveniencing legitimate use 
(and I mean use, not development, which is SERIOUSLY inconvenienced). Suddenly 
legitimate users who manage all their photos with iPhoto cannot quickly access 
those photos with our app because our app cannot access iPhoto's media. They 
are inconvenienced - they have to find some other way to get their photos into 
our app. It makes our app less useful than before.

I can't see how penalising these legitimate users to counter a hypothetical 
threat is striking the right balance.

Once "Pretty Girls" is detected for what it is, its certificate can be revoked 
and the problem gradually solves itself. If in the meantime the user had 
experienced data loss or damage then they should have known better than to 
trust the skanky app in the first place. Obviously that's not ideal but give me 
common sense over the Gulag any day. Note that because "Pretty Girls" got past 
Gatekeeper, they were probably MORE likely to trust it than if they had just 
exercised a sensible amount of caution in the first place. Gatekeeper is like 
the front door to your house, except automated to let anyone in who waves the 
right credentials at it. Then they're in your house. In real life I'd prefer to 
take a look at that person and decide for myself whether they can be trusted. I 
might get it wrong, but it was my decision. For social engineering attacks, 
like "Pretty Girls", the only solution is user education.

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

[Britt Durbrow]

I don't think that it's physically possible to resolve this issue - basically, 
we're trying to have our cake (er, have our security) and eat it too (er, use 
the functionality of the app).

Consider a 'shoebox' app that doesn't deal with run-of-the-mill media (photos, 
movies, etc)... let's say it manages CAD/CAM files - something that Apple won't 
have an API for. And it integrates into your CAD/CAM programs via plugins, and 
an intranet/internet/cloud document sharing system. By definition, the only 
behavioral difference between this app and a cyber-espionage-enabled app is 
where the data gets sent: the good app sends it to 
MyAwesomeCloudCollaborationSite.com, the bad app also sends it to 
EvilHaxorsGonnaSpyOnYou.com... and there's no programatic way to tell the 
difference between the two.

Or perhaps a more widespread target: an app that manages receipts and credit 
card data, no matter where in the file system they end up (email, PDFs, MS 
Office documents, whatnot), and integrates with a cloud system for 
collaborating with accountants, banks, the IRS, etc... again, the only way a 
good app differs from a bad one is who is on the other end of the network 
socket.

Security is always at odds with ease-of-use and functionality; and while an 
insecure system can be useless due to the inability to trust it, an overly 
secure system will be also useless because the security measures prevent it 
from doing it's job... so by demanding total security (all MAS apps must be 
sandboxed); Apple has also rendered an entire class of apps nonfunctional. Part 
of the rationale that I've heard for the current set of sandboxing requirements 
is that it protects unsophisticated users... who, unfortunately, are the very 
users who would need a cross-app shoebox system the most.

(note: due to that 90% sales figure, for the purposes of this discussion, I am 
considering not selling thru the MAS to be a non-option for economic reasons; 
even though technically speaking, as of today an unsandboxed-but-signed app 
works OK on a default install of Mountain Lion)
___

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

Issues with NSMutableOrderedSet moveObjectsAtIndexes:toIndex:

[Gordon Apple]

I¹m running into two issues with moving items in NSMutableOrderedSet:

1. To get around the non-functional autogenerated accessors for ordered sets
in CoreData, I use mutableOrderedSetValueForKey and call
moveObjectsAtIndexes:toIndex:.  Apparently this first removes the values,
then inserts them at the specified index.  Unfortunately, the former
triggers a KVO which causes an out or range exception at the receiver of the
notification, rather than waiting until both operations are executed.

2.  moveObjectsAtIndexes:toIndex: does not do what one would expect.
You would expect that the listed indexes would be moved to the specified
index location in the existing list.  That is not what it does.  Again, it
apparently removes them from the list first, then attempts to insert them at
the specified index location, which is now wrong if any of the moved items
are prior to the insert index.  Instead, to make it work right, you have to
figure out how many of the moved items are prior to the insert index, then
subtract that from the index to get the correct insert location.  Why wasn¹t
this built into the moveObjectsAtIndexes:toIndex: method?  You are making a
single call to do this and, IMHO, it should have moved the items to the
location specified in the original list, not the half-method post-removal
location.

___

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

[Graham Cox]

On 23/08/2012, at 9:37 AM, Graham Cox  wrote:

> Trying to work around this is proving impossible with the current sandbox 
> implementation - there are too many opaque hacks in the system that mean you 
> cannot trust the URLs you get from anywhere to actually point to the right 
> place, and you also have to hard-code paths in your entitlements which are 
> extremely fragile under both localisation and system updates. (For example, 
> if I add a temporary entitlement to ~/Pictures/iPhoto Library, if that 
> location changes, or is named differently, my app stops working. Note the 
> name of the iPhoto Library did subtly change between 10.7 and 10.8 - the 
> space is a different unicode character now).



Well, I spoke too soon, and have actually solved this problem. Whether it 
proves to be robust I can't say, but it wouldn't seem to be any worse than our 
un-sandboxed app in that respect.


Turns out the problem I was having with this is because of the behaviour of 
[NSURL fileURLWithPath:isDirectory:].

When I passed the path to the iPhoto database file (~/Pictures/iPhoto 
Library/Album.xml) the resulting URL was bizarrely altered to point to some 
non-existent path within my sandbox. In fact it looks like a bug because it 
ended up concatenating 'file://' somewhere in the middle of the path which 
makes no sense. Instead, I used [NSURL URLWithString:] and it works correctly.

I've also had to rev a fair bit of my code to work with URLs rather than paths, 
but that was a legacy from before URLs were more commonly used so that's not a 
sandboxing issue per se, but using URLs works with sandboxing whereas paths do 
not always it seems. I've been meaning to update this legacy code for a while, 
but while it continued to work had no real incentive to do it.

Because the iPhoto Library lives inside ~/Pictures, and there is a general 
entitlement for that folder, I no longer need a special temporary exception for 
the iPhoto Library, so the hard-coded paths issue goes away, as long as iPhoto 
Library remains in this location. I look up the actual name by peeking at iApps 
preferences and I still need a temporary entitlement for that, so I'm still at 
the mercy of Apple changes to these things, but no more so than before.

The other aspect to the general problem I was having, that of managing to 
resolve security-scoped bookmarks across sessions, I solved yesterday. Turns 
out the issue there is that you need to call the 
-startAccessingSecurityScopedResource after resolving the bookmark and leave it 
in that state until you are completely done with the folder (in my case that's 
only when the app quits).

I get an exception logged when dragging and dropping, but oddly it doesn't seem 
to cause any problems - D&D still works fine: Anyone any thoughts on this:

Artboard(70831) deny file-issue-extension /Users/grahamcox/Pictures/IMG_0899.JPG

OS Version:  Mac OS X 10.8 (12A269)
Report Version:  8

Thread 0:
0   libsystem_kernel.dylib  0x000103f99efe __mac_syscall + 10
1   libsystem_sandbox.dylib 0x00010401e4fe 
sandbox_issue_fs_rw_extension + 32
2   CoreFoundation  0x0001013b77e2 
__CFPasteboardIssueSandboxExtensionForPath + 130
3   CoreFoundation  0x0001013b74e6 
__CFPasteboardIssueSandboxExtensionForFileURL + 150
4   CoreFoundation  0x0001013838b7 
__CFPasteboardSetData + 1287
5   CoreFoundation  0x00010138333e CFPasteboardSetData 
+ 446
6   AppKit  0x000101bb774d -[NSPasteboard 
_setData:forType:index:usesPboardTypes:] + 376
7   AppKit  0x000101bb9020 -[NSPasteboard 
writeObjects:] + 1219
8   Artboard0x00010009b8f1 
-[GCMediaBrowserController imageBrowser:writeItemsAtIndexes:toPasteboard:] + 
161 (GCMediaBrowserController.m:636)
9   ImageKit0x00010a19a6b6 
-[IKImageBrowserView(ImageBrowserDragNDropInternal) 
startDragNDropWithEvent:itemIndexes:] + 616
10  ImageKit0x00010a19f949 
-[IKImageBrowserView(ImageBrowserEvents) mouseDragged:] + 1235


So unless any further issues are uncovered by testing with sandboxing, it looks 
like my app will now be able to adopt it with no loss of functionality, which 
is a huge relief.


I still think the general issues surrounding the sandboxing implementation are 
worth discussion though.


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

[Graham Cox]

On 23/08/2012, at 11:33 AM, Britt Durbrow 
 wrote:

> there's no programatic way to tell the difference between the two


Indeed, which is why you need to encourage the use of human intelligence 
instead, which very often can tell when something is "fishy".

When a computer needs to do something truly intelligent, it's usually a good 
idea to defer to the user.

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

[Britt Durbrow]

On Aug 22, 2012, at 7:16 PM, Graham Cox  wrote:

> 
> On 23/08/2012, at 11:33 AM, Britt Durbrow 
>  wrote:
> 
>> there's no programatic way to tell the difference between the two
> 
> 
> Indeed, which is why you need to encourage the use of human intelligence 
> instead, which very often can tell when something is "fishy".
> 
> When a computer needs to do something truly intelligent, it's usually a good 
> idea to defer to the user.
> 
> --Graham

Which, unfortunately, leads us to the Dancing Pigs problem... 

http://en.wikipedia.org/wiki/Dancing_pigs
___

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

Ensuring UIDatePicker shows 24-hour clock?

[Rick Mann]

I'm using the date picker to allow the user to set a time. But in this 
particular case, I need to ensure the time is always displayed in 24-hour 
format, rather than AM/PM, even if the user's current locale is set to AM/PM. 
Is there a way to do that?

Thanks!

-- 
Rick




___

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: Ensuring UIDatePicker shows 24-hour clock?

[Dave DeLong]

There is, unfortunately, no reliable way to do this.  What you could try doing 
is setting the locale of the UIDatePicker to something like en_GB, where the 
preferred time format is "HH:mm" and hope that the date picker recognizes this. 
 However, depending on which version of iOS your app is running on, it might 
not work.

As always, please file an enhancement request.  I'd love to see something like 
this go in.  :)

Cheers,

Dave

On Aug 22, 2012, at 7:29 PM, Rick Mann  wrote:

> I'm using the date picker to allow the user to set a time. But in this 
> particular case, I need to ensure the time is always displayed in 24-hour 
> format, rather than AM/PM, even if the user's current locale is set to AM/PM. 
> Is there a way to do that?
> 
> 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: Ensuring UIDatePicker shows 24-hour clock?

[Rick Mann]

Done 12157152.

How many days before it comes back as "closed as duplicate?"

-- 
Rick

On Aug 22, 2012, at 20:01 , Dave DeLong  wrote:

> There is, unfortunately, no reliable way to do this.  What you could try 
> doing is setting the locale of the UIDatePicker to something like en_GB, 
> where the preferred time format is "HH:mm" and hope that the date picker 
> recognizes this.  However, depending on which version of iOS your app is 
> running on, it might not work.
> 
> As always, please file an enhancement request.  I'd love to see something 
> like this go in.  :)
> 
> Cheers,
> 
> Dave
> 
> On Aug 22, 2012, at 7:29 PM, Rick Mann  wrote:
> 
>> I'm using the date picker to allow the user to set a time. But in this 
>> particular case, I need to ensure the time is always displayed in 24-hour 
>> format, rather than AM/PM, even if the user's current locale is set to 
>> AM/PM. Is there a way to do that?
>> 
>> Thanks!


-- 
Rick




___

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

Source List type OutlineView and bindings.

[Kevin Bracey]

Hi all,

I hate to ask these questions, either its so obvious or I'm doing it so wrong 
its laughable.

I have the "Source List" control dragged into a Window.
Bind to a NSTreeController. The NSTreeController is getting and vending fine as 
when attached to a NSBrowser the data shows as expected.

When connected to the Source list, I get blank selectable rows in the List, 
with no text, maybe no cell at all.

If checked the Source List example, but that does not use the "Source List" 
control, but a standard Outline.
It uses it own custom cell and loads the information into the cell via 
OutlineView delegate calls.

I'm guessing, the question is...

Do I get the cells from the Source List and load it using the delegate methods, 
similar to the example, or can the nodeText be bound directly.

Does anyone know where to find an example of using the "Source List" or is it 
some strange "red headed cousin" that's best ignored?

cheers
Kevin 
___

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

[Derek Chesterfield]

Gatekeeper uses the Quarantine mechanisms. Installer does not set the 
Quarantine flag, so the installed app does not trigger Gatekeeper. 

Basically if you have explicitly installed an app, you are expressing that you 
trust it. Or, expressed along the lines of the intent-driven model... I've 
installed this, I intend to execute it.  

On 23 Aug 2012, at 01:06, danchik  wrote:

> If the package is signed by Apple Developer's Installer certificate, gate 
> keeper does not complain (just askes to ok the installation) and then never 
> sais anything about the app that was installed (though it is NOT signed by 
> Apples Developer's Software certificate).
___

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