CAT-1316 Sensor-type to GAMING; LIN.ACC.- and ROT.VECT. (inclin.,…

[ghost]

…compass-dir) sensor fallback

[aried3r]

Extraneous space between float and [3].

[aried3r]

Please run the formatter on your files, there's quite a few formatting errors.

[martinbu]

Everything works fine now on Moto G1.

[ghost]

@aried3r: formatter run. Didn't think of it - but last time I ran the formatter @obusher had something against it:

obusher commented on May 18
I know the format of this class is not in best shape and it is compelling to use auto-format.
But i want to see a clean github-diff, so please do not use this magic. 🐰

I generally understand that - but it wouldn't be a problem when the formatter would be run automagically in every Android Studio on save - so the format wouldn't deteriorate in the first place.

@martinbu: Thanks for your help finding my copy/paste error - now the values in the Compute-Dialog in the formula-editor are correctly updated 👍

[aried3r]

While I agree that there should be an option to format it automatically, there is an option to only format the lines you have changed.

And while I don't personally commit from within Android Studio, there is an option to format before committing.

[robertpainsi]

edit: Dangle-it, @aried3r was faster! 😔

JFI: The comment you quoted is outdated and all java classes (except two lines [1] and [2]) are formatted according to the Android Studio formatter.
All new checkstyle rules are doing a great job, however, the approach mentioned by @aried3r should be used/preferred.

[ghost]

@aried3r : that's cool thanks - haven't tried committing from Android Studio yet.

[aried3r]

All new checkstyle rules are doing a great job

Is there a way to have Jenkins run this and report back within a few minutes? If this isn't already the case. I don't want to comment every PR because of these things.

It seems GitHub can list multiple test runs on PRs. See here for an example.

[robertpainsi]

Is there a way to have Jenkins run this and report back within a few minutes? If this isn't already the case. I don't want to comment every PR because of these things.

There is already an experimental jenkins job waiting to replace the current Catroid-Build-SourceTests-StaticChecks job. The new one will abort the complete PR testrun if there are any pmd, checkstyle or lint warnings. So, if a jenkins testrun takes only a few minutes, which you can check even without a jenkins account, it highly indicates new static code analyzing warnings. I'll ping you if the new job has been activated.

It seems GitHub can list multiple test runs on PRs. See here for an example.

Thanks for the tip! I like it and I'll write a (low priority) ticket for it. 😸

[thmq]

what happens here if useRotationVectorFallback is true? correct me if I'm wrong, but if there is no getRotationMatrixFromVector then the rotationMatrix is not initialised and hence you won't get any reasonable results anyway.

[ghost]

Hi!
If the useRotatitonVectorFallback is true - then the rotatiton-matrix is NOT obtained from the RotationVectorSensor (because this does not exist in this phone) but determined by means of the getRotationMatrix(float[],float[],float[],float[]) with accelerometer data AND macgnetic field data in line 303 in the onSensorChanged(...) method - when the MagneticField Sensor is present.
If NEITHER rotation-matrix sensor NOR magnetic field sensor are present compass direction does not work on this phone.

[thmq]

all right! got it! obviously I hadn't understood it properly before, thank you for clearing that up.

[thmq]

apart from the question regarding the compass direction the PR looks fine. any objections against merging it as soon as this has been cleared up? @robertpainsi @martinbu ?

[thmq]

I don't think the comments are necessary.

[ghost]

true

[ghost]

removed the two comments

[thmq]

retest this please

[robertpainsi]

That's an interesting case of else-if coding style...
Do you read it as else { if (... (because a else block doesn't require braces) or as else if (...?
However, let's see what the android studio formatter does! 😉

Also removing comments, as suggested by @thmq, does not always end up by just removing them. Please take a look at Clean Code, "Don't use a comment when you can use a function or variable".

However, I prefer this example

// Bad:
// Check to see if the employee is eligible for full benefits
if ((employee.flags & HOURLY_FLAG) && (employee.age > 65))

// Good:
if (employee.isEligibleForFullBenefits())

[thmq]

@robertpainsi 's right about this. you should try to keep your code as well legible as possible. besides there seems to be a problem with the sensor test [1].

[avihric]

retest this please

[ghost]

@thmq damn this test uses "reflection"!
I was sure the test was green but... since the "accelerometerSensor" which was originally used in the SensorHandler was actually the "linearAccelerationSensor" AND
"linearAcceleration[X|Y|Z]" were misspelled as "linearAcceleartion[X|Y|Z]" ;-)

So this happens when correcting variable-names AFTER running the "final" tests which uses "reflection". 🙀 Shame on me that I didn't have a look at the test - so I would have known.

[avihric]

I will merge this because the Release is urgent, but you will have to refactor Sensorhandler as described by @robertpainsi

Btw: I will cherry-pick this commit into master