• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: CFPreferences and init.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CFPreferences and init.


  • Subject: Re: CFPreferences and init.
  • From: Adam Penny <email@hidden>
  • Date: Mon, 27 Oct 2008 00:23:57 +0100



On Oct26, 2008, at 10:40 PM, Kyle Sluder wrote:

On Sun, Oct 26, 2008 at 4:12 PM, Adam Penny <email@hidden> wrote:
This is my code for the method in question and it's used for the NSTableView
bindings:

Your code is rather disorganized. Particularly, your use of else clauses is confusing and prone to introducing logic errors.

- (void) setServers:(NSMutableArray *)a;

The Objective-C parser will allow you to have a semicolon at the end of a method implementation declaration spec. Don't do it, it's confusing. I'm also pretty sure that this behavior isn't documented anywhere.

Also, you should be asking for an NSArray, not an NSMutableArray.  By
asking for an NSMutableArray, you are implicitly telling the caller
that they may change the contents of the array from underneath you at
any time.  In a to-many relationship like this, it is almost
guaranteed that this behavior is not what you want.

I can see from the code you've written that having a mutable array is uneccesary. I get the gist the assertion you make, but I think I'd probably need to see an example to understand that properly, but as my head is spinning with what I'm doing already I'll just bow to your superior knowledge for the moment and avoid mutable arrays!
{
//Method for adding a new server, with mac address to the servers
array
if (a==servers) return;

You don't want to do this. What are the odds that the NSArray object your caller is providing is the exact same instance as the one you already have? Just leave the condition out; it will never execute in practice anyway.

      [a retain];
      [servers release];
      servers = a;

Instead of just assigning a to your ivar, use [a copy]. This goes in hand with the recommendation about the argument type above. You probably don't want to store an NSMutableArray, and if the caller has provided you an NSMutableArray, which is fine since the method just asks for an NSArray, you don't want the caller to mutate the collection your object is supposed to be tracking. If you really, *really* need your ivar to be mutable, use -mutableCopy instead of -copy.

NSArray *serversToCopy = [servers copy];

This line is obsoleted if you follow my recommendation above.

//Next line causes an exception when adding a row.
if ([servers count]!=0) CFPreferencesSetAppValue(CFSTR("servers"),
(NSArray *)serversToCopy, appID);
else CFPreferencesSetAppValue(CFSTR("servers"), NULL, appID);
else NSLog(@"It's zero!");

I don't know how this code can compile; that second else clause doesn't match up with any if statement. Is one of them commented out in your code?

You're right, that doesn't compile at all, before I'd emailed I'd been trying some things in NSLog to see where things were going wrong, just hadn't deleted the old NSLog statement. Apologies for that.
Where is appID coming from?  Is it a constant NSString somewhere, like
it should be?

So here's how I'd rewrite your method (warning, code written in the
compose window, YMMV):


[snip]
@end

From what I had read on the web about the exception I was getting I had a feeling that it might be something to do with my memory management. There's some great tips in that code you wrote, thank you very much for taking the time to put it together, it's very much appreciated. I will sleep on it and try it out in the morning.

The other thing that's confusing me is that what was an XML Plist that I did
by hand like this:
[...snip...]
has been transformed by the synchronization to this(!):

That's the binary plist representation. This will be transparent to well-behaved applications. Naughty ones will try to read the raw XML plist representation and fail, but ones that use the plist serialization API won't know the difference.

So from that, do I gather that the binary is the preferred standard for plists? I'll probably show myself up to be barmy with my next revelation, but this preference panel actually started off to set the preferences for an automatically triggered Ruby command line script that I wrote for waking up hosts that share printers automatically when a print job is sent to the printer in question. I built that to read its preferences from an apple XML type plist file. At a future date, I'd like to rewrite that as an objective-c command line utility, but for the moment Is there any way I can coerce CFPreferences to synchronize as XML rather than binary? As the script will be the only thing referring to the plist for the moment I'm not too worried about other 'naughty' applications! :-)

Take care,

Adam
_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:
This email sent to email@hidden


  • Follow-Ups:
    • Re: CFPreferences and init.
      • From: "Adam R. Maxwell" <email@hidden>
References: 
 >CFPreferences and init. (From: Adam Penny <email@hidden>)
 >Re: CFPreferences and init. (From: "Kyle Sluder" <email@hidden>)
 >Re: CFPreferences and init. (From: Adam Penny <email@hidden>)
 >Re: CFPreferences and init. (From: Jean-Daniel Dupas <email@hidden>)
 >Re: CFPreferences and init. (From: Adam Penny <email@hidden>)
 >Re: CFPreferences and init. (From: Adam Penny <email@hidden>)
 >Re: CFPreferences and init. (From: Adam Penny <email@hidden>)
 >Re: CFPreferences and init. (From: "Kyle Sluder" <email@hidden>)

  • Prev by Date: Re: Getting Styluses/Track Pad Input in Cocoa
  • Next by Date: Re: CFPreferences and init.
  • Previous by thread: Re: CFPreferences and init: a possible reason?
  • Next by thread: Re: CFPreferences and init.
  • Index(es):
    • Date
    • Thread