2016년 12월 24일 토요일

generic failure: message not sent!


Hi, I have a problem. I made the application that was designed to send sms. Unfortunately, I encountered a problem on its way, namely generic failure: message not sent and I do not understand from where this problem wzioł.
adds in Annex screen with the system blocks. thank you very much in advance for your help.

 ukladblokowbramka.jpg
--
How many characters is in the txtwiadomosc block?     You can only send a sms message with a total 'length' of characters plus spaces of about 160 characters.    Or perhaps are you attempting to send an empty message .... a message without any text?  That might trigger an error.    Or the phone number might be malformed.  Dashes, dots, and parentheses may be included (e.g., (650)-555-1212) but will be ignored; spaces may not be included.  Do you include spaces?

The documentation for the sms component is here:  http://ai2.appinventor.mit.edu/reference/components/social.html#Texting

So, do you have more than 160 characters (or very close to that); is the message empty or do you have spaces in the phone number?
Are you connected to a phone network ... if you are using a tablet and do not have phone service, sms will not work.

--
A number that gives looks as follows "514158876" without region code "48" in the content fits approx. 10 characters, the problem has not gone away. But when the law texting1 googlevoiceenabled other information appears in the error, "IO Error: unable to create GVHelper". what im doing wrong?

--
Maybe the message is not sent due to "lack of funds in my account?"

--
I ask again, How many characters is in the txtwiadomosc block?     (How long is the text message Michal?)    The problem might not be with the phone number, it might have to do with the text message length.   The phone number can include th e 48514158876   and is probably necessary for you to make the phone call.

Would you please confirm that you are actually using a phone and not a tablet.  Thank you.

--
Maybe the message is not sent due to "lack of funds in my account?"
probably yes
Are you able to send a SMS manually?
Do you use a tablet? Is your phone able to send and receive text messages?

But if this problem is persisting, please make another post attaching the aia file, with instructions about what exact steps to do to cause the error to happen.

--
I use the phone, the number of characters in a block txtwiadomosc not exceed 160 characters

--
I have a feeling that this script gets the money from my account. Is there a possibility to make an application that will send messages for free as web sms gateway?

--
of course sending an SMS from your device will cost you something, it's the same as sending a SMS manually from your phone

 Is there a possibility to make an application that will send messages for free as web sms gateway?
in case you find an API which offers sending SMS for free, then yes

--
I understand everything. But I have another question. The main objective of the application was to send anonymous messages. and here begins to question. Is it possible to hide or change the number of the sender?

--
No.     ...and anonymous messages sound  a bit like spam.   Is that a nice thing to do?

--
I did not think of it that way. I meant to create an application in this category "fun" that allowed the user to send messages with jokes, etc. while maintaining the anonymity

--
Michal, is the phone that you're having this problem "generic failure: message not sent" a dual sim phone? If yes, then set the sim that you want to send the messages with as the default sim for messaging under sim management settings.

--

Generic failure


Re: generic failure: message not sent!

No. ...and anonymous messages sound a bit like spam. Is that a nice thing to do? Regards,. Steve.
15. 1. 29. 작성자: SteveJG - 작성자 4명의 게시물 13개 86회 조회

Re: "Generic failure, message not sent" error when using Texting component.

unfortunately this is a very bad solution. if you have to send a few more sms, you app will close with a runtime error.
15. 6. 24. 작성자: Taifun - 작성자 3명의 게시물 7개 398회 조회

Re: "Generic failure, message not sent" error when using No Texting While Driving app.

When using the No Texting While Driving app, I get "generic failure, message not sent" error every time I receive a text message and the app tries ...
14. 1. 18. 작성자: Hal Abelson - 작성자 2명의 게시물 2개 234회 조회

Please help me out. Generic failure Message not sent error.

I'm having Generic failure message not sent error. What should I do. Here is my Screen short for both Design and Blocks.
12월 23일 작성자: Mudi Husayni - 작성자 3명의 게시물 7개 15회 조회

generic failure: message not sent.

what is the mening of this message.
15. 5. 22. 작성자: battas zakaria - 작성자 2명의 게시물 9개 83회 조회

create sms sender on dual sim card phone (+62) code.

i have try to made some simple aplication just only to send mesage but alway get notification "Generic Failure: messege not send"
14. 8. 27. 작성자: zahiraya - 작성자 2명의 게시물 3개 42회 조회

Re: cannot change label text programmatically within while loops.

... a "Generic failure, message not sent" for the 2nd sms, while they send succesfully the 3rd one (I did not try sending more than 3 "long" sms).
15. 3. 23. 작성자: Filippo B - 작성자 2명의 게시물 6개 318회 조회

Re: Error With Emulator.

Failure of the emulator to run can be due to many things. Do you have Companion 2.24 loaded on your PC. Try Connect > Hard Reset ; if a pop up ...
15. 3. 6. 작성자: SteveJG - 작성자 2명의 게시물 2개 55회 조회

Please help me out. Generic failure Message not sent error.


I'm developing an application for reporting criminal cases for Nigeria Police force.
This apps will send message and current location of the sender. 
I'm having Generic failure message not sent error. What should I do.



Here is my Screen short for both Design and Blocks.

-- 
are you using the emulator?
is your device able to send and receive text messages?


-- 
Reply @ Taifun 
Thank you for your response. I build the app and install it on my phone for testing. that when got the error message Generic failure message not sent.
what should do

-- 
follow Ghica's advice
pro tip: do a search in the forum!

-- 

classer une liste (Classify a list)


Good evening to all and good Christmas.
I would like to classify elements of a list in ascending order, and that each item added to this list is also classified.
Is there a tutorial that would explain how to do this?
Thank you for your help
-- 
How to sort a list using the webviewer(!)

sort.aia

also don't hesitate to do a search in the forum...

--

Screen1 "not returning" after other screen closed


I am currently developing a relatively complex, multi-screen application (the blocks of one screen need 2 lateral and 7 vertical scrolls at maximum zoom out to cover all the events and procedures, and I have 6 screens with user interface widgets already, so I suppose it qualifies as pretty complex). One of the capability I want to build-in is support for multiple languages, where all the button captions, labels and dialogues are housed in language-coded files (which could even be supplemented by users), one of which is read as a function of the user-selected language, copied in TinyDB, and then accessed by all the relevant screen and used to set up all the relevant text bits through a series of statements in the various screens "Initialize" event.

In order to streamline processing, the actual reading of the language file and the loading of the TinyDB record is done by an auxiliary "shadow" screen, which is opened when the application initializes for the first time, and again should the user select a different language from the currently defined one (through a list picker .AfterPicking event), which is supposed to then override the TinyDB record with the different language captions. That screen is supposed to "close screen with value" at the end of the reading and loading into TinyDB, and hopefully return control to the screen that did the calling, where it should trigger the appropriate ".OtherScreenClosed" event, which will then call whatever procedure to update all the relevant captions and labels in the alternate language using the copy passed through the TinyDB tag.

Except that it doesn't.

When launching the application for the first time, it starts with Screen1, as expected, which then checks if there is an appropriate "loaded language" tag in TinyDB and upon not finding one, calls the language read routine to load the default English file. That screen is supposed to complete the reading and return to Screen1, but all I get after waiting an inordinate amount of time is a blank emulator screen, while the web browser development page in "http://ai2.appinventor.mit.edu/" switches back to the Screen1 block page, indicating that the file reading screen is supposed to be finished with its processing and closing... but somehow the Screen1.OtherScreenClosed event is not triggered.

Not seeing where this comes from, I peppered the code with progress caption markers at the start and end of most concerned procedures and event blocks, directed to a log file that I can visit thereafter. And I do have the proper sequence of 

⦁ "Screen1 calls language reading screen" (that statement is placed just ahead of the "open other screen" call)
⦁ "Language reading screen initiate" (at the head of the Initialize block) and the 
⦁ "Language reading screen about to return" (at the end of the .GotText block that loaded all into the TinyDB)

being issued, but the expected Screen1.Initialize that ought to follow the return, let alone the message at the start of the Screen1.OtherScreenClosed event block, never comes. And I have waited something like 15 minutes before stopping the emulator and running my "message log file visit" application (where on Earth is /sdcard anyway? I tried searching for the filename across all directories, and can only conclude that this directory is hidden or somehow "encoded". Having to rely on a custom application just to look at the content of the log file is some kind of an additional annoyance).

What is stalling the code?
Are there some additional, little known and poorly documented limitations in the emulator, or in App Inventor 2 itself, like a maximum number of pending processes, that I am unaware of?

For the record, the "aia" file is 648 KB. Even taking all the other files that are supposed to be part of the installation into account (images, data files, icon, etc) brings the total memory requirement to 1.23 MB, far from the limit, as far as I can understand.

I have been at it for over a week already, and not showing any progress; and now, on top of it all, I am out of ideas what to try next.

So, does anyone have anything to suggest? 

Any help would be much appreciated.

--
see here

Current limitations of the AI Companion app:
1, The close screen block triggers the Initialize event instead of the OtherScreenClosed event.
2. The close screen with value block triggers both the Initialize and OtherScreenClosed events instead of only the OtherScreenClosed event.
3. The close application block does not work, a message 'Closing forms is not currently supported during development' will be displayed instead.
--
Did you miss the bit about "close screen with value" visibly NOT triggering either Initialize or OtherScreenClosed, on account of my trace messages not showing any access to those blocks?

I am switching screens EXACTLY following the "recommended method".

--
to test switching screens, build you app and test using the apk file

--
Looking at the sources it should be the case that OtherScreenClosed should be triggered. Can you give us an AIA that demonstrates the problem? Regarding Initialize, it will only be called when the Screen is created (analogous to constructors in object oriented languages) so do not expect it to be called when returning from a screen.

--
That could take some doing. For the time being, I have disabled to feature so that I can concentrate on checking and debugging the rest of the app; I am wondering if there could be some bad interaction between the pages that are hurting the behaviour in a silent way (given that the emulator will mure error reporting for 5 seconds following the first one, and since the code does so much behind the scene housekeeping, who knows what goes in there at this point in time).

When I can get the other pages to run without error, I will check to see if the OtehrScreenClosed logic is still an issue. If it is, then I will make a most lightweight version of the app featuring the problem for posting. That may take some time.

--
as already said: use the apk file for your tests and follow the manager screen method

--
After many attempts, and a whole lot of efforts, I think that I managed to corner the issue.
I do not know if this is limited to the emulator or would manifest also on a bona fide Android device, but here goes.
My application is quite lavish in terms of data presented, as I indicated before. Some of those were put in TableArrangement. And I think that they are to blame for it. I completely rebuilt the pages using HorizontalArrangement nested in VerticalArrangement (that alone took well over 16 hours of work; told you it was complex) and now the page opens.

For the record, each TableArrangement had content of their own, Label and TextBox mostly, so that they would be arranged in neat columns and rows, and presumably between the fixed dimensions and some "Automatic" ones, that was apparently enough to stall the emulator completely. Switching between pages featuring TableArrangement and those that did not was apparently what caused the issue, I could not even start the emulation on the page that had such a table, but could on those that didn't, and those that didn't could then not swap pages to those that had tables.

It is far from over yet, as far as I am concerned, as I have now to migrate the data processing blocks to the new table-free page. The backpack will be useful, but cannot help wonder why the Designer does not have a feature for copying components; that would have significantly reduced the time taken to set-up the alternate, table-free screen.

--

PuraVida sqlite - sql syntax error (code 1) near "="


I'm doing an app with the puravida sqlite extention
I already can add items to a db and can read from it
now I whant to delete one entry with a delete button
but I just cant, its giving an error back

on the execute sql I have 

DELETE FROM ferramenta WHERE id = 
& globalvar = id 
It gives DELETE FROM ferramenta WHERE id =1

It returns an error:
ERROR: near "=": syntax error(code 1): , while compiling: DELETE FROM ferramenta WHERE id =1

This should be wright... what am I doing wrong?

-- 
DELETE FROM ferramenta WHERE id = & globalvar = id 


use the join block to join the text 
DELETE FROM ferramenta WHERE id = 
and the global variable
id

It would really help if you provided a screenshot of your relevant blocks, so we can see what you are trying to do, and where the problem may be.

-- 

Hope it helps


-- 
Tried to add ' ' but to no luck... 

-- 
please post your CREATE TABLE statement oft your table and I will take a look...
probably id is one of the reserved words?


-- 
Thanks, your great

-- 


FAQ for Companion and Emulator


Emulator Trouble


After the emulator process was set up, and everything was completed, the emulator screen remained white. I have had it running for 30 min. now and it is still white. I additionally recently updated the emulator software this month, so I figure that is not the problem. Please help. 

-- 
There are alternate emulators you can try in the Companion and Emulator section of this FAQ: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/mitappinventortest/2cd6Uz__xA0/cPQSiZpcDAAJ

I prefer GenyMotion Free for its speed and version control.

-- 

Publishing an App with an Extension


I've made a simple app that uses the Bluetooth Low Energy (BLE) extension. When I go to publish it to the Gallery, it says that we are not allowed to publish apps with extensions to the Gallery. Does anyone know if that 'feature' will be supported in the future?

I've downloaded the .apk and installed it on my Android phone, but it doesn't seem to be able to work with the my bluetooth radio. Everything else with the app works, but when I scan for BLE devices nothing ever gets found. Perhaps there's something else I should be doing in the app to initialize the BLE component that doesn't need to be done when using the MIT InventorApp in companion mode?

-- 
Whether extension will be supported in the future: maybe. So far extensions are experimental and until they mature, it is not likely that you can add them to the gallery, but you can publish your apps in the Play store as you can any other AI app.

I am wondering now how you developed uyour BLE app. Did you try to use the AI Companion on your phone and run it that way? If that works, your .apk should work too.
Post a screenashot of your relevant blocks, then we can take a look.

-- 
I thought that the BLE extension was considered mature and supported because it is not in the 'unsupported' section of this site: http://appinventor.mit.edu/extensions/ perhaps 'supported' doesn't necessarily mean 'mature enough for gallery usage'?

I did use the AI Companion app on my phone and I connected it via wifi. That did seem to work. 

Attached is the .aia file that has everything, as well as the compiled .apk file. I still have all of my blocks on one 'page' within the blocks editor. I assume the best way to organize all of those is to make them into procedures, but I just haven't done that yet. Let me know if I should take multiple screenshots and post them up here.

When you open the app there is a button to start scanning, and it should show a list of all the BLE devices, then if you press the button at the top, that sets a variable that then allows you to connect to the BLE device that is at that index in the list of BLE devices. When I first installed the app on my phone I got a pop up warning saying that BLE advertisements were not available. I had seen this error before when my Bluetooth was turned off on my phone, but after I turned the radio back on and I hit 'scan' it never found any devices, even though there were multiple in range that were sending advertising packets. 


-- 
Both the BLE extension and extensions itself are still experimental as far as I know. Which does not mean that you cannot make apps, but there is no guarantee that what you will make now will still work in a next release (well... is there ever?)
The warning about advertisements means that the BLE implementation on your phone does not support them, therefore you cannot run an app that needs then. But there is still a bug in the BLE extension that gives this warning even if you do not intend to use it. The problem then is that your app does not have the required permissions and will not work.
The easy work around is to include the old BT compionent in your app. You do not need to use it, just drag it into your design area.
If you now compile your app the necessary permisson will be included and your app should work (provided it did this using the companion on your phone).

-- 
When I go to publish it to the Gallery, it says that we are not allowed to publish apps with extensions to the Gallery


it seems to be, the Gallery needs an update to accept apps having extensions, too...
@Dave?


Both the BLE extension and extensions itself are still experimental as far as I know. Which does not mean that you cannot make apps, but there is no guarantee that what you will make now will still work in a next release 
@MIT: is Ghica's assumption correct?
as far as I know, the extension feature has been finally released 6 months ago... however the AppinventorExtensions document still needs an update...

-- 
Extensions are still experimental, as Ghica says.   We will be updating them, and that might require updating the extension aix files.
Two issues we are looking at are the need for extensions that provide more than one component, and interaction between extensions and the library.
Jeff can provide more information.  He is working on this, but no ETA.

-- 


How many AppInventor?


I have a problem, do not know the difference between these two AppInventor ...


Thanks in advance to those who will give me an answer

-- 
1) this is an outdated test version of the services feature, which still needs loads of work, I recommend you to NOT use that server

2) this is the main App Inventor server you should use

-- 
The n) 1 server allows you to work background apps, why not recommend to use it?

thanks a lot for your valuable help

--
The services implementation is not ready for general use because interaction with Android power management.
We're studying the issue but don't have a clear solution yet.

-- 
thanks a lot to everyone

--


PHP parameters


I know this is an AI2 forum and not a PHP forum. But I think the question I have is more of an AI2 issue. I have:

⦁ MSSQL database (sqlexpress)
⦁ PHP 5.6.25
⦁ MIT AI2

I can connect to the database and run the query and INSERT static data. I need to be able to extract data from AI2 app that users SUBMIT. I don't need to send the entire QUERY, just the user data. My question is how do I send and then extract data from an AI2 app to a PHP script?
I know this is not secure, I'm just trying to get it to work.

I've attached the blocks and here is the PHP script:

<?php

$serverName = "server\sqlexpress";
$connectionInfo = array( "Database"=>"secondOne", "UID"=>"major1", "PWD"=>"payn32");
$SQLKEY="secret";

$conn = sqlsrv_connect( $serverName, $connectionInfo);

if( $conn ) {
echo "Connected OK10.";
}else{
echo "Connection fail.<br />";
die( print_r( sqlsrv_errors(), true));
}

$first = ($conn, $_POST['name']);
$second = ($conn, $_POST['age']);

$sql = "INSERT INTO tble12 (first, second) VALUES (?, ?)";
$params = array($first,$second);

$stmt = sqlsrv_query( $conn, $sql, $params);
if( $stmt === false ) {
     die( print_r( sqlsrv_errors(), true));
}

?>

-- 
What happens if you run your app?
Does it work or do you get an error message?
If it works, then you did not need to ask the question. So I assume it does not work.
What was the error message, or what were the symptoms of it not working?

-- 
When submitted, NULL is INSERTED into the database. Which means it's not extracting the submitted data. I don't get an error message - as the query is run and completed. I just don't get any data inserted.

-- 
it seems to be, you forgot to urldecode your values in the php script
you might want to compare with the MySQL solution here http://puravidaapps.com/mysql.php
mysql.aia
mysql.php

$query=urldecode($_POST['query']);

-- 

WHY APPINVENTOR DID NOT IMPLEMENT BACKGROUND SERVICE?


The INVENTOR APP is perfect, but does not have the ability to keep running even after it's closed. How can I program an alarm for example? Why have not they implemented this feature yet?

-- 
The developers are currently working on it. 
Probably it wasn't implemented in the beginning because App Inventor is more a learning tool rather than a programming platform.

There is a test server, if you want to try it, but be aware that it may change or disappear in the future. Also looks like some of the new features in the current version of App Inventor 2 are not yet implemented in that test server.


Remember, this is for testing only. There's no support for it yet.

-- 
six months ago I had fun using the services in the background, I was able to record with the microphone, or use the accelerometer he wrote on sdcard.Un little bit, but it 's a good start.

-- 
It is useful to make a prototype of app.
I hope that AI2 become a mutual tool like a bridge for both beginner and engineer.

-- 


Using Images with MIT App Inventor


Avoid some common pitfalls!
Synopsis: 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.  

1. Out of memory errors

People building apps in App Inventor might find that their app crashes when they try to run it, with an error message like:
Failed to allocate a 25165836 byte allocation with 3395432 free bytes and 3MB until OOM
What’s happening here is that the app is is running out of memory (OOM).  In the case of the message above, the phone is trying to allocate 25 megabytes (25165836 bytes) but there are only 3 megabytes (3395432 bytes) free.   The most common reason for attempting to allocate such a large amount of memory is that the phone is trying to display a huge image, generally an image much larger than the app requires.
Every image has a “size” based on its width and height in pixels.    You can multiply these two numbers to get a sense of the amount of memory required for displaying  the image.
App Inventor lets you get  images (for example, from the Web) and import these into your app as Media.  When you use the images, and App Inventor will rescale them to fit the designated screen area in your app.    Sometimes the image to be displayed will be larger than the designed phone area.   Even so, the large image needs to be held in memory in order for rescaling to occur, even if the result of the rescaling will be a small image.

2. An example of misusing large images

Suppose you are going to display a grid of the letters of the alphabet, where each letter is in a 30×30 pixel square.  You’d expect that to take 30×30 = 900 pixels per letter, so the entire grid (assuming 4 bytes per pixel, which is typical for Android) would require 900×26×4 = 93600 or about 100 kilobytes, which will easily fit in the phone memory.
On the other hand, suppose that each letter is loaded from its own image file into the app’s Media from a high-resolution image where the size of each image is 1000 pixels by 1000 pixels.  Each of those images requires 1000×1000 = 1 million pixels or 1000×1000×4 = 4 Megabytes and the entire grid would require 26×4 = 104 Megabytes.  Typical amounts of memory available to a running app range anywhere from 20 to 50 Megabytes (not to mention that MIT App Inventor requires the app source file, including images, to be less than 5 Megabytes).   So the app will simply not work, and the project will get an OutOfMemory exception when it loads.
Even if the app could work, the result on the phone would hardly look different than if you’d used 30×30 images for the letters.  At the end of the day, each image on the screen would be 30×30 pixels, even if it required 4 Megabytes to generate it: a huge amount of wasted space.
Keep in mind that if the original image is larger and is scaled down to 30×30 for display, the image will still consume memory on the Android deviced based on its actual large size.
There’s no reason to load a giant image file into your app if you will use it displayed only as a small image on the phone.

3. Use images that are  “Just the right size”

The general point of the alphabet example above is that you should try to use images whose size is close to the actual size they will appear on the device.  There’s no reason to use larger images: it just wastes space.  And if you use smaller images, App Inventor will scale them up to fit the screen, which may lower  the image quality.  
Rule: Resize images to make them not too large and not too small, but rather, “just the right size”.
For example, it’s common to see apps that violate this principle with background images, where a person downloads a high-resolution image (e.g. 3000×3000 pixels) and sets that as the screen background.  That just wastes space.    It’s better to resize the image to better match the device’s screen size before uploading it to the app.
There are many tools that you can use if you need to resize images to be “just the right size”. Tools  include Photoshop, Preview (on MacOS), GIMP (on MacOS and GNU/Linux and Windows) and Paint (on Windows PCs). There are many more. Some tools are commercial software other tools are free or provided with the computer’s operating system. You do not need a particularly fancy program (like Photoshop) just to do image scaling. There may even be websites that you can upload your images to that will rescale them or compress them for you. A Google search for “programs for scaling images” or “image compression” will likely turn up more than a few candidates.  However, compression is not what is needed; you want to resize to “just the right size.”
You can also use services like Google image search to find images for your app that are already the right size, so you don’t need to rescale them.
Keep in mind  that image size refers to the size (height and width) in pixels.   You can find this using one of the tools above.   It’s not good to rely on the file size of the image as a guide because most image file formats have some amount of compression.  Depending on the type of image and the actual image contents, a large image may compress to a small file. The compression factor can be particularly significant with graphics (as opposed to photographs).

4. Preferred Image Format

What is the best image format to use for images images?   Although many formats are supported, most users will get the best results using JPG (JPEG) or PNG images.  The PNG images will generally look sharper than JPG on Android devices, due to the difference in compression algorithms although the file sizes tend to be larger that JPG.  (PNG uses lossless compression; JPG does not.)  Avoid BMP  images; BMP images are huge compared to other formats because they are not compressed at all.

5. Picking “just the right size”

When you resize an image for use in an app, you don’t need to exactly match the size it will appear on the screen.   It most cases, it will be adequate to get sizes within an approximate range and let App Inventor’s automatic scaling do the final adjustment.   One exception to relying only on automatic scaling is that if the image size is much smaller than the screen area size, then the image on the screen might appear low quality.  
You might want to try to avoid automatic rescaling altogether and match image sizes to the screen area size exactly.  That could work if you are designing your app for a single device.  But different devices have different screen sizes and different screen densities (pixels per inch), so there’s no single image size that can exactly match all devices.
In principle, having your app display the best quality images on all devices, could require you to  provide copies of each image at several sizes match to different devices, and then have the app pick the appropriate image when it runs.   This is the approach taken by Eclipse and Android Studio.  In designing App Inventor, we did not want to require our developers to deal with this complexity.    So we suggest that you pick “just the right size” depending on the device you care most about and rely on App Inventor’s automatic scaling do the best it can.  We might add the multiple image capability to App Inventor if there is enough demand for it.

6. Determining the size of the image on the screen

Multiple devices aside, the size for the displayed image on the screen will depend on how the app is designed.
In some contexts, when you use an image, the size of the image will be used to determine the size of the object on the screen.  For example in the HelloPurr tutorial, you set a button to have an image (the cat in this case) as its on-screen representation and set the Height and Width of the button to Automatic.  In this case, the size of the image determines the size of the button.
In other contexts the image is scaled to fit a specified size. For example if you place an Image component on the screen and set its Width and Height properties each 100 pixels, then the image displayed will take up 100 pixels of the screen in each direction, even if the actual image you load is a different size.   Android will automatically scale the image to fit the size of its container when it is displayed.   Keep in mind that if the original image is larger and is scaled down to 100×100 for display, the image will still consume memory on the Android deviced based on its actual large size.  To repeat the main rule:  It’s just wasting space to load a huge image if you will use it displayed only at small size your app.

7. Details on fixed vs. responsive sizing

This section provides some background on App Inventor image scaling and how it has changed over different App Inventor releases.
App Inventor introduced Responsive sizing in August 2015.   Prior to that release, App Inventor created Apps that were marked for Android API 3 (Android version 1.45).  That meant that MIT App Inventor Apps prior to version 1.45 of App Inventor 2, created apps could run on phones as old as Cupcake (Android 1.5). However there was a catch. With API 3 Android supported only a single device size (320 pixels wide by 480 pixels high) and a single screen density.
Newer devices usually are both larger than this and support “denser” pixels (there are more pixels to a inch of screen space). Unfortunately, when a newer device loads a program designed for API 3, the Android automatically scales the screen to make it “look” like the older device. This compatibility mode makes tablets look like giant phones and simply magnified the 320 x 480 pixel screen, which could make images (and fonts) appear to be low quality.
As Android evolved and MIT App Inventor matured, AI2 developers expressed a desire to design apps that looked good on tablets.  Additionally newer Android devices are being shipped without the API 3 compatibility mode.  This made MIT App Inventor apps use just a small section of the screen and not look right.
To support those devices  the MIT development team needed to abandon support for Android 1.5 and require at least to Android 1.6 (Donut, API 4). Starting with API 4, Android is aware of different pixel densities and screen sizes. The improved screen handling makes Android application development more complicated than before because now the application developer has to design their application to deal with different screen sizes and densities. The approach taken by Google is to design several UI versions for your application, complete with each version’s image files, and provide all of the images in your APK file. The device then chooses the correct set at runtime.  This is the system used in the Eclipse and Android Studio compilers.
We decided that creating  multiple UI designs on the Google Eclipse/Android Studio model, is more complicated than we want to subject the App Inventor programmers to. We also did not want to make a change to App Inventor requiring  every App Inventor programmer to deal with different size devices and multiple duplicate images.  We did want, to maintain the compatibility mode that we had with API 3. However to do so requires us to provide our own compatibility code, which we have.  The result is Fixed sizing (which is an attempt to emulate the original API 3 compatibility mode as much as possible) and Responsive sizing.
In current releases of MIT App Inventor you can set the “Sizing” property on Screen1 to either “Responsive” or “Fixed” (with “Fixed” being the default for new projects and older projects that automatically get upgraded). Fixed mode attempts to emulate the old API 3 compatibility mode behavior. The emulation does not duplicate the old mode exactly, but it is close enough in our opinion. Responsive mode does not invoke this compatibility feature.   Programmers using Responsive sizing may have to pay attention to the differences between devices. To make this opportunity to code for multiple screen sizes as easy as possible for AI2 developers  we introduced a way to specify the width and height of screen elements based on a percentage of the device’s screen, instead of having to give absolute pixels.
Another change that comes with this upgrade is the notion of “Density Independent Pixels” or “dips.” Density independent pixels are a measure of size that takes into account the screen density of a device. On some devices a dip may map to one pixel while on others it may be nine pixels. The idea is that most screens will have the same number of “dips” to an inch of screen real estate.
Developers can still give UI elements sizes in “pixels” in App Inventor, but realize those pixels are in fact dips.
Images are still based on “real” pixels. So if you load HelloPurr onto a denser device, the cat picture will be smaller than on a 320×480 pixel device. To deal with this difference App Inventor automatically scales images when it loads them based on a device’s screen density. This automatic response can cause issues with memory consumption.   Returning to the Alphabet example above, if  you  attempt to load the Project into a device with a screen density of 3 (not uncommon) the Project will try to use 9 times as much memory as the original example with density 1, or 2.3 Gigabytes of memory. So even if the original example fit in memory on a device with a screen density of 1, it will certainly not fit on a device with a screen density of 3!

8. In summary: What MIT App Inventor Programmers Should Do

The simple solution is to make sure that the images you load are the “correct size” for the device you care about most and let App Inventor scaling handle the rest.   To return to the Alphabet example, the images of the individual letters should be scaled to be 30 pixels by 30 pixels. If you resize the images to 30×30, each image will  require only about 1000 bytes of memory (instead of 10 Megabytes!).  The entire alphabet will fit in 26,000 bytes of memory. Even if you load this onto a device with a screen density of 3, it will  consume only about 200,000 bytes of memory.