С киткатом есть, например, GoogleNow теперь по свайпу влево можно открыть (он как ты крайний левый экран) + иконки, статусбар (статусбар, конечно, не от лаунчера зависит, а от L, но внешний вид же меняется). А, еще удобна функция, это возможность «ok, google» говорить прям с рабочего стола, в киткате вроде этого нет.
В маркете есть Google Now Launcher, вроде как его пилят как backport для лаунчера, который будет в L, можете его и попробовать.
На самом деле, у меня интересное отношение к лаунчерам. Я много чего просмотрел, многие из них интересные, даже покупал и пробовал, но вот не приживаются, и все тут. Так и сижу на стандартном Google Now Launcher на Developer Preview L и никак не переходится на другие с него. Интересно попробовать Ваш, вдруг получится?:)
Такого, как Вы говорите, лично я не видел. Но если интересна эта тема, советую взгляуть на Yahoo Aviate Launcher, подстраивает под ваш день виджеты и приложения.
Ну а если «я и сам дурак, что ему доверил это поручение» прозвучит трижды, то руководство будет уверено что «ты и сам дурак».
Я так понимаю, это не нужно говорить в слух, это нужно понимать, брать на заметку и решить проблему до того, как руководство будет обвинять Вас в провалах.
если проектов 7 штук в неделю и еще 26 мелких непредсказуемых задач в сутки.
Вероятно, в этом случае в компании неправильно поставлен процесс управления или острая нехватка кадров.
Мне, кстати, довелось работать с менеджером, который как раз таки делегирует не только обязанности, но и ответственности. Я не долго с ним работал, стоит сказать:)
Возможно, где-то в больших компаниях так и есть. Но по опыту работы в небольших компаниях (100-1000) человек могу сказать, что здравую адекватную мысль довольно легко донести до своего менеждера, даже если она противоречит мысли заказчика и найти для всей этой ситуации решение/ответ заказчику.
И да, андроид приложения тем лучше, чем меньше у него прогресс баров. Логика «тут у меня асинхронная операция, нужны прогресс бары» далеко не всегда хорошая. Ну, может это дело вкуса, конечно.
И все таки ASyncTask использовать уже практически моветон. Как минимум есть альтернативы в лице RxJava с ее Observable, где поверх retrofit таскание картинок из интернетов ложится как нельзя лучше, да еще и не надо ничего пересоздавать. Просто отписывайтесь от обсервабла и подписывайтесь еще раз.
Если не хочется тянуть библиотеки или еще что, то можно стандартно, но все равно без ASyncTask. Насчет сервисов — не так уж много писанины. Особенно, если все равно надо кэшировать или хочется еще в каких то местах уведомлять пользователя (трэй, нотификации, тосты). Старая добрая архитектура Service (запросы) + ContentProvider(кэш) + BroadcastReceiverO(result delivery) отлично ложится на любой(почти) RESTful бэкэнд.
Стоит только унифицировать общение между сервисом и ui (роутинг запросиков + нормальные броадкасты), как все становится не так уж сложно.
Стало откровением, что forEach только от памяти зависит. Интересно так же, что по всем графикам видно, что hftc самая оптимальная для использования коллекция. Совпадение ли, но Вы и есть автор этих коллекций:)
Спасибо за статью, обязательно попробую hftc в своем проекте.
Нет, конкретно у нас просто только портрет ориентация поддерживается, вот и все. А на деле все работает хорошо, потому что внутри себя Observable все-таки никак не связан с контекстом активити, только с контекстом самого Application. А при перевороте он сохраняется. А подписываться и отписываться (для того, чтобы обрабатывать и менять UI) можно хоть-сколько раз.
А при том, что у нас в 2GisDialer используется RxJava. А 2GisDialer — это приложение, написанное под Android OS. Кроме того, в статье приведено сравнение подходов к многопоточности в Android с использованием ASyncTask и Observable. Также замечу, что класс ASyncTask является частью Android SDK и его нет в Java.
А если я не хочу cancel(), а хочу еще раз попробовать сделать запрос? Понятно, что ASyncTask вполне самодостаточная вещь в каокм-то смысле. Но ее функционал все же ограничен, стоит признать.
Нет, никаких проблем. Android Studio спокойно заходит во все тела всех Observable и все хорошо. Единственное, что затрудняет дебаг, так это пошаговая отладка, потому что на пути от onNext() до, например, flatMap, если произошел retry() происходит много внутренних преобразований.
Со стектрейсами все ок, читабельно, ее умные ребята делали.
RxJava прекрасно работает в случаях смены конфигурации экрана. Ее это просто не трогает. Observable не привязан к Context' у активити, если вы все правильно делаете. И дальше вам решать, что и как делать.
Там не виснет UI, просто зеленый экран и ничего не происходит. Почему так? Потому что в дайлере все еще есть архитектурные части, которые требуют инициализации при старте приложения. Правильным решением является устранение этой необходимости, а не ProgressBar перед историей вызовов. Они никак не относятся к RxJava. Какая вообще может быть инициализация у RxJava? Ее нет. Разве что создание тред пулов и все вот это, но оно никак не трогает старт приложения.
Да, с красотой действительно беда, об этом я говорил. Но вот по эффективности RxJava очень хороша. Особенно в связке с Retrofit, если говорить про REST.
Часы — очень крутая и полезная вещь, по моему мнению. Особенно понравилось, что в часах телефон просто можно разблокировать, а без часов надо использовать пин-код или паттерн. И возможность live синхронизации часов и телефона — тоже очень круто. Когда они на I/O сдвигали рецепты, было очень эффектно. Вообще радует, что экосистема развивается и в ширь и в глубину.
Но все таки жаль, что часы с круглым «циферблатом» не выпустили еще.
В маркете есть Google Now Launcher, вроде как его пилят как backport для лаунчера, который будет в L, можете его и попробовать.
Вероятно, в этом случае в компании неправильно поставлен процесс управления или острая нехватка кадров.
И все таки ASyncTask использовать уже практически моветон. Как минимум есть альтернативы в лице RxJava с ее Observable, где поверх retrofit таскание картинок из интернетов ложится как нельзя лучше, да еще и не надо ничего пересоздавать. Просто отписывайтесь от обсервабла и подписывайтесь еще раз.
Если не хочется тянуть библиотеки или еще что, то можно стандартно, но все равно без ASyncTask. Насчет сервисов — не так уж много писанины. Особенно, если все равно надо кэшировать или хочется еще в каких то местах уведомлять пользователя (трэй, нотификации, тосты). Старая добрая архитектура Service (запросы) + ContentProvider(кэш) + BroadcastReceiverO(result delivery) отлично ложится на любой(почти) RESTful бэкэнд.
Стоит только унифицировать общение между сервисом и ui (роутинг запросиков + нормальные броадкасты), как все становится не так уж сложно.
forEachтолько от памяти зависит. Интересно так же, что по всем графикам видно, что hftc самая оптимальная для использования коллекция. Совпадение ли, но Вы и есть автор этих коллекций:)Спасибо за статью, обязательно попробую hftc в своем проекте.
Observableвсе-таки никак не связан с контекстом активити, только с контекстом самогоApplication. А при перевороте он сохраняется. А подписываться и отписываться (для того, чтобы обрабатывать и менять UI) можно хоть-сколько раз.cancel(), а хочу еще раз попробовать сделать запрос? Понятно, что ASyncTask вполне самодостаточная вещь в каокм-то смысле. Но ее функционал все же ограничен, стоит признать.Observableи все хорошо. Единственное, что затрудняет дебаг, так это пошаговая отладка, потому что на пути отonNext()до, например,flatMap, если произошелretry()происходит много внутренних преобразований.Со стектрейсами все ок, читабельно, ее умные ребята делали.
Observableне привязан кContext' у активити, если вы все правильно делаете. И дальше вам решать, что и как делать.ProgressBarперед историей вызовов. Они никак не относятся к RxJava. Какая вообще может быть инициализация у RxJava? Ее нет. Разве что создание тред пулов и все вот это, но оно никак не трогает старт приложения.Но все таки жаль, что часы с круглым «циферблатом» не выпустили еще.