Меня зовут Кирилл, я Android-разработчик. Сейчас я уже привык к тому, что живу и работаю в Лондоне, но год назад и представить себе такого не мог. В этой статье я расскажу, как мне выпал шанс устроиться в международную компанию, о чём спрашивали на интервью, какие этапы нужно пройти, чтобы уехать в Великобританию с семьёй и собаками, и какой он, Лондон.
В прошлую субботу, 17 июня, мы снова проводили митап в офисе. На этот раз принимали Android-сообщество. Эта встреча, вероятно, была самой разнообразной по темам докладов, поэтому каждый интересующийся найдет что-то для себя.
Как уже знают все Android-разработчики, Google недавно объявила об официальной поддержке Kotlin в Android. Многие риски, связанные с использованием этого замечательного языка в Android-проектах, сняты. Но актуальным, особенно для очень крупных проектов, каким является Badoo, остаётся вопрос о скорости сборки. Я был рад обнаружить, что в сети уже есть исследования на эту тему, и переводом одного из них хочу поделиться.
Итак, если вы переводите приложение с Java на Kotlin, будет ли оно компилироваться дольше?
Меня зовут Аркадий, я Android-разработчик в Badoo. В последнее время в нашем блоге много постов про Go, PHP, JS, QA, и я решил разбавить их темами по мобильной разработке. Как раз занимался портированием одного Android-проекта с RxJava 1 на RxJava 2 и читал всё, что можно найти на эту тему в интернете. В частности, доклад Джейка Вортона с конференции GOTO Copenhagen 2016. Мне показалось, что это достойный кандидат на перевод – думаю, многие Android-разработчики задумываются о переходе на RxJava 2, и им интересно, что изменилось по сравнению с первой версией.
Джейк сделал достаточно объёмное введение о реактивном программировании, так что знание RxJava 1 не требуется для понимания статьи. Доклад был подготовлен, когда RxJava2 ещё только готовилась к выпуску (на текущий момент уже выпущена версия 2.1.0).
Badoo — это прежде всего социальная сеть с удобным полнофункциональным чатом. Однако сами требования к такому чату постоянно растут. Разработчики популярных приложений для сетевого общения все время добавляют новые функции, чтобы угодить пользователям и выстоять в конкурентной борьбе.
Разумеется, Badoo не остается в стороне от этих тенденций. Мы постоянно совершенствуем свой чат и расширяем его функциональность, но возможности существующей кодовой базы и архитектуры едва успевают за требованиями современности. Некогда упорядоченный и хорошо протестированный код разрастается непредсказуемым образом, накапливая «технический долг». Анализируя пути решения этой проблемы, мы столкнулись с дилеммой, которая знакома любому разработчику: переписать код или сделать рефакторинг?
В нашем документе может существовать множество таблиц. В таблицах есть колонки, строки, ячейки, и над каждым из этих элементов могут производиться операции вставки, удаления, перемещения и редактирования. В результате некоторых таких операций возникает необходимость пересчета формул. Изюминкой нашего редактора является то, что мы можем пересчитывать только те формулы, которые действительно нужно пересчитать. То есть формулы, значение которых могло измениться. Таким образом мы повышаем эффективность при редактировании больших документов, а также избегаем ситуаций, когда значение ячейки, содержащей, например, функцию RAND, изменяется при каждом редактировании документа.
К офисным приложениям правило Парето применимо в следующем виде: 80% пользователей используют для решения своих задач только 20% представленных функций. В проекте МойОфис мы сосредоточились на реализации самых необходимых из них, чтобы повысить продуктивность работы большинства офисных сотрудников. На это влияет не только оптимальное количество функций, но и то, как они представлены в интерфейсе.
Сегодня мы расскажем, как работаем над дизайном приложений МойОфис: как выстраиваем процесс, какие инструменты используем и как проверяем результаты своей работы.
Пользователь не любит тратить время, пользователь не любит переписывать текст. Пользователь хочет копипастить. И хочет делать это даже в приложении на мобильном устройстве. И хочет, чтобы эта функция была удобной для работы пальцем на небольшом экране. Производители операционных систем по-разному реализуют эту функцию, стараясь угодить пользователям. Не отстают и разработчики приложений.
Нас тоже не обошла стороной эта тема, и в одном из приложений нам пришлось потрудиться, чтобы сделать как можно более удобную функцию выделения и копирования текста. Секретом этого рецепта мы и хотим поделиться с общественностью.
В данной статье я хотел бы вкратце рассказать про самые последние best practices от Google. Я постарался выделить самые основные моменты, чтобы читатель сразу мог понять, что именно какая-либо фича дает разработчику. Не удивляйтесь, если где-то повторяюсь. Конспектировал + добавлял от себя по ходу просмотров видео в www.youtube.com/channel/UCVHFbqXqoYvEWM1Ddxl0QDg
Также к каждому пункту приводятся все необходимые ссылки для более подробного ознакомления с конкретной best practice.
Работая над Square Register, мы рисуем подпись клиента используя битмап-кеш. Поскольку этот битмап размером с экран устройства, у нас было очень много OutOfMemory крешей во время создания его.
Мы пробовали несколько подходов ни один из которых не решил проблему:
Использовали Bitmap.Config.ALPHA_8
Ловили OutOfMemoryError, вызывали сборку мусора и пробовали снова (подглядели в GCUtils),
Мы не рассматривали вариант с размещением битмапов вне кучи Java. К счастью Fresco еще не существовало,
Первое, что я хочу сказать: статья не претендует на сильно глубокий уровень, скорее я хочу рассказать о том, что производительность это не только «быстрее с NDK на С++» и «экономьте память, а то сборка мусора будет часто запускаться», а это целый комплекс мер, потому что проблемы с производительностью возникают не когда одна функция медленно работает, а в комплексе.
Не было ли у вас ощущения, что приложение тормозит, а вы уже не знаете что делать — и память вроде не жрет, и профайлером уже посмотрели, а решения все нет. Если да, то эти заметки для вас.
Понятия и термины я переводить не буду, так как я думаю что почти все разработчики их не переводят.
На хабре ещё не была освещена тема Transitions API для анимаций, которые появились в Android начиная с 4.4 (KitKat) и продолжили свое развитие в 5.0 (Lollipop). В своей статье я расскажу о том, как упростить работу с анимациями с их использованием и как применять их на любом устройстве с версией Android 4.0 и выше.
Пятая версия Android была выпущена почти полгода назад. Несмотря на это, большинство приложений в маркете до сих пор упорствуют в стиле Holo. То ли новый Material-стиль пока не по зубам среднему разработчику, то ли Android L еще не успел прочно войти в обыденность.
Как бы там ни было, новая парадигма дизайна активно пропагандируется «корпорацией добра», да и выглядит достаточно неплохо, несмотря на некоторую непоследовательность. И все больше появляется добрых волшебников, помогающих нам, простым разработчикам, оставаться «в струе» изменчивого мира мобильного UI.
Если вы, как я недавно, твердо решили обернуть своё, давно не обновлявшееся, приложение в новую «шкурку», этот обзор инструментов и библиотек может сэкономить вам N часов времени.
Работая с Android часто можно видеть, как весь функциональный код помещается в методы жизненного цикла activity/fragment. В общем-то такой подход имеет некоторое обоснование — «методы жизненного цикла» всего лишь хэндлеры, обрабатывающие этапы создания компонента системой и специально предназначенные для наполнения их кодом. Добавив сюда то, что каркас UI описывается через xml файлы, мы уже получаем базовое разделение логики и интерфейса. Однако из-за не совсем «изящной» структуры жизненного цикла, его зависимости от множества флагов запуска, и различной (хоть и похожей) структуры для разных компонентов, эффективно воспользоваться подобным разделением не всегда бывает возможно, что в итоге выливается в написании всего кода в onCreate().
Для тех, кто не сталкивался с этой проблемой, поясню на примере — в конце длительной фоновой операции вы показываете диалог (да Google не рекомендует так делать, но заказчик требует). Если до показа диалога вы свернете приложение нажав клавишу Home, то во время показа диалога произойдет исключение IllegalStateException. То же самое произойдет в случае показа диалога ожидания и скрытия его по завершению фоновой активности — вызов метода dismiss() после сохранения состояния вызовет исключение.
Лучшая статья на эту тему, которую я нашел погуглив проблему это Fragment Transactions & Activity State Loss. Статья объясняет проблему, но дает только общие советы, сама проблема остается нерешенной. Возможно кому-то из хабражителей будет интересно сделать перевод статьи, а пока расскажу вкратце ее смысл. Система Android обладает возможностью завершить любую активность вашего приложения и ее фрагменты при нехватке памяти. Чтобы скрыть от пользователя этот прискорбный факт, Android сохраняет состояние активности и восстанавливает его при необходимости, так что пользователь даже не замечает какие катаклизмы происходили на уровне кода. Когда вы пытаетесь отобразить диалог после сохранения состояния, по сути вы нарушаете сохраненное состояние и такая активность не может быть восстановлена. Android решает это простейшим для себя способом — выкидывает исключение и не позволяет закомитить транзакцию фрагментов. А ваше приложение просто крашится.
В этой статье для начинающих android-разработчиков я постараюсь рассказать о том, что такое «утечки памяти» в android, почему о них стоит думать на современных устройствах, выделяющих по 192МБ на приложение, как быстро найти и устранить эти утечки в малознакомом приложении и на что нужно обращать особое внимание при разработке любого приложения.
Конечная цель этой статьи — ответ на простой вопрос: Куда нажать, чтобы узнать, какую строчку в приложении поправить?
