Moseycode Release Notes 0.2.1

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
May 20th 2008
Changes
Please see the changelog
Requirements
Android SDK m5-rc15 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.
  • Publishing related activities have not been adapted to landscape mode.
  • 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.
  • Though downloads are properly managed, no firm limits are yet 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.
  • Barcodes that link to documents on the web do not display the URL that they will open, unless they have a title; in general, there is no indication (at present) of the flavour of barcode being viewed.
  • At present, the Moseycode server does not modify chamber documents to insert the known creation and last-modified dates. This means that the dates reported by the barcode may differ from those given in the publishing activities.
  • Links in the About activity cannot be activated because TextViews do not seem to honour click events and there is no way to style 'Linkified' text.
  • Menu items in the History activity do not become disabled when irrelevant.
  • There is no confirmation when selecting "Clear History" from the History activity menu.
  • 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.
  • No time synchronization is performed between client & server, this can result in slightly inaccurate date classifications in listings.
  • The Settings activity spans URL settings over multiple lines instead of constraining input to a single line. This causes scrolling to become necessary in some instances. This a partial workaround to a serious bug in Android. Generally attempting to enter more text than there is space for in any text entry box in the Settings activity will cause the interface to become unusable.
    (issue tracker link)
  • The application may exhibit slow network access because it is not possible to resuse reuse HTTP client objects.
    (developer group link)
    The new version of the library cannot be used to address the problem because of this bug:
    (issue tracker link)
  • External links appear dark blue, whereas they should be styled green for legibility and consistency. This is because links cannot currently be styled. External links in the About activity do not currently launch in a separate browser because the available default styling makes them unreadable.
    (issue tracker 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'.
    (developer group link)
Feedback & Bug Reports
Please contact me at tomgibara 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.