Re: isKindofClass with NSData and NSKeyUnarchiver
Re: isKindofClass with NSData and NSKeyUnarchiver
- Subject: Re: isKindofClass with NSData and NSKeyUnarchiver
- From: Philip Vallone <email@hidden>
- Date: Thu, 27 May 2010 20:25:26 -0400
Hi Graham,
I think Ken's response was exactly what I was looking for. The code snippet I posted was just a small example to illustrate my question and ken's was as well.
> Perhaps you just need to archive a data structure at a higher level so that what pops out when you dearchive is fully formed and ready to go, instead of needing to be sorted by type and handled accordingly
This is a relative question, which depends on how the data is coming and going. My question comes from the following situation. Suppose I have a GKSession that is passing information via Bluetooth. The sender can send any type of information (NSString, UIImage etc...). The receiver needs to know how to handle this data. If there is a better way... Then how?
I appreciate the feed back and help,
Phil
Regards,
Philip Vallone
On May 27, 2010, at 8:12 PM, Graham Cox <email@hidden> wrote:
>
> On 27/05/2010, at 8:36 PM, Ken Thomases wrote:
>
>> if ([obj isKindOfClass:[NSString class]])
>> // ... use 'obj' as a string
>> else if ([obj isKindOfClass:[NSArray class]])
>> // ... use 'obj' as an array
>> // ... etc. ...
>
>
> It might also be worth pointing out that writing code structured in this way is highly indicative of a failure of design (and I say that obviously realising that Ken was only trying to illustrate how to discover an object's type in the context of the example, not how best to handle the situation as a whole).
>
> You need to design your code so that if its type is important you can easily encode and decode a type indicator along with the data itself, but even then it's a bit of a code smell. Perhaps you just need to archive a data structure at a higher level so that what pops out when you dearchive is fully formed and ready to go, instead of needing to be sorted by type and handled accordingly?
>
>
> --Graham
>
>
>
_______________________________________________
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