The getStatistics() method is buggy. We sometimes need a way to auto-scale plots upon load. Scaling is easy if it's user-driven, as in Fluxtream when you click on the double-headed arrow to maximize the plot height. But it appears to be much harder to do well upon loading a channel. The getStatistics() method has an optional callback argument, but the callback usually gets called too soon, before all the tiles have actually loaded, so the stats are useless. And we don't want to just use the min and max values in the channel spec (e.g. as returned by https://fluxtream.org/api/bodytrack/users/USER_ID/sources/list) because those min/max are for the entire time range of the channel's data, and not just for the small window of time Paul's loading up. Same is true for the "default_graph_specs" API method (e.g. https://fluxtream.org/api/bodytrack/users/USER_ID/sources/DEVICE_NAME/default_graph_specs).
The getStatistics() method is buggy. We sometimes need a way to auto-scale plots upon load. Scaling is easy if it's user-driven, as in Fluxtream when you click on the double-headed arrow to maximize the plot height. But it appears to be much harder to do well upon loading a channel. The getStatistics() method has an optional callback argument, but the callback usually gets called too soon, before all the tiles have actually loaded, so the stats are useless. And we don't want to just use the min and max values in the channel spec (e.g. as returned by https://fluxtream.org/api/bodytrack/users/USER_ID/sources/list) because those min/max are for the entire time range of the channel's data, and not just for the small window of time Paul's loading up. Same is true for the "default_graph_specs" API method (e.g. https://fluxtream.org/api/bodytrack/users/USER_ID/sources/DEVICE_NAME/default_graph_specs).