ViewPager — один из самых известных и широко используемых компонентов Android Support Library. Все простейшие карусели, онбординги и слайдеры в мобильных приложениях для Android выполнены именно на нем. В феврале 2019 года команда разработки AndroidX выпустила ViewPager2. Давайте разберемся, какие у этого были предпосылки и какими преимуществами обладает обновленная версия компонента.

Прошедший Google I/O 2019 принёс массу нашумевших новинок, многие из которых будут влиять на индустрию мобильной разработки в ближайшие годы. Не менее интересно было следить за зарождающимися трендами. Сначала в историю ушли механические клавиши управления, экраны смартфонов становились всё больше, а боковые рамки всё незаметнее. На смену экранным системным кнопкам пришли жесты, оставляя всё больше пространства для потребления контента. Приложения отображаются на всей видимой поверхности дисплея, от нижней до верхней рамки, не стесняя себя условными границами статус-бара и навигационной панели. Мы на пороге эры Edge-to-Edge.

Прим. ред.: Этой статьёй мы начинаем цикл публикаций, посвящённых английскому языку и подготовленных нашим штатным учителем для инженеров компании (в данном случае — на основе видеоурока engVid, JamesESL English Lessons). С одной стороны — нам нужно изучать язык, с другой — нравится это делать, а с третьей — почему бы не разбавить технические материалы своего блога? Ваши отзывы очень приветствуются!

Слово «very» очень популярно в английском языке, да и не только. Однако, употребляя его слишком часто, вы можете прослыть косноязычным или попросту Эллочкой-людоедочкой.



Как известно, в великом романе-эпопее «Война и Мир» Лев Николаевич не совершает повторов на протяжении каждых трех страниц(!). Не это ли искусство? Однако, не будем долго мечтать — let's get down to business.

Я хотела бы начать этот пост очень пафосно. Например, так: «Я работаю в бизнесе уже 10 лет, получила железное сердце и обросла панцирем». Или так: «Да-да, Хабр, я работник коммерческой службы: когда-то аналитик, потом продажник, потом маркетолог. Я тот самый, кого вы все не любите». В конце концов, именно так должен выглядеть пост первого января. Но нет. Никакого пафоса и романтики. Работаю в коммерции ИТ-компаний некруглые 11,5 лет. Была всем: разработчиком, проджектом, маркетологом, продажником, внедренцем, редактором, ИТ-консультантом. До этого была на госслужбе и преподавала. И я сегодня, несмотря на сто доводов против, могу сказать: «Бизнес, я люблю тебя!» Ну понятно, что развитие этой мысли под катом.

Я решил написать эту статью, потому что в интернете мало информации именно о переезде в Норвегию. Люди в основном описывают жизнь, процесс поиска работы и тому подобное. Ниже я постарался рассказать о подготовке документов, регистрации в стране, открытии банковского счёта, аренде квартиры и т.п. Надеюсь, это будет полезно.

Продолжение.

Всем привет!

Не так давно мы с вами осознали, что мобильное приложение — это не просто тонкий клиент, а это действительно большое количество самой разной логики, которое нуждается в упорядочивании. Именно поэтому мы прониклись идеями Clean architecture, прочувствовали, что такое DI, научились использовать Dagger 2, и теперь с закрытыми глазами способны разбить любую фичу на слои.

Но мир не стоит на месте, и с решением старых проблем приходят новые. И имя этой новой проблемы — мономодульность. Обычно об этой проблеме узнаешь, когда время сборки улетает в космос. Именно так и начинаются многие доклады про переход на многомодульность (раз, два).
Но почему-то все при этом как-то забывают, что мономодульность сильно бьет не только по времени сборки, но и по вашей архитектуре. Вот ответьте на вопросы. На сколько у вас AppComponent большой? Не встречаете ли вы периодически в коде, что фича А зачем-то дергает репозиторий фичи Б, хотя вроде такого быть не должно, ну или оно должно быть как-то более верхнеуровнево? Вообще у фичи есть какой-то контракт? А как вы организовываете общение между фичами? Есть какие-то правила?
Вы чувствуете, что мы решили проблему со слоями, то есть вертикально все вроде хорошо, но вот горизонтально что-то идет не так? И просто разбиением на пакеты и контролем на ревью не решить проблему.

И контрольный вопрос для более опытных. Когда вы переезжали на многомодульность, не приходилось ли вам перелопачивать половину приложения, вечно перетаскивать код с одного модуля в другой и жить с несобирающимся проектом приличный отрезок времени?

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

— За что тебя приняли, за то и уволят. – тяжело вздохнув, сказал Боб. – Слышал такую фразу?

— Нет. – угрюмо ответил Джон.

— Ты помнишь, почему я взял тебя в тимлиды? – Боб отвернулся от Джона и уставился в окно.
Вид с двадцать пятого этажа открывался шикарный, но, похоже, Боб его не видел.

— У меня своя версия. – тихо сказал Джон. – Кажется, дело было в скраме.

— Да, дело было в скраме. – кивнул Боб, все еще глядя в окно. – И я, если честно, уже не могу про него слышать. Не хочу говорить высокопарных слов, но ты меня обманул.

— Я? – недоуменно спросил Джон.

— Ты и скрам. Твой скрам. Твоя инициатива. – Боб повернулся и в упор уставился на Джона. Которая будет стоит мне проекта. И кучи денег.

Преамбулка

Эта статья является анализом другой статьи: Если вы не нанимаете джунов, то не заслуживаете сеньоров

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

Я оставил по возможности оригинальное оформление, а свои комментарии отметил отдельно.

Ну и желтый заголовок тоже оставил, немного видоизменив.

Поехали.

1. Введение в реактивное программирование

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

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

RxJava — реализация ReactiveX с открытым исходным кодом на Java. Базовыми строительными блоками реактивного кода являются Observables и Subscribers. Подробнее с базовой основой можно ознакомиться в статье Грокаем* RxJava, часть первая: основы.

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

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

Итак, с чего начать?



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

Немного подробнее остановимся на каждом пункте.

Здравствуйте все.

Мы продолжаем знакомить вас с нашим издательским поиском, и хотели прозондировать общественное мнение на тему RxJava.



В ближайшее время собираемся опубликовать более общий материал по реактивному программированию, которое нас также интересует не первый год, а сегодня предлагаем почитать о применении RxJava в Android, так как именно на этой платформе особенно важна динамичность и быстрота реагирования. Добро пожаловать под кат

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

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

На Хабре уже есть похожие статьи на тему сборки Android приложения с помощью Jenkins. Ключевыми особенностями/дополнениями текущей будет следующее:

1. Мы установим Jenkins на удалённую Linux машину, где отсутствует UI.
2. Мы будем собирать приложение из приватного репозитория.
3. Мы решим проблему сборки приложения из ветки имя которой нам не известно.
4. После сборки .apk файлов мы отправим их в Fabric и оповестим тестировщиков.
5. После отправления в Fabric мы опубликуем приложение на Google Play.
6. Защитим задачи по публикации приложения от запуска тестировщиками.

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

И извините за котов. Они совершенно никакого отношения не имеют к игрострою. Я тут параллельно учусь (пытаюсь учиться) рисовать и теперь эти мои тренировочные коты просто повсюду! Требуют чтобы их, бездельников, кому-нибудь показывали.

Здравствуйте! В свое время зачитываясь рассказами про эмиграцию в страну N, я мечтал, что когда-нибудь и я совершу нечто подобное, а затем опишу свой опыт. Что же, навязчивые мечты сбываются, и теперь пришел черед моего рассказа — и на этот раз речь пойдет об иммиграции в Болгарию.

В данной статье я вкратце опишу процесс получения сертификата начинающего андроид разработчика. Разработкой под андроид я занимаюсь уже более 4-х лет, но до настоящего момента так и не удосужился обзавестись никаким соответствующим сертификатом, хотя парочкой сертификатов по Java я обзавелся. А сложилось так по одной простой причине — сертификаты андроид разработчиков выдавали какие угодно компании, кроме собственно компании разработчика этого самого Android. Вышеупомянутые Java сертификаты были выданы компанией Oracle, что делает их наличие хоть немного осмысленными.

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

При разработке Android приложений наступают моменты, когда те или иные части кода можно вынести в виде библиотек, чтобы можно было переиспользовать их в разных проектах:

• Модули в проекте, которые часто встречаются. Например, кастомные View
• Когда существующий API неудобный или не позволяет сделать то, что задумали — создаем расширение для этого API

Чаще всего все проблемы были решены задолго до нас, но в нашем случае нужно было вынести часть слоя бизнес-логики и фактически весь слой, отвечающий за данные в 3 наших основных продукта объединенной компании Колёса Крыша Маркет. Все наши продукты – классифайды про автомобили, недвижимость и прочие товары. Поэтому нами, разработчиками, было решили написать одно решение для всех продуктов компании. К тому же, это облегчило нашу работу.

Приветствую, коллеги. Рад видеть вас снова в третьей части «Руководства по фоновой работе в Android». Если не видели предыдущие части, вот они:

• Часть 1: AsyncTask
• Часть 2: Loaders

В прошлый раз мы разобрались, как работают Loaders, а сразу после этого Google взял и сообщил, что они полностью переписали LoaderManager. Видимо, мне надо позже вернуться к этой теме, но пока что буду следовать плану и делиться подробностями того, как организовать фоновую работу в Android исключительно с помощью джавовых thread pool executors, а также как EventBus может помочь в этом, и как всё это работает под капотом.

Здесь описаны мои исследования, как сделать ревизию кода в команде более приятным занятием, которое может дать новый опыт всем участникам. У нас полностью географически распределённая команда, все коммуникации выполняются через интернет, и зачастую асинхронно. Мы используем Trello для описания возможностей продуктов, поодиночке создаём код, отправляем в GitHub пулл-реквесты, а также пользуемся встроенной в GitHub функцией их ревью. Это отличается от просмотра кода лицом к лицу в офисе и даже по видеочату.

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

Привет! Последние несколько лет я занимался фрилансом на Upwork (бывший oDesk) и вот наконец решился поделиться своим опытом и наблюдениями с Хабрасообществом в небольшом цикле статей. Начать хотелось бы издалека: кому на мой взгляд стоит рассмотреть фриланс как основной вид своей деятельности + хотелось бы разобрать основные «отпугивающие» факторы, которые мешают многим решиться. Кому небезразлична тема фриланса и Upwork в частности — добро пожаловать под кат.