OK, Am I tracking here? By using virtual screens, I can reduce program size and eliminate the need for TinyDB, as I no longer have to share data across screens?
While I am designing everything in percentages and "fill parent" widths, I have to have some pretty cut-off arrangements in the designer in order for the page to look right on my screen. Changing to tablet or monitor gets even weirder.
Would you please briefly review how I might consolidate multiple screens into one screen with virtual components? Ideally, I will not have to rewrite code but I am finding the backpack to be particularly squirrely. I understand stacking screen-sized vertical arrangements but I am unsure about populating them.
That depends on what you are ultimately going to do with the data. Do you intend to store it for use at another time or day?
You didn't answer this:
By using Virtual Screens, you will only eliminate the need for TinyDB if it is only used to share data across screens. As we don't know how much data and what you wish to do with it, we can't advise more.
That method should in fact make the App look good on a range of devices. The App Inventor Designer graphics are just a means to an end - the high resolution display of an Android device screen can't be reproduced on the comparatively low resolution computer monitor. When you are designing the interface, connect to the device (smartphone) via the Companion. Then you can see what your design looks like in real time on a real device.
EDIT: If you need to ensure a space between components, say two buttons for example, that should be done by using an empty Label as a spacer. That uses the smallest amount of bytes because it is "dumb" and it is also the most versatile for the spacer role.
You would have to rewrite some of your code but it shouldn't be difficult.
The Virtual Screens (Vertical Arrangements) of each 'Real' Screen can be built with copy-paste from Screens 2 and up. For Virtual Screen1, you can temporarily place it at the top of 'Real' Screen1 at a height of say 30%, then drag the top 30% of components from Screen1 to Virtual Screen1. Then increase the height of Virtual Screen1 and repeat the process until all components are on Virtual Screen1. So to recap, Screen1 components consist of Vertical Arrangements (fixed or scrolling, depending on your requirement). The vertical arrangements display the interface components such as text boxes, buttons, images, charts etc
I dropped the ball here in my struggles. I ultimately will have pressure, temperature, and humidity values that are read from the community (NWS), the same 3 names with different values that may be entered from a keyboard, and an additional three values that may be read from a BLE sensor so a total of nine different values. I started trying to store the data in a block list but storing the 9 variables as TinyDB outputs seemed easier. Yes, TinyDB is populated across all my screens and the namespace name is the same.
Thank you for the video links, I will peruse them shortly. I am attaching four screenshots, 2 concerning my TinyDB setup (perhaps you can tell me what I am doing wrong?) and a copy of my backpack before and after I copy it onto a screen. Is there a trick to prevent large blocks in the backpack from being mutilated when they are copied out of the backpack and onto the screen. I just get a mess that requires reassembly from the smallest block.
Learn to frequently do a right click Cleanup Blocks in the Blocks Editor, to avoid overlap and line up blocks for easy traversal with the scroll wheel.
Also, doing right click export blocks as png on your events and procedures and renaming the png files gives you backup files that can be dragged back into the Blocks Editor workspace on other screens and apps, without use of the backPack.
Regarding your use of TinyDB, I see you are storing the UUIDs, but I don't see you storing the data that arrived from those UUIDs.
The BLE extension is not present in the screen which is receiving components from the BackPack, hence the red borderlines warning that's the case. Note that the Blocks should not have "arg0 arg1 arg2" not sure what has happened there.
However, as ABG has pointed out, you do not need to store the UUIDs in TinyDB, just the value.
Now, why are your BLE Read Blocks in a Clock Timer when you only need to read them once?
Wow, thank you for a ton of information. In answer to that last question . . . because I am totally ignorant about the deeper workings here. The BLE read clocks will change as they represent local readings on my ESP32C3 that update based on the .ino code. I thought I was storing the values, or . . . I thought those were the values. I am clear now that I am trying store a long UUID code and nothing more. Those 9 different values will all update based on a clock or the operator. I eventually will add checkboxes to allow the culling of data into a database or spreadsheet.
The reason I like separate screens is because of the block editor. Combining several screens worth on block code into one display just confuses me. With separate blocks, I have a pretty good idea of what I am seeing. Other than getting the TinyDB to work and loading values and not UUIDS into storage, is there a good reason for having everything in one big screen? I am fine with the screen1 updating when it has been departed from, as a regular course of action.
I don't want to make things difficult down the road but, with 6 or so pages, is there a benefit to virtual screens that outweighs my inexperience with the blocks?
Chris, thank you so much for your information and patience with me. I was not trying to read the text tags and got nowhere. When I duplicated your TinyDB example, I received my first ever piece of data across screens via TinyDB!
I really appreciate your assistance and I hope your advice can be easily found in the future by others in my situation (old, dogged, optimistic, grateful;).
OK, so that means when the data arrives in the App from the ESP32, it should be added to a Block List - one list for each of Temperature, Humidity and Pressure. When the data stream has been stopped, the Lists should be saved in TinyDB, one tag per List.
There certainly is - you can see all of your code on one page - having to change pages can get confusing. Also, overall less code is required because no code is needed for sharing data between screens. Finally, it prevents inadvertent disconnection of Bluetooth, which only works on one screen (you can't add it to another screen as that would be a separate connection).
Sorry for the delay. The BLE data are the only data that I do need to be ongoingly refreshed, as that is specific data that is subject to frequent charge as opposed to NWS data or entering the data oneself.
II guess this is another reason to have everything on one screen - to allow the updating of "streaming" data.
