3,543
edits
Line 26: | Line 26: | ||
=== result json === | === result json === | ||
==== field names ==== | |||
For the naming of the fields of the results json the following principles are used: | |||
* Typing - the to expected type of the values is encoded in the field names, by a string at the end: | |||
** _tags - expect a String array; | |||
** _n - expect an Integer; | |||
** _t - expect a time in seconds since ?, encoded as Integer; | |||
** _f - expect a float; | |||
** none - the default will b a String | |||
==== platform specific naming issues ==== | |||
* Swift: it should be as easy as possible to decode a json with the standard Swift-libraries. | |||
** no "-", which are not allowed in Swift variable names; | |||
==== comments ==== | |||
* The json seems to have two user groups: OFF itself and end users (apps). Can the json be split in two section that correspond to these groups as well? Not sure whether this is a good approach. | * The json seems to have two user groups: OFF itself and end users (apps). Can the json be split in two section that correspond to these groups as well? Not sure whether this is a good approach. | ||
* The json can be more structured, so that it is more readible for a viewer, but also from an parsing interpreting point of view. I.e. everything that corresponds to packaging goes together. | * The json can be more structured, so that it is more readible for a viewer, but also from an parsing interpreting point of view. I.e. everything that corresponds to packaging goes together. |
edits