PWA внутри APK: почему он изолирован от Android API?
Когда вы помещаете прогрессивное веб-приложение в APK, чтобы продавать его в Goolge Play, например, с помощью Bubblewrap и Trusted Web Activity, PWA не может взаимодействовать с API Android. Верный? Если я неправильно понял это, поправьте меня и укажите на документацию.
Таким образом, даже если это APK и он поступает из надежного источника, такого как Google Play, код, который он запускает (Javascript), не сможет выполнять те же действия, что и обычное приложение для Android. Что за этим стоит? Миссия Google - сделать PWA такими же функциональными, как и нативные приложения, поэтому для меня это не имеет смысла.
Например, мне нужен доступ к файловой системе из моего PWA. Я имею в виду реальный доступ, а не кастрированный доступ, как в готовящемся к выпуску Native File System API. Пользователь принимает доступ к файлу при установке, и тогда мое приложение может делать все, что захочет. Поэтому я решил использовать API Android для доступа, но они недоступны. Как вы решили эту проблему в своих собственных PWA?
1 ответ
Когда вы помещаете прогрессивное веб-приложение в APK, чтобы продавать его в Goolge Play, например, с помощью Bubblewrap и Trusted Web Activity, PWA не может взаимодействовать с API Android. Верный? Если я неправильно понял это, исправьте меня и укажите на документацию.
Да, верно, событие, хотя это то, что часто пересматривается.
Таким образом, даже если это APK и он поступает из надежного источника, такого как Google Play, код, который он запускает (Javascript), не сможет выполнять те же действия, что и обычное приложение для Android. Что за этим стоит? Миссия Google - сделать PWA такими же функциональными, как и нативные приложения, поэтому для меня это не имеет смысла.
Цель состоит в том, чтобы включить открытие PWA, созданного для Интернета и использующего стандартизированные API веб-платформы, как части собственного приложения (это может быть одно действие в приложении или приложение может иметь другие действия).
В целом, вы можете рассматривать веб-API как слой абстракции над собственными ОС / API, который позволяет приложению работать во многих различных операционных системах без каких-либо изменений - разработчикам не нужно разветвлять свои PWA на разные ОС.
Предоставление доступа к собственным API-интерфейсам означало бы, что разработчики будут иметь в виду две вещи: 1 - разработчики должны будут создать свой собственный уровень абстракции, чтобы преодолеть разрыв между ОС. 2 - Части приложения перестанут работать на обычной вкладке браузера (например, если они не открыты в доверенной веб-активности или ее эквиваленте в других ОС).
Поэтому, хотя мы знаем, что отсутствуют API-интерфейсы для включения всех возможных вариантов использования, предпочтение отдается включению этих API-интерфейсов в качестве веб-API через Project Fugu, вместо предоставления прямого доступа к собственным API-интерфейсам.
Я задал премьер-министру именно этот вопрос недавно на мероприятии web.dev/live. Вот соответствующий раздел видео.
Например, мне нужен доступ к файловой системе из моего PWA. Я имею в виду реальный доступ, а не кастрированный доступ, как в случае с готовящимся к выпуску Native File System API. Пользователь принимает доступ к файлу при установке, и тогда мое приложение может делать все, что захочет. Поэтому я решил использовать API Android для доступа, но они недоступны. Как вы решили эту проблему в своих собственных PWA?
Я не очень хорошо знаком с API собственной файловой системы. На Дискурсе WICG есть ветка, где, возможно, стоит поделиться отзывами.
Наконец, Trusted Web Activity не должны заменять Android WebView и служить несколько иному сценарию использования. Когда веб-контент тесно связан с приложением Android (например: предполагается, что он работает только внутри приложения и не загружается в обычном браузере или в других ОС), разработка для WebView позволит подключаться ко всем собственным API-интерфейсам (в за счет поддержки многих веб-API, таких как push-уведомления и другие).