Keeping BLE connected when switching/closing screen

Dear App inventors,

please advise: I now managed to have a BLE connection to my Arduino clone, however, as soon as I switch (close) the screen, the grafik is false, of course. Technically, the Arduino is still connected, as I can see due to the onboard LED signaling.

Is there a way to keep the connection alive, even when I close and reopen the screen (it's not the manager screen)?

As a workaround, at the moment, I disconnect when the screen closes and I reconnect when the screen is opened. However, including sending the data to the Arduino, it takes several seconds until it's done. If the connection wouldn't need to be re-initialized, it would work way faster.

Thank you!

You cant close/switch the screen without disconnect.
Why are you switching screens?

Because I need to. I know, it's not ideal, but I had to use different screens due to complexity.
It's like three stages: list - description - detail. On detail screen, the BLE connection is needed.

Ok. I cant see the problem to use just one screen.

But if you need it, you have to reconnect the BLE connection.

1 Like

Ok thanks, but the question still is if there is some way around. The answer: it's not possible is easily said but often, there is a way

There is no way. The next screen can be treated as another app. You need to connect to BT again. The only solution is to use one physical screen and create multiple virtual screens on it.

1 Like

Hello consti

What you need to do is use Virtual Screens.

When we define virtual screens, we use one 'real' App Inventor Screen (most often Screen1). Screen-sized Vertical Arrangements on it are displayed/hidden as required - they are the Virtual Screens. This is generally a better approach for multi-screen Apps, they share data without having to "pass" it between screens and it also reduces code duplication, making the App more efficient and the code easier to follow if you have to return to it at a later date.

So, instead of seperate "houses", virtual screens are rooms of the same "house".

2 Likes

Thank you for your replies. I know that one screen design is best practice, now. There are many things I know now, but I didn't knew them when I started building my App one year ago. Let me explain:

Those three main screens I mentioned before actually sum up to ~15.000 blocks, Screen1 alone is 8.000 blocks. If I would redesign my app to one screen, it would take really much time and effort. Maybe I will do it, but at the moment, that's not possible. Besides, when working in Screen1, I already have performance issues with my PC (and it's not the worst one..). Okay, I admit, one screen design would reduce blocks but anyway, the more blocks in one screen, the more computing power is required.

I have an alternative workaround idea, what do you think about it:

Now, the BLE connection is established in detail screen. If the connection is established in Screen1, which is never closed while the app is running, and detail screen sends the data through tiny DB to Screen1 that is awaiting data in a clock, could this work? The question is: while another screen is in front, and Screen1 in the back, would Screen1 actively run the event block from the clock?

If you have that many Blocks on one Screen, you are probably doing something wrong :upside_down_face:

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 :grin: 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 :wink:

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?