Githawk: Всплывающие уведомления

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

Хотя хотелось бы этого

Да, я чувствую тебя. Я думаю, что хорошим временным средним решением была бы работа bg, которая помечает приложение. Мы могли бы даже запланировать локальные push-уведомления с заданием bg! Но лично меня напрягает.

Однако мы могли бы поместить все это в настройки.

Желателен ли сервер для опроса в более долгосрочной перспективе? Однажды я сделал один именно для этой цели 😅 . Не уверен, насколько разумным был мой подход, но было бы интересно взглянуть на него еще раз.

Иногда (например, в случае со службами опросов) я склонен рассматривать UX, чтобы понять, какое решение было бы лучшим.

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

Я на 100% согласен с фоновой загрузкой. Я провел тщательное тестирование с этим за последние пару недель и нашел, что это довольно надежно. Запуск почти каждый час или около того с моим приложением, которое я использую пару раз в день.

Я также думаю, что это жизнеспособное долгосрочное решение.

Мне кажется, что цель состоит в том, чтобы знать, когда появляются новые уведомления, когда я НЕ использую приложение. В любом случае приложения остаются открытыми только около 10 минут (если вы попросите об этом). Но когда вы этого не делаете, система, кажется, дает вам лучший фоновый приоритет в моем собственном тестировании.

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

Добавив эту env var, вы увидите кучу статистики, когда ваше приложение запустится в консоли отладки Xcode. Это может быть действительно полезно. Они предполагают, что ваше приложение должно запускаться менее чем за 400 мс, лично я стремлюсь к 2-300 мс.

Очевидно, что использование энергии можно проверить с помощью Xcode или Instruments.

API фоновой выборки (как я уверен, вы знаете) имеет завершениеHandler, который вам нужно вызвать, когда вы закончите. Раньше я в основном просто вызывал его с .newData во всех случаях. Это было ошибкой. Точно не знаю, как это ранжируется, но важно вызывать .noData , когда их не было. Улучшает интервалы выборки.

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

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

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

Значки добавлены, но пока я оставлю это открытым, чтобы отслеживать добавление локальных уведомлений. Я думаю, это было бы круто. Полусложно, потому что мы должны отслеживать то, что уже было уведомлено. Также возможно объединение их в одно с надписью «4 новых уведомления».

Может быть, мы можем даже разделить уведомления по репо?

@rnystrom очень круто

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

Также у меня отключен значок, но он все равно появляется 😔

@Sherlouk , вы можете отключить его с помощью «Настройки» / «Уведомления» / «Свободное время» .. снимите флажок «Разрешить уведомления».

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

Существует также переключатель, который сформулирован или, по крайней мере, интерпретируется мной как «Отключить значок» - который не работает.

Правильно, я имел в виду, чтобы вы исправили это тем временем :)

@Sherlouk , значит, ты отключил его в настройках, но он все еще отображается? Ах, черт, кажется, я знаю, почему. Починю.

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

+1 за локальные уведомления.

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

_{Отправлено с помощью GitHawk}

Основная проблема, которую я предвижу, — это просто ограничения скорости, мы уже достаточно близко подошли к этому, просто будучи активным пользователем в приложении! Это без опроса уведомлений каждые несколько минут! Технически это не так уж сложно, но нам нужно решить, как это будет работать, не блокируя приложение github!

_{Отправлено с помощью GitHawk}

Я использую CodeHub для уведомлений. Я не уверен, как они это делают, но мне пришлось заплатить, чтобы активировать эту функцию. Мне просто нужно не забыть открыть GitHawk.

Вот, исходный код тоже с открытым исходным кодом: CodeHub-Push

_{Отправлено с помощью GitHawk}

Интересно, можем ли мы настроить второе приложение github только для уведомлений? Это потребует от людей входа в систему дважды, но смягчит ли это проблему с ограничением скорости?

_{Отправлено с помощью GitHawk}

Или это просто случай, когда мы попробуем это и посмотрим, будет ли это проблемой для большинства? Лучшее отслеживание этого могло бы быть удобным — что, если бы мы использовали структуру и публиковали событие, когда пользователь превысил лимит скорости, чтобы мы знали, когда это проблема? Опять же, нет смысла предлагать альтернативные решения проблемы несуществования!

_{Отправлено с помощью GitHawk}

Откуда поступает большинство вызовов API? Можно ли оптимизировать их, кэшируя некоторые данные?

_{Отправлено с помощью GitHawk}

Глядя на CodeHub-Push (спасибо @schrodincat !) кажется, что их подход _на пользователя_ (я, вы и т. д.), а не _на приложение_ (GitHawk), поэтому ограничение скорости не должно быть проблемой?

Проблемы с ограничением скорости, которые я наблюдал, относятся к каждому пользователю 😔 мы должны, и определенно в прошлом, смотреть на оптимизацию, но в конечном итоге, если вы откроете 50 уведомлений, это будет много вызовов API! Мы мало что можем с этим поделать!

_{Отправлено с помощью GitHawk}

@rnystrom После этого слияния мы будем получать push-уведомления от GitHawk на iOS о любых обновлениях в наших репозиториях на Github?

@mesqueeb все, о чем вы получаете уведомление на веб-сайте.