Githawk: Notificaciones push

Esto requeriría bastante trabajo en términos de tener que autenticar a los usuarios y almacenarlo en un servidor web que sondee periódicamente para obtener nuevas notificaciones para enviar una notificación; creo que tendremos más suerte con la búsqueda en segundo plano en los dispositivos, lo cual sé. hay un boleto para!

Aunque me encantaría esto

Sí, te siento. Creo que una buena solución de temperatura media sería un trabajo de bg que identifique la aplicación. ¡Incluso podríamos programar notificaciones automáticas locales con el trabajo bg también! Pero para mí personalmente los empujones serían molestos.

Sin embargo, podríamos poner todo esto en la configuración.

¿Se desea un servidor de sondeo a más largo plazo? Una vez hice uno exactamente para este propósito 😅. No estoy seguro de cuán sensato fue mi enfoque, pero echarle otro vistazo sería interesante.

A veces (como con los servicios de encuestas) tiendo a considerar la UX para entender qué solución sería la mejor.

Para mí, la pregunta a responder sería cuánto tiempo pasan las personas en la aplicación para una sola sesión. Porque si, como yo, son unos pocos minutos a la vez, el sondeo probablemente sería excesivo, tbh.

Sin embargo, estoy 100% de acuerdo con las búsquedas de antecedentes. He estado haciendo pruebas exhaustivas con esto durante las últimas semanas y descubrí que es bastante confiable. Activando casi cada hora más o menos con mi aplicación que estoy usando un par de veces al día.

Creo que también es una solución viable a largo plazo.

Me parece que el objetivo es saber cuándo hay nuevas notificaciones cuando NO estoy usando la aplicación. Las aplicaciones solo permanecen abiertas durante unos 10 minutos (si lo solicita) de todos modos. Pero cuando no lo hace, el sistema parece darle una mejor prioridad de fondo en mis propias pruebas.

Notas que encontré en la búsqueda de fondo. (Algunos de un compañero de Apple)
La recuperación en segundo plano no está documentada en gran medida, sin embargo, algunos de los consejos que he encontrado son cosas como los tiempos de inicio de la aplicación y el uso de energía.

Al agregar esta variable env, verá un montón de estadísticas cuando su aplicación se inicie en la consola de depuración de Xcode. Puede ser realmente útil. Sugieren que su aplicación debería poder iniciarse en menos de 400 ms. Tiendo a apuntar a 2-300 personalmente.

Obviamente, el uso de energía se puede verificar desde Xcode o Instruments.

La API de recuperación en segundo plano (como estoy seguro de que sabe) tiene un controlador de finalización al que debe llamar cuando haya terminado. Anteriormente, en general, solo lo había llamado con .newData en todos los casos. Esto fue un error. No estoy seguro exactamente de cómo clasifica esto, pero es importante llamar a .noData cuando no había ninguno. Mejora los intervalos de recuperación.

Lo principal es mantener estos números bajos. Si la aplicación se puede iniciar con bastante rapidez, usar poca batería y finalizar con bastante rapidez, el sistema tiende a brindarle más tiempo de fondo.

Nuevamente, esto está en mi propia prueba limitada, pero he trabajado en varias aplicaciones con implementaciones exitosas de búsqueda en segundo plano a lo largo de los años.

+1 que el objetivo es identificar la aplicación y, opcionalmente, notificar cuando hay cosas nuevas cuando no está en la aplicación. Sigamos con las tareas bg por ahora.

Se agregaron insignias, pero dejaré esto abierto por ahora para realizar un seguimiento de la adición de notificaciones locales. Creo que sería genial. Semi complicado porque tenemos que rastrear lo que ya se ha notificado. También es probable que los agrupe en uno que diga "4 notificaciones nuevas".

¿Quizás incluso podamos dividir las notificaciones por repositorio?

@rnystrom muy bueno

pregunta: la aplicación obtuvo una insignia en la pantalla de inicio, pero cuando la abrí, apareció el icono :tada: y tuve que tirar para actualizar... ¿es así como funciona actualmente?

También tengo la insignia apagada, pero todavía me aparece 😔

@Sherlouk , ¿puedes apagarlo con Configuración/Notificaciones/Tiempo libre? Desmarca Permitir notificaciones.

Lo entiendo, pero como propietario de una aplicación, hacer que los usuarios la apaguen en ese nivel es realmente malo en caso de que desee aprovechar las notificaciones de otras maneras más adelante. Debería tener un mejor control en la aplicación sobre esa configuración.

También hay un conmutador que está redactado, o al menos interpretado por mí, como "Desactivar la insignia", que no funciona

Correcto, quise que arreglaras esto mientras tanto :)

@Sherlouk , ¿entonces lo disBled en la configuración pero todavía está marcado? Ah, mierda, creo que sé por qué. Arreglará.

Las notificaciones locales serían muy bienvenidas. Actualmente uso la aplicación CodeHub (de pago) para recibir notificaciones y luego tengo que recordar no tocarlas, sino abrir GitHawk.

+1 para notificaciones locales.

Estoy absolutamente 100% a favor de las notificaciones push reales del lado del servidor. Sé que GitHub no es un servicio de mensajería, pero el tiempo de reacción sigue siendo importante y una respuesta rápida puede ayudar a acelerar las conversiones y, por lo tanto, resolver los problemas más rápido. De hecho, estoy desconcertado de que GitHub todavía no haya proporcionado una aplicación oficial con push.

_{Enviado con GitHawk}

El problema principal que preveo son solo los límites de velocidad, ¡ya hemos estado bastante cerca de alcanzarlo solo con ser un usuario activo en la aplicación! ¡Eso es sin encuestas de notificaciones cada pocos minutos! Técnicamente no es demasiado difícil, ¡pero tendríamos que averiguar cómo funcionaría sin bloquear la aplicación github!

_{Enviado con GitHawk}

Uso CodeHub para las notificaciones. No estoy seguro de cómo lo hacen, pero tuve que pagar para activar la función. Solo tengo que recordar abrir GitHawk en su lugar.

Aquí tienes, también es de código abierto: CodeHub-Push

_{Enviado con GitHawk}

Me pregunto si podríamos configurar una segunda aplicación de github solo para notificaciones. Requeriría que las personas inicien sesión dos veces, pero ¿mitigaría el problema del límite de velocidad?

_{Enviado con GitHawk}

¿O es solo un caso de que lo probemos y veamos si es un problema para la mayoría? Un mejor seguimiento de esto podría ser útil: ¿qué sucede si usamos fabric y publicamos un evento cuando un usuario alcanzó el límite de frecuencia para que sepamos cuándo se trata de un problema? Nuevamente, ¡no tiene sentido poner soluciones alternativas a un problema de inexistencia!

_{Enviado con GitHawk}

¿De dónde provienen la mayoría de las llamadas a la API? ¿Es posible optimizarlos almacenando en caché algunos datos?

_{Enviado con GitHawk}

Mirando CodeHub-Push (¡gracias @schrodincat !) Parece que su enfoque es _por usuario_ (yo, usted, etc.) no _por aplicación_ (GitHawk), por lo que la limitación de velocidad no debería ser un problema.

Los problemas de límite de velocidad que he estado viendo son por usuario 😔 deberíamos, y definitivamente lo hemos hecho en el pasado, buscar optimizar las cosas, pero en última instancia, si abre 50 notificaciones, ¡son muchas llamadas API! ¡No hay mucho que podamos hacer al respecto!

_{Enviado con GitHawk}

@rnystrom Con esta combinación, ¿ recibiremos notificaciones automáticas de GitHawk en iOS para cualquier actualización en nuestros repositorios en Github?

@mesqueeb cualquier cosa para la que reciba una notificación en el sitio web.