Неплохо было бы пометить статью как перевод и указать оригинал. UPDATE: Ха, только заметил, что Вы и есть автор и эта статья — на самом деле оригинал :)
За пост спасибо, но я бы все-таки порекомендовал использовать GoogleApiClient для общения с GooglePlayServices, а не создавать ActivityRecognitionClient напрямую. Негоже учить использованию deprecated APIs :)
Также, если мне не изменяет память, в манифесте не помешает зарегистрировать «ActivityRecognitionService» иначе работать не будет ;)
По поводу перевода — я использую «translate.google.com/#auto|auto|%s» (ключевое слово «tr») — определяет язык автоматически. Удобно тем, что нет необходимости иметь 2 разные настройки для русского и англ перевода. Просто вводишь tr nightingale или tr соловей — Google сам определяет с какого на какой язык переводить
На самом деле даже не пробовал сделать real-time blur. По понятным причинам размывать кусок фона при каждом изменении скрола не вариант :) Но можно попробовать сделать что-то вроде размытия всего экрана (верней той части listView, что в данный момент видна на экране). Как только listView начинает скроллиться, скроллим нашу размытую подложку. Главное расположить layout так, чтобы подложка была видна только под ActionBar (ну или что используется для этих целей), т.е была иллюзия что размывается сам listView. Как только «доезжаем» до края размытой подложки — размываем новую порцию listView (что в данный момент на экране). В данном случае небольшой «лаг» будет заметен при обновлении подложки.
Но, если честно, не уверен, что из этого выйдет что-то хорошее :( Надо пробовать.
В Yahoo Weather сделали хитрый трюк — они не делают новую порцию размытого экрана как только доезжают до края подложки — они оставляют ее на месте. Создается иллюзия динамически размываемого фона, хотя по сути размывают они весь фон только один раз.
Насчет fps — совершенно согласен, но тут скорей я просто выразился неточно. Имелось как раз в виду, что при длительности обработки >16ms начнут пропускаться фреймы. Этот дроп в fps будет наблюдаться только во время работы blur'a. В то же время blur отработает только 1 раз, а потом закешируется.
Насчет ООП — работы тут еще много — т.к. логика в обоих фрагментах одинакова, можно было создать 1 базовый фрагмент и «скармливать» туда что-то вроде интерфейса Blurrer, Оптимизировать и оптимизировать)) Но целью данной статьи небыло создание универсального виджета production-уровня. Я лишь хотел показать с чем едят blur.
Плюс далеко неизвестно кто и как будет использовать blur, поэтому сложно полагаться на тот факт, что размывать мы будем только при создании фрагмента. В данный момент, к примеру, я работаю над куском UI, который размывает фон при показе floating окошка поверх активити. Да и даже, я думаю, найдутся уникалы, которые захотят размывать фон динамически при скроллинге контента (я бы настойчиво не рекомендавал это делать :) ). Вобщем применений может быть масса.
Но а в основном, очень даже валидные комментарии — обновлю GitHub проект как будет время.
Все верно — в данном примере я показал Fields Injection. Есть еще Constructor Injection, о котором Вы говорите.
На самом деле, Injector.inject() рано или поздно прийдется сделать, потому что для кого-то TwitterApi будет полем, а при FieldInjection необходимо добавлять себя в контейнер.
Тем не менее, Ваш вариант явно лучше хотя бы тем, что TwitterApi модуль уже не зависит от контейнера. Опыта с DI у меня немного, поэтому на подобные грабли не наступал (пока :) )
Не совсем. В случае с Dagger, мы убрали HttpClient из конструктора, поэтому у класса Tweeter остался только конструктор по умолчанию. Т.е. HttpClient указывается только в классе, которому он непосредственно необходим и нет необходимости «тянуть» его из родительских классов. Забыл добавить этот класс в вариант с Dagger — обновлю пост. Спасибо!
UPDATE: Ха, только заметил, что Вы и есть автор и эта статья — на самом деле оригинал :)
Также, если мне не изменяет память, в манифесте не помешает зарегистрировать «ActivityRecognitionService» иначе работать не будет ;)
tr nightingale
илиtr соловей
— Google сам определяет с какого на какой язык переводитьНо, если честно, не уверен, что из этого выйдет что-то хорошее :( Надо пробовать.
В Yahoo Weather сделали хитрый трюк — они не делают новую порцию размытого экрана как только доезжают до края подложки — они оставляют ее на месте. Создается иллюзия динамически размываемого фона, хотя по сути размывают они весь фон только один раз.
Насчет ООП — работы тут еще много — т.к. логика в обоих фрагментах одинакова, можно было создать 1 базовый фрагмент и «скармливать» туда что-то вроде интерфейса Blurrer, Оптимизировать и оптимизировать)) Но целью данной статьи небыло создание универсального виджета production-уровня. Я лишь хотел показать с чем едят blur.
Плюс далеко неизвестно кто и как будет использовать blur, поэтому сложно полагаться на тот факт, что размывать мы будем только при создании фрагмента. В данный момент, к примеру, я работаю над куском UI, который размывает фон при показе floating окошка поверх активити. Да и даже, я думаю, найдутся уникалы, которые захотят размывать фон динамически при скроллинге контента (я бы настойчиво не рекомендавал это делать :) ). Вобщем применений может быть масса.
Но а в основном, очень даже валидные комментарии — обновлю GitHub проект как будет время.
Сижу вчитываюсь… С каких пор «F» — не часть 16тиричного числа? Я что-то не так понял?
На самом деле, Injector.inject() рано или поздно прийдется сделать, потому что для кого-то TwitterApi будет полем, а при FieldInjection необходимо добавлять себя в контейнер.
Тем не менее, Ваш вариант явно лучше хотя бы тем, что TwitterApi модуль уже не зависит от контейнера. Опыта с DI у меня немного, поэтому на подобные грабли не наступал (пока :) )
this.client = client
— досадный копи-паст… Поправил. Спасибо еще раз!