Githawk: Notifications push

Cela nécessiterait beaucoup de travail en termes d'authentification des utilisateurs et de stockage dans un serveur Web interrogeant régulièrement les nouvelles notifications afin d'envoyer une notification - je pense que nous aurons plus de chance avec la récupération d'arrière-plan sur les appareils, ce que je sais il y a un billet pour !

J'adorerais ça cependant

Ouais, je te sens. Je pense qu'une bonne solution intermédiaire temporaire serait un travail bg qui badge l'application. Nous pourrions même programmer des notifications push locales avec le travail bg ! Mais pour moi personnellement, les poussées seraient ennuyeuses.

Cependant, nous pourrions mettre tout cela dans les paramètres.

Un serveur de vote est-il souhaité à plus long terme ? J'en ai fait un exactement dans ce but une fois 😅 . Je ne sais pas à quel point mon approche était sensée, mais y jeter un autre coup d'œil serait intéressant.

Parfois (comme avec les services de sondage), j'ai tendance à considérer l'UX afin de comprendre quelle solution serait la meilleure.

Pour moi, la question à laquelle il faut répondre serait combien de temps les gens passent-ils dans l'application pour une seule session. Parce que si, comme moi, c'est quelques minutes à la fois, les sondages seraient probablement exagérés.

Je suis à 100% avec les recherches d'arrière-plan. J'ai fait des tests approfondis avec cela au cours des deux dernières semaines et je l'ai trouvé assez fiable. Déclenchement presque toutes les heures environ avec mon application que j'utilise plusieurs fois par jour.

Je pense que c'est aussi une solution viable à long terme.

Il me semble que l'objectif est de savoir quand il y a de nouvelles notifications lorsque je n'utilise PAS l'application. Les applications ne restent ouvertes que pendant environ 10 minutes (si vous le demandez) de toute façon. Mais lorsque vous ne le faites pas, le système semble vous donner une meilleure priorité d'arrière-plan dans mes propres tests.

Notes que j'ai trouvées sur la récupération en arrière-plan. (Certains d'un camarade d'Apple)
La récupération en arrière-plan est en grande partie non documentée, mais quelques-uns des conseils que j'ai rencontrés sont des choses comme les heures de lancement des applications et la consommation d'énergie.

En ajoutant cette variable d'environnement, vous verrez un tas de statistiques lorsque votre application sera lancée dans la console de débogage de Xcode. Cela peut être vraiment utile. Ils suggèrent que votre application devrait pouvoir se lancer en moins de 400 ms. J'ai tendance à viser 2 à 300 personnellement.

La consommation d'énergie peut évidemment être vérifiée à partir de Xcode ou d'Instruments.

L'API de récupération en arrière-plan (comme vous le savez sûrement) a un CompletionHandler que vous devez appeler lorsque vous avez terminé. Auparavant, je l'avais principalement appelé avec .newData dans tous les cas. C'était une erreur. Je ne sais pas exactement comment il classe cela, mais il est important d'appeler .noData quand il n'y en avait pas. Améliore les intervalles de récupération.

L'essentiel est de maintenir ces chiffres bas. Si l'application peut être lancée assez rapidement, utiliser peu de batterie et se terminer assez rapidement, le système a tendance à vous donner plus de temps d'arrière-plan.

Encore une fois, cela fait partie de mes propres tests limités, mais j'ai travaillé sur plusieurs applications avec des implémentations réussies de récupération en arrière-plan au fil des ans.

+1 que l'objectif est de badger l'application et éventuellement de notifier lorsqu'il y a de nouvelles choses lorsqu'elles ne sont pas dans l'application. Restons avec les tâches bg pour l'instant.

Badges ajoutés mais je vais laisser cela ouvert pour le moment pour suivre l'ajout de notifications locales. Je pense que ce serait cool. Semi compliqué car il faut suivre ce qui a déjà été notifié. Il est également probable de les regrouper en un seul qui dit comme "4 nouvelles notifications".

Peut-être pouvons-nous même diviser les notifications par dépôt ?

@rnystrom très cool

question : l'application a reçu un badge sur l'écran d'accueil, mais lorsque je l'ai ouverte, j'ai obtenu l'icône :tada: et j'ai dû tirer pour actualiser... est-ce la façon dont cela fonctionne actuellement ?

De plus, j'ai désactivé le badge, mais je le reçois toujours 😔

@Sherlouk pouvez-vous l'éteindre avec Paramètres / Notifications / Freetime .. décochez Autoriser les notifications

Je comprends cela, mais en tant que propriétaire d'application moi-même, le fait que les utilisateurs l'éteignent à ce niveau est vraiment mauvais au cas où vous voudriez profiter des notifications d'autres manières plus tard - Devrait avoir un meilleur contrôle dans l'application sur ce paramètre.

Il y a aussi une bascule qui est libellée, ou du moins interprétée par moi, comme "Éteignez le badge" - qui ne fonctionne pas

D'accord, je voulais que vous corrigiez ça en attendant :)

@Sherlouk donc vous l'avez désactivé dans les paramètres mais c'est toujours un badge? Ah merde je crois savoir pourquoi. Réparera.

Des notifications locales seraient les bienvenues. J'utilise actuellement l'application (payante) CodeHub pour recevoir des notifications, puis je dois me rappeler de ne pas les appuyer, mais d'ouvrir GitHawk à la place.

+1 pour les notifications locales.

Je suis absolument à 100% pour les vraies notifications push côté serveur. Je sais que GitHub n'est pas un service de messagerie, mais le temps de réaction est toujours important et une réponse rapide peut aider à accélérer les conversions et donc à résoudre les problèmes plus rapidement. Je suis en fait déconcerté que GitHub lui-même n'ait toujours pas fourni d'application officielle avec push.

_{Envoyé avec GitHawk}

Le principal problème que je prévois concerne uniquement les limites de débit, nous sommes déjà sur le point de l'atteindre simplement en étant un utilisateur actif de l'application ! C'est sans interroger les notifications toutes les quelques minutes ! Techniquement, ce n'est pas trop difficile, mais nous aurions besoin de déterminer comment cela fonctionnerait sans verrouiller l'application github !

_{Envoyé avec GitHawk}

J'utilise CodeHub pour les notifications. Je ne sais pas comment ils font mais j'ai dû payer pour activer la fonction. Je dois juste me rappeler d'ouvrir GitHawk à la place.

Et voilà, c'est aussi open source : CodeHub-Push

_{Envoyé avec GitHawk}

Je me demande si nous pourrions configurer une deuxième application github uniquement pour les notifications ? Cela obligerait les gens à se connecter deux fois, mais atténuerait le problème de limite de débit ?

_{Envoyé avec GitHawk}

Ou s'agit-il simplement de l'essayer et de voir si c'est même un problème pour la plupart ? Un meilleur suivi à ce sujet pourrait être utile - et si nous utilisions Fabric et publions un événement lorsqu'un utilisateur a atteint la limite de débit maximale afin que nous sachions quand c'est un problème ? Encore une fois, inutile de proposer des solutions alternatives à un problème d'inexistence !

_{Envoyé avec GitHawk}

D'où proviennent la plupart des appels d'API ? Est-il possible de les optimiser en mettant en cache certaines données ?

_{Envoyé avec GitHawk}

En regardant CodeHub-Push (merci @schrodincat !), il semble que leur approche soit _par utilisateur_ (moi, vous, etc.) et non _par-application_ (GitHawk), donc la limitation du débit ne devrait pas être un problème ?

Les problèmes de limite de débit que j'ai vus sont par utilisateur 😔 nous devrions, et certainement dans le passé, envisager d'optimiser les choses, mais en fin de compte, si vous ouvrez 50 notifications, cela fait beaucoup d'appels API ! Nous ne pouvons pas faire grand-chose à ce sujet !

_{Envoyé avec GitHawk}

@rnystrom Avec cette fusion, recevrons-nous des notifications push de GitHawk sur iOS pour toute mise à jour de nos dépôts sur Github ?

@mesqueeb tout ce pour quoi vous recevez une notification sur le site.