Android: разработка приложений с уважением к пользователю.

Мне ужасно не нравятся бесконечные сравнения операционных систем ios и Android. Но я не могу начать этот пост не вспомнив про ios. Все потому что Android выигрывает и проигрывает одновременно у ios из-за большей свободы в разработке, из-за большей возможности пользоваться ресурсами устройства, из-за отсутствия какого-либо контроля со стороны Google Play Market. Разработчик ios приложений изначально находится в более тесных рамках, что минимизирует риск ошибок. Это не означает, что невозможно написать плохо под ios. Но если вы разрабатываете под платформу Android, то вы должны понимать, что правило – чем больше свобода – тем больше ответственность – для вас актуально как никогда.

Описанные ниже правила достаточно просты и вроде бы очевидны. Но тем не менее подобные ошибки встречаются не так уж редко.
  1. Начнем с разрешений приложений описанных в манифесте. Пользователи в этом случае делятся на три группы: первые ставят приложения не обращая внимание на разрешения, вторые не ставят в принципе приложения с “пугающими” разрешениями, третьи разумно относятся к необходимости разрешений и начинают волноваться только тогда, когда, например, приложение калькулятор вдруг требует неограниченный доступ в интернет. Вообще говоря пункт “проверить разрешения” находится в чек листе у разработчика перед публикацией. Но пункт из чек листа подразумевает, что вы проверили манифест на предмет лишних разрешений для своего приложения. Но помимо этого задолго перед публикацией (лучше всего вообще в самом начале разработки) лучше ответить на вопросы: 1. Действительно ли данный функционал необходим в приложении? 2. Нельзя ли данный функционал заменить на аналогичный с менее суровыми разрешениями? Пример: приложение требует разрешение для осуществления телефонных вызовов (страшное разрешение для пользователей второй и третьей группы!!!) а в действительности вы просто хотите, чтобы пользователь имел возможность набрать телефонный номер с экрана “О программе”. Никто ничего не потеряет, если вы замените action вызова activity с ACTION_CALL на ACTION_DIAL. При этом не очень нужное разрешение из манифеста уберется.
  2. Если ваше приложение требует работу таких ресурсоемких служб как GPS и bluethooth, то стоит их включать только там, где это необходимо и, что гораздо важнее, отключать, когда они становятся не нужны. Например, очень вежливо со стороны разработчика отключать GPS listener если приложение уходит в background. Вообще, стоит внимательней относится к настройкам телефона вашего потенциального пользователя.
  3. В частности не следует забывать о пользовательских настройках вибрации и звука. Иногда возникает необходимость сопроводить определенные действия в приложении звуком или вибрацией, но убедитесь, что вы проверяете не включен в этот момент беззвучный режим на устройстве (getRingerMode() AudioManager).
  4. Этот пункт будет касаться видимой пользователем передачи данных по сети. Стандартная ситуация: запуск приложения, необходимо синхронизировать данные с сервером. Обычно при этом показывается пустой экран и диалговое окошко с надписью “подождите, пожалуйста” (возможны варианты со спиннером). Что же здесь может быть не так? А не так может быть излишняя перестраховка разработчика, при которой пользователь будет видеть пустой экран с уведомлением о прогрессе каждый раз, как только он попадает на этот экран. Обычно так происходит, когда разработчик, к примеру, обновляет данные в методе onResume(), потому что есть страх, что данные на сервере могут обновится когда угодно. При этом пользователь каждый раз лишен возможности совершить в это время хоть какое-то действие. А исправить это просто: если хоть какие-либо данные были уже доступны, то стоит их хранить и показывать пользователю даже во время обновления/синхронизации. Но вообще самое правильное – не обновлять данные всегда “на всякий случай” а задуматься о реализации пуш нотификаций (про пуши поговорим чуть позже). 
  5. Точно также важно правильно реализовать невидимую пользователем передачу данных по сети. Уже все знают, что если на андроиде приложение в данный момент не запущено, то это не значит, что оно совсем не работает. Приложение может запускать обновление данных по расписанию, может реагировать на определенные события на устройстве. Все отлично, у нас есть возможность обновлять данные до того, как пользователь запустит приложение, и мы тем самым экономим ему время. Но иногда может возникнуть реально неудобная ситуация, при которой приложение может не запускаться месяцами и при этом стабильно находится в топе монитора использования мобильного интернета. Из этого следует вывод: пользователь должен знать, что данные приложения могут обновляться в бекграунде. Также было бы неплохо, если бы пользователь имел возможность отключить подобные обновления. Самый логичный способ для андроида это добавить аккаунт для приложения, тем самым предоставив возможность включать/отключать синхронизацию через службу “Аккаунты и синхронизация” в настройках. Вообще, чем меньше осуществляется невидимая передача данных по сети, чем меньше невидимой активности, тем лучше для пользователя.
  6. Правило чем меньше, тем лучше, иногда относится и к пуш нотификациям. До недавнего времени у андроид по сравнению с ios было преимущество: приложение на андроиде могло реагировать на пуши, при этом приложение на ios (до 7-ой версии) по-прежнему ничего не могло сделать по этому событию, надо было ожидать, пока пользователь не нажмет на нотификацию. Мне хотелось бы настаивать на таком подходе и для андроида: пусть все-таки максимальная активность приложения приходится на то время, когда оно действительно запущено, а пуш нотификация пусть просто указывает на то, что некое действие необходимо сделать при следующем запуске. Я понимаю, что это достаточно спорный совет, но могу объяснить на примере, чем мне лично нравится такой подход. Мне очень нравится приложение WhatsApp, особенно мне нравится переписываться с людьми с ios версией приложения. Почему? Да потому что у приложения есть маленькая фишка: исходящее сообщение помечается одной галочкой, когда оно отправлено, и двумя, когда достигает адресата. При этом если вы переписываетесь с пользователем андроида, то вы 2 галочки видите обычно сразу же после отправки. Все верно – сообщение достигло устройства. Но если вы переписываетесь с пользователем ios, то вы не увидите 2-ух галочек до тех пор, пока пользователь не нажмет на уведомление и не перейдет в чат. Ну и теперь вопрос: а какая информация для вас важна? То, что сообщение достигло устройства (андроид) или то, что ваш собеседник действительно увидел сообщение и перешел в чат (ios)?

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