Moseycode Release Notes 0.1.2

Moseycode is an experimental new barcode system for handheld devices. It provides an interactive bridge between the physical and digital worlds.

This release is primarily targeted at Android developers who are interested in adopting Moseycode for use in their own application.

This software is being released for evaluation purposes only. There is no warranty for the program, to the extent permitted by applicable law.

Release Date
January 29th 2008
Changes
Please see the changelog
Requirements
Android SDK m5-rc14 and a webcam for interactive use
Installation
Please read the installation instructions
Known Issues
  • Tilt control for the purpose of selecting contact details exhibits poor accuracy.
  • In landscape mode, it is not possible to move focus to the "Apply Settings" button without physically clicking on the button.
  • The application may briefly exhibit some confusion between a barcode that has just been scanned and a new barcode. This is because the data for some of the demonstration barcodes differ by only one or two bits. In normal operation, the probability of this occuring is extremely low.
  • There is a very occasional NullPointerException that results in an abrupt termination of the Moseycode application. This is probably a race condition that occurs on destruction of a drawing Surface.
  • Though downloads are properly managed, no firm limits are placed on disk usage or, more importantly, on download sizes and memory usage. As a result, OutOfMemory errors are possible that will kill the application.
  • Messages overlayed when the application is launched as a sub-activity of another application are rendered very inefficiently resulting in (even) lower framerates.
  • Barcodes that link to documents on the web do not display the URL that they will open; in general, there is no indication (at present) of the flavour of barcode being viewed.
  • Links in the About activity cannot be activated because TextViews do not seem to honour click events.
  • Menu items in the History activity do not become disabled when irrelevant. There does not appear to be a way of disabling menu items.
  • There is no confirmation when selecting "Clear History" from the History activity menu.
  • The last button selected on the launch screen is not remembered between visits to the activity. This is a consequence of the animations attached to the buttons.
  • No attempt is made to constrain the amount of storage used for preview images.
  • Barcode previews may be generated prematurely when the Scan activity invoked externally.
  • Barcode previews are not deleted along with the associated history record.
  • As described in the section on obtaining a camera feed, accessing a webcam via HTTP will irreversibly hang the Moseycode application if the connection fails.
    (developer group link)
  • The application may exhibit slow network access,and possibly failures, because it is not possible to resuse reuse HTTP client objects.
    (developer group link)
  • External links in the Help activity do not launch in a separate browser.
    (developer group link)
  • Orientation of the augmented feed may not match that of the device's camera.
    (developer group link)
  • The Help activity allows its pages to be scrolled 'too far' and exhibits a white background beyond the extent of its contents.
    (developer group link)
Feedback & Bug Reports
Please contact tomgibara at hotmail dot com
Other Notes

Please consult the application help, it will explain how to configure and use the Moseycode application.

At present performance of the application, in terms of refresh rates, is poor (by almost any metric). This is due to a number of factors:

  • Obtaining frames over an HTTP or TCP/IP connection is naturally very slow. This accounts for the greatest 'slow down'.
  • The main image processing method avoids any function calls, floating point arithmetic or even integer divides – yet is still slow. The overwhelming overhead in this section of the code is the Dalvik interpreter. Further improvements must practically wait until a JIT or AOT compiler is made available.
  • Thresholding needs to be performed on images by application code; there are no facilities for thresholding images using the graphics APIs that are currently available.
  • There are some small but important algorithmic improvements that can be made for accurate processing modes and in the case where multiple barcodes are being scanned.
  • Rendering is largely unoptimized and is likely to remain so until the system is more complete.