Open Chris-Petty opened 3 years ago
I just made this zip today actually! This is creating records on desktop (made for the cold chain integration).
I haven't got the setup completely right on ColdChain
but I am using flags in the start scripts to set environment variables which then trigger different deps:
I think it would be a great way to move toward but for mobile at this point I think it's a pretty massive shift.
Personally I think the most time-efficient implementation would be to have some buttons (Hidden behind __DEV__
) on the SettingsPage
or a button to navigate to some other DevPage
which just had buttons which were like "Create Sensor"
, "Generate 1000 temperature logs"
, "Create Basic Data Setup" (Creates a sensor, some breach configs/locations and some logs).
The methods themselves, if abstracted, could be utilized later for doing a more complete solution where we could generate data for any type of setup?
I just made this zip today actually! This is creating records on desktop (made for the cold chain integration).
That'd be the other other alternative, have some scripts to generate the data on mSupply and sync it to the mobile device. There is a method there to parseUnix
... is the mobile log table storing epoch integer time? Maybe mobile could/should save as JS dates?
I haven't got the setup completely right on
ColdChain
but I am using flags in the start scripts to set environment variables which then trigger different deps:I think it would be a great way to move toward but for mobile at this point I think it's a pretty massive shift.
Yea those links don't quite unpack it all. Digging to where they reach out to you've put in a bunch more.
Personally I think the most time-efficient implementation would be to have some buttons (Hidden behind
__DEV__
) on theSettingsPage
or a button to navigate to some otherDevPage
which just had buttons which were like"Create Sensor"
,"Generate 1000 temperature logs"
, "Create Basic Data Setup" (Creates a sensor, some breach configs/locations and some logs).The methods themselves, if abstracted, could be utilized later for doing a more complete solution where we could generate data for any type of setup?
Sounds good lets go with this? A bit more palatable as well as it's definitely after initial sync, so doesn't make a mess of testing sync down the line. Though I'll chat to you about how to abstract it effectively in mobile codebase.
That'd be the other other alternative, have some scripts to generate the data on mSupply and sync it to the mobile device.
This kind of solves multiple problems. Except for the fact you have to still sync - just makes that development feedback loop longer. Although it's certainly a good idea.
There is a method there to parseUnix... is the mobile log table storing epoch integer time? Maybe mobile could/should save as JS dates?
That method was just in there because adding minutes is easier to do with unix epochs - 1324234+300 to add 5 minutes then Date(123432234234)
/Time(234234234234)
etc in 4D. (But ColdChain
uses unix epochs because SQLite and easy..)
Sounds good lets go with this? A bit more palatable as well as it's definitely after initial sync, so doesn't make a mess of testing sync down the line. Though I'll chat to you about how to abstract it effectively in mobile codebase.
Cool!
Is your feature request related to a problem? Please describe.
It's quite difficult to develop/test/demo multiple features due to difficulty of getting useful data:
Describe the solution you'd like
Be able to set an environment variable that makes mobile either generate data based on scripts, or import data defined in a file (JSON would be good as easy to work with, human readable and can be updated in a PR. Could be used for repeatable testing)
Implementation
Put a button in the admin page for generating sensor data. Let it only be visible on development builds. Put the code somewhere tidy rather than directly in component (probably
/utilities/
folder).Logic should be loosely:
Describe alternatives you've considered