как связать сайт с приложением

Как превратить веб-сайт в мобильное приложение с помощью 7 строк JSON

В материале, перевод которого мы публикуем сегодня, речь пойдёт о создании мобильных приложений на базе существующих веб-проектов. Автор этой статьи демонстрирует инструменты, которые позволяют с минимальными усилиями разрабатывать приложения, пользующиеся нативными возможностями платформ iOS и Android и включающие в себя материалы работающих сайтов или локальные ресурсы. Его рассказ начинается с тех самых семи строк JSON-кода, которые позволяют превращать сайты в мобильные приложения.

Превращение веб-сайта в мобильное приложение

Обзор

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

Что, если я скажу вам, что для того, чтобы воспользоваться этим подходом, не нужно переделывать сайт, пользуясь неким фреймворком, приближающим внешний вид ресурса к виду мобильного приложения? Более того, что если весь процесс разработки заключается в подключении сайта к мобильному приложению, подобному показанному выше, с помощью обычного URL?

Кроме того, вот ещё один вопрос: «Можно ли, просто редактируя JSON, работать с нативными API, с компонентами пользовательского интерфейса, пользоваться системными переходами между страницами?».

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

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

Прежде чем я расскажу о том, как это сделано, у вас может возникнуть вполне резонный вопрос: «Всё это хорошо, но можно ли, пользуясь методом, о котором идёт речь, создать что-то действительно полезное, а не нечто вроде простого «просмотрщика» веб-страниц в контейнере нативного приложения?».

Отличный вопрос. Собственно говоря, ответу на него и посвящена данная статья. Если в двух словах, то суть рассматриваемой здесь методики заключается в создании двустороннего канала связи между контейнером для вывода веб-содержимого и приложением. Приложению это даст возможность вызывать JavaScript-функции, находящиеся в контейнере, а контейнеру позволит обращаться к нативным API, расположенным за его пределами.

Взглянем на пример, иллюстрирующий вышесказанное.

Приложение для создания QR-кодов

Вот основные составные части этого приложения:

И, наконец, обратите внимание на то, что тут показано и взаимодействие компонентов приложения. А именно, QR-код меняется после ввода новых данных. Делается это благодаря возможности вызова JavaScript-функции, расположенной внутри веб-приложения, которая отвечает за создание QR-кодов на основе переданных ей данных.

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

Когда говорят о будущем мобильных приложений, обычно всё крутится вокруг вопроса о том, какой из подходов победит: основанный на HTML5 или на нативных API. Что характерно, в подобных рассуждениях не поднимается тема сосуществования этих двух подходов, и, более того, не рассматривается эффект синергии, который, благодаря совместному использованию различных технологий, позволит достигать результатов, которые нелегко достигнуть, полагаясь лишь на что-то одно.

В этом материале я собираюсь рассказать о следующих вещах:

Зачем использовать веб-технологии в мобильных приложениях?

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

▍1. Использование технологий, созданных для веб

Для реализации некоторых частей приложений может иметь смысл использование веб-технологий. Например, WebSocket — это технология, изначально ориентированная на веб. Для её использования можно применить встроенный в мобильную платформу веб-движок ( WKWebView для iOS и WebView для Android) вместо установки сторонней библиотеки, которая попросту «эмулирует» WebSocket.

При таком подходе не нужно использовать дополнительные библиотеки, достаточно, применяя стандартные технологии, делать то, что нужно. Это ведёт нас к следующей ситуации.

▍2. Уменьшение размеров пакета приложения

Использование веб-технологий в мобильных приложениях помогает делать то, что без этих технологий потребовало бы огромных сторонних библиотек.

Например, для того, чтобы встроить в мобильное приложение генератор QR-кодов, понадобится сторонняя библиотека, которая увеличит размер пакета приложения. Однако если применить для этого стандартное средство для просмотра веб-страниц и JS-библиотеку, подключённую к странице с помощью простой конструкции

Источник

Как связать android приложение с сайтом?

Есть сайт и я хочу создать андроид приложение и связать его с сайтом (практически со всем функционалом, что есть на сайте т.е. регистрация, новости и т.п.).

Подскажите, пожалуйста, как это делается и где мне об этом почитать.
Заранее спасибо!

Оценить 2 комментария

Ну с сайта у вас должен быть API, можете пока подготовить его.

Читать наверное придется много) основы java, потом офф гугл документация.
Среда написания приложений Eclips+ADT

В интернете очень много материала на эту тему.

Поискать можно по запросу REST API
Многие фреймворки поддерживают удобную архитектуру rest из коробки
laravel, yii2.

API на сайте это при запросе GET или POST запроса мы отдаем json или xml данные.
Лучше JSON с ним проще работать на клиенте и на сервере.
Не требует особых навыков). на сервере если используется PHP json_encode/json_decode

На клиенте на android
JSONObject jsonObject = new JSONObject(json);
из SDK developer.android.com/reference/org/json/JSONObjec.

либо делается обмен данных между сайтом и приложением через JSON.

Google позволяет связать конкретные страницы сайта с приложением и отслеживать активность пользователей, работающих с ним.

Внедрение проводится в два шага:

· добавить в приложение обработчик ссылок;

· связать сайт с приложением.

Проиндексировав контент приложения, Google найдет возможные связи с сайтом и отметит их соответственно в выдаче.

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

Источник

Блог вебмастера

создание сайтов, заработок в сети, раскрутка, программирование

Как связать android приложение и сайт

В этой статье опишу как связать android приложение и сайт и как подтвердить владение сайтом для webview при загрузке на google play market. Все приложения, которые загружал лично я успешно проходили модерацию (если они не нарушают правила).

Как подтвердить владение сайтом для android приложения

Рассмотрим два варианта. Первый — при создании progressive web app (PWA). Второй — при загрузке android приложения с webview на play market.

Как связать android приложение и сайт для TWA — Digital Assets Links

Как узнать SHA256 читайте в этой статье (несколько способов).

Создание Digital Assets Links также поможет при загрузке в play market webview-приложений.

Как доказать модератору google что сайт Ваш

В последнее время почти всегда простые webview приложения улетают на проверку. Так называемая «webview политика«. Что делать в таких случаях? Всегда писать что Вы владелец сайта и можете это подтвердить.

В ответное письмо модераторы просят отправить скриншот админ-панели сайта. У меня ни разу не запросили подтвердить домен (cname, ns-записи), просто сбросить скриншот админки.

Если приложение сделано хорошо, спустя пару дней разрешают загрузить новую версию и она без проблем проходит модерацию.

Что делать если модераторы не отвечают

Во-первых, пандемия и они прямо пишут что ответ можно ждать несколько недель. При чем на каждое письмо! Если вам ответили на первое письмо, это не значит что модератор сидит онлайн по одной вашей заявке. Мой максимум переписки — полтора месяца.

Если вам вообще не отвечают — значит не правильно обращаетесь. Пишите письма на английском языке, с четким описанием проблемы.

У меня обычно отвечали в течении 2-5 суток. Делаем все правильно — проблема решается оперативно.

Нельзя загрузить android webview или другое приложение на маркет

Есть масса причин, но опишу две самые популярные. Вы можете быть в черном списке. С Вашего пк, аккаунта гугл уже загружали приложения, которые нарушили правила. Это казино, азарт, адалт и т.п. Как это решить? Создавать виртуалки, использовать VPS, новые платежные данные. Не буду описывать все просто так.

Вторая причина — незнание. У меня были такие заказчики, которые «задолбали» модераторов (и меня, можно сказать). Прошу понять правильно — вы просто задрочили их и виноваты только вы. Не хотите читать, пользоваться переводчиком, спешите все отправить на модерацию.

Заказчики просто грузили версию повторно, хотя в письме от гугл прямо написано что нельзя снова добавлять это же приложение — удалят аккаунт. Просто поменять версию тоже не поможет.

Как обойти webview policy google play market

У меня все таки получалось вывести приложения таких заказчиков в маркет, но были потрачены нервы и время. Я писал модераторам, готовил скриншоты и почти всегда грузил первоначальную версию.

Напоминаю о Digital Assets Links. Загрузка файла assetlinks для связки приложения и сайта, по моему опыту, помогает. Делайте ее.

Источник

Взаимодействие сайта в браузере и локально запущенной программы

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

Первыми приходят в голову три способа решить эту задачу:

Почему не 1 и 2?

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

Второй пункт просто реализовать, но для этой схемы придется делать авторизацию не только на сайте, но и в локальном приложении. Значит понадобится какой-никакой, но интерфейс, при смене пароля потребуется повторная авторизация и в программе. Плюс в корпоративных сетях будут дополнительные проблемы с сетью, у них часто доступ в интернет реализован через прокси-серверы с суровой фильтрацией и авторизацией, для настройки прокси тоже придётся делать интерфейс, не всегда можно отделаться автоматическим определением настроек. Далёкому от IT пользователю будет сложнее с этим работать, создадим больше работы техподдержке. Конечно, можно формировать установочный пакет индивидуально для каждого пользователя, чтобы убрать необходимость первичной авторизации, но это только добавит проблем.

При чем тут HTTPS?

Когда сайт работает по HTTPS, браузеры блокируют загрузку активного содержимого с помощью HTTP. Однако, по логике вещей, запрос к локальной машине по HTTP браузеры должны считать безопасным, и не должны блокировать его. Это оказалось не совсем так.
Таблица показывает результаты небольшого исследования поведения браузеров на платформе Windows:

В таблице приведено поведение браузеров при попытке сделать запрос по соответствующему адресу. Браузеры на движке Chromium ведут себя аналогично Chrome, а поведение Edge 44 аналогично поведению IE 11. Для HTTPS выпущен валидный сертификат, подписанный самоподписанным корневым сертификатом. Поведение для https://127.0.0.1 и https://localhost одинаковое, просто для 127.0.0.1 тогда нужно тоже выпускать сертификат, а сертификаты для IP адресов редко встречаются, так что опустим этот момент.

В Chrome всё работает. Chrome и IE используют системное хранилище сертификатов, поэтому в них работает и HTTPS. Firefox использует собственное хранилище сертификатов, поэтому не доверяет нашему самоподписанному сертификату. Firefox и IE не доверяют имени localhost, и это правильно, ведь никто не гарантирует, что оно разрешится в 127.0.0.1 (хотя они могли просто это проверить, как делает Chrome).

Главная проблема: IE не даёт обратиться к программе по HTTP. Значит возни с сертификатами нам не избежать.

Для работы с браузерами также потребуется указывать в программе правильные заголовки Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers (CORS).

SSL сертификат

Можно сделать DNS-запись для своего домена, например local.example.com, которая будет разрешаться в 127.0.0.1. Выпустить для этого домена SSL сертификат, распространять его вместе с программой. Придётся распространять закрытый ключ этого сертификата вместе с программой. Это совершенно не годится. А сертификат в программе еще и нужно будет обновлять.

IE не будет доверять самоподписанному SSL сертификату, его надо подписать доверенным корневым сертификатом (а он может быть и самоподписанный).

Можно сгенерировать корневой сертификат и SSL сертификат и распространять их с программой, добавляя в локальное хранилище сертификатов. Выглядит небезопасно. И тоже может возникнуть необходимость отозвать или обновить сертификат. Поэтому, сертификаты с ключами будем генерировать прямо на компьютере пользователя при первом запуске программы.

Создание сертификатов в C#

В примере эту работу делает метод RegisterSslOnPort в классе SslHelper.

HTTP-сервис в программе на C#

Для примера создадим endpoint, занимающийся сложением двух чисел. Важно тут установить правильные заголовки CORS, иначе браузер не будет выполнять запрос к нашему API.

Добавим инициализацию Nancy в наше приложение, и мы готовы к бою.

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

Для симуляции тяжелой работы и долгих задержек в примере добавим Thread.Sleep(1000) в вызовы нашего API.

На этом приложение готово к запуску, перейдём к вебу.

Веб-приложение

Как понятно из таблицы поведения браузеров, каким-то одним эндпоинтом обойтись не получится, придётся использовать как минимум два:

В веб-приложении нам нужно определить, если мы в IE (или Edge) – использовать HTTPS, если нет – HTTP. Можно сделать надёжнее и не выяснять в каком мы браузере, а просто попробовать выполнить запрос к методу GET /Calc нашего API, если запрос успешен – работаем, если нет – пробуем другой протокол.

Всё это нужно только если веб-приложение само использует HTTPS, потому что при использовании протокола HTTP, браузеры не накладывают ограничений на запросы, нужны только правильные заголовки CORS.

В angular – приложении создадим сервис InteractionService, который будет выполнять проверку доступности локального эндпоинта сначала по HTTP, потом по HTTPS. Проверку выполняет метод checkAvailability, а результат проверки доступен при подписке на переменную available$ типа BehaviorSubject с начальным значением false.

Работу по сложению чисел поместим в компонент AppComponent. При нажатии кнопки “Calculate”, веб-приложение делает запрос к GET /Calc/Add?num1=&num2=. Ответ или ошибка отображается в поле Result.

При отладке, даже по HTTPS, можно не заметить проблем, так как домен для запросов будет один и тот же – localhost. Поэтому тестировать приложение нужно с другим доменным именем.
Чтобы максимально упростить работу по развертыванию веб-приложения воспользуемся сервисом https://stackblitz.com, это веб-IDE для angular и не только, со вкусом VSCode. Готовое приложение доступно по ссылке.

В интерактивном режиме на stackblitz приложение не будет работать, нужно открыть его в отдельной приватной вкладке, или в другом браузере по адресу https://angular-pfwfrm.stackblitz.io.

Как попробовать?

Веб-приложение удобно запустить с помощью stackblitz, просто перейдя по ссылке https://angular-pfwfrm.stackblitz.io.

Можно запустить веб-приложение локально.

для этого нужно клонировать репозиторий:

в папке AngularWebApp нужно выполнить команды:

Веб-приложение будет доступно по адресу https://localhost:4200/

Локальное приложение можно либо скомпилировать из примера (открыть CsClientApp.sln из папки CsClientApp) с помощью Visual Studio и запустить, либо использовать скрипт для программы LINQPad.

Безопасность

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

В любом случае, программа должна работать с минимальными правами, а если делает что-то чувствительное с документами, надо добавить в неё запросы на подтверждение операций.

Вывод

Несложная на вид задача на деле оказалась довольно объемной, да еще и требующей дополнительных костылей для работы с сертификатами.

Этот подход хорошо себя показал в реальном приложении. Конечно, чтобы использовать код из примера, нужно добавить нормальную обработку ошибок.

Никто на Virustotal на эту программу не реагирует, а хотелось бы! Зато если собрать установочный пакет в InnoSetup, пара третьесортных антивирусов начинает на него срабатывать. Помогает от этого избавиться подписывание установщика с помощью code signing certificate.

Автоматическое обновление программы здесь оставлено за кадром, но оно точно не будет лишним в реальном приложении. Для управления автоматическим обновлением хорошо подходит Squirrel. Еще с помощью squirrel удобно удалить наши сертификаты из системы при удалении программы.

Источник

Связывание приложений в Android

В этом руководстве показано, как в Android 6.0 используется методика связывания приложений, позволяющая мобильным приложениям реагировать на URL-адреса веб-сайтов. Вы узнаете, что такое связывание приложений, как реализовать связывание приложений в приложении Android 6.0 и как настроить доступ к домену для мобильного приложения на веб-сайте.

Общие сведения о связывании приложений

Мобильные приложения прочно вошли в обиход — во многих случаях это важные компоненты бизнеса наряду с веб-сайтом компании. Предприятиям нужна возможно легко объединять решения для веб-репрезентации с мобильными приложениями, чтобы ссылки на веб-сайте могли запускать мобильные приложения и отображать в них соответствующее содержимое. Связывание приложений (также называется глубинное связывание) — это один из методов, позволяющих мобильному устройству реагировать на URI и запускать соответствующее мобильное приложение.

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

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

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

В этом руководстве показано, как настроить приложение Android 6.0, а также создать и опубликовать файл ссылок на цифровые ресурсы для поддержки связывания приложений в Android 6.0.

Требования

Для работы с этим руководством требуется Xamarin.Android 6.1 и приложение, предназначенное для использования Android 6.0 (API уровня 23) или выше.

Связывание приложений в более ранних версиях Android реализуется через пакет NuGet Rivets из магазина компонентов для Xamarin. Пакет Rivets не совместим с механизмом связывания приложений в Android 6.0 и не поддерживает этот механизм.

Настройка связывания приложений в Android 6.0

Настройка связывания приложений в Android 6.0 включает два основных этапа.

Настройка фильтра намерений

Вам нужно настроить фильтр намерений, который сопоставляет URI (или даже набор из нескольких URI) некоторого веб-сайта с действием в приложении Android. В Xamarin.Android такое сопоставление устанавливается путем назначения действию атрибута IntentFilterAttribute. Фильтр намерений должен объявлять следующую информацию:

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

Создание файла ссылок на цифровые ресурсы

Для связывания приложений в Android 6.0 требуется, чтобы Android проверял все связи между приложением и веб-сайтом, прежде чем устанавливать приложение в качестве обработчика по умолчанию для URI. Такая проверка выполняется при первой установке приложения. Файл ссылок на цифровые ресурсы имеет формат JSON и размещается на всех соответствующих поддоменах.

Файл цифровых ресурсов содержит метаданные, необходимые для проверки связи платформой Android. Файл assetlinks.json содержит следующие пары «ключ — значение»:

Ниже приведен пример файла assetlinks.json, где указано одно приложение:

Вы можете зарегистрировать боле одного отпечатка SHA256, чтобы поддерживать несколько версий или сборок приложения. В следующем файле assetlinks.json представлен пример регистрации нескольких приложений:

Веб-сайт Google по ссылкам на цифровые ресурсы предоставляет онлайн-средство для создания и тестирования файла цифровых ресурсов.

Тестирование связывания приложений

Реализовав связывание приложения, следует проверить разные элементы этого механизма и убедиться, что они работают должным образом.

Вы можете убедиться, что файл цифровых ресурсов имеет правильный формат и правильно размещен, используя API Google для ссылок на цифровые ресурсы, как показано в этом примере:

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

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

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

Сводка

В этом руководстве описана методика связывания приложений в Android 6.0. Затем мы описали, как правильно настроить приложение Android 6.0 для включения поддержки ссылок и реагирования на них. Мы также обсудили, как протестировать связывание приложений для приложения Android.

Источник