Development Guideline

User

Please register on this page for a user. Then let me know the username, and I will add you to the project.
(A message on the forum announcing yourself is a good way to get in touch :)

Issues

We use Issues to track work items. I'd prefer that only the ones set up to be developers, add "Non Bug" issues. Testers should add "Bug" issues if they find problems. Make sure to check the currently open bugs before adding a new issue.

Subversion

Subversion is used for source code revision. Tags will be made for each release. Information on how to use subversion is available at http://subversion.tigris.org. A cheat sheet can be found at http://www.abbeyworkshop.com/howto/misc/svn01/.

Subclipse, a subversion client can be found at http://subclipse.tigris.org

SVN Basics

If you're new to subversion and just want to get on with this project than don't bother on subversion installation and repository management details. Get the bin for your system and read the cheat sheet for the most used commands:

  • checkout : to get a local copy of the repository
  • update : to update your local files with changes from the remote repository
  • commit : to commit your changes to the remote repository, don't forget the message!
  • status : to get an overview of the files that were updated
  • add : to add a new file to versioning, must be followed by a commit to actually get the file online
  • delete : to delete a file from the repository

Commits

Commits should be fairly specific. Try to perform a commit containing only the files that was changed for a specific issue.
All commits should refer to an Issue, either just refering to it, or closing it.

When commiting, please use the following keywords to connect the commit to an issue:
  • refs #<issue number>
  • closes #<issue number>

eg:

closes #333 added class to deal with something

Coding for Performance

As we deal with high speed packets, and trying to handle these on "low performance" phones, it is important that we keep focus on performance. In particular regarding the "realtime loop". (Frame detection and handling).

The http://developer.android.com/guide/practices/design/performance.html is a good starting point regarding performance.

Decimal numbers to Nice string representation

Android is not particular fast when using the built-in methods for number to formatted string.
In general: Avoid all Decimal to string in the frameparsing/realtime loop
In particular:
  • String.format("%.2f", value) - AVOID
  • DecimalFormat.format() - AVOID in realtime loop. Preferred method for GUI updates

Coding standards

We obide by (or at least do our best to) the rules of the Java Coding Convention rules. More information can be found at http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html. The minimum required conventions are the following:

  • use CamelCase for variable and class names
  • class names begin with capitals
  • members (variables & methods) begin with small letters
  • constants are all capitals
  • provide the proper visibility for members and accessors (getters and setters) only if needed
  • use packages for grouping classes
  • use inline comments to clearify code blocks
  • use javadoc where useful
  • don't leave catch blocks empty
  • program in an Object Oriented way providing small specialized methods and representative classes
  • provide toString methods for easy debugging classes

JavaDoc

The generated javadoc information for this project can be found at: http://onomato.biz/android-dash/javadoc/. Of you contribute to the coding it's appreciated if you provide comments inline (using either // or /* /) and javadoc for classes and members. Javadoc comments begin with /* and end with */ and are on top of the class or member it describes. For more information on how to write javadoc please have a quick look at: http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html.