Мобильные приложения

Любой человек может оказаться в неприятной ситуации когда он едет ночью, в лес, в багажнике... Предусмотрительные граждане пытаются избежать подобных инцидентов выбирая сервисы такси известных брендов, которые декларируют безопасность поездки, контроль за водителями и даже вешают в приложении огромную кнопку "БЕЗОПАСНОСТЬ" которую надо жать в случае если что-то пошло не так.

Но помогает ли эта кнопка? Давайте проверим на практике.

Дано: молодая симпатичная девушка и её кнопочный телефон (без навигатора), незнакомый город бывшей союзной республики, зима, метель, мороз.

Требуется: добраться из частного сектора на окраине в центр, путь пролегает мимо промзон, лесопарков.

Решение (казалось бы очевидное): берём смартфон с сервисом ЯндексGO у супруга, заказываем ЯндексТакси, садимся и едем. Счастливый супруг тем временем наблюдает онлайн, как машина везёт пассажира по адресу...

Ой, никто уже никого никуда не везёт.

"Вы приехали" сообщает приложение. "Как всё прошло?"
"Стоимость поездки изменилась, заказ завершён не в указанной ранее точке." - вот тут наступает некоторая, так скажем, паника. Особенно на фоне новостей про онанистов из сервиса такси. Звонок супруге (не дословно):

• "Ты где?! Уже приехала?"

• "Нет, ещё еду."

• "Странно, мне показывает что поездка завершилась досрочно... Что за окном? Уже город?"

• "Нет, поля." (путь вполне может пролегать мимо лесополосы, полей, промзоны)

• "Ок, как приедешь - позвони сразу. Что-то странное твориться, будь осторожна."

• "Хорошо."

Что делать?

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

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

Пытаемся воспользоваться пресловутой кнопкой "Безопасность" которая вроде бы должна помочь в такой ситуации. По быстрому описываем вкратце ситуацию в чате "команде безопасности" и... получаем отфутболивание к службе поддержки которая "ответит в ближайшее время".

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

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

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

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

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

Дискуссии об этичности использования этих технологий стали массовыми после выхода фильма Социальная дилемма (The Social Dilemma) на Netflix,поэтому мы решили с помощью нашей платформы для выявления перспективных рынков и технологий TeqViserразобраться, что же такое технологии убеждения, каковы их возможности, как они используются в ИТ-сфере и какие опасности таят. Кстати, именно результаты мониторинга трендов TeqViser мы использовали при разработке стратегии развития Ростелекома

Что такое технологии убеждения?

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

Дисциплина, изучающая технологии убеждения, называется Каптология (Captology, от аббревиатуры CAPT: Computers As Persuasive Technologies) новое направление науки, находящиеся на стыке информационных технологий и психологии.

Оба термина ввел Би Джей Фогг социолог, философ, специалист по поведению из Стэнфордского университета. Он является основателем и директором Stanford Persuasive Technology Lab, позже переименованной в Behavior Design Lab.

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

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

Почему это важно сейчас?

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

Вот немного статистики из TeqViser:

Всего, начиная с 2014 года, опубликовано более 25 тыс. научных статей и получено около 500 патентов, связанных с технологиями убеждения.

Резкий рост инвестиций, начавшийся в 2019 году, связан с ростом числа приверженцев здорового и активного образа жизни, а также с повышенным вниманием общества к здоровью (физическому и психическому), т.к. основной сферой применения технологий убеждения на сегодняшний день является здравоохранение. Крупнейшей сделкой по этому направлению являются инвестиции венчурного фонда SoftBank в бразильское фитнес-приложение Gympass ($300 млн в 2019 году).

Кроме инвестиций растёт спрос на квалифицированных специалистов. Как правило, наибольший кадровый дефицит наблюдается на прорывных рынках в период зарождения технологий. По количеству вакансий тренд Persuasive Technology сопоставим с трендом Biometric, однако разница между спросом и предложением на рынке труда для технологий убеждений составляет 2270%, а для биометрии 112%. В очередной раз подтверждается востребованность специалистов, обладающих знаниями сразу в нескольких областях и осуществляющих свою деятельность на стыке дисциплин, в данном случае психологии и ИТ.

Как это работает?

Согласно модели поведения, которую Б.Дж. Фогг сформулировал в 2007 году, в основе любого действия лежит три элемента, которые должны совпасть во времени:
- мотивация человек должен хотеть совершить действие;
- способность у него должна быть возможность совершить это действие;
- триггер (подсказка) его нужно к этому подтолкнуть.

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

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

Вот основные стратегии убеждения:

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

Вернемся к модели поведения Б.Дж. Фогга и сопоставим её с возможностями цифровых технологий:

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

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

3. Триггер: с помощью алгоритмов по анализу пользовательского поведения можно определить лучшее время для триггера (направления уведомления) и сделать его персонализированным.

Развиваясь, технологии сокращают расстояние между продавцом и покупателем: переход от использования компьютеров к мобильным, а затем и нательным устройствам, сделал так, что постепенно, все пользователи стали доступны для взаимодействия 24/7. Очевидно, что следующим шагом станет масштабное внедрение инвазивных устройств и нейрокомпьютерных интерфейсов.

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

Сферы применения и кейсы

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

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

Nike использует технологии убеждения в своих приложениях Nike Run Club и Nike Training Club, поддерживающих пользователей в занятиях спортом (функционал приложений включает в себя возможность ставить цели, отслеживать свой результат и делиться им, а также различные рекомендации)

MoneyVerbs (США) это платформа для изменения поведения, которая помогает пользователям сформировать правильные денежные привычки и улучшить свое финансовое благополучие.

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

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

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

Какие есть риски?

Очевидно, что во избежание злоупотреблений технологии убеждения должны применяться этично и ответственно. Самым ярким, из известных примеров неэтичного использования технологий убеждения является кейс Cambridge Analytica . Компания использовала данные, полученные от Facebook, чтобы создавать профили пользователей и перенаправлять как можно более широкую аудиторию на платформу с рекламой, убеждающую посетителей голосовать определенным образом.

Специалисты по технологической этике еще в 1999 году предложили одно правило: создатели технологий убеждения никогда не должны пытаться убедить кого-либо в том, в чём они сами не хотели бы, чтобы их убеждали. Похоже на золотое правило нравственности: относись к другим так, как хочешь, чтобы относились к тебе, но как проверить его соблюдение? Очевидно, что правительства должны уделять этому вопросу гораздо больше внимания, в том числе в части необходимости регулирования использования таких технологий.

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

Скоро выходит Android 12, но в этом августе уже с 11-й версии разработчикам придётся использовать новые стандарты доступа приложений к внешним файлам. Если раньше можно было просто поставить флаг, что ваше приложение не поддерживает нововведения, то скоро они станут обязательными для всех. Главный фокус повышение безопасности.

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

Что происходит

Если вы уже знакомы с теорией, то этот раздел можно пропустить тут я хочу поверхностно сравнить подходы к предмету в разных версиях операционной системы.

В Android есть внутреннее Internal Storage (IS) и внешнее хранилище External Storage (ES). Исторически это были встроенная память в телефоне и внешняя SD-карта, поэтому ES был больше, но медленнее и дешевле. Отсюда и разделение настройки и критически важное записывали в IS, а в ES хранили данные и большие файлы, например, медиа. Потом ES тоже стал встраиваться в телефон, но разделение, по крайней мере логическое, осталось.

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

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

В Android решили всё это переделать ещё в 10-й версии, а в 11-й это стало обязательным.

Чтобы минимизировать риски для пользователя в Google решили внедрить Scoped Storage (SS) в ES. Возможность проникнуть в папки других приложений убрали, а доступ есть только к своим данным теперь это сугубо личная папка. А IS с 10-й версии ещё и зашифрована по умолчанию.

В Android 11 Google зафорсировала использование SS когда таргет-версия SDK повышается до 30-й версии API, то нужно использовать SS, иначе будут ошибки, связанные с доступом к файлам. Фишка Android в том, что можно заявить совместимость с определённой версией ОС. Те, кто не переходили на 11, просто говорили, что пока не совместимы с этой версий, но теперь нужно начать поддерживать нововведения всем. С осени не получится заливать апдейты, если не поддерживаешь Android 11, а с августа нельзя будет заливать новые приложения.

Если SS не поддерживается (обычно это для девайсов ниже 10-й версии), то для доступа к данным других приложений требуется получить доступ к чтению и записи в память. Иначе придётся получать доступ к файлам через Media Content, Storage Access Framework или новый, появившийся в 11-м Android, фреймворк Datasets в зависимости от типа данных. Здесь тоже придётся получать разрешение доступа к файлу, но по более интересной схеме. Когда расшариваемый файл создаёшь сам, то доступ к нему не нужен. Но если переустановить приложение доступ к нему опять потребуется. К каждому файлу система привязывает приложение, поэтому когда запрашиваешь доступ, его может не оказаться. Особо беспокоиться не нужно, это сложно отследить, поэтому лучше просто сразу запрашивать пермишен.

Media Content, SAF и Datasets относятся к Shared Storage (ShS). При удалении приложения расшаренные данные не удаляются. Это полезно, если не хочется потерять нужный контент.

Хотя даже при наличии SS можно дать доступ к своим файлам по определённой технологии через FileProvider можно указать возможность получения доступа к своим файлам из другого приложения. Это нормально, потому что файлы расшаривает сам разработчик.

Также добавилась фича если приложение не использовалось несколько месяцев, то снимаются все пермишены и доступы к системным элементам. По best practice разрешение запрашивается по требованию, поэтому мы просто перед выполнением какого-либо действия проверяем, есть ли у нас пермишены. Если нет, то запрашиваем.

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

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

Перейдём к практике.

Переход на новую версию

Основная функциональность по работе с файлами в приложении iFunny представлена в виде сохранения мемов в память и расшаривания их между приложениями. Это было первое, что требовалось починить.

Для этого выделили в общий интерфейс работу с файлами, реализация которого зависела от версии API.

interface FilesManipulator {    fun createVideoFile(fileName: String, copy: Copier): Uri    fun createImageFile(fileName: String, copy: Copier): Uri    fun createFile(fileName: String, copy: Copier): Uri    fun getPath(uri: Uri): String    fun deleteFile(uri: Uri)}

FilesManipulator представляет собой интерфейс, который знает, как работать с файлами и предоставляет разработчику API для записи информации в файл. Copier это интерфейс, который разработчик должен реализовать, и в который передаётся поток вывода. Грубо говоря, мы не заботимся о том, как создаются файлы, мы работаем только с потоком вывода. Под капотом до 10-й версии Android в FilesManipulator происходит работа с File API, после 10-й (и включая её) MediaStore API.

Рассмотрим на примере сохранения картинки.

fun getContentValuesForImageCreating(fileName: String): ContentValues {    return ContentValues().apply {        put(MediaStore.Images.Media.DISPLAY_NAME, fileName)        put(MediaStore.Images.Media.IS_PENDING, FILE_WRITING_IN_PENDING)        put(MediaStore.Images.Media.RELATIVE_PATH, Environment.DIRECTORY_PICTURES + File.separator + appFolderName)    }}fun createImageFile(fileName: String, copy: Copier): Uri {    val contentUri = MediaStore.Images.Media.getContentUri(MediaStore.VOLUME_EXTERNAL_PRIMARY)    val contentValues = getContentValuesForImageCreating(fileName)    val uri = contentResolver.insert(contentUri, contentValues)         ?: throw IllegalStateException("New image file insert error")    downloadContent(uri, copy)    return uri}fun downloadContent(uri: Uri, copy: Copier) {    try {        contentResolver.openFileDescriptor(uri, FILE_WRITE_MODE)                .use { pfd ->                    if (pfd == null) {                        throw IllegalStateException("Got nullable file descriptor")                    }                    copy.copyTo(FileOutputStream(pfd.fileDescriptor))                }        contentResolver.update(uri, getWriteDoneContentValues(), null, null)    } catch (e: Throwable) {        deleteFile(uri)        throw e    }}fun getWriteDoneContentValues(): ContentValues {    return ContentValues().apply {        put(MediaStore.Images.Media.IS_PENDING, FILE_WRITING_DONE)    }}

Так как операция сохранения медиафайлов достаточно длительная, то целесообразно использовать MediaStore.Images.Media.IS_PENDING, которая при установлении значения 0 не дает видеть файл приложениям, отличного от текущего.

По сути, вся работа с файлами реализована через эти классы. Шаринг в другие приложения автоматически сохраняют медиа в память устройства и последующая работа с URI уже происходит по новому пути. Но есть такие SDK, которые ещё не успели перестроиться под новые реалии и до сих пор используют File API для проверки медиа. В этом случае используем кеш из External Storage и при необходимости провайдим доступ к файлу через FileProvider API.

Помимо ограничений с памятью в приложениях, таргетированных на 30-ю версию API, появилось ограничение на видимость приложения. Так как iFunny использует шаринг во множество приложений, то данная функциональность была сломана полностью. К счастью, достаточно добавить в манифест query, открывающую область видимости к приложению, и можно будет также полноценно использовать SDK.

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

<manifest  ><queries><intent>    <action android:name="android.intent.action.SENDTO" />    <data android:scheme="smsto, mailto" /></intent>    <package android:name="com.twitter.android" />    <package android:name="com.snapchat.android" />    <package android:name="com.whatsapp" />    <package android:name="com.facebook.katana" />    <package android:name="com.instagram.android" />    <package android:name="com.facebook.orca" />    <package android:name="com.discord" />    <package android:name="com.linkedin.android" /></queries></manifest>

После проверок запуска UI-тестов на девайсах с версиями API 29-30 было выявлено, что они также перестали корректно отрабатываться.

Первоначально в LogCat обнаружил, что приложение не может приконнектиться к процессу Orchestrator и выдает ошибку java.lang.RuntimeException: Cannot connect to androidx.test.orchestrator.OrchestratorService.

Эта проблема из разряда видимости других приложений, поэтому достаточно было добавить строку <package android:name="androidx.test.orchestrator" /> .

Тест удачно запустился, но возникла другая ошибка Allure не может сохранить отчёт в память устройства, падает с ошибкой.

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

Так как нам нужно использовать этот пермишен только для тестов, то нам условия подходят. Поэтому я быстренько написал свой ShellCommandExecutor, который выполняет команду adb shell appops set --uid PACKAGE_NAME MANAGE_EXTERNAL_STORAGE allow на создании раннера тестов.

На Android 11 тесты удачно запустились и стали проходить без ошибок.

После попытки запуска на 10-й версии Android обнаружил, что отчет Allure также перестал сохраняться в память девайса. Посмотрев issue Allure, обнаружил, что проблема известная, как и с 11-й версией. Достаточно выполнить команду adb shell appops set --uid PACKAGE_NAME LEGACY_STORAGE allow. Сказано, сделано.

Запустил тесты всё еще не происходит сохранения в память отчёта. Тогда я обнаружил, что в манифесте WRITE_EXTERNAL_STORAGE ограничен верхней планкой до 28 версии API, то есть запрашивая работу памятью мы не предоставили все разрешения. После изменения верхней планки (конечно, для варианта debug) и запроса пермишена на запись тесты удачно запустились и отчёт Allure сохранился в память устройства.

Добавлены следующие определения пермишенов для debug-сборки.

<uses-permission android:name="android.permission.MANAGE_EXTERNAL_STORAGE" /><uses-permission    android:name="android.permission.WRITE_EXTERNAL_STORAGE"    android:maxSdkVersion="29"    tools:node="replace" />

После всех вышеописанных манипуляций с приложением, можно спокойно устанавливать targetSdkVersion 30, загружать в Google Play и не беспокоиться про дедлайн, после которого загружать приложения версией ниже станет невозможно.

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

Немного истории

Четыре года назад для нужд нашей организации было принято решение написать мобильное приложение для двух платформ (iOS и Android). Программист был один, а опыта работы с нативными языками на тот момент не было. Для этих целей мы решили попробовать кроссплатформенную схему разработки от Cordova.

Выбор фреймворка

Оказалось, что реализовать проект в основе которого лежит один подход, можно по-разному. Выбрав Phonegap можно было получить платформу Cordova, плюс несколько полезных инструментов для отладки и демонстрации приложения, а главное, облачную сборку для разных платформ (не бесплатно). Для тех кто не в курсе, приложения для iOS собираются только на macOS, а для Android, можно собирать как на macOS, так и на Windows. Судя по всему идея заработать на облачной сборке у Phonegap провалилась, так как Adobe прекратила инвестиции в проект. Другой путь это Ionic, команда этой группы предлагает набор инструментов охватывающий все этапы разработки гибридного приложения от А до Я. Здесь к платформе Cordova вы получите возможность интеграции с популярными фреймворками (Angular, React, Vue), инструменты для бесплатной и платной разработки, подробную документацию и многое другое. Мы пошли по пути наименьшей зависимости от кого бы то ни было. Взяли Cordova, а в качестве фреймворка для single page application выбрали менее хайповый, но довольно симпатичный Framework 7 (так же были доступны Angular, React, Vue и другие). В реальном проекте трудности обычно возникают либо с плагинами, либо с особенностями самих платформ. Так как команда Ionic предлагает готовые решения известных проблем, многим, будет легче поддерживать проект присоединившись к ним.

Плюсы и минусы

После нескольких лет работы с платформой могу выделить некоторые значимые плюсы и минусы. Далее в данной статье буду говорить о некоторых пунктах подробнее.

Плюсы:

• не нужен программист для каждой платформы на начальном этапе

• лёгкая интеграция с приложениями имеющими веб интерфейс

• разнообразие фреймворков для разработки одностраничных приложений

• возможность обновлять код без выпуска новых сборок

• возможность использования большого количества бесплатных веб компонентов

• возможность быстрой разработки собственных компонентов, используя доступные средства и библиотеки веб технологий

Минусы

• поддержка существующих плагинов

• особенности браузерных компонентов webview

• неудобная работа с файловой системой

• многозвенная схема отладки приложения

• вечно-зеленый компонент webview у Android

Программисты и плагины

На начальном этапе можно действительно обойтись без навыков нативной разработки, но по мере увеличения количества плагинов в вашем проекте, это будет неизбежно. Дело в том, что код плагинов быстро устаревает и часть функционала либо перестает работать, либо будет работать неправильно в определенных версиях ОС той или иной платформы. Бывают ситуации и хуже. Так обновленный Xcode поддерживающий последнюю версию платформы iOS, может отказаться собирать ваш проект, обнаружив в нем плагин написанный на предыдущей версии swift. Пример конечно экзотичен, потому как 99% плагинов под iOS написаны на Objective C, тем не менее, с этим приходилось сталкиваться. Немалое количество плагинов сообщество энтузиастов-разработчиков забросило, а те что поддерживаются, порой ждут обновлений довольно долго. Так же, нужного плагина может и не быть вовсе. В итоге, чтобы иметь актуальный и работающий проект, вам необходимо будет вносить изменения в нативный код плагинов, писать их с нуля или просто редактировать главные модули приложения (на Objective C и Java соответственно).

Интеграции

Интегрировать в проект отдельные элементы веб приложений или полноценные приложения довольно удобно. Ваш проект работает в браузере, а это значит, что вы сможете загружать в него веб страницы, делать запросы к веб сервисам, использовать возможности WebDAV и многое другое. При HTTP запросах из вашего приложения к другим веб ресурсам, вы наверняка столкнётесь с проблемами аутентификации, CORS ограничениями, нюансами работы с сертификатами итд. Полноценные веб приложения лучше загружать в отдельный браузерный компонент с помощью плагина. Если потребуется, вы даже сможете настроить обмен данными между вашим основным браузерным компонентом (webview) и внешним. При этом, пользователь не будет покидать окна мобильного приложения. Как показала практика, многие десктопные приложения уже имеют веб интерфейсы, а некоторые из них, даже адаптированы к мобильным телефонам и планшетам. Так, например, мне удалось интегрировать веб версии клиентов MS Outlook, 1С, Redmine. Конечно, там не все гладко, неоднородность интерфейсов, отсутствие поддержки touch экранов, ограничения при работе с файловой системой и другие нюансы. Но спектр возможностей от таких интеграции, по-моему, перевешивает все недостатки.

WebView

Несмотря на хорошую поддержку стандартов со стороны браузерных компонентов двух платформ, сами webview имеют серьезные отличия. WKWebView - так называется актуальный компонент для iOS, имеет кучу ограничительных политик безопасности, в том числе и дурацких, среди которых невозможность загрузки контента по протоколу File. При этом, является намного более производительным и быстрым чем webview у Android. Ниже таблица с некоторыми показателями двух компонентов, которые были важны в реализации моего проекта.

VPN

При работе с корпоративными удаленными ресурсами (веб приложения, сервисы, базы данных), которые не являются публичными, возможно, придётся использовать VPN. Такой подход является довольно логичным, но затея не является безобидной. В реальности это накладные расходы на разработку и обслуживание, плюс негативный опыт ваших пользователей. Идеальным решением будет интеграция VPN клиента в приложение, что тоже не просто. Так, например, библиотеку с открытым кодом Open VPN можно интегрировать в проект с помощью нативного кода и предварительно скомпилированных библиотек. Плагина для Cordova нет, возможно, появится позже. Здесь так же придется немного помучиться с приложениями и сервисами работающими по протоколу HTTPS. Дело в том, что последние в корпоративной среде используют либо самоподписанные сертификаты, либо сертификаты выданные локальным центром сертификации, что для ваших webview не являются доверенными. Этот вопрос решается для двух платформ, но универсального и однозначного подхода здесь нет. Кто-то считает, что доступ к ресурсам внутри сети может быть осуществлен по-обычному HTTP. В этом есть логика, но не надо забывать, что весь трафик в данном случае будет передан без шифрования. Можно научить приложения для iOS и Android работать по HTTPS с ресурсами внутри сети и такой вариант считаю предпочтительным.

Провайдер сервер за прокси

Реализация такого сервера задача необходимая, если конечно, ваше приложение собирается получать push-уведомления. Для работы с APNS (служба Push-уведомлений Apple), потребуется установка соединения только по протоколу HTTP v.2 + TLS. Библиотеки и API популярных серверов научились работать с HTTP2, но не все они умеют работать с прокси серверами и здесь, возможно, будут сложности. Я какое-то время для этих целей использовал Apache, позже перешёл на собственный сервер, который был написан на Nodejs. Это оказалось невероятно просто и удобно. FCM для Android в этом смысле не такой требовательный (работает на HTTP v.1), при работе с ним проблем не наблюдалось.

Распространение приложений

Для iOS приложений придется оплачивать ежегодную enterprise лицензию, для Android это бесплатно. Плюсом enterprise лицензии для iOS является отсутствие модерации кода и возможность свободного распространения приложения без App Store. Достаточно иметь публичный сервер на котором у вас будут файл приложения и файл манифеста. Ссылку на манифест в специальном формате вы и будете распространять среди новых пользователей вашей организации. У Android приложений ограничений в распространении нет изначально. Последние рекомендую распространять через стандартные магазины приложений, так как APK загруженные не из магазина, по умолчанию, не являются доверенными для ОС Android.

Заключение

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

Только примерно 20% больных реальной депрессией ищут медицинскую или психологическую помощь, причем большинство из них обращаются к участковым терапевтам и неврологам. Те, в свою очередь, не всегда готовы к правильной диагностике, вследствие чего лишь около 30% депрессий (из числа 20% обратившихся) диагностируются своевременно и из них лишь 25% пациентов, в среднем, получает необходимую антидепрессивную терапию, лекарственную или иную. Трагичность (почему бы и не да) этих цифр тем более очевидна, если учесть тот факт, что в 60-70% случаев правильное научное лечение приносит пациентам быстрый желаемый эффект.

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

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

Весь прикол КТ в том, например, что известен эксперимент, в котором однажды один ученый впрыскивал в кровь испытуемым добровольцам в большой дозе адреналин, не говоря им, что это он. Люди становились психосоматически и объективно, по показаниям приборов, возбужденными, но 2/3 из них заявляли, что не испытывают никаких эмоций, а 1/3 говорила, что испытывала что-то похожее на эмоцию. Исследования других ученых показали, что одного физиологического возбуждения (или другого ощущения) недостаточно для возникновения эмоции, необходимо, чтобы человек распознал это реальное возбуждение, осознал, оценил и обозначил его словесно, мысленно, как это ему свойственно. Например, учащенное после подъема по лестнице на 10-й этаж сердцебиение ипохондричный пессимист назовет страшным приступом тахикардии, а спортивный оптимист - кайфовой тренировкой кровообращения. Изменения в организме у обоих одинаковые, но через минуту или час у первого настроение и здоровье ухудшится (приболел), а у второго - улучшится (потренил), причем не только субъективно, но и объективно, по показаниям самых современных высокоточных приборов. Получается, что отрицательные или положительные эмоции - следствие привычного (чаще наученного или наследственного) оценивания и убеждения в том, что они вызваны вредной или полезной данной конкретной причиной. Приблизить субъективное к объективному ради здоровья и успеха первоклассно помогает как раз КТ.

Начало практики когнитивной самокоррекции включает более подробное информирование о её философии (коротко повторим - эмоциональные проблемы вызывают не сами события, а их оценка) и о последовательных этапах восприятия события человеком в виде:

Ао --> Ас --> В --> C

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

Описательные мысли, как уже отмечалось, соединены с оценочными установками связями разной степени жесткости. Начиная от абсолютно исключающих какие-либо варианты, протекающих по типу рефлекса, при которых отношение к событию уже предопределено и тогда можно говорить о наличии у вас иррациональной установки (ИУ), заканчивая многовариантными, когда при принятии решения о действии осуществляется анализ альтернативных вариантов, хотя он может протекать неосознанно, и тогда можно говорить о наличии рациональной установки. Цель КТ перевод в проблемных ситуациях с иррациональных, депрессивных и стрессовых установок на максимально рациональные и приятные.

Работа в КТ всегда строится с учетом схемы А, В, С. Сначала:

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

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

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

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

а) самонаблюдение за мимическими проявлениями при вашем воспоминании об эмоции и предоставление письменной обратной связи вами самими,

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

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

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

a) вспоминательная фокусировка на тех мыслях, которые приходили Вам на ум в момент столкновения со стрессовым событием,

b) высказывание вами самими гипотетических предположений типа У меня в такой стрессовой ситуации возникли бы следующие мысли,

c) вопросы с проекцией в будущее время, например: Предположим, что произойдет самое худшее в ситуации стресса, что же это будет? и др.

Выявлению ИУ очень здорово помогает анализ используемых вами слов. Обычно с иррациональными установками связаны слова, отражающие крайнюю степень вашей эмоциональной вовлеченности в депрессию или стресс (ужасно, потрясающе, невыносимо и др.), имеющие характер обязательного предписания (необходимо, надо, должен, обязан и др.), а также глобальных, абстрактных оценок лица, объекта или события (совсем плохо, всегда хорошо). И все эти слова и мысли неконкретны, нереальны, неэффективны и болезнетворны. Можно доказать это. Легко.

Самая распространенная группа ИУ, создающих всеразличные проблемы - это катастрофические установки (отмечайте тут возможные ваши):

Я настолько расстроен(а) и несчастлив(а), что не могу это выдержать.

Мое будущее безнадежно, и ничто не может измениться к лучшему.

Я чувствую, что как личность, я полный(ая) неудачник(ца).

Я полностью не удовлетворен(а) жизнью и мне все надоело.

Я постоянно испытываю чувство вины.

Я чувствую себя уже наказанным(ой).

Я себя ненавижу.

Ко мне приходят мысли покончить с собой, но я не буду их осуществлять.

Я виню себя во всем плохом, что происходит.

Раньше я мог(ла) плакать, а сейчас не могу, даже если мне хочется.

Теперь я постоянно чувствую, что раздражен(а).

Я полностью утратил(а) интерес к другим людям.

Я с трудом заставляю себя сделать что-либо.

Я полностью утратил(а) сексуальный интерес.

Мой аппетит теперь значительно хуже.

Я очень обеспокоен(а) своим физическим состоянием и мне трудно думать о другом.

Если у вас даже один или более плюсов следует обратиться к врачу-психотерапевту или психологу. Есть про это опросники, вот два примера аппликаций в ГуглПлее - Тест на депрессию и моя старая модификация Тест оценки депрессии.

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

Следующие же духовные враги психосоматического здоровья и эффективного развития, которых тоже желательно заменять на более оптимистичные и уверенные убеждения, менее катастрофичны и опасны, нежели предыдущие, но зато чаще встречаются у всех нас (ставьте мысленно плюсы, если есть соответствия):

Я расстроен(а).

Я все время расстроен(а) и не могу от этого отключиться.

Я чувствую, что озадачен(а) будущим.

Я чувствую, что меня ничего не ждет в будущем.

Я чувствую, что пережил(а) больше неудач, чем другие люди.

Когда я оглядываюсь на мою жизнь, я вижу в ней очень много неудач.

Я не получаю столько же удовольствия от жизни, как и раньше.

Я больше не получаю удовлетворения ни от чего.

Достаточно часто я чувствую себя виноватым(ой).

Большую часть времени я чувствую себя виноватым(ой).

Я чувствую, что могу быть наказан(а).

Я ожидаю, что могу быть наказан(а).

Я разочаровался(ась) в себе.

Я себе противен(на).

Я критикую себя за ошибки и слабости.

Я все время обвиняю себя за свои проступки.

Сейчас я плачу чаще, чем раньше.

Теперь я все время плачу.

Я более легко раздражаюсь, чем раньше.

Я меньше интересуюсь другими людьми, чем раньше.

Я почти потерял(а) интерес к другим людям.

Я чаще, чем раньше, откладываю принятие решения.

Я больше не могу принимать решения.

Я знаю, что выгляжу безобразно.

Мне необходимо сделать дополнительное усилие, чтобы начать делать что-нибудь.

Я совсем не могу выполнить никакую работу.

Сейчас я сплю хуже, чем раньше.

Я просыпаюсь на 1-2 часа раньше обычного и мне трудно заснуть опять.

Теперь я устаю быстрее, чем раньше.

Я устаю почти от всего, что я делаю.

Я не могу ничего делать из-за усталости.

Мой аппетит стал хуже, чем раньше.

Сейчас я значительно меньше интересуюсь сексуальными вопросами.

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

Я настолько обеспокоен своим физическим состоянием, что больше ни о чем не могу думать.

Результаты: 0-1 нормально, до 5 плюсов требуется помощь психолога, более 5 нужно к врачу-психотерапевту или психиатру.

Цель диагностического этапа реализована, когда в области стресса или депрессии выявлены такие или им подобные ИУ, показан характер связи между ними и отношениями в семье, на работе и т.д. Уточнение рациональных установок и целей также необходимо, поскольку они составляют ту позитивную часть отношения, которая в последующем может быть расширена. Что мы и сделаем, насколько это возможно, чуть дальше. Хотя в приложения есть хорошие для здесь и сейчас), например - Mindspa: психологическая помощь в любой момент или Психология самооценки: 6 практик. Личностный рост с BestHelp Психологическая помощь онлайн.

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

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

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

Максимально быстрое осознание способов неадекватной обработки информации и замена их правильными - таковы главные общие задачи когнитивной самокоррекции. Она наиболее показана людям с 14-16 лет со способностью к самонаблюдению и анализу своих мыслей. Т.е. сознательным товарищам.

Важная задача начального этапа - письменное описание проблем (идентификация проблем, имеющих в основе одни и те же причины, и их группировка). Эта задача относится как к симптомам (соматическим, психическим), так и просто к эмоциональным проблемам. При этом достигается укрупнение мишеней воздействия КТ. Другим вариантом описания проблем является идентификация первого звена в цепи симптомов, который и запускает всю цепочку, что иногда приводит к выходу на уровень ваших конкретных ощущений. Этому посвящены минимум два мобильных приложения - Когнитивная Tерапия: Три Колонки и Личный дневник настроения и эмоций, ежедневник.

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

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

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

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

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

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

Вы можете сказать - хватит указывать, кто виноват, лучше опишите что, когда и как делать!. Чрезвычайно согласен, настолько, насколько это только возможно.

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

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

Отдаление повышает способность вас проводить разграничение между мнением, которое надо обосновать (я считаю) и неопровержимым фактом (я знаю). Оно развивает умение осуществлять дифференциацию между фактическим внешним миром и своим отношением к нему. Обоснование, доказательство не-реальности ваших автоматических мыслей облегчает отдаление вашей объективности от них, формирует у вас навык видеть в авто-мыслях гипотезы, а не факты. Как на суде - вы прокурор-адвокат в одном лице и проверяете мысли (лучше письменно) на предмет их преступности. В процессе отдаления вам становится более ясным путь нереального отображения восприятия события. И наоборот усиливается ваша истинность.

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

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

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

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

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

Если вы регулярно читаете Хабр, то вам попадались статьи в духе: бросайте всё и начинайте изучать Swift, Kotlin или Flutter прямо сейчас. Давайте разбираться, правда ли стоит переобуваться в мобильного разработчика. Мы попросили спикеров, программный комитет и разработчиков взглянуть на сферу мобильной разработки с разных ракурсов и приоткрыть завесу тайны грядущей конференции Мир. Труд. Мобайл. В конце приятный бонус для читателей Хабра и подробности программы.

Мобильная разработка актуальна. Это факт

В отчёте State of Mobile 2021 говорится, что рынок мобильных приложении и игр вырос на 30% за 2020 год пользователи потратили на них рекордные $111 млрд. Пандемия и изоляция внесли свой вклад.

Про начинку современных смартфонов не приходится говорить. Фотографируют лучше стареньких Кэнон, по производительности и возможностям потягаются с простенькими ноутбуками.

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

В сторах можно найти приложение на любой случай жизни. Что говорить, когда даже у автомата по розливу воды у дома в спальном районе (за 3 /литр) есть мобильное приложение для онлайн-оплаты. Кажется, мобильщики выбрали как девиз любая идея достойна мобильного приложения! Почему? Отчасти потому что новые технологии упростили и шаблонизировали разработку.

Про изменения в подходах к разработке мы спросили Фёдора Цымбала из Orion Innovations. Он выступит с докладом: Android Automotive. Не путать с Android Auto.

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

В плане UI-фреймворков сейчас очень популярен Flutter. Но Jetpack Compose вполне может его потеснить. Стоит выбрать что-то одно из этих двух опций.

Заметен уход с мобилок на другие устройства: часы, телевизоры, автомобили. Android на этих устройствах сейчас активно развивается. По моему мнению, это тоже очень интересная тема. Про Android Automotive я и буду рассказывать: Google Automotive Services, Driver Distraction Guidelines, Garage Mode и об интеграции Android с подсистемами автомобиля, такими как камера заднего вида, климат контроль или поворотники.

Павел Стрельченко из hh.ru занимается Android-разработкой с 2015 года, поэтому успел застать разработку под Android 4, первую версию Android Studio, жизнь без Jetpack, Architecture Components и Kotlin. Павел выступит с темой: Укрощая фиче-флаги. Разберем проблемы постоянных merge-конфликтов, сбора флагов в один-единственный список.

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

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

Сейчас Android-разработчикам можно порекомендовать две вещи изучать корутины и Compose. Скоро все там будем, чтобы не отстать, нужно не останавливаться в изучении современных подходов и библиотек.

Тем, кто только начинает свой путь в увлекательный мир Android, я всегда рекомендую одно и тоже посмотреть лекции Android Academy. Мои коллеги по Android-у проделали потрясающую работу, собрав в один бесплатный курс всё необходимое для успешного старта в профессии.

Приложение остаётся способом реализовать большую идею малыми силами

Мобильное приложение по-прежнему отличный вариант для старта своего продукта с небольшой затратой ресурсов. Самый сладкий и большой кусок пирога мобильные игры. Пользователи потратили на них в 2020 году $143 млрд. Доля мобильных игр в магазинах приложений в 2021 году вырастет до 20%.

Про технологии, рынок, зарплаты и перспективы вроде понятно. Вопрос сколько стоит реализовать свою идею.

Резиденты Иннополиса работают над приложением DVIZZ, которое объединяет афишу городских событий и создание встреч, чтобы познакомиться с новыми людьми и хорошо провести время. Придумать новую идею становится сложнее, уже практически всё реализовано. Поэтому новые приложения активно комбинируют функции. Стремление в сторону супераппов с замкнутой экосистемой как тренд не только для IT-гигантов.

Основатель DVIZZ Михаил Иванов рассказывает, что потратил 500 000 на разработку и 3 млн на зарплаты за полгода после запуска.

Сейчас на операционные расходы уходит около 10 000 в месяц. Но это ещё не всё, потому что самое сложное продвижение. На анализ, стратегию, маркетинг, таргетинг потратили 300 000 . Уже удалось снизить стоимость установки до приятных цифр, но начальный этап действительно самый сложный.

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

У нас есть три стратегии монетизации: реклама больших ивентов в афише, платные мероприятия или мастер-классы больше 10 человек и доступ в бизнес-кабинет владельцев площадок для аренды, например, теннисного корта или лектория прямо из приложения. Уже понемногу зарабатываем, планируем запускать в Москве. Окупиться планируем через год.

Что будет на Мир. Труд. Мобайл

Два формата: бесплатный онлайн и офлайн на цифровой даче в Иннополисе. Всего будет 5 больших хабов:

• Android;

• iOS;

• Кроссплатформа;

• Дизайн;

• Софтскилы.

Офлайн

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

Онлайн

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

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

Увидимся на Мир. Труд. Мобайл.

27 мая

Скидка на офлайн 25% для читателей Хабра по промокоду habr

Мобайл редьки слаще!

Вступление

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

Данные

Датасет опубликован на сайте Kaggle.

DOI: 10.34740/KAGGLE/DSV/2107675.

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

В датасете 4 файла:

• bundles_desc.csvсодержит только описания;

• bundles_desc_tokens.csvсодержит токены и жанры;

• bundles_prop.csv, bundles_summary.csvсодержат рпзличные характеристики приложений и даты релиза/обновления.

EDA

Прежде всего, давайте посмотрим, как данные распределяются по операционным системам.

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

Учитывая, что набор данных содержит только самые популярные приложения, интересно посмотреть, как распределяется дата выпуска.

histnorm ='probability' # type of normalization

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

Основные данные были собраны за короткий период времени в январе 2021 года.

Добавим новую фичу - количество месяцев между датой выпуска и последним обновлением.

df['bundle_update_period'] = \    (pd.to_datetime(        df['bundle_updated_at'], utc=True).dt.tz_convert(None).dt.to_period('M').astype('int') -      df['bundle_released_at'].dt.to_period('M').astype('int'))у

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

Мы видим, что жанры полностью не пересекаются. Особенно это заметно в играх. Для анализа такая ситуация крайне неприятна. Что мы можем с этим поделать? Самое очевидное - уменьшить количество жанров для Android и привести их к тому же виду, что и для iOS путем сведения всех игровых жанров к одному Games. Но я полагаю, что это не лучший вариант, так как будет потеря информации. Попробуем решить обратную задачу. Для этого нужно построить модель, которая будет предсказывать жанры приложений по их описанию.

Модель

Я создал несколько дополнительных фичей, используя длину описания и количество токенов.

def get_lengths(df, columns=['tokens', 'description']):    lengths_df = pd.DataFrame()    for i, c in enumerate(columns):        lengths_df[f"{c}_len"] = df[c].apply(len)        if i > 0:            lengths_df[f"{c}_div"] = \                lengths_df.iloc[:, i-1] / lengths_df.iloc[:, i]            lengths_df[f"{c}_diff"] = \                lengths_df.iloc[:, i-1] - lengths_df.iloc[:, i]    return lengths_dfdf = pd.concat([df, get_lengths(df)], axis=1, sort=False, copy=False)

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

Для обучения используются данные Android-приложений.

android_df = df[df['store_os']=='android']ios_df = df[df['store_os']=='ios']

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

columns = [    'genre', 'tokens', 'bundle_update_period', 'tokens_len',    'description_len', 'description_div', 'description_diff',    'description', 'rating', 'reviews', 'score',    'released_at_month']

Я разделил данные на две части - train и validation. Обратите внимание, что разделение должно быть стратифицировано.

train_df, test_df = train_test_split(    android_df[columns], train_size=0.7, random_state=0, stratify=android_df['genre'])y_train, X_train = train_df['genre'], train_df.drop(['genre'], axis=1)y_test, X_test = test_df['genre'], test_df.drop(['genre'], axis=1)

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

В Нетрадиционный анализ тональности текста: BERT vsCatBoost я привожу пример того, как CatBoost работает с текстом и сравниваю его с BERT.

!pip install -U catboost

При работе с CatBoost рекомендую использовать Pool. Это удобная оболочка, объединяющая метки и другие метаданные, такие как категориальные и текстовые фичи. Бонусом идет снижение затрат памяти, так как не происходит дополнительная конвертация внутри библиотеки.

train_pool = Pool(    data=X_train,     label=y_train,    text_features=['tokens', 'description'])test_pool = Pool(    data=X_test,     label=y_test,     text_features=['tokens', 'description'])

Напишем функцию для инициализации и обучения модели. Я не подбирал оптимальные параметры; пусть это будет еще одним домашним заданием.

def fit_model(train_pool, test_pool, **kwargs):    model = CatBoostClassifier(        random_seed=0,        task_type='GPU',        iterations=10000,        learning_rate=0.1,        eval_metric='Accuracy',        od_type='Iter',        od_wait=500,        **kwargs    )return model.fit(        train_pool,        eval_set=test_pool,        verbose=1000,        plot=True,        use_best_model=True    )

Текстовые фичи используются для создания новых числовых фичей. Но для этого необходимо объяснить CatBoost, что именно мы хотим от него получить.

CatBoostClassifier имеет несколько параметров:

• tokenizersиспользуемые для предварительной обработки фичей текстового типа перед созданием словаря;

• dictionariesиспользуется для предварительной обработки фичей текстового типа;

• feature_calcersиспользуется для расчета новых фичей;

• text_processingобщий JSON-конфиг для токенизаторов, словарей и вычислителей, который определяет, как текстовые фичи преобразуются в фичи с плавающей точкой.

Четвертый параметр заменяет первые три и, на мой взгляд, самый удобный, так как в одном указывается, как работать с текстом.

tpo = {    'tokenizers': [        {            'tokenizer_id': 'Sense',            'separator_type': 'BySense',        }    ],    'dictionaries': [        {            'dictionary_id': 'Word',            'token_level_type': 'Word',            'occurrence_lower_bound': '10'        },        {            'dictionary_id': 'Bigram',            'token_level_type': 'Word',            'gram_order': '2',            'occurrence_lower_bound': '10'        },        {            'dictionary_id': 'Trigram',            'token_level_type': 'Word',            'gram_order': '3',            'occurrence_lower_bound': '10'        },    ],    'feature_processing': {        '0': [            {                'tokenizers_names': ['Sense'],                'dictionaries_names': ['Word'],                'feature_calcers': ['BoW']            },            {                'tokenizers_names': ['Sense'],                'dictionaries_names': ['Bigram', 'Trigram'],                'feature_calcers': ['BoW']            },        ],        '1': [            {                'tokenizers_names': ['Sense'],                'dictionaries_names': ['Word'],                'feature_calcers': ['BoW', 'BM25']            },            {                'tokenizers_names': ['Sense'],                'dictionaries_names': ['Bigram', 'Trigram'],                'feature_calcers': ['BoW']            },        ]    }}

Запустим обучение:

model_catboost = fit_model(    train_pool, test_pool,    text_processing = tpo)

bestTest = 0.6454657601

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

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

Чтобы получить такой вектор, нам нужно усложнить процесс, используя предсказания OOF (Out-of-Fold). Не будем использовать сторонние библиотеки; попробуем написать простую функцию.

def get_oof(n_folds, x_train, y, x_test, text_features, seeds):        ntrain = x_train.shape[0]    ntest = x_test.shape[0]              oof_train = np.zeros((len(seeds), ntrain, 48))    oof_test = np.zeros((ntest, 48))    oof_test_skf = np.empty((len(seeds), n_folds, ntest, 48))    test_pool = Pool(data=x_test, text_features=text_features)     models = {}    for iseed, seed in enumerate(seeds):        kf = StratifiedKFold(            n_splits=n_folds,            shuffle=True,            random_state=seed)                  for i, (tr_i, t_i) in enumerate(kf.split(x_train, y)):            print(f'\nSeed {seed}, Fold {i}')            x_tr = x_train.iloc[tr_i, :]            y_tr = y[tr_i]            x_te = x_train.iloc[t_i, :]            y_te = y[t_i]            train_pool = Pool(                data=x_tr, label=y_tr, text_features=text_features)            valid_pool = Pool(                data=x_te, label=y_te, text_features=text_features)            model = fit_model(                train_pool, valid_pool,                random_seed=seed,                text_processing = tpo            )            x_te_pool = Pool(                data=x_te, text_features=text_features)            oof_train[iseed, t_i, :] = \                model.predict_proba(x_te_pool)            oof_test_skf[iseed, i, :, :] = \                model.predict_proba(test_pool)            models[(seed, i)] = model    oof_test[:, :] = oof_test_skf.mean(axis=1).mean(axis=0)    oof_train = oof_train.mean(axis=0)    return oof_train, oof_test, models

Обучение трудозатратно, но в результате получили:

• oof_trainOOF-предсказания для Android приложений

• oof_testOOF-предсказания для iOS приложений

• modelsall OOF-модели для каждого фолда и сида

from sklearn.metrics import accuracy_scoreaccuracy_score(    android_df['genre'].values,    np.take(models[(0,0)].classes_, oof_train.argmax(axis=1)))

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

OOF accuracy: 0.6560790777135628

Я созданную фичу android_genre_vec, копируем значения из oof_train для приложений Android и oof_test для приложений iOS.

idx = df[df['store_os']=='ios'].indexdf.loc[df['store_os']=='ios', 'android_genre_vec'] = \    pd.Series(list(oof_test), index=idx)idx = df[df['store_os']=='android'].indexdf.loc[df['store_os']=='android', 'android_genre_vec'] = \    pd.Series(list(oof_train), index=idx)

Дополнительно был добавлен android_genre, в котором находится жанр с максимальной вероятностью.

df.loc[df['store_os']=='ios', 'android_genre'] = \    np.take(models[(0,0)].classes_, oof_test.argmax(axis=1))df.loc[df['store_os']=='android', 'android_genre'] = \    np.take(models[(0,0)].classes_, oof_train.argmax(axis=1))

После всех манипуляций, можно наконец-то посмотреть и сравнить распределение приложений по жанрам.

Итоги

В статье:

• представлен новый бесплатный датасет;

• сделан небольшой EDA;

• созданы несколько новых фичей;

• создана модель для предсказания жанров приложений по описаниям.

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

Код из статьи можно посмотреть здесь.

Главная сложность в разработке приложения накодить его функционал. Например, сделать редактирование текста для приложения-блокнота. Так я полагал, когда был моложе и наивнее.

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

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

О базовых продуктовых рисках говорить не буду. Понятно, что если вы не найдете свой product-market fit, то всё остальное уже не будет иметь значения. Поэтому давайте предположим, что вы придумали перспективную идею приложения, сделали грамотный кастдев, изучили рынок и конкурентов, продумали монетизацию, просчитали юнит-экономику и бизнес-модель, наняли толковую команду. Вроде все схвачено Или нет?

1. Выбор фреймворка

Ещё до написания первой строчки кода вы встанете перед судьбоносным выбором: делать приложение нативно под каждую платформу (iOS / Android) или на кроссплатформенном фреймворке?

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

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

Что почитать по теме?

• Кроссплатформенная мобильная разработка: история вопроса

• Больше всех пахала лошадь, но председателем колхоза так и не стала

• Как правильно переходить границу: кроссплатформенность в мобильном приложении

• Натив или гибрид? Специалисты Яндекса отвечают на главный вопрос мобильной разработки

• Когда имеет смысл писать кроссплатформенные приложения: появление и исчезновение React Native в Lingualeo

• Новое приложение Медузы. Почему Flutter?

• Почему Flutter побеждает?

2. Устаревание кода

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

Обновлять приходится всё: фреймворк, SDK, библиотеки, работу с внешними API, поддержку новых версий iOS и Android.

Если не обновить код вовремя произойдет одно из двух:

• Ваш релиз не пройдет ревью, то есть вы не сможете обновлять приложение.

• С ревью проблем не возникнет, но что-то в приложении перестанет работать.

Кому-то это покажется мелочью ну что там, код иногда нужно переписать.

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

Что почитать по теме?

• Разрабатывать приложения под Android словно быть (демонетизированным) ютубером

• В macOS 10.15 более не поддерживаются 32-битные приложения. Что вы можете сделать?

• Уровень Android API, обратная и прямая совместимость

• Кремлевские девойки

3. Требования стора

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

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

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

Например, однажды мы полтора месяца вели переговоры с Apple. Переписывались, созванивались, объясняли, как работает приложение, высылали документ с описанием нашей бизнес-модели Всё это время мы не могли зарелизиться, а наши пользователи сидели с непофикшеными багами. По итогу пришлось вырезать из приложения функционал, который делал жизнь пользователей проще. Забавно, что приложение жило с этим функционалом уже пару лет и претензий со стороны App Store не было.

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

Что почитать по теме?

• За что Android-разработчики ненавидят Google

• Почему я как разработчик ненавижу iOS

• Как я разочаровался в Google Play

• App Store не позвонит. Или как я сделала своё приложение, но оно не попадёт к пользователям

• Я сделал PWA и выложил в трёх магазинах приложений. И вот что я выяснил

4. Видимость в поиске

Не важно, насколько классное приложение вы сделали, если его никто не скачает. Например, когда я впервые зарелизил свое приложение оно появилось в выдаче только через 10 дней, на 143 позиции!

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

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

К тому же, сторы держат алгоритм ранжирования в секрете и он может меняться со временем.

Что почитать по теме?

• Продвижение мобильных приложений: выученные уроки

• Как продвигать мобильное приложение в 2019 году: 4 практических способа + полезные инструменты

• ASO: ранжирование в App Store и Google Play (найди 10 отличий в алгоритмах)

• Как повысить рейтинг приложения в Google Play?

• О том, как выпустить отличное iOS приложение, которое никому не нужно

• Как я слил 1000$ в продвижение игры и что из этого получилось

5. Мобильная аналитика

Аналтика это всегда непросто.

Google Analytics стремится засемплировать ваши данные, события Amplitude блокируются браузерами пользователей, а в атрибуции каналов сам черт ногу сломит.

Но с мобильной аналитикой всё ещё хуже.

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

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

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

Эти проблемы решаемы, но такими мудреными способами, что вам захочется всё бросить и уйти в монастырь web-разработку.

Кроме того, если у вас есть и сайт, и приложение аналитика поведения пользователей может оказаться нетривиальной задачей. Особенно, если вам нужно построить сквозной дашборд.

Что почитать по теме?

• Сравнение аналитических систем для мобильного маркетинга

• Мобильный маркетинг: расхождения в статистике установок

• Переход от Google Analytics к Firebase

• Запуск мобильного ретаргетинга с Appsflyer: настройки, отчеты и ссылки

• Универсальные ссылки: дворец из подводных камней

6. Внешняя аутентификация

До сих пор многие сайты используют email как единственный способ регистрации. Но большинство приложений просто не может себе такого позволить.

Прежде всего, это неудобно для пользователя: вся это возня с подтверждением email, вводом пароля с экранной клавиатуры и так далее. А для некоторых проектов, вроде небольших мобильных игр это вообще смерти подобно. Пользователь, увидев сложную регистрацию, просто удалит такую игру и установит следующую.

Поэтому приходится прикручивать другие способы входа через FB, VK, Apple, Google, Telegram. Но это сторонние сервисы, которые живут своей жизнью. А значит, ваша аутентификация может сломаться только потому, что Facebook что-то изменил на своей стороне. А он изменит, не сомневайтесь.

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

Например, Apple заставит вас сделать вход через Apple ID. Только вот на сайте у вас вряд ли был Apple ID. Как связать эти аккаунты? По email? Ок, вы будете запрашивать еще и email во время регистрации в приложении через Apple ID. Но пользователь мог зарегистрироваться в Apple под другим emailом. Или просто запретил передавать email в настройках.

Тут столько подводных камней, что хватило бы на отдельную статью.

Что почитать по теме?

• Внедряем Sign in with Apple систему авторизации от Apple

• Использование OAuth и API VK в Go

• Авторизация с помощью Facebook и Vkontakte в одностраничном приложении на Backbonejs + Express

• Авторизация пользователя на вашем сайте через Telegram для Django

• Аутентификация OAuth2 в приложении посредством Google Sign-In. Непрерывный доступ к API Google

7. Адаптивный дизайн

Хочется, чтобы приложение смотрелось прилично хотя бы на актуальных смартфонах. Только вот смартфонов этих тысячи, и отличаются они не только разрешением, но и пропорциями, и плотностью пикселей. А есть еще и особенности конкретных моделей, вроде моноброви у iPhone X.

Кроме того, встречается как натуральный Android (например, у Samsung или Google), так и смартфоны, использующие ядро Android + свою интерфейсную обертку (например, Xiaomi). Где-то клавиши навигации аппаратные, где-то виртуальные, а где-то их вообще нет.

Поэтому не думайте, что адаптировать дизайн под весь этот зоопарк простая задача. Для каждого разрешения нужно:

• растянуть интерфейс и контент под размеры экрана;

• масштабировать изображения без потери качества;

• масштабировать элементы управления, чтобы ими комфортно было пользоваться;

• выдерживать размер шрифтов так, чтобы тексты были читабельны;

• избежать наслоения элементов;

• не дать целевым кнопкам уйти за пределы экрана;

• продумать поведение экранной клавиатуры.

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

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

Что почитать по теме?

• Руководство для дизайнера по DPI

• О размере экрана, пикселя и элемента

• Оптимизация графики для Retina-экранов

• 32 отличия дизайна мобильного приложения под iOS и Android

• Поясняем за чёлку в Android P. Что делать с Android Cutout?

8. Организация тестирования

Тестирование приложения заметно отличается от тестирования сайта. Причем не в лучшую сторону. Поэтому если вы планировали, что ваши web QA быстро просмотрят приложение перед релизом и всё будет хорошо вероятно, вас ждет разочарование.

Вот на что стоит обратить внимание:

• Разнообразие устройств и разрешений.

• Большой разброс версий операционных систем.

• Мобильные механики: мультитач, работа в фоне, аппаратные кнопки, экранная клавиатура.

• Ресурсы телефона: производительность, расход заряда, утечки памяти.

• Плохая скорость интернета или его отсутствие.

• Внезапные прерывания: смс, звонки, разряд аккумулятора.

• Работа push-уведомлений.

Типичная ситуация, когда баг возникает только на 10% устройств. Вы узнаете об этом только из жалоб пользователей. А у вас такого устройства просто нет. Как тогда воспроизвести баг и понять, что удалось его починить? Можно использовать эмуляторы, но они не эмулируют аппаратную часть. Есть ещё фермы устройств, но они тоже не идеальны например, не позволяют пощупать свой продукт.

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

К качеству мобильного тестирования особые требования: в отличие от web, вы не сможете быстро пофиксить баг, если QA его пропустили. Придется снова собирать билд, отправлять его на ревью, ждать эпрув.

Что почитать по теме?

• Что общего у мобильного QA и осьминога

• 7 лучших ферм устройств для тестирования мобильных приложений

• Управление фермой Android-устройств. Лекция в Яндексе

• Гиперкуб. Как мы обеспечили разработчиков тестовыми устройствами и не потеряли их

• Как настроить расширяемую систему для регрессионного тестирования на телефонах: опыт мобильной Почты Mail.Ru

• Мобильное тестирование, автоматизация тестирования, тестирование API: с чем нужно уметь работать в 2021 году

9. Поддержка версионности

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

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

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

Нет-нет, постойте, вот вам задачка на подумать: если вы релизите бэкенд в понедельник и в тот же день отправляете билд в сторы то в Google Play приложение обновится в среду, а в Apple Store через неделю. То есть у вас невольно получится три разных даты релиза и несовпадение версий фронтенда и бэкенда как это вообще должно работать?

Что почитать по теме?

• Версионность веб-приложений

• Версионная миграция структуры базы данных: основные подходы

• Генерируем номер версии и билда на иконке iOS приложения

• Инструмент автоматизации управления версиями

10. Работа офлайн

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

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

Что с этим делать? Как минимум выдать ошибку и объяснить пользователю, что происходит. Как максимум сделать офлайн-режим или скачивание данных на устройство (как это сделано у Google Maps или 2GIS, например).

Но офлайн-режим это не только работа без интернета. Это еще и система синхронизации с сервером. В общем, задача не самая тривиальная, придется повозиться.

Что почитать по теме?

• Автономность в первую очередь

• Поиск без интернета. Новая бета приложения Яндекс

• Как мы запустили offline-версию сайта RG.RU

• Переходим В OFFLINE FIRST с использованием Core Data и Managed Document(s)

• Amelisa. Оффлайн и реалтайм движок для React и Mongo

• Оффлайн-режим на iOS и особенности его реализации на Realm

11. Push-уведомления

Уведомления самый удобный способ взаимодействовать с мобильными пользователями вне приложения. Вряд ли вам удастся пренебречь таким инструментом.

Но прикрутить механику отправки пушей это только полдела. А вот вторая половина:

• Как вы будете отправлять пуши? По расписанию, по триггерам или вручную? Не исключено, что вам понадобятся все три способа.

• Если уведомления отправляются по расписанию нужно учитывать время и часовой пояс получателя. От разбуженного среди ночи пользователя не ждите слов любви.

• Если пуши отправляются по триггерам реализация самих триггеров может оказаться трудоемкой задачей.

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

• Вероятно, вам понадобится отдельная логика отправки пушей: очередь, приоритеты, ограничения.

Все вышесказанное будет не особо эффективно, если только 10% пользователей согласятся получать уведомления. Поэтому отдельный квест: как грамотно запросить разрешение на отправку. Ведь если пользователь нажмет Запретить исправить это почти невозможно.

Что почитать по теме?

• 5 ошибок в реализации push-уведомлений для мобильных приложений

• Безопасные push-уведомления: от теории к практике

• Основы успешной реализации push-уведомлений для мобильных приложений

• Пара способов отправить уведомления на смартфон со своего сервера

• Внедряем кросс-платформенные пуш-уведомления: дополнительные возможности

12. Перевод и локализация

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

Локализация почти всегда выглядит простой задачей, и почти всегда это не так.

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

Стоит ли говорить, что перевод это только часть локализации?

Что почитать по теме?

• Локализация приложения за 10 шагов

• Локализация приложений: как мы подружили перевод и разработку

• Локализация мобильных приложений: основные сложности и лайфхаки

• Что разработчику нужно знать о локализации приложения

• UX при локализации приложений: пособие разработчика

• Гайд по тестированию локализации и интернационализации, а также большой и полезный checklist

13. Защита приложения

Если вы делаете приложение попроще, чем Telegram / Monobank / VK то вряд ли вопрос безопасности не дает вам уснуть. Тем не менее, по моему опыту, даже маленькие приложения ломают.

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

Более наглые ребята могут ломать ваше приложение прямо в сторе. Говорят, что особенно легко это делать в Google Play. Есть разные способы, расскажу, как было у нас.

Между покупкой в приложении и фактическим подтверждением платежа от стора есть окно, примерно от часа до суток. Конечно, если пользователь сделал оплату мы не можем заставлять его ждать сутки, прежде чем дать доступ к контенту. Поэтому мы выдаем доступ сразу.

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

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

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

Что почитать по теме?

• Топ-10 уязвимостей мобильных приложений и способы их устранения

• Безопасность данных в разработке мобильных приложений

• Разработчик, помни трафик твоего приложения смотрят

• Нарушения безопасности мобильных приложений как результат недостаточного внимания компаний-разработчиков

• Безопасность Android-приложений. Лекция в Яндексе

• Двухфакторная аутентификация, которой удобно пользоваться

That's all Folks!

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

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

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

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

Дисклеймер

Сразу предупрежу, что люблю писать подобные статьи довольно подробно, не ради объема и многобукав, а ради максимального погружения в проблему и способ ее решения. Обратите внимание, что я работаю на macOS, поэтому все команды в терминале будут ориентированы под данную ОС.

Как до этого дошло?

Мне выслали .apk файл приложения. Где-то внутри приложения есть баг, который мне нужно воспроизвести. Но пройти вглубь приложения у меня не получается. Мое устройство не проходит проверку на рутованность.

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

Что будем делать?

Первое, что пришло мне в голову, так это попробовать выполнить декомпиляцию и поправить кое-где код, а потом собрать все обратно. Основное сомнение по поводу такого подхода вызывало то что, у меня не нативное android-приложение, а flutter-приложение. То есть как такового основного кода приложения в виде байт-кода в .apk найти не получится. Или получится? И нужен ли мне код самого приложения?

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

Таким образом, я сделал вывод, что в имеющемся .apk файле есть как минимум 2 интересующих меня места в виде байт-кода. Первое место - это нативная часть приложения, которая слушает команды из flutter части приложения, чтобы вызвать соответствующие нативные методы. И второе место - это собственно и есть эти самые нативные методы, а в данном случае - библиотека для проверки на рутованность устройства.

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

Смотрим байт-код .apk

Итак, посмотрим на внутренности .apk. Для этого можно воспользоваться инструментом, предоставляемый Android Studio. В меню выбираем Build -> Analyze APK В окне выбора файла находим интересующий нас .apk.

Весь скомпилированный байт-код хранится в файле classes.dex. Выберем его и взглянем на его содержимое. В первую очередь нас интересуют не файлы java или androidx, а именно файлы приложения. Поэтому выбираем первый package в структуре файлов android проекта, в моем случае это папка com. Из любопытства к содержимому каждой из папок я затригерился на слово rootbeer. Погуглив в гугле оказалось, что это весьма популярная библиотека для проверки устройства на предмет рутованности.

Исследовав документацию и исходники библиотеки стало ясно о том, как пользоваться библиотекой и где располагается ключевой метод isRooted().

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

Судя по исходникам библиотеки, нужный мне файл должен находится рядом с классом RootBeerNative, и как мы видим тут таких, два a и b. Эмпирическим методом я понял, что это файл b. Правый клик по файлу b и в выпадающем меню выбираем Show Bytecode.

К сожалению, имена всех методов обфусцированы. Снова обращаясь к исходному файлу на github становится ясно, что метод isRooted() находится на строке 42. Побегав по файлу с байт-кодом мне удалось найти этот метод. Только теперь он называется a() и почему-то начинает работу с .line 43. Вот этот метод я и буду редактировать. Но не так быстро, К сожалению здесь только Read-only доступ.

Редактируем содержимое classes.dex

Для этого придется декомпилировать весь .apk при помощи популярного инструмента apktool. Работать с ним довольно просто. После его установки нам понадобятся всего 2 команды:

apktool d appname.apk, которая декомпилирует указанный .apk и apktool b directory_with_app, которая соберет .apk обратно (в указанной directory_with_app должен располагаться файл apktool.yml).

Итак, выполняю декомпиляцию при помощи команды в терминале: apktool d app.apk

После выполнения команды появляется папка с файлами приложения. Нас интересует папка smali. Smali - это язык которым описан байт-код (вот классная статья по основам smali). Именно эта папка и есть содержимое файла classes.dex. К только что выполненной команде можно добавить параметр --skip-sources или просто -s тогда вместо папки smali мы увидим тот самый файл classes.dex.

Далее, в папке smali находим интересующий и уже известный нам файл b.smali:

Открываем его любым текстовым редактором и переходим к месту, где располагается метод isRooted():

.method public a()Z    .locals 1    .line 43    invoke-virtual {p0}, Lcom/scottyab/rootbeer/b;->c()Z    move-result v0    if-nez v0, :cond_1    invoke-virtual {p0}, Lcom/scottyab/rootbeer/b;->d()Z    move-result v0    if-nez v0, :cond_1    const-string v0, "su"    invoke-virtual {p0, v0}, Lcom/scottyab/rootbeer/b;->a(Ljava/lang/String;)Z    move-result v0    if-nez v0, :cond_1    const-string v0, "busybox"    .line 44    invoke-virtual {p0, v0}, Lcom/scottyab/rootbeer/b;->a(Ljava/lang/String;)Z    move-result v0    if-nez v0, :cond_1    invoke-virtual {p0}, Lcom/scottyab/rootbeer/b;->f()Z    move-result v0    if-nez v0, :cond_1    invoke-virtual {p0}, Lcom/scottyab/rootbeer/b;->g()Z    move-result v0    if-nez v0, :cond_1    .line 45    invoke-virtual {p0}, Lcom/scottyab/rootbeer/b;->b()Z    move-result v0    if-nez v0, :cond_1    invoke-virtual {p0}, Lcom/scottyab/rootbeer/b;->h()Z    move-result v0    if-nez v0, :cond_1    invoke-virtual {p0}, Lcom/scottyab/rootbeer/b;->j()Z    move-result v0    if-nez v0, :cond_1    invoke-virtual {p0}, Lcom/scottyab/rootbeer/b;->e()Z    move-result v0    if-eqz v0, :cond_0    goto :goto_0    :cond_0    const/4 v0, 0x0    goto :goto_1    :cond_1    :goto_0    const/4 v0, 0x1    :goto_1    return v0.end method

Можем сравнить его с неповторимым оригиналом:

Очень похожи. Итак, нас интересует return, то есть самый конец метод. Видим, что метод возвращает некоторое значение константы v0, значение которой определяется на основе выполнивших в методе условий. Нам это не подходит. Нам всегда нужно возвращать false или же как это будет в smali 0x0. Для этого добавим свою констант v1 со значением 0x0. Сделаем это прямо над return:

:goto_1const/4 v1, 0x0return v1

И конечно же заменим в return v0 на v1. Поднимемся в самое начало метода и изменим значение .locals с 1 на 2 потому, что так надо. Сохраняем изменения в файле и закрываем редактор.

Собираем .apk обратно

Для этого воспользуемся командой apktool b app, где app - папка с приложением, в котором мы редактировали smali файл. После завершения команды, в папке app появиться директория dist. Здесь и расположен наш заново собранный .apk. Однако при попытке установить его мы получим следующую ошибку:

The APK failed to install.Error: INSTALLPARSEFAILEDNOCERTIFICATES: Failed collecting certificates for /data/app/vmdl164530405.tmp/base.apk: Failed to collect certificates from /data/app/vmdl164530405.tmp/base.apk: Attempt to get length of null array

Это из-за того, что после пересборки нужно еще и переподписать приложение. Для этого нам понадобиться любой keystore файл. Или можно создать новый при помощи команды:

keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000

Подписать ключом приложение можно при помощи одного из двух инструментов: apksigner или jarsigner.

Я выбрал jarsigner используя следующую команду:

jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore keystore app.apk cp_key

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

Однако и это еще не все, теперь при попытке установить .apk мы будем получать другую ошибку:

The APK failed to install.Error: INSTALL_FAILED_INVALID_APK: Failed to extract native libraries, res=-2

Это потому, что после подписи приложения нужно выполнить оптимизацию .apk файла при помощи инструмента zipalign.

Для выполнения оптимизации нужно ввести следующую команду: ~/Library/Android/sdk/build-tools/30.0.3/zipalign -v -f -p 4 app.apk rdy.apk

30.0.3 - я выбрал самую последнюю версию на момент написания статьи. После завершения команды на выходе получаем файл rdy.apk, который можно успешно установить! Проверим, получилось ли обойти проверку на рутованность устройства:

И да, это успех!

Заключение

Вызов принят - вот, что я подумал получив этот .apk. И считаю это маленькой победой. Данной статьей я стремился описать не просто инструкцию о том, как расковырять приложение или свои способности по типу "смотрите как могу". Этой статьей я хочу сказать (и напомнить тем, кто стал забывать) что большинство проблем решаемы, нужно только копать, копать и еще раз копать, не опускать руки и результат обязательно будет удовлетворительным. Даже если, в конце концов, баг я так и не обнаружил, я очень рад что расширил свой кругозор и в дальнейшем смогу взяться за более сложные задачи! Спасибо за внимание, обязательно буду писать еще про подобные танцы с бубном!

Всем привет, меня зовут Мария и я CEO & co-founder компании Технофабрика. Продолжаю делиться заметками из жизни команды разработки и сегодняшняя тема дня ожидания и реальность коробочных решений. Про масштабирование, кастомизацию, поддержку, доработку и вот это вот все.

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

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

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

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

Поймите же, в 90% случаев, когда вы пишите или заставляете кого-то писать код, он на самом деле, совершенно никому не нужен. Чем меньше вы плодите кода, тем лучше. Прекратите все писать свой код, сейчас же!

Про готовое

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

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

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

Так и с готовыми приложениями. Если вам нужно что-то непритязательное и прямщас, например, вы придумали небольшой стартап с полутора сотрудниками и вам нужно проверить свою идею не позже чем до конца месяца, такое решение в самый раз. Не нужно задумываться ни о качестве теста, ни о свежести ингредиентов. Ну не нобелевский обед же накрываем, ну. Да, может подглючивать, вылетать и не совсем идеально подпадать под ваши конкретные нужды. Но в качестве быстрого старта почему бы и нет? Why do we call it beta? Cuz its beta then nothing!

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

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

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

И вот тут начинается ад. Причем как для вас, так и для тех, к кому вы обратитесь.

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

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

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

и кастомное

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

1. Этот код написан специально под ваш бизнес

2. Этот код легко масштабируется, меняется, поддерживается и дополняется не только теми, кто его писал, но и любыми другими разработчиками.

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

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

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

Да, ресторан дороже. Да, пицца дешевле. Но что именно сейчас предпочтительнее по масштабу, качеству и больше соответствует моменту решать вам.

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

Что такое Vision

Из документации Apple: "Vision применяет алгоритмы "компьютерного зрения" для выполнения множества задач с входными изображениями и видео. Фреймворк Vision выполняет распознание лиц, обнаружение текста, распознавание штрих-кодов, регистрацию изображений. Vision также позволяет использовать пользовательские модели CoreML для таких задач, как классификация или обнаружение объектов."
Анализируя документацию Apple, можно предположить, что Vision - это один из этапов подготовки таких продуктов как Apple glasses или шлем смешанной реальности. Забегая вперед, следует подчеркнуть, что данный фреймворк потребляет изрядное количество ресурсов. Обработка статичного изображения может занимать десятки секунд, следовательно, работа с видео в реальном времени будет предельно ресурсоемким процессом, над оптимизацией которого инженерам Apple еще предстоит поработать.
В рамках поставленной задачи, необходимо было решить следующую проблему: распознание блоков текста с помощью Vision.

Разработка

Проект построен на UIKit, который в данной статье детально рассматриваться не будет. Основное внимание уделяется блокам кода, связанным с фреймворком Vision. Приведенные листинги снабжены комментариями, позволяющими разработчикам детальнее понять принцип работы с фреймворком.
В MainViewController, который будет взаимодействовать с фреймворком Vision, нужно объявить две переменные:

//Recognition queuelet textRecognitionWorkQueue = DispatchQueue(label: "TextRecognitionQueue", qos: .userInitiated, attributes: [], autoreleaseFrequency: .workItem)//Request for text recognitionvar textRecognitionRequest: VNRecognizeTextRequest?

1. Очередь для задач Vision не вызывает никаких затруднений у разработчиков. Именно в ней будут выполняться все задачи фреймворка.

2. Объявляется переменная типа VNRecognizeTextRequet. Инициализируется объект из ViewDidLoad (или из init), так как он должен быть активен на протяжении всей жизни ViewController. Этот объект отвечает за работу с Vision, поэтому необходимо разобрать его инициализацию подробнее:

//Set textRecognitionRequest from ViewDidLoadfunc setTextRequest() {    textRecognitionRequest = VNRecognizeTextRequest { request, error in        guard let observations = request.results as? [VNRecognizedTextObservation] else {            return        }        var detectedText = ""        self.textBlocks.removeAll()                    for observation in observations {            guard let topCandidate = observation.topCandidates(1).first else { continue }            detectedText += "\(topCandidate.string)\n"                        //Text block specific for this project            if let recognizedBlock = self.getRecognizedDoubleBlock(topCandidate: topCandidate.string, observationBox: observation.boundingBox) {                self.textBlocks.append(recognizedBlock)            }        }                    DispatchQueue.main.async {            self.textView.text = detectedText            self.removeLoader()            self.drawRecognizedBlocks()        }    }            //Individual recognition request settings    textRecognitionRequest!.minimumTextHeight = 0.011 // Lower = better quality    textRecognitionRequest!.recognitionLevel = .accurate}

Настройки объекта textRecognitionRequest. Описание всех доступных настроек можно найти в документации. Наиболее важным является параметр minimumTextHeight. Именно этот параметр отвечает за сочетание быстродействия и точности распознания текста. Для каждого проекта необходимо найти индивидуальное значение данного параметра, оно зависит от того, какие данные будет обрабатывать приложение.
Так как основной поставленной задачей являлось считывание текста с квитанций, для вычисления значения параметра minimumTextHeight в приложение были добавлены различные типы квитанций в различном состоянии (в том числе и основательно помятые). В результате тестирования было определено значение равное 0.011. В случае распознания текста с квитанций, это значение лучшим образом сочетает в себе быстродействие и точность. Однако нужно отметить, что текст с одного изображения распознается в среднем за пять секунд. Подобной скорости недостаточно для обработки информации в реальном времени и ее следует значительно оптимизировать инженерам Apple.
На основе представленного кода можно сделать вывод, что после операции распознания, объект типа VNRecognizeTextRequet получает блоки текста. Именно с ними и ведется дальнейшая работа, в зависимости от функций приложения. В рассматриваемом примере, каждый распознанный фрагмент текста был внесен в текстовое поле. Так как особенностью задействованного приложения является выделение суммы на квитанции, следовательно, сохранялись только блоки текста, которые можно преобразовать в тип Double. Помимо распознанного текстового значения сохраняются и координаты блока текста на изображении.
Представленный ниже метод отвечает за запуск работы запроса на распознание:

//Call text recognition request handlerfunc recognizeImage(cgImage: CGImage) {    textRecognitionWorkQueue.async {        let requestHandler = VNImageRequestHandler(cgImage: cgImage, options: [:])        do {            try requestHandler.perform([self.textRecognitionRequest!])        } catch {            DispatchQueue.main.async {                self.removeLoader()                print(error)            }        }    }}

В метод передается объект CGImage, в котором необходимо распознать текст. Вся работа по распознанию ведется в созданной для этого очереди. Создается объект VNImageRequestHandler, в который передается распознаваемый объект CGImage. В блоке do/try/catch запускается работа инициализированного объекта типа VNRecognizeTextRequet.
Описанные выше функции отвечают за распознание текста в приложении. Однако стоит еще остановится на методах, связанных с выделением нужных блоков текста.

func drawRecognizedBlocks() {    guard let image = invoiceImage?.image else  { return }        //transform from documentation    let imageTransform = CGAffineTransform.identity.scaledBy(x: 1, y: -1).translatedBy(x: 0, y: -image.size.height).scaledBy(x: image.size.width, y: image.size.height)            //drawing rects on cgimage    UIGraphicsBeginImageContextWithOptions(image.size, false, 1.0)    let context = UIGraphicsGetCurrentContext()!    image.draw(in: CGRect(origin: .zero, size: image.size))    context.setStrokeColor(CGColor(srgbRed: 1, green: 0, blue: 0, alpha: 1))    context.setLineWidth(4)        for index in 0 ..< textBlocks.count {        let optimizedRect = textBlocks[index].recognizedRect.applying(imageTransform)        context.addRect(optimizedRect)        textBlocks[index].imageRect = optimizedRect    }    context.strokePath()            let result = UIGraphicsGetImageFromCurrentImageContext()    UIGraphicsEndImageContext()    invoiceImage?.image = result}

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

struct RecognizedTextBlock {    let doubleValue: Double    let recognizedRect: CGRect    var imageRect: CGRect = .zero}

При распознании блоков текста фреймворк Vision вычисляет ряд важных параметров в объекте VNRecognizedTextObservation. Для нужд рассматриваемого проекта необходимо было получить только значение типа Double и его координаты на изображении, сохраняемые в константе recognizedRect.
Для выделения блока текста на изображении, следует применить трансформацию к координатам из константы recognizedRect. Полученные координаты так же сохраняются в объекте RecognizedTextBlock в переменной imageRect, необходимой для обработки нажатий на выделенные блоки текста.
После сохранения точных координат выделяемых блоков на изображении, обработку нажатий на выделенные области можно осуществить несколькими способами:

• Добавить необходимое количество невидимых кнопок на изображение, при помощи трансформации сохраненного объекта imageRect;

• При каждом нажатии на изображение проверять массив блоков текста и искать совпадение координат нажатия с сохраненным объектом imageRect и др.

Чтобы не перегружать ViewController дополнительными элементами, был использован второй способ.

//UIImageView tap listener@objc func onImageViewTap(sender: UITapGestureRecognizer) {    guard let invoiceImage = invoiceImage, let image = invoiceImage.image else {        return    }            //get tap coordinates on image    let tapX = sender.location(in: invoiceImage).x    let tapY = sender.location(in: invoiceImage).y    let xRatio = image.size.width / invoiceImage.bounds.width    let yRatio = image.size.height / invoiceImage.bounds.height    let imageXPoint = tapX * xRatio    let imageYPoint = tapY * yRatio    //detecting if one of text blocks tapped    for block in textBlocks {        if block.imageRect.contains(CGPoint(x: imageXPoint, y: imageYPoint)) {            showTapAlert(doubleValue: block.doubleValue)            break        }    }}

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

Выводы

Представленная статья позволяет разработчикам IOS-приложений ознакомиться с фреймворком Vision, прежде всего с его функцией распознания текста. Тестовое приложение, полученное в результате работы с распознанием текста в Vision, является ключом к пониманию работы с такими возможностями фреймворка как распознание лиц, текста, штрих-кодов и др.
Cкриншоты полученного приложения для распознавания цифровых значений на различных изображениях представлены ниже:

Для ознакомления проект можно скачать из репозитория.

3 марта 2021 года разработчики Google представили Flutter 2. Что появилось в новой версии языка Dart? Как теперь быть с разработкой и поддержкой приложений, созданных с использованием Flutter предыдущих версий? И, самое главное, насколько сложно будет мигрировать на версию 2? В этой статье подробно опишем опыт миграции приложения на новую версию Flutter и проблемы, которые могут возникнуть в процессе миграции.

Кто такой и зачем нужен Flutter?

Для тех, кто набрел на статью случайно и понятия не имеет, что такое Flutter это технология от Google для разработки кроссплатформенных мобильных приложений - да, да приложения будут работать и на Android, и на iOS устройствах. Flutter активно завоевывает сердца разработчиков и очень быстро идет от только мобильной разработки к Web и Desktop. Он достаточно прост в освоении, позволяет отказаться от одновременной разработки двух приложений для Android и iOS, он показывает высокую производительность и значительно ускоряет разработку приложений. Ну не прелесть ли? Первая версия была представлена в начале 2018, а спустя два года мы уже видим Flutter 2 с весьма серьезными доработками и нововведениями.

Что появилось во Flutter 2?

Наиболее громкие изменения:

• Новая версия языка Dart 2.12 c Sound null safety;

• Выход Flutter for web;

• Большой шаг к мультиплатформенности с Flutter for desktop.

Разработчики обещают, что миграция существующих решений на Flutter 2 должна пройти просто и быстро, есть гайды по миграции с примерами простых приложений, но можем ли мы им доверять, имея на руках приложение с множеством экранов, общающееся с сервером по api и использующее внешние библиотеки?

Если изменения по части Web и Desktop не затрагивают существующие приложения, то sound null safety может потребовать доработок. Почему и зачем sound null safety вообще нужна? Sound null safety - это фича, которая появилась в новой версии языка Dart 2.12, вышедшей вместе с Flutter 2.0. На просторах сети уже довольно много сказано о нововведениях и о null safety, поэтому очень подробно на этом останавливаться не будем. Но для целостности картины происходящего немного все же нужно сказать.

До появления Sound null safety все переменные в языке Dart могли принимать значение null. Если разработчик забывал добавить проверку на null перед использованием переменной, то во время работы приложения внезапно можно было получить экран со следующим содержанием:

Не самые приятные события. Разработчики понимают, что такую проверку легко забыть сделать, и, если вместо ссылки на экземпляр определенного типа мы получаем null, который ничего не знает о методах и состояниях экземпляра, мы имеем красный экран смерти с NoSuchMethodError.

Решить эту проблему призван Sound null safety, основные принципы которого:

• Безопасность кода по умолчанию - все переменные, которые мы создаем, по умолчанию будут non-nullable, пока мы не разрешим им другого поведения.

• Простота написания кода - с этим все понятно: не хотелось бы в обмен на безопасность получать сложности в написании и понимании кода.

• Непротиворечивость кода - если мы определяем какую-то переменную как переменную non-nullable типа, то она абсолютно точно никогда не будет равна null. Как сказал Евгений Сатуров в своем подкасте, это самый главный принцип Sound null safety, и загадочное sound переводится именно как непротиворечивость.

Итак, в языке Dart иерархия типов претерпевает некоторые изменения:

Null больше не является подтипом для всех типов, а существует по соседству с ними. Если у нас есть переменная типа String, то она всегда будет содержать строку. Но на практике, конечно, случаются ситуации, когда нужно использовать null в качестве значения для переменной.

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

Ниже пример использования этого типа в деле приготовления бургеров:

makeBurger(String burger, [String? meat]) {  if (meat != null) {    print('$burger with $meat');  } else {      print('Vegan $burger'); }}

Пользоваться переменными с ? небезопасно, поэтому нужно прибегать к дополнительным проверкам на null или специальным операторам .

Более подробно о новой иерархии типов можно почитать в официальной документации здесь.

В изменениях типов по умолчанию кроются сложности и страхи миграции проекта на Flutter 2. Второй момент, вызывающий опасения, это сторонние пакеты из pub.dev. На момент написания статьи более 85% пакетов из топ-250 на pub.dev уже поддерживают null safety. Никто, конечно, не застрахован от того, что нужный пакет и вовсе больше не поддерживается, поэтому перед использованием стоит проверить нужный пакет на pub.dev.

Подготовка к миграции кода

Начнем переезжать на Flutter 2, подсматривая в официальный гайд с использованием мигратора.

Первым делом, конечно же, обновляем Dart и Flutter до последних версий с помощью команды:

flutter upgrade

Вместе с Flutterом обновляется и Dart до версии 2.12.

Помимо SDK, нужно обновить плагины Flutter и Dart, сделать это можно в среде разработки. В AndroidStudio откроем Settings->Plugins. Там нас уже ждут кнопочки Update. Для применения апдейта обязательно потребуется перезапуск среды.

Далее проверяем, что все пакеты, которые мы используем в своем проекте, обновлены до версии с поддержкой null safety. Сделать это можно с помощью команды:

dart pub outdated --mode=null-safety

Выполнять ее нужно из директории проекта, оттуда, где лежит файл pubspec.yaml, который как раз анализируется на присутствие устаревших пакетов. Если такие пакеты в проекте есть, в консоли будет подсказка с информацией, кому из них требуется обновление, с какой версии пакета начата поддержка null safety, и какая версия наиболее свежая. У нас целых 5 таких пакетов.

Здесь Dart подсказывает нам, что для автоматической смены версий пакетов можно воспользоваться командой:

dart pub upgrade --null-safety

Пробуем, не получается

Кажется, пакет device_id все еще не может в null safety. На pub.dev выясняется, что все еще хуже: обновляли его последний раз в апреле 2019. Но есть и хорошие новости, этот пакет в проекте используется только в одном месте при формировании http запросов к серверу для определения ID устройства. Уходит некоторое время на поиски и тестирование альтернативы, удается найти null safety пакет, в котором есть методы для определения ID устройства, - platform_device_id. Если бы такой альтернативы не нашлось, пришлось бы делать форк и допиливать пакет самостоятельно. Добавляем platform_device_id актуальной версии в pubspec.yaml вместо device_id. Пробуем выполнить апгрейд пакетов еще раз.

Теперь все сработало отлично, пакеты обновлены!

Другой путь обновления пакетов: поправить версии руками в pubspec.yaml, а потом выполнить команды:

dart pub get

dart pub upgrade

Результат будет таким же.

Сразу переходить к миграции кода в нашем случае не получается: в проекте появились ошибки. Методы post() и get() пакета http в новой версии поменяли тип аргумента uri, вместо String теперь нужен Uri. Эта проблема тоже довольно быстро решается с помощью метода Uri.parse().

После обновления SDK, плагинов и пакетов проект все еще собирается и работает, но остается самый главный шаг - миграция кода.

Миграция кода

Ее можно осуществить вручную или воспользоваться мигратором, вызвав команду:

dart migrate

Мигратор проводит анализ нашего проекта и, если все хорошо, отдает ссылку, перейдя по которой можно найти предложения по миграции, в которых мы видим файлы исходного кода нашего проекта с автоматически внесенными изменениями, поддерживающими null safety.

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

Рассмотрим более подробно предлагаемые изменения. Где-то мигратор добавил ? к типу поля или переменной, сделав его nullable.

Появились комментарии /* no valid migration */ как в примере к строчке, где метод возвращает null, а принимающая сторона этого не ждет.

В окошке справа от кода можно найти подробности о причинах внесения тех или иных изменений, например, такие причины для приведения к nullable поля title:

• поле не является final, значит его значение может измениться после определения в конструкторе;

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

Здесь же можно воспользоваться кнопочками Add, чтобы добавить к типу String /*!*/, сообщив мигратору, что мы уверены, что это поле должно быть non-nullable, перезапустить миграцию и понаблюдать, как меняется код, использующий это поле. Вот, например, при передаче meter.customName в конструктор ButtonItem появился !.

Пробежавшись по коду, можно заметить, что везде, где есть использование nullable, но требуется non-nullable переменная, мигратор добавил оператор !. Он уговаривает метод или выражение, которое ждет только non-nullable, взять из наших рук nullable. Оператор ! относится к null-aware операторам, таким как ?., ??, !. (подробно про их использование можно почитать здесь).

ComboMeal(Drink? drink) {  drink!.addIce(); //приложение упадет}ComboMeal(null);

Мигратор часто использует оператор ! в коде, но, так как это может быть небезопасно, нужно обязательно проверить каждое появление ! и проанализировать, можно ли как-то это избежать.

Вместо ! подойдет простая проверка на null, но не всегда. Можно встретить, например, вот такую ситуацию с полем meters:

Проверка есть, но мигратор все равно добавляет !.

Оказывается, проверка на null перед использованием перетаскивает на светлую non nullable сторону только локальные переменные и не работает с полями класса. На простых примерах это выглядит так:

ComboMeal(Drink drink) {  if (drink.bestTemperature != null) {    keepTemperature(drink.bestTemperature); // ошибка компиляции  }}ComboMeal(Drink drink) {  int? bestTemperature = drink.bestTemperature;  if (bestTemperature!= null) {    keepTemperature(bestTemperature); // null safety  }}

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

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

ComboMeal(Drink? drink) {  drink?.addIce(); // addIce не вызывается}...ComboMeal(null);

Еще обойти опасный ! там, где это возможно, хорошо помогает оператор ??, позволяющий заменить возможный null на значение по умолчанию.

ComboMeal(Drink? drink) {  keepTemperature(drink.bestTemperature ?? 70);}

Перед некоторыми полями классов мигратор добавил слово late.

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

class ComboMeal {  String burgerName; // ошибка компиляции    void comboWithCheeseburger() {    burgerName = 'Сheeseburger';  }    void comboWithChickenBurger() {    burgerName = 'Chicken burger';  }    getComboMealName() {    return 'ComboMeal with ' + burgerName;}}

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

class ComboMeal {  String? burgerName;    void comboWithCheeseburger() {    burgerName = 'Сheeseburger';  }    void comboWithChickenBurger() {    burgerName = 'Chicken burger';  }    getComboMealName() {    return 'Combo meal with ' + burgerName!;}}

Ключевое слово late позволяет избежать необходимости делать это поле nullable.

class ComboMeal {  late String burgerName; //null safety    void comboWithCheeseburger() {    burgerName = 'Сheeseburger';  }    void comboWithChickenBurger() {    burgerName = 'Chicken burger';  }    getComboMealName() {    return 'Combo Meal with ' + burgerName;  }}ComboMeal comboMeal = ComboMeal();comboMeal.comboWithCheeseburger();print(comboMeal.getComboMealName());

Здесь стоит обратить внимание на то, что такая инициализация все равно не является абсолютно безопасной. Если поменять местами последние две строки кода из примера выше, то ошибки компиляции не будет, но произойдет ошибка LateInitializationError во время работы приложения, так как поле burgerName не было проинициализировано.

Еще одним применением ключевого слова late является ленивая инициализация полей класса.

class ComboMeal {  late String burgerName = _getSurpriseName();}

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

Автоматическая миграция

Насколько долго придется дорабатывать код после миграции? В нашем проекте около 1200 строк кода. Я потратила на внесение изменений немного времени - около одного рабочего дня. Предлагаю оставить этап несогласия с мигратором и правок за кадром и нажать кнопку Apply Migration, чтобы понять, насколько работоспособен код после автоматической миграции.

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

В первую очередь, видим ошибки там, где были комментарии /* no valid migration */. Это те места, где в методах возвращается или передается null. Правим.

Второй тип ошибок компиляции после миграции связан с удалением конструктора по умолчанию для списка в языке Dart. То есть нельзя больше объявить список таким образом:

List<String> words = List<String>();

Это решение было принято разработчиками из-за того, что конструктор по умолчанию создает список определенного размера, но не инициализирует его элементы, то есть все они имеют значение null. Такой конструктор теперь нельзя применить даже для списка, допускающего содержание nullable элементов. Для разрешения этой проблемы в зависимости от ситуации можно воспользоваться инструментами создания фиксированного или нефиксированного списка List.empty(), List.generate(), List.fill(), []. Правим места с использованием конструктора по умолчанию.

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

На этом миграцию приложения можно считать успешной, но с небольшими оговорками.

Впечатления от миграции

Автоматическая миграция не отдает 100% рабочего кода. Но, справедливости ради, стоит признать - так получается из-за того, что исходный код не обеспечивает null safety. Возможно, если провести какую-то предварительную подготовку, то таких проблем не будет. С другой стороны, правки после миграции были не сложными, заняли не так уж много времени, и вдобавок список ошибок акцентирует внимание на проблемах, которые можно было и не заметить при подготовке.

Выбор мигратора делать переменную/поле nullable или non-nullable, судя по всему, полностью зависит от их использования в коде. Это хорошо прослеживается в окошке с причинами добавления nullable к типу в предложениях по миграции. Понятно, что нельзя полностью уйти от использования null. Например, при получении данных от сервера и декодировании json-ответов в классы невозможно гарантировать, что все поля будут заполнены, как мы ожидаем. Мигратор, конечно, сам не догадается о контексте и не сделает все поля response-класса nullable. Разработчику придется уделить время на доработку, чтобы получить хороший код.

Встречались еще странные моменты с использованием ключевого слова late для полей класса, которые инициализируются в конструкторе. Часть из этих полей мигратор отмечал как late, а часть делал nullable, как, например, ниже:

Но все это опять же легко поправилось.

Документация по null-safety языка Dart и вообще вся документация Dart и Flutter отлично написана, в ней можно найти ответы на большинство возникших вопросов, связанных с работой nullable или non-nullable. Ну и конечно, когда при написании нового кода на Dart 2.12 встает вопрос - делать переменную nullable или non-nullable, лучше выбирать non-nullable и работать с этой концепцией пока не станет очевидно, что без nullable не обойтись.

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

P.S. Об Инфосфере

В завершение стоит немного рассказать о мобильном приложение, которое было героем этой статьи и переживало миграцию на Flutter 2. Оно является частью платформы Инфосфера, которая разработана центром проектирования программного обеспечения компании Миландр.

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

Тестировать рекламные механики не так просто, как может показаться. Главные действующие лица здесь сторонние SDK, которые не особо подконтрольны команде разработки. А так как рекламные интеграции важная часть наших мобильных приложений, то ниже вместе с @maiscourt и @santypa расскажем, как мы это делаем.

Далее список инструментов с описаниями, задачи тестирования и некоторые внутренние гайдлайны.

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

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

И тут нам понадобятся некоторые инструменты.

Инструменты

Ниже список инструментов, которые мы используем при тестировании рекламы, а потом перейдём к задачам.

1. Сниффер для анализа трафика (у нас Charles).

2. Админка у медиатора, где можно настроить получение рекламы от конкретного партнёра на свой тестовый юнит (специальный id, используя который, паблишер запрашивает рекламу у медиатора).

3. Своя админка с фича-тогглами, где можно включить/отключить, или изменить наши эксперименты.

4. Наша дебаг-панель.

5. VPN.

6. Внешние гайдлайны.

7. Внутренняя база знаний и Confluence для её хранения.

8. Чек-листы.

9. Zephyr для хранения тест-кейсов.

Пройдёмся по каждому.

Инструмент 1. Charles. Активно используется не только тестировщиками, но и разработчиками. Практически все задачи требуют замены продакшн параметров на тестовые. Например, часто возникает необходимость добавить в конфиг эксперимент или обращаться к тестовым юнитам медиатора.

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

Инструмент 2. Тестовая админка медиатора. Медиатор это специальная платформа, которая позволяет подключать приложение сразу к нескольким рекламным сетям, а также управлять показом рекламы (например, Google AdMob, Fyber и другие). Ещё во время онбординга мы проводим обучающие курсы по рекламе, где сотрудники в тестовой админке медиатора создают свой тестовый юнит для настройки параметров рекламы под себя.

Инструмент 3. Админка с фича-тогглами. Практически все рекламные (и не только) механики в приложении iFunny закрыты под фича-тогглы (механизм реализации, при котором часть кода прячется за флаг, контролирующий его включение или выключение). Это нужно, чтобы сделать более надёжным и безопасным выпуск той или иной функциональности.

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

Документацию обновляем и дополняем по мере необходимости: если после обновления SDK изменилась описанная логика работы, или если вышли нормативы/регламенты, требующие внесения обязательных правок.

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

Инструмент 5. VPN. В основном используется для проверки задач, связанных с GDPR и CCPA. Для тестирования GDPR подходит VPN с возможностью получения IP европейской страны. Для тестирования CCPA необходим VPN с возможностью получения калифорнийского IP.

Инструмент 6. Внешние гайдлайны. В работе с рекламными SDK часто используем их официальную документацию, где можно получить:

• рекламные креативы и их идентификаторы, которые используются для настройки и получения тестовой рекламы;

• форматы запросов и ответов рекламной SDK, а также параметры, из описания которых понимаем, за что они отвечают, и какие возможные значения для них допустимы;

• changelog изменений рекламных SDK чтобы понять, на какие изменения при обновлении SDK нужно обратить внимание во время тестирования.

Инструмент 7. Внутренняя документация. Внешние гайды не всегда являются достаточно подробными. Кроме того, проверка одной и той же функциональности от разных SDK требует переключения между разными источниками для поиска необходимой информации. Поэтому оказалось удобным агрегировать информацию из разных гайдлайнов SDK и делать сборную внутреннюю документацию в нашем Confluence, дополняя её своими комментариями.

Инструмент 8. Чек-листы. Наравне с внешней и внутренней документацией для проверок различных задач используем чек-листы (пример можно посмотреть ниже в разделе про обновление SDK). Для такого типа задач, как проверка обновлений SDK, обновлений медиатора или адаптеров, мы используем уже составленный чек-лист, который изменяется по мере необходимости.

Для остальных задач составляем чек-листы либо в процессе разработки задачи, либо непосредственно перед тестированием, в зависимости от сложности задач.

Инструмент 9. Тест-кейсы. Тест-кейсы неотъемлемая часть тестирования любого проекта/функциональности, в том числе рекламы. Тест-кейсы разделены по приоритетам, что позволяет использовать risk-based testing, о котором будет рассказано подробнее ниже. В тест-кейсах фигурируют такие проверки, как загрузка и показ рекламы, запросы на рекламу, работа разных механик (например: водопад, аукцион), а также запрос и отображение рекламы от партнёрских рекламных сетей. Данные проверки в полной мере позволяют убедиться, что рекламный функционал работает без сбоев/корректно.

Задачи

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

Разберём, с чем приходится сталкиваться на постоянной основе:

1. Обновление SDK.

2. Тестирование форматов.

3. Безопасность.

4. Регрессионное тестирование.

5. Смоук тестирование.

6. Другие задачи (юридические вопросы, локализации, эксперименты, аналитика, рефакторинг и так далее).

Задача 1. Обновление SDK. Можно сказать, что обновление SDK наиболее популярная задача в рамках тестирования рекламы. Из-за частого проведения тестирования обновлений SDK (а также медиатора или адаптеров) составили чек-лист проверок:

• Вёрстка. Проверяем всё: центрирование, размер, отображение на устройствах с разными разрешениями экранов.

• Пользовательские сценарии. Тап по контенту/кнопке и по privacy icon, возврат в приложение, воспроизведение и остановка видеорекламы.

• Репорт (отправка жалоб, связанных с рекламой). Пользователь может пожаловаться на рекламный контент или сообщить о технических проблемах.

• Соответствие стандартам GDPR и CCPA.

• Отправка аналитики. Внутренняя и внешняя (партнёру и медиатору).

• Технические проверки. Например, уход в фон во время загрузки рекламы.

Задача 2. Тестирование форматов. Баннерная и нативная рекламы у нас закрепились и работают стабильно, но мы пробуем интегрировать и другие виды, в частности, fullscreen-рекламу. В целом, тестирование Rewarded Video и Interstitial во многом схоже с тестированием других видов: проверяется корректная загрузка и отображение рекламы, а также отправка аналитики.

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

Отдельно нужно сказать про механику Rewarded Video после окончания просмотра рекламы (или просмотра до определённой временной метки) пользователь должен получить вознаграждение. Поэтому очень важно хорошо протестировать этот функционал.

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

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

Задача 4. Регрессионное тестирование. Раз в две недели iFunny релизится на iOS и Android. Независимо от количества рекламных задач, попавших в релизную ветку, мы проводим регрессионное тестирование рекламного функционала/блока. В регрессионных паках собраны следующего рода проверки:

• Основные проверки, что реклама запрашивается и отображается на нужных экранах приложения.

• Работа нативной и баннерной рекламы, а также рекламных сетей, с которыми сотрудничаем по сути, это упрощённый чек-лист, используемый для тестирования SDK (добавления, обновления).

• Работа разных механик: водопад и биддинг (что это такое, можно ознакомиться здесь).

• Проверка на соответствие юридическим нормам.

• Проверки каких-то наших внутренних разработок (например, эксперименты с дизайном).

Если встречаем проблемы в процессе тестирования (не проходят какие-то кейсы регресса), то чиним в текущей релизной ветке не катимся с рекламой, которая не работает.

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

Задача 5. Смоук тестирование. Перед тем, как выкладывать сборку в сторы, а также при тестировании хотфиксов, мы прогоняем смоук тесты. В рамках смоук тестирования реклама проверяется, но не так детально, как при регрессе. Мы тестируем основные моменты, связанные с рекламой, а именно её загрузку и отображение.

Задача 6. Другое. К тестированию других задач можно отнести:

• юридические задачи, например, связанные с GDPR и CCPA;

• задачи локализации (для пользователей iFunny из Бразилии);

• эксперименты, связанные с дизайном рекламы;

• задачи аналитики;

• рефакторинг, оптимизации. Например, оцениваем доступный нам для анализа контент на предмет валидности.

Бонус. Онбординг новых сотрудников

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

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

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

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

Вместо заключения

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

App Store самая строгая площадка для размещения приложений. Ревью проходит дольше и строже, чем у Google Play и Huawei App Gallery. В 2020 году AppStore отклонил миллион приложений, которые публиковались впервые, и миллион апдейтов.

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

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

Мы составили чек-лист очевидных и не очень очевидных причин, по которым AppStore отклоняет приложения. Сам чек-лист в гугл-доке. В статье раскроем подробнее каждый пункт.

Нарушения политики конфиденциальности и пользовательских данных

Нет ссылки на пользовательское соглашение. Ссылка должна быть и внутри приложения, и на странице в магазине. Если ссылка ведёт на сайт компании, соглашение должно быть размещено там и ссылка должна работать.

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

Нарушение функциональных требований

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

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

У нас в Surf, например, однажды отклонили приложение, потому что в нём была подключена библиотека для Apple Pay, но она нигде не использовалась.

UI, не соответствующий Human Interface Guideline. Сложное для использования приложение, имеющее нелогичное поведение и расположение элементов, отклонят.

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

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

Несанкционированный доступ к данным пользователя. В 2021 году вступило в силу изменение политики Apple в отношении рекламы. Теперь, чтобы собирать данные для рекламных кампаний, нужно запросить разрешение у пользователя на доступ к отслеживанию активности.

Изменение поведения системных функций, кнопок или жестов. Нельзя изменять поведение кнопок громкости или жестов свайпа панели управления.

Для распознавания по FaceID используются сторонние технологии. Идентификация пользователя по FaceID должна происходить только с помощью библиотеки LocalAuthentication.

Нет входа по AppleID, если есть возможность входа через соцсети. Это обязательно для iOS 13 и новее.

Нарушения в оформлении приложения

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

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

Есть слова Beta, Demo или Debug в названии приложения. Такие приложения запрещены к публикации в магазине App Store. Для бета-версий есть Test Flight.

Нет описания новой функциональности у обновлённого приложения. Если в приложении появилась новая функциональность, необходимо описать её в поле в App Store Connect. Без чёткого описания приложение ревью не пройдёт.

Скриншоты приложения, иконка и другой контент на странице магазина не подходят для аудитории 4+. И не важно, что приложение может быть не предназначено для такого возраста: аудитория App Store дети от четырёх лет.

Контент не соответствует возрастной метке. При публикации нужно пройти опрос, чтобы установить возрастную метку приложения. Если контент ей не соответствует, приложение или обновление отклонят при публикации.

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

Файл с расширением .ipa превышает размер 50 мб в момент публикации.

Нет демо-пользователя для ревью, если приложение требует обязательной авторизации.

Не указаны правила участия и выигрыша, если в приложении есть розыгрыши, рулетки или казино. Следует явно написать, что Apple не имеет никакого отношения к этим конкурсам и розыгрышам.

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

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

В период пандемии этот пункт стал особенно важен: Apple строго следит за распространением информации, связанной с COVID-19.

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

Контент оскорбляет людей разных рас, вероисповеданий, сексуальной ориентации, национальности.

Приложение поощряет незаконное использование оружия или позволяет его купить.

Есть откровенно сексуальный или порнографический контент.

Приложение разрешает анонимную отправку смс/ммс, анонимные звонки, розыгрыши.

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

У карты лояльности в wallet нет контактной информации о компании. Её нужно добавить, чтобы пользователи могли связаться с компанией, если захотят.

Покупки в приложении

Цифровой контент продаётся не через in-app purchase.К цифровому контенту относятся подписки, музыка в приложении, видео, расширенный доступ к функциям.

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

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

Приложение не предоставляет пользователю всю необходимую информацию о покупке до момента продажи. Это важно, если приложение использует Apple Pay. Также недопустима кастомизация окна оплаты.

Категория Kids

Kids в App Store отдельный вид приложений. К ним Apple относится максимально строго. Категория Kids делится на три подкатегории: до 5 лет, 68 лет, 911 лет.

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

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

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

Составили гугл-док с чек-листом требований для ревью App Store.

А по каким причинам App Store отклонял ваши приложения? Расскажите в комментариях.

Месяц назад один из моих подкастов стал лучшим по итогам премии Золотого сайта 2020 года. Он выходит на Хабре в виде текстовых расшифровок и как мне кажется этот фактор существенным образом добавляет передаче веса и позволяет видеть обратную связь.

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

API страховых компаний мы уже работаем с ними

Текстовая версия Аудиоплеер в веб-версии Apple Podcasts

Михаил Михеев, страховой эксперт и соведущий передачи, заинтересовался этой темой еще в 2017 году и рассказал о ней на одной из технологических площадок. После этого он начал готовить собственные ИТ-системы, используемые в работе с клиентами [главным образом для оформления страховок], к потенциальной интеграции с API компаний-партнеров. Стоит признать, что последние на тот момент не были в достаточной степени развиты и доступны для агентов. Поэтому интеграцию начали только в конце 2019-го, после того как Михаил принял участие в одной из профильных insurtech-конференций и познакомился с новыми партнерами.

Ситуация вокруг дизайна ИТ-систем для страхования

Текстовая версия Аудиоплеер в веб-версии Apple Podcasts

Один из первых выпусков, где мы затрагиваем тему insurtech'а. Мы записали его еще в 2017 году, когда большая часть страховых компаний не задумывалась о развитии веб-сервисов, мобильных приложений и существенном улучшении инхаус CRM-систем. К сожалению, с тех пор в сфере страхования появилось не так и много инноваций буквально два-три громких стартапа.

Отношение к ИТ на внутренней кухне крупных страховщиков практически не изменилось, поэтому этот выпуск все еще актуален с точки зрения понимания mindset'а в индустрии.

Гаджеты помогут, но не сразу

Текстовая версия Аудиоплеер в веб-версии Apple Podcasts

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

Помимо этого в блоге эксперта есть публикации на смежные темы например, о том, почему Tesla не изменит рынок страхования, посты о беспилотниках и заметки о телематике.

Без технологий не стать экспертом

Текстовая версия Аудиоплеер в веб-версии Apple Podcasts

Еще один компактный выпуск, в котором Михаил делится мнением о том, как технологии влияют на работу независимого страхового агента. Он рекомендует младшим коллегам задумываться об использовании CRM-систем с первых дней работы. При серьезном отношении к этой профессии и развитии дела переходить к проектированию собственных решений в этой области. Именно так в свое время Михаил поступил сам, что сейчас позволяет ему действовать без оглядки на продукты того или иного ИТ-вендора и быстрее интегрировать API страховых компаний.

Как отработал дилер после моего ДТП

Текстовая версия Аудиоплеер в веб-версии Apple Podcasts

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

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

P.S. Михаил за десять лет работы самостоятельно собрал портфель, состоящий из десяти с лишним тысяч клиентов только по автострахованию, и планирует далее развиваться в этой области в качестве независимого страхового эксперта. По данной теме выходит не так много контента, поэтому прошу отнестись с пониманием к нашему скромному опыту. Мы будем благодарны за предложения по темам и направлениям для совершенствования подкаста.

Месяц назад один из моих подкастов стал лучшим по итогам премии Золотого сайта 2020 года. Он выходит на Хабре в виде текстовых расшифровок и как мне кажется этот фактор существенным образом добавляет передаче веса и позволяет видеть обратную связь.

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

API страховых компаний мы уже работаем с ними

Текстовая версия Аудиоплеер в веб-версии Apple Podcasts

Михаил Михеев, страховой эксперт и соведущий передачи, заинтересовался этой темой еще в 2017 году и рассказал о ней на одной из технологических площадок. После этого он начал готовить собственные ИТ-системы, используемые в работе с клиентами [главным образом для оформления страховок], к потенциальной интеграции с API компаний-партнеров. Стоит признать, что последние на тот момент не были в достаточной степени развиты и доступны для агентов. Поэтому интеграцию начали только в конце 2019-го, после того как Михаил принял участие в одной из профильных insurtech-конференций и познакомился с новыми партнерами.

Ситуация вокруг дизайна ИТ-систем для страхования

Текстовая версия Аудиоплеер в веб-версии Apple Podcasts

Один из первых выпусков, где мы затрагиваем тему insurtech'а. Мы записали его еще в 2017 году, когда большая часть страховых компаний не задумывалась о развитии веб-сервисов, мобильных приложений и существенном улучшении инхаус CRM-систем. К сожалению, с тех пор в сфере страхования появилось не так и много инноваций буквально два-три громких стартапа.

Отношение к ИТ на внутренней кухне крупных страховщиков практически не изменилось, поэтому этот выпуск все еще актуален с точки зрения понимания mindset'а в индустрии.

Гаджеты помогут, но не сразу

Текстовая версия Аудиоплеер в веб-версии Apple Podcasts

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

Помимо этого в блоге эксперта есть публикации на смежные темы например, о том, почему Tesla не изменит рынок страхования, посты о беспилотниках и заметки о телематике.

Без технологий не стать экспертом

Текстовая версия Аудиоплеер в веб-версии Apple Podcasts

Еще один компактный выпуск, в котором Михаил делится мнением о том, как технологии влияют на работу независимого страхового агента. Он рекомендует младшим коллегам задумываться об использовании CRM-систем с первых дней работы. При серьезном отношении к этой профессии и развитии дела переходить к проектированию собственных решений в этой области. Именно так в свое время Михаил поступил сам, что сейчас позволяет ему действовать без оглядки на продукты того или иного ИТ-вендора и быстрее интегрировать API страховых компаний.

Как отработал дилер после моего ДТП

Текстовая версия Аудиоплеер в веб-версии Apple Podcasts

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

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

P.S. Михаил за десять лет работы самостоятельно собрал портфель, состоящий из десяти с лишним тысяч клиентов только по автострахованию, и планирует далее развиваться в этой области в качестве независимого страхового эксперта. По данной теме выходит не так много контента, поэтому прошу отнестись с пониманием к нашему скромному опыту. Мы будем благодарны за предложения по темам и направлениям для совершенствования подкаста.