Make level2.json parsing robust for syntax errors

[vdhamer]

Problem

If a JSON file is syntactically or semantically incorrect, the parsing library SwiftyJSON robustly returns nil or default values like “”. This is as if the data that you requested was not in the file. It only takes a missing or extra comma to trigger this.

The user of the app then doesn't get their data updated, but usually will be seeing the older content in their CoreData database instead. So "how are they going to know?". Or more to the point, "how is the person who made the error going to know?" - because this is typically the person who can needs to fix the error?

Options below don’t distinguish clearly between errors at JSON level versus errors at JSON schema level.

Alternative solutions

1. Dedicated editor
   Don't edit the JSON files at the ascii level, but provide a dedicated tool that checks syntax and schema (e.g. OpenAPI). Probably this should be done in the long run. Help wanted. A form-based editor reduces the chance of errors, but will never guarantee that the file didn't reach the server via some other route ("it was only a small change"). Fortunately the people who would cut corners typically can handle the consequences.
2. Server stands guard
   Check the JSON files regularly using a watchdog job running on some server. Would need to notify admin type users via e-mail. Maybe the Level 2 files should then contain an e-mail address of the maintainer who should be contacted.
3. App does the checking
   Check the JSON files regularly using the app. This could be done using schema validation code that checks both syntax and schema. Regardless whether it runs on request or on program launch, it can present a modal dialog alarming all (?) users that something is wrong, and that they have missing or outdated data. The checking can be enabled/disabled via an extra toggle in Settings.
4. App checks as file is loaded
   Variant of preceding option, but combine the JSON parsing (SwiftyJSON) with a syntax check. Example: a json file containing photo clubs should contain at least one photo club. It will currently return zero if there is an error in the json, and zero is technically ok, but probably not intended. Missing (readable) data can trigger say a red warning triangle, and clicking on the triangle can provide more information like "The app cannot refresh the list of clubs and museums. Cause: file Foobar.level2.json is damaged."
5. Checking using extended SwiftyJSON
   There is a pull request for SwiftyJSON to distinguish no data from syntactically corrupt data. The pull request hasn't been merged for a long time, so we would need to switch to the forked version. This is a variant of the preceding option.

[vdhamer]

• ik zou kunnen melden als een club tijdelijk niet werkt (niet gewenst: bij 100 clubs zit er straks altijd wel een verkeerde data tussen)
• ik zou in een soort stats lijst per club kunnen aangeven met een datum wat de laatste geslaagde leespoging is (“last successful read was 12-may-25”). Danwel een icoon die aangeeft per club dat het niet ok is.