Function to store usage data to local JSON file on a timer or app background call

[burrage]

User Story As a developer, I want to be able to automatically store the usage data to a local JSON file on a timer (every 30 seconds) OR if the app is backgrounded, So that usage data is stored safely in the local JSON file at a fixed interval and we are not constantly writing data to a file every time an event happens.

Acceptance Criteria Given that I have written and integrated all the functions to collect data, When either 30 seconds have elapsed between a write to the local JSON file OR the app is backgrounded, Then the collected usage data collected should be written to the local JSON file.

[srishti-learner]

@burrage I think this one needs a bit of discussion because, 1) 5 minutes is a hell lot of time. What if child plays for 3-4 minutes and closes the application? or plays for some time which isn't multiple of 5(say,19) and then closes the application? Data loss. 2) How will we know app is backgrounded and otherwise if we figured this out, it surely can happen that the app is killed/closed from the background( as we swipe the app out in android phones?).

My suggestion on this would be to do it on a page/scene transition but in that case, we may lose the data of last page (still less than 5 minutes' data), iff we can bear that loss! OR do it on event by event basis (I was thinking of doing this to prevent data loss and run it on a separate thread so that the main flow of execution is not affected by it). I would like to have your thoughts on this.

[burrage]

@srishti-learner Have a quick chat with Ashwanth-- there are a couple of different routes we can go (lower the timer (say 1-2 minutes) or on page turn).

Originally I had envisioned on page turn but some of the reasoning behind going to a timer proposed by Ashwanth was to prevent data loss if the child plays a lot on a single page but then gets distracted and leaves the tablet-- we are still able to capture that last page of data.

I do think that you're correct that a child may potentially finish a book in less than 5 minutes (especially decodable level 1 if they aren't interacting a lot) so the timer value is unrealistic and should be lowered if we go that route.

Again, bigger picture, it is more important for the child to have a better reading experience than to capture ALL the data so the optimal solution would be something that doesn't slow down the reading experience (because of data collection anything taking up too many cycles that can be used toward dealing with interaction, displaying the book, etc. etc.) but still captures enough data to make it worth analyzing.

[srishti-learner]

Yes. Also, doing just the timer based thing, we may have a page data (if child spends a lot of time on that) but also, we can lose a lot of data as you said in level one tinkrbook. It's better losing one page data than a whole book in my opinion.

[burrage]

@srishti-learner Agreed. Let's take this convo to #discussion with Ashwanth and I'll post the outcome here for reference :-)

[ashwanththotta]

1. Timer based, but we need to reduce the time interval from 5minutes (way too long) and make it 20-30 (max) seconds cycle.
2. page wise: (optimal) but dis-advantage when the child keeps the book down halfway, we lose the last page data
3. Event wise (can work) but disadvantage, every event I need to write the data back and with attention deficit of kids these days will be a huge challenge, and if the kid loses patience or gets frantic and keeps queing clicks handling the capture; again need to understand how are we planning to capture data, write to the local file (firebase?) and then write it to server..... with both advantages and disadvantages to each, we can plan maybe a mixture of two things.
4. capture event wise data; locally but then write to the server time based after every 2min interval; again depends on the way we are handling the data locally

[srishti-learner]

@ashwanththotta @burrage Sir, I think there are two ways we can handle this problem(in the same way what you wrote). Just considering the local write now. 1) We can make event wise write work and handle it properly without disrupting the flow of story, if we do it in separate thread rather than the book thread. 2) Otherwise, I support the idea of mixture of both if we are targeting no data loss.

[burrage]

@ashwanththotta @srishti-learner Hmm... Let me have us take a step back for a moment and ask a different set of questions here just so we make sure we can wrap up data collection this sprint and we have something we feel good in putting out for testing in the field before moving on to the decodable books.

What's the smallest set of functions we can write that A.) collects the 3 types of data on the local device, B.) gets that data off the device onto a server, and C.) gives us enough information to figure out what's the best next step to take in fine tuning data collection at a later time?

Srishti has knocked A out of the park already (go Srishti!) so we're just on B and C.

With Firebase, can't we just send the data to Firebase local, know it has 72 hours to send it, and call it a day? We'd be able to log how many devices are hitting the server, the frequency, and also know how many aren't even checking in at all. From that we can assess how many users really are affected by this 72 hour rule (Is it < 5-10%? Is it worth spending the engineering cycles for that fraction when there are bigger fish to catch?)

Let me know your thoughts, please.

[srishti-learner]

@burrage I think it's a great idea(at the start at least) so that we know if this 72 hours rule actually affect. Also as you remarked, we will get the idea if 72 hours is enough for our use case (affects lesser percentage of users) because right now we are just sort of assuming that it may not be. If at all it turns out to be adverse then the code for JSON is all written which we can integrate later if we face any issue.

[burrage]

@srishti-learner @ashwanththotta Great, as long as all feel OK, we can move this and associated non-finished JSON storage cards to the Backlog column of the kanban board and we can revisit once we have surveyed the extent of the users affected by the 72 hour rule.

[burrage]

@srishti-learner And Srishti, yeah just comment out the storage directly to local JSON leaving a comment that we can revisit this once we have surveyed how many users are affected by the 72 hour Firebase rule, and plop in the code to write the event directly to Firebase local instead.

All related functions written can just have a comment at the top that they are related to preserving data for users that would be affected by the 72 hour rule so we remember their purpose if and when we come back around to this.

In all these comments, let's use a phrase like "72 hour rule" so we can easily search the codebase for later?

Sound good? Anything to change?

[srishti-learner]

@burrage Yes Ben. I can do these changes and integrate this with the shelf also but a new task card will be required for the changes. Let us have "72 hour rule" as the phrase.

[burrage]

@srishti-learner You got it! #196 and #197 are ready.

Also we can move this card to the Backlog column when #196 is in place and we can revisit this 72 hour rule if it turns out to affect a greater percentage of users.