Pull to refresh
12
0
Pavel Dudka @paveldudka

User

Send message
Да, поздно заметил) Но за статью спасибо — с удовольствием почитал англ версию.
Неплохо было бы пометить статью как перевод и указать оригинал.
UPDATE: Ха, только заметил, что Вы и есть автор и эта статья — на самом деле оригинал :)
За пост спасибо, но я бы все-таки порекомендовал использовать GoogleApiClient для общения с GooglePlayServices, а не создавать ActivityRecognitionClient напрямую. Негоже учить использованию deprecated APIs :)
Также, если мне не изменяет память, в манифесте не помешает зарегистрировать «ActivityRecognitionService» иначе работать не будет ;)
Интересно было почитать. Через пару недель лечу на Google I/O —  надо будет похожую статью написать. Интересно сравнить опыт :)
По поводу перевода — я использую «translate.google.com/#auto|auto|%s» (ключевое слово «tr») — определяет язык автоматически. Удобно тем, что нет необходимости иметь 2 разные настройки для русского и англ перевода. Просто вводишь tr nightingale или tr соловей — Google сам определяет с какого на какой язык переводить
Насчет UniversalImageLoader — рекомендую также взглянуть на Picasso библиотеку
Кстати наткнулся на то, что Вы как раз ищите: GlassActionBar
На самом деле даже не пробовал сделать  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 проект как будет время.
число записано в шестнадцатеричной форме. Но ведь она допускает только A,B,C,D,E в качестве букв — кажете вы. Откуда тогда P и F?

Сижу вчитываюсь… С каких пор «F» — не часть 16тиричного числа? Я что-то не так понял?
Какое же все-таки самое употребляемое слово? :) Только скорей всего это предлог какой-нибудь, поэтому надо еще ограничение на мин длину слова
ну или 8 звездочек :)
Все верно — в данном примере я показал Fields Injection. Есть еще Constructor Injection, о котором Вы говорите.
На самом деле, Injector.inject() рано или поздно прийдется сделать, потому что для кого-то TwitterApi будет полем, а при FieldInjection необходимо добавлять себя в контейнер.
Тем не менее, Ваш вариант явно лучше хотя бы тем, что TwitterApi модуль уже не зависит от контейнера. Опыта с DI у меня немного, поэтому на подобные грабли не наступал (пока :) )
Все верно, client инициализируется при inject'e. this.client = client — досадный копи-паст… Поправил. Спасибо еще раз!
Не совсем. В случае с Dagger, мы убрали HttpClient из конструктора, поэтому у класса Tweeter остался только конструктор по умолчанию. Т.е. HttpClient указывается только в классе, которому он непосредственно необходим и нет необходимости «тянуть» его из родительских классов. Забыл добавить этот класс в вариант с Dagger — обновлю пост. Спасибо!

Information

Rating
Does not participate
Location
Redmond, Washington, США
Date of birth
Registered
Activity