Conversation
|
@MrApplejuice I don't want to conflate multiple issues in this one, but another thing I noticed which would potentially contribute to slowness is rather high LIMIT on SQL query. I think dropping the LIMIT down to 1000 or 100 may be a huge performance gain. Though I would totally understand if that should be done in a separate Issue/PR |
Those particular lines, I hope, are generally irrelevant. I hope that people do not create thousands of timers or children in their babybuddy instance. My entire app is not adequate for those usecases. Generally, you are right, those cases should be handled using the underlying pagination, but in practice, I do not think this is really necessary, because I am working based on the assumption that people do not manage thousands of children and thousands of timers in babybuddy. So I am giving this a "won't fix", but if you really want, you can create a patch... I will retire the entire BabyBuddyClient(V1) though because of the cancelable network monitoring issue, so maybe it is better to wait until that is done :D |
Remaining issues to address
|
Continuation of #106
#106 offers tighter timers, which is a good start, but the slower timeouts cause issues on devices that are not so powerful. The true solution for faster connections seems to be to rely on active network-monitoring provided by Android, allowing detection of network switchovers and then dynamically cancelling networking calls.
Cancelling networking calls is the crux here though, requiring the use of an asynchronous call interface for managing network connections. Right now, I only created a threaded-sychrnous model, so to properly solve this problem I need to start working on a asynchronous network layer, maybe it is already provided by
retrofitalready?In any case, I need cancelable queries for the following data structures to achieve a more snappy interaction: