Android Programming with App Inventor
Drag and drop your way to Android programming.
MIT App Inventor, re-released as a beta service (as of March 5, 2012) by the MIT Center for Mobile Learning after taking over the project from Google, is a visual programming language for developing applications for the Android mobile computing platform. It is based on the concept of blocks, and applications are designed by fitting together blocks of code snippets. This may sound like a very childish way of programming, especially for seasoned readers of Linux Journal. But then again, App Inventor will tickle the child programmer in you and make you chuckle at the ease with which you can develop applications for your Android device. In this article, I describe how to use the camera on the Android device, develop e-mail and text-messaging-based applications and also show how to use location sensors to retrieve your current geographical location. Let's get started.
App Inventor has minimum setup requirements and is completely browser-based. You need a working Java installation on your system, as it uses Java Web Start for its functioning. Point your browser to http://appinventor.mit.edu, and once you sign in with your Google account, you should see a screen as shown in Figure 1. This is called the Projects Page where you can see your existing projects and create new ones.
Figure 1. App Inventor's Projects Page
Now, let's develop and deploy an Android application using App Inventor and in the process learn the basic development-deployment cycle. Create a New Project using the New Project button, and enter a name for your project, say "Project1". Now you should see the Designer window for your project. The Designer window is composed of four sub-components. The Palette on the leftmost side of the window is the placeholder for all the available components for your project. The Viewer is where the application will be designed by placing together various components (this is where you design the user interface for your application). The Components show the currently used components in your project, and the Properties column is where you assign the properties of the components.
First, let me briefly explain the notion of components. An App Inventor project is made up of building blocks called components, such as a text label to display text, a text box to take user inputs, a camera component to click pictures and so on. Currently, you will see a few categories of components—basic components, such as those for user input and display of text to more specialized components, such as those for displaying media and animations, and components acting as an interface to the device sensors. A complete reference for all the components is available at http://appinventor.mit.edu/learn/reference/index.html. Components have associated behavior, methods and properties. Some of the properties can be set; whereas others can be only read.
In this first project, let's use the following components: Camera, Button and Image. The code usually shows it better, but briefly here is what you're going to do: clicking the button starts the camera on your device, which you use to click a picture, which then is displayed using the Image component. Here are the steps:
Drag a Camera component from the palette to the Viewer. It should show up under Non-visible components below the Viewer. By default, it will be named as Camera1, which you can, of course, change to something else.
Drag a Button to the Viewer, and from the Properties, change its Text to "Click".
Drag an Image component onto the Viewer.
You can play around with the Screen properties to set things like title, background color and orientation. For the purpose of this project, set the Title to "Click!".
Figure 2. User Interface for Project1
That completes the design of the user interface (Figure 2). Next, let's program the components using Blocks.
Open the Blocks Editor, which should start downloading the JAR file for the editor. It will ask you for the location of the App Inventor setup commands if you have not installed them in the standard location under /usr/google. The Blocks Editor for the current project will look like Figure 3. Going back to the description for this project, the goal is to activate the device camera when the button is clicked. This is done with the code block "When Button1.click", which you dragged from the Blocks pane on the left. When the button is clicked, you want the device's camera to be activated, so drag the "call Camera1.TakePicture" block inside the previous block. Once the picture is taken, you will want it to be displayed using the Image component. So, insert the block "when Camera1.AfterPicture" into the editor, and then set the "Image1.Picture" to the location of the saved image.
Figure 3. Blocks Editor for Project1
Now that you have designed the user interface and programmed the application's logic, you're ready to test it. Go back to the Designer window, and on the right, click on Package for Phone→Download to this Computer. That should initiate the download of the Android package (.apk file) for your project. Now, transfer this file to your Android device, and install it. Then, try it out.
A Peek under the Hood
Now you have designed and deployed your first Android application, and you have used components (the camera component and the image components), assigned them behavior and set properties. If you are familiar with the idea of event-driven programming, you already will have realized that App Inventor is an event-driven programming framework. The event can be the user clicking a button or the reception of a text message. For example, when the button is clicked, an event is said to have occurred, and in response to this event, the camera is activated. Again, when the camera finishes capturing a picture and saving it, the response code uses the image location to display it using an image component.
Earlier, I mentioned that components have associated behavior, methods and properties. You can find these for a component by clicking the component in the Blocks Editor. For example, Figure 4 shows the method available for the Camera component (Camera1.TakePicture) and the behavior (Camera1.AfterPicture).
Figure 4. Blocks Available for the Camera Component
Besides the blocks associated with components, more fundamental programming blocks are available: Math blocks, Logic blocks, Control blocks and others. (I'll demonstrate using a few of these in one of the projects later in this article.)
Now that you have a basic idea of developing applications using App Inventor, let's look under the hood a bit, starting from the source. Download the source code for "Project1" by going to the Projects Page and selecting Project1 and clicking on More Actions→Download Source. That should start downloading the sources in a zip file. When you unzip the file, you will have two directories: src and youngandroidproject. Under the src directory, you will have a subdirectory called appinventor, which houses the subdirectories, and then ai_droidery/Project1 (note that "droidery" is my Google user name). In this directory, you will see the source files Screen1.blk, Screen1.scm and Screen1.yail. Screen1.blk is an XML-based representation of the visual blocks that was created earlier; Screen1.yail is an intermediate language based on the Scheme language used by App Inventor, which is then fed to Kawa to create the Android package for installation on Android devices. The Screen1.scm file is a JSON representation of the components used in the project with details about the components, such as the version information. If you are keen to understand how App Inventor really works, you also may want to check out App Inventor's source code (see Resources).
Next, let's move on to becoming familiar with sensors and some of the other components available in App Inventor.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide