Have distributed objects been deprecated?

Discussion in 'Mac Programming' started by jiminaus, Apr 6, 2011.

  1. macrumors 65816

    jiminaus

    Joined:
    Dec 16, 2010
    Location:
    Sydney
    #1
    The Remote Messaging part of the Apple's Objective C Programming Language guide has gone. Has Apple (perhaps by stealth) deprecated Objective-C distributed objects? It doesn't look like it's been implemented in iOS, which is a shame. I thought it would be a great communication system between Mac and iOS. Does anyone know of or have any experience with using distribute objects in classic RPC-style client/server projects? I'm just wondering if I should ignore it even for architectural prototypes and just use a "standard" communication system.
     
  2. macrumors 68000

    Sydde

    Joined:
    Aug 17, 2009
    #2
    The main class for distributed objects is NSProxy and its concrete subclass NSDistantObject. These are in the Foundation framework. Mac OS X and iOS use the same Foundation framework. There does not appear to be any deprecation note on either of these classes.
     
  3. thread starter macrumors 65816

    jiminaus

    Joined:
    Dec 16, 2010
    Location:
    Sydney
    #3
    I don't think iOS does share the same Foundation framework as Mac OS X. iOS seems to lack NSConnection and NSDistantObject. It does have NSPort, but only NSMachPort, not NSSocketPort.
     
  4. macrumors 68000

    Sydde

    Joined:
    Aug 17, 2009
    #4
    Given that multi-tasking is relatively new and that iOS is still primarily focused on a single active application, it would make sense that NSProxy has not been implemented. My guess would be that this is the opposite of "deprecated": expect at some point down the road that these things will be implemented. In the meantime, you will have to work with what lower-levels are available to suit your needs.
     
  5. macrumors 68030

    Catfish_Man

    Joined:
    Sep 13, 2001
    Location:
    Portland, OR
    #5
    The main issue I've encountered with distributed objects is that they're *too* transparent. The temptation is to treat remote objects as 'just another part of your app', when in fact they really can't be (what happens if the connection is interrupted? or there's suddenly high latency?). The best way to use them is closer to the way you'd use a traditional communication mechanism, with a defined protocol for communicating encapsulated in one remote object representing your communication channel.

    Given that design restriction, they start looking a bit less appealing vs other communication mechanisms, although they're still a pretty neat technology.
     

Share This Page