I've got a quandary on how to proceed logically more than how to actually code a feature.
The app is an aid to raising tilapia in floating cages. The screen in question is for estimating number of fish by weight. You average 3 buckets (weigh and count). Then enter the weight of each bucket while the app sums weights and estimates how many fish you've transferred.
I used it in the wild and it works fine, but I quickly realized a problem. If it crashes or battery dies or I turn if off or leave the page accidentally all data is lost. Because I was testing I had written the weights on a pad, but it was a scare. I can put a safety on exit, but I'd like to backup data as I go. I've got it to save and re-load on opening, but I'm stuck in a loop (me, not the app) as to the best strategy. NOTE: Textboxes are added dynamically as needed and the number of entries can reach a hundred or more. This also means the name of the textbox will be different from save to restore.
I could save all data on the page every time any textbox is changed. My fear is it's going slow down the system. It also seems redundant to re-save the same info 100 times.
I could save only the last one with append. But what if user sees an error and changes previous box.
I could save only changed boxes, but how do I maintain the order so I save it into the right spot?
I could save sequentially as if recording and then restore would be playback. A changed box would first have the wrong value and then the corrected just as in the original. I'm not sure I know how to implement that. Maybe a list of pairs: boxID,value. The dynamic boxes would be complicated.
some combination of above
But what I'm really hoping for is a solution so simple I'll smack my forehead and say "Duh, I should have thought of that!"
I didn't explain it well. Since I can't know how many readings there will be, I can't create the entry boxes in advance. They are created (in groups of 3) as needed. It didn't seem to make sense to put 10 if the user will need 100, or 100 if they will only need 10.
I did use a TinyDB in preliminary experiments, but after each entry I created a list and saved it as csv. If I just add to the end after each entry, how do I change the middle if the user goes back and modifies an earlier entry? Should I make a DB entry for each textbox rather than a list?
From what you say one reading/record is three buckets then weight of all three buckets divided by 3?
Then save this.
Then make another reading ?
If so you only need three textboxes for the weight of each bucket, and a button to save the calculation and the weights (along with any other data you need to collect for that reading). You can save this to a list, then save the list to a tinydb. After a reading the textboxes reset for the next reading. Or am i missing something ?
Here's a real life scenario. On Jul 30 I bought 3500 fingerlings (young fish). We went to the cage and dipped out 3 buckets that totaled about 6.5kg. The count was 92 fish for an avg of 56g. At 56g I'd need 83.5kg for 1500 fish. From that point on, we scooped up a bucket full, weighed it and dumped it into the transport uncounted. The app summed up the buckets full (or bucket fulls) and kept a running total of weight and est count. We had to divide it into 2 batches so there were 20 and 21 buckets weighing from 3 to 6.5 kg. Last week I sold about 1700 fish from .900 to 1 kg. Here's a picture of the list. (The app wasn't used). I haven't got the final report, but you can see it was a lot of entries. And here's a screen shot of this part of the app.
It's in Portuguese but the important parts you should be able to guess at. At the bottom of the screen shot I re-created the first entries. The second button at the bottom adds another row of boxes.
The app uses both of those for data display and to select from data. I don't think I know how to use them for data entry. The Score app is interesting and storage situation is similar. The pre- and suf- fixes is an interesting idea, too.
I imagine the first 3 buckets of a batch are for statistical accuracy in determining the ratio of weight per bucket, fish count per bucket, and consequently weight per fish.
But it looks like you are counting out the remainder of a batch in units of 3 buckets?
Because you have 3 workers, each with his own bucket?
The List Picker is rigged to show all its entries in its .Text for visual confirmation of recent entries, and its selection event is rigged to immediately delete whatever is selected. (In the example I deleted item 2, the value 55.)
I neglected to add a Clear button to reset global list weights to empty list and to call recalculate.
I neglected to address your TinyDB usage scenario.
Instead of storing the current batch's list of weights in global variable weights, you could read and write from TinyDB tag CURRENT_BATCH_WEIGHTS, and keep your current batch fish per kg ratio in tag CURRENT_BATCH_FISH_PER_KG.
Will this get awkward with 100+ entries? One of my dislikes about the list view is it takes up so much space. I haven't found a way to shorten the height. Maybe its an Android thing.
But this s great. It'll take me a bit of chewing to dumb it down to my level and fully understand the details but I understand the basic intent.
This can be easily amended to show only the first 4 (numerically by index) (last by time) entries in the List Picker.Text for feedback, so it does not overwhelm the display. The whole list would still be in the Elements list and in the TinyDB entry.
Yeah, I think this is better. And one input location definitely is better. Even if I use multiple lists. I think it'll take fewer blocks. I just have to get up the nerve to throw out a couple of weeks my work and sub it for a couple of minutes of yours . It's not so bad when I'm half way, but I'd already worked out the kinks. Oh well, better is better. Oh the curse of living in the shadow of others' genius.
. It's not so bad when I'm half way, but I'd already worked out the kinks. Oh well, better is better. Oh the curse of living in the shadow of others' genius.