1

How would I go about using bluetooth to transfer a core data entity with it's corresponding relationships? I have three core data entities with inverse relationships set up and it all works fine, but I need to transfer these to another iPhone based on the context that it is not in the corresponding table in the core data entity set on the other iPhone. I know how to transfer simple things such as strings and integers over bluetooth, but this is on a whole new level, and I only started programming for iPhone around 4 month ago. Thanks for all your help you experts!

EDIT:

Thanks, but for some reason I keep getting this error! What should I do?

2010-02-12 21:24:14.907 PitScout[92918:207] Failed to call designated initializer on NSManagedObject class 'Team' 
2010-02-12 21:24:14.907 PitScout[92918:207] *** -[Team setTeamNumber:]: unrecognized selector sent to instance 0x112b630
2010-02-12 21:24:14.908 PitScout[92918:207] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[Team setTeamNumber:]: unrecognized selector sent to instance 0x112b630'

Thanks.

thkala
  • 84,049
  • 23
  • 157
  • 201
Aditya Vaidyam
  • 6,259
  • 3
  • 24
  • 26

3 Answers3

2

You will need to serialize your objects in some way to transfer and then re-insert into a context on the other side. I suggest looking into the NSCoding protocol and examples which will allow you to use NSKeyedArchiver and NSKeyedUnarchiver to serialize your objects to NSData for transfer (or base64 encoded to an NSString if necessary).

First make sure your model object implements NSCoding:

@interface MyObject :  NSManagedObject <NSCoding>

And then implement the following methods in your model object to handle the encoding and decoding of the objects:

-(id)initWithCoder:(NSCoder*)coder
{
    if (self = [self init])
    {
        self.myProperty = [coder decodeObjectForKey:@"myProperty"];
    }

    return self;
}

-(void)encodeWithCoder:(NSCoder*)coder
{
    [coder encodeObject:self.message forKey:@"myProperty"];
}

Use NSKeyedArchiver to serialize your object to NSData:

NSData *data = [NSKeyedArchiver archivedDataWithRootObject:myObject];

Use NSKeyedUnarchiver to deserialize:

MyObject *myObject = (MyObject *)[NSKeyedUnarchiver unarchiveObjectWithData:myData];

If a string is required then you'll have to base64 encode and decode the NSData, see this post for details on that: How do I do base64 encoding on iphone-sdk?

Community
  • 1
  • 1
Greg Martin
  • 5,074
  • 3
  • 34
  • 35
  • 1
    They serialize to data, not strings. Treating strings as plain binary data is a very common mistake that causes *a lot* of confusion. – Peter Hosey Jan 21 '10 at 03:00
  • Ah yes, my mistake, the resulting data could then be base64 encoded if a string is a requirement. I've corrected my answer. – Greg Martin Jan 21 '10 at 04:17
  • And exactly how would I do this? – Aditya Vaidyam Jan 21 '10 at 07:04
  • WOW. THANK YOU SO MUCH! Although I still don't understand the complete usage of the KeyedArchiver, I think I can find out from reading Apple's Dev stuff. Thank You Greg! – Aditya Vaidyam Jan 22 '10 at 02:32
  • You can't serialize NSManagedObject instances because they are tied directly to the NSManagedObjectContext that created them. They will not deserialize properly. – Marcus S. Zarra Feb 13 '10 at 16:12
2

Trying to serialize NSManagedObject instances is going to fail because they are tied directly to the NSManagedObjectContext that they come from.

You will need to translate them into another data structure and then transmit them. Both JSON and XML work very well for this and since you can use KVC to get the data out of an NSManagedObject and into a NSDictionary which can then easily be translated into the intermediate format.

Once you have them in the intermediate format and sent over the wire then you can easily reconstruct them into the destination NSManagedObjectContext without issue.

Marcus S. Zarra
  • 46,571
  • 9
  • 101
  • 182
1

It may be over kill for this but a method that has yet to fail me is SLIP, RFC 1055 the 1988 version. For years i have used it to map blocks of data into a 7 or 8 bit ASCII stream for transmission over every media I have encountered. Then used the inverse or some modification of it to convert the stream back to their needed configuration on the other end. Examples of the code in C are in the RFC. I always used Phil Karn's suggestion to use the same character for both the start and end of packet. 

That way only one routine is needed to deal with the stream. It gobble up characters until the SOP/EOP is encountered. This was chosen to deal with noise that can accumulate on the input of radio links as they sit idle awaiting data. Phil address that in other writings.

I usually use \x0D or \x0A which ever the system the debugging tools run on uses for as a carriage return and use the ever popular back slash '\' as the escape character. Now and then it is handy to use another control code or use differ values for the control characters to reduce the packet size. Use of the system as allows a terminal program with the code for SLIP added and a few modifications  to function as a monitor and as tool to enter packets into the stream by hand.

I have always found I had enough options if the first character in the packet indicated the options on the other end. Of course some form of error checking and either/or error recovery and ability to re-transmit a MUNGED packet must be provided. For small packets of data sent over highly reliable links a simple checksum might do or in the case transmissions using three mineralized volcanos as antenna sites that a bit farther apart than one would like a highly redubpndantr Fowarad Error Correction algorithim is right at home.  

SLIP is versatile enough to take data from a 16 bit Motorola 68HC11 and reconstruct it on a 32 bit Intel system if the programmer reverses the endedness and takes care of the offset between 16 & 32 bit data.

Gordon 

Gordon Couger Stillwater, OK

Gordon Couger
  • 9
  • 2