At the time of writing, there seem to be no complete explaination on what is needed to setup everything. I got everything working with combined information from the comments in issue 126 by staxgr and arichiardi.

• Prepare the Eclipse project and create the directories libs and libs-compile.
• Download the following libraries:
  • the dagger jars from Maven Central.
  • dagger-x.x.x.jar goes into the libs directory
  • dagger-compiler-x.x.x.jar goes in the libs-compile directory
  • the javawriter jar and put it into libs-compile
  • javax.inject goes into libs
• Enable Annotation Processing and add all four libraries to the factory path of the annotation processing settings
  • Project Properties → Java Compiler → Annotation Processing
    • check "Enable project specific settings" and "Enable annotation processing"
  •  Project Properties → Java Compiler → Annotation Processing → Factory Path
    • "Add JARs..." for each downloaded jar

When starting a build, the generated files should appear in .apt_generated. This directory should be automatically configured as a source folder after annotation processing has Bern enabled.

Let's assume we have a backlog packed with 80 user stories. Each of them has a decent description and also has acceptance criteria defined.

As a first step we need to set up complexity buckets. In those buckets we'll put stories with similar complexity. For simplicity we choose shirt sizes: XS, S, M, L and XL. The XS bucket is for stories which can be easily achieved in a couple of hours, whereas the XL bucket is for stories which we don't really have a clue on how to solve. All other stories would be evenly distributed among the other buckets.

The buckets get put on a board in form of cards. The user stories will be put next to the bucket cards.

The product owner starts by briefly presenting each user story. The team then has just a couple of seconds to decide on the complexity of the story. When time is up (the ScrumMaster could help here by watching the time) the story goes into its complexity bucket. This process shouldn't really take much longer than 30 seconds, certainly not longer than a minute. If the team cannot make a reasonable decision, just put the story in one of the higher ranked buckets -- we are not in a sprint planning, we just want to get an idea of the workload. Don't think about it too long, just shoot right away.

After all stories are distributed the team gets time to have a look over all buckets (in the meantime the product owner can go to get a coffee refill). Are there some stories which doesn't quite fit to the others? The team can take maybe ten minutes to reorder all stories. If there are stories which could make up there own bucket, create a new one. There might be real no-brainers which could all go into an XXS bucket. But don't try to create too many buckets, this wouldn't be much helpful.

Now all user stories are clustered into their complexity. In the next step we can put story points on the buckets: is the S bucket three or five points; the XL bucket might be 20 points. When all buckets have story points assigned, we can add it all up.

Board with user stories arranged into complexity categories

The sum of story points gives us a rough direction of how many sprints it would take to finish all user stories. At the end the product owner can use the estimated story points to prioritize user stories for the upcoming sprints. Furthermore, he can compare the estimation outcome with the product's time table if it is actually possible to do or maybe if some feature need to be cut down.

This approach is just one possible way of doing a magic estimation. There are other ways the team could do this:

As soon as new code is finished it should be integrated into the code base. By that it is not only ensured that all members of the development team get access to new code, it also minimises the risk of running into incompatibilities and reduces the complexity of merging changes.

In a recurring fashion this could happen at the end of development day. Also partly finished features can already be pushed into the base as long as they meet the project's quality minimums (etc. testable/tested, documented). At the beginning of the next development day changes would get individually pulled into the working copy.

Maximise coverage of automated tests

Testing code is a crucial part in reaching a certain level of quality and stability. To minimise the workload needed the process should be automated where possible. This can be done with unit tests using state of the art testing frameworks (JUnit, Selenium, etc) to further reduce workload.

It should be also possible to combine testing with continuous integration. This gives the advantage of running tests as often as possible and getting the chance to react to issues quickly.

Think ahead and stay flexible

Each team member should keep the future constantly in mind. As the application grows requirements might (or most likely "will") change. To be able to react and implement these changes it is important to always develop for scalability and flexibility. This accounts not only for the development members but also for the management members of team. The management should always evaluate new features with what might come next.

Keep it simple

Always create the simplest solution for a problem that will work and deliver for the minimum requirement. Maintaining a simple, clean and open design ensures that the application can be easily extended while staying focused and meeting dead lines.

// ...
if (charset == null) {
charset = HTTP.DEFAULT_CONTENT_CHARSET;
}
// ...

And guess what, HTTP.DEFAULT_CONTENT_CHARSET does not take advantage of Charset.defaultCharset() but instead is set up with "ISO-8859-1".

To get real UTF-8 data we need to do something like new StringEntity("âáàéèê", HTTP.UTF_8);.

java.lang.IllegalStateException this should only be called when the cursor is valid

You might want to call stopManagingCursor in onResume()

The package glossaries seems to be state of the art. I set it up as the following on my Windows machine with TeXnicCenter:

% in the preamble
\usepackage{glossaries}
\makeglossaries

Define a new output profile: Copy one of the existing profiles (e.g. "LaTeX > PDF") and add the following entries to the postprocessing tab:

• makeglossaries #1
  Application: {full path to}/makeindex.exe
  Arguments: -s "%bm".ist -t "%bm".glg -o "%bm".gls "%bm".glo
• makeacronyms #1
  Application: {full path to}/makeindex.exe
  Arguments: -s "%bm".ist -t "%bm".alg -o "%bm".acr "%bm".acn
• pdflatex #2
  copy from (La)Tex tab
• makeglossaries #2
  Application: {full path to}/makeindex.exe
  Arguments: -s "%bm".ist -t "%bm".glg -o "%bm".gls "%bm".glo
• makeacronyms #1
  Application: {full path to}/makeindex.exe
  Arguments: -s "%bm".ist -t "%bm".alg -o "%bm".acr "%bm".acn
• pdflatex #3
  copy from (La)Tex tab

This procedure avoids to use of makeglossaries.exe which requires that you have Perl installed. The iterative calls are described in the Latex Wikibook and it seems to work well this way. You can import my output profile: latex-pdf-glossary+acronym.tco

Mind, that if you use the hyperref package, to load this before the glossaries package. This way glossary entries will be automatically linked in the PDF output.

I just updated JavaCV to the latest version (2011-07-05) which includes OpenCV 2.3.0 and some precompiled code for Android devices with an FPU (armeabi-v7a). Just by replacing JavaCV I gained an enormously computation boost. Well, of course I knew that an FPU is better for heavy number crunching than a CPU. Nevertheless I'm surprised that this makes such a big difference even in the tiny smartphone (HTC Desire HD).

My current implementation detects Shi-Thomasi corners and then tries to track them in following video frames. Where yesterday (without "FPU-code") my detector needed around 3 to 4 seconds to detect about 50 corners (even though it didn't much matter if I detected 50 or let's say 250) now it needs about 170 milliseconds and very often even less. My tracker needed about 1000 milliseconds to find known corners in new frames -- now 20 milliseconds. The detector is about 18 times faster.

I know, I know ... this is kind of supposed to be like that . But I'm just surprised to see this working. As result from that I will just target on devices with an FPU. I'm not quite sure yet if a certain Android version requires an FPU, so could just say e.g. from 2.3.0 and up my program will work or if I need to actually check this during runtime.

Last updates were in January this year, so quite up-to-date actually.

Oh, btw, guys why can't I find you when I search for "AR Android". I mean seriously, take care of your website keywords

Hopefully this can boost my project a little.Will see.

AndroidExperimental looked promising at the beginning. But of course everything just works on Linux without problems.

The step where get_ndk_toolchain_linux.sh is referenced won't work on Windows and actually you don't need to do everything in there if you already have the NDK. So, assuming the NDK is already installed, just run the last portion of the script. The following is what worked for me with Cygwin. ANDROID_NDK was defined in the Windows environment variables and therefore had backslashes in it, somehow this wouldn't want to work, so I overwrite it. NDK_TMPDIR is used in the shell script and with Cygwin it has no write access to this folder. Choosing another folder worked.

export ANDROID_NDK=/cygdrive/d/android-ndk-windows
export NDK_TMPDIR=$ANDROID_NDK/../ndk-tmp

$ANDROID_NDK/build/tools/make-standalone-toolchain.sh --platform=android-5 --install-dir=$ANDROID_NDK/android-toolchain --system=windows

ln -fs $ANDROID_NDK/android-toolchain /opt/android-toolchain

So, this prep-work is done. Unfortunately compiling the hello-cmake sample didn't work and ends with:

-- Check for working C compiler: /cygdrive/d/android-ndk-windows/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc -- broken
CMake Error at /usr/share/cmake-2.8.4/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE):
  The C compiler "/cygdrive/d/android-ndk-windows/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc" is not able to compile a simple test program.

I'm not sure why this is happening. Maybe it's because the path to the project has spaces in it. Or what ever.
Trying something else for now.

But there is more. Qualcomms QCAR augmented reality SDK is well up to date and working incredibly good. Though, there is a huge problem: If you want to track images with natural features you'd need to first upload your images, let them go through Qualcomms "Image Target System", download some binary file (which has most likely interest points from the image in it) and then compile everything into the Android application. I mean, come on! How useful is that!? So I cannot use QCAR either, because I want to dynamically load interest points and other information during runtime.

What is left? I guess I need to try it on my own. OpenCV has all the functionality I need (There is this Android-optimized version which compiles nicely with the NDK). I "just" need to use it. JavaCV is Java-based wrapper to the OpenCV API, it is not commented at all but hopefully it will be of any use for me.

If there is someone out there with (helping) suggestions, please drop me a line in the comments.

Similar to PTAM Wagner et. al also use a separated detection and tracking system. The detection system tries to find known targets in the currently available camera image using a modified SIFT algorithm. Instead of calculating the kind of expensive Differences of Gaussian (DoG) they use a FAST corner detection over multiple scales. Memory consumption is then reduced by using only 36-dimensional features instead of the original 128-dimensions of SIFT. Found descriptors are matched with entries from multiple spill trees, which is a similar data structure like the k-d-tree used in the original SIFT.

-- unfinished --