В предыдущей статье я уже объяснил, что такое ARCore и как он помогает разработчикам создавать удивительные приложения дополненной реальности без необходимости понимания математики и OpenGL.

Если вы ещё не читали её, я настоятельно рекомендую это сделать, прежде чем перейти к этой статье и начать разработку ARCore-приложений.

Источники вдохновения

Этот пост возник благодаря недавней публикации Араса Пранцкевичуса о докладе, предназначенном для программистов-джуниоров. В нём рассказывается о том, как адаптироваться к новым ECS-архитектурам. Арас следует привычной схеме (объяснения ниже): показывает примеры ужасного ООП-кода, а затем демонстрирует, что отличным альтернативным решением является реляционная модель (но называет её «ECS», а не реляционной). Я ни в коем случае не критикую Араса — я большой фанат его работ и хвалю его за отличную презентацию! Я выбрал именно его презентацию вместо сотен других постов про ECS из Интернета потому, что он приложил дополнительные усилия и опубликовал git-репозиторий для изучения параллельно с презентацией. В нём содержится небольшая простая «игра», используемая в качестве примера выбора разных архитектурных решений. Этот небольшой проект позволил мне на конкретном материале продемонстрировать свои замечания, так что спасибо, Арас!

Слайды Араса выложены здесь: http://aras-p.info/texts/files/2018Academy — ECS-DoD.pdf, а код находится на github: https://github.com/aras-p/dod-playground.

Я не буду (пока?) анализировать получившуюся ECS-архитектуру из этого доклада, но сосредоточусь на коде «плохого ООП» (похожего на уловку «чучело») из его начала. Я покажу, как бы он выглядел на самом деле, если бы правильно исправили все нарушения принципов OOD (object-oriented design, объектно-ориентированного проектирования).

Спойлер: устранение всех нарушений OOD приводит к улучшениям производительности, аналогичным преобразованиям Араса в ECS, к тому же использует меньше ОЗУ и требует меньше строк кода, чем ECS-версия!

TL;DR: Прежде чем прийти к выводу, что ООП отстой, а ECS рулит, сделайте паузу и изучите OOD (чтобы знать, как правильно использовать ООП), а также разберитесь в реляционной модели (чтобы знать, как правильно применять ECS).

Введение

В сегодняшние дни есть много разных способов взаимодействия со смартфонами: тач-скрин, аппаратные кнопки, сканер отпечатков пальцев, видео камера (например система распознавания лиц), D-PAD, кнопки на гарнитуре, и так далее. Но что насчет использования жестов движений?

Например быстрое перемещение телефона вправо или влево держа его в руке может очень точно отражать намерение перейти на следующую или предыдущую песню в плей-листе. Или же вы можете быстро перевернуть телефон верх ногами и потом назад для обновления контента приложения. Внедрение такого взаимодействия выглядит многообещающим и буквально добавляет новое измерение в UX. Эта статья описывает как реализовать подобное используя машинное обучение и библиотеку Tensorflow для Android.

Два года назад я начал негласно исполнять роль iOS-lead в компании Touch Instinct и формированием стабильной работы iOS-отдела. Спустя полгода это трансформировалось в официальную должность. Из-за отсутствия опыта у меня возникало огромное количество проблем, которые вызывали жжение в области верхней части кресла. Это происходило из-за ряда факторов:

• Нехватка опыта менеджмента.
• Отсутствие рядом компетентного человека, уже прошедшего путь становления от новой для себя роли к человеку, который понимает устройство процессов, обязанностей и пути решения проблем.
• Нестабильность общих процессов в компании из-за её молодого возраста на тот момент.

Если вы стали лидом и первоначальная эйфория сменилась небольшим горением и унынием, то пара советов не будет лишней.

Меня зовут Аркадий, я Android-разработчик в Badoo. В последнее время в нашем блоге много постов про Go, PHP, JS, QA, и я решил разбавить их темами по мобильной разработке. Как раз занимался портированием одного Android-проекта с RxJava 1 на RxJava 2 и читал всё, что можно найти на эту тему в интернете. В частности, доклад Джейка Вортона с конференции GOTO Copenhagen 2016. Мне показалось, что это достойный кандидат на перевод – думаю, многие Android-разработчики задумываются о переходе на RxJava 2, и им интересно, что изменилось по сравнению с первой версией.

Джейк сделал достаточно объёмное введение о реактивном программировании, так что знание RxJava 1 не требуется для понимания статьи. Доклад был подготовлен, когда RxJava2 ещё только готовилась к выпуску (на текущий момент уже выпущена версия 2.1.0).

В данном материале можно будет увидеть различные инструменты и подсказки, которые здорово облегчают жизнь Android разработчикам. Большая часть собрана напрямую от знакомых разработчиков и содержит вещи, которые должен знать каждый. Дополнения и расширения приветствуются, и если вы знаете о каком-то крутом механизме, который не был упомянут в статье, не поленитесь перейти в оригинал и открыть pull request.

Предлагаю вашему вниманию перевод статьи «Android Project Structure — alternative way». Поблагодарить автора оригинальной статьи можно тут.

Intro

Все мы знаем, как выглядит структура Android проекта – поместить все изображения в этот каталог, все файлы разметки в тот каталог. Но… во время разработки проекта количество файлов растет очень быстро и становится трудно ориентироваться и переходить к нужному файлу.

Структура типичного Android проекта

Сегодня я хочу поделиться с вами моим вольным переводом статьи, написанной Сергеем Повзнером (Sergey Povzner). Сергей ведёт блог bongizmo.com и занимается разработкой туристических гидов под общим названием Citybot.

В то время как Android продолжает свой невероятный рост, всё больше и больше программистов начинают разрабатывать приложения на этой платформе. Если ты начинаешь свой путь сегодня, то ты определенно — счастливчик. За последние годы Android значительно повзрослел и избавился от множества детских болезней. Информации по платформе более чем достаточно. Я же расскажу о самых важных ресурсах.

Статья будет полезна как новичкам, так и опытным разработчикам. Это гид по миру Android-разработки.

При разработке и тестировании какого-либо продукта появляется много рутинной работы. Чтобы избежать ошибок, связанных с человеческим фактором, мы используем AIDA.

AIDA (англ. Automated Interactive Deploy Assistant) — это учётная запись, значительно облегчающая работу с Git, TeamCity и JIRA.
Сегодня речь пойдет о том, как с её помощью нам удалось автоматизировать многие рабочие процессы.

В первую очередь мы вспомним об используемой в Badoo системе контроля версий, далее расскажем о том, как было автоматизировано создание веток релиза и осуществлено автоматическое слияние веток в Git, поговорим о существенной помощи AIDA в работе с JIRA (контроль и изменение статуса задач, заполнение полей) и ТeamCity (непрерывная интеграция и развёртывание на тестовое окружение).

Метапрограммирование — вид программирования, связанный с созданием программ, которые порождают другие программы как результат своей работы (в частности, на стадии компиляции их исходного кода), либо программ, которые меняют себя во время выполнения.

Аннотации, как инструмент метапрограммирования появились вместе с релизом Java 5 в далеком 2004 году. Вместе с ними появился инструментарий Annotation Processing Tool, на смену которому пришла спецификация JSR 269 или Pluggable Annotation Processing API. Что интересно, этой спецификации без малого 10 лет, но свою популярность в Android разработке она начала обретать только сейчас.

О возможностях, которые открывает эта спецификация мы поговорим чуть позже (будет мнооого кода), а сперва, не хотите ли поговорить о компиляции Java кода?

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

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

41. JSONView
jsonview.com



Расширение для Firefox, которое позволяет просматривать JSON в браузере. Документ выглядит отформатированным, есть подсветка и можно сворачивать и раскрывать объекты и массивы.

40. Android GUI Set
www.bypeople.com/free-photoshop-android-interface-gui



Набор интерфейсов, в который входят и файлы для фотошопа. Главное меню, клавиатура, панель статуса, браузер, слайдер, список контактов, и т.д. и т.п.

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

Для начала, вспомним, что такое MVP. MVP — это паттерн, который позволяет «разбивать» приложение на три основных слоя (компонента):

1. Модель (Model) — где сосредоточены данные;
2. Представление (View) — интерфейс приложения (UI — элементы);
3. Presenter — промежуточный компонент, который реализует связь между Моделью и Представлением.

MVP паттерн — это наследник более известного шаблона — MVC. Применение такого подхода позволяет отделить в приложении логику от интерфейса.

Сегодня все больше приложений создается сразу для нескольких мобильных платформ, а приложения, созданные изначально для одной платформы, активно портируются на другие. Теоретически можно полностью писать приложение «с нуля» для каждой платформы (т.е. фактически «кроссплатформенной» оказывается только идея приложения). Но это означает, что трудозатраты на его разработку и развитие будут расти пропорционально количеству поддерживаемых платформ. Если же многоплатформенность изначально заложить в архитектуру приложения, то эти затраты (плюс, в особенности, затраты на поддержку) могут существенно сократиться. Вы разрабатываете общий кроссплатформенный код один раз — значит используете его на текущих (и будущих) платформах. Но в этом случае сразу возникает несколько взаимосвязанных вопросов:

• Должна ли быть граница между общим (кроссплатформенным) и нативным (специфичным для данной платформы) кодом?
• Если да, то где и как провести эту границу?
• Как сделать так, чтобы кроссплатформенный код было удобно использовать на всех платформах, как на тех, что надо поддержать сейчас, так и на тех, чья поддержка, вероятно, может потребоваться в будущем?

Конечно, ответы на эти вопросы зависят от конкретного приложения, предъявляемых к нему требований и накладываемых ограничений, поэтому универсальный ответ найти, по всей видимости, невозможно. В этой статье мы расскажем, как мы искали свои ответы на эти вопросы в процессе разработки мобильного клиента Parallels Access для iOS и Android, какие архитектурные решения были приняты и что в итоге получилось.

Хочу сразу предупредить, что букв в этом посте много, но дробить тему на куски не хотелось. Поэтому запаситесь терпением.

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

Большая часть кода Android приложения работает в контексте компонент, таких как Activity, Service, ContentProvider или BroadcastReceiver. Рассмотрим, как в системе Android организованно взаимодействие этих компонент с потоками.

На сегодняшний день в Google Play насчитывается более 800 тысяч приложений. Многие из них реализованы на основе клиент-серверного общения. При разработке таких приложений нужно учесть три основных момента, о которых пойдет речь в этой статье.

Мы запускаем 5-ую бесплатную школу iOS-разработчиков! Курс предназначен для программистов, имеющих базовое знание языка Swift, ООП. Для занятий необходимо наличие Mac или Win+vmware.



Все, что вам надо сделать — это скачать со страницы школы тестовое задание, выполнить его и прислать нам до 10:00 2 марта. Участники, прошедшие отбор, будут известны не позднее 13 марта.

Обучение бесплатное, занятия будут проходить два раза в неделю в нашем офисе на улице Оптиков, 4. Подробный курс лекций можно посмотреть на сайте школы.

Как вы понимаете, мы имеем самое непосредственное отношение к разработке приложений для Android, ведь именно эта ОС установлена на YotaPhone. И этим постом мы открываем серию публикаций, в которых будем освещать различные аспекты разработки приложений под Android, делиться опытом, как своим, так и других специалистов. Кстати, некоторое время назад мы уже писали об SDK и особенностях архитектуры YotaPhone, что тоже отчасти перекликается с темой данной публикации: полностью разработанная нами SDK построена по принципам, аналогичным стандартной SDK для Android, чтобы дать разработчикам интуитивно понятные инструменты.

Если вы разрабатываете приложения под Android, то вам, скорее всего, нужно где-то хранить данные. Вы можете выбрать один из облачных сервисов (в этом случае удобно пользоваться SyncAdapter) или воспользоваться встроенной SQLite-базой данных. Во втором случае вам придётся выбрать между записью SQL-запросов с помощью Content Provider (если вы планируете использовать данные несколькими приложениями) или ORM.

В этом посте мы рассмотрим некоторые из Android ORM, которые вы можете использовать в своих приложениях.

Настало время переходить на Lollipop, друзья. Как бы смешно это не звучало.



Буквально вчера мы в Surfingbird обновили дизайн приложения и сегодня, по свежим следам, хотелось бы поделиться впечатлениями от перехода на material design.

Привет!

На хабре ещё не была освещена тема Transitions API для анимаций, которые появились в Android начиная с 4.4 (KitKat) и продолжили свое развитие в 5.0 (Lollipop). В своей статье я расскажу о том, как упростить работу с анимациями с их использованием и как применять их на любом устройстве с версией Android 4.0 и выше.