2015-10-26 1 views
0

Voici un cas d'utilisation que j'essaie de résoudre avec rxJava et Dagger2 dans mon application android.La tâche du moniteur rxJava jusqu'à complète

  1. Charge enregistrement détails
  2. Vérifiez serveur principal si HLS transcode existe REST (Appel)
    • Si existe, surveiller jusqu'à ce processus est 100% (REST Appel toutes les n secondes jusqu'à 100%)
    • Si n'existe pas, ne pas appeler processus de surveillance

Les appels REST sont injectés à travers un composant poignard. Je me bats avec la configuration de rxJava pour créer un moniteur qui va actualiser l'appel REST jusqu'à ce que le processus soit à 100% et s'arrête, ou l'utilisateur recule juste l'écran.

Je ne suis pas sûr que je pose cette question correctement, donc si une mise à jour est nécessaire, s'il vous plaît faites le moi savoir.

Voici un lien vers mon présentateur sur github repo. Cela charge les données et doit déclencher les mises à jour vers le fragment responsable de l'affichage des données.

MISE À JOUR: 26/10/2015 PM Je sais que c'est probablement un hack, mais voilà comment je mis à exécution les appels retardés répéter:

@Override 
protected Observable buildUseCaseObservable() { 

    Action1<List<LiveStreamInfo>> onNextAction = new Action1<List<LiveStreamInfo>>() { 

     @Override 
     public void call(List<LiveStreamInfo> liveStreamInfos) { 

      try { 
       Thread.sleep(5000); 
      } catch(InterruptedException e) { } 

     } 

    }; 

    return this.contentRepository.liveStreamInfos(this.filename) 
      .repeat(Schedulers.io()) 
      .doOnNext(onNextAction); 
} 

Ensuite, dans la méthode d'appel qui établit un subsriber:

private void getProgramDetails() { 

    this.getProgramDetailsUseCase.execute(new ProgramDetailsSubscriber()); 

} 

Et l'abonné:

private final class LiveStreamInfosListSubscriber extends DefaultSubscriber<List<LiveStreamInfo>> { 

    @Override 
    public void onCompleted() { 
     ... 
    } 

    @Override 
    public void onError(Throwable e) { 
     ... 
    } 

    @Override 
    public void onNext(List<LiveStreamInfo> liveStreamInfos) { 

     if(null != liveStreamInfos && !liveStreamInfos.isEmpty()) { 

      ProgramDetailsPresenter.this.showLiveStreamDetailsInView(liveStreamInfos.get(0)); 

      if(liveStreamInfos.get(0).getPercentComplete() == 100) { 

       ProgramDetailsPresenter.this.getLiveStreamsListUseCase.unsubscribe(); 

      } 

     } 

    } 

} 

l'abonné se désinscrit de l'observable une fois que le pourcentage atteint atteint 100%, annulant tous les appels futurs. L'avantage ici est que cet abonné se déclenche lorsqu'un utilisateur initie le transcodage, en créant le flux en direct, à partir de l'application, ou qu'il le récupère du backend lorsqu'il est initié à partir de l'interface Web principale.

Répondre

0

Que diriez-vous d'ajouter .retry() avec combien de fois vous voulez réessayer et une grande valeur pour le nombre de tentatives de votre observateur rx. Ensuite, il suffit de vous désabonner de votre source observable lorsque vous quittez votre fragment pour arrêter l'interrogation.

+0

Si j'ajoute une nouvelle tentative au get initial, celui-ci émettra alors cet objet qui va forcer un redessin des éléments sur l'écran. Qu'en est-il de combiner avec un filtre pour restreindre cela? – dmfrey

+0

Ah je vois. Oui, un filtre semble fonctionner. En aparté, avez-vous la possibilité de modifier le code côté serveur? Si oui, avez-vous envisagé de modifier la conception du point de terminaison REST que vous interrogez toutes les n secondes pour utiliser l'interrogation de comète/inversion? Cela rendra votre serveur plus évolutif et améliorera les performances de votre client Android. – davehenry

+0

le backend est [mythtv] (http://mythtv.org). Je ne suis pas un développeur de backend, ou je l'essayerais. Ce serait génial de ne pas avoir à interroger du tout et de laisser le backend s'occuper de ça. Cela étant dit, mythtv est open source, donc, je pourrais y jeter un coup d'œil. C'est juste le temps. – dmfrey