Работа мобильного приложения в режиме сервиса
Наше приложение на мобильной платформе по замыслу должно работать в режиме сервиса, т.е. постоянно находиться на связи с сервером, чтобы моментально получать от него информацию о новых заказах, событиях и т.д.
Инициализация сеанса связи реализована через реакцию на пуш-уведомление и дополнительно выполняется раз в N секунд через обработчик ожидания, реализованной в одной из форм приложения.
Но мы столкнулись с тем, что для работы в таком режиме после установки необходима дополнительная настройка смартфона/планшета, связанная с отключением контроля активности (настройка экономии энергии).
Вот такая проблема. Может быть, кто-то сталкивался с ней и знает как решить ее более надежно и просто.
Инициализация сеанса связи реализована через реакцию на пуш-уведомление и дополнительно выполняется раз в N секунд через обработчик ожидания, реализованной в одной из форм приложения.
Но мы столкнулись с тем, что для работы в таком режиме после установки необходима дополнительная настройка смартфона/планшета, связанная с отключением контроля активности (настройка экономии энергии).
Вот такая проблема. Может быть, кто-то сталкивался с ней и знает как решить ее более надежно и просто.
По теме из базы знаний
- Проект, который прошел путь от провала до web-клиента. От web-клиента до мобильного приложения
- Мобильное приложение на 1С?
- Мобильное приложение 1С и Умный дом. В каждый дом. Пролог
- Как начать зарабатывать на разработке мобильных приложений уже завтра!
- Подсистема управления контентом + автономное мобильное приложение
Найденные решения
во всех смартфонах есть такая опция - блокировки приложения, точнее типо его защиты, это нужно для мессенджеров например, так как андроид их тоже выгружает из памяти и сообщения не приходят.
Попробуйте включить защиту на самой 1с.
Включается она по разному на разных смартфонах.
Вот тут примеры есть что можно сделать для этого
Например, для Xiaomi
Попробуйте включить защиту на самой 1с.
Включается она по разному на разных смартфонах.
Вот тут примеры есть что можно сделать для этого
Например, для Xiaomi
При открытии панели недавних приложений перетащите приложение вниз – оно будет заблокировано. Таким образом, даже если вы удалите последние приложения, они не будут удалены из фона. Перетащите вниз еще раз, чтобы очистить приложение от фона.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
во всех смартфонах есть такая опция - блокировки приложения, точнее типо его защиты, это нужно для мессенджеров например, так как андроид их тоже выгружает из памяти и сообщения не приходят.
Попробуйте включить защиту на самой 1с.
Включается она по разному на разных смартфонах.
Вот тут примеры есть что можно сделать для этого
Например, для Xiaomi
Попробуйте включить защиту на самой 1с.
Включается она по разному на разных смартфонах.
Вот тут примеры есть что можно сделать для этого
Например, для Xiaomi
При открытии панели недавних приложений перетащите приложение вниз – оно будет заблокировано. Таким образом, даже если вы удалите последние приложения, они не будут удалены из фона. Перетащите вниз еще раз, чтобы очистить приложение от фона.
(2)Спасибо.
Мы тоже рассматривали такое решение. Но пока не торопимся его применять, т.к. есть риск, что на некоторых моделях устройств блокировка может привести к проблемам при зависании приложения.
Интересно, что есть связанная с озвученной выше проблема (опять же не на всех устройствах) - пуш-уведомления, направленные приложению 1С, срабатывают на устройстве только в момент "просыпания" устройства. Причем само приложение активно (судя по сеансам связи с сервером), благодаря настройкам экономии энергии.
Блокировка помогает, но не понятно, почему именно для 1С такое исключение, для других приложений без доп. настроек уведомления приходят нормально.
Мы тоже рассматривали такое решение. Но пока не торопимся его применять, т.к. есть риск, что на некоторых моделях устройств блокировка может привести к проблемам при зависании приложения.
Интересно, что есть связанная с озвученной выше проблема (опять же не на всех устройствах) - пуш-уведомления, направленные приложению 1С, срабатывают на устройстве только в момент "просыпания" устройства. Причем само приложение активно (судя по сеансам связи с сервером), благодаря настройкам экономии энергии.
Блокировка помогает, но не понятно, почему именно для 1С такое исключение, для других приложений без доп. настроек уведомления приходят нормально.
(3) других это каких? Если вы обратите внимание, то не со всеми мессенджарами это работает.
Для того чтобы приложение могло вот так работать без всего оно должно ставить аккаунт, вот у вайбера, телеграмма и т.д. - он есть, если его нету, то тако приложение будет вести себя точно так же как и 1с.
Зайдите в настройки - Аккаунты и синхронизация и увидите полный список. Таким образом эти приложения прклеиваются к службе синхронизации. Без этого сделать ничего не выйдет. Я уже 3 года про это самой 1С гворю, что это логично, если 1С будет ставиться как аккаунт системы, в этом случае я могу создать все контакты контрагентов в телефоне, например, и они будут прикреплены к этому акку, и если вы 1с удалите, то и контакты все эти левые исчезнут.
Короче, там дофига плюшек выходит, но увы, воз и ныне там :(
Для того чтобы приложение могло вот так работать без всего оно должно ставить аккаунт, вот у вайбера, телеграмма и т.д. - он есть, если его нету, то тако приложение будет вести себя точно так же как и 1с.
Зайдите в настройки - Аккаунты и синхронизация и увидите полный список. Таким образом эти приложения прклеиваются к службе синхронизации. Без этого сделать ничего не выйдет. Я уже 3 года про это самой 1С гворю, что это логично, если 1С будет ставиться как аккаунт системы, в этом случае я могу создать все контакты контрагентов в телефоне, например, и они будут прикреплены к этому акку, и если вы 1с удалите, то и контакты все эти левые исчезнут.
Короче, там дофига плюшек выходит, но увы, воз и ныне там :(
(4)Интересная тема про аккаунты.
У нас есть еще приложение (назовем его Не1С), мы шлем туда пуш-уведомления (через API FCM правда), вот туда прилетают они, когда устройство в спячке.
Тут же шлем пуш в 1С (с помощью методов встроенного языка) - уведомления появляются на устройстве, только когда выведешь его из спячки.
Посмотрел, в упомянутом разделе и 1С и Не1С приложения не числятся, но 2е почему-то работает лучше.
У нас есть еще приложение (назовем его Не1С), мы шлем туда пуш-уведомления (через API FCM правда), вот туда прилетают они, когда устройство в спячке.
Тут же шлем пуш в 1С (с помощью методов встроенного языка) - уведомления появляются на устройстве, только когда выведешь его из спячки.
Посмотрел, в упомянутом разделе и 1С и Не1С приложения не числятся, но 2е почему-то работает лучше.
(7)
Там все не так просто, но зависимость от памяти - прямая.
Есть такая картинка
Андроид (как и вобщем то любой линукс) - килит все сверху вниз, и слева на право, вот так раз слева на право он килит по коэффициенту, называется он oom_adj_score, и чем он выше - тем быстрее андроид кильнет его.
НО! Этот коэфициент - это вероятность килла, и чем он выше - тем ВЕРОЯТНЕЕ что андроид его кильнет, НО НЕ ГАРАНТИРУЕТ :) Вот так.
Иначе получалось бы так, что вы игру запустили, она сожрала у вас всю память, теперь вы ее свернули и открывается вайбер чтобы прочитать сообщение, и в этот момент - андроид бы должен был сразу кильнуть игру, ибо пипец. Но он кильнет ее сразу, т.е. если вы за пару секунд справитесь и откроете игру - вы продолжите с того, где остановились. А не снова ждать ее перезагрузки.
Короче - тут ванговать надо и курить функцию, что бы понять - как именно андроид выбирает жертву, но всем в лом и все знают, что есть некая вероятность что приложение убъет, и онана прямую зависит в том числе от памяти.
Короче, тут долго жевать можно.
Идея в том, что на горизонтальный приоритет - влиять не реально, а на вертикальный - реально, но не нам, а разработчикам платформы.
Там все не так просто, но зависимость от памяти - прямая.
Есть такая картинка
Андроид (как и вобщем то любой линукс) - килит все сверху вниз, и слева на право, вот так раз слева на право он килит по коэффициенту, называется он oom_adj_score, и чем он выше - тем быстрее андроид кильнет его.
НО! Этот коэфициент - это вероятность килла, и чем он выше - тем ВЕРОЯТНЕЕ что андроид его кильнет, НО НЕ ГАРАНТИРУЕТ :) Вот так.
Иначе получалось бы так, что вы игру запустили, она сожрала у вас всю память, теперь вы ее свернули и открывается вайбер чтобы прочитать сообщение, и в этот момент - андроид бы должен был сразу кильнуть игру, ибо пипец. Но он кильнет ее сразу, т.е. если вы за пару секунд справитесь и откроете игру - вы продолжите с того, где остановились. А не снова ждать ее перезагрузки.
Короче - тут ванговать надо и курить функцию, что бы понять - как именно андроид выбирает жертву, но всем в лом и все знают, что есть некая вероятность что приложение убъет, и онана прямую зависит в том числе от памяти.
Короче, тут долго жевать можно.
Идея в том, что на горизонтальный приоритет - влиять не реально, а на вертикальный - реально, но не нам, а разработчикам платформы.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот