Что такое webview ios
Понимание вьюпорта WebView в iOS 11
iOS 11 представила новое, — пожалуй, неинтуитивное — поведение, связанное со статус-баром. Оно имеет особое значение для тех, кто разрабатывает приложения при помощи инструментов вроде Apache Cordova и Ionic. В частности, изменение затрагивает веб-приложения под iOS11, использующие фиксированное позиционирование верхней панели навигации. Эта статья поможет понять вьюпорт WebView в iOS 11.
Примечание: уже существующие приложения продолжат работать так, как всегда работали — без изменений в поведении их вьюпорта. Нововведение затрагивает только приложения, скомпилированные при помощи Xcode 9 и предназначенные для iOS 11.
Чтобы понять это изменение, посмотрим на его контекст.
Статус-бары и безопасные зоны
В ранних версиях iOS статус-бар был просто черной полосой через верхнюю часть экрана и обычно не реагировал на касания. Он был частью системного интерфейса, и приложение запускалось в пространстве под ним.
Это изменилось с выходом iOS 7, у которой был прозрачный статус-бар. Он принимал цвет верхней панели навигации приложения. Для приложений, отображающихся в WebView, наподобие Cordova, это часто означало определение версии iOS и добавление 20px верхнего отступа к фиксированной верхней панели навигации. Таким образом, она вставала правильно.
Последующие версии iOS представили небольшие доработки. В их числе была такая особенность: во время звонка в статус-баре мог отображаться дополнительный баннер, а также когда приложение фоново использовало геолокацию.
В нативных приложениях это во многом автоматически управлялось стандартными средствами: UINavigation Bar (управление панелью навигации) и autolayout (авто-выравнивание). Были инструменты выравнивания верхней и нижней части экрана, которые автоматически подстраивали их под высоту статус-бара (-баров). Они проверяли, что контент приложения находится в безопасной зоне, и статус-бар его не перекроет. Если имелась панель навигации UINavigation Bar, выровненная по верхнему краю, то iOS автоматически добавляла ее цвет в качестве фона статус-бара. Для веба, к сожалению, не было такого эквивалента.
Изменения в iOS 11
Поведение вьюпорта по умолчанию в iOS 11 на iPhone 8
Вы можете убедиться, насколько это плохо, в этом видео:
Очень странное поведение скролла в iOS 11 для элементов с фиксированным позиционированием
Почему вообще Apple внесли такое изменение?
Если вы видели дизайн iPhone X, то цель изменения понятна. У iPhone X нестандартная форма экрана с выемкой наверху для динамика и камеры. Если фиксированные элементы выровнять по реальному верхнему краю экрана, то они станут недоступными позади этой выемки.
Выравнивание по нижнему краю статус-бара гарантирует, что всё, что находится в панели навигации, будет доступным.
Круто… Не считая того, что теперь приложения выглядят ужасно со странной верхней панелью навигации, двигающейся вверх и вниз, и контентом, который проглядывает через статус-бар во время прокрутки.
Фиксы iOS 11
Всё в порядке в iOS 11 на iPhone 8, когда свойство viewport-fit имеет значение cover
iPhone X
Примечание: приложение использует все пространство экрана на iPhone X только в том случае, если у вас есть сториборд для экрана загрузки. Уже существующие приложения будут показаны в контейнере просмотра с черным пространством сверху и снизу.
На iPhone X уже появляется проблема, даже при том же значении cover у свойства viewport-fit
Четыре константы для управления раскладкой безопасных зон — это:
И, в качестве последнего подарка для нас, Apple портировало эти переменные для UIWebView.
Пример с CSS-константами
Скажем, есть фиксированная верхняя панель навигации, и CSS для iOS 10 сейчас выглядит так:
Чтобы она автоматически подстраивалась под iPhone X и другие устройства на iOS 11, надо добавить свойство viewport-fit=cover в мета-тег viewport и изменить CSS с обращением к константе:
Проблема на iPhone X решена через добавление отступа в зависимости от устройства
Также не стоит забывать делать то же самое для нижней панели навигации.
P.S. Это тоже может быть интересно:
Если вам понравилась статья, поделитесь ей!
Android и iOS WebView-приложения для арбитража трафика: что это такое?
Проработав с WebView более года, я решил поделиться накопленной инфой и подробно описать, что же такое Android / iOS WebView-приложения для арбитража трафика, зачем они нужны и с чем их едят. Отмечу, что я рассматриваю все вопросы в документе исходя из своего скромного опыта исключительно со стороны разработки подобных приложений и не претендую на истину. Документ рассчитан в основном на новичков, но есть нюанс.
Содержание статьи:
Что такое WebView-приложения?
WebView — это системный компонент, который отвечает за открытие веб-страниц в рамках приложений. Иными словами, это то, что вы видите, когда открываете стороннюю ссылку в Telegram или VK.
В рамках арбитража трафика подобные приложения размещаются в Google Play, App Store, либо на сторонних сайтах-одностраничниках, куда затем ведется трафик. Поскольку модераторы подобных площадок не дремлют, в приложения вшивается клоака, которая отсеивает нецелевой трафик и модераторов, показывая им заглушку. Как правило, это какая-то простая игра (match-3, раннер или даже крестики-нолики) либо читалка. Целевым же пользователям показывается WebView с вашим оффером.
Выглядеть страница с приложением в Google Play может примерно так:
Зачем нужны WebView-приложения?
WebView-приложения неспроста стали настолько популярны в последние пару лет. Слив трафика через приложения имеет неоспоримые плюсы.
Первый из них — разнообразие источников трафика. Размещение приложения в сторе позволяет лить на него трафик не только с Facebook, но и с in-app рекламы, а также с UAC.
Второй — возможность «дожимать» пользователя, который попал к нам на оффер. Как правило, в подобные приложения вшиваются сервисы вроде Onesignal, с помощью которых можно отправлять пуш-уведомления прямиком на телефон пользователя, мотивируя его регистрироваться и заносить депозиты.
Третий — траст со стороны пользователей. Приложение на официальной площадке с десятками отзывов и тысячами установок вызывает гораздо больше доверия, чем обычный одностраничник.
Четвертый — подробная статистика. Webview-приложения позволяют использовать SDK для трекинга и аналитики на всю катушку. Appsflyer, Appmetrica, Firebase — you name it.
Такие понятия, как deeplink (диплинк, или отложенная глубокая ссылка), а также нейминг, позволяют вам проводить подробный анализ каждого клика вашего трафика, чтобы определять, с какого крео и благодаря какому баеру вам прилетел деп. Позже мы остановимся на этом подробнее.
Вертикали, в которых используются WebView-приложения
Webview-приложения могут использоваться практически для всех вертикалей. Самая популярная вертикаль на данный момент — гемблинг, однако также подобные прилы используются для дейтинга, крипты, финансов и даже нутры. Особую популярность в последнее время набирает беттинг, вангую, что прилы под беттинг станут трендом 2021 года
Минусы WebView-приложений
Как и у всего в нашем нелегком деле, у работы с WebView-приложениями есть свои нюансы и сложности. Первый и самый важный — баны. Нет, БАНЫ!
Когда я только начинал разрабатывать подобные приложения, они сводили меня с ума. Бан аккаунта разработчика, бан приложения на модерации, бан приложения спустя час после выхода с недельной модерации… Описывать эту дурку можно бесконечно. Но даже если вы разберетесь с причинами банов и настроите качественную клоаку, приложения будут вылетать спустя пару недель активного отлива. Кроме того, периодически, когда Гуглу снова ударит моча в голову, модерация может затягиваться на неделю или даже более, заставляя сердечко разработчика трепетать и снова и снова чекать аккаунт на предмет саспенда или реджекта приложения.
Со временем мы в Apps4You выработали определенный воркфлоу, который позволяет проходить модерацию относительно быстро (2-3 дня) и безболезненно, а приложения в среднем живут от двух недель до месяца. Однако есть рекордсмены в обе стороны. Помимо банов собственно приложений и аккаунтов разработчика, вы можете словить так называемую метку на приложение в Facebook или UAC и не сможете на него лить из этого источника. Вообще. Совсем. Хорошо, что источников может быть несколько! А чтобы жизнь не казалась вам медом, добавлю — баны приложений — это головная боль разработчика, но не забываем про баны аккаунтов в источниках!
Вторая проблема (если вы разработчик) — поиск аккаунта, куда можно вылить свое приложение. Один аккаунт использовать не получится, потому что рано или поздно на него прилетит бан. Для нормальной работы нам нужен постоянный поток аккаунтов. Google ревностно следит, чтобы у одного разработчика не было несколько аккаунтов, и выписывает баны по причине мультиакка налево и направо. Что же делать? Варианта три — использовать VDS, прокси и регистрировать аккаунты самостоятельно, покупать готовые аккаунты у селлеров, либо найти людей, которые за определенную плату будут выливать ваши приложения к себе на аккаунт, пока его не забанят. В свое время я потратил не один месяц, чтобы найти приемлемый алгоритм работы.
Третья проблема (если вы арбитражник) — поиск нормального исполнителя. В настоящий момент рынок перенасыщен приложениями, но качественный сервис оказывают единицы. Как правило, это крупные сервисы. Более того, большая часть приложений заточены под гемблинг, в то время как найти приложение под крипту или беттинг бывает непросто. В поисках подобных приложений можно наткнуться на недобросовестных исполнителей. Многие ребята предпочитают взять предоплату и уйти в закат. Пользуйтесь проверенными сервисами, например, Apps4You, и не забывайте про гаранта, друзья!
Хочу писать приложения!
Для написания WebView-прилок могут использоваться самые разные движки, языки и среды разработки.
Вот самые популярные из них:
В целом, писать можно на чем угодно, хоть на Прологе (нет), поскольку плагины и библиотеки для WebView есть почти везде.
Сам я пишу на Unity (C#), но это лишь потому что моя основная деятельность связана с разработкой игр, и Unity я уверенно владел еще до того, как окунулся в арбитраж. На Unity легко и удобно писать игры-заглушки, поскольку движок изначально заточен под разработку игр, в том числе и на мобильные платформы. Кроме того, Unity кроссплатформенный, что позволяет нам легко и непринужденно разрабатывать приложения как на Android, так и на iOS.
Новичкам, которые никогда не сталкивались с программированием и разработкой в принципе, я могу посоветовать не лезь, она тебя сожрет Android Studio.
Атрибуция и другие умные слова
Раз уж мы переходим к технической части, стоит остановиться на том, как работает диплинк и нейминг.
Клоакинг
Как я уже писал выше, чтобы модераторы не вынесли ваше приложение еще на этапе модерации, важно не показывать им свои истинные намерения и косить под обычную игру/читалку. Приведу лишь пару способов, потому что вариаций масса.
Заглушка
Но что же должно показываться модератору, чтобы он не настучал нам по попке? Если заглушка будет недостаточно качественной, это тоже может послужить причиной бана. Графон может быть супер убогим и стоковым, главное, чтобы в приложении был хотя бы примитивный рабочий геймплей, а описание приложения хотя бы косвенно совпадало с его содержимым. Так, для приложений под подписку на фоторедактор мы разработали простенький фоторедактор, а для гембловых приложений достаточно каких-нибудь игр. Заглушки не должны быть слишком простыми или похожими друг на друга и прочие игры в маркете, иначе можно получить по жопе.
Прикрепляю пару скриншотов рабочих заглушек, надеюсь, вы не дропнете документ после увиденного!
Полезная информация от автора
Статья написана представителем сервиса аренды-продажи webview-приложений Apps4You.
Промокод дающий скидку в 50$ на выкуп прилки «traffink»
Поделиться ссылкой:
Добавить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
О WebView мобильных приложениях
Операционная система «Andriod» имеет встроенный компонент «WebView», позволяющий встраивать веб-страницы в мобильные приложения. На основе данной технологии осуществляется быстрая сборка гибридных Android-приложений, использующих в качестве источника контента мобильную версию сайта. Для полноценной реализации достаточно написать легкое нативное приложение с меню и подключить к нему сайт через компонент «WebView».
Для чего это нужно?! Различные предприятия и компании, выпуская какие-либо продукты или сервисы на рынок, выполняют реализацию сайта и мобильного приложения. Разработка нативного Android-приложения занимает много времени и связана с высокими издержками. Чтобы ускорить и удешевить процесс, имеет смысл реализовать «гибрид», который будет задействовать в работе страницы веб-сайта. Несмотря на ограниченный функционал и зависимость от интернета, подобного приложения бывает вполне достаточно для предварительного тестирования и оценки со стороны интернет-пользователей.
Какие преимущества и недостатки у «WebView» Android-приложений? Плюсами служит быстрая и дешевая реализация по сравнению с нативными продуктами. К минусам можно отнести зависимость от интернета, более долгая скорость загрузки контента, ограниченный функционал.
Отдельно можно выделить проблемы с безопасностью с точки зрения пользователя. Мобильные приложения на основе компонента «WebView» имеют доступ к конфиденциальной информации и персональным данным. Всегда возникает риск их недобросовестного использования и/или утечки.
Ранее, приложения на основе «WebView» можно было разрабатывать и для пользователей платформы «iOS», но компания «Apple» запретила их распространение в официальном магазине «AppStore». Таким образом, реализовать подобным образом iOS-приложение можно, но на следующей стадии возникнет проблема с его распространением.
Две стороны WebView: о быстром запуске проектов и краже персональных данных
Меня зовут Евгений, я Full Stack JS разработчик, текущий стек Node.js + React + React Native. В разработке я более 10 лет. В мобильной разработке пробовал разные инструменты от Cordova до React Native. Получив опыт работы с Cardova, я понял, что мне хотелось бы создавать нативные интерфейсы, на мой взгляд WebView не должно быть всем приложением. Но это не значит, что его не надо использовать вовсе.
По приглашению коллег из Сбербанка, в этом посте хочу рассказать про гибридные мобильные приложения. При правильном подходе, это отличный способ быстро реализовать идею в виде хорошо работающего продукта, достаточного для первого запуска вашего стартапа.
Источник: srishta.com
Также немного расскажу о том, как вы можете использовать WebView и как его могут использовать против вас злоумышленники. Примеры в статье будут показаны с использованием фреймворка React Native, но те же идеи можно реализовать и без него.
Немного про стартапы
Начну с принципиальных отличий в запуске стартапов у нас и на Западе, расскажу, как здесь может помочь WebView, дам рабочие примеры взаимодействия веб и нативных элементов, а также советы по технике безопасности при взаимодействии со сторонними приложениями.
Как правило, чтобы стартап стал успешным, ему нужно быстро запуститься. Потеряешь время – и конкуренты тебя обойдут. Это понимают и у нас, и на Западе. Но российский подход к запуску, как правило, гораздо основательнее — в плохом смысле этого слова.
Все неудачные российские стартапы начинаются и развиваются примерно по одному сценарию. Наиболее частые ошибки связаны со стратегическим планированием развития программного продукта. Руководство думает, что запуск возможен только после 110%-ной реализации всей функциональности и всех нюансов. При таком подходе быстро возникает дефицит бюджета, поскольку расходы на разработку высокие, а доходов от стартапа еще нет. Поиск дополнительных инвестиций, бесконечный круг утверждений и переработок занимает кучу времени, продукт появляется у конкурента. Все, марафон проигран.
Европейские и американские стартапы действуют иначе. Для начала они ограничиваются только мобильной веб-версией с минимально достаточной функциональной частью. Ее можно смотреть и с десктопов, и с мобильных устройств. И на этом этапе проект готов к запуску! После запуска для мобильных устройств делается приложение.
Как правило, по основным возможностям приложение не отличается от веб-версии. Оно расширяет возможности взаимодействия с пользователем, например посредствам пуш-уведомлений. Такой подход обеспечивает выполнение основного условия — быстрый запуск, быстрое получение первой прибыли. Доходы с первого этапа можно инвестировать в развитие. В дальнейшем проект может масштабироваться и развиваться как угодно без дефицита бюджета, бесконечно выполняя итерационный подход для добавления нового функционала и развития пользовательского интерфейса.
Предлагаю подробнее рассмотреть тот этап, когда уже есть мобильная версия сайта и нужно разрабатывать приложение для мобильных устройств. Итак, мы сделали сайт, а значит занимались разработкой серверного API, интерфейса и бизнес-логики. Два из трех компонентов –
— интерфейс и логика — присутствуют и в мобильном приложении. Согласитесь, не хочется писать их заново.
Объединяем лучшее от нативных и веб-приложений
Есть инструменты, ориентированные на разработку нативных приложений. Другие предназначены для веба. Преимущество нативных приложений в том, что они могут использовать весь функциональный потенциал телефона. Но разрабатывать их по сравнению с веб-приложениями довольно сложно. Веб дает возможность простого старта, но сильно ограничивает возможности приложения.
* для уменьшения тавтологии веб-приложениями я назову мобильные приложения, основная часть логики и интерфейса которых реализована на стороне браузера
Объединить все достоинства нативных приложений и веба позволяют гибридные приложения, которые создают с помощью компонента WebView. Конечно, найдутся дотошные разработчики, которые категорически против WebView в любых его проявлениях. Они аргументируют это тем, что приложение должно сразу быть полностью нативным, чтобы можно было использовать все возможности мобильного устройства, а также обеспечить комфортную производительность пользовательского интерфейса. Но во многих случаях, когда возможностей мобильной версии сайта вполне достаточно, можно сократить время первого запуска, сделав гибридное приложение, и заменять его на нативное постепенно.
Гибридные приложения — это не всегда что-то плохое и не расширяемое. Они могут быть удобными и производительными. При грамотном использовании такой подход помогает получить достаточное время на разработку качественного приложения, а не выпускать нативное приложение на скорую руку.
Есть несколько ситуаций, в которых целесообразно использовать гибридные приложения. Они хороши в качестве временной заглушки для быстрого старта — когда у нас готова мобильная версия сайта, а мобильное приложение нужно было «вчера». Такое приложение можно создать за несколько часов, запустить в продакшн. Пользователи получат возможность работать с мобильным приложением, а вы — возможность работать над более полноценной версией в менее жестких временных рамках (если это нужно).
Вот пример. Недавно коллегам срочно понадобилось мобильное приложение. В веб-версии у него было восемь пунктов меню, и мы их отобразили через WebView. А потом по одному пункту заменяли. Так получилось выпустить приложение не через месяц-три, а буквально за несколько дней. После постепенно переводили его на натив.
Гибридное решение не всегда временное. Его возможности позволяют переиспользовать в приложении кодовую базу, созданную ранее для веб-версии. К примеру специфичные анимации уже созданные на Canvas. Также WebView удобен, когда используется какой-то сторонний сервис. Еще один вариант – когда у вас есть сложный интерфейс, который проще подключить через WebView.
Как использовать WebView
Возьмем популярный сценарий. Мы хотим использовать мобильную версию сайта и нативное меню. Мы создаем нативное приложение с меню, но вместо контента подключаем мобильную версию сайта через WebView (пока что без каких либо изменений).
На гифке можно увидеть 2 меню. Правое меню является частью сайта, реализованное на веб, слева нативное меню, реализованное внутри мобильного приложения. Чтобы получить первое приближение к нативному приложению, нам достаточно просто скрыть то меню, которое реализовано на веб. Вот сколько кода нужно, чтобы через WebView отобразить веб-версию внутри приложения:
Следующий пример – о том, как нативная часть может взаимодействовать с вебом.
Робот нарисован на Canvas, это часть веб-сайта. А переключатель к нему построен на нативном UI. На разных телефонах он будет выглядеть по-разному. Мы можем управлять движениями робота при помощи переключателя. Можно и наоборот – какими-то элементами веб-интерфейса влиять на приложение. В React Native для этого предусмотрено специальный API для взаимодействия между вебом и нативной частью.
Ниже код для использования этой анимации. Layout — все пространство. Picker — нативная часть, которая может выбирать из dropdown варианты состояния робота. WebView — контейнер для отображения веба, внутри которого отрисовывается робот.
Подобные кейсы возникают часто. Например, мы сделали приложение для тестирования и аттестации стоматологов. Для каждого варианта ответа в тесте внутри вопросов рисовалась анимация, реализованная посредствам Canvas на вебе. Задача состояла в том, чтобы создать мобильное приложение, с этим тестированием. Использовав WebView, мы смогли отображать анимации из веба, тогда как остальной интерфейс мы построили нативно. Анимация отлично работала даже на старых смартфонах.
Как делаются инъекции
До 2013 года браузер Opera использовал собственный движок Presto, но потом его перевели на движок Blink от Google. Многих пользователей это очень расстроило. Свет на причины этого перехода проливает видео «Зачем опере вебкит». Главные виновники — большие корпорации типа Google или Facebook, которые не тестировали код своих продуктов в Opera и запрещали отображение страниц в этом браузере, ссылаясь на то, что он не достаточно популярен у пользователей.
Например, заходишь на Gmail через Opera и видишь: «Ошибка JavaScript». Пишешь в саппорт, получаешь ответ: «Opera у нас не поддерживается, мы не будем писать под нее код». Сначала компания Opera нанимала разработчиков, чтобы писать инъекции – специальный код, который встраивался в Gmail и позволял ему работать в Opera. Но постепенно таких сайтов, как Gmail, становилось все больше. Opera сдалась и сменила движок.
Так о чем это я? Ах да самое время поговорить об инъекциях:
На гифке – пример инъекции, которая изменяет поведение сайтов. Допустим, у нас есть чужой сайт, и мы делаем инъекцию стилей – скрываем правое меню и слайдер, выезжающий справа. Это – инъекция стилей. Логика работы сайта не меняется, только отображение.
Код, написанный зеленым, — инъекция. Она скрывает элементы, на них нельзя нажать, с ними нельзя взаимодействовать. С виду получается полностью нативное приложение, без веб-элементов управления.
Следующая инъекция интереснее. Допустим, у нас есть мобильное приложение, а в нем — встроенный мобильный браузер.
Человек переходит по ссылке, и мы запросто подставляем ему страничку Фейсбука, в которой нужно ввести логин и пароль. Если человек его вводит – приложение его перехватывает. Вот код:
Такой код называется инъекцией логики. Обычно он сложнее, но не намного. То есть утащить пароль проще, чем скрыть элементы управления.
Минутка паранойи: браузеры, встроенные в приложения
Как известно, во многих приложениях есть встроенные браузеры (WebView) — например, ВКонтакте, Telegram, Gmail, WhatsApp и так далее. Крупным компаниям мы можем доверять, но WebView используется и огромным количеством приложений с малым количеством звезд и сомнительными авторами — к примеру QR-ридерами, файловыми менеджерами, оболочками для камер и т.п… Устанавливаешь приложение, читаешь через него код, нажимаешь на ссылку, вводишь конфиденциальные данные — и у приложения, как показано в предыдущем примере, появляется доступ к ним. А потом уже не отследишь, куда эти данные утекают. Поэтому для открытия ссылок пользуйтесь только браузерами, которым доверяете.
Есть сайты, которые запрашивают логин и пароль каждый раз. А есть такие, которые делают это редко — раз в месяц, раз в год. Как ни странно, второй вариант безопаснее с точки зрения утечки данных через WebView. Например, ты заходишь на сайт с какого-то левого браузера. Сайт требует логин и пароль, и тебе не кажется это странным – он всегда так делает. А в случае, когда авторизация требуется редко, это заставит насторожиться.
Интересно, что двухфакторная авторизация от такой атаки не защищает – только от кражи пароля. Дело в том, что после подтверждения тебе в ответ возвращается токен, который, в свою очередь, двухфакторной авторизации уже не имеет, и его легко перехватить. То есть если ты ввел логин и код с СМС один раз, то браузер получает токен, который можно использовать многократно. С этим подтвержденным токеном он может делать что хочет, в течение времени, пока токен остается актуальным. В общем, не стоит слишком доверять встроенным браузерам.
Познакомиться с примерами из этого поста можно через демо-приложения. На ОС Android нужно скачать Expo Project — инструмент для работы с JavaScript и React Native. После установки Expo останется только считать QR-код:
С устройствами под iOS сложнее: компания Apple запретила распространять приложения таким образом. Так что любопытствующим придется собрать приложение из исходников на GitHub. Спасибо за внимание!