Arquitetura de aplicativo android de programação reativa

5

Eu vou criar um aplicativo android de mercado de ações. Cotações de ações mudam a cada poucos segundos, então, para manter o aplicativo atualizado, decidi implementar um design funcional reativo.

Meu design IDEAL seria:

  • Toda vez que o servidor tem um novo valor para um estoque, o aplicativo recebe os novos dados. Finalmente, os dados são exibidos para o usuário.

No entanto, meu problema é que minha fonte de dados de estoque é uma API REST (por exemplo, do Yahoo). Com uma API REST, acho que a parte "notificar o aplicativo" do meu design não será facilmente implementada.

Eu pensei em fazer:

  • Programar uma chamada Api a cada X segundos usando Retrofit + RxJava. Enquanto isso parece ser o caminho mais simples, há duas coisas que eu não gosto:

1) Vou baixar muito mais dados do que o necessário, já que não sei o que as ações mudaram seu valor, vou ter que buscar todas elas.

2) Isso não é realmente "programação reativa". De alguma forma eu sinto que o servidor deve "empurrar" os dados para o cliente e não o contrário.

Você pode me dar algumas dicas de como eu implementaria o design "Ideal" que descrevi acima?

    
por Javier Ventajas Hernández 18.07.2016 / 02:29
fonte

2 respostas

2

Everytime that the server has a new value for a stock, the app is passed the new data. Finally, the data is displayed to the user.

Isso deixa muito fora da história. Isso é mais um caso de uso do que um design.

Existem várias maneiras de abordar esse problema. São suas limitações fundamentais que realmente guiam o design. Eu estarei fazendo suposições sobre quais são suas limitações.

Provavelmente você não possui o servidor que é a fonte de dados de estoque. Você simplesmente tem uma API de descanso à qual você pode se conectar. Provavelmente você está limitado em quanto você pode baixar e com que frequência você pode se conectar.

Schedule an Api call every X seconds

Isso é chamado de polling. Tem severas limitações sobre os eventos, mas pode funcionar bem se for bem feito.

1) I'll be downloading much more data than is necessary, since I don't know what stocks have changed their value, I will have to fetch all of them.

Isso depende inteiramente das limitações da API. Se a API realmente não permitir que você pergunte sobre um determinado estoque, mas insiste em enviar a você o ticker inteiro, então sim, isso é verdade.

2) This is not really "reactive programming". I somehow feel that the server should "push" the data to the client and not the other way around.

O polling, feito corretamente, é realmente o que os eventos realmente são. Seria um projeto horrível se, a cada x segundos, todos os usuários acessassem a API e pesquisassem a lista de marcadores do estoque com o qual se preocupavam e verificassem se o preço havia se movido. Isso é muito trabalho e movimentação sem sentido de dados.

Se a API não permitir que você faça algo mais avançado, clique no ícone inteiro ao ligar para ele. Recomendo a criação de um servidor próprio. Seu único servidor irá acessar a API do seu servidor, obter o código inteiro, fazer isso a cada x segundos, mas será a única coisa que fará isso.

O seu servidor permitirá que os usuários se registrem como observadores de estoques e toda vez que um estoque for alterado, o seu servidor fará um loop de ações que registrará os observadores e enviará uma notificação para eles.

Você precisará de alguns limites de tempo e limitações razoáveis para se registrar como observador ou será alvo de ataques de negação de serviço.

Assim, as notificações podem ser limitadas tanto a ações de interesse quanto a movimentos de preços de interesse, e com tempos limite, a observadores ainda interessados.

Isso também permite que você envie notificações de qualquer forma que desejar, UDP, TCP, SMS, e-mail, telefonemas, cartões postais.

    
por 18.07.2016 / 03:45
fonte
0

Você pode fazer o polling (talvez com algum batching / caching para vários clientes) no lado do servidor. Para notificar os aplicativos para dispositivos móveis sobre alterações, você pode usar o Google Cloud Messaging e economizar uma certa largura de banda para os clientes.

    
por 13.02.2017 / 17:43
fonte