Githawk: Mitteilungen

Dies würde ziemlich viel Arbeit erfordern, um Benutzer zu authentifizieren und dies in einem Webserver zu speichern, der regelmäßig nach neuen Benachrichtigungen abfragt, um eine Benachrichtigung zu senden - denke, wir werden mehr Glück mit dem Abrufen im Hintergrund auf Geräten haben, was ich weiß es gibt ein Ticket für!

Würde das aber lieben

Ja, ich fühle dich. Ich denke, eine gute temporäre Mid-Lösung wäre ein BG-Job, der die App kennzeichnet. Wir könnten sogar lokale Push-Benachrichtigungen mit dem bg-Job planen! Aber für mich persönlich wären Pushs ärgerlich.

Wir könnten dies jedoch alles in den Einstellungen vornehmen.

Wird ein Polling-Server längerfristig gewünscht? Genau für diesen Zweck habe ich mal einen gemacht 😅 . Ich bin mir nicht sicher, wie vernünftig mein Ansatz war, aber es wäre interessant, einen weiteren Blick darauf zu werfen.

Manchmal (wie bei Umfragediensten) neige ich dazu, die UX zu betrachten, um zu verstehen, welche Lösung am besten wäre.

Für mich wäre die zu beantwortende Frage, wie lange sich die Leute für eine einzelne Sitzung in der App aufhalten. Denn wenn es wie ich nur ein paar Minuten dauert, wäre das Polling wahrscheinlich zu viel des Guten.

Ich bin jedoch zu 100% mit den Hintergrundabrufen einverstanden. Ich habe dies in den letzten Wochen gründlich getestet und festgestellt, dass es ziemlich zuverlässig ist. Triggere fast jede Stunde oder so mit meiner App, die ich ein paar Mal am Tag verwende.

Ich denke, es ist auch eine praktikable langfristige Lösung.

Klingt für mich so, als ob das Ziel darin besteht, zu wissen, wann es neue Benachrichtigungen gibt, wenn ich die App NICHT verwende. Apps bleiben sowieso nur etwa 10 Minuten geöffnet (wenn Sie es wünschen). Aber wenn Sie dies nicht tun, scheint das System Ihnen in meinen eigenen Tests eine bessere Hintergrundpriorität zu geben.

Notizen, die ich zum Abrufen im Hintergrund gefunden habe. (Einige von einem Apple-Kollegen)
Das Abrufen im Hintergrund ist weitgehend undokumentiert, aber einige Tipps, auf die ich gestoßen bin, sind Dinge wie Anwendungsstartzeiten und Energieverbrauch.

Wenn Sie diese env-Variable hinzufügen, sehen Sie eine Reihe von Statistiken, wenn Ihre App in der Debug-Konsole von Xcode gestartet wird. Es kann wirklich nützlich sein. Sie schlagen vor, dass Ihre App in weniger als 400 ms gestartet werden sollte. Ich persönlich strebe eher 2-300 an.

Der Energieverbrauch kann natürlich von Xcode oder Instruments überprüft werden.

Die Hintergrundabruf-API (wie Sie sicher wissen) hat einen completeHandler, den Sie aufrufen müssen, wenn Sie fertig sind. Bisher hatte ich es meist nur mit .newData in allen Fällen genannt. Das war ein Fehler. Ich bin mir nicht sicher, wie es das einordnet, aber es ist wichtig, .noData zu callen, wenn es keines gab. Verbessert die Abrufintervalle.

Die Hauptsache ist, diese Zahlen niedrig zu halten. Wenn die App ziemlich schnell gestartet werden kann, wenig Akku verbraucht und ziemlich schnell fertig ist, neigt das System dazu, Ihnen mehr Hintergrundzeit zu geben.

Auch dies ist in meinen eigenen begrenzten Tests, aber ich habe im Laufe der Jahre an mehreren Apps mit erfolgreichen Hintergrundabrufimplementierungen gearbeitet.

+1, dass das Ziel darin besteht, die App zu kennzeichnen und optional zu benachrichtigen, wenn es neue Dinge gibt, wenn sie nicht in der App sind. Bleiben wir vorerst bei bg-Aufgaben.

Abzeichen hinzugefügt, aber ich lasse dies vorerst offen, um das Hinzufügen lokaler Benachrichtigungen zu verfolgen. Ich denke, das wäre cool. Halb kompliziert, weil wir nachverfolgen müssen, was bereits gemeldet wurde. Es ist auch wahrscheinlich, sie in eine zu stapeln, die wie "4 neue Benachrichtigungen" lautet.

Vielleicht können wir die Benachrichtigungen sogar nach Repo aufteilen?

@rnystrom sehr cool

Frage: Die App hat ein Abzeichen auf dem Startbildschirm, aber als ich sie öffnete, bekam ich das Symbol :tada: und musste ziehen, um sie zu aktualisieren. Funktioniert das derzeit so?

Außerdem habe ich das Abzeichen deaktiviert, aber ich bekomme es immer noch angezeigt 😔

@Sherlouk können Sie es mit Einstellungen / Benachrichtigungen / Freizeit deaktivieren. Deaktivieren Sie Benachrichtigungen zulassen

Ich verstehe das, aber als App-Besitzer selbst ist es wirklich schlecht, wenn Benutzer es auf dieser Ebene ausschalten, falls Sie Benachrichtigungen später auf andere Weise nutzen möchten - Sie sollten eine bessere In-App-Kontrolle über diese Einstellung haben.

Es gibt auch einen Schalter, der als "Abzeichen ausschalten" formuliert oder zumindest von mir interpretiert wird - was nicht funktioniert

Richtig richtig, ich wollte, dass du das in der Zwischenzeit behebst :)

@Sherlouk , also hast du es in den Einstellungen disBled gegeben, aber es ist immer noch ein Abzeichen? Ah Scheiße, ich glaube, ich weiß warum. Wird behoben.

Lokale Benachrichtigungen wären sehr willkommen. Ich verwende derzeit die (kostenpflichtige) App CodeHub, um Benachrichtigungen zu erhalten, und muss dann daran denken, sie nicht anzutippen, sondern stattdessen GitHawk zu öffnen.

+1 für lokale Benachrichtigungen.

Ich bin absolut zu 100 % für echte serverseitige Push-Benachrichtigungen. Ich weiß, dass GitHub kein Messaging-Dienst ist, aber die Reaktionszeit ist immer noch wichtig, und eine schnelle Reaktion kann dazu beitragen, dass Konvertierungen schneller in Gang kommen und Probleme daher schneller gelöst werden. Ich bin eigentlich verblüfft, dass GitHub selbst immer noch keine offizielle App mit Push bereitgestellt hat.

_{Gesendet mit GitHawk}

Das Hauptproblem, das ich voraussehe, sind nur Ratenbegrenzungen, wir sind schon ziemlich nahe dran, es zu erreichen, nur weil wir ein aktiver Benutzer in der App sind! Das ist ohne Abfrage für Benachrichtigungen alle paar Minuten! Technisch ist es nicht allzu schwierig, aber wir müssten herausfinden, wie das funktionieren würde, ohne die Github-App zu sperren!

_{Gesendet mit GitHawk}

Ich verwende CodeHub für Benachrichtigungen. Ich bin mir nicht sicher, wie sie das machen, aber ich musste bezahlen, um die Funktion zu aktivieren. Ich muss nur daran denken, stattdessen GitHawk zu öffnen.

Bitte schön, es ist auch Open Source: CodeHub-Push

_{Gesendet mit GitHawk}

Ich frage mich, ob wir eine zweite Github-App nur für Benachrichtigungen einrichten könnten? Es würde erfordern, dass sich die Leute zweimal anmelden, aber würde das Problem der Ratenbegrenzung abgemildert?

_{Gesendet mit GitHawk}

Oder ist es nur so, dass wir es ausprobieren und sehen, ob es für die meisten überhaupt ein Problem ist? Eine bessere Nachverfolgung könnte praktisch sein – was wäre, wenn wir Fabric verwenden und ein Ereignis posten, wenn ein Benutzer das Ratenlimit ausgeschöpft hat, damit wir wissen, wann es ein Problem gibt? Auch hier macht es keinen Sinn, alternative Lösungen für ein Nicht-Existenz-Problem zu finden!

_{Gesendet mit GitHawk}

Woher kommen die meisten API-Aufrufe? Ist es möglich, sie zu optimieren, indem einige Daten zwischengespeichert werden?

_{Gesendet mit GitHawk}

Wenn man sich CodeHub-Push ansieht (danke @schrodincat !), scheint es, dass ihr Ansatz _pro Benutzer_ (ich, du usw.) und nicht _pro App_ (GitHawk) ist, also sollte die Ratenbegrenzung kein Problem sein?

Die Rate-Limit-Probleme, die ich gesehen habe, sind pro Benutzer 😔 wir sollten, und definitiv in der Vergangenheit, uns mit der Optimierung von Dingen befassen, aber letztendlich, wenn Sie 50 Benachrichtigungen öffnen, sind das viele API-Aufrufe! Da können wir nicht viel machen!

_{Gesendet mit GitHawk}

@rnystrom Erhalten wir bei dieser Zusammenführung Push-Benachrichtigungen von GitHawk auf iOS für Updates in unseren Repos auf Github?

@mesqueeb alles, wofür Sie auf der Website eine Benachrichtigung erhalten.