Tag Archives: android

Tips

Blocks Editing Tip: Arranging and collapsing blocks in the editor

4 Comments

As you develop your App Inventor program using the Blocks editor, do you find your blocks overlapping and crashing in to one another on the screen? You know, like this:

AIBlockMess

You can drag the blocks on the screen so they no longer overlap, but dragging each block is tedious (time consuming). But there is an easy way to automatically re-arrange the blocks.

  • Move the mouse pointer to any part of the white space outside the blocks
  • On Windows, right-click the mouse button
  • On Mac OS X, press Ctrl and click the mouse button

Continue reading Blocks Editing Tip: Arranging and collapsing blocks in the editor →

Components

Part 1: Basic Bluetooth communications using App Inventor

89 Comments

(Some very minor updates were made to this in November 2019).

This tutorial covers basic App Inventor Bluetooth communications  code.   Subsequent tutorials will add additional features. To implement and test this sample code, you need access to two Android devices – one to act as a Bluetooth “server” and the other to act as a “Bluetooth” client.

I tested this code using an old LG smart phone running Android 2.2 and a new Nexus 5 running Android 5.0.1.  I also tested this code using the Nexus 5 paired with a Nexus 7 tablet. (Update I have since also run this on an Honor 8 phone and a Pixel 2, with much newer versions of Android.)

This tutorial is lengthy – it introduces Bluetooth communications, then presents the user interface and blocks code for both the server and client programs, and then discusses how to set up the Bluetooth Communications link using “pairing”.

Downloadable App Inventor source code for the client and server is at the end of this post.

This is the first of several  posts on Bluetooth. This first post covers basic connections and the sending and receiving of text between two Bluetooth devices. The two halves of the link – client and server – are kept in separate apps to keep this simple,  however, it is possible for a single app to act as both a client and a server. A subsequent post will show how to send other types of data, such as numbers, and introduce additional features for using Bluetooth communications.

Related:

Introduction to Bluetooth

Bluetooth is the communications technology with a funny name.[1] Bluetooth is actually named for a long ago Danish king who worked to unite groups of people, which is similar to Bluetooth’s goal of interconnecting different devices.  The King’s real name was “Harald” but he had a nickname that translates as “Bluetooth” – no one knows for sure why he had this nickname but one thought is he had one dark tooth that may have appeared black or blue. And that is certainly an obscure way to choose a name for new technologies!

Bluetooth establishes a very low power, short range (up to 10 meters) communications link between two devices. Bluetooth uses the same frequency band (2.4 Ghz) as Wi-Fi, but uses different technology. Both Bluetooth and Wi-Fi use forms of spread spectrum radio links that result in signals moving around within a wide band in ways that enable sharing of the spectrum by multiple devices. But the two technologies serve different purposes, are  not identical, and cannot communicate with one another.

Bluetooth applications include common wireless headsets for wired and cellular phones, and in-ear cordless adapters for phones. Bluetooth is also used by cordless headphones and to exchange address cards between devices, and for industrial applications where sensors collect and send data into a network.

There are two forms of Bluetooth – classic Bluetooth, which  we use in the sample applications, and a newer version known as Bluetooth low energy, Bluetooth BLE, Bluetooth LE or Bluetooth Smart – all referring to the same new technology.  The newest Android devices running Android 4.3 or newer, usually support the newest Bluetooth Smart technology. Regardless, we use classic Bluetooth which is backwards compatible to older phones, and is the technology supported by App Inventor.

Setting up a Bluetooth devices involves “pairing” the two devices and establishing a connection. This will be covered later in this tutorial.

Footnote:

[1] Actually there is another communications technology with a funny name called TWAIN, which is an acronym for “Technology without and interesting name” (really!)

The Designer View

Continue reading Part 1: Basic Bluetooth communications using App Inventor →

Components, Programming Method

Android App Inventor Tip Calculator version 4: Introduction to Procedures

5 Comments

What the App Does

This is the fourth version of 5 versions that implement a tip calculator. Each version has added improvements or new programming methods.

  • Version 1 introduced the basic app and the use of error checking to handle user data entry mistakes.
  • Version 2 introduced the Slider user interface component to select the tip amount. Using the Slider, the user selects a tip from 0% to 30%. Since there is no text entry, it is not possible for an incorrect tip value to be entered.
  • Version 3 introduced an improved user interface to eliminate user data entry errors.
  • Version 4 introduces “procedures” to clean up the code in preparation for version 5.
  • Version 5 revises Version 4 to make the calculation of the tip fully automatic plus fixes some minor oddities.

The Tip Calculator User Interface

No changes from version 3.

The Designer View

No changes from version 3.

The Blocks Code

Continue reading Android App Inventor Tip Calculator version 4: Introduction to Procedures →

Components, Programming Method

Sensors: Using the Accelerometer to detect motion

4 Comments

This tutorial introduces the accelerometer – at a high level – as a tool to detect the phone being shaken. You can use this feature as another kind of user input to your app – for example, make a game where shaking the phone resets the game play or starts a new game.

An accelerometer is a hardware device that detects and measures motion, typically in three axes: X, Y and Z. For example, if the phone is moved left or right, the acceleration changes in the X axis and the accelerometer returns a value indicating the X axis movement.

Smart phones – and many modern devices – have special hardware accelerometer components built in. The orientation sensor, described previously, is actually a software sensor that uses the hardware accelerometer but converts acceleration into orientation values.

The purpose of this demonstration app is to show one example of using the accelerometer.

The user interface is simple – it displays a Start button and a Stop button, and the status of the accelerometer.

AccelUI

 

Continue reading Sensors: Using the Accelerometer to detect motion →

Components, Tips

Using TinyDB in App Inventor

33 Comments

(This post was completely rewritten and updated on October 30, 2015)

What is TinyDB?

TinyDB is a simple “database” that stores data on your phone or tablet. Unlike program variables that go away when your app is finished running or your phone is re-set, values stored in TinyDB remain on your phone for use the next time your app is run.

About Memory on your Phone or Tablet

Your smart phone or tablet typically has two primary types of memory: RAM and FLASH memory.

RAM stands for “random access memory” – but today we mostly think of RAM as memory that can be accessed very fast (as compared to Flash or hard drive memory storage). RAM retains values as long as power is applied to the RAM circuity. Once we turn off the power, the values stored in RAM are lost. (In some applications, extra batteries are used to continuously provide power to RAM even when the “normal” power is turned off.)

Flash memory retains values when the power is turned off. But access to Flash RAM is not as fast as access to conventional RAM memory.

Why is it called “Flash”?  There was an early version of memory technology where the memory was erased by literally flashing it with ultraviolet light. However the inventor of Flash RAM chose the name “Flash” for different reasons. Modern Flash RAM is read, written and erased electronically.

App Inventor variables are stored in RAM memory – and the content of RAM is erased or reset whenever the power is turned off. TinyDB, on the other hand, stores values in FLASH RAM, where the values remain even when the power is turned off.

Using TinyDB

TinyDB provides a simple way to store and retrieve data efficiently and to store the data in long-term storage.  TinyDB is based on the concept of a “tag” to identify the stored data, and the data value. Think of a “tag” as like using your name as your identification to look up your address:

Tag value: Martin

Value: 123 Main St, Anytown, USA

or

Tag value: Alexa

Value: 321 Other St, Someplace, USA

TinyDB uses the “tag” (such as Alexa) to quickly locate the corresponding value. Even if you have 100 names and addresses stored in TinyDB, TinyDB can  look up the “tag” quickly and use the tag to find the corresponding value. We do not need to know how TinyDB does its look up so fast – it just does it [see Footnote 1].

In most database programs, the “tag” is known as a “key” or “key value”. App Inventor uses the name “tag” in place of “key”. As I am used to the name “key”, I tend to use “key” were I should have used “tag” in App Inventor! You will see this is the sample program, below!

To learn how to put TinyDB in operation, we construct a very simple app, described below.

Continue reading Using TinyDB in App Inventor →