• 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: Efficient XML loading [continuation of NSString from mapped NSData thread]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Efficient XML loading [continuation of NSString from mapped NSData thread]


  • Subject: Re: Efficient XML loading [continuation of NSString from mapped NSData thread]
  • From: Jens Alfke <email@hidden>
  • Date: Wed, 14 May 2008 15:20:27 -0700


On 14 May '08, at 8:08 AM, Matt Gough wrote:

Well, if iTunes is already running, why don't you just do it via Scripting Bridge?

Because it would be orders of magnitude slower. Even the property list parser can read the iTunes library in a few seconds. Extracting all that information via AppleEvents would certainly take minutes.
Taking that amount of time, it would be subject to race conditions, since the library might change while your script is iterating it.
It also requires that iTunes be running, which is a bad assumption if you have an app that wants to grab an MP3 to use on its own (i.e. like a slideshow soundtrack in iPhoto.)


Trust me; I've done this before.

Relying on the XML format of the iTunes library staying the same for all future versions of iTunes is going to be more troublesome than the worries you have of the file being overwritten.

No. That file exists specifically for interoperability. (iTunes itself uses a separate database file in some funky binary format; it only emits the XML file for other apps to read.) If it ever changed incompatibly, any number of 3rd party apps would break, and even Apple apps (like all of iLife) would have to change their code and complain bitterly to the iTunes folks about screwing up their release schedules. In other words, it isn't going to happen. What does happen is that new keys get added to the plist over time.


You also don't need to worry yourself about the location of 'iTunes Music Library.xml' - Mine exists on a volume connected to an Airport Extreme, not in ~/Music/iTunes Music/

Good point that the location is not hardwired! A lot of developers don't know that and their apps end up not working for people who've moved their music folders elsewhere.


The location of the XML file is stored in user defaults. If you use code like the snippet below you'll always be able to find it:

+ (NSURL*) currentITunesLibraryURL
{
    [[NSUserDefaults standardUserDefaults] synchronize];
    NSArray *dbs = [[[NSUserDefaults standardUserDefaults]
                        persistentDomainForName: @"com.apple.iApps"]
                            objectForKey: @"iTunesRecentDatabases"];
    if( [dbs count] > 0 ) {
        NSURL *url = [NSURL URLWithString: [dbs objectAtIndex: 0]];
        if( [url isFileURL] )
            return url;
    }
    return nil;
}


—Jens

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________

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: Efficient XML loading [continuation of NSString from mapped NSData thread]
      • From: Matt Gough <email@hidden>
References: 
 >Efficient XML loading [continuation of NSString from mapped NSData thread] (From: Keith Duncan <email@hidden>)
 >Re: Efficient XML loading [continuation of NSString from mapped NSData thread] (From: Matt Gough <email@hidden>)

  • Prev by Date: Re: Can I use NSString classes SYNCHRONOUSLY?
  • Next by Date: Re: Can I use NSString classes SYNCHRONOUSLY?
  • Previous by thread: Re: Efficient XML loading [continuation of NSString from mapped NSData thread]
  • Next by thread: Re: Efficient XML loading [continuation of NSString from mapped NSData thread]
  • Index(es):
    • Date
    • Thread