hello, vanomart!

how can I help you today?

Hi Mark, I am working on app that uses sensors. The goal is to get the data from different users/phones and then using the data to train the ML model that would predict which hand users hold the phone. I noticed from the testing so far that various phones output different sensor values. I was not able to find any useful information how to tackle this problem. I saw at some google apps that they require the user to calibrate the sensors before the first use, but I am not quite sure how to do that. Do you have any idea how should I approach this problem? Thanks

well, I have never done this

my assumption is that those apps just present the UI (e.g., "twist the phone like this") and collect readings

how exactly they use that to normalize their data is less of an Android thing and more of a statistics thing, I guess

the problem is that the calibration itself may be unreliable, if the user does not completely follow the instructions

I assume that the "calibrated" data points prove to be better than not doing it, but, again, that's a matter of the data normalization more than the actual Android code

My problem is that only some phones output weird sensor data, moreover only some sensor values are off.

I am sorry, but I have no real idea what I am looking at in this image

this is the accelerometer plot of the scroll task. different traces represent x,y,z values

what is the unit of the X axis?

milliseconds from the beginning of the experiment

and, what is your specific concern with what these graphs are telling you? just the noise?

I am not quite sure I can explain it. Ok, nevermind, I was just interested if you ever had to solve such problem.

sorry, but no

I also have an unanswered question in SO. Could you take a quick look? Thank you. http://stackoverflow.com/questions/42900284/str...

I have not used those annotations, outside of what little that I assembled for a book chapter

have you tried using a shorter EVENT_2?

or temporarily removing the @Size?

as right now, if I understand correctly, EVENT_2 is not a valid value, due to length

yet you're saying in the @StringDef that it *is* a valid value

and that could be confusing Lint

yes, EVENT_2 is not valid. Where exactly I say that?

well, the value is "really_long_event_name_that_exceeds_32_chars_limit"

so, while I didn't count the characters, I assume that it is longer than 32 characters :-)

yes, it is longer but the lint is not triggered

my point is that having an invalid value in a @StringDef might be confusing Lint

Ok let's say that it might confuse lint. What should however work is sending an invalid param to the function. If I call new UserActivityEvent("asd"); but "asd" is not defined in @UserActivityEvents the lint should be triggered, right? Or not?

I agree with your interpretation

but I suggest either changing EVENT_2 to be valid or temporarily removing the @Size, and see what the results are

if Lint now rejects "asd", then my Lint-confusion theory holds

if Lint still accepts "asd", then my theory does not hold, and I am as confused as you are

yep, that fixes the problem with passing a value other than one defined in @UserActivityEvents

any idea how to implement a lint check for a field that cannot be longer than 32 chars? I can now see that if I apply both @Size and @StringDef to one class, the @StringDef is ignored

why would you need @Size with @StringDef?

so long as @StringDef has short-enough strings, by definition, your size limit is covered

my idea was to just specify events and don't care about the length. I log approximately 70 events in the app and we previously used events longer than 32 chars that were not displayed in the firebase. So instead of manually checking for the length or writing some shell script do to it I wanted something simple that would do it for me, in AS

well, then, temporarily remove the @StringDef, and leave just @Size

see where Lint complains

fix those events

later, if you switch back to @StringDef, you can get rid of @Size

Yes, I guess I have to do it this way. ok Mark, thank you for your time. Have a nice rest of the day :)

you too!

that is a wrap for today's chat

the next chat is Tuesday at 7:30pm US Eastern

have a pleasant day!