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
- Charge enregistrement détails
- 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.
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
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
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