|
I've been literally 'hacking around' with JSON and collecting data from external URL's, currently my code isn't failsafe as i'm stepping through to see if everyone who has published the JSON file is conforming to the same specification. What I've found is some oddities which I'm able to catch and code for. but there is one that I don't know how to handle. Where the publisher of the JSON file has included a key name with a space ; example : instead of something like {"some_id":"123456"} instead they have published as {"some id":"123456"} So the key is neither camelCase nor snake_case. Ideally the publisher of the JSON should change their file so that it conforms, but is there a slick way that I could change how the Codable decode works to cater for this rogue space. I am wondering if the best approach would be to 'collect' the JSON from external source, run it through some sort of validation function where I check purely for rogue string values in the keys and correct them, then safe the file locally and then use that file. to extract the JSON data from using codable structure in swift. But so far I've only found once instance of this rogue space within one key and thus wondered if there is a simpler way to catch and correct it so the JSON file decodes without issue. |
|
This is a good example of when you would use a Since you didn't supply a sample of your JSON, I had to just make something up, but this simple example should suffice to illustrate the point:
The tricky bit is that if you specify one key in a |
|
Great reply @roosterboy, it's the tricky bit that i'm struggling with. a. the structure is a nested structure - eg. in your example say Person has sub-structures for fullName containing firstName, middleName and lastName and that maybe age would also have date of birth and place of birth ; for scenario a. I'm struggling to see how the enum should be declared to cater for the substructures too - I figured that they all need to be enumerated so that they are valid but I keep getting compile error saying that the structure isn't codable. for scenario b. my line of thinking is that I could declar the Key as optional with ? and then also define it in the enum, something like, using your example firstName : String? first_name : String? then when reading the different JSON files if it's got "first name" that can be defined in the enum but if it's got "first_name" that would decode fine and I can test firstName and first_name for nil to ensure I capture the populated one from the JSON. |
|
Please show an example of what you are talking about. It's too difficult to provide a good answer without seeing some code. |
|
I used your code example, modified it for the nested structure(s) that I'm having to work with and I think i've cracked it...it needs mulitple private enum's one for each region of the hierarchy.... as you said you need to enum them all, but when nested the enums are nested within the relevant section and can't be done in a single block.
Note : the JSON file here is single element, but in reality it would have [] within it for multiple array entries. |
|
Yep, I think you got the hang of it. A few comments...
The convention in Swift is for type names to start with a capital letter and variables to start with a lowercase. It aids readability and helps others (including Future!You) understand your code better. So these should be:
With When I said "The tricky bit is that if you specify one key in a |
|
SPONSORED Ready to dive into the world of Swift? try! Swift Tokyo is the premier iOS developer conference will be happened in April 9th-11th, where you can learn from industry experts, connect with fellow developers, and explore the latest in Swift and iOS development. Don’t miss out on this opportunity to level up your skills and be part of the Swift community!
Sponsor Hacking with Swift and reach the world's largest Swift community!
This topic has been closed due to inactivity, so you can't reply. Please create a new topic if you need to.
All interactions here are governed by our code of conduct.
Link copied to your pasteboard.