Joseph Lewandowski

unread,
Oct 7, 2015, 6:35:14 PM10/7/15
to MIT App Inventor Forum
For some reason, my application started to run very slow. I'm using the SpeechRecognition component, yet barely have complex functionality for it. This program is going to be a voice activated calculator, but is failing right now due to the lag. I have four screens. Screen one is the home screen, screen two is the help section, screen three is the calculator, and screen four is for graphing. Here are screenshots of my program to help resolve my problem:

Screen1:











(Extended)


















Screen2:


















Screen3: 











Screen4: I haven't worked on it yet. 

Joseph Lewandowski

unread,
Oct 7, 2015, 6:40:44 PM10/7/15
to MIT App Inventor Forum
Extra Information:

Screen3 has the similar control block to Screen1 because I haven't added the functionality yet.
Where the if-then statements check if you said menu or something close to that, I have not yet changed the string values, since "menu" is not referring to the calculator screen. 
On Screen2, all I did was list out every single possible command in the program. 

Scott Ferguson

unread,
Oct 8, 2015, 12:34:29 AM10/8/15
to MIT App Inventor Forum
You could simplify your testing when the user wants to see the menu or get help.
Menu and help are the key words you are looking for so just look for those words you have one test to do:

Looking for ways to simplify your blocks may have an effect on performance.

Also, I don't see the obvious benefit to going from one screen to the next.

I would imagine you could do with just two screens - a splash screen and an interpreter screen.

---

sf





Abraham Getzler

unread,
Oct 8, 2015, 3:20:32 PM10/8/15
to MIT App Inventor Forum
I notice you have a button that issues an OPEN for Screen1.

No AI2 program should ever open Screen1.
That results in memory filling up because screens are never closed.

Think of your screens as plates to be stacked and unstacked in a single stack,
with no duplication, to keep the maximum height (memory usage) low.

Use the Close Screen block to return to Screen1.

ABG


Abraham Getzler

unread,
Oct 9, 2015, 2:43:45 PM10/9/15
to MIT App Inventor Forum
Note to original poster - 

Your last post(s) arrived in my Inbox, where it was automatically deleted.
Please re-post to this board for world wide support.

ABG

Joseph Lewandowski

unread,
Oct 9, 2015, 2:58:05 PM10/9/15
to MIT App Inventor Forum
My program is still lagging. Here are pictures:

Screen 1:


Screen2:


Screen3:










Scott Ferguson

unread,
Oct 9, 2015, 10:03:03 PM10/9/15
to MIT App Inventor Forum
Screen1: check only for the key words calculator and help
Screen2: "
Opening a screen with App Inventor is like opening another app.
So if you have 5 screens open in succession that is like opening 5 apps.
Try to put your blocks on fewer screens (I would use just one).
With one screen you can show and hide horizontal and vertical arrangements to give the same effect as switching screens but much faster.
---
sf

Joseph Lewandowski

unread,
Oct 12, 2015, 7:32:30 PM10/12/15
to mitappinv...@googlegroups.com
Okay, I know you told me to shorten the way the Voice Recognition collects what you say(the commands help and calculator), but instead of doing that, I wanted to move my blocks from Screen3 over to Screen1 and the blocks from Screen2 over to Screen1 as well. I have changed the names of many components, but my program doesn't work at all. When Button1 is clicked, it doesn't launch .getText as well as the set background color command. Why is this? Please help! 

Screenshots: 












SteveJG

unread,
Oct 12, 2015, 8:42:26 PM10/12/15
to MIT App Inventor Forum
Hi Joseph.    I do not have a solution for you.   You are using both the SpeechRecognizer and TTS in the same app using a compiler that is event driven.  You also have lots of commands the SR is supposed to recognize.  I have lots of experience with command and control using Microsoft's Speech program; the system on Android is similar.

Often the Recognizer is slow, even in programming environments where the compiler results in fast responding apps.  App Inventor 2 is a relatively slow responding compiler.  Its Math routines are slow compared to other languages; the graphics screen is very slow repopulating the screen and there are other issues that make the super app this could be relatively slow in responding.  Additionally, changing screens is not lightning fast, especially when passing variables (why I prefer to develop almost entirely on a single screen using virtual screens). That seems to be what you are attempting.  With lots of blocks, a difficult task.

You are aware AI2 is event driven, it can not multi thread and activities of Android housekeeping can co-opt the operating system momentarily.  Daisy chained SR and TTS activities might not respond as intended because they could interfere with one another requiring possibly Clock.Timer triggering of subsequent commands.

What I can recommend is creating a a copy of your Project (save what you got so far) and experiment with the copy.   How?    You app has several different functions... a voice command, a calculation and the reading of the result with TTS.  I would temporarily disable sections of the blocks ..those involving SR and TTS especially, and get the app to work conventionally.  Your present code does not work..why?   With just a listing, impossible to debug.   I would ensure sections are responding properly using DoIt .   This is probably not what you want to hear.   I assure you, it is worth trying.

When you are done, you will have a very interesting app that probably stretches the capabilities of App Inventor 2 and might have to accept slow response.

Good luck.

Regards,
Stve

Joseph Lewandowski

unread,
Oct 12, 2015, 11:46:09 PM10/12/15
to MIT App Inventor Forum
You're right. App Inventor 2 does have a slow compiler. Would if I tried creating applications using Java? 

Scott Ferguson

unread,
Oct 13, 2015, 6:31:10 AM10/13/15
to MIT App Inventor Forum
Steve has some good suggestions.

Here is what I was thinking if you decide to soldier on...

Is Button1 checked in the designer as Enabled?
Do you set it's Enabled to false anywhere?

I don't see any problem with the blocks you have shown that would prevent the speech recognizer from opening.

If you reduce the number of blocks that set visibility to only one which sets the outermost screen arrangement visible or not visible you may not need the clock timer (see below) at all.

Debugging:

If you need to test values inside your procedures, you can use the Do It tool.

Suppose you wanted to know what the result value returned to the when SpeechRecognizer1.AfterGettingText block is. You could do something like the following:

Create a global variable named debug.
insert a 'set global debug to result' blocks pair at the top of 'when SpeechRecognizer.AfterGettingText' event block before the 'if' block.

On the Blocks Viewer canvas, place a 'get global debug' variable block by itself.

Connect your device for testing and connect to your device with the Companion app.
Touch Button1 on the device screen, speak your text. 

After speech recognizer returns it's result you can right-click on the 'get global debug' variable block and choose 'Do It'.
The result should display in a comment callout.
--

Another method to stitch digits together in the calculator display is to just use the Text join block to join the new digit to the previous digit.

---
With as many updates as you have to the screen display it may be necessary to place your blocks from the Screen1.Initialize event block inside a Clock Timer block to give the screen time to update.

Create Clock1 and uncheck it's TimerEnabled checkbox.

You can set it's Interval value to 0 for the minimum delay, but that should allow your BackgroundColor block time to update the display.
If it doesn't, try increasing the Interval value.
So all you would have inside Screen1.Initialize would be:

Clock1.TimerEnabled to true

Then your blocks in the Clock1.Timer:

Clock1.Timer
  <blocks from Screen1.Initialize>
  Clock1.TimerEnabled to false

---
If all of your calculator buttons are inside screen arrangements then you will only need to set the outermost screen arrangement to visible false or visible true to hide or show your custom numeric keypad.

I recommend that you consider organizing your buttons similar to the following:

Vertical screen arrangement
   horizontal screen arrangement (contains top row of buttons)
   horizontal screen arrangement (contains second row of buttons)
   etc.
---
sf
Reply all
Reply to author
Forward
0 new messages