Mobile & iframe
iframe iframe
iframe в мобильных приложениях — не то же
самое, что iframe в вэб приложениях
Это как отправлять городской седан по бездорожью.
По трассе Москва - Владивосток.
Зимой.
— А ЧТО НЕ ТАК ТО?
— КОЛЕСА, ДВИГАТЕЛЬ ЕСТЬ!
— ИЗ ТОЧКИ А В ПУНКТ Б ДОЕЗЖАЕТ!
— ЧТО СЛУЧИТСЯ ТО?
Условия эксплуатации iframe в web и мобильных приложениях отличаются. Этот связано с иным опытом использования, принципами работы мобильных ос и техническими особенностями устройств.

Web и есть web, но проблемы кроются в деталях. Работать с ними можно только углубившись в вопросы пользовательского опыта и проработки сценариев.
Камень преткновения
На чем фокусируемся
Технические особенности
Мобильные устройства имеют технические ограничения по железу и дополнительные устройства в виде gsm / gprs модулей. И то и то влияет на поведение системы и приложений.
Разные "принципы" работы ОС и пользовательского поведения
Web заточен под управление мышкой, мобильные интерфейсы под управление пальцем. Разные принципы управления задают разную логику построения интерфейсов, обработки информации и принципы взаимодействия с серверной составляющей.
Обе проблемы связаны и связывают решение
Обе проблемы ведут к изменению как на бэкенде, так и на фронте
iframe накладывает дополнительные ограничения на проектирование и не только интерфейса.
Структура взаимодействий
iframe накладывает дополнительные ограничения на проектирование приложения
App front-end
Web или native-based приложение

App back-end
Набор Api для синхронизации приложений и банковскими системами
iframe
Самостоятельный web-based front-end

iframe back-end
Набор Api для синхронизации web-app с банковскими системами
И все же это возможно если взять платформу автомобиля и превратить седан во внедорожник.
Вопрос в том кто станет отвечать и за какую часть работоспособности и тестирования?
Различные паттерны поведения интерфейса


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


Нужен элемент или ивент (например переход между экранами) обновления iframe'а - т.к. сам iframe может зависнуть или не подгрузится

Может ли iframe открываться в fullscreen - событие во фрейме вызывать интерфейс который раскроется на весь экран? Или он сам раскроется или вызовет новый в самом приложении - это вопрос проектирования бэкенда

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

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

Навигация

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

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

Есть два критических фактора. Они вызваны разными причинами но всегда одинаковы с точки зрения общего поведения
Потеря соединения
---
Ограничения памяти
---
Потеря соединения
Слабое соединение, смена сети, подключение к открытым wi-fi с закрытой авторизацией, пролет метро или тоннель, лифт...
Компонентов в приложениях мобильнх ос к этому подготовлены, а iframe нет
Для таких случае должен быть проработан сценарий обновления контейнера - не закрывать ведь приложение каждый раз. Это должен быть элемент интерфейса самого приложения: кнопка или слайд. Или сценарий - переключение между вкладками.

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

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

Если интерфейсы iframe участвуют в таких сценариях это критично и требует дополнительной проработки.
Сценарий 1
iframe не имеет доступа к sms и push "службам" ос. Он не сможет в автоматически подтянуть присланный код.
Если для подтверждения требуется ввести код присланный по смс то возможен критический сценарий связанный с нехваткой памяти. Это сценарий в котором есть переходы между самим приложением, приложением СМС и обратно в приложение. При недостатке памяти исходное приложение может перезагрузиться выйдя из фонового режима. Тогда iframe должен показать интерфейс ввода. Это возможно если такие события и очередь перехода регламентирует сервер.

Код запрашивается в интерфейсе iframe

Сервер присылает смс на телефон, но iframe его не распознает

Пользователь переключается в приложение СМС для просмотра кода

Переключение перезапускает приложение и iframe в нем, те без сохранения последовательности
Сценарий 2
Сценарий 2 можно использовать как обход "сценария 1" если позволяет служба безопасности. Это приведет к измменению бизнес процессов
Если для подтверждения операции требуется код присланный push уведомлением, то нужна дополнительная функция которая параллельно push передаст ключь непосредственно в iframe.
Чем все чревато и что делать?
Тесная коллаборация всех команд на этапах проектирования и тестирования.

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

Увеличиваются затраты на операции и администрирование за счет усложнения процесса доставки тестовых версий к участникам
Made on
Tilda