Сегодня утром решил почитать статьи, связанные с Git.
Если вы новичок, то рекомендую почитать статью, которая рассказывает о том, как работает #git и на примерах объясняются базовые команды.
Сегодня хочу с вами делиться некоторыми командами, которые помогают мне в работе.
1) В работе иногда сталкиваюсь с тем, что после совершения коммита понимаю, что добавил в него не все нужные мне файлы. Для добавления создаётся новый коммит, в котором указывается сообщение "Add to previous commit". На практике это выглядит не очень красиво, ведь данный коммит не несет никакой пользы. Лучше не создавать новый коммит, а добавить файлы в последний при помощи команды
2) В некоторых компаниях руководство требует отправлять отчеты о проделанной работе за неделю. Для быстрого составления отчета можно воспользоваться командой
Если вы новичок, то рекомендую почитать статью, которая рассказывает о том, как работает #git и на примерах объясняются базовые команды.
Сегодня хочу с вами делиться некоторыми командами, которые помогают мне в работе.
1) В работе иногда сталкиваюсь с тем, что после совершения коммита понимаю, что добавил в него не все нужные мне файлы. Для добавления создаётся новый коммит, в котором указывается сообщение "Add to previous commit". На практике это выглядит не очень красиво, ведь данный коммит не несет никакой пользы. Лучше не создавать новый коммит, а добавить файлы в последний при помощи команды
git commit --amend. 2) В некоторых компаниях руководство требует отправлять отчеты о проделанной работе за неделю. Для быстрого составления отчета можно воспользоваться командой
git log --author="author_name" --after="1 week ago" --oneline.Люблю читать истории создания продуктов.
Больше нравится читать не рассказы о глобальных корпорациях, а о небольших стартапах, где у людей была только идея, благодаря которой они создали полезный продукт.
Попалась история создания стартапа Kidkin.
Две девушки решили сделать продукт для родителей, где они могут для детей найти секции, занятия и другие события.
Читая историю понял несколько вещей:
1) Важно хотеть создать крутой продукт. Думаю, что первоначальным желанием должно быть именно создание продукта, а не получение прибыли.
2) Для продукта важна команда. В одиночку никто, даже самый умный и вдохновленный идеей человек, ничего не сможет сделать.
Раньше писал свои мысли о плюсах работы в стартапе и большой компании. Но в моих рассуждениях не было пункта о собственном стартапе. Мне кажется, что здорово воплощать свою идею в жизнь. Но гораздо сложнее, чем просто писать код.
А как вы думаете, где интереснее работать, в компании или стартапе?
🔴 — стартап;
🔵 — компания.
Больше нравится читать не рассказы о глобальных корпорациях, а о небольших стартапах, где у людей была только идея, благодаря которой они создали полезный продукт.
Попалась история создания стартапа Kidkin.
Две девушки решили сделать продукт для родителей, где они могут для детей найти секции, занятия и другие события.
Читая историю понял несколько вещей:
1) Важно хотеть создать крутой продукт. Думаю, что первоначальным желанием должно быть именно создание продукта, а не получение прибыли.
2) Для продукта важна команда. В одиночку никто, даже самый умный и вдохновленный идеей человек, ничего не сможет сделать.
Раньше писал свои мысли о плюсах работы в стартапе и большой компании. Но в моих рассуждениях не было пункта о собственном стартапе. Мне кажется, что здорово воплощать свою идею в жизнь. Но гораздо сложнее, чем просто писать код.
А как вы думаете, где интереснее работать, в компании или стартапе?
🔴 — стартап;
🔵 — компания.
Эффект последней строки
#статьи
Сегодня прочитал статью об ошибках, которые допускают разработчики.
Автор статьи исследует исходных код open source приложений на предмет в них ошибок при помощи статических анализаторов. В результате выяснился такой феномен как эффект последней строки.
Уверен, что каждый разработчик часто сталкивается с ситуациями, когда нужно написать несколько почти одинаковых строк кода подряд.
Самым простым, но не лучшим решением является копирование этих строк и дальнейшее их изменение с нужными параметрами. Разработчики что-то забывают поменять, в результате в программе появляется ошибка. Например:
В данном коде разработчик просто забыл поменять последнюю строчку на vector.z. Хорошо, если подобные ошибки обнаруживается на этапе тестирования, а не в проде.
Проанализировав несколько проектов, автор пришёл к выводу, что вероятность найти ошибку в последнем скопированном блоке в 4 раза выше, чем в любом другом.
Для нас, разработчиков, это значит, что не стоит расслабляться в конце написания функции, и если что-то не работает, то стоит искать ошибки в последнем фрагменте кода.
#статьи
Сегодня прочитал статью об ошибках, которые допускают разработчики.
Автор статьи исследует исходных код open source приложений на предмет в них ошибок при помощи статических анализаторов. В результате выяснился такой феномен как эффект последней строки.
Уверен, что каждый разработчик часто сталкивается с ситуациями, когда нужно написать несколько почти одинаковых строк кода подряд.
Самым простым, но не лучшим решением является копирование этих строк и дальнейшее их изменение с нужными параметрами. Разработчики что-то забывают поменять, в результате в программе появляется ошибка. Например:
private void addVector(Vector vector) {
x = vector.x;
y = vector.y;
z = vector.y;
}В данном коде разработчик просто забыл поменять последнюю строчку на vector.z. Хорошо, если подобные ошибки обнаруживается на этапе тестирования, а не в проде.
Проанализировав несколько проектов, автор пришёл к выводу, что вероятность найти ошибку в последнем скопированном блоке в 4 раза выше, чем в любом другом.
Для нас, разработчиков, это значит, что не стоит расслабляться в конце написания функции, и если что-то не работает, то стоит искать ошибки в последнем фрагменте кода.
(Не)Безопасность 101
#разработка
Хочу порекомендовать доклад Григория Джанелидзе о безопасности Android приложений. На канале часто говорю по поводу безопасности приложений, и что ей необходимо уделять внимание при разработке.
Если вкратце, то: всё, что есть у вас в apk файле реально достать. Будь это JNI код или нативный. Вопрос заключается только во времени и цене того, что получит «исследующий» приложение.
Кстати, для себя открыл несколько полезных инструментов для анализа приложений. Я не так часто занимаюсь подобными исследованиями, поэтому для меня это было интересно и захотелось попробовать.
#разработка
Хочу порекомендовать доклад Григория Джанелидзе о безопасности Android приложений. На канале часто говорю по поводу безопасности приложений, и что ей необходимо уделять внимание при разработке.
Если вкратце, то: всё, что есть у вас в apk файле реально достать. Будь это JNI код или нативный. Вопрос заключается только во времени и цене того, что получит «исследующий» приложение.
Кстати, для себя открыл несколько полезных инструментов для анализа приложений. Я не так часто занимаюсь подобными исследованиями, поэтому для меня это было интересно и захотелось попробовать.
YouTube
«(Не)Безопасность 101», Григорий Джанелидзе, Mosdroid
Безопасность – хорошо, а вот иллюзия безопасности – плохо. Многие статьи и доклады про безопасность в контексте Android за последние годы упускают один важный момент – насколько предложенные способы на самом деле усложняют работу по взлому/реверс-инжинирингу…
Новая навигация от Google
#разработка
Уверен, что все Android-разработчики пристально следили за конференцией Google IO. На ней Google представила много интересных вещей.
Для разработчиков представлен Jetpack, который содержит набор средств для создания приложений.
Одним из компонентов является The Navigation Architecture Component, упрощающий навигацию в приложениях. Я попробовал это решение, и мне оно показалось достаточно удобным. Конечно, пока его нельзя встраивать в реальные проекты, потому что версия alpha, но то, что мы получили достойный инструмент — очень радует.
Подробнее о компоненте тут, а также отличная статья для быстрого старта тут.
#разработка
Уверен, что все Android-разработчики пристально следили за конференцией Google IO. На ней Google представила много интересных вещей.
Для разработчиков представлен Jetpack, который содержит набор средств для создания приложений.
Одним из компонентов является The Navigation Architecture Component, упрощающий навигацию в приложениях. Я попробовал это решение, и мне оно показалось достаточно удобным. Конечно, пока его нельзя встраивать в реальные проекты, потому что версия alpha, но то, что мы получили достойный инструмент — очень радует.
Подробнее о компоненте тут, а также отличная статья для быстрого старта тут.
В личку пришел вопрос о просьбе провести #опрос: какой операционной системой вы пользуетесь?
Например, я долгое время пользовался только компьютерами с Windows. Давно это было Windows 7, потом на смену пришла 8, и даже сейчас в офисе стоит достаточно мощный компьютер с Windows 10, на котором и пишу код. Как по мне, «восьмерка» и «десятка» — прекрасные операционные системы.
Дома у меня Macbook Pro 17 года, который появился где-то полгода назад. Я не делал замеры, но по ощущениям сборка одного и того же проекта на нем быстрее (примерно на 15-20%). Возможно, дело в железе. Что касается самой операционки MacOS, то к ней быстро привыкаешь. А в совокупности с отличным экраном Macbook, работать шикарно. Из недостатков операционной системы могу отметить иные горячие клавиши. Нужно или переопределять, или ставить другую схему, но полной совместимости все равно нет.
Когда-то давно был опыт работы на Ubuntu, но отсеял этот вариант, потому что мой прошлый ноутбук быстро разряжался из-за дискретной карты, на которую было сложно поставить драйвера. Хотя знаю людей, которые пользуются Linux для разработки под Android.
Какой же ваш выбор?
🔴 — Windows;
🔵 — MacOS;
⚫️ — Linux.
Например, я долгое время пользовался только компьютерами с Windows. Давно это было Windows 7, потом на смену пришла 8, и даже сейчас в офисе стоит достаточно мощный компьютер с Windows 10, на котором и пишу код. Как по мне, «восьмерка» и «десятка» — прекрасные операционные системы.
Дома у меня Macbook Pro 17 года, который появился где-то полгода назад. Я не делал замеры, но по ощущениям сборка одного и того же проекта на нем быстрее (примерно на 15-20%). Возможно, дело в железе. Что касается самой операционки MacOS, то к ней быстро привыкаешь. А в совокупности с отличным экраном Macbook, работать шикарно. Из недостатков операционной системы могу отметить иные горячие клавиши. Нужно или переопределять, или ставить другую схему, но полной совместимости все равно нет.
Когда-то давно был опыт работы на Ubuntu, но отсеял этот вариант, потому что мой прошлый ноутбук быстро разряжался из-за дискретной карты, на которую было сложно поставить драйвера. Хотя знаю людей, которые пользуются Linux для разработки под Android.
Какой же ваш выбор?
🔴 — Windows;
🔵 — MacOS;
⚫️ — Linux.
Room
#разработка #библиотека
Уже прошло прилично времени с момента анонса библиотеки Room от Google. Начав небольшой проект, решил попробовать ее как главную библиотеку для базы данных. Поделюсь мнением об этой библиотеке.
Вся работа с библиотекой осуществляется при помощи 3 аннотаций:
1) @Entity — аннотация, которая говорит о необходимости создания таблицы для данного класса. При этом, нужно указать @PrimaryKey, а также при желании имя таблицы, имена колонок и те поля, которые не нужно добавлять в базу.
2) @Dao — аннотация для интерфейса, в которой описываются все методы для доступа к БД. Для методов этого интерфейса нужно указывать типы запросов, а также при желании можно написать свой запрос с помощью @Query.
3) @Database — аннотация для абстрактного класса, где необходимо проинициализировать БД.
Этих 3 сущностей достаточно для начала работы с базой.
Мне понравилось:
• быстрая установка базы;
• совместимость с RxJava;
• получение ошибок на этапе компиляции;
• инициализация для тестов (можно сделать БД, которая живет только во время жизни приложения, что удобно для тестирования);
• многопоточность;
• отсутствие необходимости наследования от базового класса БД.
Что касается скорости работы, то мне сложно сравнивать это с другими существующими решениями. Например, если верить этой статье, то Room не очень быстр. Однако, это синтетический тест, и всегда надо опираться на те задачи, которые решает БД в конкретном приложении. Да и скорость работы — это только один из параметров.
Впечатления от библиотеки остались положительные, поэтому рекомендую попробовать ее для работы. Чтобы было проще начать, воспользуйтесь этой статьей.
#разработка #библиотека
Уже прошло прилично времени с момента анонса библиотеки Room от Google. Начав небольшой проект, решил попробовать ее как главную библиотеку для базы данных. Поделюсь мнением об этой библиотеке.
Вся работа с библиотекой осуществляется при помощи 3 аннотаций:
1) @Entity — аннотация, которая говорит о необходимости создания таблицы для данного класса. При этом, нужно указать @PrimaryKey, а также при желании имя таблицы, имена колонок и те поля, которые не нужно добавлять в базу.
2) @Dao — аннотация для интерфейса, в которой описываются все методы для доступа к БД. Для методов этого интерфейса нужно указывать типы запросов, а также при желании можно написать свой запрос с помощью @Query.
3) @Database — аннотация для абстрактного класса, где необходимо проинициализировать БД.
Этих 3 сущностей достаточно для начала работы с базой.
Мне понравилось:
• быстрая установка базы;
• совместимость с RxJava;
• получение ошибок на этапе компиляции;
• инициализация для тестов (можно сделать БД, которая живет только во время жизни приложения, что удобно для тестирования);
• многопоточность;
• отсутствие необходимости наследования от базового класса БД.
Что касается скорости работы, то мне сложно сравнивать это с другими существующими решениями. Например, если верить этой статье, то Room не очень быстр. Однако, это синтетический тест, и всегда надо опираться на те задачи, которые решает БД в конкретном приложении. Да и скорость работы — это только один из параметров.
Впечатления от библиотеки остались положительные, поэтому рекомендую попробовать ее для работы. Чтобы было проще начать, воспользуйтесь этой статьей.
Package by layers vs Package by features
#разработка #опрос
При создании проекта, существует два основных подхода для организации кода.
Первый подход называется Package by layers. Его смысл в том, что вы раскладываете классы по папкам, которые разбиты по слоям: например, модели содержатся в папке models; работа с интерфейсом, и view содержатся в папке ui. Далее внутри каждой папки создается каталог с названием фичи. Пример можно посмотреть тут
Из плюсов такого подхода могу выделить то, что при наследовании переиспользуемые классы находятся в одном месте. Это удобно, если вы хотите отрефакторить какой-либо базовый класс.
Минус в том, что при разработке проекта нужно создавать огромное количество одинаковых подкаталогов, и следить за тем, чтобы их названия совпадали для удобства и читаемости. Для ускорения этого процесса стоит создать template в Android Studio.
Второй подход Package by features говорит о том, что необходимо раскладывать классы для каждой из фич в отдельную папку. Например, каталог login будет содержать все необходимое для модуля авторизации: views, api, di.
При таком подходе легко понять, что содержится в приложении, а также быстро переключаться между фичами. Пример такой организации файлов можно увидеть тут.
А какой из подходов используете вы?
🔴 — Package by layers;
🔵 — Package by features;
#разработка #опрос
При создании проекта, существует два основных подхода для организации кода.
Первый подход называется Package by layers. Его смысл в том, что вы раскладываете классы по папкам, которые разбиты по слоям: например, модели содержатся в папке models; работа с интерфейсом, и view содержатся в папке ui. Далее внутри каждой папки создается каталог с названием фичи. Пример можно посмотреть тут
Из плюсов такого подхода могу выделить то, что при наследовании переиспользуемые классы находятся в одном месте. Это удобно, если вы хотите отрефакторить какой-либо базовый класс.
Минус в том, что при разработке проекта нужно создавать огромное количество одинаковых подкаталогов, и следить за тем, чтобы их названия совпадали для удобства и читаемости. Для ускорения этого процесса стоит создать template в Android Studio.
Второй подход Package by features говорит о том, что необходимо раскладывать классы для каждой из фич в отдельную папку. Например, каталог login будет содержать все необходимое для модуля авторизации: views, api, di.
При таком подходе легко понять, что содержится в приложении, а также быстро переключаться между фичами. Пример такой организации файлов можно увидеть тут.
А какой из подходов используете вы?
🔴 — Package by layers;
🔵 — Package by features;
Гамбургерное меню
#дизайн
Недавно прочитал статью о том, как влияет скрытое меню на опыт использования приложения или сайта.
Исследование говорит, что пользователи сайтов использовали скрытое меню только в 27% случаев, а видимую часть в 50%. На мобильных устройствах эта цифра составляет 57% для скрытого меню и 87% для видимого.
Интересно наблюдать за тенденцией: раньше большинство мобильных приложений стремилось использовать кнопку «гамбургер» для создания скрытого бокового меню. Даже когда оно не было уместно. Все это преподносилось под соусом гайдлайнов, и поэтому никто не задумывался о правильности использования.
Этот же «гамбургер» перекочевал и на десктопные сайты, где в распоряжении огромный экран, куда помещается сколько угодно контента. Например, известный сайт BBC Russian имеет полоску со скрытым меню. Попробуйте засечь, сколько секунд вам понадобилось, чтобы понять, что там есть меню и еще больше контента, кроме того, что сейчас доступен.
Сейчас все больше приложений уходят в сторону видимого или комбинированного меню. Например, такое меню размещается внизу при помощи
Из всего этого можно сделать один вывод: по возможности нужно использовать видимое меню. Если приложение состоит из 5 разделов, то смысл скрытого меню теряется, а о некоторых функциях пользователь может догадаться не сразу.
#дизайн
Недавно прочитал статью о том, как влияет скрытое меню на опыт использования приложения или сайта.
Исследование говорит, что пользователи сайтов использовали скрытое меню только в 27% случаев, а видимую часть в 50%. На мобильных устройствах эта цифра составляет 57% для скрытого меню и 87% для видимого.
Интересно наблюдать за тенденцией: раньше большинство мобильных приложений стремилось использовать кнопку «гамбургер» для создания скрытого бокового меню. Даже когда оно не было уместно. Все это преподносилось под соусом гайдлайнов, и поэтому никто не задумывался о правильности использования.
Этот же «гамбургер» перекочевал и на десктопные сайты, где в распоряжении огромный экран, куда помещается сколько угодно контента. Например, известный сайт BBC Russian имеет полоску со скрытым меню. Попробуйте засечь, сколько секунд вам понадобилось, чтобы понять, что там есть меню и еще больше контента, кроме того, что сейчас доступен.
Сейчас все больше приложений уходят в сторону видимого или комбинированного меню. Например, такое меню размещается внизу при помощи
BottomNavigationView . Это удобно, и позволяет очень быстро переключаться между основными разделами приложения.Из всего этого можно сделать один вывод: по возможности нужно использовать видимое меню. Если приложение состоит из 5 разделов, то смысл скрытого меню теряется, а о некоторых функциях пользователь может догадаться не сразу.
Dagger 2
#разработка #статьи
Мне кажется, что про библиотеку Dagger 2 слышал каждый Android-разработчик. Тема заезжанная, есть много статей для быстрого старта, но мне хочется собрать их вместе и помочь начинающим разработчикам в изучении этой библиотеки, чтобы они могли стать чуть лучше в программировании.
Dagger 2 — библиотека, которая позволяет реализовать паттерн Dependency Injection. Этот паттерн снижает зависимость объектов друг от друга, а также уменьшает время написания кода. Отличный цикл статей для новичков есть тут. В этих статьях вы найдете много примеров, которые объясняют, для чего нужен Dagger.
В одной из статей прочел пример из реальной жизни, который примерно описывает то, что делает Dagger.
Представьте операционную, где выполняется многочасовая операция. При этом процессе присутствуют хирург и помощник. Хирург занят тем, что оперирует пациента, и ему постоянно необходимо получать разные инструменты: зажимы, скальпели. Он просит помощника подать скальпель. Помощник сам знает, где ему взять этот инструмент, на какой полке он лежит. Хирург же занят своей зоной ответственности — операция, и он отвечает только за это. Зона ответственности помощника — это предоставление всех инструментов, которые могут понадобиться хирургу.
Примерно по такому же принципу и работает паттерн Dependency Injection. Dagger выполняет роль помощника, а наше приложение — хирург, который делает операцию.
Второй цикл статей, который помог мне в освоении этой библиотеки можно найти тут.
На самом деле, вначале может показаться, что библиотека сложная. Такое чувство возникает из-за кода, который генерирует Dagger. Но если немного разобраться в принципах построения графа и почитать этот код, то все встает на свои места.
#разработка #статьи
Мне кажется, что про библиотеку Dagger 2 слышал каждый Android-разработчик. Тема заезжанная, есть много статей для быстрого старта, но мне хочется собрать их вместе и помочь начинающим разработчикам в изучении этой библиотеки, чтобы они могли стать чуть лучше в программировании.
Dagger 2 — библиотека, которая позволяет реализовать паттерн Dependency Injection. Этот паттерн снижает зависимость объектов друг от друга, а также уменьшает время написания кода. Отличный цикл статей для новичков есть тут. В этих статьях вы найдете много примеров, которые объясняют, для чего нужен Dagger.
В одной из статей прочел пример из реальной жизни, который примерно описывает то, что делает Dagger.
Представьте операционную, где выполняется многочасовая операция. При этом процессе присутствуют хирург и помощник. Хирург занят тем, что оперирует пациента, и ему постоянно необходимо получать разные инструменты: зажимы, скальпели. Он просит помощника подать скальпель. Помощник сам знает, где ему взять этот инструмент, на какой полке он лежит. Хирург же занят своей зоной ответственности — операция, и он отвечает только за это. Зона ответственности помощника — это предоставление всех инструментов, которые могут понадобиться хирургу.
Примерно по такому же принципу и работает паттерн Dependency Injection. Dagger выполняет роль помощника, а наше приложение — хирург, который делает операцию.
Второй цикл статей, который помог мне в освоении этой библиотеки можно найти тут.
На самом деле, вначале может показаться, что библиотека сложная. Такое чувство возникает из-за кода, который генерирует Dagger. Но если немного разобраться в принципах построения графа и почитать этот код, то все встает на свои места.
Я уже писал о том, что Kotlin сегодня — лучший язык для написания приложений для Android. Сегодняшний мой совет поможет начинающим разработчикам хорошо прокачать себя в изучении Kotlin.
Помимо того, что Kotlin содержит отличную документацию, есть ещё Try Kotlin, где вы можете прямо в браузере применять свежие знания о языке к небольшим проектам.
Try Kotlin разбит на несколько блоков, каждый из которых состоит из ссылок на конкретный пункт документации, задания и фрагмента кода, которые нужно дописать. Для прохождения задания, нужно дописать код и запустить тесты. Это увлекательное занятие, а знания о языке хорошо усваиваются.
Помимо того, что Kotlin содержит отличную документацию, есть ещё Try Kotlin, где вы можете прямо в браузере применять свежие знания о языке к небольшим проектам.
Try Kotlin разбит на несколько блоков, каждый из которых состоит из ссылок на конкретный пункт документации, задания и фрагмента кода, которые нужно дописать. Для прохождения задания, нужно дописать код и запустить тесты. Это увлекательное занятие, а знания о языке хорошо усваиваются.
Fill RAM
#разработка #приложение
Давненько не писал для вас ничего интересного. Сегодня постараюсь исправить это недоразумение и не пропадать надолго.
Иногда возникают ситуации, когда нужно проверить работу своего приложения в ситуации, когда на телефоне недостаточно оперативной памяти.
Для того, чтобы это сделать можно попытаться открывать одновременно большое количество приложений, которые в итоге действительно займут большую часть оперативной памяти. Но ведь текущие смартфоны порой имеют и 4, и 6, а то и 8 гигабайт оперативной памяти. Такой объем заполнить не так просто и придется захламить кучей приложений телефон.
Для этой цели гораздо комфортнее использовать приложение Fill RAM. Нажав одну кнопку через некоторое время вы получите телефон с заполненной памятью. Теперь краши, связанные с недостатком оперативы будет проще найти и исправить.
#разработка #приложение
Давненько не писал для вас ничего интересного. Сегодня постараюсь исправить это недоразумение и не пропадать надолго.
Иногда возникают ситуации, когда нужно проверить работу своего приложения в ситуации, когда на телефоне недостаточно оперативной памяти.
Для того, чтобы это сделать можно попытаться открывать одновременно большое количество приложений, которые в итоге действительно займут большую часть оперативной памяти. Но ведь текущие смартфоны порой имеют и 4, и 6, а то и 8 гигабайт оперативной памяти. Такой объем заполнить не так просто и придется захламить кучей приложений телефон.
Для этой цели гораздо комфортнее использовать приложение Fill RAM. Нажав одну кнопку через некоторое время вы получите телефон с заполненной памятью. Теперь краши, связанные с недостатком оперативы будет проще найти и исправить.
Android Sunflower
#разработка
На последнем Google IO представили Jetpack, который содержит набор библиотек, помогающий разработчикам эффективно писать приложения.
Документация есть, но удобно видеть пример кода, помогающий быстрее разобраться в инструментах. Совсем недавно мне на глаза попался репозиторий, где содержится пример инструментов из Jetpack, таких как:
• Android KTX — позволяет писать лаконичный и краткий код на Kotlin;
• Navigation — инструмент для создания навигации внутри приложения;
• Room — база данных, обёртка над SQLite (упоминал, кстати, о ней);
• WorkManager — работа с фоновыми операциями в Android.
Помимо этих, в проекте использовано куча других инструментов из Jetpack. Рекомендую для ознакомления и изучения.
#разработка
На последнем Google IO представили Jetpack, который содержит набор библиотек, помогающий разработчикам эффективно писать приложения.
Документация есть, но удобно видеть пример кода, помогающий быстрее разобраться в инструментах. Совсем недавно мне на глаза попался репозиторий, где содержится пример инструментов из Jetpack, таких как:
• Android KTX — позволяет писать лаконичный и краткий код на Kotlin;
• Navigation — инструмент для создания навигации внутри приложения;
• Room — база данных, обёртка над SQLite (упоминал, кстати, о ней);
• WorkManager — работа с фоновыми операциями в Android.
Помимо этих, в проекте использовано куча других инструментов из Jetpack. Рекомендую для ознакомления и изучения.
ButterKnife или Data binding?
#разработка #библиотеки
Сегодня на работе спорили о том, что лучше использовать: ButterKnife или Data binding?
Помню, что когда ещё не было ButterKnife, то приходилось писать
Не так давно появился Data Binding. Для использования нужно немного модифицировать xml-файл разметки и написать в Activity
Какие плюсы у ButterKnife? Например, есть другие аннотации, которые упрощают работу, например:
В Data Binding же мы получаем мощный инструмент для работы с адаптерами в
С появлением Kotlin появились
Так уж повелось, то в Java-проектах я использую ButterKnife, а в новых, написанных на Kotlin проектах — Kotlin Extensions. С Binding сталкивался на ранних этапах его появления, но уверен, что это отличный инструмент.
А что больше нравится вам?
🔴 — ButterKnife;
🔵 — Data Binding;
⚫️ — Kotlin Extensions.
#разработка #библиотеки
Сегодня на работе спорили о том, что лучше использовать: ButterKnife или Data binding?
Помню, что когда ещё не было ButterKnife, то приходилось писать
findViewById, после чего кастовать найденную View к нужной. Было слишком много лишнего кода. Например, если в вашей Activity есть 10 View, то для использования их нужно было писать 20 строк кода с findViewById. С появлением в проектах ButterKnife число строк сократилось вдвое, и теперь нужно было просто написать @BindView(R.id.textView) TextView text.Не так давно появился Data Binding. Для использования нужно немного модифицировать xml-файл разметки и написать в Activity
ActivityMainBinding binding = DataBindingUtil.setContentView(this, R.layout.activity_main);, после чего у вас появляется доступ к вашему layout напрямую: binding.textView. Количество View не играет никакой роли при использовании Data Binding. Ведь строк кода всегда остается только 2!Какие плюсы у ButterKnife? Например, есть другие аннотации, которые упрощают работу, например:
@OnClick, @OnItemSelected, @BindColor. Также можно примененить аннотации на несколько View.В Data Binding же мы получаем мощный инструмент для работы с адаптерами в
RecyclerView, возможность делать кастомные атрибуты и много других интересных и удобных инструментов.С появлением Kotlin появились
kotlin-android-extensions, которые ещё больше упростили базовую работу с View. Так уж повелось, то в Java-проектах я использую ButterKnife, а в новых, написанных на Kotlin проектах — Kotlin Extensions. С Binding сталкивался на ранних этапах его появления, но уверен, что это отличный инструмент.
А что больше нравится вам?
🔴 — ButterKnife;
🔵 — Data Binding;
⚫️ — Kotlin Extensions.
Скорость сборки проекта
#разработка
Каждый раз, когда собираю основной рабочий проект, то берет грусть от времени сборки.
И вот, когда время сборки проекта стало приближаться к 5 минутам, то решил найти варианты решения этой проблемы.
На последнем Mobius был доклад, в котором автор рассказывал про уменьшение времени сборки проекта. Главным аргументом для этого было разбиение проекта на модули.
Думаю, что проблемы долгой сборки у большинства крупных проектов одинаковые:
• Annotation processing;
• переплетенность модулей между собой;
• Data binding и Dagger в каждом модуле;
• огромный модуль и Application модуль.
Первые шаги, которые помогут уменьшить время сборки проекта:
1) Использование
2) Ядро приложения должно быть максимально тонким. Сюда лучше всего добавлять только интерфейсы, а все реализации описываются в конкретной фиче.
3) Код приложения нельзя шарить между модулями.
4) Модули не должны взаимодействать друг с другом.
Также стоит помнить про инструмент
Чтобы лучше разобраться с модульностью рекомендую ознакомиться с проектом.
#разработка
Каждый раз, когда собираю основной рабочий проект, то берет грусть от времени сборки.
И вот, когда время сборки проекта стало приближаться к 5 минутам, то решил найти варианты решения этой проблемы.
На последнем Mobius был доклад, в котором автор рассказывал про уменьшение времени сборки проекта. Главным аргументом для этого было разбиение проекта на модули.
Думаю, что проблемы долгой сборки у большинства крупных проектов одинаковые:
• Annotation processing;
• переплетенность модулей между собой;
• Data binding и Dagger в каждом модуле;
• огромный модуль и Application модуль.
Первые шаги, которые помогут уменьшить время сборки проекта:
1) Использование
implementation вместо api в gradle.2) Ядро приложения должно быть максимально тонким. Сюда лучше всего добавлять только интерфейсы, а все реализации описываются в конкретной фиче.
3) Код приложения нельзя шарить между модулями.
4) Модули не должны взаимодействать друг с другом.
Также стоит помнить про инструмент
gradlew clean assembleDebug --scan. Он покажет интерактивную диаграмму с этапами сборки проект.Чтобы лучше разобраться с модульностью рекомендую ознакомиться с проектом.
Бывают ситуации, когда необходимо создать фон для изображения, но не в виде цвета, а в виде повторяющегося изображения.
Многие, особенно в начале своего пути, используют просто повторяющиеся фоновое изображение. Однако, такой подход не самый лучший, так как нужно хранить полное изображение, что ведет к увеличению размеров apk-файла. Предлагаю использовать данный #совет, чтобы уйти от этой проблемы.
В Android можно очень просто создать повторяющийся фон:
1) Вырежьте небольшой кусок того фрагмента, который будет повторяться
2) Добавьте новый
Подробнее можно прочитать тут
Многие, особенно в начале своего пути, используют просто повторяющиеся фоновое изображение. Однако, такой подход не самый лучший, так как нужно хранить полное изображение, что ведет к увеличению размеров apk-файла. Предлагаю использовать данный #совет, чтобы уйти от этой проблемы.
В Android можно очень просто создать повторяющийся фон:
1) Вырежьте небольшой кусок того фрагмента, который будет повторяться
2) Добавьте новый
drawable, где создайте <bitmap>, указав src и android:tileMode="repeat"Подробнее можно прочитать тут
Найм
#мысли
Около недели назад послушал свежий выпуск подкаста Про найм. А тут вторая часть. Я, например, нашёл там несколько интересных пунктов:
1) Не стоит указывать среди первых своих навыков кроссплатформенные фреймворки, типа Xamarin. Если собеседуетесь на вакансию Android разработчика, то лучше сосредоточиться на его навыках и используемых библиотеках. Из своего опыта собеседований могу сказать, что о таком человеке складывается мнение, что он не знаком ни с чем, а попробовал все на уровне тестовых и документации. Если же вы чувствуете свою мощь, то составьте несколько резюме для каждой из вакансий.
2) Пробуйте приложение и сервис той компании, куда собираетесь пойти. Конечно, если это не какой-то закрытый проект. Если вы предложите интересные идеи для улучшения проекта, то это увеличит ваши шансы на оффер.
3) Прокачивайте теоретическую и алгоритмическую базу. Поэтому заходите на HackerRank, чтобы решить пару задач.
Ну и еще много всего интересного про найм в этом выпуске. Кстати, всегда заглядывайте в ссылки, которые опубликованы в выпуске. Там можно найти и список вопросов для собеседования и много полезных сервисов. Ну и слушайте этот подкаст, если еще не делаете этого. Группа для обсуждения подкаста тут.
Например увидел несколько отличных сайтов для составления резюме онлайн. Это не простая задача, как может показаться на первый взгляд.
#мысли
Около недели назад послушал свежий выпуск подкаста Про найм. А тут вторая часть. Я, например, нашёл там несколько интересных пунктов:
1) Не стоит указывать среди первых своих навыков кроссплатформенные фреймворки, типа Xamarin. Если собеседуетесь на вакансию Android разработчика, то лучше сосредоточиться на его навыках и используемых библиотеках. Из своего опыта собеседований могу сказать, что о таком человеке складывается мнение, что он не знаком ни с чем, а попробовал все на уровне тестовых и документации. Если же вы чувствуете свою мощь, то составьте несколько резюме для каждой из вакансий.
2) Пробуйте приложение и сервис той компании, куда собираетесь пойти. Конечно, если это не какой-то закрытый проект. Если вы предложите интересные идеи для улучшения проекта, то это увеличит ваши шансы на оффер.
3) Прокачивайте теоретическую и алгоритмическую базу. Поэтому заходите на HackerRank, чтобы решить пару задач.
Ну и еще много всего интересного про найм в этом выпуске. Кстати, всегда заглядывайте в ссылки, которые опубликованы в выпуске. Там можно найти и список вопросов для собеседования и много полезных сервисов. Ну и слушайте этот подкаст, если еще не делаете этого. Группа для обсуждения подкаста тут.
Например увидел несколько отличных сайтов для составления резюме онлайн. Это не простая задача, как может показаться на первый взгляд.
RxJava: flatMap, switchMap и concatMap
#разработка
Это достаточно распространные операторы, и между ними есть существенная разница, о которой стоит помнить. В качестве примера для списка элементов "a", "b", "c", "d", "e", "f" применяется фукнция конкатенации x. Вот краткое объяснение:
• flatMap — применяет функцию к каждому элементу, соединяет элементы вместе и после чего возвращает Observable. Следует помнить, что элементы могут чередоваться, поэтому функция не заботится о порядке возвращения. В примере увидим cx, ex, fx, bx, dx, ax.
• switchMap — в отличии от flatMap, при получении нового элемента отписывается и перестает отображать предыдущие элементы, и наблюдает только за текущим. В примере увидим fx.
• concatMap — в отличии от flatMap, заботится о порядке элементов. При этом ему необходимо дождаться, пока каждый из элементов завершит свою работу перед получением нового. Поэтому, этот оператор нужно использовать осторожно. В примере увидим ax, bx, cx, dx, ex, fx.
Больше объяснений и примеров использования операторов тут.
#разработка
Это достаточно распространные операторы, и между ними есть существенная разница, о которой стоит помнить. В качестве примера для списка элементов "a", "b", "c", "d", "e", "f" применяется фукнция конкатенации x. Вот краткое объяснение:
• flatMap — применяет функцию к каждому элементу, соединяет элементы вместе и после чего возвращает Observable. Следует помнить, что элементы могут чередоваться, поэтому функция не заботится о порядке возвращения. В примере увидим cx, ex, fx, bx, dx, ax.
• switchMap — в отличии от flatMap, при получении нового элемента отписывается и перестает отображать предыдущие элементы, и наблюдает только за текущим. В примере увидим fx.
• concatMap — в отличии от flatMap, заботится о порядке элементов. При этом ему необходимо дождаться, пока каждый из элементов завершит свою работу перед получением нового. Поэтому, этот оператор нужно использовать осторожно. В примере увидим ax, bx, cx, dx, ex, fx.
Больше объяснений и примеров использования операторов тут.
👍1
На канале был пост о том, где лучше работать, в большой компании или в стартапе.
Я сменил свое место работы, и теперь работаю удаленно в стартапе. Это интересный опыт. Сейчас вливаюсь в рабочий процесс и вникаю в проект.
Что я понял за неделю работы удаленно?
1) Важно, чтобы дома было рабочее место. Ни в коем случае нельзя работать на кровати. Это значительно уменьшает производительность.
2) Необходимо контролировать рабочие часы. Для себя я решил работать по технике Pomodoro. Не стоит перерабатывать, иначе есть шанс просто перегореть.
3) Нужно делать перерывы и отвлекаться от компьютера. Хотя бы иногда стоит разминаться, пить воду и не забывать про обед.
Для меня это новый опыт, дальше обязательно напишу о плюсах и минусах удаленной работы.
Я сменил свое место работы, и теперь работаю удаленно в стартапе. Это интересный опыт. Сейчас вливаюсь в рабочий процесс и вникаю в проект.
Что я понял за неделю работы удаленно?
1) Важно, чтобы дома было рабочее место. Ни в коем случае нельзя работать на кровати. Это значительно уменьшает производительность.
2) Необходимо контролировать рабочие часы. Для себя я решил работать по технике Pomodoro. Не стоит перерабатывать, иначе есть шанс просто перегореть.
3) Нужно делать перерывы и отвлекаться от компьютера. Хотя бы иногда стоит разминаться, пить воду и не забывать про обед.
Для меня это новый опыт, дальше обязательно напишу о плюсах и минусах удаленной работы.
Live Templates
#разработка #совет
При длительном написании кода, усталость разработчика накапливается, поэтому он может совершить простые ошибки в коде, которые никогда бы не совершил при ее отсутствии.
Уверен, что каждый совершал описку в этом коде:
Чтобы уменьшить количество таких простых ошибок и сократить количество повторяющегося кода, созданы Live Templates. Есть большое количество шаблонов, встроенных в студию. Посмотреть их можно в настройках File > Settings > Editor > Live Templates.
В нашем случае достаточно было написать Toast, чтобы получить шаблон для всплывающего сообщения.
Подробнее о написании своих Live Templates можно почитать тут.
#разработка #совет
При длительном написании кода, усталость разработчика накапливается, поэтому он может совершить простые ошибки в коде, которые никогда бы не совершил при ее отсутствии.
Уверен, что каждый совершал описку в этом коде:
Toast.makeText(this, "Text to show»);Toast не покажется, потому что мы забыли написать в конце .show(). Среда подскажет об ошибке, однако в других случаях этого может не произойти.Чтобы уменьшить количество таких простых ошибок и сократить количество повторяющегося кода, созданы Live Templates. Есть большое количество шаблонов, встроенных в студию. Посмотреть их можно в настройках File > Settings > Editor > Live Templates.
В нашем случае достаточно было написать Toast, чтобы получить шаблон для всплывающего сообщения.
Подробнее о написании своих Live Templates можно почитать тут.
В сообщения пришел #вопрос: сколько необходимо опыта и что еще нужно соблюдать для перехода на удаленку? Все, что написано ниже — только мое мнение.
Считаю, что не нужно выбирать удаленную работу в качестве первой работы.
Во-первых, достаточно сложно будет найти подобную работу. Если на офисную работу часто требуются люди с хоть каким-то опытом, то на удаленную работу эти требования растут еще выше.
Во-вторых, обучаться и получать опыт на первоначальном этапе комфортнее в офисе. Говорю это по своему опыту, возможно у кого-то иначе: моя первая работа была в офисе, и не уверен, что получил бы те навыки, находясь дома.
Поэтому, рассматривать удаленную работу стоит после хотя бы одного года работы в офисе с командой.
На что еще обратить внимание, если рассматриваете удаленную работу? Думаю, что это личные качества. Поймите, интроверт вы или экстраверт. Если экстраверт, то будет тяжелее, чем в офисе. Вам будет не хватать живого общения с коллегами. Ну и корпоративные вещи, например поздравление с днем рождения и поедание пиццы, также уйдут. Кроме этого решите для себя, какая у вас мера ответственности. Если сложно заставить себя не смотреть очередную серию любимого сериала, то удаленка точно не для вас.
Некоторых людей останавливает общение с коллегами. Для многих комфортно подойти к коллеге и поговорить с ним лично. К сожалению, для связи чаще всего будет чат. Но, как по мне, это не особо критичный пункт.
Всегда рад ответить на ваши сообщения тут.
Считаю, что не нужно выбирать удаленную работу в качестве первой работы.
Во-первых, достаточно сложно будет найти подобную работу. Если на офисную работу часто требуются люди с хоть каким-то опытом, то на удаленную работу эти требования растут еще выше.
Во-вторых, обучаться и получать опыт на первоначальном этапе комфортнее в офисе. Говорю это по своему опыту, возможно у кого-то иначе: моя первая работа была в офисе, и не уверен, что получил бы те навыки, находясь дома.
Поэтому, рассматривать удаленную работу стоит после хотя бы одного года работы в офисе с командой.
На что еще обратить внимание, если рассматриваете удаленную работу? Думаю, что это личные качества. Поймите, интроверт вы или экстраверт. Если экстраверт, то будет тяжелее, чем в офисе. Вам будет не хватать живого общения с коллегами. Ну и корпоративные вещи, например поздравление с днем рождения и поедание пиццы, также уйдут. Кроме этого решите для себя, какая у вас мера ответственности. Если сложно заставить себя не смотреть очередную серию любимого сериала, то удаленка точно не для вас.
Некоторых людей останавливает общение с коллегами. Для многих комфортно подойти к коллеге и поговорить с ним лично. К сожалению, для связи чаще всего будет чат. Но, как по мне, это не особо критичный пункт.
Всегда рад ответить на ваши сообщения тут.