[HTC One S] ovimunt:
Just thought I should mention that I do have quite a bit of experience in C++ and Java programming but I have no experience with the Android environment and that's where I need some help.

If someone could explain to me how the bits I'm interested in fit together in Android I'm sure I'd be able to do all the programming. The problem is that I don't have the time to read all the Android documentation and go through all the source code to get up to speed with all the relevant aspects so I would need some help to get a head start on it.

Also, in response to some of the requests:

- I don't think double tap is a good idea on keys that are expected to perform a single tap function which is unrelated to the double tap function. Basically, the way the singe click / double click works with the mouse is that the double click is an additional function to what the single click does so that the system can process the single click action straight away and then wait to see if a second click was performed in the relevant timeframe - i.e. a double click on an icon in order to start an aplication involves selecting the icon first and then launching the application the icon links to. If you look at it carefully you'll see that the action of a double click is actually made up of the action of a single click (i.e. select icon) plus an additional action which is performed once the second click is detected (i.e. launch application). So the only way you can implement a double tap on a button which also has a single tap assigned to it is if the second tap performs an action that is additional to the first tap. Otherwise, as Habarug already mentioned, we would introduce a lag as the system would have to wait for a given time to decide whether it was a single tap or a double tap and only then perform the relevant action. You may say that double taps are already implemented in Android but if you actually look at each and every situation where they are used you will see that they either fit the description I've given above or they are used in a situation where a single tap would not perform any action. The only exception is in the internet browser - i.e. a double tap performs a zoom-in / zoom-out, whereas if you single tap on a link it follows the link, which is an action unrelated to the double tap. However, if you look closely you will realize that this is actually handeled the same as explained with the single-click / double-click - i.e. if you try to double tap on a link you will see that the link actually gets selected but the browser does not follow the link and instead performs a zoom-in / zoom-out. So, how does this work then? Well, very simple, a lag is in fact intoduced on all single taps in the browser! Have you noticed how when you tap on a link the browser does not follow it straight away but instead just sits there doing nothing for a split second and then performs the action? If you don't believe me just try it yourself, you'll notice it. What the system does is that it performs the bit of the single tap action which is 'safe' to perform (i.e. select the link) but then it waits to see whether it was a single or a double tap before it performs the 'unsafe' part of the action (i.e. follow link or zoom-in / zoom-out). I say 'unsafe' because this bit of the action depends on what the user has actually done, i.e. single tap or double tap, so the system cannot go ahead and perform it until it knows for sure what the user actually wants, whereas the 'safe' action is something the system can perform regardless as it will not impact on what the user is doing as the 'unsafe' action would. So I guess the whole point is, do you want to have a lag on your capacitive buttons or not? My guess is that you don't want a lag on your buttons whereas in the internet browser a lag is assumed to be acceptable.

- implementing long-press actions on all capacitive buttons would be nice but we have to start somewhere so we need to set some targets, i.e. long press on recent apps for starters and then we can look at other things. Otherwise we risk loosing the plot.