ОБЛАСТЬ ТЕХНИКИ

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

УРОВЕНЬ ТЕХНИКИ

На сегодняшний день растущее применение находит технология прогрессивных вебприложений (англ. PWA - Progressive Web Application), позволяющая “продлевать” действие веб-ресурса в аналог приложения на основании веб-ресурса. Также, еще одной применяемой технологией является решение Apache Cordova, которое позволяет формировать гибридное приложение для каждого веб-ресурса.

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

Еще один метод описан в патентной заявке US 20070277109 Al (IBM, 29.11.2007), где раскрывается принцип представления приложения на конечном устройстве пользователя с помощью своеобразного запаковщика (англ. Wrapper), который обеспечивает анализ и перенос программной логики и отрисовку интерфейса с внешнего-веб-приложения в интерфейс устройства пользователя, формируя тем самым нативное приложение.

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

Общим недостатком данных известных решений является то, что при переносе веб-ресурса в виде приложения на устройство пользователя не учитываются уникальные правила сохранения веб-ресурса для каждого устройства, исходя из особенностей его операционной среды, что приводит к необходимости создавать отдельные правила сохранения и/или программные контейнеры для каждого типа устройств пользователей. СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

Заявленное решение реализуется за счет способа конвертирования веб-ресурса в приложение для устройства пользователя, который выполняется с помощью процессора и содержит этапы, на которых:

- получают информацию о веб-ресурсе в виде по меньшей мере URL-адреса;

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

- выполняют конвертацию веб-ресурса с заданными правилами сохранения приложения на устройстве пользователя;

- сохраняют веб-ресурс в виде приложения на устройстве пользователя.

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

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

В другом частном примере осуществления способа правила сохранения основаны по меньшей мере на параметрах ОС и параметрах веб-браузера устройства пользователя.

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

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

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

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

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

В другом частном примере осуществления способа информация о веб-ресурсе дополнительно содержит графическую иконку или название.

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

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

В другом частном примере реализации системы правила сохранения основаны по меньшей мере на параметрах ОС и параметрах веб-браузера устройства пользователя.

В другом частном примере реализации системы дополнительно учитывается разрешение экрана устройства пользователя.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фиг. 1А-1В иллюстрируют пример сохранения веб-ресурса с помощью контейнера.

Фиг. 2 иллюстрирует пример наполнения контейнера.

Фиг. 3 иллюстрирует пример ручного сохранения веб-ресурса с помощью панели администратора.

Фиг. 4 иллюстрирует блок-схему заявленного способа.

Фиг. 5 иллюстрирует общую схему вычислительного устройства.

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

Как представлено на Фиг. 1А-1В, заявленное техническое решение позволяет конвертировать внешний веб-ресурс (110) в сети Интернет, отображаемый в браузере устройства пользователя (100), например, смартфоне, планшете или персональном компьютере, в устанавливаемое приложение (120). Конвертация веб-ресурса (110) осуществляется с помощью применения программного контейнера (111), размещаемого на веб-ресурсе (НО). Контейнер (111) может быть как внешней оболочкой для веб-ресурса (ПО) (iframe), так и устанавливаемым расширением (применение Java Script библиотек для получения функций установки), данный пример приведен на Фиг. 1В, на которой слева представлен пример с оболочкой, справа - реализация контейнера (111) в виде расширения.

Данная технология значительно упрощает процесс создания и доставки сетевых приложений любого вида до источника их потребления (пользователя) и не зависит от источника или метода производства, как то - CMS систем (например WordPress, Wix, Shopify, BigCommerce, Bitrix), фрэймворков или языков программирования (например VUE, Angular, JS тд) или баз данных (например MySQL, PostgreSQL, MS SQL, MongoDB и тп), а также независимо от юзер агента или метода просмотра, по типу устройств (например смартфон, ПК) или операционной среды (сочетания операционной системы и браузера).

Процесс конвертирования веб-ресурса (110) осуществляется непосредственно на устройстве (100) пользователя за счет активации логики контейнера (111), которая получает информацию о веб-ресурсе (110), в частности его URL-адрес, но также может использоваться доступная информация о названии веб-ресурса и наличия графической иконки, которые также могут использоваться при конвертировании.

Контейнер (111) связывается с базой правил сохранения веб-ресурсов (110) для устройства пользователя (100). Данная база учитывает множество вариаций правил сохранения вебресурсов (НО), исходя из особенностей различных конечных устройств, как это представлено на Фиг. 1Б для различного примера сохранения на устройствах (101) - (103). Конвертирование веб-ресурса (110) осуществляется по заданным правилам, подходящим под конкретное устройство (100), с которого поступает такой запрос и выполняется активация контейнера (111), в ходе чего формируется логика устанавливаемого приложения (120) на устройстве, содержащего весь функционал и параметры отображения веб-ресурса (110).

Заявленный способ учитывает правила создания и сохранения приложений в различных условиях и модифицирует свое поведение для каждого отдельного пользовательского устройства (101)-(103), в зависимости от текущих условий получающего устройства (агента), вынося правила сохранения на уровень выше от самого контента и логики приложения, и выполняя маршрутизацию правил в зависимости от среды их исполнения. Таким образом источник контента не требует никаких модификаций, а работает внутри контейнера (111) системы, обеспечивающего процессы сохранения приложений (120) и доступа к ним в каждой индивидуальной операционной среде пользователя на выбранном устройстве (100).

На Фиг. 2 представлен пример наполнения контейнера (111). Контейнер (111) хранит методы и данные уровня приложения, при этом также хранит внутри (или запрашивает извне) набор правил уровня контейнера для автоматической адаптации в зависимости от сочетания таких параметров как: операционная система (ОС), браузера и форм фактора операционной среды. Контейнер (111) использует любую из доступных технологий, в которых источник контента является внешним (iframe, portals), при использовании внутреннего контейнера. Контейнер имеет внешние выходы для взаимодействия с бэкенд системами ресурса по API и дает возможность вызывать указанные API от внешнего источника.

Под данными уровня приложения, используемыми в контейнере (111), может применяться манифест веб-ресурса (ПО), включающий в себя набор данных, таких как: иконка, отображаемая после сохранения, принцип загрузки веб-ресурса (ПО) (с адресной строкой, без нее или в полноэкранном режиме), заставка экрана (Splash screen), цветовую тему, ориентацию экрана, начальный url и др. Как правило, манифест представляет собой JSON файл.

Также, другими важными данными, используемыми в контейнере (111) является сервисный обработчик (англ. Service worker), выполняющий роль прокси-сервера, находящегося между веб-приложением ( 110) и браузером устройства ( 100), а также сетью (если доступна). Сервисный обработчик описывает корректное поведение веб-приложения (ПО) в режиме офлайн, обеспечивает перехват запросов сети и принимает соответствующие меры, основываясь на доступности сети. Также, он позволяет обновлять данные, находящиеся на сервере при доступе к нему, и имеет доступ к push-уведомлениям и API для фоновой синхронизации .

Наполнение контейнера (111) может осуществляться автоматически или в ручном режиме. Автоматическое наполнение использует доступные данные с веб-ресурса (ПО), для наполнения всех правил контейнера (111), например - графической составляющей (например, favicon для создания всех необходимых разрешений иконки приложения) и названия приложения. Эта информация может получаться с помощью парсинга содержимого веб-ресурса (ПО). При ручном наполнении все данные необходимые по правилам работы контейнера (111 ) наполняются в панели администратора, представленные на схеме Фиг. 3. После наполнения данными, производится создание контейнера (111), и в результате работы этого процесса формируются URL ссылки на контейнер (111) и/или токены для получения контейнера (111) с сервера в режиме онлайн.

На Фиг. 4 приведена блок-схема выполнения заявленного способа конвертирования вебресурса. На первом этапе (201) пользователь с помощью веб-браузера устройства (100) осуществляется вход на веб-ресурс (110), который содержит контейнер (11 1). При активации контейнера (111) выполняется обработка URL-адреса соответствующего вебресурса (ПО). При активации контейнера (202) выполняется проверка вариантов операционной среды устройства пользователя (100), для чего контейнер (111) обращается к хранилищу вариантов сред. Проверка вариантов операционной среды включает в себя анализ на какой операционной среде и каком браузере открыт контейнер (111), в том числе проверка на Webview, проверка того, что возможно ли в данной операционной среде сохранить приложение прямым способом, и какой способ является подходящим для данной операционной среды.

Хранилище вариантов сред являет собой логическое дерево, которое может как быть в составе самого программного кода контейнера (111), то есть в памяти устройства (100), с которого осуществляется вход, так и располагаться на внешнем источнике, к которому выполняет запрос в реальном времени и возвращается уже определенное правило сохранения. В заявленном решении реализован гибридный подход, в котором правила уже присутствуют в контейнере (111), но при этом при сохранении веб-ресурса (ПО) выполняется проверка того, что упомянутые правила являются актуальными и контейнер (111) содержит их последнюю версию.

На этапе (203) по факту обработки данных операционной среды устройства (100) осуществляется сохранения веб-ресурса (110) с помощью правил сохранения, применяемых контейнером (111). На данном этапе логика контейнера (111) также обращается к хранилищу вспомогательных методов/инструкций для обеспечения процесса сохранения веб-ресурса (110).

Правила сохранения учитывают особенности конечного устройства (100) и формируют правильный тип отображения веб-ресурса (ПО) в интерфейсе пользователя, исходя из ОС и веб браузера, установленных на устройстве (100), а также разрешения экрана, соотношения сторон и пр.

На этапе (204) выполняется конвертирование веб-ресурса (110) с учетом правил сохранения контейнера (111) и формирование нативного приложения (120) в операционной среде устройства (100) на этапе (205).

На этапе (204) дополнительно может выполняться подбор метода взаимодействия контейнера ( 111 ) с операционной средой устройства ( 100), для чего логика контейнера (111) обращается к хранилищу правил нотификаций/уведомлений для каждого варианта операционной среды для аналогичного типа устройств, а также к набору правил доступа к API операционной системы каждой упомянутой операционной среды. В зависимости от операционной среды контейнер (111) отображает только те методы, которые возможны в данной среде, например, если веб-ресурс (110) генерирует запрос на возможность отправки Push уведомлений, то контейнер (111) осуществляет анализ доступных методов для такого вида уведомлений. На этапе (205) дополнительно может осуществляться сохранение данных о выборе пользователя, например, факт установки контейнера (111), наличие разрешение на отправку Push уведомлений, в какой операционной среде было выполнено сохранение, имеется ли единый профиль.

При конвертировании веб-ресурса (110) может также осуществляться проверка нахождения контейнера (111) в режиме онлайн и определения доступности выбора метода взаимодействия с контейнером (111) для внешних API вызовов веб-ресурса (110). Внешние API вызовы могут представлять собой: PUSH уведомления, или запрос на разрешение Push уведомлений, или запрос факта установки контейнера приложения ранее, или запрос авторизационных данных единого профиля и прочее. Указанная выше проверка может осуществляться посредством методов иерархического взаимодействия по типу PARENT - CHILD , используя стандартные POST сообщения, для тех видов операций, где существует обработчик таких сообщений, и посредством передачи контейнером (111) на веб-ресурс (НО) метки о том, что вход сейчас осуществлен через приложение и сайт может использовать данные методы в таком случае.

Для каждого пользователя, осуществляющего активацию контейнера (111) для сохранения веб-ресурса (110) может осуществляться проверка наличия авторизационных данных пользователя и создание нового профиля пользователя, если ранее информация о таком пользователя не хранилась в системе, связанной с контейнером (111) и содержащей информацию о зарегистрированных единых профилях пользователей. Единый профиль может содержать следующие сведения о пользователях: ID пользователей, факты установленных приложений, факты привязки каналов Push сообщений, факты установки авторизационных токенов, данные пользователя с веб-ресурса, ID веб-ресурсов.

Единый профиль содержит унифицированные данные для сквозной авторизации пользователя с помощью программного контейнера (111) на внешнем веб-ресурсе (110).

На Фиг. 5 представлен общий пример вычислительной системы на базе вычислительного компьютерного устройства (300), например, компьютер, сервер, ноутбук, смартфон и т.п., которое может применяться для полной или частичной реализации заявленного решения и применяемых в нем устройств. В общем случае устройство (300) содержит такие компоненты, как: один или более процессоров (301), по меньшей мере одну оперативную память (302), средство постоянного хранения данных (303), интерфейсы ввода/вывода (304), средство В/В (305), средства сетевого взаимодействия (306). Процессор (301) устройства выполняет основные вычислительные операции, необходимые для функционирования устройства (300) или функционала одного или более его компонентов. Процессор (301) исполняет необходимые машиночитаемые команды, содержащиеся в оперативной памяти (302).

Память (302), как правило, выполнена в виде ОЗУ и содержит необходимую программную логику, обеспечивающую требуемый функционал. Средство хранения данных (303) может выполняться в виде HDD, SSD дисков, рейд массива, сетевого хранилища, флэш-памяти, оптических накопителей информации (CD, DVD, MD, Blue-Ray дисков) и т.п. Средство (303) позволяет выполнять долгосрочное хранение различного вида информации, например, истории обработки запросов (логов), идентификаторов пользователей, данные камер, изображения и т.п.

Интерфейсы (304) представляют собой стандартные средства для подключения и работы с камерами (20) или иными вычислительными устройствами. Интерфейсы (304) могут представлять, например, USB, RS232, RJ45, LPT, COM, HDMI, PS/2, Lightning, FireWire и т.п. Выбор интерфейсов (304) зависит от конкретного исполнения устройства (300), которое может представлять собой персональный компьютер, мейнфрейм, серверный кластер, тонкий клиент, смартфон, ноутбук и т.п., а также подключаемых сторонних устройств.

В качестве средств В/В данных (305) может использоваться: клавиатура, джойстик, дисплей (сенсорный дисплей), проектор, тачпад, манипулятор мышь, трекбол, световое перо, динамики, микрофон и т.п.

Средства сетевого взаимодействия (306) выбираются из устройства, обеспечивающий сетевой прием и передачу данных, например, Ethernet карту, WLAN/Wi-Fi модуль, Bluetooth модуль, BLE модуль, NFC модуль, IrDa, RFID модуль, GSM модем и т.п. С помощью средства (406) обеспечивается организация обмена данными по проводному или беспроводному каналу передачи данных, например, WAN, PAN, ЛВС (LAN), Интранет, Интернет, WLAN, WMAN или GSM, квантовый канал передачи данных, спутниковая связь и т.п.

Компоненты устройства (300), как правило, сопряжены посредством общей шины передачи данных (310).

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