Re: About iVars declaration and property
On Nov 13, 2011, at 1:16 AM, ico wrote: > I am surprise that I just know we do not need to declare instance variables > explicitly when we declare the property and use @synthesize. > > That is we do not need a instance variable to be declared that is > corresponds to the property declaration. > > > > look at this blog: > http://cocoawithlove.com/2010/03/dynamic-ivars-solving-fragile-base.html > > > > However, I just wonder, is it really true that there is no ANY different > between explicitly declaring iVars and not delaring it? > > If so, is it a better approach that just declare the property and let > @synthesize to generate the iVars itself. > > > > Any more explaination and clarify will be appreciated. Only difference is that you have to explicitly declare the ivar to be compatible with the 32-bit runtime. If you’re 64-bit only (or if you require Lion or better), there’s no real reason to explicitly declare the ivars these days. Charles___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
About iVars declaration and property
I am surprise that I just know we do not need to declare instance variables explicitly when we declare the property and use @synthesize. That is we do not need a instance variable to be declared that is corresponds to the property declaration. look at this blog: http://cocoawithlove.com/2010/03/dynamic-ivars-solving-fragile-base.html However, I just wonder, is it really true that there is no ANY different between explicitly declaring iVars and not delaring it? If so, is it a better approach that just declare the property and let @synthesize to generate the iVars itself. Any more explaination and clarify will be appreciated. -- == Life isn't about finding yourself. Life is about creating yourself. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
App store receipt checking - getting a new receipt
Hi, I have implemented app store receipt checking, and it all seemed to be going OK, but I needed to change the bundle version number and check a new version, but when I run the application, it seems to download the previously generated receipt from the app store, which of course has the old bundle version, so validation fails. Do I need to do something special to get a new receipt? I didn't see anything about this in the documentation. Thanks Gideon ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSBitmapImageRep and alpha channel
On Nov 12, 2011, at 3:29 PM, Quincey Morris wrote: > On Nov 12, 2011, at 14:01 , James Merkel wrote: > >> d' = a * s + (1 - a) * d >> All premultiplication does is precalculate a * s." >> >> First question -- what is d' in that equation? > > It's the result of compositing the source (your image) onto the destination > (the background). > >> I read images from files and create histograms from them using pixel data >> from the NSBitmapImageRep. >> Things seem to work ok except for images that have an alpha channel (that >> is, bitsPerPixel = 32 from the NSBitmapImageRep, and an alpha channel is >> present). >> The histograms in that case have gaps in them (certain levels seem to be >> under-represented). > > Histograms of what? Color component distributions? How do you determine that > levels are under-represented? If the pattern of gaps is regular, that > probably means that the original image data was up-sampled at some point in > the process of delivering the data to the bitmap image rep. > >> Some specific images with this problem were downloaded through Image >> Capture and rotated in Image Capture. >> When an image is rotated in Image Capture, apparently the pixel data is >> rotated and the Exif Orientation tag is changed to reflect the rotation. >> (This is different from what I thought Apple said in previous documentation. >> I thought just the Exif Orientation tag was changed, and it was up to the >> image display program to rotate the image). >> Anyway, after rotation, the order of the data is ARGB, whereas before the >> rotation the order was RGBA. > > In a sense, the pixel order is is irrelevant -- it only matters if you're > going to operate on the image pixel by pixel, so that you can decode the > pixel components. > >> Also, before the rotation, the alpha channel appears to be just an unused >> channel >> -- i.e. it's not really an alpha channel. > > What do you mean by unused? If the pixel format says there's an alpha > channel, there is one. Are all the alpha channel values 1.0? I'd imagine that > something captured via Image Capture would be fully opaque. > >> Two additional questions: are the pixel data premultiplied with the alpha >> channel? > > Yeah, presumably. > >> Also, for a histogram, should the data be premultiplied with alpha? That is, >> should the histogram reflect the alpha? > > Typically, you'd expect not. That's why premultiplied data sucks if you need > to analyze or manipulate the pixels. You can always recover a > non-premultiplied value, but there's a loss of precision involved (more > pronounced as the alpha heads towards 0), so it's better to get hold of the > un-premultiplied data. > > Of course, if all of the alpha values are 1.0, then a * s == s everywhere, > so the question of premultiplication is moot. > > Yes, these are histograms of the color components. I think these histograms are wrong because I looked at the histograms generated by two other programs, and they don't show those gaps. Either they are wrong or I am wrong. Agree, pixel order doesn't matter. However, I only see the problem when the order is ARGB. By unused I mean the format is 32-bits per pixel, but the method hasAlpha on the image bitmap says there is no alpha. The color space is RGB, so I conclude there is an unused 4th channel. Also, using the mask NSAlphaFirstBitmapFormat says the alpha is not first. It (the unused channel) is last. Agree, for these images, the alpha value is always xFF which is 1. So it shouldn't matter. 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSBitmapImageRep and alpha channel
On Nov 12, 2011, at 14:01 , James Merkel wrote: > d' = a * s + (1 - a) * d > All premultiplication does is precalculate a * s." > > First question -- what is d' in that equation? It's the result of compositing the source (your image) onto the destination (the background). > I read images from files and create histograms from them using pixel data > from the NSBitmapImageRep. > Things seem to work ok except for images that have an alpha channel (that is, > bitsPerPixel = 32 from the NSBitmapImageRep, and an alpha channel is > present). > The histograms in that case have gaps in them (certain levels seem to be > under-represented). Histograms of what? Color component distributions? How do you determine that levels are under-represented? If the pattern of gaps is regular, that probably means that the original image data was up-sampled at some point in the process of delivering the data to the bitmap image rep. > Some specific images with this problem were downloaded through Image Capture > and rotated in Image Capture. > When an image is rotated in Image Capture, apparently the pixel data is > rotated and the Exif Orientation tag is changed to reflect the rotation. > (This is different from what I thought Apple said in previous documentation. > I thought just the Exif Orientation tag was changed, and it was up to the > image display program to rotate the image). > Anyway, after rotation, the order of the data is ARGB, whereas before the > rotation the order was RGBA. In a sense, the pixel order is is irrelevant -- it only matters if you're going to operate on the image pixel by pixel, so that you can decode the pixel components. > Also, before the rotation, the alpha channel appears to be just an unused > channel > -- i.e. it's not really an alpha channel. What do you mean by unused? If the pixel format says there's an alpha channel, there is one. Are all the alpha channel values 1.0? I'd imagine that something captured via Image Capture would be fully opaque. > Two additional questions: are the pixel data premultiplied with the alpha > channel? Yeah, presumably. > Also, for a histogram, should the data be premultiplied with alpha? That is, > should the histogram reflect the alpha? Typically, you'd expect not. That's why premultiplied data sucks if you need to analyze or manipulate the pixels. You can always recover a non-premultiplied value, but there's a loss of precision involved (more pronounced as the alpha heads towards 0), so it's better to get hold of the un-premultiplied data. Of course, if all of the alpha values are 1.0, then a * s == s everywhere, so the question of premultiplication is moot. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Calling a Cocoa library from C
Note that of course you can take this one step further and use a typedef to
mask that you're passing back an untyped pointer:
typedef OCObjcCodeRef void *
OCObjcCodeRef OCCreateObjcCode(void)
{
return (ObjcCodeRef)[[ObjcCode alloc] init]
}
int OCGetFloatData(OCObjcCodeRef objcCodeRef, float *result1, float *result2)
{
ObjcCode *obj = (ObjcCode *)objcCodeRef;
@autoreleasepool
{
*result1 = [obj doSomeStuff];
*result2 = [obj doSomethingElse];
return [obj doMagic];
}
}
void OCReleaseObjcCode(OCObjcCodeRef o)
{
[(ObjcCode *)o release];
}
Which gets you roughly to the "toll free bridging" abstraction.
Tom Davie
if (*ra4 != 0xffc78948) { return false; }
On 12 Nov 2011, at 22:48, Greg Guerin wrote:
> Nathan Sims wrote:
>
>> Hmm, if not a global, where would the declaration go? The C function
>> certainly shouldn't return it, so if it is to remain persistent across
>> calls, wouldn't the logical (the only?) place for it be as a global in the
>> library's .m file?
>
>
> Why shouldn't the C function return it? As far as C is concerned, an object
> pointer is just an opaque pointer. Handle it like any other opaque pointer.
>
> Example:
>
> void * setup_data()
> {
> return (void *) [[ObjcCode alloc]init];
> }
> int get_float_data( void * ptrFrom_setup_data, float *result1, float *result2)
> {
> ObjcCode *obj = (ObjcCode *) ptrFrom_setup_data;
>
> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>
> [obj call];
> *result1 = [more stuff];
> etc.;
>
> [pool drain];
> return 0;
> }
> void quit_data( void * ptrFrom_setup_data )
> {
> [(ObjcCode *)ptrFrom_setup_data release];
> }
>
> -- GG
>
>
> ___
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/tom.davie%40gmail.com
>
> This email sent to tom.da...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Calling a Cocoa library from C
Nathan Sims wrote:
Hmm, if not a global, where would the declaration go? The C
function certainly shouldn't return it, so if it is to remain
persistent across calls, wouldn't the logical (the only?) place for
it be as a global in the library's .m file?
Why shouldn't the C function return it? As far as C is concerned, an
object pointer is just an opaque pointer. Handle it like any other
opaque pointer.
Example:
void * setup_data()
{
return (void *) [[ObjcCode alloc]init];
}
int get_float_data( void * ptrFrom_setup_data, float *result1, float
*result2)
{
ObjcCode *obj = (ObjcCode *) ptrFrom_setup_data;
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[obj call];
*result1 = [more stuff];
etc.;
[pool drain];
return 0;
}
void quit_data( void * ptrFrom_setup_data )
{
[(ObjcCode *)ptrFrom_setup_data release];
}
-- GG
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
NSBitmapImageRep and alpha channel
The document for NSBitmapImageRep says the following: "Alpha Premultiplication If a coverage (alpha) plane exists, a bitmap’s color components are premultiplied with it. If you modify the contents of the bitmap, you are therefore responsible for premultiplying the data. For this reason, though, if you want to manipulate the actual data, an NSBitmapImageRep object is not recommended for storage. If you need to work with data that is not premultiplied, you should use Quartz, specifically CGImageCreate with kCGImageAlphaLast. Note that premultiplying does not affect the output quality. Given source bitmap pixel s, destination pixel d, and alpha value a, a blend is basically d' = a * s + (1 - a) * d All premultiplication does is precalculate a * s." First question -- what is d' in that equation? I read images from files and create histograms from them using pixel data from the NSBitmapImageRep. Things seem to work ok except for images that have an alpha channel (that is, bitsPerPixel = 32 from the NSBitmapImageRep, and an alpha channel is present). The histograms in that case have gaps in them (certain levels seem to be under-represented). Some specific images with this problem were downloaded through Image Capture and rotated in Image Capture. When an image is rotated in Image Capture, apparently the pixel data is rotated and the Exif Orientation tag is changed to reflect the rotation. (This is different from what I thought Apple said in previous documentation. I thought just the Exif Orientation tag was changed, and it was up to the image display program to rotate the image). Anyway, after rotation, the order of the data is ARGB, whereas before the rotation the order was RGBA. Also, before the rotation, the alpha channel appears to be just an unused channel -- i.e. it's not really an alpha channel. Two additional questions: are the pixel data premultiplied with the alpha channel? Also, for a histogram, should the data be premultiplied with alpha? That is, should the histogram reflect the alpha? Thanks for any help. 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Calling a Cocoa library from C
On Nov 12, 2011, at 12:01 PM, Nathan Sims wrote: > Hmm, if not a global, where would the declaration go? The C function > certainly shouldn't return it, so if it is to remain persistent across calls, > wouldn't the logical (the only?) place for it be as a global in the library's > .m file? Not necessarily. For example, if your C library already allocates some kind of ‘context’ structure, you could add an ObjcCode* variable to that struct to store the object reference. I’m just pointing this out because using global variables in a library can create problems for thread-safety and re-entrancy. It’s often considered better design to put the library’s data into some struct/object that can be managed by the caller, so there could be a separate one for each thread or for independent clients. —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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Calling a Cocoa library from C
On 12 Nov 2011, at 18:45, Nathan Sims wrote:
> On Nov 12, 2011, at 10:56 AM, Thomas Davie wrote:
>> Okay, does this mean that an object instantiated by a C function has
>> persistence across C function calls? In the example above you have:
>> [objcCode call];
>> I'm guessing I would have to have:
>> ObjcCode *objcCode;
>> declared globally in the library, and that would suffice?
>
> Declared somewhere certainly – I would highly recommend against it being a
> global though for all the usual reasons to avoid globals.
Hmm, if not a global, where would the declaration go? The C function certainly
shouldn't return it, so if it is to remain persistent across calls, wouldn't
the logical (the only?) place for it be as a global in the library's .m file?
Something like this:
mylibrary.m:
-
#import "ObjcCode.h"
ObjcCode *objcCode;
. . .
int setup_data()
{
objcCode = [[ObjcCode alloc]init];
return 0;
}
int get_float_data(float *result1, float *result2)
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[objcCode call];
*result1 = [more stuff];
etc.;
[pool drain];
return 0;
}
int quit_data()
{
[objcCode release];
objcCode = nil;
return 0;
}
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Calling a Cocoa library from C
On Nov 11, 2011, at 8:34 PM, Charles Srstka wrote:
> On Nov 11, 2011, at 8:22 PM, Wim Lewis wrote:
>
>> On Nov 11, 2011, at 5:49 PM, Nathan Sims wrote:
>>> (OSX 10.6.8, Xcode 3.2.6)
>>
>> int get_float_data(float *result1, float *result2)
>> {
>> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>> @try {
>> [objcCode call];
>> *result1 = [more stuff];
>> etc.;
>> } @catch {
>> fprintf(stderr, "omg doomed!\n");
>> etc.;
>> } @finally {
>> [pool drain];
>> }
>>
>> return blahblah;
>> }
>
> In this day and age, you should probably just use @autoreleasepool instead of
> NSAutoreleasePool:
Note: use of Xcode 3.2.6.
@autoreleasepool is not available there. I believe it requires Xcode 4.2 and
LLVM (Clang) 3.0.
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Calling a Cocoa library from C
On Nov 12, 2011, at 10:45 AM, Nathan Sims wrote: > Okay, does this mean that an object instantiated by a C function has > persistence across C function calls? Yes. Think of Objective-C references as pointers to opaque structs, and treat them like any other generic pointer variable. You can store them in globals, locals, statics, struct fields, etc. Just be careful about retain/release guidelines, i.e. if you’re storing a reference to an object in something other than a local variable, you’d better retain it first (and release it when you’re done.) —Jens smime.p7s Description: S/MIME cryptographic signature ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Calling a Cocoa library from C
On 12 Nov 2011, at 18:45, Nathan Sims wrote:
> On Nov 11, 2011, at 6:22 PM, Wim Lewis wrote:
>
>> int get_float_data(float *result1, float *result2)
>> {
>> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>> @try {
>> [objcCode call];
>> *result1 = [more stuff];
>> etc.;
>> } @catch {
>> fprintf(stderr, "omg doomed!\n");
>> etc.;
>> } @finally {
>> [pool drain];
>> }
>>
>> return blahblah;
>> }
>
> Wow, I didn't realize how integrated C and Objc are, that you could employ
> Objc code from a C function. Kewl.
Strictly speaking, this is an objective-c function. But, Objective-C is a
superset of C – this means that all valid C programs are valid objective-c
programs with the same meaning. In this case, the C function definition syntax
has the same meaning when you're writing objective-c, only now we can make
objective-c calls, and use objective-c exception catching because we're writing
objective-c.
As someone else mentioned, this should now be written with the @autoreleasepool
directive.
> Okay, does this mean that an object instantiated by a C function has
> persistence across C function calls? In the example above you have:
>[objcCode call];
> I'm guessing I would have to have:
>ObjcCode *objcCode;
> declared globally in the library, and that would suffice?
Declared somewhere certainly – I would highly recommend against it being a
global though for all the usual reasons to avoid globals.
Tom Davie___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Calling a Cocoa library from C
On Nov 11, 2011, at 6:22 PM, Wim Lewis wrote:
> int get_float_data(float *result1, float *result2)
> {
> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> @try {
> [objcCode call];
> *result1 = [more stuff];
> etc.;
> } @catch {
> fprintf(stderr, "omg doomed!\n");
> etc.;
> } @finally {
> [pool drain];
> }
>
> return blahblah;
> }
Wow, I didn't realize how integrated C and Objc are, that you could employ Objc
code from a C function. Kewl.
Okay, does this mean that an object instantiated by a C function has
persistence across C function calls? In the example above you have:
[objcCode call];
I'm guessing I would have to have:
ObjcCode *objcCode;
declared globally in the library, and that would suffice?
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: How to determine if there is an internet connection available?
On Nov 11, 2011, at 6:39 PM, Vojtěch Meluzín wrote: > I'm using BSD sockets for some internet access, it works fine. But if there > is no connection available, it waits for say 30 seconds completely stopping > the application. Is there a way to determine if there is actually an > internet connection, so that I can check before using sockets? If there really is no active network interface, then making a socket connection will immediately fail with an error something like “no route to host”. The situation you’re seeing is more likely one where the link is up, but has trouble connecting upstream — for example, your WiFi router is working but the cable modem is down, or you have one bar of cell signal but can’t get enough packets through to establish a connection. In that case the situation is out of your device’s control; it has no idea what is going to happen to packets that it sends to the network, so it can’t tell you whether a network connection will work or not. (An interesting intermediate situation is one where you do have an Internet connection, but not to the address you want to connect to. For example, you want to talk to an intranet server behind a firewall but the VPN tunnel isn’t up. This is why questions like “is there actually an Internet connection?” aren’t meaningful.) So the general rules are: 1. Use the SystemConfiguration API to find out whether the host you’re interested in is potentially reachable, i.e. any network interface is up. You can either ask directly or set up notifications. 2. If you’re calling an API that wants a raw IP address, resolve the hostname asynchronously or on a background thread, since otherwise the DNS lookup could lock up your thread for some time waiting for an upstream resolver to reply. 3. Try to make a connection. Do this asynchronously or on a background thread. Never do synchronous network I/O on the main thread. 4. If the connection fails, assume you’re currently offline, and retry only after the network configuration changes or the user requests a reconnect. —Jens smime.p7s Description: S/MIME cryptographic signature ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: capturing self is likely to lead to a retain cycle ..
ARC doesn’t know in the context of that method what will happen to the
block. Each method lives in a vacuum with retain counts being consistent at
the beginning and end. So, even though you know that the block will be
released, that’s not clear in the context of the method. I would recommend
the approach of a weak reference to self.
Jeff Kelley
On Sat, Nov 12, 2011 at 3:14 AM, Roland King wrote:
> I have a UIViewController which is presented modally, it has a textfield
> which allows editing and a model object, call it foo, on which it can
> attempt to set the 'topicName' property. Because I'm dealing with
> UIDocument(s) and trying to be nicely iCloud compatible and the topic name
> change does require a background call, the setTopicName: method cannot
> directly return YES or NO, it has a completionHandler which runs after the
> operation is attempted (and on the main thread). I'm using that completion
> handler to either pop up an alert sheet saying it failed, or call the
> onCancel: method of myself to dismiss the modal window.
>
> With the code below I'm getting a warning "Automatic Reference Counting
> Issue: Capturing 'self' strongly in this block is likely to lead to a
> retain cycle", but I don't see why. I understand that 'self' is retained by
> the block, but after the block runs, it should be released again. I've
> re-read the ARC guide and understand why, if you set a block as a property
> of yourself and that block uses self, it can cause a retain cycle, but I'm
> not setting this block as a property and I don't see how, for an anonymous
> block which is passed down the call chain and run, there would be a retain
> cycle.
>
> Am I missing the blindingly obvious, or is ARC just being very cautious
> about ANY block retaining self and suggesting I use another pattern? I can,
> I can easily set up a weak reference to myself just before the block and
> use it .. I just want to understand why.
>
>
> -(BOOL)textFieldShouldReturn:(UITextField*)textField
> {
>[ foo setTopicName:[ textField text ]
> completionHandler:^(BOOL)success{
>
>if( !success )
>{
>// present an alert sheet
>}
>else
>{
>// onCancel is also the callback from the 'cancel'
> button and dismissed this modally presented viewcontroller
>[ self onCancel:nil ]; // <-- ARC not too happy
> with this
>}
>} ];
> }___
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/slaunchaman%40gmail.com
>
> This email sent to slauncha...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Calling a Cocoa library from C
Le 12 nov. 2011 à 03:34, Charles Srstka a écrit :
> On Nov 11, 2011, at 8:22 PM, Wim Lewis wrote:
>
>> On Nov 11, 2011, at 5:49 PM, Nathan Sims wrote:
>>> Newb question. I need to create an OS X Cocoa library that is going to be
>>> called from a C program. The C program's interface will be simple, along
>>> the lines of:
>>>
>>> retval=get_float_data(&float1,&float2);
>>>
>>> where get_float_data() is a function that resides in the Cocoa library and
>>> invokes Objc code to generate and return two float values to the caller.
>>>
>>> I'm unclear on how to architect this. Can a C function invoke Objc methods?
>>> (OSX 10.6.8, Xcode 3.2.6)
>>
>> Yes. There's no real barrier between the two (even less of a barrier than
>> there is between C and C++). Everything works as you'd expect.
>>
>> Unless your calling program is being invoked from other ObjC code (like an
>> application's event loop), you may want to put an autorelease pool and an
>> exception-catching block in the called C function. The autorelease pool will
>> make sure that temporary objects created in the ObjC code get deallocated
>> when get_float_data() returns, and although exceptions can propagate through
>> C functions you probably want to convert them into an error code or exit(1)
>> or something.
>>
>> int get_float_data(float *result1, float *result2)
>> {
>> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>> @try {
>> [objcCode call];
>> *result1 = [more stuff];
>> etc.;
>> } @catch {
>> fprintf(stderr, "omg doomed!\n");
>> etc.;
>> } @finally {
>> [pool drain];
>> }
>>
>> return blahblah;
>> }
>
> In this day and age, you should probably just use @autoreleasepool instead of
> NSAutoreleasePool:
>
> int get_float_data(float *result1, float *result2)
> {
> @autoreleasepool {
> [objcCode call];
> *result1 = [more stuff];
> etc.;
> }
>
> return blahblah;
> }
Note that this code is not equivalent with the previous one. @autoreleasepool
does not drain on exception.
-- Jean-Daniel
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: How to determine if there is an internet connection available?
Le 12 nov. 2011 à 04:41, Conrad Shultz a écrit : > On 11/11/11 6:39 PM, Vojtěch Meluzín wrote: >> Hi, >> >> I'm using BSD sockets for some internet access, it works fine. But if there >> is no connection available, it waits for say 30 seconds completely stopping >> the application. Is there a way to determine if there is actually an >> internet connection, so that I can check before using sockets? > > (This has been extensively discussed in the past in the context of iOS > network availability. Search the archives for more info.) > > The only reliable way to verify connectivity is to attempt a connection. > Checking for physical connectivity might speed up failure detection > (assuming you don't care about connections on the loopback interface), > but there are a host (no pun intended) of reasons that you still might > not be able to connect. > > However, there are other options. > > For one, since you are using BSD sockets (and I have to ask: are you > sure that a higher level API wouldn't accomplish what you need?), you > can use setsockopt() to control various timeouts. One of the Darwin or > networking lists might be of more assistance at this level of the > application. > > More worrying is your statement that the wait "completely [stops] the > application." Are you saying that you are blocking the main thread > while waiting on I/O? This is almost always a bad idea in a > user-interactive application. The BSD sockets API is thread-safe (when > accessed from a single thread), so you could spawn a separate network > thread. I believe there is also a non-blocking mode within the sockets > system, but people on the Darwin list would be more helpful here. > > If you are able to use higher level APIs, life becomes somewhat easier. > One level up, using CFNetwork, Apple has detailed documentation about > how to handle this issue > (http://developer.apple.com/library/mac/#documentation/Networking/Conceptual/CFNetwork/CFStreamTasks/CFStreamTasks.html#//apple_ref/doc/uid/TP30001132-CH6-SW19). > And if you find that CFStream does not fit your need (to high level for your purpose), you can just wrap you BSD socket into a CFSocketRef, and schedule it on the current run loop. -- Jean-Daniel ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
capturing self is likely to lead to a retain cycle ..
I have a UIViewController which is presented modally, it has a textfield which
allows editing and a model object, call it foo, on which it can attempt to set
the 'topicName' property. Because I'm dealing with UIDocument(s) and trying to
be nicely iCloud compatible and the topic name change does require a background
call, the setTopicName: method cannot directly return YES or NO, it has a
completionHandler which runs after the operation is attempted (and on the main
thread). I'm using that completion handler to either pop up an alert sheet
saying it failed, or call the onCancel: method of myself to dismiss the modal
window.
With the code below I'm getting a warning "Automatic Reference Counting Issue:
Capturing 'self' strongly in this block is likely to lead to a retain cycle",
but I don't see why. I understand that 'self' is retained by the block, but
after the block runs, it should be released again. I've re-read the ARC guide
and understand why, if you set a block as a property of yourself and that block
uses self, it can cause a retain cycle, but I'm not setting this block as a
property and I don't see how, for an anonymous block which is passed down the
call chain and run, there would be a retain cycle.
Am I missing the blindingly obvious, or is ARC just being very cautious about
ANY block retaining self and suggesting I use another pattern? I can, I can
easily set up a weak reference to myself just before the block and use it .. I
just want to understand why.
-(BOOL)textFieldShouldReturn:(UITextField*)textField
{
[ foo setTopicName:[ textField text ] completionHandler:^(BOOL)success{
if( !success )
{
// present an alert sheet
}
else
{
// onCancel is also the callback from the 'cancel'
button and dismissed this modally presented viewcontroller
[ self onCancel:nil ]; // <-- ARC not too happy with
this
}
} ];
}___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: 2 itunesconnect questions
On Nov 11, 2011, at 16:59 , April wrote: > That's why the meaningless name in my email even though by and large I do not > use a pseudonym anywhere else in the world. AFAIK, there is not and never has been any standard of etiquette for this list that forbids or even frowns upon the use of pseudonyms. In fact, I distinctly remember an occasion, a couple of years ago, where the list moderator chastised a list member for chastising another list member for posting under an obvious pseudonym. The value of the list is in the interchange of technical ideas, and the form of self-identification used by each contributor belongs within the discretion of that contributor, I'd say. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
