Результаты первого месяца
#эксперимент
Пора описать результат первого месяца эксперимента.
Сейчас мы изучили компоненты Clean Architecture. Снова рекомендую для изучения замечательный кукбук. Там можно найти всю информацию для того, чтобы правильно писать приложение.
Мы стараемся придерживаться той стрктуры пакетов, что описана там.
Больше всего сложностей при разработке возникло понимание, что такое View. Точнее, как верно инициализировать. По сути View — элемент архитектуры, которая не должен отвечать за данные, а только получать их, а также передавать реакцию пользователя с экрана. Это интерфейс, который имплементит Activity, Fragment или другие компоненты, отвечающие за вывод информации. Ну и о ней всегда знает только Presenter.
Для взаимодействия между View и Presenter, а также правильным управлением жизненным циклом, рекомендую использовать библиотеку Moxy. Она избавит вас от управления поворотами экрана и другой нудной работы. Думаю, что к ней стоит переходить, когда есть понимание, за что отвечает каждый компонент архитектуры.
Сейчас также выполняется авторизация пользоваться через Firebase. Обернуто это через RxJava 2, что, кстати, получилось быстро. Но это только начало работы с этой огромной библиотекой, поэтому ещё будет много нюансов.
Первая и достаточно распространенная проблема — выполнение длительных операций в main thread. У вас не получится сделать это для получения данных из сети, но Firebase это успешно выполняет. Правильно всегда делать длительные операции в другом потоке. Отличный гайд про потоки в Rx тут.
Из небольших проблем могу выделить дизайн. Пока этот пункт остается открытым, поэтому мы еще не касались верстки.
В общем, разработка проекта идет, и вскоре я дам ссылку на репозиторий, где каждый сможет посмотреть текущий прогресс.
#эксперимент
Пора описать результат первого месяца эксперимента.
Сейчас мы изучили компоненты Clean Architecture. Снова рекомендую для изучения замечательный кукбук. Там можно найти всю информацию для того, чтобы правильно писать приложение.
Мы стараемся придерживаться той стрктуры пакетов, что описана там.
Больше всего сложностей при разработке возникло понимание, что такое View. Точнее, как верно инициализировать. По сути View — элемент архитектуры, которая не должен отвечать за данные, а только получать их, а также передавать реакцию пользователя с экрана. Это интерфейс, который имплементит Activity, Fragment или другие компоненты, отвечающие за вывод информации. Ну и о ней всегда знает только Presenter.
Для взаимодействия между View и Presenter, а также правильным управлением жизненным циклом, рекомендую использовать библиотеку Moxy. Она избавит вас от управления поворотами экрана и другой нудной работы. Думаю, что к ней стоит переходить, когда есть понимание, за что отвечает каждый компонент архитектуры.
Сейчас также выполняется авторизация пользоваться через Firebase. Обернуто это через RxJava 2, что, кстати, получилось быстро. Но это только начало работы с этой огромной библиотекой, поэтому ещё будет много нюансов.
Первая и достаточно распространенная проблема — выполнение длительных операций в main thread. У вас не получится сделать это для получения данных из сети, но Firebase это успешно выполняет. Правильно всегда делать длительные операции в другом потоке. Отличный гайд про потоки в Rx тут.
Из небольших проблем могу выделить дизайн. Пока этот пункт остается открытым, поэтому мы еще не касались верстки.
В общем, разработка проекта идет, и вскоре я дам ссылку на репозиторий, где каждый сможет посмотреть текущий прогресс.
Android Resource Usage Count
#плагин
Как только проект становится большим, то появляются ресурсы, которые не используются, но по-прежнему остаются в проекте.
В итоге эти ресурсы засоряют проект, но удалить их сразу не так просто: если использовать встроенный инструмент для рефакторинга, то он удалит неиспользуемые ресурсы. Однако, он оставит их, если они используются хотя бы один раз.
Предположим, что у нас один и второй разработчик добавил красный цвет. Достаточно одного красного, но оставаться в проекте будет несколько.
Чтобы упростить рефакторинг ресурсов, существует отличный плагин: Android Resource Usage Count. Он автоматически подсчитывает количество использования ресурсов и добавляет их количество слева. Если цвет не используется, то число помечается серым, если один раз — синим, и если несколько, то красным.
В итоге стоит задуматься: надо ли вам засорять приложение ресурсами, которые используются один раз?
На мой взгляд плагин работает хорошо, хоть иногда и не справляется с большим количеством строк. К установке рекомендую.
#плагин
Как только проект становится большим, то появляются ресурсы, которые не используются, но по-прежнему остаются в проекте.
В итоге эти ресурсы засоряют проект, но удалить их сразу не так просто: если использовать встроенный инструмент для рефакторинга, то он удалит неиспользуемые ресурсы. Однако, он оставит их, если они используются хотя бы один раз.
Предположим, что у нас один и второй разработчик добавил красный цвет. Достаточно одного красного, но оставаться в проекте будет несколько.
Чтобы упростить рефакторинг ресурсов, существует отличный плагин: Android Resource Usage Count. Он автоматически подсчитывает количество использования ресурсов и добавляет их количество слева. Если цвет не используется, то число помечается серым, если один раз — синим, и если несколько, то красным.
В итоге стоит задуматься: надо ли вам засорять приложение ресурсами, которые используются один раз?
На мой взгляд плагин работает хорошо, хоть иногда и не справляется с большим количеством строк. К установке рекомендую.
Какой интерфейс лучше?
#думы #дизайн
Если мы обратимся к Википедии, то найдем следующее определение интерфейса:
Интерфейс — «общая граница» между отдельными системами, через которую они взаимодействуют; совокупность средств и правил, обеспечивающих взаимодействие отдельных систем.
Если говорить простыми словами, то это прослойка, которая позволяет взаимодействовать разным системам. Возникает вопрос: какой интерфейс лучше всего?
Недавно прочитал статью, в которой рассказывали о книге Генриха Альтшуллера «Найти идею. Введение в ТРИЗ - теорию решения изобретательских задач». Автор доказал, что процесс изобретательства и творчества управляем и подвергается определенным законам.
Одним из тезисов, который там есть говорит о том, что технический объект идеален, когда его нет, но необходимая функция выполняется.
Если мы применим это определение к интерфейсу, то идеальный интерфейс — это такой, которого нет (или его не замечают), но он помогает дойти до нужной цели.
Например, недавний магазин Amazon, который работает без касс. Покупатель сам выбирает себе товары, кладет их в корзину и уходит с магазина. Деньги автоматически списываются с его счёта.
А что будет идеальным интерфейсом в мобильных приложениях?
Думаю, что сейчас можно только приблизиться к нему. Идеальным он станет тогда, когда человек сможет управлять телефоном, например, при помощи мысли.
Если говорить о приближенных к идеальным интерфейсам, то я вижу Google Play Music. На рабочий стол можно добавить виджет «Мне повезет», который позволит включить музыку за один клик. Кстати, голосовые помощники тоже делают интерфейс приближенным к идеальным.
Помните, что создавать сложно — легко. А сделать, чтобы было легко — дико сложно.
#думы #дизайн
Если мы обратимся к Википедии, то найдем следующее определение интерфейса:
Интерфейс — «общая граница» между отдельными системами, через которую они взаимодействуют; совокупность средств и правил, обеспечивающих взаимодействие отдельных систем.
Если говорить простыми словами, то это прослойка, которая позволяет взаимодействовать разным системам. Возникает вопрос: какой интерфейс лучше всего?
Недавно прочитал статью, в которой рассказывали о книге Генриха Альтшуллера «Найти идею. Введение в ТРИЗ - теорию решения изобретательских задач». Автор доказал, что процесс изобретательства и творчества управляем и подвергается определенным законам.
Одним из тезисов, который там есть говорит о том, что технический объект идеален, когда его нет, но необходимая функция выполняется.
Если мы применим это определение к интерфейсу, то идеальный интерфейс — это такой, которого нет (или его не замечают), но он помогает дойти до нужной цели.
Например, недавний магазин Amazon, который работает без касс. Покупатель сам выбирает себе товары, кладет их в корзину и уходит с магазина. Деньги автоматически списываются с его счёта.
А что будет идеальным интерфейсом в мобильных приложениях?
Думаю, что сейчас можно только приблизиться к нему. Идеальным он станет тогда, когда человек сможет управлять телефоном, например, при помощи мысли.
Если говорить о приближенных к идеальным интерфейсам, то я вижу Google Play Music. На рабочий стол можно добавить виджет «Мне повезет», который позволит включить музыку за один клик. Кстати, голосовые помощники тоже делают интерфейс приближенным к идеальным.
Помните, что создавать сложно — легко. А сделать, чтобы было легко — дико сложно.
Как создать красивые анимации?
#дизайн #статьи
Уже не раз на этом канале упоминалось то, что в современных приложениях важны анимации. Без них приложение теряет живость и отзывчивость, ну и, конечно, красоту.
Недавно на глаза попались статьи, авторы которых дизайнеры.
В первой статье говорится об анимациях движения. Любое приложение состоит из многих двигающихся элементов, поэтому важно сделать их максимально плавными. Давая кучу примеров, автор говорит о принципах построения таких анимаций. Раньше не задумывался о том, что анимации подвержены определенным законам.
Во второй статье автор сравнивает хорошие и отличные анимации. О том, как сделать переходы между экранами, открытие списков и показ всплывающих меню идеальными, вы прочитаете в этой статье.
Эти две статьи сделаны без привязки к операционной системе. Так что эти принципы можно использовать для создания прекрасных интерфейсов не только на Android.
#дизайн #статьи
Уже не раз на этом канале упоминалось то, что в современных приложениях важны анимации. Без них приложение теряет живость и отзывчивость, ну и, конечно, красоту.
Недавно на глаза попались статьи, авторы которых дизайнеры.
В первой статье говорится об анимациях движения. Любое приложение состоит из многих двигающихся элементов, поэтому важно сделать их максимально плавными. Давая кучу примеров, автор говорит о принципах построения таких анимаций. Раньше не задумывался о том, что анимации подвержены определенным законам.
Во второй статье автор сравнивает хорошие и отличные анимации. О том, как сделать переходы между экранами, открытие списков и показ всплывающих меню идеальными, вы прочитаете в этой статье.
Эти две статьи сделаны без привязки к операционной системе. Так что эти принципы можно использовать для создания прекрасных интерфейсов не только на Android.
Новый топ статей из Medium.
#статьи #medium
1) Модули, модули повсюду. — (8 минут)
В последнее время часто попадаются статьи, где описывается модульная архитектура. Такой подход значительно увеличивает скорость сборки приложения и делает простым повторное использование компонентов. Автор делится опытом о рефакторинге приложения в сторону модульной архитектуры.
2) Flutter: Routes and Navigation. — (6 минут)
Сейчас у сообщества на слуху Flutter. Уверен, что вы слышали об этом фреймворке, который позволяет писать кроссплатформенные приложения. Есть много статей о написании приложений, и эта статья поможет вам написать простое приложение на Flutter, что позволит больше вникнуть в разработку на нем.
3) Анатомия аналитики от Google. — (20 минут)
Для того, чтобы делать продукт лучше, придумано много инструментов для аналитики. Одним из самых популярных инструментов для аналитики является Firebase и Google Analytics. В статье автор делится подробным описанием этого инструмента. Возможно, вы используете не всю мощь Firebase. Для себя узнал о BigQuery.
#статьи #medium
1) Модули, модули повсюду. — (8 минут)
В последнее время часто попадаются статьи, где описывается модульная архитектура. Такой подход значительно увеличивает скорость сборки приложения и делает простым повторное использование компонентов. Автор делится опытом о рефакторинге приложения в сторону модульной архитектуры.
2) Flutter: Routes and Navigation. — (6 минут)
Сейчас у сообщества на слуху Flutter. Уверен, что вы слышали об этом фреймворке, который позволяет писать кроссплатформенные приложения. Есть много статей о написании приложений, и эта статья поможет вам написать простое приложение на Flutter, что позволит больше вникнуть в разработку на нем.
3) Анатомия аналитики от Google. — (20 минут)
Для того, чтобы делать продукт лучше, придумано много инструментов для аналитики. Одним из самых популярных инструментов для аналитики является Firebase и Google Analytics. В статье автор делится подробным описанием этого инструмента. Возможно, вы используете не всю мощь Firebase. Для себя узнал о BigQuery.
Управление проектом
#эксперимент
В рамках нашего эксперимента хочу поделиться сервисом, который мы используем для работы в нашей небольшой команде. Это сервис Trello.
Весь интерфейс Trello выстроен на основе канбан-досок. На самом деле за непонятным названием скрывается логичная и простая доска с карточками, где есть несколько колонок. В нашем случае их 4: нужно сделать, в процессе, готово и проверено.
Trello очень полезный сервис для построения проектов в небольших командах. Для удобства есть мобильное приложение и куча возможностей форматирования как в задачах, так и в комментариях.
Единственным существенным недостатком является отсутствие спринтов. В альтернативах, например, в Jira и YouTrack есть такая возможность. Сейчас те задачи, которые выполнены и проверены отправляются в архив. Возможно, в будущем мы перейдем на альтернативу, но пока возможностей Trello достаточно.
Кстати, если вы хотите следить за нашим прогрессом, то вот наша доска.
Как всегда, я рад ответить на ваши вопросы.
А каким сервисом вы пользуетесь для управления проектами у себя в команде?
⚪️ — Trello;
⚫️ — Jira;
🔴 — YouTrack;
🔵 — другие.
#эксперимент
В рамках нашего эксперимента хочу поделиться сервисом, который мы используем для работы в нашей небольшой команде. Это сервис Trello.
Весь интерфейс Trello выстроен на основе канбан-досок. На самом деле за непонятным названием скрывается логичная и простая доска с карточками, где есть несколько колонок. В нашем случае их 4: нужно сделать, в процессе, готово и проверено.
Trello очень полезный сервис для построения проектов в небольших командах. Для удобства есть мобильное приложение и куча возможностей форматирования как в задачах, так и в комментариях.
Единственным существенным недостатком является отсутствие спринтов. В альтернативах, например, в Jira и YouTrack есть такая возможность. Сейчас те задачи, которые выполнены и проверены отправляются в архив. Возможно, в будущем мы перейдем на альтернативу, но пока возможностей Trello достаточно.
Кстати, если вы хотите следить за нашим прогрессом, то вот наша доска.
Как всегда, я рад ответить на ваши вопросы.
А каким сервисом вы пользуетесь для управления проектами у себя в команде?
⚪️ — Trello;
⚫️ — Jira;
🔴 — YouTrack;
🔵 — другие.
Stream API в Android
#советы #разработка
С недавних пор одной из моих любимых библиотек стала Lightweight Stream API. Она позволяет использовать возможности Stream API на Java 6 и 7, причем добавляет несколько новых фукнций. Библиотеку можно найти тут.
В чем же удобство Stream при разработке? Для себя я выделил несколько моментов:
1) Обработка null, используя
2) Иная обработка списков. Теперь можно использовать
3) Работа с
Ну и напоследок кусок кода, который мне очень нравится. Когда идет написание кастомной View и добавление атрибутов к ней, то появляется код, который выглядит не экстетично. Заменив всё на Stream API получим такую красоту.
Исходный код
#советы #разработка
С недавних пор одной из моих любимых библиотек стала Lightweight Stream API. Она позволяет использовать возможности Stream API на Java 6 и 7, причем добавляет несколько новых фукнций. Библиотеку можно найти тут.
В чем же удобство Stream при разработке? Для себя я выделил несколько моментов:
1) Обработка null, используя
Optional. Теперь можно уйти от проверки на null в большинстве объектов. Для этого надо воспользоваться функцией Optional.ofNullable()2) Иная обработка списков. Теперь можно использовать
Stream для работы со списком. После этого доступна куча операторов, которые вы можете найти по ссылке выше. В результате получаем изящную цепочку из операторов. 3) Работа с
Throwable. Теперь можно заменить try/catch на отдельный оператор, который легко включается в цепочку вызовов. Ну и напоследок кусок кода, который мне очень нравится. Когда идет написание кастомной View и добавление атрибутов к ней, то появляется код, который выглядит не экстетично. Заменив всё на Stream API получим такую красоту.
Исходный код
AttributeLoader тут.Меня удивили результаты опроса про средства для управления проектом. Думал, что за вариант «другие» проголосует небольшое число подписчиков.
Хочется сделать обзор того, чем пользуются разработчики в работе. Google отдает огромное количество средств для управления проектами, однако хотелось бы узнать, что конкретно используется в работе и почему.
Обязательно опишу результаты тут, а вот форма для ответов.
Хочется сделать обзор того, чем пользуются разработчики в работе. Google отдает огромное количество средств для управления проектами, однако хотелось бы узнать, что конкретно используется в работе и почему.
Обязательно опишу результаты тут, а вот форма для ответов.
Эзотерические языки программирования
#разработка
В мире разработки существует такой понятие как эзотерический язык программирования.
При создании такого языка программирования целью является не создание языка с простым и понятных синтаксисом, а наоборот: синтаксис или вообще не понятен, или понятен узкому кругу людей.
Благо, на таких языках не пишут серъезных программ, но они часто используются во всяких конкурсах и викторинах. Их огромное количество, но я расскажу про 2 из них:
1) Brainfuck — эзотерический язык программирования, где исходный код программы представляет собой последовательность этих символов без какого-либо дополнительного синтаксиса. Подробнее можно почитать тут. С этим языком программирования я встретился во время выполнения квеста от MBLT. В общем-то существуют интерпретаторы онлайн, которые без труда позволят вам выполнить программу на этом языке.
2) Malbolge — язык программирования, цель которого следать процесс написания программ максимально сложным. Для многих людей программирование является написание каких-то непонятных знаков. Подумал, что было бы забавно, если бы они увидели Malbolge. Подробнее можно почитать тут. Кстати, своё название этот язык получил от Malebolge, восьмого круга ада Данте.
Очень радует, что у нас есть высокоуровневые языки программирования, которые используются повсеместно.
Теперь, вы можете показать исходный код на этом языке кому-нибудь из знакомых, если они скажут, что на Java непонятный код.
#разработка
В мире разработки существует такой понятие как эзотерический язык программирования.
При создании такого языка программирования целью является не создание языка с простым и понятных синтаксисом, а наоборот: синтаксис или вообще не понятен, или понятен узкому кругу людей.
Благо, на таких языках не пишут серъезных программ, но они часто используются во всяких конкурсах и викторинах. Их огромное количество, но я расскажу про 2 из них:
1) Brainfuck — эзотерический язык программирования, где исходный код программы представляет собой последовательность этих символов без какого-либо дополнительного синтаксиса. Подробнее можно почитать тут. С этим языком программирования я встретился во время выполнения квеста от MBLT. В общем-то существуют интерпретаторы онлайн, которые без труда позволят вам выполнить программу на этом языке.
2) Malbolge — язык программирования, цель которого следать процесс написания программ максимально сложным. Для многих людей программирование является написание каких-то непонятных знаков. Подумал, что было бы забавно, если бы они увидели Malbolge. Подробнее можно почитать тут. Кстати, своё название этот язык получил от Malebolge, восьмого круга ада Данте.
Очень радует, что у нас есть высокоуровневые языки программирования, которые используются повсеместно.
Теперь, вы можете показать исходный код на этом языке кому-нибудь из знакомых, если они скажут, что на Java непонятный код.
Результаты опроса про средства для управления проектом
Большое спасибо всем, кто принял участие в опросе. О некоторых средствах я ни разу не слышал.
Больше всего упоминаний получила распространенная Jira.
Она имеет большое количество функций, много средств для отчетов и приятный интерфейс. Думаю, что во многих компаниях используется именно она.
Из недостатков могу выделить отсутствие бесплатной версии даже для персонального использования. Хотя очень часто за качество приходится платить.
Вторым по популярности оказался сервис Redmine. Мне не приходилось много работать с ним, однако в одной из команд, где я работал, эта среда использовалась для хранения небольшой документации. Она бесплатная и opensource.
Следующим сервисом является любимый мной Trello. Он имеет удобный и понятный интерфейс, простую настройку и работу с командой. Мне очень нравится форматирование текста, которое добавляется в комментарии и при создании запросов. Для меня недостатком является отсутствие спринтов.
Одинаковое число голосов набрали Asana, WorkSection, GitLab и TFS. С этими сервисами не работал, хотя отвечающие отмечали их, как хорошо работающие продукты и альтернатива Jira.
Большое спасибо всем, кто принял участие в опросе. О некоторых средствах я ни разу не слышал.
Больше всего упоминаний получила распространенная Jira.
Она имеет большое количество функций, много средств для отчетов и приятный интерфейс. Думаю, что во многих компаниях используется именно она.
Из недостатков могу выделить отсутствие бесплатной версии даже для персонального использования. Хотя очень часто за качество приходится платить.
Вторым по популярности оказался сервис Redmine. Мне не приходилось много работать с ним, однако в одной из команд, где я работал, эта среда использовалась для хранения небольшой документации. Она бесплатная и opensource.
Следующим сервисом является любимый мной Trello. Он имеет удобный и понятный интерфейс, простую настройку и работу с командой. Мне очень нравится форматирование текста, которое добавляется в комментарии и при создании запросов. Для меня недостатком является отсутствие спринтов.
Одинаковое число голосов набрали Asana, WorkSection, GitLab и TFS. С этими сервисами не работал, хотя отвечающие отмечали их, как хорошо работающие продукты и альтернатива Jira.
Варианты использования векторных картинок
#разработка #библиотеки
Недавно рефакторил один проект, в котором было около 200 однотипных ресурсов: это небольшие изображения, которые сделаны ещё в png формате. Эти изображения не занимали много места, но при этом просто засоряли проект.
Решил заменить их на аналогичные векторные ресурсы. Расскажу как это происходило, и, возможно, мой опыт пригодится и вам.
Для быстрой конвертации noscript-файлов в xml, рекомендую использовать этот плагин. Он позволит пакетно обработать целую папку файлов. Если же вам нужно обработать только один файл, то есть такая же web-версия.
К сожалению, в Android не существует возможности создавать xml-ресурс во время работы приложения. Но есть альтернативный вариант: использование noscript-изображений напрямую с сервера.
Для этого рекомендую подготовить изображение. На самом деле, в noscript может содержаться много лишней информации, которая не нужна для показа изображения: информация о версии noscript, лишние тэги и комментарии. Чтобы очистить изображение от мусора, рекомендую использовать SVG Optimizer. Одна из версий тут. В моем случае размер изображений уменьшился в среднем на 40%.
Для беспроблемной загрузки изображений мне пригодилась библиотека Glide. А чтобы подружить её с загрузкой noscript-файлов рекомендую использовать SvgGlidePlugins. Плагин очень свежий, но работает замечательно. Кстати, разработчик оперативно поправил те недочеты, которые я нашёл в начале работы с плагином.
Впоследствии, из проекта ушло огромное число ненужных ресурсов, а также появилась возможность динамического обновления их на сервере. Так что использование noscript в Android приложениях — отличная идея.
#разработка #библиотеки
Недавно рефакторил один проект, в котором было около 200 однотипных ресурсов: это небольшие изображения, которые сделаны ещё в png формате. Эти изображения не занимали много места, но при этом просто засоряли проект.
Решил заменить их на аналогичные векторные ресурсы. Расскажу как это происходило, и, возможно, мой опыт пригодится и вам.
Для быстрой конвертации noscript-файлов в xml, рекомендую использовать этот плагин. Он позволит пакетно обработать целую папку файлов. Если же вам нужно обработать только один файл, то есть такая же web-версия.
К сожалению, в Android не существует возможности создавать xml-ресурс во время работы приложения. Но есть альтернативный вариант: использование noscript-изображений напрямую с сервера.
Для этого рекомендую подготовить изображение. На самом деле, в noscript может содержаться много лишней информации, которая не нужна для показа изображения: информация о версии noscript, лишние тэги и комментарии. Чтобы очистить изображение от мусора, рекомендую использовать SVG Optimizer. Одна из версий тут. В моем случае размер изображений уменьшился в среднем на 40%.
Для беспроблемной загрузки изображений мне пригодилась библиотека Glide. А чтобы подружить её с загрузкой noscript-файлов рекомендую использовать SvgGlidePlugins. Плагин очень свежий, но работает замечательно. Кстати, разработчик оперативно поправил те недочеты, которые я нашёл в начале работы с плагином.
Впоследствии, из проекта ушло огромное число ненужных ресурсов, а также появилась возможность динамического обновления их на сервере. Так что использование noscript в Android приложениях — отличная идея.
Дизайн приложения
#эксперимент
Я убежден, что каждый человек должен заниматься своим делом. Программист пишет код и является создателем программы. Дизайнер — рисует удобный и притягивающий дизайн. Если кто-то занимается не своим, то получается не самый лучший продукт.
В нашем эксперименте получилась аналогичная ситуация. Тот дизайн, что был предложен учеником не укладывался в принципы Material-дизайна. Выглядел так же не аккуратно. Но сейчас вопрос с ним решился.
В сообщении прикреплен экран регистрации для нашего приложения. Как только будет окончен дизайн всего проекта, то обязательно покажу макеты.
Как вам дизайн?
#эксперимент
Я убежден, что каждый человек должен заниматься своим делом. Программист пишет код и является создателем программы. Дизайнер — рисует удобный и притягивающий дизайн. Если кто-то занимается не своим, то получается не самый лучший продукт.
В нашем эксперименте получилась аналогичная ситуация. Тот дизайн, что был предложен учеником не укладывался в принципы Material-дизайна. Выглядел так же не аккуратно. Но сейчас вопрос с ним решился.
В сообщении прикреплен экран регистрации для нашего приложения. Как только будет окончен дизайн всего проекта, то обязательно покажу макеты.
Как вам дизайн?
Сегодня посмотрел интересное, немного с ностальгией видео про смартфон Nexus 5 и планшет Nexus 7. Я не фанат планшета, поэтому поделюсь, что думаю о телефоне.
Помню, что когда первый раз взял этот смартфон, то удивлялся, насколько он хорошо лежит в руке. Особенно нравился красно-оранжевый Nexus 5, который сильно выделялся на фоне всех остальных.
Если вкратце по видео, то:
• можно установить свежий Android Oreo. Кстати, этот аргумент применим в споре с любителями iPhone;
• средняя автономность. Часто нужно менять аккумулятор, стоимость замены около 1000 рублей;
• хороший дисплей и неплохой процессор. Топовые игры немного тормозят, но остальные — вполне комфортно и без лагов;
• комфортная основная камера. Снимает сносно, на уровне современных среднебюджетных телефонов. Передняя — просто есть, снимает не очень.
Из всего этого следует сделать вывод: если вы покупаете флагман компании, то срок его жизни выше, чем у устройств дешевле. Поэтому, если вы выбираете девайс с ограниченным бюджетом, то стоит смотреть в сторону прошлых флагманов. Часто эти устройства лучше.
Помню, что когда первый раз взял этот смартфон, то удивлялся, насколько он хорошо лежит в руке. Особенно нравился красно-оранжевый Nexus 5, который сильно выделялся на фоне всех остальных.
Если вкратце по видео, то:
• можно установить свежий Android Oreo. Кстати, этот аргумент применим в споре с любителями iPhone;
• средняя автономность. Часто нужно менять аккумулятор, стоимость замены около 1000 рублей;
• хороший дисплей и неплохой процессор. Топовые игры немного тормозят, но остальные — вполне комфортно и без лагов;
• комфортная основная камера. Снимает сносно, на уровне современных среднебюджетных телефонов. Передняя — просто есть, снимает не очень.
Из всего этого следует сделать вывод: если вы покупаете флагман компании, то срок его жизни выше, чем у устройств дешевле. Поэтому, если вы выбираете девайс с ограниченным бюджетом, то стоит смотреть в сторону прошлых флагманов. Часто эти устройства лучше.
YouTube
Nexus 5 и Nexus 7 в 2018!
Когда хочется купить бюджетный смартфон – встаёт выбор: либо новый, но слабый смартфон, либо старый, но мощный. Актуальны ли в 2018-м году устройства Nexus 5 и Nexus 7 (2013), можно ли установить на них Android 8.1 и что насчёт качества камер, экрана и звука?…
Как изменить строковые ресурсы налету?
#разработка
Если приложение имеет поддержку нескольких языков, то в разработке появляется ещё одно звено — отдел переводчиков. Сразу появляется несколько проблем:
1) Люди ошибаются, и в переводах есть опечатки, неточности и ошибки, которые проявляются уже после релиза.
2) Добавление переводов. Если в приложении много языков, то обычно переводят базовый язык (английский), а остальные добавляют после. Если ждать перевода строк на несколько языков, то выкладка релиза может сильно затянуться. Опять приходится ожидать нового релиза.
3) Обмен строковыми ресурсами. Переводчикам не удобно работать с форматом xml. Для удобства используются средства, которые преобразуют xml в таблицу Excel. После этого эти файлы нужно экспортировать обратно в проект. Это лишняя и рутинная задача, которая отнимает время.
К сожалению, Android не даёт стандартных средств для замены строк налету. Стандартные ресурсы работают хорошо и работают с огромным количеством языков. Но только вшивая их в очередной apk-файл.
Недавно мне попался ресурс, который решил все описанные проблемы. Это сервис Lokalise. В нем есть гора возможностей, которые улучшают процесс перевода приложения.
• импорт текущих ресурсов. В большом проекте может быть несколько тысяч строк. Сервис автоматически покажет дублированные строки, которые можно объединить, удалить или пропустить. При добавлении второй платформы, сервис сам предложит объединить строки с разными ключами. Это все делается в течении получаса;
• скриншоты к конкретной строке. Почти всегда для понимания контекста перевода, требуется скриншот. Добавить его можно или через API, или вручную. Делается это в пару кликов.
• переводы налету. Есть SDK для Android и iOS, которое позволит исправлять ошибки переводчиков без перезаливки приложения.
• работа с командой и система администрирования. Удобно давать доступ для переводчиков только к текущему языку.
• интеграция с Git, Jenkins и другими системами. При правильной настройке, взаимодействие с отделом переводов можно свести к минимуму или вовсе исключить. Строки будут попадать из приложения и обратно самостоятельно.
Это только некоторые преимущества этого сервиса. Их на самом деле гораздо больше. Сервис платный, но за решение такого числа задач у него вполне адекватная цена. Всячески рекомендую сервис для использования.
#разработка
Если приложение имеет поддержку нескольких языков, то в разработке появляется ещё одно звено — отдел переводчиков. Сразу появляется несколько проблем:
1) Люди ошибаются, и в переводах есть опечатки, неточности и ошибки, которые проявляются уже после релиза.
2) Добавление переводов. Если в приложении много языков, то обычно переводят базовый язык (английский), а остальные добавляют после. Если ждать перевода строк на несколько языков, то выкладка релиза может сильно затянуться. Опять приходится ожидать нового релиза.
3) Обмен строковыми ресурсами. Переводчикам не удобно работать с форматом xml. Для удобства используются средства, которые преобразуют xml в таблицу Excel. После этого эти файлы нужно экспортировать обратно в проект. Это лишняя и рутинная задача, которая отнимает время.
К сожалению, Android не даёт стандартных средств для замены строк налету. Стандартные ресурсы работают хорошо и работают с огромным количеством языков. Но только вшивая их в очередной apk-файл.
Недавно мне попался ресурс, который решил все описанные проблемы. Это сервис Lokalise. В нем есть гора возможностей, которые улучшают процесс перевода приложения.
• импорт текущих ресурсов. В большом проекте может быть несколько тысяч строк. Сервис автоматически покажет дублированные строки, которые можно объединить, удалить или пропустить. При добавлении второй платформы, сервис сам предложит объединить строки с разными ключами. Это все делается в течении получаса;
• скриншоты к конкретной строке. Почти всегда для понимания контекста перевода, требуется скриншот. Добавить его можно или через API, или вручную. Делается это в пару кликов.
• переводы налету. Есть SDK для Android и iOS, которое позволит исправлять ошибки переводчиков без перезаливки приложения.
• работа с командой и система администрирования. Удобно давать доступ для переводчиков только к текущему языку.
• интеграция с Git, Jenkins и другими системами. При правильной настройке, взаимодействие с отделом переводов можно свести к минимуму или вовсе исключить. Строки будут попадать из приложения и обратно самостоятельно.
Это только некоторые преимущества этого сервиса. Их на самом деле гораздо больше. Сервис платный, но за решение такого числа задач у него вполне адекватная цена. Всячески рекомендую сервис для использования.
Android Support Library 28. Что добавилось?
#разработка #библиотеки
Уверен, что все уже в курсе, что Google выпустили свежую версию Support Library. Поделюсь с вами тем, что заинтересовало меня.
1) FingerprintDialog. Разработчики получили доступ к разблокировке по отпечатку пальца с Android 6. После анонса, многие разработчики начали использовать эту возможность. Но всем приходилось верстать экран разблокировки по своему усмотрению, не было единого дизайна для диалога. Теперь анонсирован диалог, который легко настроить и внедрить в приложение. Подробнее про использование диалога тут.
2) Slices. Интересная библиотека, которая позволяет использовать часть другого приложения без привязки к его интерфейсу. Думаю, что это обязательно найдёт своё применение. Например, теперь можно внедрить в приложение Google Assistant, и он будет выглядеть по аналогии с вашим дизайном. Больше информации тут.
3) BottomAppBar. Элемент, который позволяет располагать AppBar внизу экрана. Сейчас распространены устройства с высокими экранами, поэтому пользователям тяжело тянуться вверх до кнопки меню. Не уверен, что элемент будет пользоваться популярностью, но мне очень нравится сочетание FabButton и BottomAppBar, а точнее их анимация. Больше информации тут.
Пока версия Android Support Library не финальная, и уверен, что мы получим ещё больше интересных элементов.
#разработка #библиотеки
Уверен, что все уже в курсе, что Google выпустили свежую версию Support Library. Поделюсь с вами тем, что заинтересовало меня.
1) FingerprintDialog. Разработчики получили доступ к разблокировке по отпечатку пальца с Android 6. После анонса, многие разработчики начали использовать эту возможность. Но всем приходилось верстать экран разблокировки по своему усмотрению, не было единого дизайна для диалога. Теперь анонсирован диалог, который легко настроить и внедрить в приложение. Подробнее про использование диалога тут.
2) Slices. Интересная библиотека, которая позволяет использовать часть другого приложения без привязки к его интерфейсу. Думаю, что это обязательно найдёт своё применение. Например, теперь можно внедрить в приложение Google Assistant, и он будет выглядеть по аналогии с вашим дизайном. Больше информации тут.
3) BottomAppBar. Элемент, который позволяет располагать AppBar внизу экрана. Сейчас распространены устройства с высокими экранами, поэтому пользователям тяжело тянуться вверх до кнопки меню. Не уверен, что элемент будет пользоваться популярностью, но мне очень нравится сочетание FabButton и BottomAppBar, а точнее их анимация. Больше информации тут.
Пока версия Android Support Library не финальная, и уверен, что мы получим ещё больше интересных элементов.
Ошибка выжившего
#думы
Уверен, что вам часто попадались статьи из разряда «Топ 10 привычек успешных людей» или «15 вещей, которые состоявшиеся люди делают до завтрака». Подобные статьи очень популярны во всевозможных пабликах. В них даются советы, делая которые можно прийти к успеху. Говорят, что эти советы основаны на жизни людей, которые достигли определенных высот в жизни. Логично, что делая так же, можно прийти к тому же результату. Или нет?
Попалась интересная статья, которая описывает такое явление как ошибка выжившего. В качестве примера описывается случай с войны, когда математик Абрахам Вальд помог пилотам американских бомбардировщиков чаще возвращаться на базу живыми. В задачу входило улучшение брони самолета. Но весь самолёт нельзя было покрыть броней из-за её огромного веса. Одни инженеры предложили проанализировать те попадания, с которыми самолеты возвращались домой, и укрепить данные места броней. Но Вальд предложил укреплять те места, в которые пули не попадали на основании того, что именно эти ранения были смертельными. Его совет сократил число сбитых бомбардировщиков.
За каждой success story скрывается череда неудач других людей, которые не сумели стать лучшими. И увлечение такими историями порой бывает опасно: вы можете попасть в реализацию чужих советов.
Любому человеку важно стремиться к успеху. Думаю, что секрет успеха не в следовании советам, а в постоянном труде и решимости. В мире разработки это особенно актуально. Профессия программиста требует постоянного обучения и развития. Те знания, которые разработчики получили пару лет назад могут быть не актуальными сегодня. И я точно знаю, что находясь в таком состоянии вы будете успешным разработчиком, даже если вы пьете кофе или не делаете утром зарядку.
#думы
Уверен, что вам часто попадались статьи из разряда «Топ 10 привычек успешных людей» или «15 вещей, которые состоявшиеся люди делают до завтрака». Подобные статьи очень популярны во всевозможных пабликах. В них даются советы, делая которые можно прийти к успеху. Говорят, что эти советы основаны на жизни людей, которые достигли определенных высот в жизни. Логично, что делая так же, можно прийти к тому же результату. Или нет?
Попалась интересная статья, которая описывает такое явление как ошибка выжившего. В качестве примера описывается случай с войны, когда математик Абрахам Вальд помог пилотам американских бомбардировщиков чаще возвращаться на базу живыми. В задачу входило улучшение брони самолета. Но весь самолёт нельзя было покрыть броней из-за её огромного веса. Одни инженеры предложили проанализировать те попадания, с которыми самолеты возвращались домой, и укрепить данные места броней. Но Вальд предложил укреплять те места, в которые пули не попадали на основании того, что именно эти ранения были смертельными. Его совет сократил число сбитых бомбардировщиков.
За каждой success story скрывается череда неудач других людей, которые не сумели стать лучшими. И увлечение такими историями порой бывает опасно: вы можете попасть в реализацию чужих советов.
Любому человеку важно стремиться к успеху. Думаю, что секрет успеха не в следовании советам, а в постоянном труде и решимости. В мире разработки это особенно актуально. Профессия программиста требует постоянного обучения и развития. Те знания, которые разработчики получили пару лет назад могут быть не актуальными сегодня. И я точно знаю, что находясь в таком состоянии вы будете успешным разработчиком, даже если вы пьете кофе или не делаете утром зарядку.
Удаление неиспользуемых языков
#разработка #советы
Сегодня расскажу один способ уменьшения размера apk-файла.
При разработке приложений на одну локаль, многие думают, что в их приложении хранится только она, однако, это не так. Если вы проинспектируете собранный apk, то заметите несколько десятков включенных языков.
Это происходит потому, что некоторые библиотеки и компоненты переведены на много языков. Мало кому нужны все языки сразу, поэтому их нужно удалять из приложения при помощи:
Чуть больше информации об этом вы можете почитать тут.
#разработка #советы
Сегодня расскажу один способ уменьшения размера apk-файла.
При разработке приложений на одну локаль, многие думают, что в их приложении хранится только она, однако, это не так. Если вы проинспектируете собранный apk, то заметите несколько десятков включенных языков.
Это происходит потому, что некоторые библиотеки и компоненты переведены на много языков. Мало кому нужны все языки сразу, поэтому их нужно удалять из приложения при помощи:
resConfigs "auto". Его необходимо добавить в defaultConfig.Чуть больше информации об этом вы можете почитать тут.
Сегодня моё рабочее утро началось со статьи с кучей советов для Android-разработчиков. Автор потрудился и собрал вместе много полезных техник. Уверен, что даже опытные разработчики найдут здесь для себя новое. Тут собраны:
• #советы по Android Studio, среди которых горячие клавиши, плагины, templates, советы по шрифтам;
• выбор эмуляторов;
• советы при написании кода;
• консольные команды;
• целый пласт лучших библиотек.
Я изучил ещё не весь документ, но уже взял несколько интересных вещей, например:
1) Постфиксное завершение кода. Например можно написать
2) Команда для обновления всех зависимостей это
3) Узнал, почему нельзя использовать
4) Нашёл библиотеку, которая позволяет создавать скриншоты прямо из приложения. Хочу попробовать.
5) Узнал про атрибут
Добавил в закладки и буду ещё не раз обращаться к этому репозиторию.
• #советы по Android Studio, среди которых горячие клавиши, плагины, templates, советы по шрифтам;
• выбор эмуляторов;
• советы при написании кода;
• консольные команды;
• целый пласт лучших библиотек.
Я изучил ещё не весь документ, но уже взял несколько интересных вещей, например:
1) Постфиксное завершение кода. Например можно написать
<expr>.null вместо if(<expr> == null).2) Команда для обновления всех зависимостей это
./gradlew --refresh-dependencies.3) Узнал, почему нельзя использовать
@android:color/transparent в градиентах. 4) Нашёл библиотеку, которая позволяет создавать скриншоты прямо из приложения. Хочу попробовать.
5) Узнал про атрибут
tools:parentTag, когда используешь <merge> в верстке.Добавил в закладки и буду ещё не раз обращаться к этому репозиторию.
Арабская локализация. Особые знаки процентов
#разработка
В одном из первых постов я упоминал те проблемы, с которым сталкивался при поддержке приложения в RTL-локализациях. Сегодня хочу поделиться той болью, с которой столкнулся недавно. Это особые символы процента на арабском языке.
Как вы знаете, в Android, ресурсы локализаций располагаются в специальном xml файле. Среди обыкновенных строк часто встречаются спец.символы вида
Соблюдение этих символов важно при переводе приложения на другие локализации. Если проигнорировать их, то приложение может работать некорректно, а то и крашнуться.
Получив свежие переводы на арабскую локаль стало ясно, что переводчик решил заменить обыкновенный символ % на другой, напоминающий процент '٪'. Причем сделано это было не во всем переводе, а только в некоторых его частях.
Изменение RTL-языков в Android Studio не самая приятная процедура, поэтому замена этих символов легла на плечи переводчика.
Вывод: обращайте внимание на эти языки при разработке своего приложения.
#разработка
В одном из первых постов я упоминал те проблемы, с которым сталкивался при поддержке приложения в RTL-локализациях. Сегодня хочу поделиться той болью, с которой столкнулся недавно. Это особые символы процента на арабском языке.
Как вы знаете, в Android, ресурсы локализаций располагаются в специальном xml файле. Среди обыкновенных строк часто встречаются спец.символы вида
%s %d и некоторые другие, которые значат, что вместо этого символа будет вставлена определенная строка или число. Соблюдение этих символов важно при переводе приложения на другие локализации. Если проигнорировать их, то приложение может работать некорректно, а то и крашнуться.
Получив свежие переводы на арабскую локаль стало ясно, что переводчик решил заменить обыкновенный символ % на другой, напоминающий процент '٪'. Причем сделано это было не во всем переводе, а только в некоторых его частях.
Изменение RTL-языков в Android Studio не самая приятная процедура, поэтому замена этих символов легла на плечи переводчика.
Вывод: обращайте внимание на эти языки при разработке своего приложения.
Техника Pomodoro
#планирование
Часто я слышу о технике, которая называется Pomodoro.
Суть техники заключается в планировании дел в «помидорах», затем вы ставите таймер и работаете в это время ни на что не отвлекаясь и концентрируясь на работе. Если появилось что-то срочное, то это нужно записать и сделать в следующий период.
Стандартный «помидор» — это 25 минут, но время можно подкорректировать под себя. После завершения этого промежутка необходимо сделать перерыв. Обычно это 5 минут. После 4 «помидоров» надо сделать большой перерыв — 20 минут.
Я не слышал о том, используется ли подобный подход при в процессе написания кода. Мне кажется, что когда разработчик увлечен работой, то время для него пролетает незаметно. К сожалению, постоянная работа без перерывов грозит выгоранием, стрессом и сильной усталостью.
Я решил испробовать эту технику. Для этого воспользовался плагином для Google Chrome, который сообщает о завершении «помидор», перерыва, а также ведет статистику эффективности.
Пока не уверен, что техника даст профит, и что вообще её можно использовать при программировании. Но в любом случае подобный подход выгодно использовать, когда не получается сконцентрироваться, но важно решить задачу. Особенно для рутинных, нелюбимых, но обязательных дел.
А вы пробовали использовать эту технику?
#планирование
Часто я слышу о технике, которая называется Pomodoro.
Суть техники заключается в планировании дел в «помидорах», затем вы ставите таймер и работаете в это время ни на что не отвлекаясь и концентрируясь на работе. Если появилось что-то срочное, то это нужно записать и сделать в следующий период.
Стандартный «помидор» — это 25 минут, но время можно подкорректировать под себя. После завершения этого промежутка необходимо сделать перерыв. Обычно это 5 минут. После 4 «помидоров» надо сделать большой перерыв — 20 минут.
Я не слышал о том, используется ли подобный подход при в процессе написания кода. Мне кажется, что когда разработчик увлечен работой, то время для него пролетает незаметно. К сожалению, постоянная работа без перерывов грозит выгоранием, стрессом и сильной усталостью.
Я решил испробовать эту технику. Для этого воспользовался плагином для Google Chrome, который сообщает о завершении «помидор», перерыва, а также ведет статистику эффективности.
Пока не уверен, что техника даст профит, и что вообще её можно использовать при программировании. Но в любом случае подобный подход выгодно использовать, когда не получается сконцентрироваться, но важно решить задачу. Особенно для рутинных, нелюбимых, но обязательных дел.
А вы пробовали использовать эту технику?
Давно у нас не было топа статей из Medium
#статьи #medium
1) Mastering the World of Android Testing. — (8 минут)
Тестирование приложений — это то, чем часто пренебрегают даже опытные разработчики. Иногда не по их вине, а по вине руководителей. Большинство хочет видеть новые фичи, а покрытие тестами считают лишней тратой времени, и не оставляют на это часть времени при разработке. Со временем приложение, которое не покрывается тестами может приносить сюрпризы: отваливается уже готовая функциональность, появляются краши.
Автор в статье делится тезисами, которые относятся к тестированию Android-приложений. А тут вторая часть.
2) Why Flutter Will Change Mobile Development for the Best. — (11 минут)
На канале уже много раз упоминал язык Flutter. Мне попадались статьи, которые говорят, что язык очень сырой и его еще долго нельзя использовать. Другие говорят, что это тот язык, на котором уже можно писать простые приложения, и которые успешно себя чувствуют в проде.
Автор рассуждает о Flutter, сравнивает нативно написанное приложение под Android и кроссплатформенное на Flutter. В любом случае, Flutter достойный язык для того, чтобы попробовать его и немного изучить.
#статьи #medium
1) Mastering the World of Android Testing. — (8 минут)
Тестирование приложений — это то, чем часто пренебрегают даже опытные разработчики. Иногда не по их вине, а по вине руководителей. Большинство хочет видеть новые фичи, а покрытие тестами считают лишней тратой времени, и не оставляют на это часть времени при разработке. Со временем приложение, которое не покрывается тестами может приносить сюрпризы: отваливается уже готовая функциональность, появляются краши.
Автор в статье делится тезисами, которые относятся к тестированию Android-приложений. А тут вторая часть.
2) Why Flutter Will Change Mobile Development for the Best. — (11 минут)
На канале уже много раз упоминал язык Flutter. Мне попадались статьи, которые говорят, что язык очень сырой и его еще долго нельзя использовать. Другие говорят, что это тот язык, на котором уже можно писать простые приложения, и которые успешно себя чувствуют в проде.
Автор рассуждает о Flutter, сравнивает нативно написанное приложение под Android и кроссплатформенное на Flutter. В любом случае, Flutter достойный язык для того, чтобы попробовать его и немного изучить.