Project 7: AMaze: an Android App to explore a Maze 

To Deliver: release 11.0

To Download: 

Due date for submission:    Nov 25, at 5 AM

Drop out date:                     Dec 2, at 5 AM.

Motivation

We want to complete our maze application on Android by integrating the automated maze exploration algorithms, i.e. the various implementations of the RobotDriver.java interfaces. 

The key difference to Project 6 is that the automated maze exploration does not produce a sequence of (user input, screen update, user input, screen update, …) but a sequence of screen updates as an effect of a single user input. So, basically, our robot driver produces a sequence of images much like an animation, a movie. 

This will force us to use a slightly different approach than the one we used in Project 6.

What to learn from this project:

- Experience in difference between the general Java environment and the specific Android Java environment. 

- Working with threads (the maze generation operates in a separate thread to keep the UI responsive)

- Working with simple graphics in Android

- How Android handles graphics and screen updates in its UI thread with a message queue

Notes

When porting Falstad's code to Android, several issues come up:

• State  Play:  
• To handle the Maze graphics, there are different options, among others one can draw on a Canvas using a View as described here. 
• What does not work I: feeding a sequence of screen update requests (method: invalidate) to the UI thread is noticed by the UI thread. It optimizes its own performance by skipping intermediate updates and simply going to the last screen. The visual effect is that the maze exploration starts and basically reaches the exit immediately. 
• What does not work II: as a fix to the UI thread optimization, one may think that slowing doing the UI thread with sleep commands may yield the desired effect. This is a very bad idea because Android expects the UI thread to be responsive. Android may decide to bring up a user dialog and offer to kill the app as it does not seem to respond (assuming it hangs and thus better be killed). 
• What works: For the automated exploration with the RobotDriver, it is advisable to consider using a Handler for the UI thread and feeding runnable tasks for robot steps into the handler such that the UI thread faithfully performs all requested updates (check method postdelayed). Perform an internet search for "Android postdelayed UI update", see e.g. the section "Handling Expensive Operations in the UI Thread" in  http://developer.android.com/guide/faq/commontasks.html

As a general advice: do not attempt a big bang integration, identify individual steps, e.g. the integration of the maze generation and make this one work before integrating the graphics part etc.

To do list:

• Refine the AMaze app from Project 6 into a full blown, working maze application that runs on Android with similar functionality as the maze application worked as a Java application on a PC before. 
• Update the repository and deliver a release 11.0 to submit your results to the grader. 
• Dec 2-Dec 7: Prepare for a 5-10 min in class presentation of your App with key characteristics of the implementation (focus on aspects that are not necessarily known to all other students in class).
• Grading: You will receive points
• for a subversion release 11.0 that includes source code that can be checked out by the grader. 
• if your Android app can be executed and the First Person and Map visualization works for a manual exploration at least for a small skill level. 
• if your Android app can be executed and the First Person and Map visualization works such that an automated exploration for the WallFollower (including a First Person and Map visualization)  finds the exit at least for a small skill level. 
• if your Android app can be executed and the First Person and Map visualization works such that an automated exploration for the Wizard finds the exit at least for a medium skill level.
• if your Android app can be executed  and the First Person and Map visualization works for any further automated exploration (Gambler, CuriousGambler). 
• for reasonable amount of feedback produced at runtime with Log.v / Log.e etc commands such that one can see that the app internally works.