12 советов разработчику Андроид приложений

советы разработчику Андроид приложений

Вот уже год я занимаюсь поддержкой приложения в Google Play. За это время приложение установили сотни тысяч раз, а пользовательская база разрослась до десятков тысяч. Каждый день я получаю отзывы и письма, сообщения об ошибках и пишу код. Эта статья — советы для тех, кто только начинает свой путь в Google Play и желает сохранить хотя бы часть головы свободной от шишек.

РЕКОМЕНДУЕМ!
Частые проблемы кодинга Android-разработчика

Научитесь правилам гигиены

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

Если хотите быстро получить ответ от разработчика, просто напиши вопрос и поставьте одну звезду. Такая модель поведения появилась благодаря крупным разработчикам с собственной службой поддержки, которая просто обязана отвечать на все отзывы с плохими оценками (они обычно пишут тошнотворное «Мы рады, что вы скачали наше приложение» в начале каждого ответа). Таких ребят лучше игнорить, после получения ответа они не исправят оценку.

Вы ничего не умеете, сидите на шее у родителей и чувствуете себя никем? Просто напишите гадость в отзывах. Опять же игнор, плюс жалоба Google (это легко, достаточно нажать на флажок). Отзывы с матом Google удалит сам.

Вы купили китайское гуано вместо телефона? Виноваты разработчики приложений! Android настолько фрагментирован, что, даже если вы вылизали приложение до блеска, оно все равно будет работать криво на десятках и сотнях моделей телефонов. Выхода из ситуации два: первый — объяснять каждому юзеру, как обойти его проблему на конкретном телефоне, второй — пойти по пути разработчиков VLC. Они, напомню, просто заблокировали половину моделей Huawei, потому что механизм энергосбережения этих смартфонов прибивал плеер во время просмотра видео.

стать разработчиком приложений на андроид
А вот так делать не стоит

Хорошая техподдержка не менее важна, чем хороший код

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

Общение с технически неграмотной аудиторией может быть очень болезненным и стоить миллионы нервных клеток. Но это совсем не значит, что пользователей нужно игнорировать и уж тем более посылать далеко.

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

Я стараюсь отвечать всем, независимо от того, насколько банальный вопрос задает пользователь. Есть только два способа сделать так, чтобы я намеренно не ответил: написать не имеющее отношения к приложению письмо и начать спамить одинаковыми вопросами. Остальным: добро пожаловать.

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

Никогда ничего не обещайте

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

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

Никто не читает документацию

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

Что с этим делать? Конечно же, постараться сделать интерфейс приложения настолько понятным, чтобы никакие пояснения просто не требовались. Проблема только в том, что это не всегда возможно сделать. Эффективность использования и наглядность интерфейса пересекаются не так уж часто, и во многих ситуациях без пояснений просто не обойтись. Вы будете пояснять эти моменты в ответных письмах, в отзывах на Google Play, на форумах. Каждый раз по новому.

Не торопитесь

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

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

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

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

Не делайте быстро, делайте правильно

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

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

Лучше мало превосходно работающих функций, чем много недоработанных

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

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

Не доверяйте чужому коду

Stack Overflow полностью изменил подход к написанию приложений. Сегодняшние программисты не читают документацию и не ведут многочасовые беседы с коллегами. Они идут на SO и просто копируют ответ, набравший большее количество голосов. Выбор библиотек зачастую не более сложный: где звездочек на GitHub больше, то и лучше.

Что мы получаем в результате? Забагованные, уязвимые и медленные приложения. Большое количество голосов или звездочек не означает, что код корректен. Сниппет кода мог устареть; те, кто ставил оценки, могли не брать в расчет безопасность и скорость; в конце концов, код может просто не подойти для вашей конкретной ситуации.

То же самое касается библиотек. Не все разработчики настолько опытные и продвинутые, как ребята из Square. Программисты делают ошибки, недостаточно хорошо проверяют библиотеку, не обновляют ее к текущим реалиям, ну или просто забивают.

Всегда тщательно тестируйте любой код, который вы включаете в приложение. Читайте комментарии на SO, анализируйте код, просматривайте баг-репорты на GitHub, посмотрите, когда был сделан последний коммит, и внимательно следите за нововведениями Android. Они могут сломать не только ваш, но и чужой код.

как стать разработчиком андроид приложений
При работе с множеством изображений Blurry будет крашить твое приложение каждые две минуты

Никто не будет тестировать бета-версию

Отсутствие профессионального бета-тестирования — одна из основных проблем инди-разработчиков. Часто мы просто не можем позволить себе нанимать профессионалов и поэтому прибегаем к помощи друзей, родственников, соседей и котов. Результат обычно получается плачевным, и мы пытаемся найти способ расширить аудиторию тестеров за счет самих пользователей.

Google Play позволяет загружать три различные версии приложения: альфа, бета и стабильная. И кажется, что это именно то, что нам нужно: просто загружаем бету, и пусть ее устанавливают все, кто хочет, и отписываются о проблемах.

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

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

Невозможные баги возможны

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

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

Вы уже три раза проверили код и не смогли повторить его на всех эмуляторах и смартфонах? Проверьте код еще три раза и в этот раз запустите приложение на всех-всех эмуляторах и смартфонах.

Готовьтесь к проблемам

Когда вы только начинаете изучать программирование для Андроид, вам кажется, что здесь все просто и понятно. Но чем дольше вы этим занимаетесь, тем больше понимаете, насколько все сложно и запутанно. Android появился как операционная система для классического типа смартфонов, напоминающих старые BlackBerry: небольшой экран, QWERTY-клавиатура, простые приложения. А затем его в срочном порядке начали переделывать в нечто вроде iOS. Через несколько лет приложения внезапно стали намного сложнее. А потом мир изменился снова.

РЕКОМЕНДУЕМ!
Инструменты Android-разработчика

Google постоянно переделывала Android, добавляя в него все новые API, которые могли работать сообща со старыми или конфликтовать с ними. В то же время расширялся список устройств, а старые версии Андроид все никак не устаревали. Появились библиотеки поддержки, призванные помочь в разработке для разных версий ОС, а на деле еще более ее усложняющие.

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

Ваше приложение своруют, смиритесь

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

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

Как с этим бороться? Никак. Это один из багов экосистемы Android. Единственный вариант — ежедневно находить в гугле ссылки на пиратские версии своего приложения и писать жалобы.

советы разработчику Android приложений
Очередной индиец сообщает о рекламе в приложении

На этом все. Надеюсь, что приведенные в статье советы, помогу начинающему разработчику Андроид приложений.

Понравилась статья? Поделиться с друзьями:
Добавить комментарий