AGTEK Lib (henceforth called “Lib” for keyboard convenience) is a library of code to provide a repository of common functionality for Android and Java applications. While the potential exists for generic Java applications, the focus is currently Android, so using this Library in a generic Java application may require some effort (particularly repackaging, building proper build scripts, etc.) It's also possible that a generic Java platform library needs to exist separately from the Android lib. Generic Java would be usable in in Android, which Java Swing would not be (much like Android specific functionality). Note for future thoughts, split the library 3 ways (generic, Android Platform specific, Java Platform specific).

This document is intended to give the reader an overview, with some taste (via simple code snippets) of how pieces of the Lib are to be used. This documented is not intended document each class, member, or method. The Javadocs are to be used for detailed reference on call level documentation. All components of the Lib are required to be Javadoc'ed.

AGTEK Lib is a collection of different functional groups. Largely the groups are intended to be interoperable functional classes. It's possible that some functional groups are intraoperable, but that is not a design requirement for the Lib. It is envisioned that the Lib will grow, somewhat organically as the Android product suite expands. While inclusion of a new functional group is encouraged, a group must exhibit some of the following characteristics:

• Be written in an application neutral manner. Under no circumstances must a Lib component be aware of what application is using it.
• A library should be usable by more than one application. In otherwords, it should be obvious that the functional group is useful in a wider context. If you aren't sure, keep it with the originating application, and move it to the Lib when it it is needed by the second application.
• Unit tests must be provided for all appropriate components. It is recognized that when dealing with external devices, or servers, you've gone beyond the ability to unit test the code. In all circumstances the code needs to be tested and provable correct before being checked in to the Lib.
• All classes and methods must be JavaDoc'ed.
• Tags will be layed upon the Subversion project to aid configuration management and rebuilding repeatable / secure applications. Generally developers should do their work on the HEAD of the trunk.