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

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

Disclaimer

• Статья не претендует на открытие Америки и носит популяризаторско-реферативный характер. Способы борьбы с NPE в коде далеко не новые, но намного менее известные, чем этого хотелось бы.
• Разовый NPE — это, наверное, самая простая из все возможных ошибок. Речь идет именно о ситуации, когда из-за отсутствия политики их обработки наступает засилье NPE.
• В статье не рассматриваются подходы, не применимые для Java 6 и 7 (монада MayBe, JSR-308 и Type Annotations).
• Повсеместное защитное программирование не рассматривается в качестве метода борьбы, так как сильно замусоривает код, снижает производительность и в итоге все равно не дает нужного эффекта.
• Возможны некоторые расхождения в используемой терминологии и общепринятой. Так же описание используемых проверок Intellij Idea не претендует на полноту и точность, так как взято из документации и наблюдаемого поведения, а не исходного кода.

JSR-305 спешит на помощь

Здесь я хочу поделиться используемой мной практикой, которая помогает мне успешно писать почти полностью NPE-free код. Основная ее идея состоит в использовании аннотаций о необязательности значений из библиотеки, реализующей JSR-305 (com.google.code.findbugs: jsr305: 1.3.9):

• @Nullable — аннотированное значение является необязательным;
• @Nonnull — соответственно наоборот.

Естественно обе аннотации применимы к полям объектов и классов, аргументам и возвращаемым значениям методов, локальным переменным. Таким образом эти аннотации дополняют информацию о типе в части обязательности наличия значения.

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

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

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

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

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

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

Уже очень скоро завершится набор в Школу мобильной разработки, которая традиционно пройдет в Москве. Упор в ней будет сделан на практические занятия — командные мини-хакатоны, в которых помимо написания кода нужно будет принимать решения, разбираться с возникшими спорными вопросами и заниматься долгосрочным планированием. Помогать студентам — каждой команде индивидуально — будут ребята из Яндекса. Более подробно о предстоящей школе можно почитать здесь. Мы закончим принимать заявки 6 мая в 23:59 по московскому времени, а пока ещё есть время на выполнение заданий, мы решили разобрать прошлогодний вариант. Вы узнаете, какие ошибки часто допускают начинающие разработчики и чему следует уделить внимание при написании кода вашего первого приложения.



Традиционно задание построено так, чтобы мы могли обратить внимание на разные аспекты разработки. К ним относится архитектура приложения, стабильность, производительность, верстка, удобство использования. Все составляющие одинаково важны: даже идеально причесанный и разложенный на слои код с большой вероятностью не пройдет отбор, если возникнут проблемы в интерфейсе или падения в процессе выполнения базовых пользовательских сценариев. Универсального рецепта приготовления идеального приложения, которое гарантированно пройдёт отбор, нет. Есть множество подходов к разработке и разные варианты построения архитектуры, но одна из составляющих успеха — позитивные пользовательские ощущения. Продукт должен создавать впечатление законченности, независимо от того, сколько в нем полезной функциональности, экранов или элементов.

Привет, Хабр! Представляю вашему вниманию перевод статьи Аллена Б. Дауни, автора таких книг как Think Python, Think Java, Think Bayes и других, опубликованной в личном блоге автора.

Я написал несколько книг, в которых c использованием языка программирования Python объясняются темы вроде Байесовской статистики и цифровой обработки сигналов. В дополнение к книгам читатели могут загрузить код с GitHub. Для того, чтобы использовать этот код, нужно знать некоторые основы Python. То есть, у читателей должен быть компьютер, на котором установлен интерпретатор этого языка и необходимые библиотеки, они должны знать, как загрузить код с GitHub, а еще они должны знать, как запустить код, который они загрузили.

Пытаясь проделать все это, многие читатели начинают испытывать трудности.

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

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

Позвольте объяснить мое понимание проблемы и предложить несколько решений (или как минимум, обходных путей).

Realm давно известен в среде мобильных (и не только) разработчиков. К сожалению, в рунете почти нет статей об этой базе данных. Давайте исправим эту ситуацию.

Год назад в build.gradle нашего проекта появилась строчка:

classpath "io.realm:realm-gradle-plugin:0.87.5" 

За этот год код Realm вырос до версии 3.3, обзавелся множеством фич и починил кучу багов, реализовал новый функционал и получил облачный бекенд. Давайте поподробнее поговорим о Realm в реалиях Andoroid разработки и обсудим тонкие моменты, возникающие при его использовании.

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

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

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

На прошедшем в конце ноября митапе по разработке на Dart Александр Дорошко из JetBrains рассказал о полезных фичах, хинтах и горячих клавишах, которые упрощают работу в Intellij Idea и WebStorm.
Нам показалось, что доклад будет полезен не только дарт-разработчикам, поэтому делимся записью презентации Александра со всем широким кругом хабровчан.

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

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

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

Данная статься познакомит вас с разработкой простого приложения для Android TV. В первую очередь она ориентированна на тех, кто уже имел какой-либо опыт в разработке приложений для Android, поэтому я не буду здесь объяснять что такое Activity, Fragments и т.д.

В интернете есть много русскоязычной информации по разработке приложений для Android и не мало статей по написанию HelloWord для него же. Заинтересовавшись разработкой приложений для Android TV, я сразу же начал изучать эту тему на англоязычных сайтах. К моему удивлению материала оказалось не так уж и много, и я решил посмотреть что же есть на русском. На русском ничего найти не удалось (возможно плохо искал). В общем я намерен исправить эту ситуацию.

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

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

Я не самый талантливый кодер в мире. Правда. Так что я стараюсь писать как можно меньше кода. Чем меньше кода я пишу, тем меньше кода может ломаться, поддерживаться и требовать пояснений.

А еще я ленивый — мед, да еще и ложкой (я решил использовать в статье аналогии с едой).

Но, оказывается, что единственный гарантированный способ повысить производительность в вебе — это писать меньше кода. Минифицировать? Окей. Сжимать? Ну, да. Кэшировать? Звучит неплохо. Вообще отказываться кодить или использовать чужой код изначально? А вот теперь — в яблочко! Что есть на входе — должно выйти на выходе в той или иной форме, независимо от того, смог ли ваш сборщик растворить и переварить это своими желудочными соками (я, пожалуй, откажусь от пищевых аналогий).

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

В стремлении к уменьшению мне больше всего нравится вот что: в конце остается только то, что реально нужно, только то, что по-настоящему требуется пользователю. Огромная фотка какого-то чувака, пьющего латте? Выкинуть. Кнопки социальных сетей, которые подсасывают кучу левого кода и ломают дизайн страницы? Пинок под зад им. Эта хреновина на JavaScript, которая перехватывает правый клик и показывает кастомное модальное окно? Выставить на мороз!

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

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

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

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

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



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

Сергей Алешин обсуждает проблему «возвратной» навигации в мобильных приложениях:

• При потреблении контента кнопка Back должна вести себя аналогично кнопке Back в браузере
• Если же речь идет об изменении (создании) содержания, у этой кнопки появляется двойственный смысл — то ли Back, то ли Undo.

Сравниваются приложения под iOS, Android и Windows Phone.
Помимо этого Сергей рассказал про bluetooth-адаптер, в разработке которого он участвует, и который позволит слушать и понимать свой автомобиль ;)

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

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



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

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

29 августа на конференции OGIC (Online Games Industry Conference) Владимир Верховский рассказал как нужно продвигать мобильные приложения.

В этом докладе не будет 20-минутного рассказа о том, что нужно делать красивую иконку и корректное описание, об этом в курсе каждый второй разработчик в App Store. Если вам интересно, что означают аббревиатуры eCPM, CPC, СPD, ARPU, RAL и как приложения попадают в ТОП, то это видео для вас.


Текстовая расшифровка и презентация

Подробнее о продвижении мобильных приложений