Connecting with Bluetooth

Bluetooth is a short-range wireless communication protocol supported by most mobile devices, and available for use in App Inventor. Two new apps have been added to the UniTY section of the App Library, one that demonstrates a Bluetooth connection and data transfer between two devices, and one that uses it in a two-player game:

• BluetoothDemo - establish a client-server connection between two devices and exchange data
• LizardSpock - an extension of Rock-Paper-Scissors, made famous in The Big Bang Theory

Note that Bluetooth must be enabled and the devices paired before running the apps. On most devices, Bluetooth configuration can be found at Settings - Wireless - Bluetooth.

Additional Resources

Three new apps have been added to the UniTY section of the App Library, including two that serve as reference implementations of interfaces with media and sensor features:

• HelloWorld - a minimal Hello World app, using the fewest elements possible
• MediaDemo - explore the media capabilities of your device (and see responsive design in action)
• SensorsDemo - explore the sensor capabilities of your device

Project Notes and Extra Challenges have been added to the Core 2: The Brainstormer project, to provide additional insight into the workings of the app, and suggestions for further development:

• http://unitydcu.ie/ss-c2n - Project Notes
• http://unitydcu.ie/ss-c2c - Extra Challenges

Links to additional sources of demonstration apps and reference material have been added to the Starter Apps document:

• link to Mini Golf app on the App Inventor website
• link to tutorial library on the App Inventor website
• link to online book and tutorials on appinventor.org

Fixed vs Responsive Sizing

App Inventor allows apps to be built with either Fixed or Responsive sizing, controlled by the Sizing parameter of Screen1. This parameter is available only in the Designer, and cannot be changed dynamically.

Fixed Sizing
Apps are built with a fixed width of 320 pixels in portrait mode, or a fixed height of 320 pixels in landscape mode. The longer dimension varies depending on the device; designing for 320x480 pixels works in most cases. The majority of apps in App Inventor tutorials and in the DCU Access courses use Fixed Sizing for consistency.

Responsive Sizing
Apps are built to use the full screen size of the device, which varies considerably across devices. This means that scaling of design elements becomes a factor, especially when apps may be used on both phones and tablets. Read more here. Responsive sizing appears to be necessary for well-behaved video playback.

Note that most Android devices use 'soft buttons' at the bottom of the screen, which reduces the available vertical screen size; this is not the case with the Emulator or ARC Welder. The table below shows the screen size available to App Inventor for a selection of devices using each Sizing option.

Fixed Sizing	Portrait	Landscape
Emulator	320 x 480	480 x 320
ARC Welder, Phone	320 x 569	569 x 320
ARC Welder, Tablet	320 x 512	512 x 320
Fire 7" tablet	320 x 520	546 x 294
Nexus 7 tablet	319 x 482	512 x 294
Responsive Sizing	Portrait	Landscape
Emulator	320 x 480	480 x 320
ARC Welder, Phone	360 x 640	640 x 360
ARC Welder, Tablet	800 x 1280	1280 x 800
Fire 7" tablet	600 x 976	1024 x 552
Nexus 7 tablet	600 x 905	961 x 552

Core 2: Brainstormer Updates

The videos for Core 2: The Brainstormer have been edited to remove 'first takes' as needed. There is no change to the instructional content, so there is no need to revisit videos that students have already viewed. The old versions of the videos are now marked private.

The downloadable AIA file WhoIsQuiz_example.aia has been updated to prevent the app from crashing after the last question is answered. It differs from the code built up in videos 4 and 5 when dealing with user-typed answers, and shown again in video 8 when dealing with the drop-down list, as follows:

• Incrementing the list index CurrentQuestion has been removed from the SubmitButton event handler in the first version of the quiz, and from the AnswerPicker event handler in the second version.
• In the NextButton event handler, the test for the end of the list has been changed to a test for equality, as the change above means the list index is not incremented before it is tested.
• An else clause has been added to the conditional block, in which the list index is incremented and the next image is displayed only if the game is not over.

Before: the index is incremented when the third question is answered correctly, and the NextButton handler then attempts to display the fourth image in a list of three, crashing the app before the check for the end of the game

After: when the Next button is clicked, we check if the game is over; if it's not, the index is incremented and the next image is displayed

It would have been possible to fix the crash without moving the CurrentQuestion increment into the NextButton handler, but the program flow is easier to follow with the solution above. It also means that the AnswerPicker handler (or the SubmitButton handler in the first version) deals only with whether or not the user gave the correct answer, and the NextButton handler deals only with determining how to move the game forward. This is an example of the programming principles of Single Responsibility and Separation of Concerns.

Student Resource Centre

Building on the shortcut URLs for course material, a new Student Resource Centre page has been created, with links to key course material from Google Drive and YouTube:

http://unitydcu.ie/smart-skills-student-resource-centre/

There's nothing on this page that's not already publicly accessible and linked from the lesson plans; the idea is to provide a convenient starting point for students to find the material without them needing access to the lesson plans. It's intended for reference and revision, not as a substitute for students working through the lesson plans under a teacher's guidance. The page can also be reached via the shortcut http://unitydcu.ie/ss-src.

App Library

A library of apps is being assembled on Google Drive at http://unitydcu.ie/ss-app, and will hold sample apps used in the Smart Skills course as well as other apps of interest. For each app, there are four files in the library:

• appname.aia - project source code to import into App Inventor
• appname.apk - compiled app to load into ARC Welder or install on a device
• appname.png - screenshot of code blocks
• appname_QR.png - QR code to download apk file directly onto a tablet or phone

At the time of writing, the first two Smart Skills apps (WhackAMole and WhoIsQuiz) are available, along with apps from the APPlied App Development course for First Years.

App Inventor Coordinate System

For handling moving objects ("sprites"), App Inventor uses an X/Y coordinate system for position on the screen, Heading for direction of movement, and Speed and Interval for velocity.

X and Y measure horizontal and vertical distance from the top left of the screen in units of pixels. By default, the Screen1 Sizing parameter is set to Fixed, which generates apps with a horizontal dimension of 320 pixels in portrait orientation. The vertical dimension varies with the device; designing for 320x480 pixels should work on most devices. Changing the Sizing parameter to Responsive results in apps that use the full screen resolution, which varies considerably from one device to another. The apps in this course use Fixed sizing for predictable behaviour.

The Z value of a sprite determines the stacking order when sprites overlap, with higher numbered sprites rendered in front of lower numbered sprites.

Heading is expressed as an angle between 0 and 359 degrees, with 0 representing movement to the right, and proceeding anti-clockwise from there.

Interval determines the time in milliseconds between updates to a sprite's position, while Speed determines how many pixels the sprite moves per update. Setting the Speed to 5 and the Interval to 10 (i.e. 5 pixels every 10 ms) is a reasonable starting point for a rolling ball with smooth animation.

There are built-in procedures to detect when a sprite reaches the edge of the screen, with the value of Edge set to 1, 3, -1, -3 for top, right, bottom, left respectively. Edge values are also used for the corners, where 2, 4, -2, -4 represent top right, bottom right, bottom left, top left respectively.

This document contains a reference diagram showing the X/Y, Heading and Edge schemes, and would be useful to have to hand when working on arcade style games: App Inventor Coordinate System