Разрабатывая под Android, всегда нужно быть начеку. Шаг влево / шаг вправо — и вот прошел ещё один час за дебагом. Кюветы могут быть какие угодно: начиная от обычных багов в SDK и заканчивая неочевидными именами методов с контекстно зависимым результатом (да-да, Fragment.getFragmentManager(), это я о тебе).

В предыдущей статье были описаны кюветы «на поверхности» SDK, в которые угодить очень легко. На этот же раз кюветы будут поглубже, помудрёнее и поспецифичнее. Также будет несколько моментов, связанных с Retrofit 2 & Gson.

Желание выйти на новые рынки с нашим проектом уже долгое время не дает нам покоя – и идеи в наличии, и потенциал неплохой, но, как говорится, все руки не доходили до нормальной реализации.

Сей рассказ пойдет про отрезок нашего пути длиной в два года, который можно смело назвать «спин-оффом» к изначальному циклу статей. Речь о дополнительном проекте, который даже для нас несколько неожиданно совпал открытием с годовщиной «браузерки». Но мы ведь не могли сделать все так, как надо.

Я ничего не смыслю в электронике, никогда не работала с платами и микроконтроллерами, не паяла, но посмотрев The Maker Show, я уже подумываю, а не заказать ли мне Arduino или Raspberry Pi.
Рекомендую это шоу тем, кто только начинает изучать тему Интернета вещей. Для вас я сделала обзор основных выпусков шоу.

1. Введение в электронику

Как заставить светодиод светиться с помощью лимона?

Технологический евангелист Microsoft Дэвид Крук проводит несколько экспериментов, иллюстрирующих основы электроники.

На просторах интернета много отрывочной информации о той или иной ORM для Андроид. Пока что мне не попадалось качественное сравнение ведущих ORM. Существующие статьи попахивают пиаром той или иной системы и ставят в невыгодное положение своих конкурентов либо некорректной постановкой тестирования, либо вообще использованием заведомо неверных настроек, либо не включением в тестирование сильных соперников.

Данное тестирование проведено было скорее для собственного интереса. Т.к. ORM много, все они разные, и хотелось бы иметь объективное представление о существующих системах.

Когда описывают преимущества RxJava, всегда упоминают об удобстве организации работы многопоточного приложения средствами RxJava. То, как использовать операторы subscribeOn и observeOn, можно прочитать практически в каждой статье, посвященной основам RxJava. Например, здесь хорошо описаны случаи, когда использовать методы subscribeOn и когда observeOn. Однако, на практике часто приходится сталкиваться с проблемами, для которых нужно более глубокое понимание того, что именно делают методы subscribeOn и observeOn. В этой статье я хотел бы рассмотреть ряд вопросов, которые иногда возникают при использовании этих операторов.

Развернутый ответ на вопрос, вынесенный в заглавие поста, приводится в статье Брюса Эккеля в редакции от 25 ноября 2015 года. Мы решили разместить здесь перевод этой статьи и поинтересоваться, что вы думаете о функциональном программировании в Java, а также об актуальности такой книги:



Приятного чтения!

Распространенной проблемой является некорректное поведение приложения при повороте девайса. Дело в том что при повороте Activity-host (Activity которое является родителем для фрагмента) уничтожается. В тот момент когда этот процесс происходит FragmentManager отвечает за уничтожение дочернего фрагмента. FragmentManager запускает методы угасающего жизненного цикла фрагмента: onPause(), onStop() и onDestroy().

В случае если в контроллере нашего дочернего фрагмента, к примеру, есть объект Media-Player, то в методе фрагмента Fragment.onDestroy() экземпляр нашего звонко играющего Media-Player-а прервет воспроизведение медиа данных. Первое, что приходит в голову, сохранить состояние объекта Media-Player вызвав Fragment.onSaveInstanceState(Bundle), что сохранит данные, а новое Activity загрузит их. Однако, сохранение состояния объекта MediaPlayer и его последующее восстановление, все равно, прерывает воспроизведение и заставляет акул ненависти сновать в головах пользователей.

Полгода назад за чашечкой кофе программист, режиссер и геймдизайнер вели дружескую беседу на тему того, что кинематограф становится скучным. «Да, спецэффекты становятся круче, количество D становится больше, но этим сейчас малого кого можно удивить. Людей цепляет сюжет. А теперь представьте, что когда-нибудь мы будем смотреть смотреть фильмы, которыми можно управлять?»
— Я бы убил Джона Коннора.
— А я бы не выбросил бузинную палочку и стал плохим волшебником.
— А я бы на месте Поттера воспользовался маховиком времени, чтобы спасти его родителей, а не клювокрыла.



И, как говорится, понеслось…

На прошлой неделе мы спросили Хабражителей интересно ли узнать о технических аспектах создания игры. Сейчас мы готовы представить плоды нашей работы и рассказать с какими трудностями столкнулись, как с ними боролись и какие результаты получили.

И вам даже не понадобятся API из Android N!

Если вы просматривали недавно видеоролик, озаглавленный «Что нового в Android N», то вы, возможно, успели уже задуматься о поддержке мультиоконности.



Мультиоконность будет работать в режиме разбиения экрана, что означает, что два приложения будут находиться на экране одновременно, бок о бок. Чтобы понять, как же работает эта магия, я тут же прошерстил документацию в поисках новых API.

Оказывается, их не так уж и много. Несколько XML атрибутов, указывающих, собираетесь ли вы вообще поддерживать мультиоконность, да несколько методов Activity, позволяющих понять, работает ли ваше приложение сейчас в режиме мультиоконности. И где тут магия? Магия вообще-то была здесь всегда.

Довольно долгое время я никак не мог понять, в чём же разница между «библиотекой» и «фреймворком». Нет-нет, я умел и читать, и гуглить, но до меня всё никак не доходил смысл этих понятий. Начав же программировать под андроид, я наконец понял, что значат слова «библиотеку использует программист, но программиста использует фреймворк».
В этой серии статьей я хочу рассказать о проблемах, с которыми мне пришлось столнулся при разработке под андроид. Моей целью является не предоставление каких-либо убер-решений приведенных проблем, а лишь информирование о том, с какими проблемами может столкнуться тот, кто посягнет на святой грааль Android SDK. Не думаю, что суровые синьоры откроют для себя Америку, но как говорится: «повторение — мать учения».

«Это не была война ученых, это была война в которой каждый принял участие. Ученые, похоронившие свои старые профессиональные разногласия, в угоду общему делу, многое разделили вместе и многому научились. Это было опьяняюще, работать в эффективных партнерских отношениях. Сейчас, для многих, это подходит к концу.
Что ученые будут делать дальше?»



Речь пойдёт об эссе американского инженера Вэнивара Буша «As We May Think», вышедшем в журнале The Atlantic в 1945 году. В нём Буш предсказал наступление информационной эпохи и появление некоторых её проявлений, например, персональных компьютеров, интернета. В статье описывается гипертекст реализованный «в железе».

Эта работа вдохновила и была ориентиром для первопроходцев информационных технологий Джозефа Ликлайдера (компьютерная сеть, разделение времени), Дугласа Энгельбарта (мышка, NLS, GUI, пруф), Теда Нельсона (гипертекст, Xanadu) и пр.

В 1940 году Вэнивар Буш был назначен председателем Национального исследовательского комитета по вопросам обороны США, а с 1941 по 1947 год возглавлял организацию преемника комитета — Бюро научных исследований и развития, занимавшееся координацией усилий научного сообщества (6000 ведущих учёных страны) в целях военной обороны, разработкой ядерного оружия и Манхэттенским проектом.

Биография на Википедии.

• Советник по науке при президенте Рузвельте.
• Инициировал разработку дифференциального анализатора, аналогового компьютера, который мог решать дифференциальные уравнения с 18 независимыми переменными.
• Научный руководитель Клода Шеннона (основатель теории информации) и Фредерика Термана («отец» кремниевой долины).

As We May Think

На Википедии
PDF
Скан самой газеты
Выдержки из статьи (на русском)

Под катом — перевод первой половины статьи.
(за перевод спасибо Алексею Ворсину)

Наше путешествие от стандартных Activity и AsyncTask'ов к современной MVP архитектуре с применением RxJava.

Код проекта должен быть разделён на независимые модули, работающие друг с другом как хорошо смазанный механизм — фото Честера Альвареза.

Экосистема средств разработки под Android развивается очень быстро. Каждую неделю кто-то создаёт новые инструменты, обновляет существующие библиотеки, пишет новые статьи, или выступает с докладами. Если вы уедете в отпуск на месяц, то к моменту вашего возвращения уже будет опубликована свежая версия Support Library и/или Google Play Services.

Я занимаюсь разработкой Android-приложений в компании ribot в течение последних трёх лет, и всё это время и архитектура наших приложений, и используемые нами технологии, постоянно развивались и улучшались. Эта статья проведёт вас путём, пройденным нами, показав вынесенные нами уроки, совершенные нами ошибки, и рассуждения, которые привели ко всем этим архитектурным изменениям.