Hello there, Luis,
After writing all the novel below, I re-read your initial question and realized that there is one simple misunderstanding:
If you choose to go with the āāon-device storageāā You do NOT have to use the flow functions āSet item to storageā and āget item from storageā.
All you need is the regular ācreate recordā, āget recordā etc functions. But of course as the first step you need to set up the data schema and the resource under the āDataā tab in the navigation.
I have just read your other topics as well. And would have a few questions and suggestions. Hopefully helpful.
First of all, did you manage to get your tables (data that you already have) into the app? I perfectly get your point of not using any REST api-s or online databases, but still I consider that as the easiest way to get your data inside the app. If you have the data in a spreadsheet I would suggest spending a little time on writing a simple Google Script, that would return the data of a spreadsheet as a structured JSON that you could then use with the āset itemā flow function.
Until now, I just played around with local storage but the way I see it that the item key is the id or reference to the data that you store in the storage. The data itself is the other key which is a json object or in simple notation an object with key:value pairs. Similar to:
{ "tubing": "external-upset", "diameter": 1.5 }
And so on.
So the flow of storing your data in the persistent storage would be something like this:
- Initial loading of the app.
- Somehow getting your data from a spreadsheet to list of json objects.
- creating unique ids via the GENERATE_UUID formula, or choose a column of your data as reference. These will be your
item keys
- looping through the list to set each and every row to the storage. (I am not sure wether set item works with lists)
- that is it.
On every later app launch you should already have your data stored in the persistent storage.
At least one would think that is itā¦ But:
You will have to know and feed the id or the item key to the storage to get the data. Then you can set it to a page or app variable and do all your functions as usual. But here comes the big question, how on earth will you know the unique item key for each of your data records if you have more than 1000 data?
Well you could in fact create another item to the storage which would contain all of the item keys.
For that you would use: item key would be like ālistOfidsā and the json object would be something like this:
{ "keys": ["firstKey", "secondKey", ....]}
So on loading the app you first get this list and then can find the rest.
I wish I could understand your reluctance to utilise at least Firebase. It is so much simpler. You would not need to upload all the data, just your base dataset. But you could even go with simply uploading your item keys. But then why not upload the rest?
Now another question. Will it be an ios/android app or a webapp?
And another one? Why do you wish to utilise the Persistent storage? "on-device storage" would not fit your needs? You could also set that on letās say first launch and then use it later on. With that you can simply set data variables to the data records, use get collections, etc. etcā¦
