We'll need to think about a way to fill in some information more quickly; seeing delays of several minutes and sometimes crashes so far on develop branch; most likely related to time to read informations and/or missing information needed for the plot from health kit
Adding on that the shorter so far for a screen presentation on the daily progress screen is three minutes, the norm is closer to five, with the slowest being six. The bug where if you get impatient and move to another screen it prevents the user from returning to the third screen is still present.
Adding on that this is in the HKStore queue thread, so clearly something with the dispatch entries. It also seems to be tied into something with what it expects to find and not handling an error coming off from that gracefully. Today w/out a sleep entry from overnight, it crashed with this thread indicated as the main cause. (and continuing: still crashes -- grows to more than 1 GB of memory on the third screen and then crashes; even w/sleep entry and other metrics similar to yesterday)
another direction is to try and speed up the queries by making sure that they hit the main queue:
https://www.natashatherobot.com/healthkit-getting-fitness-data/
-------- from the discussion at the end ------------
(Hey, i had the same problem & thought health kit is just slow, but its not!
The problem is that the queries are performed asynchronously in the background so if you want to do something in the completion block of the query, like saving data or updating the UI make sure to dispatch back to the main thread (or queue)!
In swift this is really simple, just add:
dispatch_async(dispatch_get_main_queue(), { () -> Void in
//do something like saving data or updating the UI here
})
We'll need to think about a way to fill in some information more quickly; seeing delays of several minutes and sometimes crashes so far on develop branch; most likely related to time to read informations and/or missing information needed for the plot from health kit
Adding on that the shorter so far for a screen presentation on the daily progress screen is three minutes, the norm is closer to five, with the slowest being six. The bug where if you get impatient and move to another screen it prevents the user from returning to the third screen is still present.
Adding on that this is in the HKStore queue thread, so clearly something with the dispatch entries. It also seems to be tied into something with what it expects to find and not handling an error coming off from that gracefully. Today w/out a sleep entry from overnight, it crashed with this thread indicated as the main cause. (and continuing: still crashes -- grows to more than 1 GB of memory on the third screen and then crashes; even w/sleep entry and other metrics similar to yesterday)
working on this problem with help from two stack overflow comments: (1) http://stackoverflow.com/questions/30466273/data-is-loading-very-slow-using-gcd and (2) http://stackoverflow.com/questions/30473158/dispatch-group-leave-crash-in-swift
another direction is to try and speed up the queries by making sure that they hit the main queue: https://www.natashatherobot.com/healthkit-getting-fitness-data/ -------- from the discussion at the end ------------ (Hey, i had the same problem & thought health kit is just slow, but its not!
The problem is that the queries are performed asynchronously in the background so if you want to do something in the completion block of the query, like saving data or updating the UI make sure to dispatch back to the main thread (or queue)!
In swift this is really simple, just add: dispatch_async(dispatch_get_main_queue(), { () -> Void in //do something like saving data or updating the UI here })
This should speed up your queries dramatically )