fixed backwards compatibility for API 8 (#694)

[ghost]

Fixes strange sliding behavior for API <11 as mentioned in issue #694 and slight fix to catch API 11 call introduced in issue #525

** I'm not very familiar (yet) with pulling/pushing remotes, please let me know if I make mistakes in procedure/form, or if anything needs changing.

[ghost]

Not a lot going on in the code (which I consider a good thing :P)

my old HTC desire with android 2.2 (API 8) couldn't run the app without eventually crashing and no smooth sliding
another Alcatel one touch with 2.3 (api 9) seemed to work without problems with the original code

this branch recreates at least the backwards compatibility and (possibly?) an issue with some older (probably slower) devices.

[charlesdurham]

The logic here looks exactly the same, can you elaborate how this is solving #694?

[ghost]

my guess is race condition / slower hardware, the logic IS exactly the same, but the jittery (and buggy) sliding happened because the return value (calculated in the topBoundCollapsed code below) would every now and then switch from X to -X while isSlidingUp and all calculated values would be correct
// adding this line already solved the problem
Log.d("jack", "values= " + getMeasuredHeight() + " " + getPaddingBottom() + " " + mPanelHeight + " " + slidePixelOffset );

when I added that line there for troubleshooting, the problem immediately disappeared, and seeing as the only thing happening was the 'pre-calculation' of several functioned values, having the values calculated before the actual return statement, solved the strange behavior (I considered that a better 'solution' then leaving a debug line in)

Also as it turned out, HTC desire (2.2) had the problem, another alcatel one touch (with 2.3) didn't so it might be a bit more device specific, seeing as the logic doesn't change, this will probably make it work on more (possibly slower) devices

** topBoundCollapsed in below function would be -660 instead of the expected 660 it did on 'slower slides' or just hitting DragView (for a bottom panel anyway)

private float computeSlideOffset(int topPosition) {
        // Compute the panel top position if the panel is collapsed (offset 0)
        final int topBoundCollapsed = computePanelTopPosition(0);

I agree it's been baffling me for a few days already :) but the above explanation seems to make the most sense, I do know that adding that line makes the library use-able (and sliding smooth) for me on my test device while without it the sliding is all over the place (-X here meant it wasn't sure if it wanted to be Top or Bottom Panel :) )