No way to set sensitivity of underlying ShakeDetector about shaky-android

[drewhannay]

It would probably be simplest to add a new method to ShakeDelegate that you can optionally override to set the sensitivity int. I'm skeptical that there are enough other things people would want to customize to be worth letting them set a custom ShakeDetector (but feel free to disagree and explain why).

Happy to accept a PR for this, thanks for flagging it :)

[akalra]

That's interesting, I actually hadn't thought about that.

In my mental conception of the entities, ShakeDelegate was the thing you delegated the shake event to, to figure out how to process it. I didn't expect it to have any configuration for the ShakeDetector, though I see now that it already does a little bit of that (isEnabled()).

I'm not yet sure how I feel about that, it seems odd to be injecting something to a ShakeDetector that both configures it and processes its output. They seem like two semantically different things to me, so I would have assumed you would inject a ShakeDetectionConfiguration and a ShakeDelegate separately.

Am I thinking about your modeling the wrong way?

[drewhannay]

From a "pure" modeling perspective, your approach is probably more correct. My reasoning is mostly just that this is a fairly simple library and I was hoping to keep a fairly simple API, where most things just work out of the box with no configuration.

ShakeDelegate is maybe not the greatest name because I'm really thinking of it as the way the app hooks into the library, both for configuration and for processing. It's possible we might want to separate out two objects like you described, but since isEnabled is already in ShakeDelegate, we can't do that without a breaking change.

So how about for now we just add the extra method to ShakeDelegate and then if we keep getting more requests for configuration options, I'll make a major version bump down the line and separate it out into a separate configuration object. I'm hoping that strikes the right balance between correctness and practicality, what do you think?

[akalra]

Sent in a basic PR based off of your comments. Held off on doing anything too fancy for now, though I did restrict knowledge of the Seismic constants to the one class that interacts with Seismic, and created corresponding values for within Shaky.

Not ideal, but leaking abstractions or using weaker modeling (strings or something) made me a little uncomfortable.

Ankur