Android studio cordova ionic

Android Development

This guide covers how to run and debug Ionic apps on Android emulators and devices using Capacitor or Cordova . Android apps can be developed on Windows, macOS, and Linux.

Android Studio

Android Studio is the IDE for creating native Android apps. It includes the Android SDK , which will need to be configured for use in the command line.

Android Studio is also used to create Android virtual devices , which are required for the Android emulator. Ionic apps can also be launched to a device .

We don’t recommend using Android Studio for developing Ionic apps. Instead, it should only really be used to build and run your apps for the native Android platform and to manage the Android SDK and virtual devices.

Installing Android Studio

Download Android Studio from the Android website . More detailed installation instructions can be found in the User Guide .

Installing the Android SDK

Once installed, open Android Studio. The IDE should detect that the Android SDK needs to be installed. In the SDK Components Setup screen, finish installing the SDK. Keep note of the Android SDK Location .

By default, the latest stable SDK Platform is installed, which includes a collection of packages required to target that version of Android.

To install system images and other minor SDK platform packages, you may need to ensure Show Package Details is checked at the bottom of the SDK Manager.

For future reference, the Android SDK can be managed with Android Studio in the Configure » SDK Manager menu of the Android Studio welcome screen or Tools » SDK Manager inside Android projects.

Configuring Command Line Tools

The Android SDK ships with useful command-line tools . Before they can be used, some environment variables must be set. The following instructions are for macOS and Linux. For Windows, check the documentation on setting and persisting environment variables in terminal sessions.

/.bash_profile , or similar shell startup scripts, make the following modifications:

Set the ANDROID_SDK_ROOT environment variable. This path should be the Android SDK Location used in the previous section.

Add the Android SDK command-line directories to PATH . Each directory corresponds to the category of command-line tool .

# avdmanager, sdkmanager export PATH=$PATH:$ANDROID_SDK_ROOT/tools/bin
# adb, logcat export PATH=$PATH:$ANDROID_SDK_ROOT/platform-tools
# emulator export PATH=$PATH:$ANDROID_SDK_ROOT/emulator

For apksigner and zipalign , $ANDROID_SDK_ROOT/build-tools must also be added to PATH .

Creating an Android Virtual Device

Android Virtual Devices (AVDs) are blueprints that the Android emulator uses to run the Android OS. The following documentation is a quick way to get the Android emulator set up. For more detailed instructions and information, see the Android documentation .

AVDs are managed with the AVD Manager. In the Android Studio welcome screen, click Configure » AVD Manager . The AVD Manager can also be opened inside Android projects in the Tools » AVD Manager menu.

Click Create Virtual Device and select a suitable device definition. If unsure, choose Pixel 2 . Then, select a suitable system image. If unsure, choose Pie (API 28) with Google Play services. See Android version history for information on Android versions.

Once the AVD is created, launch the AVD into the Android emulator. Keeping the emulator running is the best way to ensure detection while developing Ionic apps for Android.

Set up an Android Device

Actual Android hardware can also be used for Ionic app development. But first, the device must be set up for development. The following documentation is a quick way to set up Android devices for development. For more detailed instructions and information, see the Android documentation .

1. Enable USB debugging on the device. Open Settings , navigate to Developer options , and enable USB debugging . The Developer options menu may need to be enabled first. See the Android documentation for instructions.
2. Ensure the device has permission to connect to the computer. For macOS, no additional setup is required. For Windows, install the OEM USB drivers .

Verify the connection works by connecting the device to the computer with a USB cable and using the following command:

The device should be listed. See the full adb documentation for troubleshooting and detailed information.

Cordova Setup

Additional setup is required for Cordova to support programmatic builds. This section is not necessary for Capacitor.

Native Android apps are compiled with the Java programming language. Download JDK8 from the download page .

Unfortunately, Cordova is not compatible with the latest version of Java.

Gradle

Gradle is the build tool used in Android apps and must be installed separately. See the install page for details.

Project Setup

Before apps can be deployed to Android simulators and devices, the native project must be configured.

Generate the native project, if it does not already exist.

For Capacitor, run the following:

For Cordova, run the following:

For Capacitor, open the capacitor.config.json file and modify the appId property.

For Cordova, open the config.xml file and modify the id attribute of the root element, . See the Cordova documentation for more information.

Running with Capacitor

Capacitor uses Android Studio to build and run apps to simulators and devices.

Develop the Ionic app and sync it to the native project.

With each meaningful change, Ionic apps must be built into web assets before the change can appear on Android simulators and devices. The web assets then must be copied into the native project. Luckily, this process is made easy with a single Ionic CLI command.

In Android Studio, click the Run button and then select the target simulator or device.

Live reload

To start a live-reload server run the following command.

When running on a device make sure the device and your development machine are connected to the same network.

Running with Cordova

The Ionic CLI can build, copy, and deploy Ionic apps to Android simulators and devices with a single command. It can also spin up a development server, like the one used in ionic serve , to provide live-reload functionality.

Run the following to start a long-running CLI process that boots up a live-reload server:

Now, when changes are made to the app’s source files, web assets are rebuilt and the changes are reflected on the simulator or device without having to deploy again.

Debugging Android Apps

Once an app is running on an Android device or emulator, it can be debugged with Chrome DevTools.

Using Chrome DevTools

Chrome has web developer tool support for Android simulators and devices. Go to chrome://inspect in Chrome while the simulator is running or a device is connected to the computer and Inspect the app that needs to be debugged.

Make sure your application is running on the device or simulator, or it will not show up in the list.

Viewing Native Logs

If running with Android Studio, native logs can be found in Logcat .

If the Logcat window is hidden, you can enable it in View » Tool Windows » Logcat .

You can also access Logcat with ADB .

Источник

Cordova. Quick start

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

Что такое Cordova и зачем она нужна

Если коротко — это опенсорсный фреймворк, позволяющий писать кросс-платформенное приложение на JavaScript, а все слои ниже как раз призваны обеспечить сборку этого кода в приложение для целевой платформы, будь то Android, iOS, Windows, браузерное приложение или даже экзотическая платформа типа Tizen. В данном конкретном случае будут рассмотрены только сценарии для Android и браузера.

Более подробно о том, «что это и зачем это нужно» — гораздо лучше рассказано на сайте проекта, и конкретно здесь.

А мы пока только добавим картинку из упомянутого источника:

Установка Cordova на Windows

Установка фреймворка довольно проста. На ПК должен быть установлен Node.js. Он живет на сайте https://nodejs.org/en/, и для установки не требует никаких навыков, кроме умения кликать мышкой.

После установки Node.js в командной строке Windows будет доступен вызов пакетного менеджера npm. Теперь надо только взять и установить Cordova с его помощью:

npm install -g cordova

Все, Cordova установлена.

Однако, есть нюанс. Наличие установленной Cordova не означает наличия систем сборки под конечные платформы. И под каждую из платформ, кроме браузера, потребуется установка этих систем. Например, для Android потребуется установка Android SDK и Gradle. Установка этих систем описана в отдельных документах, здесь это рассматриваться не будет.

Создание пустого приложения

Этот шаг тоже не требует каких-то особых знаний.

В командной строке надо перейти в директорию, в которой планируется расположить проект, и выполнить команду:

cordova create test_prj

Будет создан каталог test_prj, в котором будут файлы проекта. Теперь надо перейти в него:

И добавить поддерживаемые платформы:

cordova platform add browser

cordova platform add android

В поддиректории platforms добавятся папки browser и android, содержащие наборы файлов уже под целевые платформы.

Теперь можно собрать тестовый проект, это делается так:

После сборки приложение можно запустить под конкретную платформу:

cordova run browser

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

cordova run android

То фреймворк установит и запустит приложение на эмуляторе Android-устройства или на живом устройстве, подключенном по USB.

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

Доработка дефолтного приложения

Отлично, у нас есть приложение, которое жрет память и батарейку, и больше ничего не делает. Прекрасный симулятор существования многих людей на планете, но программа обычно должна реагировать на внешние события. Раз так, то пойдем разбираться с тем, что у нас имеется. Главное, что у нас есть — это поддиректория www в папке с проектом, файл index.html и файл js/index.js внутри нее.

В index.html описан, по большому счету, макет окна, и анализировать его не имеет смысла.

Файл js/index.js тоже простой и очень короткий, если убрать комментарии:

Из него мы можем сделать два основных вывода:

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

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

Добавляем реакцию на внешнее воздействие

Начнем с простого. У нас уже есть элемент — надпись «Device is ready». Как на любой элемент на HTML-странице, на нее можно добавить обработчик события onClick. После запуска приложения исполняется функция onDeviceReady(). В ней, стало быть, и напишем:

Самой функции у нас нет, но и написать ее недолго:

Теперь после касания надписи будет появляться окошко с сообщением:

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

Теперь для нее надо добавить обработчик события ‘click’. Для этого в ту же функцию onDeviceReady() дописываем:

И создаем обработчик:

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

И как выглядит окошко с сообщением о нажатии кнопки:

Находим консоль

Это не единственный способ, но простой: в браузере Google Chrome вводим в адресную строку:

После этого у нас появится окошко, в котором можно найти свое отлаживаемое устройство/сессию:

Если приложение отлаживается на живом устройстве — можно будет подключиться и к нему. После нажатия «inspect» откроется окошко с довольно богатыми отладочными средствами — это видно по количеству вкладок сверху. Но нас в первую очередь интересует консоль, в которой видно сообщение о нажатии кнопки. Дублирующиеся сообщения консоль объединяет, показывая слева от них счетчик сообщений. Видно, что кнопка была нажата дважды.

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

Плагины

Что такое плагины в Cordova и зачем они нужны?

В идеологии Cordova плагин — это платформенно-зависимый кусок кода, «обернутый» в JavaScript. Они необходимы, так как многие вещи в «чистом» JavaScript не решить — начиная с банальной работы с файлами.

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

Почему не использовать сторонние плагины?

Кто сказал «не использовать»? Наоборот, использовать сторонние плагины, безусловно, надо. Увы, не на всякую задачу получится найти готовый плагин, не требующий доработок. Рано или поздно придется либо дорабатывать чужой плагин, либо писать свой.

Создание плагина

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

npm install -g plugman

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

plugman create —plugin_id «test.mytest» —name cordova-test-mytest —plugin_version 0.1.0

В текущей директории будет создана папка cordova-test-mytest (то есть, имя папки совпадает с параметром name). В ней будут следующие важные вещи:

Файл www/cordova-test-mytest.js — содержит объявление функций, доступных основному приложению после добавления плагина. По умолчанию будет доступен один метод под именем coolMethod().

Файл plugin.xml, содержащий имя плагина:

Указание на упомянутый выше файл JS:

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

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

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

plugman platform add —platform_name android

Произойдет несколько вещей:

Чертова утилита удалит из plugin.xml все переносы строк, превратив стройный XML в мешанину, которую придется приводить обратно к читабельному виду. Возможно, это можно исправить малой кровью, но на этапе написания статьи я этого способа не знаю.

Помимо устранения переносов строк, в файле XML появится элемент platform:

Здесь указаны всякие штуки, важные для Андроида, но на данном этапе нам важно то, что указан исходный файл cordova-test-mytest.java в элементе source-file.

В директории src появится поддиректория android, в которой будет тот самый файл cordova-test-mytest.java.

Как всё это работает, рассказано ниже, в разделе «Вызов функции плагина».

Добавление плагина к приложению

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

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

cordova plugin add ../cordova-test-mytest

Все, плагин добавлен.

Вызов функции плагина

В конечном приложении мы вызываем функцию следующим образом:

При вызове coolMethod() плагин в конечном счете вызывает метод execute() класса cordova-test-mytest. Тот получает на вход параметр action, который формирует cordova — он совпадает с именем вызванного метода. Можно объявить метод в cordova-test-mytest.js, но не предусмотреть под него действий в if() в методе execute() — тогда его вызов не приведет ни к каким полезным действиям.

Массив параметров вызова метода передается в виде JSON — это аргумент args, который преобразуется в строку путем вызова args.getString(0).

Само «полезное действие» реализовано в отдельном методе coolMethod(), куда передается строка с параметрами вызова и контекст обратного вызова. На самом деле, здесь уже можно передавать любой набор параметров. И даже callbackContext можно было бы не передавать, а вызывать callback-функции, вернувшись в execute() после выполнения coolMethod(). Но это привело бы к загромождению кода, поэтому сделано так, как сделано.

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

В результате выполнения кода в его приведенном виде мы должны получить alert с текстом «just string example», или с другим другим текстом, который мы передадим в coolMethod. Если же не задавать первый параметр coolMethod(), то тоже получим alert, но из функции errorMtd() — в нем будет текст «Error! Expected one non-empty string argument».

Отладка плагина

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

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

cordova plugin remove plugin.name

А потом добавлять его заново:

cordova plugin add ../plugin_path

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

Заключение

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

Как идеология — cordova вполне интересна, тут спорить не с чем. Хотя персонально мне, конечно, удобнее и интереснее писать в чем-то ближе к железу. В идеале так и вообще нативный код под ARM.

Совершенно невыносимым (лично для меня, повторюсь) оказалась отладка JS. При сборке ошибки в JS никак не отображаются, и к этому очень сложно привыкнуть приверженцу методологии «собралось — в релиз». Конечно, достаточно приучить себя к использованию отладочной консоли, но это занимаем определенное время.

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

Источник