Ceci est une ancienne révision du document !
This time, we’ll finish up using SL4A. We’ll make a larger program and then send it to the virtual machine via ADB.
Let’s deal with our code first. In this, we’ll simply be trying out some of the “widgets” that are available to us when using SL4A. Start on your desktop using your favorite editor.
Enter the code shown top right and save it (but don’t try to run it) as “atest.py”.
The first line imports the android library. We create an instance of it in the second line. Line 3 creates and displays a dialog box with the title “Hello”, the prompt of “What’s your name?”, a text box for the user to enter their name, and two buttons, “OK” and “Cancel”. Once the user presses “OK”, the response is returned in the variable uname. The last line (so far) then says “Hello {username} from python on Android!”. This isn’t new, we did this before. Now we’ll add more code (above).
Save your code as atest1.py. We’ll be sending this to our virtual machine after we discuss what it does.
Take a look at the first four lines we just entered. We create an alert type dialog asking “Would you like to play a game?”. In the case of an alert type dialog, there’s no text box to enter anything. The next two lines say to create two buttons, one with the text “Yes”, which is a “positive” button, and one with the text “No”, a “negative” button. The positive and negative buttons refer to the response returned - either “positive” or “negative”. The next line then shows the dialog. The next seven lines wait for a response from the user.
We create a simple loop (while True:) then wait for a response for up to 10 seconds by using the droid.eventWait(value) call. The response (either “positive” or “negative”) will be returned in - you guessed it - the response variable. If response has the name of “dialog”, then we will break out of the loop and return the response. If nothing happens before the timeout occurs, we simply break out of the loop. The actual information returned in the response variable is something like this (assuming the “positive” or “Yes” button is pressed)…
{u’data’: {u’which’: u’positive’}, u’name’: u’dialog’, u’time’: 1339021661398000.0}
You can see that the value is passed in the ‘data’ dictionary, the dialog key is in the ‘name’ dictionary, and there is a ‘time’ value that we don’t care about here.
Finally we dismiss the dialog box.
Before we can send our code to the virtual machine, we have to start the virtual machine. Start your Android emulator. Once it starts up, notice that the title bar has four digits at the start of the title. This is the port that the machine is listening on. In my case (and probably yours) it’s 5554.
Now, let’s push it to our virtual machine. Open a terminal window and change to the folder you saved the code in. Assuming you have set your path to include the SDK, type
adb devices
This asks adb to show any devices that are connected. This can include not only the Android emulator but also any smartphones, tablets, or other Android devices. You should see something like this…
List of devices attached emulator-5554 device
Now that we are sure that our device is attached, we want to push the application to the device. The syntax is…
adb push source_filename destination_path_and_filename
So, in my case it would be…
adb push atest1.py /sdcard/sl4a/scripts/atest1.py
If everything works correctly, you’ll get a rather disappointing message similar to this…
11 KB/s (570 bytes in 0.046s)
Now, on the Android emulator, start SL4A. You should see all of the python scripts, and, in there you should see atest1.py. Tap (click) on ‘atest1.py’, and you’ll see a popup dialog with 6 icons. From left to right, they are “Run in a dialog window”, “Run outside of a window”, “Edit”, “Save”, “Delete”, and “Open in an external editor”. Right now, tap (click) on the far left icon “Run in a dialog window” so you can see what happens.
You’ll see the first dialog asking for your name. Enter something in the box and tap (click) the ‘Ok’ button. You’ll see the hello message. Next, you’ll see the alert dialog. Tap (click) on either button to dismiss the dialog. We aren’t looking at the responses yet so it doesn’t matter which one you choose. Now we’ll add some more code (top right).
I’m sure you can figure out that this set of code simply checks the response, and, if it’s ‘None’ due to a timeout, we simply print “Timed out.” And, if it’s actually something we want, then we assign the data to the variable rdialog. Now add the next bit of code (below)…
This part of the code will look at the data passed back by the button-press event. We check to see if the response has a “which” key, and, if so, it’s a legitimate button press for us. We then check to see if the result is a “positive” (‘Ok’ button) response. If so, we’ll create another alert dialog, but this time, we will add a list of items for the user to choose from. In this case, we offer the user to select from a list including Checkers, Chess, Hangman, and Thermal Nuclear War, and we assign the values 0 to 3 to each item. (Is this starting to seem familiar? Yes, it’s from a movie.) We then display the dialog and wait for a response. The part of the response we are interested in is in the form of a dictionary. Assuming the user tapped (clicked) on Chess, the resulting response comes back like this…
Result(id=12, result={u’item’:1}, error=None)
In this case, we are really interested in the result portion of the returned data. The selection is #1 and is held in the ‘item’ key. Here’s the next part of the code (above right)…
Here we check to see if the response has the key “item”, and, if so, assign it to the variable “sel”. Now we use an if/elif/else loop to check the values and deal with whichever is selected. We use the droid.makeToast function to display our response. Of course, you could add your own code here. Now for the last of the code (bottom right)…
As you can see, we simply respond to the other types of button-presses here.
Save, push, and run the program.
As you can see, SL4A gives you the ability to make “GUIfied” applications, but not full gui apps. This however, should not keep you from going forward and starting to write your own programs for Android. Don’t expect to put these up on the “market”. Most people really want full GUI type apps. We’ll look at that next time. For more information on using SL4A, simply do a web search and you’ll find lots of tutorials and more information.
By the way, you can push directly to your smartphone or tablet in the same way.
As usual, the code has been put up on pastebin at http://pastebin.com/REkFYcSU
See you next time.