General Tips and Tricks for App Inventor

This list was made by @Taifun

  1. Use different screens wisely
    Before starting to create another screen, first you should think about is it really necessary? See also Building apps with many screens and SteveJG's post about advantages/disadvantages, because in only one screen you also can use vertical arrangements to simulate different screens, just set the arrangements to visible = true/false as needed...
    If you decided to use different screens, then you should switch them correctly, else you will run out of memory after a while... The recommended method of switching screens in App Inventor

  2. App Inventor works best if you use images whose size matches the size you want them to appear on your screen. If you import larger images into your app, your app may run out of system memory. Using Images with App Inventor

    by @Italo
    First, you need to understand that the file size of an image is not the amount of memory it uses when it's being displayed. The file size is the compressed size, much like a zip or rar file. When viewed, the image needs to be decompressed.
    For example, if your image says its file size is 100 kb, and its dimensions are 1024 x 768, 32 bit color, then that image uses over 3 mb of RAM (not 100 kb!) when you show it on the screen. ((1024 * 768 ) * 32) / 8 = 3,145,728 kb (3 mb)

    Now, this is a mistake most people make when using arrangements as "virtual screens": They set different image components with their images loaded but hidden, instead of having only one image component and changing the picture according to the user's selection or app events, not knowing that apparently the hidden image components are also using the ram, (yes, even though they are invisible!).

  3. Avoid redundancy
    Probably it helps to read chapter 19 - 21 in Dave's book to get an idea how to do DRY programming with App Inventor - Don't repeat yourself

  4. See SteveJG's monster list of tips and tricks

  5. How to overcome the App Inventor project limit of 30 MB

  6. Backup your project frequently


see also the following statements by @ewpatton
(copied from here Are App Inventor Projects Limited to 10 Screens? - #7 by ewpatton)

There isn't a hard limit on the number of Screens in an app.

When used properly, multiple screens are a perfectly reasonable way to organize your app. For example, in a app for finding restaurants you may have a main screen with a map, a second screen that shows restaurant data, a third that shows menu contents, a forth that shows pictures of food, a fifth that shows reviews, etc. In this design each screen is a view over some model (cf. model-view-controller design pattern). The wrong way to use screens is to create a screen for each individual instance in your model (i.e., a screen for ABC restaurant, a screen for XYZ restaurant, etc.), which is often how screens are used because beginners haven't yet internalized the abstractions necessary to know when it makes sense to really use a new screen versus reuse an existing screen.

It's also not true that many screens necessarily implies memory issues when the app is running on the device. Android will first try to kill other applications that are not active to free up memory. With proper management, you can certainly build a multi-screen app that never runs into memory issues by closing screens to pop them off the activity stack. Conversely, you can also build an app with 2 screens that will overflow memory by constantly having one open the other and vice versa, effectively attempting to put an infinite number of screens onto the (finite) stack.

The other major consideration around number of screens is from a performance perspective in App Inventor itself, namely that it needs to load these files from the server (each screen is 2 files--designer and blocks), which takes time. There are also some not-quite-efficient design choices in App Inventor because it was originally designed to only model a single screen. These design choices cause multi-screen apps to take quite a bit of time to load and for the browser to use quite a bit of memory to support them. All screens are "open" at once in App Inventor but only one is ever shown at a time, and so this extra memory cost can slow down the website on older hardware and computers with limited memory. I have previously worked on some changes to address these performance issues but they are not yet in production.


For screens :

Don't you think these blocks would be best :


Instead of looping over all Virtual Screens every time you need to make one visible, you could have managed a gloable currentVirtualScreen and when you are to make smother to be visible just make visibility of current to be false and make the required screen true and update the global currentVirtualScreen varialbe with the current visible screen you just made visible.


Ya but in case somehow some other virtualScreen is also open, it would close it. That's why I looped all these.

At the initial all would be visible false, so in every case one would be visible and that is refrenced by

at all time, when you need to make othere to be visible just make the current to be false and required to be true and update the global currentVirtualScreen with the new one.

wo0ow great tidy optimized way for lot of screens project [ beautiful mind ]

1 Like