CODEWITHSUNDEEP
objective-cjsoncocoamappingnsdictionary
Dimillian
Dimillian

Reputation: 3646

Objective-C, JSON and object mapping

I'm doing some homemade parsing and "object mapping", you'll see, not really object mapping at the moment but that my goal, I need to find the best approach first.

Current simplified code example

Parser

Today I have some parser specially made for my app, here is the key method, you'll get it.

-(void)jsonParserDidFinishParsing:(NSDictionary *)dic fromFile:(BOOL)file
{
    if ([dic objectForKey:@"timeline"]) {
        NSArray *items = [dic objectForKey:@"timeline"]; 
            for (NSDictionary *item in items) {
                MSTimelineItem *aItem = [[MSTimelineItem alloc]initWithDic:item]; 
                [delegate timelineParserDidParseAnItem:aItem];
            }
            [delegate timelineParserDidFinishParsing]; 
     }
}

Models

I have models with some standard constructor like this (sure, in my real app keys are constants).

-(id)initWithDic:(NSDictionary *)dic
{
    self = [super init]; 
    if (self) {
        _udid = [dic objectForKey:@"udid"]; 
        _picUrl = [dic objectForKey:@"profile"]; 
        _name = [dic objectForKey:@"name"]; 
        _job = [dic objectForKey:@"job"]; 
    }
    return self; 
}

Goal

Make it more dynamic, avoiding changing local key when a server change is made. Make something beautiful...

Approach

Avoid all that constructor code, my approach is to use KVC, name properties the same name JSON keys are named and only keep my @dymanic properties for calculated things. So I can literally loop in the JSON dic properties and use setObject:ForKey from the parser.

With this approach I only need to keep the properties, still some code, but I can deal with it. Change a server key, refactor the properties, done !

problems

I have some object with relation, like a model can contain an array another models. Still need some logic to deal with that. Also keeping all the properties can be still a lot of code.

Also accessing or setting a properties which do not exist will crash the application. What can I do against that ?

Conclusion

In all cases I still need to know the keys/properties at some point. Accessing objects properties is better than object:forKey as I'll get instant warning and errors.

I don't want to use framework like RESTKit, I have made my own framework for Rest things, I only need this dynamic approach to have a fully standard set of classes.

I also know that I don't have the knowledge to think of a more elaborated solution, your turn :)

Question

Am I right ? What is the best approach as per your experiences, I'm really interested to hear what you've done before, why it worked, why it is good or not.

Hope you liked the presentation ;)

Upvotes: 2

Views: 1447

Answers (1)

kevboh
kevboh

Reputation: 5245

As you've suggested, your choice boils down to having hardcoded property names so you can get synthesized methods and dot-accessors or using some sort of dynamic storage and only being able to access properties by explicitly naming them via KVC.

If you're working with an API that you're also building yourself, I'd suggest standardizing and documenting the JSON structure returned by your API such that you don't have to deal with shifting property names. In this way you can back the API locally with well-named and -formed objects that have matching declared properties. Sure, by the standard you've outlined this isn't as fluid, but you gain all of the compiler and syntax benefits of having regular typed properties. I'd bet this results in far easier development.

If your API returns a changing JSON structure (again, not recommended) then I'd suggest eschewing a model-mapping architecture altogether and just using NSDictionary to store the response.

I guess the sticking point here is that if you want an object model to map to your API then you're implying that there are set models to pass around, and if that's the case then just make properties that match the JSON and don't worry about beauty/technicality. Keep it simple.

Upvotes: 2

Related Questions