Pull to refresh

Comments 11

Догадался, скорее всего из-за того, что в этом случае постоянно генерировались бы списки, а это лишние затраты.
Протестировал своё предположение на C#
 Observable.Never<Object>().Buffer(TimeSpan.FromSeconds(1)).Subscribe(list => Console.WriteLine(list.Count));
Простой пример, когда этот оператор не даст нам ожидаемого результата: граница буффера попала как раз на серию событий, в результате в каждом буффере будет меньше трех событий. Попробую это визуализировать: [...**][*....]. В первом буффере будет 2 события, во втором — одно событие.
К тому же, этот оператор генерирует события, даже если на входе вообще не было событий (генерируются пустые массивы), что не сильно вредно, но не нужно в нашем случае.

А вообще, предлагаемое решение — не единственное, ради тренировки можно попробовать решить еще короче!
Решение на RxJava элегантное, спасибо.

Справедливости ради решение от Seismic всего на примерно 150 линий длиннее, но не подключает три библиотеки для решения задачи.
Спасибо! Согласен, подключать зависимости никто не любит, но ведь область применения этих библиотек не ограничивается этой одной фичей. Вы сможете использовать их мощь повсюду. А без лямбд вообще грустно.
применяют low pass фильтрацию для того, чтобы убрать гравитационную составляющую.
Там high pass.
Не за что. А про Sensor.TYPE_ACCELEROMETER первая мысль та, что он более «древний», код для этого типа писался, когда не было ещё Sensor.TYPE_LINEAR_ACCELERATION, и упомянутые решения тянутся оттуда.
Всегда интересовало — а как использование этого сенсора отражается на расходе батареи? Т.е. что в данном случае означает «подписка на событие»? Включение сенсора (если выключен) и подписка или просто подписка (он и так включен всегда)?
Sign up to leave a comment.