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

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

Хороший DX — хорошее приложение

Большую часть времени я разрабатываю свое приложение на Chrome в «мобильном режиме». но в определенный момент вам нужно протестировать свое приложение на симуляторе или на реальном телефоне. создание приложения заново каждый раз, когда вы хотите что-то изменить, может легко привести к усталости разработчиков. Поскольку это необходимо для эффективной разработки, вы можете подключиться к серверу разработки Vite\CRA, объявив его Файл конденсатора.config.ts как таковой:

“server”: {
 “url”: “http://<your-ip>:<server-port>",
 “cleartext”: true
},

не забудьте отключить его, когда захотите перейти к работе.

Проверьте свое приложение Webview

Это очень важно, так как Capacitor дает отличную обратную связь для всех нативных вызовов в консоли JS. В Android это просто chrome://inspect из браузера Chrome и щелчок по устройству. На сафари немного возится с настройками, детали можно найти здесь

Некоторые версии Android очень темные (режим).

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

Способ решить эту проблему — изменить файл «styles.xml» в «src/main/res»:

    <style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
        <item name="colorPrimary">@color/colorPrimary</item>
        <item name="colorPrimaryDark">@color/colorPrimary</item>
        <item name="colorAccent">@color/colorAccent</item>
        <item name="android:forceDarkAllowed">false</item>
    </style>
   <style name="AppTheme.NoActionBar" parent="Theme.AppCompat.DayNight.NoActionBar">
        <item name="windowActionBar">false</item>
        <item name="windowNoTitle">true</item>
        <item name="android:background">@null</item>
        <item name="android:forceDarkAllowed">false</item>
    </style>

Вот и все! Теперь ваш фон яркий и безопасный.

Нежелательные диалоги — не просто хорошее название фильма.

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

Что здесь нужно, так это заблокировать пользователя этой долго нажимаемой функциональностью, это добавить этот код в свой CSS:

body {
  -webkit-touch-callout: none !important;
}

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

Копировать|Вставить?

Что ж, это немного менее драматично, но опять же, это способ имитировать UX нативного приложения — отключение возможности выбора и копирования текста из приложения, поскольку это дает вид «веб-сайта», что нежелательно для нашего приложение. Это можно отключить, добавив свойство «user-select: none» в наш тег body:

body {
  -webkit-touch-callout: none !important;
  -webkit-user-select: none !important;
  user-select: none !important;
}

Безопасные зоны

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

Лично я загружаю его как можно скорее в дерево компонентов, а затем определяю ‹SafeArea position="top" /› и ‹SafeArea position="bottom" /› для управления верхним и нижним пространствами приложения. высота этих div дается плагином.

  • Обратите внимание на свойство «bottomSafe» панели навигации. это необходимо, так как панель навигации в этой ситуации «зафиксирована», поэтому свойство CSS «нижний» должно знать, насколько «держаться подальше» от нижней части экрана.

Уважайте мощную кнопку «Назад» в Android.

Конденсатор по умолчанию не будет уважать это. Это просто жестоко свернет приложение. Это большой запрет для нативного приложения, и его следует заменить, чтобы имитировать природу приложения. С этим легко справиться благодаря App plugin. Я использую его с DOM реактивного маршрутизатора как таковой:

import { App as Native } from "@capacitor/app";

...

   useEffect(() => {
    Native.addListener("backButton", (data) => {
      if (window.location.pathname === "/") {
        Native.minimizeApp();
      } else {
        navigate(-1);
      }
    })},[])
  • Обратите внимание, что если в вашем приложении есть нежелательные «обратные ссылки», такие как страницы оплаты или страницы входа, вы должны заменить историю местоположений, чтобы пользователь не мог вернуться.
// going back from a payment page to the homepage
   navigate("/", {
   state: { status: "success", id, email },
   replace: true,
   });

И последнее: никогда не доверяйте WIFI.

И на самом деле сотовые сети. Хорошо, просто не доверяйте Интернету. Как веб-разработчики, мы привыкли к тому, что пользователи загружают наше потрясающее веб-приложение с сервера — если их подключение к Интернету недостаточно — сайт просто не загрузится. Это не относится к конденсаторному приложению. Сайт всегда будет загружаться, просто статически ожидая, пока мы его откроем. это означает, что приложение может изначально загружаться на устройство без интернета, но асинхронная выборка не произойдет. это очень распространено в сотовом устройстве. Подумайте о лифтах, туннелях, бесплатном Wi-Fi McDonald и многом другом. Это означает для нас больше обработки ошибок, больше обратной связи с пользовательским интерфейсом, чтобы понять, что происходит, и больше запасных вариантов, особенно в медиа.

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