marcoscaceres
commented
10 years ago This is looking good. I would drop type tho. We don't want to have to document every platform, and then it would be sad if we had to document platform versions if any of these API properties change name in future versions (or even at a language level: e.g., Objective-c and Swift).
I'm ok for us to keep latencyRange in there for now.
Also, JSON doesn't support comments :) Maybe just add the ref as a property.
First run at the (cellular) connection info JSON struct based on data from: https://docs.google.com/spreadsheets/d/16csKPy0dC2Hs6OHbLdWf0qlDiiRreqPtsMEE8vebRYo/edit
ceilingvalue is in kbps (kilobits per second). I initially used MiB/s, but there is some precision loss when I do that, and I wanted to keep it faithful to the numbers that are usually used in the standard specs. That said, when we report them in the UA, I think we should still convert these to MBps or MiB/s.typecould arguably live in a comment, but I'm erring on the side of too much information, and it might as well be structured data? It's a non-trivial exercise to map some of the different connection types across different platforms to a consistent name.latencyRangeis in ms. Once again, erring on the side of too much info.The reason I'm erring on the side of "too much" is because finding a good source of structured data on this stuff is really darn hard, and perhaps this could be it -- pull in this JSON and you have all you need. On that note, I'm also entertaining making ceiling an object with two values: uplink, downlink.
Am I crazy? Feel free to tell me that I am. :)