如何在iOS中动态解析JSON

Question

We used a third party service and it provides a JS file. The js file launches an http request and get a json.We parsed the json and got the content we wanted but the json format always changes.

Is there a way to parse the json but do not update our app?

Answer 1

It sounds awful stupid to constantly change schemas, but anyway, maybe you could try having a manifest somewhere in the cloud that translates the latest schema keywords into one your app understands?

Basically, I presume that the info in the JSON is similar (otherwise it wouldn't make sense at all) and only the keywords change. You could have a JSON you constantly update that translates the keywords used in the app into the newest one used by the webservice.

So an example would look like this. Imagine this is the format you are used to when developing the app (this is the one app expects).

{
    "name" : "Henri",
    "title" : "iOS Developer"
}

Now if the webservice changes it's schema and returns something like this

{
    "key1" : "Henri",
    "key2" : "iOS Developer"
}

You should have a manifest.json which translates it like this

{
    "name" : "key1",
    "title" : "key2"
}

I hope you get where I'm going with this, basically you can shift the translation to the cloud, giving you the chance to keep it up to date while app remains the same. So after loading in the translation you can access the data like this

NSString *name = [actualJSON objectForKey: [manifestJSON objectForKey: @"name"]];

Answer 2

The JSON home page has quite a bit of materials on the subject which should allow you to develop your own parser if you wish. There are also some ObjectiveC parsers available down at the bottom of the page.

http://www.json.org/

Answer 3

For this purpose we looked at Cocoa's standard key path infrastructure but weren't particularly happy with how it combines with arrays and dictionaries. In the end I ended up writing my own little key-path lookup thing, essentially like:

- (id)objectAtPath:(NSString *)path inObject:(id)object
{
    // accept an input string like key1.key2.key3.index.key4.etc;
    // so we'll split on the dots and use each separate component
    // to navigate the object graph
    NSString *components = [path componentsSeparatedByString:@"."];
    for(NSString *component in components)
    {
         if([object isKindOfClass:[NSDictionary class]])
         {
             // if this is a dictionary, use this component as
             // a key into the dictionary
             object = [object objectForKey:component];
         }
         else
             if([object isKindOfClass:[NSArray class]])
             {
                 // if this is an array, use this component
                 // as an index into the array
                 NSInteger index = [component integerValue];

                 // treat out of bounds indices as finding nil
                 // rather than raising an exception
                 if(index < 0 || index >= [object count]) object = nil;
                 else object = [object objectAtIndex:index];
             }
    }
}

So you might call objectAtPath:@"shoes.4.typeOfLaces" inObject:jsonResult if 'jsonResult' is a dictionary to get the array 'shoes', the dictionary at index 4 in the array and then whatever value that dictionary has for the key 'typeOfLaces'.

The production code actually has some smarter navigation aids, allowing you to say things like "take whichever object in this array of dictionaries has the largest value for the key 'size'" or "take the object with type=large if it exists, otherwise take any object", but exactly what you want to do there will depend on your app and the variability of the schema.

Once you're navigating object graphs by key path, you can just grab the current key paths from a server somewhere, allowing you to change how JSON is navigated on device without submitting a new binary.

The only warning I'd add is to be careful how much functionality you put into your key paths. Apple don't allow fresh code to be downloaded so whatever you do you don't want to end up at anything that Apple could construe as a scripting language, no matter how restricted.