Re: Is it 'normal' that scrolling in a UIScrollView leaks some bytes?
I believe this is a known bug in UIScrollview (search for strdup leak in UIScrollview). Wouldn't hurt to file a bug with Apple (which will probably be marked a duplicate). Aaron On Jul 24, 2012, at 10:28 AM, Richard Altenburg (Brainchild) wrote: I can answer it myself: no, it should not be considered normal that an app leaks memory, and that is why it makes me quite nervous. What happens is this: In an iPad / iPhone project I present a few UIImageViews on-screen. They are contained within their own UIScrollViews as I want to zoom in and out and scroll on them. I still have to work in the iOS Simulator because I am waiting for approval to provision my devices, but still testing seems to work fine. I can display images inside the views, and using keyboard modifiers I can emulate the standard gestures for zooming and scrolling, which al works perfectly. Sometimes, just sometimes, when I scroll an image beyond its content size (you can see the animating bouncing back and forth of the image inside the UIScrollView), Instruments reports a memory leak of only small number of bytes. These are not leaked images I created, it must be something deeper within the UIKit I guess. It tells me something like this: Leaked Object: Malloc 48 Bytes Address: any pointer to the leaked 48 Bytes Size: 48 Bytes Responsible Library: libsystem_c.dylib Responsible Frame: strdup Do you guys recognize this behavior? And should I get that nervous, or is it not an issue at all? (That is highly unlikely but I can ask, right?) Thank you for any insights. [[[Brainchild alloc] initWithName:@Richard Altenburg] saysBestRegards]; ___ 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/eeyore%40monsterworks.com This email sent to eey...@monsterworks.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: False positive on writeToURL:atomically:encoding:error: ?
In general, it is not safe to assume that errors from Cocoa frameworks are
cleared when an operation succeeds (in fact, I believe that they they are
almost never cleared). The only way to determine if writeToURL succeeds is to
test the return value (not the error). If the return value is YES, the error is
garbage. If the return value is NO, the error will have meaning.
NSError *error = nil;
BOOL success = [content writeToURL:aURL atomically:YES encoding:encoding
error:error];
if (!success)
{
[NSApp presentError:error];
return NO;
}
Aaron
On Jun 23, 2012, at 10:50 AM, Martin Hewitson wrote:
Dear list,
I have an interesting bug report from a user of an app of mine. The app
manages files and allows the user to edit them. When they save the project
each file is saved to disk (if necessary). They are experiencing what appears
to be a false positive of writeToURL:atomically:encoding:error:. The file
actually does save, but the error comes back non-nil and when presented says:
You don’t have permission to save the file “XXX” in the folder “YYY”.
The piece of code I use is
NSError *error = nil;
[content writeToURL:aURL atomically:YES encoding:encoding error:error];
if (error) {
[NSApp presentError:error];
return NO;
}
By giving the user a debug version of the app with lots of NSLog statements,
we narrowed it down to the above code. So even though the file is saved,
'error' comes back non-nil.
Has anyone seen such behaviour before, or does anyone have any idea how to
further investigate this?
Best wishes,
Martin
___
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/eeyore%40monsterworks.com
This email sent to eey...@monsterworks.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: self.myTextField.stringValue = @ fails
There's definitely a nil being passed somewhere it shouldn't, I don't have any insights on that based on what was posted. However, I don't think @ will be nil (at least it isn't in Xcode 4.3.2 for iOS 5.1): NSString* theString = @; NSLog(@%p, theString); prints 2012-05-08 09:54:20.270 iSplit[1450:15503] 0x235f24 Aaron On May 8, 2012, at 9:28 AM, Charlie Dickman wrote: Read the message... Catchpoint 7 (exception thrown).2012-05-08 18:09:31.742 MyApp[18775:507] Invalid parameter not satisfying: aString != nil On May 8, 2012, at 12:15 PM, Antonio Nunes wrote: Catchpoint 7 (exception thrown).2012-05-08 18:09:31.742 MyApp[18775:507] Invalid parameter not satisfying: aString != nil @ is the nil string and the compiler is smart enough to make the substitution. Charlie Dickman 3tothe...@comcast.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/eeyore%40monsterworks.com This email sent to eey...@monsterworks.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: monitoring changes in a local property
Roland's right about ARC, you just need the set and copy. Just for the record,
I don't think the pattern you present is safe when newSelection equals
mySelection (as you release before you copy), you need something like one of
the following:
if (mySelection != newSelection)
{
[mySelection release];
mySelection = [newSelection copy];
}
OR
[mySelection autorelease];
mySelection = [newSelection copy];
OR
oldSelection = mySelection;
mySelection = [newSelection copy];
[oldSelection release];
Aaron
On May 7, 2012, at 8:38 PM, Koen van der Drift wrote:
On May 7, 2012, at 11:28 PM, Roland King wrote:
-(void)setMySelection:(NSArray*)newSelection
{
// set whatever instance variable you have for mySelection,
with appropriate memory management if necessary
I thought about that too, but how do I do that when using ARC? Can I still do
this:
[mySelection release];
[mySelection = [newSelection copy]];
or something along those lines?
- 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/eeyore%40monsterworks.com
This email sent to eey...@monsterworks.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: How is this an incorrect decrement of a reference count?
I think the link was to the Resource Programming Guide which covers both Mac OS X and iOS. You will want to look at page 17 in the PDF Legacy Patterns. If you follow David's advice and want to try Heap Shot analysis, there's a good introduction here: http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/ Aaron On Mar 20, 2012, at 10:55 AM, David Duncan wrote: On Mar 20, 2012, at 10:48 AM, G S wrote: I *am not* releasing the IBOutlets in dealloc, and have yet to see a leak in Leaks as a result. For a myriad of arcane reasons it is fairly difficult to see UIView (or CALayers) in Leaks. That doesn't mean they will eventually be deallocated. I would look into using Heap Shots to see what you are losing by not releasing your outlets in -dealloc. -- David Duncan ___ 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/eeyore%40monsterworks.com This email sent to eey...@monsterworks.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: How is this an incorrect decrement of a reference count?
On Mar 20, 2012, at 12:19 PM, Eeyore wrote: I think the link was to the Resource Programming Guide which covers both Mac OS X and iOS. You will want to look at page 17 in the PDF Legacy Patterns. Sorry, I meant: You will want to look at the section Legacy Patterns on page 17 of the PDF version of the Guide. There isn't a Legacy Pattern PDF. Aaron ___ 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: further confusion regarding the release of controls loaded from a nib
The material quoted is post-ARC usage (not the use of weak and not assign). In the legacy paradigm material, you will see that pre-ARC. You can choose retain or assign (or copy, but I'll leave that out here). iOS outlets should be held as retain, and therefore need to be nil-ed in viewDidUnload (so that they can be released in low memory situations) and released in dealloc (or they will leak). You probably don't want to use assign because then if your view unloads, your outlets will be pointing at garbage until your view is reloaded. In iOS 4 ARC, the choices are strong (retain equivalent), unsafe_unretained (assign equivalent). Here, outlets should be strong but you will no longer need to call release in dealloc since ARC handles that. You will need to nil them in viewDidUnload (so that they can be released in low memory situations). You probably wouldn't want to use unsafe_unretained for the same reasons as above. In iOS 5 ARC, you can also use weak. Weak acts like assign except that the references will be automatically nil-ed when the object is released. Here, outlets should be weak. So when your view gets unloaded, your outlets will get deallocated (as you aren't holding on to them with strong), but ARC will magically nil your outlets so there is no chance that you will try access a zombie. Aaron On Mar 20, 2012, at 1:49 PM, G S wrote: The Apple doc for iOS says: From a practical perspective, in iOS and OS X outlets should be defined as declared properties. Outlets should generally be weak, except for those from File’s Owner to top-level objects in a nib file (or, in iOS, a storyboard scene) which should be strong. Outlets that you create should will therefore typically be weak by default because: Outlets that you create to, for example, subviews of a view controller’s view or a window controller’s window, are arbitrary references between objects that do not imply ownership. This just adds more confusion. If the properties for the majority of IBOutlets are weak (since they're usually all going to be owned by the UIViewController's view), why would we release them in dealloc? That seems like an error. And setting them all to nil in viewDidUnload wouldn't seem to have any effect, other than simply being good practice for safety. ___ 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 is this an incorrect decrement of a reference count?
for any insight. ___ 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/eeyore%40monsterworks.com This email sent to eey...@monsterworks.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: How is this an incorrect decrement of a reference count?
On Mar 19, 2012, at 4:27 PM, G S wrote: That reminds me of another question, though: Someone earlier mentioned the need to release elements loaded from the nib, in dealloc. I didn't think this was necessary, so I don't do it. And there are no apparent leaks as a result. What's the story on that? I may have been the one to suggest this. When I made that statement, I was thinking of pre-ARC iOS programming. See Greg's link for the correct answr for your case. Aaron ___ 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: There's obviously something I don't understand about NSDate.
I believe you were also on the discussion of properties vs. direct ivar access. This ties into that discussion. If you declare/define a property with: @property (nonatomic, retain) NSDate* firstBadAccuracyTime; and @synthesize firstBadAccuracyTime=_firstBadAccuracyTime; then the runtime will automatically retain the value in the setter, allowing you to make a call: self.firstBadAccuracyTime = [NSDate date]; You would still need to release the object in dealloc [_firstBadAccuracyTime release] If you are using ARC, the property would be @property (nonatomic, strong) NSDate* firstBadAccuracyTime; the synthesize and set statements would be the same, but you would not be required to make the release call in dealloc. By using direct ivar access, you are taking the responsibility to handle the memory management yourself, meaning you really need to understand autorelease pools (see references in other posts). Aaron On Mar 17, 2012, at 3:38 PM, G S wrote: I have a member variable to hold an NSDate: NSDate* _firstBadAccuracyTime; At some point, something happens and I set this value to now: _firstBadAccuracyTime = [NSDate date]; On my next trip through this function, I calculate how long it has been since I set this date: NSDate* now = [NSDate date]; if([now timeIntervalSinceDate:_firstBadAccuracyTime] BAD_ACCURACY_TIME) then CRASH: BAD ACCESS _firstBadAccuracyTime still contains a valid address, but the object must've been released. Why? If I add a retain where I assign it, the crash doesn't happen. I added autorelease, but then got a crash on releasing an object I hadn't allocated (which makes me think it's already autoreleased). Thanks for any insight! Gavin ___ 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/eeyore%40monsterworks.com This email sent to eey...@monsterworks.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: There's obviously something I don't understand about autorelease.
On Mar 17, 2012, at 6:10 PM, Richard Somers wrote: On Mar 17, 2012, at 6:12 PM, Roland King wrote: So often I find I start with @synthesize foo=_foo; and by the time I get to the end of the project I've written custom foo: and setFoo: methods which do something else too. I have also done that but I recently read a blog where the writer recommends Do not override @synthesized properties with your own code: use @dynamic properties instead http://wiki.akosma.com/Objective-C_Code_Standards I would be curious if anyone else has an opinion on that one way or the other. If you define methods foo and setFoo:, you don't need to use @dynamic or @synthesize (but I doubt it hurts). I think @dynamic tends to be used in situations where you want to promise the compiler that these will be implemented, but the compiler cannot determine that while parsing the source (I think these arise in Core Data). Aaron ___ 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: Why so many public properties all up in my grizzle?
David Duncan indicates that some of this can be alleviated with newer runtimes, but Objective C's messaging system allows you to send messages to objects even if those messages are not declared in the object's interface. So simply hiding the actions in the implementation doesn't protect you from finding out the method's name and calling it. Another issue (not Obj-C specific) is that all the frameworks that I've used that connect graphically developed UIs with code required the classes to expose the point of connection. Your completely coded example is a little more protected from malicious coders, but not completely, as a hacker would still have access to the controller's view and could walk the subviews making changes. The convenience I get by being able to lay my views out graphically comes at the expense of requiring me to expose my outlets (so that the system can connect my code and my nib). I don't think there could be any way for the system to make those connections without making the outlets publicly available. Specific comments on your example, below: On Mar 16, 2012, at 2:00 PM, Brian Lambert wrote: #import UIKit/UIKit.h // MyViewController interface. @interface MyViewController : UIViewController // Properties. @property (weak, nonatomic) IBOutlet UILabel * labelMyLabel; I suspect that the UILabel ought to be strong, but that's not really the topic here. // buttonDoItTouchUpInside action. - (IBAction)buttonDoItTouchUpInside:(id)sender; @end This means that my UILabel called labelMyLabel is publicly available. Anyone who has access to an instance of MyViewController can do anything they want to with my label, including replacing it. In your implementation, you (probably) have something like @synthesize labelMyLabel=_labelMyLabel; This means that labelMyLabel may be public but the actual data _labelMyLabel is private. If you are really concerned about someone tinkering with the labelMyLabel, you can try to intercept access to labelMyLabel by implementing your own custom getter/setter. But if you want the runtime to connect your label to your class, you are going to need to allow outsiders to set your label at some point (possibly repeatedly as your view unloads and loads due to memory warnings). Also, anyone who has an instance of MyViewController can call my buttonDoItTouchUpInside action. If you don't want to expose this, then you can expose the button through a IBOutlet and manually connect the action in viewDidLoad. I actually prefer to connect actions manually because then if I have multiple nibs for the same class (e.g., an iPhone and an iPad nib for the same controller), I don't have to try to remember to set all the actions, just the outlets. Everyone, all the books, training materials, samples, and so on, just seem to accept this style of doing things as being normal. In fact, one book I read *encouraged* this technique of using public properties for ALL the internal state of a class over using ivars. It said public properties were preferable. The ivars are your data, the properties are just getter/setter methods that access that data (with some syntactic sugar that makes it look like data access). I would guess that the author was suggesting to make all data access go through getter/setter properties instead of direct ivar access. I think they were comparing public property vs. public ivar and proposing the use of public properties (getter/setters) instead of direct data manipulation. Aaron ___ 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: Newbie Q: how print NSArray element from Xcode's debugger?
From source, NSLog(@%@, object); will print out the description of most Cocoa objects, including NSArrays. You can get the same description from within gdb/lldb using po (for print object), po object Aaron On Mar 15, 2012, at 2:32 PM, Bill Doster bil...@umich.edu wrote: short of adding code to load the value into a vanilla-C type variable... TIA, Bill ___ 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/eeyore%40monsterworks.com This email sent to eey...@monsterworks.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: String Constants the solution
On Mar 8, 2012, at 4:29 PM, Prime Coderama wrote:
I have references to 'ground' and 'air' in multiple files. It is usually used
in this context, but not always.
if ([transport.type isEqualToString:@ground]) {
// do something for automobiles
}
else if ([transport.type isEqualToString:@air]) {
// do something else for planes
}
else {
// we don't care
}
Should I be using string constants to represent 'ground' and 'air' so if I
ever change their literal, I just update it in one place? e.g.
NSString * const TransportGround = @ground;
NSString * const TransportAir = @air;
I then decide I want to rename 'ground' to be 'wheels', then I would only
update the above string constant.
I would say yes, partially so you only have one place to update it and
partially so you don't end up with typos, e.g., if ([transport.type
isEqualToString:@gound]).
Depending on your situation, subclassing could use the objects class to
indicate its type and reduce the number of if-elseif blocks.
Or you might try a typedef-ed enum instead of strings so you could use plain ==
for comparison. The typedef would also allow you to use switch statements so
that if you add a new transportation mode (e.g., water), you can get the
compiler to warn you if you aren't handling it (assuming you set the
appropriate flags and don't use a default case). However, you need to be
careful since Objective C typedefs aren't as carefully checked as C++ typedefs
(at least I don't think they are).
Aaron
___
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: [Obj-C] if (self) vs. if (self != nil)
I think you can turn it off, but I think you can also use double-()'s to
suppress it:
if ((self = [super init]))
On Feb 26, 2012, at 5:40 PM, Graham Cox wrote:
On 27/02/2012, at 12:13 PM, William Squires wrote:
I prefer the if (self = [super init]) combined form, myself.
One potentially annoying thing about this form is that, if you compile with
plenty of warnings on, such as the possible unintended assignment warning (if
not, why not?) then this flags a warning.
Apple recommend:
self = [super init];
if( self )
{
...
}
Anyway, this seems to be one of those tiny trivial issues that people seem to
get very religious about. It takes a second to type in any form, so what's
the big deal?
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/eeyore%40monsterworks.com
This email sent to eey...@monsterworks.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: Block Confusion...
On Jan 31, 2012, at 3:49 PM, R wrote: David, Class B is a parser. It is passed NSData to parse (weak reference) and the Array (weak reference) from Class A. The results of the Data parse are placed into the Array. Class A will be around for the life of the application. Class B will be released (set to nil) after completing the parse. I chose this approach rather than delegation. Thoughts? I've been following skimming this thread and I think I would pass the NSData and the Array into the parser as strong references. It doesn't look like there is any chance of a cycle being created and the extra call to retain/release isn't an optimization to make until you start profiling. Even if you eventually decide to use weak references (after discovering the retain/release calls are a drag on performance), making them strong references now to see if that fixes the behavior can help you diagnose the problem. If strong references solve the obvious problem (the nil object), then you should question your assumptions about lifetimes of your objects. Aaron ___ 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: NSDateFormatter -initWithDateFormat:: vs. -init
I think there was a similar discussion on this list earlier this year (maybe late last year). IIRC, the conclusion was that init was removed from the documentation since it is inherited from its superclass' superclass (NSObject) and doesn't do anything exceptional in NSDateFormatter, however it is still the designated initializer for NSDateFormatter. Aaron On Nov 11, 2011, at 5:40 PM, Dave DeLong wrote: I think you've misunderstood the documentation. -init is the preferred method for creating 10.4+ date formatters. http://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSDateFormatter_Class/Reference/Reference.html#//apple_ref/occ/instm/NSDateFormatter/initWithDateFormat:allowNaturalLanguage: Dave Sent from Jane On Nov 11, 2011, at 5:36 PM, Jerry Krinock je...@ieee.org wrote: NSDateFormatter documentation indicates that -initWithDateFormat:allowNaturalLanguageString: is the recommended initializer for new designs, and furthermore that -init is not available after 10.5. ___ 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: IBOutlet getter/setter pattern question
Thanks Matt, was kind of hoping you would provide some insight (your responses to others have been helpful). Very ingenious, but doesn't it leave a lot of stuff lying around that is just an accident waiting to happen? You are assuming that setLabel: will be called only by the nib-loading mechanism; but how do you know? Someone else can call setLabel: later and get very weird results. I guess that was my question. When I declare something as an IBOutlet, am I exposing it to others? If I'm the only one to access it, then only I can shoot myself in my foot. However, the question is now moot, see below. How about giving the label, if created in the nib, a tag number (how much trouble can that be, since you had to go into the nib in order to make the label in the first place) so that no ivar is needed in order to find it? I haven't used tags enough in the past to think of it, but this appears to be the solution. Aaron ___ 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: IBOutlet getter/setter pattern question
Thanks, I guess the situation is that I really want a writeonly property. I don't ever need to read the outlet, I just want to do some adjustments when the property is first set (in this situation, when the nib is loaded). The old style shouldn't look too weird. It is just using @synthesize to create the getter/setter along with all the UIViewController code necessary for memory management of an IBOutlet (which is what I'm trying to avoid both to reduce the amount of code and to reduce the number of retained pointers I need to keep track of). Aaron On Oct 17, 2011, at 2:56 PM, Jerry Krinock wrote: I don't quite understand your special situation. Both your old and new style accessors look weird. But the new is definitely better. Go for it. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/eeyore%40monsterworks.com This email sent to eey...@monsterworks.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
IBOutlet getter/setter pattern question
I noticed that I many of my IBOutlets were only being used to modify the view
from the viewDidLoad methods but which were not accessed later in my code.
These outlets exist so that I can keep consistent appearance settings in a
large number of nibs without actually editing each nib. As a simplified example
(typed into Mail, but should describe the pattern), consider the following.
- begin old style -
@interface Class : UIViewController
@property (nonatomic, retain) IBOutlet UILabel* label;
@end
@implementation Class
@synthesize label=myLabel;
- (void)viewDidLoad
{
[super viewDidLoad];
self.label.textColor = kLabelTextColor;
self.label.text = NSLocalizedString(@Blah blah blah, @Label text);
}
- (void)viewDidUnload
{
self.label = nil;
[super viewDidUnload];
}
- (void)dealloc
{
[myLabel release];
[super dealloc];
}
@end
- end old style -
I have replaced this with the following:
- begin new style -
@interface Class : UIViewController
@property (nonatomic, assign) IBOutlet UILabel* label;
@end
@implementation Class
- (void)setLabel:(UILabel*)label
{
label.textColor = [UIColor lightGray];
label.text = NSLocalizedString(@Blah blah blah, @Label text);
}
- (UILabel*)label
{
NSAssert(NO, @label is inaccessible);
return nil;
}
@end
- end new style -
The new style allows me to focus on non-trivial activities in viewDidLoad,
viewDidUnload, and dealloc (sometimes even eliminating those methods) and
reduces the number of things that need to be memory managed.
So the question: anyone see any problems with this?
Aaron___
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: Retain/Release and Properties clarification
Not enough morning coffee for you, On Oct 3, 2011, at 7:29 AM, Steve Sisak wrote: You do, indeed want: self.audioPlayer = [self getSoundFile:soundfile.wav]; or [self setAudioPlayer = [self getSoundFile:soundfile.wav]]; I think you meant [self setAudioPlayer:[self getSoundFile:soundfile.wave]]; I second Steve's suggestion of giving ivars a different name than properties, especially when just learning the language. Even after you know the language, the distinction will help newbies when they need to work with the code you've written. Aaron___ 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: STAssertEquals and type-checking
I was doing the same type of casting for a little bit, but then I started to set up variables for the testing. Now I prefer to keep constants out of the STXXX macros and tend to write the tests like: NSUInteger theExpectedLength = 32; STAssertEquals(myArray.length, theExpectedLength, nil); While in some cases it does just add an extra line, in other cases (where I reuse theExpectedLength), I don't have to hunt down all those magic constants and update them individually. Aaron On Aug 16, 2011, at 10:36 AM, Jens Alfke wrote: I’ve been using the STxxx test macros lately, as they’re the path of least resistance, but I’m getting pretty frustrated with them. Worst is the way that STAssertEquals is extremely picky about types (the actual and expected parameters have to have exactly the same type), and worse, somehow manages to defer the type checking until runtime, so you only find out when you get an assertion failure. So I keep making ‘mistakes’ like: STAssertEquals(myArray.length, 32, nil); which compiles fine, but fails at runtime because -length returns an NSUInteger and 32 is an int. Changing 32 to 32u works on 32-bit but not 64-bit; the only form I’ve found that always works is the awkward STAssertEquals(digest.length, (NSUInteger)32, nil); Not surprisingly, I still forget to do this pretty often. The implementation of STAssertEquals is pretty gnarly so I haven’t dug into why it can’t do proper type-checking. I know it’s possible to, because the test macros I wrote for MYUtilities are both more lenient about types and do the checking at compile-time. Is anyone considering fixing this macro, or does anyone have a compatible version that works right? —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/eeyore%40monsterworks.com This email sent to eey...@monsterworks.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: Properties, Attributes and Retain+Autorelease
Still learning Cocoa myself, so hoping to be corrected if I'm wrong.
On Jun 29, 2011, at 10:39 AM, Markus Hanauska wrote:
Cocoa’s ownership policy specifies that received objects should typically
remain valid throughout the scope of the calling method. It should also be
possible to return a received object from the current scope without fear of
it being released. It should not matter to your application that the getter
method of an object returns a cached instance variable or a computed value.
What matters is that the object remains valid for the time you need it.
This principle is violated by a getter returning an object that is not
retain+autorelease, since even without destroying the parent the returned
object might go away. As pointed out in my other mail:
I guess I'm not sure what the debate is. Are you questioning whether Apple's
code honors the agreement? If you find an instance where Apple's code is
actually violating this agreement, then you should file a bug. Otherwise, you
should probably work under the assumption that all of Apple's getters other
than those specifically excluded will retain/autorelease and that synthesized
getters will also follow a retain/autorelease pattern.
// someObject
- (id)value
{
return value;
}
- (void)doSomething
{
// ...
[value release];
value = ...;
/ /...
}
// someOtherObject
- (void)setValue:(id)aValue
{
[someObject doSomething];
if (value == aValue) return;
[value release];
value = [aValue retain]; // --- BANG, CRASH
}
On the other hand, if you are writing your own getters and setters, of course
you can break the contract (as someObject does here). Matt Gallagher writes
about this in
http://cocoawithlove.com/2010/06/assign-retain-copy-pitfalls-in-obj-c.html
where he says that he typically does not follow a retain/autorelease but is
aware that the result would be more correct with them. If you get the
BANG-CRASH and are the author of someOtherObject, you should submit a bug to
someObject's author and then put a workaround in place, two possible examples:
[someOtherObject setValue: [[[someObject value] retain] autorelease]]; //
retain/autorelease required due to bug in [someObject value]
or possibly, use a category to extend someObject to provide a safe getter as a
work-around
- (id)safeValue
{
return [[[self value] retain] autorelease];
}
and then never use value, but use safeValue instead
[someOtherObject setValue: [someObject safeValue]];
Both workarounds would be removed when the author of someObject gets his/her
act together (either by retain/autoreleasing in the getter or by autoreleasing
in doSomething).
Aaron
___
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: Synthesised properties and additional actions
Here is a trick I saw somewhere else that might do what you need. On the other
hand, i'm still learning cocoa myself so it may have drawbacks that I'm unaware
of.
Create a private property (like internal_foo below) to handle memory. Then have
a public property to do the other stuff. So users of the class access the
property with foo and you get synthesized memory management with internal_foo.
Sent from my iPad
On Jun 18, 2011, at 10:12 PM, Graham Cox graham@bigpond.com wrote:
If I synthesize a property, is it possible to also directly invoke some other
code when that property is set (other than the usual KVO)? That is, I need to
do something like:
@synthesize internal_foo;
- (void)setFoo:(id) newFoo
{
self.internal_foo = newFoo;
[self doSomethingElseAsWell];
}
-(id) foo
{
return self.internal_foo;
}
Is this kind of thing possible? It looks to me as if the self.foo = line will
incur an infinite loop. But if the property is synthesized, to what would I
assign the new value?
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/eeyore%40monsterworks.com
This email sent to eey...@monsterworks.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: Seeding random() randomly
I've seen gnu documentation for srandom that suggest the equivalent of Kevin's suggestion, namely srandom(time(0)). Not sure if using the NSDate has any advantage over a call to time() and it would avoid this type of thing (gnu is likely to ensure time() and srandom() work correctly together). Aaron On May 26, 2011, at 8:10 PM, Chase Latta wrote: unsigned seed = (unsigned)([NSDate timeIntervalSinceReferenceDate] * 1.0); You are trying to set seed to a value that is something like 3,281,585,690,000; seed cannot handle this value so it will be set to 4294967295, at least on my machine. You are using the same seed each time you run the program so you are getting the same values. Try getting rid of the * 1.0. Chase On Thu, May 26, 2011 at 7:15 PM, Kevin Bracey ke...@ilike.co.nz wrote: I think this was from some programming book I have, sorry I can site it: srandom(time(NULL)); cheers Kevin ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/chaselatta%40gmail.com This email sent to chasela...@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/eeyore%40monsterworks.com This email sent to eey...@monsterworks.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: iOS: multiple view controllers, one nib?
I had a similar issue in my code and am unsure if my solution is correct. So if I'm doing this wrong, let me know. My strategy was to associated each custom view (MWView subclass of UITextField) with a handler (MWHandler subclass of NSObjectUITextFieldDelegate). The MWHandler is a class whose interface and implementation reside inside the MWView's implementation file, so the MWView appears to be self-contained. The MWHandler holds pointers to the MWView's subviews that the MWHandler will need to update. Controls inside the MWView that should trigger actions are set up to notify the MWHandler (with addTarget:action:forControlEvents:). You need to watch out for retain cycles (where the MWHandler retains a pointer to the MWView which retains a pointer to the MWHandler). Code available on request (unless people tell me I've done it wrong), Aaron On May 18, 2011, at 12:32 PM, Nathan Sims wrote: Hmm, but then how would each custom class communicate with the view elements? NSNotifications? On May 18, 2011, at 12:27 PM, Eric E. Dolecki wrote: I don't think so but you could always associate a custom Class with each of the UIViews to tuck most of the UIView specific code away from the view controller's code. Google Voice: (508) 656-0622 Twitter: eric_dolecki XBoxLive: edolecki PSN: eric_dolecki http://blog.ericd.net On Wed, May 18, 2011 at 3:19 PM, Nathan Sims newsli...@autonomy.caltech.edu wrote: Okay, but won't that make for one mega-complex view controller? On May 18, 2011, at 11:58 AM, Luke the Hiesterman wrote: The IB concerns aside, attempting to build your own more than one view controller on the screen solution is currently fraught with peril, and something you'll probably get wrong. The window expects to have a single rootViewController to handle rotations and such. You're probably better off having a single view controller and each of your quad views should just be regular UIViews managed by the one view controller. And, if you did that, all your views would naturally be built in the one nib that defines your view controller :) Luke On May 18, 2011, at 11:53 AM, Nathan Sims wrote: I'm writing an iPad app that has its main screen subdivided into 4 equal regions, each with a UIView, all defined in one IB nib. I have a dedicated view controller class for each view. When I instantiate the view controller class for each quadrant's view with -initWithNibName:bundle:, I have to specify the same nib name for each: quad1VC = [[Quad1ViewController alloc] initWithNibName:@QuadViewiPad bundle:nil]; quad2VC = [[Quad2ViewController alloc] initWithNibName:@QuadViewiPad bundle:nil]; quad3VC = [[Quad3ViewController alloc] initWithNibName:@QuadViewiPad bundle:nil]; quad4VC = [[Quad4ViewController alloc] initWithNibName:@QuadViewiPad bundle:nil]; Will this properly connect each quadrant's view with the corresponding view controller, or should I have just one view controller for all 4 views? ___ 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/luketheh%40apple.com This email sent to luket...@apple.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/edolecki%40gmail.com This email sent to edole...@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/eeyore%40monsterworks.com This email sent to eey...@monsterworks.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: iOS Best Practice Question
On Apr 26, 2011, at 2:51 PM, glenn andreas wrote: On Apr 26, 2011, at 4:36 PM, koko wrote: So we have one vote for: 3. Use a view in a layer of the current view Any other views (no pun intended) ... going once going twice Any comments against : 1. Use UIAlert - easy but seems clunky -koko Adding additional content in UIAlert is not recommended, since it requires a high degree of care and verges on something that can get an app rejected from the App Store. (you've got to do special casing for different versions of the OS and make bad assumptions about the layout of the subviews, and will quite likely break when the next OS release happens). In general, if you can avoid making a UIPickerView appear as the result of an action, you'll be better off. Make it part of the UI, always available, or use a different mechanism (for example, in a table view, just push a second table view onto the navigation controller and let the user select the element from that table view, just like Settings.app does, etc...) I agree that the UIAlert is not the way to go. However, I agree with koko that including a picker on the screen can feel clunky, in my case it made it feel like the date was more important than the other information in the much smaller UITextFields on the same screen. My solution was to have the date displayed in a UITextField whose inputView is set to a UIDatePicker. Tapping the text field to edit the date results in the UIDatePicker popping up instead of a keyboard and I use the UITextField's inputAccessoryView to provide a toolbar with a Set button, and an Undo button. Implementing this didn't require a lot of code (I think most of my code is there to facilitate the Undo button). I believe it feels natural to users: it looks like a text field, and acts like a text field but has a slightly unusual keyboard that limits possible input. Based on the documentation, it does appear that this is the purpose of the inputView and the inputAccessoryView, so I don't think it will run afoul of Apple's guidelines. I'm willing to provide code if requested, although the classes I'm using are tied into a larger collection of special purpose textfields so you'll need to disentangle the features you want. Aaron___ 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: Proper way to create a singleton without @synchronized ?
On Apr 17, 2011, at 12:58 PM, Quincey Morris wrote: On Apr 17, 2011, at 12:04, WT wrote: On Apr 17, 2011, at 3:52 PM, Joanna Carter wrote: Tell me; maybe it's my background in other languages, but I would tend to use a static class as a singleton; or, at least, design a class with only class methods/properties, with static fields declared in the @implementation section of a class. Why this fascination with going to all the trouble of creating a singleton rather than using the static class approach? not a fascination, but simply a preference and being used to coding that way. As for the static class idea, what happens if you need/want to subclass that class? Then you have to search for and change all the places in your code base that refer to it. 1. I've found that using the class as a singleton doesn't always serve the purpose -- though I can never remember the usage case that's a problem. The issue that recently caused me to convert a static class to a singleton was when testing my own code that relied on the singleton. I found that it was much easier to mock an object with instance variables than a class with static variables. Whether this design change was the tail wagging the dog is probably a reasonable issue to raise. Once I moved from the static class to a singleton object, I ended up taking the next step and shifting to a default object rather than a true singleton (which I think is what Quincey is addressing in his second point, quoted below). That cleaned up some code smells elsewhere, so, at least in this case, the singleton was probably the wrong pattern from the start. 2. FWIW, I'm generally with Kyle and others who are suggesting that trying to implement forced, generalized singleton-ness may be a practical un-necessity. A while back, I asked on this list whether a singleton is an object that there *is* only one of, or it's an object that there *can be* only one of. The answer, from someone whose opinion I respect (and who is almost always right) was is, not can be. Aaron ___ 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: iOS Pass NSManagedObjectContext from my app delegate
On Jan 20, 2011, at 4:46 PM, Nick Zitzmann wrote: On Jan 20, 2011, at 5:25 PM, Philip Vallone wrote: Currently, my NSManagedObjectContext is retained like this in my app delegate: @property (nonatomic, retain, readonly) NSManagedObjectContext *managedObjectContext; If you have declared the property to be read-only, then the retain keyword is not necessary. Retain and assign are only necessary if it's a read/write property, since they tell the synthesizer what to do with new values (if @synthesize is in use). I'm somewhat new to all this also, so perhaps I'm off on this one. My understanding is that using (retain, readonly) in the class interface insures that if the property is ever changed to readwrite in a category, then it must be (retain, readwrite) and not (assign, readwrite) or (copy, readwrite). Whether this guarantee is important or not probably depends on the circumstances, but there is extra information the compiler can use to catch errors when you declare it as (retain, readonly) that isn't available when you declare it as (readonly). Aaron ___ 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: NIB Object instantiation of missing class
Could you mock/stub the framework? Supply stub objects/functions that would cause failing assertions if they are ever called to do real work and simply do nothing in cases where they are harmless. That way you can silence the warnings and also test your assumption that the outlet really does live by itself and won't be noticed if removed. Aaron On Dec 1, 2010, at 9:08 AM, Markus Spoettl wrote: Hello, I have an application for which I need to create a second version that's basically the same but doesn't use a Framework the original uses. I've done this by creating a second target where I removed all references to the framework in the target setup. In a NIB file the application instantiates an object of that framework. Apart from one outlet the object lives by itself and performs tasks in a stand-alone manner, so the app actually won't miss it if it's not instantiated. I'd like to avoid duplicating the nib and removing the object because it would generate a lot of overhead (localization, maintenance, etc.) that isn't justified. Now, it seems to work, all I get is a Console log entry stating that the object class wasn't found and NSObject was used instead. An outlet connected to that object wasn't restored either which generates another log message. Other than that the application behaves correctly. The obvious question is: Is there a better way to do this (that avoids duplication of resources), or is it OK? I'm targeting 10.5 my base SDK is 10.5, so far I only tested on Snow Leopard so I'm not sure if that situation is handled gracefully in Leopard (I assume it is). Regards Markus -- __ Markus Spoettl ___ 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/eeyore%40monsterworks.com This email sent to eey...@monsterworks.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: What is Mac's custom for an agent to display its GUI?
I fumble-fingered the first message and sent it without actually typing anything. Sorry for the noise if the moderator didn't catch it. Someone may know an approved Apple method, but here are some things that are out there now you could emulate. You could have it in Applications and use a menu item to access its control panel (like Shimo, Jolt, Caffeine, BravoTunes). You could install your background app as a command-line app and have a GUI app in Applications that launches the control panel (see ClamXav for an example). You could put it in Library/Application Support and have access to the Control panel through System Preferences (like Roxio's Retrospect). Aaron On Nov 16, 2010, at 5:27 PM, eveningnick eveningnick wrote: Hello! I have to write an application, that should run on the background. When the user needs, it should display some control panel. On Windows system i would have used System tray, and an icon there - when the user clicks on that icon, it displays some GUI. but what is the Mac's usual practice? I am thinking that the analog to that tray application is an agent, launched by launchd. On what event it is considered to be good to trigger that control panel? All i could think of - is installing a global event tap (but i need accessibility Enabled then all the time - it is neither a good idea) and watch some Shortcut pressed on a keyboard. Another idea was to create an item in System preferences (but, could it be done? And how?). And where should I install that application? Installing in /Applications doesn't seem to be nice, because it's not really a full-gui applicatlion, It's rather some kind of background system helper. Thanks for the hints, George ___ 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/eeyore%40monsterworks.com This email sent to eey...@monsterworks.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 getter on const object
I'm new at this too, so perhaps I am completely off here. My guess is that it
isn't the const that is messing this up, but the non-class type. The problem I
see is that frame is a pointer to an objc_object and objc_objects aren't the
same as NSObjects (but, like I said, I'm new, so maybe they are interchangeable
here). Does it work if you try declaring frame as a NSObjectFrameProtocol
instead of an idFrameProtocol?
Aaron
On Nov 8, 2010, at 8:37 AM, Jonny Taylor wrote:
I'm afraid I'm not sure if I understand exactly what you're asking. I would
like to be able access the frame number property (which is in fact stored
as a variable within the class, and is fixed soon after instantiation) in
spite of the fact that I only have a 'const' pointer to the object at the
time I want to access it. Semantically I don't see why it should be unsafe to
attempt to find out the value of that property.
Either way, hopefully the actual code helps to answer your question:
-(void)analyzeFrameAsync:(idFrameProtocol)frame
{
int num = frame.frameNumber;// Temporary variable avoid
problems with calling method on 'frame' [const] from block
dispatch_async(analysisSerialQueue,
^{
[analyzer processFrame:frame];
self.latestFrameNumberProcessed = num; // I can't call
frame.frameNumber from within the block (compiler error)
});
}
On 8 Nov 2010, at 16:29, David Duncan wrote:
It might be useful to know what you expect to get from the const reference
in the first place? Primarily because I highly suspect that it is not
necessary to ensure the semantics that you desire.
On Nov 8, 2010, at 4:59 AM, Jonny Taylor wrote:
I have encountered what I presume is a common newcomer's problem, but I
haven't had any luck with google (maybe I'm using the wrong search terms?).
Suppose I have a const id, e.g. const idFrameProtocol frame. If I
attempt to call a getter for the object I get the following compiler error:
request for member 'frameNumber' in 'frame', which is of non-class type
'objc_object* const'
--
David Duncan
___
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/eeyore%40monsterworks.com
This email sent to eey...@monsterworks.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
