1. Welcome to the new MacRumors forums. See our announcement and read our FAQ

NSURL vs NSString: discussion?

Discussion in 'Mac Programming' started by MrFusion, Jan 25, 2009.

  1. macrumors 6502a

    I thought NSURL vs NSString would make a nice discussion for the experts here.

    Cocoa seems, to me at least, undecided between NSURL and NSString. Many filesystem methods require a NSURL path, (e.g. in the NSDocument class). However, if you want to create a NSURL to a locale path, you have to use fileURL... methods, instead of URL... methods. Also, the NSURL class lacks easy ways to change the path. NSString has many methods for appending or deleting path components. NSString paths are also used many times for writing out data directly. When it comes down to use of use, NSString paths are the thing to do.

    My code is littered with going back and forth between NSURL and NSString objects for paths. I don't like it, it is ugly.

    It's probably easy to write a category for NSURL to mimic the NSString methods, but then why is such basic functionality not included in the class from the beginning?
    Why is cocoa so seemingly confused between NSString and NSURL (or am I the one who is confused)?
    And as for the future, will it stay like this or will one win over the other?

    NSURL vs NSString: who is the winner?
  2. Moderator emeritus


    A lot of those methods that work on paths have a corresponding CF function that works on URLs (for example CFURLCreateCopyDeletingPathExtension() and stringByDeletingLastPathComponent), so either NSString internally is converting itself to a URL (which seems wasteful) or it just has its own implementations of these CF functions.

    I'd use NSStrings for local paths as much as possible since an NSURL can also be used to reference an external file. If a class supports loading from an NSURL it's assumed that it handles loading external files (from a server) and if you don't want that then use an NSString.
  3. macrumors 68030


    NSURL is the winner, but I can't explain why yet. Sorry.

    <edit> For those with access to WWDC08 sessions, check out #375 </edit>
  4. macrumors 6502a

    It's august. Can you explain now? Or not until Snowy is out hunting?
  5. macrumors 68030


    Not until SnowLeopard is out.
  6. Moderator emeritus


    I just skimmed through it. Pretty interesting. Guess I was wrong :)
  7. macrumors 6502a

    Ok. Do you promise to tell when Snowy is on the loose?
  8. macrumors 6502


    I'm surprised to find myself so intrigued by a discussion of NSURL.
  9. macrumors 68030


    Yup. Please bump this if I forget.
  10. macrumors 6502


    So, can you talk about it?
  11. macrumors 68030


    NSURL's API and role has been expanded significantly in Snow Leopard. Some key points:

    * File reference URLs and bookmarks: There's a new form of URL called a file reference URL, which is the replacement for the old Carbon alias and FSRef types. It will track files even if they move, and can be serialized to and from "bookmarks", which are the persistent on-disk representation of this.

    * File properties: Replacements for the old FSGetCatalogInfo and similar functions have been added through a unified file property API.

    * Speed: Various caches have been added to NSURL, and more of the other Cocoa APIs have standardized on it. This avoids redundant stat()s and open()s, and the conversion costs to/from paths, FSRefs, etc...
  12. macrumors 6502


    Pretty cool. When I saw that the documentation pages all changed to the (horrible) ones they use for the iPhone reference, I checked out the revisions for NSURL. Saw bookmarks, but didn't bother finding out what it meant :)
  13. Moderator emeritus


    There are still some classes that don't support URLs yet. Tad annoying.

Share This Page