Re: NSPipe eating up all available pipes on system.

[Ken Thomases]

On Feb 22, 2013, at 5:52 PM, Mr. Gecko wrote:

> On Feb 22, 2013, at 10:47 AM, Willeke  wrote:
> 
>> I don't know why but it doesn't leak if you do readInBackgroundAndNotify 
>> only if [data length]!=0.
> 
> Doesn't make sense as when you release the NSPipe, it should disable that. I 
> will report this to apple via Rdar.

Actually, I doubt it will be considered a valid bug.  When you release the 
pipe, all that means is that you are no longer guaranteed that it will remain 
around.  You are not guaranteed that it will be deallocated.  The framework is 
entitled to keep it around for its own purposes when you do something like 
-readInBackgroundAndNotify.

Willeke is correct that you should not initiate another read after EOF (good 
catch!) and you _might_ report a bug about that read operation not immediately 
resulting in another notification with an empty data object.  The reason it 
doesn't, though, is probably related to the part of the kqueue() documentation 
that says that you can clear an EOF flag and resume waiting for the pipe to be 
readable.

https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/kqueue.2.html
"When the last writer disconnects, the filter will set EV_EOF in flags.  This 
may be cleared by passing in EV_CLEAR, at which point the filter will resume 
waiting for data to become available before returning."

(It's clear to me how a FIFO could acquire a new writer after all previous 
writers have disconnected.  It's not clear to me whether or how a pipe could, 
so I don't know why this semantic applies to pipes.)

In this case, avoiding issuing the new background read is easy and reliable.  
In other cases, if you want to make sure the framework has terminated all 
background uses of a file handle, you can try invoking -[NSFileHandle 
closeFile].  However, even that is not clearly documented to terminate 
in-flight background operations.

Regards,
Ken


___

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: NSPipe eating up all available pipes on system.

[Mr. Gecko]

Doesn't make sense as when you release the NSPipe, it should disable that. I 
will report this to apple via Rdar.

Thanks for solving my issue!

On Feb 22, 2013, at 10:47 AM, Willeke  wrote:

> I don't know why but it doesn't leak if you do readInBackgroundAndNotify only 
> if [data length]!=0.
> 
> - Willeke

___

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: Tracking object references

[Jean Suisse]

I am not taking any sides here, but rather just interested in the topic at hand 
: Tracking object references.

I had met an issue once that I never solved, which did require me to track down 
retain / release calls. What I did was to find in my code every explicit or 
implicit (@property accessors) calls to retain or release for the leaked 
instance and insert there a log statement with the value of self and a message 
telling me if retain or release was called. Then a few lines of php code 
(regular expressions weren't available in cocoa at that time) were able to 
remove all the balanced retain/release. That should have revealed which 
instance was responsible for the trouble.
This didn't help me much because the source of the leak wasn't in my code 
(turns out the leaked objects were actually copies made by NSTableView), but 
maybe it can help you.

Jean

On 22 févr. 2013, at 21:11, Greg Parker  wrote:

> On Feb 22, 2013, at 7:42 AM, Matt Neuburg  wrote:
>> Some specific object did send "retain". It is that specific object's 
>> responsibility eventually to send "release". That's how Cocoa memory 
>> management works. Instruments *can* know, and *should* tell me, what 
>> specific object that is. I wouldn't be here (i.e. using this aspect of 
>> Instruments) if this were not the very problem I'm having, i.e. some 
>> specific object is not fulfilling its responsibilities and I need to work 
>> out who it is. The fact that Instruments doesn't tell me this is not just 
>> some mild forgivable accident. It is Teh Suck. m.
> 
> Assume for the sake of argument that your attribution model above works. One 
> problem is that the retaining object can hand off its responsibility to some 
> other object, with no way for Instruments to be able to detect the change. 
> For example, consider code that reads a value out of one strong variable, 
> sets that variable to nil, and writes the value to a second strong variable. 
> No retain or release calls are necessary, which means there's no way for 
> Instruments to know that the release responsibility changed.
> 
> Another problem is that "who called retain?" is not always possible to 
> answer. For example, the call to retain could be an optimized tail-call. In 
> that case, the stack trace inside -retain includes no information about the 
> caller of -retain. If you assigned blame to the caller of retain, you might 
> be mis-attributing the release responsibility. Even worse, Instruments has no 
> way to know whether that has happened.
> 
> In order to solve problems like these you would need some sort of debug 
> compilation that defeats enough optimizations and preserves enough 
> information for Instruments to see what's going on, and you'd need to compile 
> everything (including OS libraries) this way.
> 
> 
> -- 
> Greg Parker gpar...@apple.com Runtime Wrangler
> 


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [OT] Sync vs ASync Server Comms

[Jens Alfke]

On Feb 22, 2013, at 8:32 AM, Dave  wrote:

> Of course there are threading "issues" Having delegates doesn't stop that

There are no threading issues if you don’t create background threads. I’ve 
written a lot of code that does network access using the async APIs, and most 
of it didn’t require me to create any background threads. Since all my code 
runs on the main thread, I don’t have any threading issues. That’s one less 
huge thing to worry about in my app.

Scalability is another issue that I don’t think anyone else has brought up — 
this is the reason that async network programming has become so popular in 
server frameworks like Twisted and Node.js. If you want to perform N 
simultaneous operations with a synchronous API, you have to spawn N threads. As 
N increases, this gets expensive: threads consume kernel resources and eat up 
address space for their stacks. With an async API, you can do the same work on 
a single thread. (And no, the OS does not create N threads behind your back to 
service the async API; it uses kqueues to manage any number of async tasks from 
a single background thread.)

> You don't have to take the example so literally! If I called the methods:
> 
> -(someValue) syncGetValueFromServer
> {
> //  Get Value From Server - takes a long time.
> return Value;
> }
> 
> -(void) aSyncGetValueFromServer:
> {
> //  Get Value From Server - takes a long time.
> }
> 
> It would amount to exactly the same thing! You are making a common mistake of 
> making conclusions about the method you are calling!

No, it wouldn’t be the same. The “aSyncGetValueFromServer” method would return 
immediately, letting me get on with other work on that thread. That’s what 
“asynchronous” means.

Dave, it’s kind of rude to ask the list for advice/insight, then start yelling 
at us when you don’t like our opinions (especially when a lot of the people 
replying have a lot more Cocoa experience than you seem to.)

—Jens

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: iOS books, etc for experienced OSX programmers

[Koen van der Drift]

Thanks everyone for the helpful info. Highly appreciated!

- Koen.

On Fri, Feb 22, 2013 at 1:55 PM, Alex Zavatone  wrote:
> FYI, in looking for material to use, from my experience, it is also
> important to know what to avoid.
>
> Ignore anything that is older than two years and any older material that
> references any version of Xcode before 4.
>
>
> A lot of the books that I do buy, (Matt's, Erica's, Vandad Nahavandipoor's)
> serve as wonderful references even if you do not read the the entire
> book/pdf.
>
> Also, and I feel that this is critical, if you do not yet fully understand
> deployment, provisioning and the whole certificate mess, (especially if you
> plan on doing Enterprise deployment), it's really really important to get
> your head around that.
>
> Here is a list of the resources that I have tabulated/recommended for my
> team.  Some of these may be too junior for you, but they are here for your
> reference.
>
> Also, previous years of the WWDC videos and PDFs from 2010, 2011 and 2012
> are often invaluable resources for reference and instruction.  They are
> massive but are easily recompressed to MP4 and can take up 1/2 the file size
> and still get look great.
>
> Essential iOS Build and Release
> http://shop.oreilly.com/product/0636920022282.do
>
> iOS Programming
> http://www.raywenderlich.com/store/ios-6-by-tutorials
>
> iOS Programming
> http://www.raywenderlich.com/store/ios-apprentice
>
> iOS Programming
> http://shop.oreilly.com/product/0636920023562.do
>
> iOS 6 Programming
> http://shop.oreilly.com/product/0636920027683.do
>
> Cocoa Design Patterns
> http://www.amazon.com/Cocoa-Design-Patterns-Erik-Buck/dp/0321535022
> https://developer.apple.com/library/mac/#documentation/cocoa/conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html
> http://iphone2009.crowdvine.com/talk/presentation_file/5106/Buck_-_Cocoa_Design_Patterns.pdf
>
> Apple Reference Documentation
> https://developer.apple.com/devcenter/ios/index.action
> https://developer.apple.com/library/ios/navigation/index.html?section=Resource+Types&topic=Getting+Started#
>
> Apple iOS Dev Videos
> https://developer.apple.com/videos/ios/
> https://developer.apple.com/videos/wwdc/2012/
>
>
> On Feb 22, 2013, at 8:53 AM, Koen van der Drift wrote:
>
> Having a lot of knowledge of and experience with Cocoa/ObjC/OSX I am
> looking for a good introduction to making iOS apps. Starting at
> Apple's dev website I did the BirdWatching tutorial. When searching
> for books, two jump out: the ones by Hillegass and by Dudney. However,
> based on their table of contents, both seem to require not much
> previous knowledge and therefore spent several chapters explaining the
> basics.
>
> Also found lots of tutorials, but I cannot judge the quality of those,
> and again they all seem to be for kids with hardly any programming
> knowledge.
>
> What do you guys think, shall I just go ahead and get one of those
> books, or did I miss some?  I think what I am looking the most for is
> some text that focuses on differences between iOS and OSX, so that I
> am not using techniques (eg bindings) and patterns that will not work
> on iOS.
>
> Thanks,
>
> - 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/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: Tracking object references

[Greg Parker]

On Feb 22, 2013, at 7:42 AM, Matt Neuburg  wrote:
> Some specific object did send "retain". It is that specific object's 
> responsibility eventually to send "release". That's how Cocoa memory 
> management works. Instruments *can* know, and *should* tell me, what specific 
> object that is. I wouldn't be here (i.e. using this aspect of Instruments) if 
> this were not the very problem I'm having, i.e. some specific object is not 
> fulfilling its responsibilities and I need to work out who it is. The fact 
> that Instruments doesn't tell me this is not just some mild forgivable 
> accident. It is Teh Suck. m.

Assume for the sake of argument that your attribution model above works. One 
problem is that the retaining object can hand off its responsibility to some 
other object, with no way for Instruments to be able to detect the change. For 
example, consider code that reads a value out of one strong variable, sets that 
variable to nil, and writes the value to a second strong variable. No retain or 
release calls are necessary, which means there's no way for Instruments to know 
that the release responsibility changed.

Another problem is that "who called retain?" is not always possible to answer. 
For example, the call to retain could be an optimized tail-call. In that case, 
the stack trace inside -retain includes no information about the caller of 
-retain. If you assigned blame to the caller of retain, you might be 
mis-attributing the release responsibility. Even worse, Instruments has no way 
to know whether that has happened.

In order to solve problems like these you would need some sort of debug 
compilation that defeats enough optimizations and preserves enough information 
for Instruments to see what's going on, and you'd need to compile everything 
(including OS libraries) this way.


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



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: IOS iPad PopOver Nav bar color

[Alex Zavatone]

I just came across this the other day.

You can crack open AI or PS and draw your own and replace the graphic which is 
a great skill to learn.

http://layersmagazine.com/designing-ios-tab-and-navigation-bars-in-photoshop.html

Then use this:

if ([self.navigationController.navigationBar 
respondsToSelector:@selector(setBackgroundImage:forBarMetrics:)] ) {
UIImage *image = [UIImage imageNamed:@"my new awesome nav bar image.png"];
[self.navigationController.navigationBar setBackgroundImage:image 
forBarMetrics:UIBarMetricsDefault];
}

You can simply change the tint in a storyboard or in code.

http://stackoverflow.com/questions/7179741/ios-navigation-controller-change-toolbar-color

You also can create the gradient in code which is probably even more useful.

(FYI, this is awesome) 
http://stackoverflow.com/questions/1852319/uinavigationbar-gradient-details

And Ray has an example on how to draw gradients.  Enjoy.

http://www.raywenderlich.com/2079/core-graphics-101-shadows-and-gloss




On Feb 22, 2013, at 10:44 AM, Matt Neuburg wrote:

> On Sun, 17 Feb 2013 17:24:25 -0800, Trygve Inda  
> said:
>> I have a popover view and would like a nav-like title bar on it in a dark
>> color that matches the frame gradient of the popover fram. I can make the
>> nav bar grey or black, but can't seem to get it to apply the gradient that
>> the frame has.
> 
> Starting in iOS 5 you can draw the frame and you can draw the navigation bar 
> background. So to say you can't get the navigation bar to match the frame has 
> is just false. Of course you can. m.
> 
> --
> matt neuburg, phd = m...@tidbits.com, 
> A fool + a tool + an autorelease pool = cool!
> Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
> ___
> 
> 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: Tracking object references

[Ken Thomases]

On Feb 22, 2013, at 9:42 AM, Matt Neuburg wrote:

> On Sun, 17 Feb 2013 12:16:47 -0600, Ken Thomases  said:
>> On Feb 17, 2013, at 11:50 AM, Matt Neuburg wrote:
>> 
>>> On Sat, 12 Jan 2013 11:13:13 +, Mike Abdullah 
>>>  said:
 
 The allocations instrument can show you all presently allocated objects. 
 Find the object(s) you're interested in from that list and you can view 
 its history of being retained and (auto)released, to figure out what is 
 still holding onto it.
>>> 
>>> Actually, Instruments is no help in figuring out "what is still holding 
>>> onto it". That's not entirely unreasonable, since in a very real sense *no* 
>>> object is "holding onto" anything; there are only messages and the object's 
>>> own internal retain count.
>> 
>> Well, you can't figure out what object is holding onto another object, but 
>> you can figure out which _body of code_ is holding onto an object.
>> 
>>> But it sure would be nice if Instruments did give more info about this, so 
>>> that one could try to track down which retains are balanced by which 
>>> releases (and which retains, therefore, are unbalanced).
>> 
>> Well, Instruments can no more divine which release balances which retain as 
>> it can know what object might "hold" what other object.
> 
> The words "which body of code is holding onto an object" don't have any 
> meaning to me, and I don't think they have any meaning to you either. You're 
> just waving your hands. If I wanted to wave my hands I wouldn't be using 
> Instruments.

It means a class's implementation or a module.  It's an organizational notion 
so, no, it doesn't have a precise syntactical definition.  It's the same sort 
of thing as "separation of responsibilities".  If it doesn't have meaning for 
you, I don't know how to help you.


> Some specific object did send "retain".

Objects don't send messages.  Code sends messages.  The implementations of 
methods of classes send messages, as can straight functions.

(As an aside, it's a pretty common question from new programmers – not saying 
you're one – to want to know, when implementing a method, "which object sent 
the message?"  More experienced programmers understand that that isn't how 
things work and that information isn't available and isn't even always 
meaningful.  For the same reasons, it's not productive to try to think about, 
from within an implementation of -retain or -release, "which object 
retained/released this object?" because it's the same question.  This point of 
view, from within the implementation of -retain and -release, is roughly that 
which is available to Instruments.)

> It is that specific object's responsibility eventually to send "release".

Nope.  It is the responsibility of the related code.

> That's how Cocoa memory management works.

Nope.  Cocoa includes conventions for one part of the code to pass ownership to 
other parts of the code.  Methods with "new" or "copy" in their name return 
ownership to their callers, for example.

Also, Cocoa memory management isn't the only kind of memory management that's 
necessary.  For example, Core Foundation memory management can interact with 
Cocoa memory management through toll-free bridging.  I hope you see that Core 
Foundation memory management can't be assigned to objects.

> Instruments *can* know, and *should* tell me, what specific object that is.

Nope.  It can only know which code is responsible.  Just because that code may 
be a method implementation doesn't mean Instruments knows what object that 
belongs to.  The code could also not belong to any object and that's valid in 
Cocoa memory management. It's also possible that the code which is supposed to 
release something is not part of the same class as the code which allocated it 
(ownership was transferred).

> I wouldn't be here (i.e. using this aspect of Instruments) if this were not 
> the very problem I'm having, i.e. some specific object is not fulfilling its 
> responsibilities and I need to work out who it is. The fact that Instruments 
> doesn't tell me this is not just some mild forgivable accident. It is Teh 
> Suck.

Well, I'm sorry that you're frustrated but many aspects of development require 
the application of human intelligence and can't be automated.  This is one of 
them.  If you actually go through the exercise of reviewing an object's 
retain/release history and matching up the retains and releases, you'll pretty 
quickly see that it's a difficult problem requiring an understanding of the 
code at a pretty high level.

If you believe that Instruments could be made to automate it, you should 
describe an algorithm that could do it.  I don't think you'll be able to 
without invoking magical artificial intelligence.

Regards,
Ken


___

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

Re: iOS books, etc for experienced OSX programmers

[Alex Zavatone]

FYI, in looking for material to use, from my experience, it is also important 
to know what to avoid.  

Ignore anything that is older than two years and any older material that 
references any version of Xcode before 4.  


A lot of the books that I do buy, (Matt's, Erica's, Vandad Nahavandipoor's) 
serve as wonderful references even if you do not read the the entire book/pdf.

Also, and I feel that this is critical, if you do not yet fully understand 
deployment, provisioning and the whole certificate mess, (especially if you 
plan on doing Enterprise deployment), it's really really important to get your 
head around that.

Here is a list of the resources that I have tabulated/recommended for my team.  
Some of these may be too junior for you, but they are here for your reference.

Also, previous years of the WWDC videos and PDFs from 2010, 2011 and 2012 are 
often invaluable resources for reference and instruction.  They are massive but 
are easily recompressed to MP4 and can take up 1/2 the file size and still get 
look great. 

Essential iOS Build and Release
http://shop.oreilly.com/product/0636920022282.do

iOS Programming
http://www.raywenderlich.com/store/ios-6-by-tutorials
 
iOS Programming
http://www.raywenderlich.com/store/ios-apprentice
 
iOS Programming
http://shop.oreilly.com/product/0636920023562.do
 
iOS 6 Programming
http://shop.oreilly.com/product/0636920027683.do
 
Cocoa Design Patterns
http://www.amazon.com/Cocoa-Design-Patterns-Erik-Buck/dp/0321535022
https://developer.apple.com/library/mac/#documentation/cocoa/conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html
http://iphone2009.crowdvine.com/talk/presentation_file/5106/Buck_-_Cocoa_Design_Patterns.pdf
 
Apple Reference Documentation
https://developer.apple.com/devcenter/ios/index.action
https://developer.apple.com/library/ios/navigation/index.html?section=Resource+Types&topic=Getting+Started#
 
Apple iOS Dev Videos
https://developer.apple.com/videos/ios/
https://developer.apple.com/videos/wwdc/2012/
 

On Feb 22, 2013, at 8:53 AM, Koen van der Drift wrote:

> Having a lot of knowledge of and experience with Cocoa/ObjC/OSX I am
> looking for a good introduction to making iOS apps. Starting at
> Apple's dev website I did the BirdWatching tutorial. When searching
> for books, two jump out: the ones by Hillegass and by Dudney. However,
> based on their table of contents, both seem to require not much
> previous knowledge and therefore spent several chapters explaining the
> basics.
> 
> Also found lots of tutorials, but I cannot judge the quality of those,
> and again they all seem to be for kids with hardly any programming
> knowledge.
> 
> What do you guys think, shall I just go ahead and get one of those
> books, or did I miss some?  I think what I am looking the most for is
> some text that focuses on differences between iOS and OSX, so that I
> am not using techniques (eg bindings) and patterns that will not work
> on iOS.
> 
> Thanks,
> 
> - 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/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: iOS books, etc for experienced OSX programmers

[David Rowland]

I like Matt Neuburg's book, and I recommend it to iOS classes I teach. Its 
first person style suits me, and I turn to it for answers and often find 
something extra. However, it is dense and not for everyone. Some of my students 
wish there were more examples, but Neuburg explicitly avoids HelloWorld stuff. 
His attitude is, let's saddle up and get moving, there is ground to cover.

David


On Feb 22, 2013, at 7:49 AM, Matt Neuburg  wrote:

> On Fri, 22 Feb 2013 22:16:11 +0800, Roland King  said:
>> I like the stuff Matt Neuburg publishes, I admit to reading that which he's 
>> made publicly available without purchasing the book (sorry Matt)
> 
> No apologies needed. I posted it so you could read it. (Of course I'd *like* 
> to be rewarded if my work has helped you, but obviously that's between you 
> and the long dark tea-time of the soul.) At the moment the *entire* iOS 6 
> version of the book is available to read for free, so I encourage people to 
> look it over while they can, as I don't know how long I'll be permitted to 
> keep it up.
> 
> http://www.apeth.com/iOSBook/
> 
> m.
> 
> --
> matt neuburg, phd = m...@tidbits.com, 
> A fool + a tool + an autorelease pool = cool!
> Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
> ___
> 
> 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/rowlandd%40sbcglobal.net
> 
> This email sent to rowla...@sbcglobal.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [OT] Sync vs ASync Server Comms

[Quincey Morris]

On Feb 22, 2013, at 08:32 , Dave  wrote:

> As long as you are not running on the main thread there is no real difference 
> between a Sync or ASync operation as far as any of the issues you mention 
> above are concerned.

You're correct that, at some level, using synchronous methods on a background 
thread is an equivalent to using async methods on the main thread (or any other 
thread, for that matter).

> The question is you have two black box methods that do the same thing, one 
> has Sync in it's name the other has ASync in it's name. Given everything else 
> is equal (which is is in this case), which one would you choose and why?

The main advantage of synchronous methods on a background thread is simplicity 
and/or conciseness of the code. In some cases, that can be a big enough "win" 
to choose this approach over the other.

Comparatively, the main advantage of async methods is their modest resource 
requirements, which means they may scale better. For example, you could likely 
perform thousands of (individually slow) network accesses simultaneously this 
way, while you really wouldn't want to create thousands of threads to do the 
same thing with sync calls. (That's an artificial and impractical example, of 
course.)

However, there's a whole boatload of disadvantages to using the sync calls 
which are purely situational, and can only be evaluated in a particular app 
design context. For example:

-- Very often, your background thread will need to trigger updates to the UI, 
and it must "switch" to the main thread to do this. That may introduce 
asynchronous behavior into the background thread, which in turn may subvert its 
entire approach.

-- Threads blocked in a synchronous method can't cancel themselves or respond 
to environmental changes like memory pressure until they return.

-- Since blocks were introduced, the frameworks have rapidly embraced 
blocks-based asynchronous patterns. That means that some of the most recent, 
capable and convenient APIs are async-only.

-- An interesting example I came across recently is AVFoundation, where there 
is API for loading asset object properties asynchronously. The documentation 
notes that you can do it synchronously in a background thread in OS X if you 
want, but you should not try doing that on iOS because you're likely to have 
your app killed by the OS for being non-responsive.

So, there's something of a trend -- currently -- towards asynchronicity. My 
suggestion would be to use the synchronous background approach if/when that 
truly simplifies the implementation, but when your task becomes more complex 
switch over to the better supported async approach.

___

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: [OT] Sync vs ASync Server Comms

[Alex Zavatone]

Well, one reason on iOS is that it will happen on thread 1 and block the main 
thread which is also the thread that the GUI is handled on.

Sent from my iPad

On Feb 22, 2013, at 5:13 AM, Dave  wrote:

> Hi All,
> 
> I was reading an article about Server/Client communications using a Rest 
> service and the author seemed to have a downer on using the Sync (as opposed 
> to ASync) methods of making a request and receiving a reply. Also I've 
> noticed it being generally discouraged in quite a few other places when I was 
> searching for 3rd Party Network Libraries. However, I can't find any reason 
> behind it? Does anyone have any idea why ASync transactions are better than 
> Sync transactions? Or is it just Sync'ism? lol
> 
> Have a Good Weekend!
> 
> 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/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: NSPipe eating up all available pipes on system.

[Willeke]

I don't know why but it doesn't leak if you do readInBackgroundAndNotify only 
if [data length]!=0.

- Willeke



Op 20 feb 2013, om 23:56 heeft Mr. Gecko het volgende geschreven:

> Looks like every pipe is leaking. I cannot see a way to prevent the leak 
> myself as I know the NSPipes are being released. It doesn't seem to crash 
> with Auto Reference Counting… But boy, it eats memory and still leaks. So I 
> would think this is an Apple bug.
> 


___

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: [OT] Sync vs ASync Server Comms

[Dave]

On 22 Feb 2013, at 15:48, Fritz Anderson wrote:


On 22 Feb 2013, at 8:56 AM, Dave  wrote:


A (Background) thread has two choices at this stage:

1.  Call aSyncComputePIToAZillionPlacesWithDelegate and provide a  
delegate that will be called back with the result.


2.  Call syncComputePIToAZillionPlaces get the result inline.

As long as the Background Thread doesn't have more work to do in  
parallel with the Compute PI operation, why is option 2 better  
than option 1.


I think that option 1 is by far the best solution and I can't  
understand why anyone would choose option 2!!


You misconceive what Apple and the other replies are telling you.  
The whole point of the async API is that _you don't create a  
background thread at all._ You call the method that starts the  
async process on the main thread, the implementing class does all  
the background processing as/if needed (and does it correctly), and  
it reports progress, errors, and completions on the main thread.


You get:

* No threading issues (Apple has already done them correctly)
* A service that can make an optimal choice between a background  
thread and a runloop source

* The ability to cancel (no threading issues)
* Progress events (no threading issues)
* The ability to detect security issues on-the-fly (no threading  
issues)

* Authentication (no threading issues)
* Error handling (no threading issues)
* The ability to interface with your controllers and views in a way  
that is factored out of the asynchronous process into your main- 
thread delegate methods (no threading issues)




Of course there are threading "issues" Having delegates doesn't  
stop that and running a delegate on the main thread is not always the  
best thing to do. Also with this approach, if the delegate want to do  
another lengthy operation then you get delegates within delegates and  
the whole thing becomes a giant mess.


You get none of this if you toss a synchronous call into a  
dispatch_async() and call it a day.


As long as you are not running on the main thread there is no real  
difference between a Sync or ASync operation as far as any of the  
issues you mention above are concerned.




That's only what I can think of for NSURLConnection; your example  
of a calculation of pi is simplified to the point of being a straw  
man, and better handled with an NSOperation.


You don't have to take the example so literally! If I called the  
methods:


-(someValue) syncGetValueFromServer
{
//  Get Value From Server - takes a long time.
return Value;
}

-(void) aSyncGetValueFromServer:
{
//  Get Value From Server - takes a long time.
}

It would amount to exactly the same thing! You are making a common  
mistake of making conclusions about the method you are calling! It  
may well be better with an Operation queue, but that's not the point  
or the question! The question is you have two black box methods that  
do the same thing, one has Sync in it's name the other has ASync in  
it's name. Given everything else is equal (which is is in this case),  
which one would you choose and why?


Take Care
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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: A plugin for a sandboxed app - where to can I successfully store a temp file?

[Kyle Sluder]

On Fri, Feb 22, 2013, at 04:40 AM, Nick wrote:
> Uli,
> there's no error. URLForDirectory returns the directory path (something
> like  /private/var/folders/WM/(com.apple.mail)/Downloads
> on both working and non-working systems.
> No output to the console either.

Mail plugins are not supported, so you're not likely to find much help
on this list. (I know, I know, we offer one.)

That said, in general, just because you can compute a path to somewhere
doesn't mean the sandbox will grant you access to write there.

BTW, /private/var is not inside your sandbox. Your sandbox lives in a
subdirectory of ~/Library/Containers.

--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: iOS books, etc for experienced OSX programmers

[Matt Neuburg]

On Fri, 22 Feb 2013 22:16:11 +0800, Roland King  said:
>I like the stuff Matt Neuburg publishes, I admit to reading that which he's 
>made publicly available without purchasing the book (sorry Matt)

No apologies needed. I posted it so you could read it. (Of course I'd *like* to 
be rewarded if my work has helped you, but obviously that's between you and the 
long dark tea-time of the soul.) At the moment the *entire* iOS 6 version of 
the book is available to read for free, so I encourage people to look it over 
while they can, as I don't know how long I'll be permitted to keep it up.

http://www.apeth.com/iOSBook/

m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
___

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: [OT] Sync vs ASync Server Comms

[Fritz Anderson]

On 22 Feb 2013, at 8:56 AM, Dave  wrote:

> A (Background) thread has two choices at this stage:
> 
> 1.  Call aSyncComputePIToAZillionPlacesWithDelegate and provide a delegate 
> that will be called back with the result.
> 
> 2.  Call syncComputePIToAZillionPlaces get the result inline.
> 
> As long as the Background Thread doesn't have more work to do in parallel 
> with the Compute PI operation, why is option 2 better than option 1.
> 
> I think that option 1 is by far the best solution and I can't understand why 
> anyone would choose option 2!!

You misconceive what Apple and the other replies are telling you. The whole 
point of the async API is that _you don't create a background thread at all._ 
You call the method that starts the async process on the main thread, the 
implementing class does all the background processing as/if needed (and does it 
correctly), and it reports progress, errors, and completions on the main thread.

You get:

* No threading issues (Apple has already done them correctly)
* A service that can make an optimal choice between a background thread and a 
runloop source
* The ability to cancel (no threading issues)
* Progress events (no threading issues)
* The ability to detect security issues on-the-fly (no threading issues)
* Authentication (no threading issues)
* Error handling (no threading issues)
* The ability to interface with your controllers and views in a way that is 
factored out of the asynchronous process into your main-thread delegate methods 
(no threading issues)

You get none of this if you toss a synchronous call into a dispatch_async() and 
call it a day.

That's only what I can think of for NSURLConnection; your example of a 
calculation of pi is simplified to the point of being a straw man, and better 
handled with an NSOperation.

— F

-- 
Fritz Anderson
Xcode 4 Unleashed: 4.5 supplement for free!
http://www.informit.com/store/xcode-4-unleashed-9780672333279


___

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 iPad PopOver Nav bar color

[Matt Neuburg]

On Sun, 17 Feb 2013 17:24:25 -0800, Trygve Inda  said:
>I have a popover view and would like a nav-like title bar on it in a dark
>color that matches the frame gradient of the popover fram. I can make the
>nav bar grey or black, but can't seem to get it to apply the gradient that
>the frame has.

Starting in iOS 5 you can draw the frame and you can draw the navigation bar 
background. So to say you can't get the navigation bar to match the frame has 
is just false. Of course you can. m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
___

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: Tracking object references

[Matt Neuburg]

On Sun, 17 Feb 2013 12:16:47 -0600, Ken Thomases  said:
>On Feb 17, 2013, at 11:50 AM, Matt Neuburg wrote:
>
>> On Sat, 12 Jan 2013 11:13:13 +, Mike Abdullah 
>>  said:
>>> 
>>> The allocations instrument can show you all presently allocated objects. 
>>> Find the object(s) you're interested in from that list and you can view its 
>>> history of being retained and (auto)released, to figure out what is still 
>>> holding onto it.
>> 
>> Actually, Instruments is no help in figuring out "what is still holding onto 
>> it". That's not entirely unreasonable, since in a very real sense *no* 
>> object is "holding onto" anything; there are only messages and the object's 
>> own internal retain count.
>
>Well, you can't figure out what object is holding onto another object, but you 
>can figure out which _body of code_ is holding onto an object.
>
>> But it sure would be nice if Instruments did give more info about this, so 
>> that one could try to track down which retains are balanced by which 
>> releases (and which retains, therefore, are unbalanced).
>
>Well, Instruments can no more divine which release balances which retain as it 
>can know what object might "hold" what other object.

The words "which body of code is holding onto an object" don't have any meaning 
to me, and I don't think they have any meaning to you either. You're just 
waving your hands. If I wanted to wave my hands I wouldn't be using Instruments.

Some specific object did send "retain". It is that specific object's 
responsibility eventually to send "release". That's how Cocoa memory management 
works. Instruments *can* know, and *should* tell me, what specific object that 
is. I wouldn't be here (i.e. using this aspect of Instruments) if this were not 
the very problem I'm having, i.e. some specific object is not fulfilling its 
responsibilities and I need to work out who it is. The fact that Instruments 
doesn't tell me this is not just some mild forgivable accident. It is Teh Suck. 
m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
___

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: [OT] Sync vs ASync Server Comms

[Dave]

On 22 Feb 2013, at 13:57, Uli Kusterer wrote:

performSelector doesn't take care of locking non-threadsafe data  
structures, avoiding deadlocks in aforementioned logs etc. Although  
e.g. Cocoa's UI classes have improved a lot WRT thread-safety in  
recent MacOS releases, it's still not safe to drive arbitrary  
controls from another thread. Similar with certain libraries. By  
using async APIs, they take care of this for you and call you back  
on the main thread. It's simply letting Apple write the difficult  
code (and all their users find the bugs for you) instead of  
noticing them a year after you've shipped.


Yes, I know all that, but that's true of anything, not just a Network  
Manager  And this isn't Apple Call Backs, I'm talking about. I've  
nothing against delegate type call backs.


As an example of what I mean:

-(largenumber) syncComputePIToAZillionPlaces
{

//  Compute PI for a Zillion Places - takes a long time.

return PI;
}


-(void) aSyncComputePIToAZillionPlacesWithDelegate:
{

//  Compute PI for a Zillion Places - takes a long time.

}

A (Background) thread has two choices at this stage:

1.  Call aSyncComputePIToAZillionPlacesWithDelegate and provide a  
delegate that will be called back with the result.


2.  Call syncComputePIToAZillionPlaces get the result inline.

As long as the Background Thread doesn't have more work to do in  
parallel with the Compute PI operation, why is option 2 better than  
option 1.


I think that option 1 is by far the best solution and I can't  
understand why anyone would choose option 2!!


TTFN
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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: iOS books, etc for experienced OSX programmers

[Koen van der Drift]

Good advice, thanks Roland. I do have an idea and a project, so I will
just go ahead and dive in.

One thing I'm not sure about yet is the use of 'storyboards'. Apple
uses it in their tutorial, but the two books I mentioned seem to
hardly touch on it. Maybe it is too new to have been included inthose
books?

- Koen.

On Fri, Feb 22, 2013 at 9:16 AM, Roland King  wrote:
> With respect to Mssrs Hillegass and Dudney, if you have a good knowledge of
> OSX Cocoa I think you are probably going to do as well jumping in and
> reading what docs and sample code Apple has trying to convert your brain to
> iOS. My experience, going the other way, is that the iOS interface is
> cleaner and has less 'oh really' moments than the OSX one. I like the stuff
> Matt Neuburg publishes, I admit to reading that which he's made publicly
> available without purchasing the book (sorry Matt)  and he's quite
> methodical about going through the framework which I think might also work
> quite well for someone with an already working knowledge transitioning over.
>
> I would probably start by assuming you know most of what you need to know,
> jump in and have a few headscratchers and see if you think you are missing
> something. It's more similar than it is different and just getting your head
> around that little screen on the iPhone or the sligthly-too-large one on the
> iPad is possibly most of the difficulty. Think of a project, code it, ask
> questions here.
>
> Roland
>
> PS no bindings on iOS, I count myself lucky. Jury still out on Autolayout
> and no menus is somewhat of a win.
>
>
>
> On 22 Feb, 2013, at 9:53 PM, Koen van der Drift 
> wrote:
>
> Having a lot of knowledge of and experience with Cocoa/ObjC/OSX I am
> looking for a good introduction to making iOS apps. Starting at
> Apple's dev website I did the BirdWatching tutorial. When searching
> for books, two jump out: the ones by Hillegass and by Dudney. However,
> based on their table of contents, both seem to require not much
> previous knowledge and therefore spent several chapters explaining the
> basics.
>
> Also found lots of tutorials, but I cannot judge the quality of those,
> and again they all seem to be for kids with hardly any programming
> knowledge.
>
> What do you guys think, shall I just go ahead and get one of those
> books, or did I miss some?  I think what I am looking the most for is
> some text that focuses on differences between iOS and OSX, so that I
> am not using techniques (eg bindings) and patterns that will not work
> on iOS.
>
> Thanks,
>
> - 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/rols%40rols.org
>
> This email sent to r...@rols.org
>
>
___

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 books, etc for experienced OSX programmers

[Roland King]

With respect to Mssrs Hillegass and Dudney, if you have a good knowledge of OSX 
Cocoa I think you are probably going to do as well jumping in and reading what 
docs and sample code Apple has trying to convert your brain to iOS. My 
experience, going the other way, is that the iOS interface is cleaner and has 
less 'oh really' moments than the OSX one. I like the stuff Matt Neuburg 
publishes, I admit to reading that which he's made publicly available without 
purchasing the book (sorry Matt)  and he's quite methodical about going through 
the framework which I think might also work quite well for someone with an 
already working knowledge transitioning over. 

I would probably start by assuming you know most of what you need to know, jump 
in and have a few headscratchers and see if you think you are missing 
something. It's more similar than it is different and just getting your head 
around that little screen on the iPhone or the sligthly-too-large one on the 
iPad is possibly most of the difficulty. Think of a project, code it, ask 
questions here.  

Roland

PS no bindings on iOS, I count myself lucky. Jury still out on Autolayout and 
no menus is somewhat of a win. 



On 22 Feb, 2013, at 9:53 PM, Koen van der Drift  
wrote:

> Having a lot of knowledge of and experience with Cocoa/ObjC/OSX I am
> looking for a good introduction to making iOS apps. Starting at
> Apple's dev website I did the BirdWatching tutorial. When searching
> for books, two jump out: the ones by Hillegass and by Dudney. However,
> based on their table of contents, both seem to require not much
> previous knowledge and therefore spent several chapters explaining the
> basics.
> 
> Also found lots of tutorials, but I cannot judge the quality of those,
> and again they all seem to be for kids with hardly any programming
> knowledge.
> 
> What do you guys think, shall I just go ahead and get one of those
> books, or did I miss some?  I think what I am looking the most for is
> some text that focuses on differences between iOS and OSX, so that I
> am not using techniques (eg bindings) and patterns that will not work
> on iOS.
> 
> Thanks,
> 
> - 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/rols%40rols.org
> 
> This email sent to r...@rols.org

___

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: [OT] Sync vs ASync Server Comms

[Uli Kusterer]

performSelector doesn't take care of locking non-threadsafe data structures, 
avoiding deadlocks in aforementioned logs etc. Although e.g. Cocoa's UI classes 
have improved a lot WRT thread-safety in recent MacOS releases, it's still not 
safe to drive arbitrary controls from another thread. Similar with certain 
libraries. By using async APIs, they take care of this for you and call you 
back on the main thread. It's simply letting Apple write the difficult code 
(and all their users find the bugs for you) instead of noticing them a year 
after you've shipped.

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

On Feb 22, 2013, at 2:22 PM, Dave  wrote:

> How is threading hard in this case? Given that you have to make sure you 
> don't block the main thread anyway, you'd automatically do time consuming 
> things on a Background thread. It's as hard as [self 
> performSelectorInBackground. ];


___

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 books, etc for experienced OSX programmers

[Koen van der Drift]

Having a lot of knowledge of and experience with Cocoa/ObjC/OSX I am
looking for a good introduction to making iOS apps. Starting at
Apple's dev website I did the BirdWatching tutorial. When searching
for books, two jump out: the ones by Hillegass and by Dudney. However,
based on their table of contents, both seem to require not much
previous knowledge and therefore spent several chapters explaining the
basics.

Also found lots of tutorials, but I cannot judge the quality of those,
and again they all seem to be for kids with hardly any programming
knowledge.

What do you guys think, shall I just go ahead and get one of those
books, or did I miss some?  I think what I am looking the most for is
some text that focuses on differences between iOS and OSX, so that I
am not using techniques (eg bindings) and patterns that will not work
on iOS.

Thanks,

- 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: [OT] Sync vs ASync Server Comms

[Dave]

Hi,



Hi,

On 22 Feb 2013, at 11:29, Uli Kusterer wrote:


 in short: Network processes can take a long time (high traffic,  
14.4k modems, ...). If you are using a synchronous call on the main  
thread, your application will be completely blocked from doing  
anything else. The CPU will sit there idle, not doing anything  
until the transfer has finished. Since the operating system  
processes events on the main thread, the user will not be able to  
quit your application, click a "Cancel" button or do anything else.


Yes, but that's true of anything that takes, a long time. I didn't  
mean the main thread, obviously you can't block that regardless of  
what causes the delay!!!


 Now imagine you're loading images into a table on an iPhone. The  
user is scrolling through the list. Whenever a new item in the  
table is exposed, you go out to the network, request that image,  
blocking the main thread (and pausing the user's scrolling). At  
home, as the developer, you don't notice. The server is sitting  
right next to you. But a user at the edge of cell phone reception  
or in a moving train will find it impossible to scroll because  
essentially he's exposing one item, waiting, exposing the next  
item, waiting...


Yeah. but not on the main thread, on a Background thread.


 You could solve this problem by using synchronous API on a  
separate thread, but threading is hard. That's where async API  
comes in. In many cases (e.g. NSURLConnection) these APIs create a  
new thread, that does all the synchronous download calls for you,  
and then notifies the main thread when it's done. You don't need to  
use locks, or semaphores, or do the threading yourself. Other async  
calls work by splitting their work into small bits, adding them to  
a queue, and then periodically (but on the main thread) performing  
a tiny fraction of the work by executing the next tiny fraction of  
a task from the queue. In between these tiny operations, the user  
can keep working, and barely notices the tiny interruptions.




How is threading hard in this case? Given that you have to make sure  
you don't block the main thread anyway, you'd automatically do time  
consuming things on a Background thread. It's as hard as [self  
performSelectorInBackground. ];


The App I am working on in highly multi threaded app and all time  
consuming work in run on a background thread as a matter of course.


Dave




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

On Feb 22, 2013, at 11:13 AM, Dave  wrote:


Hi All,

I was reading an article about Server/Client communications using  
a Rest service and the author seemed to have a downer on using the  
Sync (as opposed to ASync) methods of making a request and  
receiving a reply. Also I've noticed it being generally  
discouraged in quite a few other places when I was searching for  
3rd Party Network Libraries. However, I can't find any reason  
behind it? Does anyone have any idea why ASync transactions are  
better than Sync transactions? Or is it just Sync'ism? lol


Have a Good Weekend!

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/ 
witness.of.teachtext%40gmx.net


This email sent to witness.of.teacht...@gmx.net




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: A plugin for a sandboxed app - where to can I successfully store a temp file?

[Nick]

Uli,
there's no error. URLForDirectory returns the directory path (something
like  /private/var/folders/WM/(com.apple.mail)/Downloads
on both working and non-working systems.
No output to the console either.


2013/2/22 Uli Kusterer 

> He meant the error return parameter to the URLForDirectory call. You're
> passing NULL. Why not pass it an NSError* and NSLog() the object it gives
> you back when it returns NIL (which it presumably does?) Also, is there any
> output on the console? If it's the sandbox, there's usually a log message
> there that tells you it blocked an operation that isn't permitted.
>
> Cheers,
> -- Uli Kusterer
> "The Witnesses of TeachText are everywhere..."
> http://www.zathras.de
>
> On Feb 22, 2013, at 11:52 AM, Nick  wrote:
> >> You’re not consulting/logging the error message for a start . That will
> >> tell you *why* it fails
> >>
> > There's not much to log. The path to a file i generate is (i - is a
> number):
>
>
___

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: A plugin for a sandboxed app - where to can I successfully store a temp file?

[Uli Kusterer]

He meant the error return parameter to the URLForDirectory call. You're passing 
NULL. Why not pass it an NSError* and NSLog() the object it gives you back when 
it returns NIL (which it presumably does?) Also, is there any output on the 
console? If it's the sandbox, there's usually a log message there that tells 
you it blocked an operation that isn't permitted.

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

On Feb 22, 2013, at 11:52 AM, Nick  wrote:
>> You’re not consulting/logging the error message for a start . That will
>> tell you *why* it fails
>> 
> There's not much to log. The path to a file i generate is (i - is a number):


___

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: [OT] Sync vs ASync Server Comms

[Uli Kusterer]

Hi,

 in short: Network processes can take a long time (high traffic, 14.4k modems, 
...). If you are using a synchronous call on the main thread, your application 
will be completely blocked from doing anything else. The CPU will sit there 
idle, not doing anything until the transfer has finished. Since the operating 
system processes events on the main thread, the user will not be able to quit 
your application, click a "Cancel" button or do anything else.

 Now imagine you're loading images into a table on an iPhone. The user is 
scrolling through the list. Whenever a new item in the table is exposed, you go 
out to the network, request that image, blocking the main thread (and pausing 
the user's scrolling). At home, as the developer, you don't notice. The server 
is sitting right next to you. But a user at the edge of cell phone reception or 
in a moving train will find it impossible to scroll because essentially he's 
exposing one item, waiting, exposing the next item, waiting...

 You could solve this problem by using synchronous API on a separate thread, 
but threading is hard. That's where async API comes in. In many cases (e.g. 
NSURLConnection) these APIs create a new thread, that does all the synchronous 
download calls for you, and then notifies the main thread when it's done. You 
don't need to use locks, or semaphores, or do the threading yourself. Other 
async calls work by splitting their work into small bits, adding them to a 
queue, and then periodically (but on the main thread) performing a tiny 
fraction of the work by executing the next tiny fraction of a task from the 
queue. In between these tiny operations, the user can keep working, and barely 
notices the tiny interruptions.

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

On Feb 22, 2013, at 11:13 AM, Dave  wrote:

> Hi All,
> 
> I was reading an article about Server/Client communications using a Rest 
> service and the author seemed to have a downer on using the Sync (as opposed 
> to ASync) methods of making a request and receiving a reply. Also I've 
> noticed it being generally discouraged in quite a few other places when I was 
> searching for 3rd Party Network Libraries. However, I can't find any reason 
> behind it? Does anyone have any idea why ASync transactions are better than 
> Sync transactions? Or is it just Sync'ism? lol
> 
> Have a Good Weekend!
> 
> 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/witness.of.teachtext%40gmx.net
> 
> This email sent to witness.of.teacht...@gmx.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: A plugin for a sandboxed app - where to can I successfully store a temp file?

[Nick]

>Why should Mail "obviously should have access to this directory”?

Because Mail stores attachments to that folder.

>You’re not consulting/logging the error message for a start . That will
tell you *why* it fails

There's not much to log. The path to a file i generate is (i - is a number):

NSString *emlFilePath = [TempDir stringByAppendingPathComponent:[NSString
stringWithFormat:@"%d.eml", i, nil]];


empFilePath (disregarding ability to save file to that directory) contains
some sandbox-like bath (i.e., it's not a "straight" path to ~Downloads, but
rather a symlink through /private/var


Then I'm calling

[Message saver] alloc] init] autorelease]
saveMessagesWithoutPrompting:wrappedMessage
toFilePath:emlFilePath headerDetailLevel:1 format:0];


This function does not return any error status.

It works on Mail on OS X 10.6, and on my machine on OS X 10.8. It doesn't
work on my client's 10.8 though.

I was wondering if I am breaking some sandboxing rules that may forbid apps
to do what I am doing, when the system has higher security settings that my
system, that's all. Because on my 10.8.2 with latest update of Mail.app it
works fine, on client's machine (with latest update either!) it doesn't -
the .eml files do not get created, and the only error I am getting is that
.eml file is not found (when I try to access the file later).



2013/2/22 Mike Abdullah 

>
> On 22 Feb 2013, at 01:34, Nick wrote:
>
> > Hello.
> > I am working on a plugin for Mail.app for Mountain Lion. The problem is
> > whenever I try to save a file, I am getting an error. Which can be
> > explained by the fact that Mail.app is sandboxed and I am not allowed to
> > modify files anywhere on the system.
> > So what I do instead - is call
> >
> >
> > TempDir = [[[NSFileManager defaultManager] URLForDirectory:
> > NSDownloadsDirectory inDomain:NSUserDomainMask appropriateForURL:nil
> create:
> > YES error:nil] path];
> >
> >
> > and then create in this TempDir another directory using standard
> > NSFileManager functions.
> > On my Mail.app it works, on another system - it doesn't (the dir doesn't
> > get created). I can't understand why. I was hoping to store a temporary
> > file in Downloads, since Mail obviously should have access to this
> > directory.
>
> Why should Mail "obviously should have access to this directory”?
> >
> > I also tried calling this
> >
> > TempDir = NSFileManager defaultManager]
> > URLForDirectory:NSItemReplacementDirectory inDomain:NSUserDomainMask
> > appropriateForURL:[NSURL URLWithString:
> > @"file:///private/var/tmp/my.great.app"] create:YES error:nil] path]
> > retain];
> >
> >
> > On my 10.8 system it works, on another - it doesn't (I can't save files
> to
> > TempDir from my plugin). What am I doing wrong?
>
> You’re not consulting/logging the error message for a start . That will
> tell you *why* it fails.
___

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

[OT] Sync vs ASync Server Comms

[Dave]

Hi All,

I was reading an article about Server/Client communications using a  
Rest service and the author seemed to have a downer on using the Sync  
(as opposed to ASync) methods of making a request and receiving a  
reply. Also I've noticed it being generally discouraged in quite a  
few other places when I was searching for 3rd Party Network  
Libraries. However, I can't find any reason behind it? Does anyone  
have any idea why ASync transactions are better than Sync  
transactions? Or is it just Sync'ism? lol


Have a Good Weekend!

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: A plugin for a sandboxed app - where to can I successfully store a temp file?

[Mike Abdullah]

On 22 Feb 2013, at 01:34, Nick wrote:

> Hello.
> I am working on a plugin for Mail.app for Mountain Lion. The problem is
> whenever I try to save a file, I am getting an error. Which can be
> explained by the fact that Mail.app is sandboxed and I am not allowed to
> modify files anywhere on the system.
> So what I do instead - is call
> 
> 
> TempDir = [[[NSFileManager defaultManager] URLForDirectory:
> NSDownloadsDirectory inDomain:NSUserDomainMask appropriateForURL:nil create:
> YES error:nil] path];
> 
> 
> and then create in this TempDir another directory using standard
> NSFileManager functions.
> On my Mail.app it works, on another system - it doesn't (the dir doesn't
> get created). I can't understand why. I was hoping to store a temporary
> file in Downloads, since Mail obviously should have access to this
> directory.

Why should Mail "obviously should have access to this directory”?
> 
> I also tried calling this
> 
> TempDir = NSFileManager defaultManager]
> URLForDirectory:NSItemReplacementDirectory inDomain:NSUserDomainMask
> appropriateForURL:[NSURL URLWithString:
> @"file:///private/var/tmp/my.great.app"] create:YES error:nil] path]
> retain];
> 
> 
> On my 10.8 system it works, on another - it doesn't (I can't save files to
> TempDir from my plugin). What am I doing wrong?

You’re not consulting/logging the error message for a start . That will tell 
you *why* it fails.
___

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: How to recognize mutability?

[Keith J. Schultz]

Hi Everybody,

I step in here, with my two euro cents worth.

I see a basic design flaw happening here.
That is you do not to be doing consistency checks.

It is possible to find out if something goes wrong during the arching process.
Check the API for NSKeyedArchiver.

Maybe, I am to old school, but I have learned working with any similar
to a database you need consistency checks before you commit.

The same goes for any input to a program. Either, control the input to your 
system,
or make sure it does not cause problems. 

regards
Keith.
 

Am 22.02.2013 um 07:37 schrieb Alex Zavatone :

> 
> On Feb 22, 2013, at 1:15 AM, Jens Alfke wrote:
> 
>> 
>> On Feb 21, 2013, at 8:34 PM, Gerriet M. Denkmann  
>> wrote:
>> 
>>> Well, the opposite of: "can store all strings" is: "can store only certain 
>>> strings".
>>> My point is that the number of unstorable strings is greater than zero. 
>>> Whether it is 1 or any other number is quite beside the point.
>> 
>> Yes. What makes this so bad is that it’s pretty likely that some strings 
>> stored in an archive are created outside the program’s control, i.e. by a 
>> user (or worse, possibly from data received over a network.) That means you 
>> have to explicitly guard against un-archivable strings, maybe by escaping 
>> them somehow, or run the risk of crashes or corruption. And we don’t even 
>> know for sure what the full set of un-archivable strings is.
>> 
>> It also doesn’t matter how obscure/unlikely those illegal inputs are. Let’s 
>> say you wrote an IRC client that persists transcripts using an 
>> NSKeyedArchiver, with a data structure where every message is an NSString. 
>> Makes sense. So then all someone has to do is type the message “$null” into 
>> an IRC chat, and boom! Everyone in that chat room using your client 
>> simultaneously gets kicked out with a crash.* Instant DoS attack. In this 
>> case it wouldn’t matter if the illegal string were a specific 800 characters 
>> of gibberish; once someone found out the bug, that string would become 
>> pretty widely known.
>> 
> 
> Exactly that.
> 
> In one iOS project I have that is a front end GUI to a corporate database, 
> simply entering null as a search query to the server ends up returning every 
> record in the database.  
> 
> It's unexpected issues like this that can have really dangerous and 
> unpredictable implications.  Since I don't have control over the server, I 
> have an array of query values to check for that could crater the server and 
> filter the search input against this array to remove any of those values if 
> present.  
> 
> Now, IF this were for a project that was, ohh, the entire sales figures for a 
> large public company (it is), this is a massive security and legal issue in 
> that the back end exposes the entire data set of clients (or whatever) simply 
> by passing in null as a query string.
> 


___

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