Githawk: 푸시 알림

이것은 사용자를 인증하고 알림을 보내기 위해 정기적으로 새 알림을 폴링하는 웹 서버에 저장해야 한다는 점에서 많은 작업이 필요합니다. 장치에서 백그라운드 가져오기가 더 운이 좋을 것이라고 생각합니다. 티켓이 있습니다!

그래도 이것을 좋아할 것입니다.

그래, 나는 너를 느낀다. 나는 좋은 임시 중간 솔루션이 앱에 배지를 주는 bg 작업이 될 것이라고 생각합니다. b 작업으로 로컬 푸시 알림을 예약할 수도 있습니다! 그러나 개인적으로 푸시는 짜증날 것입니다.

그러나 우리는 이 모든 것을 설정에 넣을 수 있습니다.

폴링 서버가 더 오래 원하는가요? 딱 이 용도로 한번 만들어봤습니다 😂 . 내 접근 방식이 얼마나 제정신인지는 확실하지 않지만 다시 한 번 살펴보면 흥미로울 것입니다.

때로는 (폴링 서비스와 같이) 어떤 솔루션이 가장 좋은지 이해하기 위해 UX를 고려하는 경향이 있습니다.

나에게 대답해야 할 질문은 사람들이 단일 세션 동안 앱에서 보내는 시간입니다. 나처럼 한 번에 몇 분 정도면 폴링이 과도할 수 있기 때문입니다.

나는 그가 배경 가져오기에 100% 동의합니다. 나는 지난 몇 주 동안 이것으로 철저한 테스트를 했고 그것이 꽤 신뢰할 수 있다는 것을 발견했습니다. 하루에 두 번 사용하는 앱에서 거의 매시간 트리거합니다.

나는 그것이 실행 가능한 장기적 해결책이라고 생각합니다.

앱을 사용하지 않을 때 새 알림이 있을 때를 아는 것이 목표인 것 같습니다. 어쨌든 앱은 약 10분 동안만 열려 있습니다(요청한 경우). 그러나 당신이하지 않을 때 시스템은 내 자신의 테스트에서 더 나은 배경 우선 순위를 제공하는 것으로 보입니다.

백그라운드 가져오기에서 찾은 메모. (애플 동료의 일부)
백그라운드 가져오기는 대부분 문서화되어 있지 않지만 응용 프로그램 시작 시간 및 에너지 사용량과 같은 몇 가지 팁을 보았습니다.

이 환경 변수를 추가하면 앱이 Xcode의 디버그 콘솔에서 시작될 때 많은 통계를 볼 수 있습니다. 정말 유용할 수 있습니다. 그들은 귀하의 앱이 400ms 이내에 시작될 수 있어야 한다고 제안합니다. 저는 개인적으로 2-300ms를 목표로 하는 경향이 있습니다.

에너지 사용량은 분명히 Xcode 또는 Instruments에서 확인할 수 있습니다.

백그라운드 가져오기 API(당신이 알고 있는 것처럼)에는 완료되었을 때 호출해야 하는 completionHandler가 있습니다. 이전에는 거의 모든 경우에 .newData 로 호출했습니다. 이것은 실수였습니다. 이 순위가 정확히 어떻게 되는지 확실하지 않지만 아무 것도 없을 때 .noData 를 호출하는 것이 중요합니다. 가져오기 간격을 개선합니다.

중요한 것은 이 수치를 낮게 유지하는 것입니다. 앱을 매우 빠르게 실행할 수 있다면 배터리를 적게 사용하고 상당히 빨리 완료하면 시스템이 백그라운드 시간을 더 많이 제공하는 경향이 있습니다.

다시 한 번 이것은 내 자신의 제한된 테스트이지만 수년 동안 성공적인 백그라운드 가져오기 구현을 통해 여러 앱에서 작업했습니다.

+1 목표는 앱에 배지를 지정하고 앱에 없을 때 새로운 것이 있을 때 선택적으로 알리는 것입니다. 지금은 b 작업을 계속하겠습니다.

배지가 추가되었지만 로컬 알림 추가를 추적하기 위해 지금은 열어 둡니다. 나는 그것이 멋지다고 생각한다. 이미 통보된 내용을 추적해야 하기 때문에 세미 복잡합니다. 또한 "4개의 새로운 알림"과 같은 메시지로 일괄 처리할 수 있습니다.

알림을 repo별로 나눌 수도 있습니까?

@rnystrom 아주 멋져요

질문: 앱이 홈 화면에 배지를 가지고 있지만 열었을 때 :tada: 아이콘을 얻었고 새로고침하기 위해 당겨야 했습니다. 이것이 현재 작동하는 방식인가요?

또한 배지가 꺼져 있지만 여전히 표시되고 있습니다 😔

@Sherlouk 는 설정/알림/자유 시간으로 끌 수 있습니다 .. 알림 허용을 선택 취소합니다

이해하지만 앱 소유자로서 사용자가 해당 수준에서 해당 기능을 끄도록 하는 것은 다른 방법으로 알림을 활용하려는 경우에 정말 좋지 않습니다. 해당 설정에 대한 인앱 제어가 더 좋아야 합니다.

"배지 끄기"와 같이 말하거나 적어도 내가 해석하는 토글도 있습니다. 작동하지 않습니다.

맞아요, 그 사이에 이 문제를 해결해 주려고 했어요 :)

@Sherlouk 그래서 설정에서 disBled를 주었지만 여전히 배지를 받고 있습니까? 아 젠장 ​​그 이유를 알 것 같아요. 수정합니다.

지역 알림은 매우 환영받을 것입니다. 저는 현재 (유료) 앱 CodeHub를 사용하여 알림을 받은 다음 알림을 탭하지 말고 대신 GitHawk를 열어야 한다는 것을 기억해야 합니다.

지역 알림의 경우 +1입니다.

나는 실제 서버 측 푸시 알림에 대해 절대적으로 100%입니다. GitHub가 메시징 서비스가 아니라는 것을 알고 있지만 반응 시간은 여전히 ​​중요하며 빠른 응답은 전환을 더 빠르게 진행하여 문제를 더 빨리 해결하는 데 도움이 될 수 있습니다. 나는 실제로 GitHub 자체가 아직 푸시 기능이 있는 공식 앱을 제공하지 않았다는 사실에 당황했습니다.

_{GitHawk 와 함께 전송}

내가 예상하는 주요 문제는 단지 속도 제한입니다. 앱에서 활성 사용자가 되는 것만으로도 이미 거의 도달했습니다! 몇 분마다 알림을 폴링하지 않아도 됩니다! 기술적으로 그렇게 어렵지는 않지만 github 앱을 잠그지 않고 어떻게 작동하는지 알아내야 합니다!

_{GitHawk 와 함께 전송}

나는 알림을 위해 CodeHub 를 사용합니다. 어떻게 하는지는 모르겠지만 기능을 활성화하려면 비용을 지불해야 했습니다. 대신 GitHawk를 여는 것을 기억해야 합니다.

여기도 오픈 소스입니다: CodeHub-Push

_{GitHawk 와 함께 전송}

알림용으로 두 번째 github 앱을 설정할 수 있는지 궁금합니다. 사람들이 두 번 로그인해야 하지만 속도 제한 문제를 완화할 수 있습니까?

_{GitHawk 와 함께 전송}

아니면 우리가 그것을 시도하고 그것이 대부분의 문제인지 확인하는 경우입니까? 이에 대한 더 나은 추적은 편리할 수 있습니다. 패브릭을 사용하고 사용자가 속도 제한을 초과했을 때 이벤트를 게시하여 언제 문제가 발생하는지 알 수 있다면 어떨까요? 다시 말해서 존재하지 않는 문제에 대한 대안적 해결책을 제시하는 것은 의미가 없습니다!

_{GitHawk 와 함께 전송}

대부분의 API 호출은 어디에서 발생합니까? 일부 데이터를 캐싱하여 최적화할 수 있습니까?

_{GitHawk 와 함께 전송}

CodeHub-Push를 보면( @schrodincat 감사합니다!) 그들의 접근 방식은 _per-app_(GitHawk)가 아니라 _per-user_(나, 당신 등)인 것 같으므로 속도 제한이 문제가 되지 않아야 합니까?

내가 보아온 속도 제한 문제는 사용자당입니다. 우리가 할 수 있는 일은 많지 않습니다!

_{GitHawk 와 함께 전송}

@rnystrom 이 병합으로 iOS의 GitHawk에서 Github의 저장소 업데이트에 대한 푸시 알림을 받게 됩니까?

@mesqueeb 웹사이트에서 알림을 받는 모든 것.