Simple Color Selector in AppInventor – Better Solution

The Background

In my last post, I detailed the attempt to use a ListPicker element to make a quick color selector.  It dead ended when the selector brought up only color code numbers instead of a human friendly color blocks to select from (see Creating Color Selector Using ListPicker Element in AppInventor2 – Not a good idea).

The Plan

I am now going to attempt another method to make a more elegant color selector using a second screen.  There is a great tutorial that shows a similar type function at, but that is quite complex and covers several other concepts.  I am going to GREATLY simplify it here.

The Screen Layouts

I am going to leave the ListPicker element and functionality from my previous post (link to the post above) to compare the 2 methods.  First I added another Button element to link my new functionality to.  I then added a second screen by clicking the “Add Screen…” button (circled in the next screen shot) and naming the new screen “ColorSelector” in the dialog box that popped up….


Next I chose “ColorSelector” that I just created in the screen selector pull down.  On that screen layout, I added 3 buttons and set the default color to some example colors….


This sets up both screens.  Now I added the code Blocks…

The Code Blocks

First was to bring up the ColorSelector screen when the button is clicked on Screen1….

  1. Select “Screen1” to work on in the screen selector menu.
  2. Pull out the “when Button1.Click” block.
  3. Add the block to “open another screen”  (under the “Control” group).
  4. Add a text block set to the name of the second screen as the screenName parameter.

Here is a snapshot of my code block….


Next is the functionality for the color buttons on the ColorSelector screen.

  1. Select the “ColorSelector” in the screen selector pull down.
  2. For each of the buttons, add the block to “close screen with value”.  This block is under the “Control” group.
  3. Attach the corresponding button’s background color to be sent back as the result back to Screen1 and close ColorSelector screen.  The result will be used later in Screen1 to set the color of the button.

Here is a snapshot of my code block….


The final step is to set the button background color in Screen1 to the result that was sent back from the “ColorSelector” screen.

  1. Select “Screen1” to work on in the screen selector menu.
  2. Pull out the “when Screen1.OtherScreenClosed” block from the Control group.
  3. Pull out the “set Button1.BackgroundColor to” and attach the “get result” from that block as the color to be set.


The Testing – Round 1

I was trying to test this while my phone was connected to the AppInventor environment mode but found out a limitation in this testing mode.  You can’t move from one screen to another using code when running on the phone in this mode.  The phone will just display the screen that is selected in the screen selector pull down.  I couldn’t test the most important features of my new app.

The Multi-Screen Testing Solution

Unfortunately, testing of multi-screen functionality can only be done if the app is fully installed on the testing device.  Luckily AppInventor has an easy method to allow users to quickly build and install the full Android app you are developing to your phone/tablet.  Under the build menu, select “App (provide QR code for .apk)”.  It will build the code and bring up a QR code that you can scan using the camera while in the AI2 Companion app on the device you are using for test.


Once done building, a QR code will pop up like this….


As the note says, the code is only valid for 2 hours so don’t expect to be able to reuse it later.

The Testing – Round 2

Once I installed this test app on my phone, everything worked as expected.  When I clicked the “SecondScreenChooser” the other screen with 3 color buttons came up.  Once I clicked one of the colors, the first screen came back up and the “SecondScreenChooser” color changed to match what I clicked.


Creating Color Selector Using ListPicker Element in AppInventor2 – Not a good idea

The Plan

I was helping a friend with getting started with using AppInventor and he wanted to make a color selection function.  He came up with the idea of using a ListPicker but didn’t know how to use the ListPicker so I thought I would help him out and post a quick demo on how to do it.  It seemed like a good idea but after trying to implement this, there is a major drawback.

The Attempt

This is just a simple example so I am going to keep this simple.  All I am going to include is a sample ListPicker element.  Once the user selects a color, the ListPicker button will change to the color the user selected.


This first step in the code Blocks is to set the ListPicker elements to a list of colors.  This can be done during the screen initialization.  In the Blocks screen..

  1. click on Screen1 and drag out the “when Screen1.Initialize” block.
  2. click on the ListPicker1 and drag out the “set ListPicker1.Elements to” block out
  3. click on the “Lists” (blue box) and drag out a “make a list” block
  4. click on the “Colors” (gray box) and add the colors you would like to be included in the List block.
  5. You can add more color items to the list block by clicking on the darker blue box in the upper left of the list block

Here is a snapshot with some notes…


Now to add the functionality to change the color of the ListPicker button, click on the ListPicker and add the blocks in this diagram…


This will change the ListPicker button color to what was selected after a user selects a color….

The Problem

The problem with this approach is that the colors come up as a color code number instead of a list of colors to select.  Here is a screen shot of my phone running the above project….


As you can see, this is not really useful to a human.  I tried digging around to see if there was a simple solution but couldn’t find one.  Unfortunately what seemed to be a good simple solution turned out to be a dead end.  I will attempt to create a better but unfortunately more complicated solution in my next post.

Arduino + ESP8266 remote control LED using an Android App with Camera Live View

The Plan

In several of my previous post, I showed…

  1. …my setup to control LED’s using an Arduino + ESP8266. (LED’s Control Through ESP8266 + Arduino Web Page)
  2. …using the AppInventor environment to send a Web.PutText to send a message to the Arduino. (AppInventor2 Web Interface Trial)
  3. …embedding a live stream of a Foscam Wireless Camera into an AppInventor application. (Real time Wireless Camera view using AppInventor2)

My plan is to now mash up all three into one project.  I will make an app that will send Web.PutText to the Arduino through the ESP8266 to trigger LED light changes and have an embedded live Foscam Wireless window all on the screen on an Android App built in the AppInventor environment.

The Android App (built in AppInventor2)

The screen layout is made up of

  • 6 buttons to turn on/off 3 LED’s.  The buttons are just sending custom WebPutText keywords.
  • A WebViewer element which loads will load web page defined in text box element when the Go button is clicked.
  • Another text box to specify the web address of the Arduino + ESP8266 system.

Here is what is looks like….


The AppInventor code to point the Web component to the ESP8266/Arduino server will set the Web1 URL to point to the web address that is entered in the corresponding text box.  I was running out of screen space and didn’t want to have to add another button so I just have the code run after the address is typed into the box and something else on the screen is touched.  It looks like this…


The code to start up the live camera view is really just creating a Webviewer window which will display the web site specified in the corresponding text box whenever the Go button is clicked.  The rest is really up to the Foscam camera to serve up the live stream….


The LED controls are just sending some custom strings using the Web.PutText function.  I am using “PtcApp” as a keyword that is not likely to be seen by the server that I can key off of.  I follow up “PtcApp” keyword with a code for the {first letter of the LED color}:{1 for on / 0 for off}.  The magic will happen on the upcoming Arduino code.  Here is the AppInventor code….


The Arduino Code

I am only going to cover the additional Arduino code I add to implement the AppInventor functionality here.  The rest of the program has been detailed in many of my previous post.

The first step is really simple.  I just added another parser block to look for “PtcApp” in the incoming line from the ESP8266.  I left all the previous parsing blocks and function so that all the previous features will still continue working (ie: the web page interface is still fully functional).   Once the “PtcApp” is found, I call a function to parse out which color LED to control and if it is a request for On or OFF.  Here is the code snips….

 if (InLine.indexOf("PtcApp ") != -1) {
    CommandQue[QueIn++]=PUT_REQUEST;    //** See next section in post for what this is for **
//*** This parses out the LED control strings from custom Android App and sets the appropriate state vars *** 
void ParseCustomAppRequest(String InLine){
 if (InLine.indexOf("R:0")!=-1) RED_State=false;
 if (InLine.indexOf("G:0")!=-1) GREEN_State=false;
 if (InLine.indexOf("B:0")!=-1) BLUE_State=false;

 if (InLine.indexOf("R:1")!=-1) RED_State=true;
 if (InLine.indexOf("G:1")!=-1) GREEN_State=true;
 if (InLine.indexOf("B:1")!=-1) BLUE_State=true;

The First Test

This all actually started working very well initially.  Everything worked pretty much on the first attempt, but after 5 LED change requests from the Android App, the ESP8266+Arduino stopped seeing any more requests.

Debugging the logs, I found that each PUT request was holding an additional IPD channel open.  (In case you haven’t been following my previous posts, an IPD channel is the ESP8266 way of handling multiple TCP clients.  Each channel corresponds to a client so the server can send messages to a specific client).  The ESP8266 seems to have a limit to only be able to hold open 5 open IPD channels and then stop accepting any more connections.

I remembered another similar situation where the client wasn’t closing the connection.  It was because I wasn’t sending an HTTP header back for a GET request (see the “Extra Fix” section in my post “Arduino + ESP8266 Mini Server with Command Que“).  Hoping it was the same problem I made a very simple HTTP header with 0 length response and send it back each time I get a PUT request…

String PutResponse ="HTTP/1.0 200 OK \r\n"
 "Date: Fri, 31 Dec 1999 23:59:59 GMT\r\n"
 "Content-type: text/html\r\n"
 "Content-length: 0\r\n"
 "Connection: Closed\r\n"


    SendCIPChunk(PutResponse,CommandQueIPD_CH[QueOut]); // Send the CIPSEND command to respond to Put request 

Once I sent back the proper HTTP header, the client automatically closed the connection and all the requests from the AppInventor Web.PutText button clicks were coming in on IPD channel 0 consistently.  I was able to get the LED to change +100 times through a day of testing so I think it is pretty stable now.  🙂

BTW – I will include a link at the end of this post for the full Arduino code to get the complete picture.

The Demo

Here is a short video demoing the setup…

The Arduino Code

If you want the code…

Real time Wireless Camera view using AppInventor2

The Plan

I was showing people how I can remotely control some LED’s connected to an Arduino and an ESP8266 through the internet while at the park today.  I had 2 phones running.  One phone had a live feed coming from a Dlink Wireless camera and the other phone was controlling the LED’s through the web page that I demoed in my previous post “LED’s Control Through ESP8266 + Arduino Web Page“.  Note: There have been other additions to enhance the setup in some of my later post that built on top of that so look for those if you are interested.

This 2 phone demo was pretty cool but it was a little clunky having 2 phones for a demo.  I was thinking a more elegant demo would be to have the LED controls and live feed all contained in one Android app.

I have also been messing around with MIT’s AppInventor environment in some of my recent posts.  I found that I can send custom strings to the Arduino through the internet using the Web.PutText feature (see post “AppInventor2 Web Interface Trial“) so controlling the LED’s can be taken care of by using that.

I did some more looking around in AppInventor2 and found the WebViewer component today.  I am going to see if I can make a portion of the app screen show a web page that is pointed to my Dlink Wireless camera.  This post will show the trials I did to get familiar with the AppInventor2 WebViewer component.

The AppInventor Setup

The screen layout is added on top of the Web Interface Trial for now.  I left the 2 buttons to send a PutText and PostText.  I added a text box to type in the URL and a load button.  The rest of the screen is just a WebViewer component….


The code is also simple.  When someone clicks the load button, set the WebViewer’s URL property to what is in the text box….


The Testing

First I tried just entering into the text box and couldn’t get the web page to load.  I then decided to try putting the full address of “” and that worked.  Then I tried and could view this blog site with no problem.

I then tried to enter the ip address of my Dlink Wireless camera.  Unfortunately all that comes up is “Error: Authorization Required…. Authentication was requested”.  When I go to the same page using a standard web browser on the PC, it pops up login dialog.  The camera could be using Java scripts.  The AppInventor WebViewer probably just doesn’t support it.

Luckily I have different type of wireless camera to try.  I recently bought a refurbished Foscam FI8910W Wireless Camera from Amazon:  I tried that one and it worked perfectly.  That camera has a much simpler web interface and even features a “mobile phone” interface.  I logged into the camera in the WebViewer window and could see a live feed.

The Next

Now I have tested the individual pieces to be able to make an AppInventor App that can send custom strings to my Arduino + ESP8266 + LED setup and display a live video feed in the same app to watch as the lights change.  Will hope to put it all together in my next post and show a quick video demo of it all working.

AppInventor2 Web Interface Trial

The Plan

So far I have been able to demo using a simple TTY or a more complex HTML web page with an embedded form to control 3 LEDs connected to an Arduino through an ESP8266 wifi module.  I was looking for a way to control things directly from an Android App to make it look cooler and to allow for a more flexible messaging system.  In my last post, I also showed how I started messing around with MIT’s App Inventor 2 environment (Android Programming with AppInventor2).  I tried finding some sort of raw TCP IP connection or UDP packet sender in the App Inventor 2 tools, but couldn’t find anything.  The closest I could find was the Web.PutText and Web.PostText.  This blog post is to show the details of what I found trying to get familiar with this AppInventor feature.

The AppInventor Implementation

The AppInventor screen layout is very simple.  All I want to do at this point is to send either Web.PutText or Web.PostText so I just made 2 buttons on the screen that I can attach some code to.  I also added a Web component with the URL set to the IP address of my ESP8266 (see my previous post “Adding LCD to Web Page Controlled LED” for details on the ESP8266).  Here is a snapshot of the screen layout in AppInventor…


The “code” is also dead simple.

  • When Button1 is clicked, send a Web.PutText with a payload of “Hello put”
  • When Button2 is clicked, send a Web.PostText with a payload of “Hello post”

Here is what the “code” looks like…


The Results

I fired up my Arduino + ESP8266 system and launched my AppInventor application on my Android tablet.

When I click the button to test the Web.PutText feature, this is what the Arduino saw coming from the ESP8266…

  • +IPD,0,237:PUT / HTTP/1.1
    User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.2.1; M470BSA Build/JOP40D)
    Connection: Keep-Alive
    Accept-Encoding: gzip
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 9
    Hello put

When I clicked the button to test the Web.PostText feature, this is what the Arduino saw coming from the ESP8266…

  • +IPD,1,240:POST / HTTP/1.1
    User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.2.1; M470BSA Buil
    Connection: Keep-Alive
    Accept-Encoding: gzip
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 10
    Hello post

Both of these will send a full HTTP header before the text that I want to send.  So it isn’t exactly what I wanted like a TTY app which can send just the raw characters, but it still drastically cuts down on the data traffic vs. my previous implementation using a full HTML page with embedded form.  Using the HTML form required me to send a full HTML page just so a user could send back a POST command and then required me to send back another full HTTP header and HTML page.  Now I can build a fully customized Android app that can send a PUT or POST command without needing my server to send it something first.  Also don’t need to send back a full HTTP header and HTML to satisfy the browser.  Should make my system a little more robust when a user has the custom Android app.

The Next

Now that I have a better grasp of what raw data will be going through the ESP8266 when AppInventor calls the Web.PutText function, I will enhance my previous Arduino code to be able to control LED’s from messages coming from a custom Android app utilizing the Web.PutText component.

BTW – I contemplated if I should use the Web.PutText or Web.PostText component and decided to go with the Web.PutText for now.  The Web.PostText sends the string “POST / HTTP” which is identical to the trigger I use for controlling LEDs and sending back a full HTTP header and HTML page with the current LED states when using a HTML form.  The Web.PutText will send a string with “PUT / HTTP” which I am currently NOT looking for.  This will allow me to add to my current system instead of replacing my current system.

Hopefully my next post will be to demo a custom Android App controlling LED through the ESP8266 and Arduino from anywhere in the world where I can access the internet.

Android Programming with AppInventor2

A little break from the Arduino and ESP8266.  Wanted to broaden my skills with some Android programming to be able to come back and interface phone/tablet with the Arduino.

The Plan

I wanted to be able to use my Android phone or tablet to communicate with my Arduino through the ESP8266 or a Bluetooth module that I bought recently.  I saw some other examples on Youtube where they used MIT’s AppInventor platform to make some Android apps that could communicate through a Bluetooth module.  I decided to try my hand at making a few apps at … and got very caught up in it.  The system is very easy to use and relatively powerful.  Very impressed with how easy they make it.  This post is focusing on the first app that I made.

The Android App

I followed the normal tutorials they have at the AppInventor web site.  They were painting type apps where you can draw pictures with your finger.  Was useful to get the feeling of the environment.  I pushed forward to make something I thought was a little more interesting.  I decided to incorporate the accelerometer with the drawing program.  It is kind of like a marble with wet paint on a pad of paper.  You can tilt the phone/tablet to move the marble around on the pad and leave a trail where the marble rolled.  Best to just show the video of the finished app….

The Research

To start, I needed to get familiar with AppInventor accelerometer interface.  I made a very simple app that would just print out what the x and y accelerometer returned whenever there was a change in the accelerometer readings.  Just 2 labels and 2 text boxes to fill in the accelerometer reading.  Here is a short video….

Here is what the screen layout looks like in AppInventor….


The “code” looks like this…


All this is saying is…

  • Whenever there is a change in the accelerometer…
    1. Change the text in text box1 to the value returned by the x-accelerometer.
    2. Change the text in text box2 to the value returned by the y-accelerometer.

That is it!!  That is the entire “code”!

From what I can tell, it looks like it is just reporting back in standard G’s.  If I have the phone vertical, the y-accelerometer shows around 9.8 ( m/sec^2 if I am not mistaken).  The same goes for the x-accelerometer.  I didn’t test the z since I am not trying to sense that for anything yet.

The Full Mable Pad App

Now that I figured out the accelerometer interface I moved on to making the marble pad app.  I already knew how to draw dots on the screen from the various on line tutorials.  Now just needed to mash the 2 together.

  1. First I create a button to reset the screen and a canvas that the dots will be painted on.  That is all that the screen setup needs to be…
    • MarblePadScreenLayoutSnap
  2. The code initialize an x and y variable to hold the current position of the marble.
    • See next section for picture.
  3. When the screen initializes, set the current x and y variables to the halfway point, ie: middle of the canvas.  Draw a purple dot at the current x,y coordinate (which we just set to middle of the canvas).
    • MarblePadInitCode
  4. Whenever the accelerometer value changes,
    1. increment the current y by the value returned by y accelerometer
    2. subtract the value returned by the x-accelerometer from the current x value.  We need to subtract the x accelerometer value because tilting it right causes a negative number
    3. Round the value of the accelerometer value since the x,y coordinates are pixels so need to be whole numbers.
    4. Check if the current x or y value is either below 10.  If either are less then 10, set it back to 10.  This is to keep a top and left border around where the marble can go.
    5. Check if the current x or y value is within 10 of the total width or total length of the canvas area.  If it is, set it back to 10 less than the max.  This is to keep a right and bottom border around where the marble can go.
    6. Once the new x,y coordinate is found, draw the new dot.


There is also some code for the reset screen which is the same as the screen init but adds a clear canvas at the start to wipe all the lines on the screen.


That is pretty much it!  Not very hard at all.  If you have ever thought, “only if someone would write an app that could…”, I encourage you to give it a try.  You can be that someone that will write that app.

The Actual Code

If you want to play around with the Marble Pad app, you can download the .apk here:

If you have your own AppInventor2 account and want to import the full code, you can get the .aia file here:

Have fun!