If you have that many Blocks on one Screen, you are probably doing something wrong 
1 Like
Not really, you can copy-paste the Screen components into Vertical Arrangements and the Blocks can be copied over via the BackPack. You would just replace Open/Close Screen Blocks with a Procedure to do the same with the Arrangements.
Unfortunately, each Screen behaves like an individual App on Android, they know nothing about each other 
So, would not work, only the current Screen is active.
1 Like
Even without moving on to Virtual Screens, it should be possible to reduce the number of Blocks used substantially, with different coding practice. For example, perhaps you are using a lot of global variables where a Block List might be more efficient, or assigning values to components with individual Blocks when an "any component" loop might be a better choice, or perhaps you have several instances of a component when only one, recycled, is required.
1 Like
Ah ok, many blocks mean I'm doing something wrong. It can't be that my app is complex, it has to be a wrongdoing..
Strange. I already had a constellation when on Screen1, there was something running in a clock while it wasn't the screen in front.
Sometimes, it's frustrating when people always tend to say: it's not possible. But I'm an inventor and I never give up, and until now, I always found a solution
That's absolutely the right way to be - but don't mock the unpaid volunteers trying to help you, especially given the fact that they know far more about App Inventor than you do.
1 Like
Here's a list of patterns in blocks that need to go on a diet, and how to fix them:
- box of combs
- If your Blocks Image looks like a box of combs, you need to switch if/then/elseif logic to table lookup from tables loaded from the Media folder.
- sea of purple
- if your Blocks Image looks like a sea of purple text blocks, you should instead be loading your data at startup from text files in the Media folder.
- deja vu
- If you keep seeing the same pattern in different places in your blocks, you need to code procedures for that common code function, and change those code blocks to parameterized calls to the new procedures.
- Event Macaroni
- if you have the same event block repeated for lots of similar components, consider keeping lists of those similar components and having one generic event block service the events in that list.
5 Likes
Good morning,
First of all, generally, I really thank everyone for his/her time when replying here and investing unpaid time in order to help someone else, I really appreciate this!
Please excuse me @ChrisWard, it wasn't my intension to mock you and as I can see, you really know a lot about AI2 and your guides on your homepage are great, thank you. I admit, I was first frustrated when reading your reply because it didn't help me to find a solution and it was not directly related to my question and the topic. I agree, reducing blocks is always possible, but please also believe me when I tell you that my app is huge, not due to high redundancy but due to many algorithms needed. At the moment, it sums up to 18.859 blocks in total.
Anyway, this in another topic, but thank you @ABG for the instructions how to reduce blocks, it's really a good guideline.
But, back to my original question, I would like to let you know that I found a workaround myself. In order to encourage others to think around the corner and never give up, I should mention this. I'm now establishing the BLE connection in Screen1 and send the data to the Arduino when opening a list item, as the required data is already available in this screen. When the user walks through the other screens, the connection keeps alive. It's not what I originally planned, but it does what I need, too.
Ok, you convinced me, I will have a try. However, I know it will be a lot of work because I will also have to change parts of the app logic and I will have to adjust component names etc. It's the next project 
I have another short side-question: Is it possible to establish an BLE connection without activating location?
Thank you
Hello consti
That is actually an Android security measure so location is essential (fine location for BLE).
1 Like
They could be in a single HTML file, as Javascript Functions. You could then feed variables and function name to a Procedure which would return the result.
Ok thank you, this approach is something I have not thought about yet. To be honest, at the moment, I can't fully imagine how this works. So the HTML file will act like a procedure container?
Here are some samples:
Essentially, yes. No Internet required.
Try this: dataFromScreen2.aia (4.1 KB)
Build the APK and check ...
Note: In order for the timer to work in the background for a longer period of time, a Foreground service is also required.
Screen1:
Screen2:
See also here:
1 Like
Bear in mind that we have seen memory corruption issues when a Clock Timer is left running in a screen that is not the currently displayed screen, so advice has been to disable all clocks before switching screens.
When Screen2 is closed, the timer is disabled automatically. On Screen1 the timer must not be disabled, because the result is needed on Screen2. Screen1 is not closed but only in the background. There have never been any problem running a Clock when the screen is in the background (not visible or in idle mode).
An example to work with two Screens and Bluetooth in this topic:
2 Likes
As I understand the situation, that is the intention, but it doesn't always happen.
Thank you very much @Anke @Juan_Antonio !
Your answers are a a combination of a clock and a Tiny DB, this was exactly the idea and the question I asked, and you solved it.
1 Like