Category Archives: Components

Sensors: How to use the Orientation Sensor

Smart phones and tablets contain several kinds of “sensors” to sense information about their environment. For example, an accelerometer provides information about movement of the phone (or tablet) – letting us know the speed and direction of travel in x, y and z coordinates (three dimensions).

The orientation sensor tells us if the phone is tilted to the left or right, or up or down (or flipped over). App Inventor provides a simple to use interface to the orientation sensor. We can use this to control a sprite or ball on the screen – by tilting our phone, we can make graphic items move around on the screen!

Sample source code that you can download is at the bottom of this post!

After going through this tutorial, you now know enough to create your own interactive smart phone game!

Review

Before we get started, please review these earlier tutorials:

Continue reading Sensors: How to use the Orientation Sensor

Controlling the sprite animation with your finger on the screen

In the prior tutorial, we created a sprite-based bouncing animation – which is surprisingly easy to do in App Inventor.

But how might we make the animation interactive? Such as touching the bouncing object with a finger and flinging it (throwing it) off in another direction? In other words, as the object travels around the screen, we would like to touch it with our finger and then “drag” the object off in a new direction.

To implement this, just handle the Image Sprite’s “Flung” event, like this:

ImageSprite-Flung

 

App Inventor (and the Android OS) handle the details of sensing our finger on the screen and translating that into some values we can use in our app.

When the “Flung” event occurs, App Inventor passes along several values – including the (x,y) coordinate values at the time we touch the object, the speed and heading in which we’ve dragged the object with our finger, and the x and y velocity.  When this event is detected, our program sets the sprite’s current heading and speed to the values determined by our finger drag across the screen.

Click on the “speed” and “heading” parameters in the Flung event to find the “get heading” and “get speed” values.

I multiplied the speed parameter by 3 as the values returned by Flung were small and resulted in slow movement of the sprite. You can set this value to a smaller or larger value based on your preference.

Here’s the app screen, when in use:

Screenshot_2014-10-20-15-53-14

 

As the sprite moves across the screen, touch it with your finger and “fling” it off in a new direction. (You may have to experiment for a bit in terms of how you do your “flings”).

Stopping the Sprite When Touched

If the sprite is moving quickly, it moves out from under your finger before you can take action. To fix this, we sense the finger touching the sprite and stop the sprite while it is being touched.

We implement the “TouchDown” event for ImageSprite1. The moment our finger touches the sprite, the sprite is stopped by setting its Speed property to zero. Now we can casually “fling” the sprite in a new direction.  When we stop touching the sprite, the “TouchUp” event occurs – here we restore the original speed so that the sprite resumes moving. Of course, the “Flung” event occurs next and sets a new speed for the sprite based on our finger movement.

Update: Delete – do not use – the .Touchup block, shown below. It is not needed. Instead, when you lift your finger up as part of a “flung” operation, the flung event handler will set the sprite’s speed proportional to your finger movement. Thus, it is not necessary to restore the saved speed value.

ImageSprite-Touch

Using ImageSprites for animated App Inventor graphics

I described the basics of creating a bouncing ball animation earlier and mentioned that “image sprites” are similar to the bouncing ball graphic, but provide a way to specify your own image for the ball. To introduce a bit about images in App Inventor, we took a quick look at using the phone’s camera.

This tutorial starts with the original bouncing ball program and then modifies it to use an Image Sprite instead of a ball. Be sure to read the bouncing ball and camera tutorials first!

Previous:

The ImageSprite component is almost identical to the ball component!

Continue reading Using ImageSprites for animated App Inventor graphics

Using Lists in App Inventor

A frequent search topic on this blog is how to use lists. “Lists” are a way of storing a collection of data in App Inventor programs. Many other programming languages provide a number of methods for storing collections of data including arrays, records, even lists, and even something called “collections” (imagine that!)

App Inventor provides Lists, plus you can also use components like the TinyDB.

For a detailed description of using Lists, please refer to Chapter 8 – Introduction to Lists in my e-book “App Inventor 2: Tutorial”, available for $2.99 from Amazon. I hope to make this text available in additional e-reader formats during November.

Using Images and the Camera in App Inventor

In an earlier post, I mentioned that ImageSprites use images – and suggested I do a tutorial on images so here is a first look at using images in App Inventor 2.

For this tutorial, we create a very simple app that uses the camera to take a picture, or we can fetch a selected photo from the phone’s photo gallery. Either way, the image that is obtained is displayed on the screen.

First, create a simple user interface. To set this up, I used the VerticalArrangement layout and then added a button, an ImagePicker and an Image on to the Viewer:

Image1-UserInterface

The Image component is located in the User Interface section of the Palette, in the Designer.

The ImagePicker is located in the Media section of the Palette. Drag each to the Viewer window.

You also need to drag a Camera component to the Viewer; the Camera is also located in the Media section. Note that the Camera is an invisible component and will appear below your app’s user interface screen, as shown above.

After renaming the components, we should have a set of components like this:

Image1-Components

For the Image1 component, the Properties look like:

Image1-Properties1

Note that the text box field named Picture has the name of a .jpg image file entered into, in this example. Sorry for the ugly gibberish filename – I just grabbed a photo off of my own Flickr page, saved to my hard drive and then uploaded to App Inventor.

To upload a photo from your computer to the Image1 control, click on the Picture field – this displays a prompt:

Image1-Properties2

The prompt shows the full name of the image I have already uploaded, and this file is already highlighted. Or, click on Upload File … at bottom to select and upload your own .jpg image file.

This uploaded .jpg becomes the default image initially displayed in the program. If you want, you could leave this blank but having something to show on screen makes the program a bit more interesting and helps the user to see where photos will be displayed.

The Blocks

Taking a photo is absurdly easy. When the button for taking a photo (btnTakePhoto) is clicked on (or rather, pressed with your finger), the Click event is raised – and all this event handled need do is call the camera’s TakePicture method:

Image1-TakingPhoto

Once the camera completes taking the picture, the AfterPicture event occurs. This is where we fetch the image (hover your mouse over the pink “image” within the AfterPicture block and select “get image”). Assign the image that was just taken (the get image) to the Picture property of the Image1 control. This copies the photo that was just taken, and displays it on screen.

We could stop here, but let’s take a look at grabbing a picture from the photo gallery on the phone. To implement this, we use ImagePicker. The ImagePicker is a control that displays the photo gallery, let’s you select an image from the photo gallery, and then returns that selected image to the app.

The ImagePicker displayed in the Designer is effectively a button that contains its own event handler for the Click event. Pressing the ImagePicker button on the main screen automatically enters the gallery where you select your photo. When the selection is complete, the ImagePicker’s AfterPicking event is raised and we add a tiny bit of code to process the image, merely copying the “Selection” property of the ImagePicker control (renamed here as impgSelectPhoto) to the Image control on screen to display the selected photo.

Image1-ImagePickerAfter

Running the App

When activating the camera, take a photo and wait a moment – you should see a “checkmark” at the bottom of the screen after the photo is processed.  Tap the checkmark icon to signify you are done and you should be returned to the app and the photo you took should be displayed.

When selecting a photo from the gallery, wait for the gallery to appear, scroll through and select a photo. Tap the photo and wait for a moment – and control should return to the app and the selected photo will appear on the screen.

Note – if you have more than one photo gallery app registered on your phone (I have 3 such apps), Android will prompt you as to which of the gallery apps you wish to use.

There are additional features that are not shown here. For example, if your phone has a front facing and back facing camera, its possible to switch between the cameras.

SOURCE CODE

Source code is available in the MIT App Inventor Gallery –> here

MIT App Inventor Source Code

This is for advanced software developers only: MIT App Inventor Sources. That’s the actual source code that makes App Inventor work behind the scenes – from the browser based editor to the server side support to the AI Companion. It’s all there.

MIT has made the source code for App Inventor publicly available. At a minimum, you need to be proficient in Java, Javascript, and have familiarity with various web techniques, such as JSON. Exploring this source code is not for the neophyte.

With access to the source code it is possible to host App Inventor on your own server and it is possible to develop your own App Inventor components (this also requires making a custom version of AI Companion).

Again, this is for advanced software developers.