Githawk: Notificações via push

Isso exigiria muito trabalho em termos de autenticar usuários e armazenar isso em um servidor da Web pesquisando regularmente novas notificações para enviar uma notificação - acho que teremos mais sorte com a busca em segundo plano nos dispositivos, o que eu sei há um bilhete para!

Mas adoraria isso

Sim, eu sinto você. Acho que uma boa solução temporária seria um trabalho de bg que identifica o aplicativo. Também poderíamos agendar notificações push locais com o trabalho bg! Mas para mim, pessoalmente, os empurrões seriam irritantes.

No entanto, poderíamos colocar tudo isso em configurações.

Um servidor de pesquisa é desejado por mais longo prazo? Eu fiz um exatamente para essa finalidade uma vez 😅 . Não tenho certeza de quão sã foi minha abordagem, mas dar outra olhada seria interessante.

Às vezes (como nos serviços de pesquisa) costumo considerar o UX para entender qual solução seria melhor.

Para mim, a pergunta a ser respondida seria quanto tempo as pessoas passam no aplicativo para uma única sessão. Porque se, como eu, são alguns minutos de cada vez, a pesquisa provavelmente seria um exagero tbh.

Estou 100% com ele buscas de fundo embora. Eu tenho feito testes completos com isso nas últimas duas semanas e achei bastante confiável. Acionando quase a cada hora com meu aplicativo que estou usando algumas vezes ao dia.

Eu acho que é uma solução viável a longo prazo também.

Parece-me que o objetivo é saber quando há novas notificações quando NÃO estou usando o aplicativo. Os aplicativos ficam abertos apenas por cerca de 10 minutos (se você solicitar) de qualquer maneira. Mas quando você não o faz, o sistema parece dar a você uma prioridade de fundo melhor em meus próprios testes.

Notas que encontrei na busca em segundo plano. (Alguns de um colega da Apple)
A busca em segundo plano é em grande parte não documentada, no entanto, algumas das dicas que encontrei são coisas como tempos de inicialização do aplicativo e uso de energia.

Ao adicionar este env var, você verá várias estatísticas quando seu aplicativo for iniciado no console de depuração do Xcode. Pode ser realmente útil. Eles sugerem que seu aplicativo deve ser capaz de iniciar em menos de 400 ms, eu costumo apontar para 2-300 pessoalmente.

O uso de energia obviamente pode ser verificado no Xcode ou no Instruments.

A API de busca em segundo plano (como tenho certeza que você sabe) tem um completeHandler que você precisa chamar quando terminar. Anteriormente, eu tinha apenas chamado com .newData em todos os casos. Isso foi um erro. Não tenho certeza exatamente como ele classifica isso, mas é importante chamar .noData quando não havia nenhum. Melhora os intervalos de busca.

O principal é manter esses números baixos. Se o aplicativo puder ser iniciado rapidamente, usar pouca bateria e terminar rapidamente, o sistema tende a dar mais tempo de fundo.

Novamente, isso está em meus próprios testes limitados, mas trabalhei em vários aplicativos com implementações de busca em segundo plano bem-sucedidas ao longo dos anos.

+1 que o objetivo é selar o aplicativo e, opcionalmente, notificar quando houver novidades quando não estiver no aplicativo. Vamos ficar com as tarefas bg por enquanto.

Emblemas adicionados, mas vou deixar isso aberto por enquanto para acompanhar a adição de notificações locais. Acho que seria legal. Semi complicado porque temos que rastrear o que já foi notificado. Também é provável que eles sejam agrupados em um que diga "4 novas notificações".

Talvez possamos até dividir as notificações por repositório?

@rnystrom muito legal

pergunta: o app ficou com um badge na tela inicial mas quando abri ele apareceu o ícone :tada: e tive que puxar para atualizar.. é assim que funciona atualmente?

Também estou com o emblema desligado, mas ainda estou conseguindo aparecer 😔

@Sherlouk você pode desativá-lo com Configurações / Notificações / Freetime .. desmarque Permitir notificações

Eu entendo isso, mas como proprietário de um aplicativo, ter usuários desativá-lo nesse nível é muito ruim, caso você queira aproveitar as notificações de outras maneiras mais adiante - Deve ter um melhor controle no aplicativo sobre essa configuração.

Há também uma alternância que é redigida, ou pelo menos interpretada por mim, como "Desativar o emblema" - que não funciona

Certo, eu queria que você corrigisse isso enquanto isso :)

@Sherlouk , então você desabilitou nas configurações, mas ainda está com badging? Ah merda, acho que sei por quê. Fixará.

Notificações locais seriam muito bem-vindas. Atualmente, uso o aplicativo (pago) CodeHub para receber notificações e, em seguida, tenho que lembrar de não tocá-las, mas de abrir o GitHawk.

+1 para notificações locais.

Estou absolutamente 100% para notificações push reais do lado do servidor. Eu sei que o GitHub não é um serviço de mensagens, mas o tempo de reação ainda é importante e a resposta rápida pode ajudar a acelerar as conversões e, portanto, resolver problemas mais rapidamente. Na verdade, estou perplexo. O próprio GitHub ainda não forneceu um aplicativo oficial com push.

_{Enviado com GitHawk}

O principal problema que prevejo são apenas os limites de taxa, já chegamos bem perto de atingi-lo apenas por ser um usuário ativo no aplicativo! Isso sem pesquisa de notificações a cada poucos minutos! Tecnicamente, não é muito difícil, mas precisaríamos descobrir como isso funcionaria sem bloquear o aplicativo github!

_{Enviado com GitHawk}

Eu uso o CodeHub para notificações. Não tenho certeza de como eles fazem isso, mas tive que pagar para ativar o recurso. Eu só tenho que lembrar de abrir o GitHawk em vez disso.

Aqui está, também é de código aberto: CodeHub-Push

_{Enviado com GitHawk}

Gostaria de saber se poderíamos configurar um segundo aplicativo github apenas para notificações? Isso exigiria que as pessoas fizessem login duas vezes, mas atenuaria o problema do limite de taxa?

_{Enviado com GitHawk}

Ou é apenas um caso de tentarmos e ver se é mesmo um problema para a maioria? Um melhor rastreamento sobre isso pode ser útil - e se usarmos fabric e postarmos um evento quando um usuário atingiu o limite de taxa máximo para sabermos quando é um problema? Novamente, não adianta colocar soluções alternativas para um problema de não existência!

_{Enviado com GitHawk}

De onde vem a maioria das chamadas de API? É possível otimizá-los armazenando alguns dados em cache?

_{Enviado com GitHawk}

Olhando para o CodeHub-Push (obrigado @schrodincat !), parece que a abordagem deles é _per-user_ (eu, você, etc.) não _per-app_ (GitHawk), então a limitação de taxa não deve ser um problema?

Os problemas de limite de taxa que tenho visto são por usuário 😔 devemos, e definitivamente no passado, procurar otimizar as coisas, mas, no final das contas, se você abrir 50 notificações, são muitas chamadas de API! Não podemos fazer muito sobre isso!

_{Enviado com GitHawk}

@rnystrom Com essa mesclagem, receberemos notificações push do GitHawk no iOS para qualquer atualização em nossos repositórios no Github?

@mesqueeb qualquer coisa que você receber uma notificação no site.