Ваше замечание справедливо, постоянное поддержание WS в фоне действительно может сказаться на ресурсах устройства, но в данном контексте стоит учитывать, что любое собственное решение, исключающее официальные методы работы с пушами, будет иметь определенные минусы и в то же время плюсы. В пример можно взять те же RuStore-пуши, в первых версиях они также расходовали ресурс (что является минусом), но плюсом являлось то, что они не зависят от сервисов Гугл. С iOS-пушами согласен, Apple накладывают ограничения на создание подобных собственных решений, и даже если попытаться обойти APN-сервисы и написать свой хак (попытаться сделать фоновый сервис), велик риск получить Reject приложения. В данных вопросах важно также подчеркнуть, что суть статьи заключается в том, чтобы "раскрыть" исходную модель работы с пушами и на основе полученных знаний реализовать собственный интерфейс работы с пушами без FCM, RuStore и других провайдеров. Думаю, что теория работы с энергоэффективностью и улучшениями данного решения - это предмет более глубокого исследования и рассмотрения в отдельной статье.
Хороший вопрос. Интеграция «самописных» пушей под каждую платформу сводится к тому, что мы через единый интерфейс вызываем специфичные под требуемую платформу методы, поэтому для каждой платформы это действительно специфично. Для Web, к примеру, можно зарегистрировать Service Worker и далее реализовывать логику отображения пуша в package. В узле WS можно передавать практически любые данные (в том числе конфигурации, счетчики и ограничения) и явных ограничений на пуши, соответственно, нет, однако любые ограничения можно реализовать, модифицировав решение под конкретную систему/проект/задачу, в этом как раз преимущество самописного решения
@ADDA16Всё верно, голос и лицо в совокупности - это образец, анализ которого определяет - являетесь ли Вы субъектом биометрических персональных данных. Такой анализ не легко пройти в системе Госуслуг.
Ваше замечание справедливо, постоянное поддержание WS в фоне действительно может сказаться на ресурсах устройства, но в данном контексте стоит учитывать, что любое собственное решение, исключающее официальные методы работы с пушами, будет иметь определенные минусы и в то же время плюсы. В пример можно взять те же RuStore-пуши, в первых версиях они также расходовали ресурс (что является минусом), но плюсом являлось то, что они не зависят от сервисов Гугл.
С iOS-пушами согласен, Apple накладывают ограничения на создание подобных собственных решений, и даже если попытаться обойти APN-сервисы и написать свой хак (попытаться сделать фоновый сервис), велик риск получить Reject приложения.
В данных вопросах важно также подчеркнуть, что суть статьи заключается в том, чтобы "раскрыть" исходную модель работы с пушами и на основе полученных знаний реализовать собственный интерфейс работы с пушами без FCM, RuStore и других провайдеров. Думаю, что теория работы с энергоэффективностью и улучшениями данного решения - это предмет более глубокого исследования и рассмотрения в отдельной статье.
Хороший вопрос. Интеграция «самописных» пушей под каждую платформу сводится к тому, что мы через единый интерфейс вызываем специфичные под требуемую платформу методы, поэтому для каждой платформы это действительно специфично.
Для Web, к примеру, можно зарегистрировать Service Worker и далее реализовывать логику отображения пуша в package.
В узле WS можно передавать практически любые данные (в том числе конфигурации, счетчики и ограничения) и явных ограничений на пуши, соответственно, нет, однако любые ограничения можно реализовать, модифицировав решение под конкретную систему/проект/задачу, в этом как раз преимущество самописного решения
@ADDA16Всё верно, голос и лицо в совокупности - это образец, анализ которого определяет - являетесь ли Вы субъектом биометрических персональных данных. Такой анализ не легко пройти в системе Госуслуг.