I tried use the tutorial below to implement observer on my code:
https://www.joshmorony.com/building-mobile-apps-with-ionic-2/observables-in-ionic2.html
but there is no next method for observer type:
this.checklistObserver.next(true);
when I put this line in the code I get a blank screen…
After a search I found a explanation about RXJS observer and the new method was named onNext() but no success.
my code:
import { Injectable } from '@angular/core';
import { Http, Response, Headers, RequestOptions } from '@angular/http';
import {Observable} from 'rxjs/Observable';
//import {Observable} from 'rxjs/Rx';
import {Observer} from 'rxjs/Observer';
import { LoginProvider } from "../../providers/login/login";
import { SQLite, SQLiteObject } from '@ionic-native/sqlite';
import 'rxjs/add/operator/do';
import 'rxjs/add/operator/map';
import 'rxjs/add/operator/catch';
/*
Generated class for the ItemsProvider provider.
See https://angular.io/docs/ts/latest/guide/dependency-injection.html
for more info on providers and Angular DI.
*/
@Injectable()
export class ItemsProvider {
items: Array<Item>;
checkitems: any;
checkitemsObserver: any;
constructor(public http: Http, private sqlite: SQLite, private login: LoginProvider) {
console.log('Hello ItemsProvider Provider');
this.items = [];
this.checkitems = Observable.create(observer => {
this.checkitemsObserver = observer;
});
this.requestServer();
}
checkitemsUpdates(): Observable<any> {
return this.checkitems;
}
}
requestServer() {
/* CODE THAT GET DATA FROM SERVER AND UPDATE DATA IN SQLITE DATABASE - was omitted */
this.checkitemsObserver.onNext(this.items); // the data was new items
}
}
checklistitemsObserver
is also defined as any
. I would try and define it as having a proper type.
@AaronSterling the questions is: Why the .next doesn’t work inside a provider?
@SigmundFroyd thank you… I changed to Observer, but the problem is still there… one thing I did not mention is the observer code is in a provider… when I change to a model the .next works. Is there a problem running inside a provider? whether yes… why http.get works?
I have yet to see a situation where Observable.create()
is the best option. Please describe what you are actually trying to achieve here.
The idea is: A list of items can be updated by server or local database… and a page shows the items… for example: User open app and the app request a list of items from server, update the database and shows the list of items updated… when user add a item, the item is inserted in local database, sent to the server and the list of items is updated… when server discover new attribute for the item it send a message to app and the list is updated. There are 3 ways to update the list on screen… 1. a app request for updates, 2. user updates, 3. server send new updates.
what I did: A Item model (to get data from database and make requests to the server, the object responsible for the consistency of the items)… a server provider (a interface to the server)… and the page that observe item model to show the changes.
All of that seems reasonable. I think some flavor of Subject
would be more straightforward to work with than a hand-crafted Observable
, though.
@rapropos thank you… I will try a Subject instead Observable 
I didn’t know the diference between subject and observable… based in this link subject will be a better choice than observable (considering that Items observes/receives/listening states/changes from server and database and is observed by external object. Am I correct?).
@SigmundFroyd You are correct… I removed the old code and add a new one, with explicit Subject type and works… but why in a model/page set variable with <any>
works and inside a provider doesn’t work call the method .next()? And Why when I declared Observer<any>
(like you said) doesn’t work but Subject<any>
works???
I would agree with this assessment. In order for your provider to both send and receive updates, to do so with a raw Observable
would require you to more or less reinvent what a Subject
would already give you. The primary difference between the two main flavors is that BehaviorSubject
s have a well-defined initial state, whereas ReplaySubject
s can start in a sort of “idk nothing to report yet” limbo state, which is sometimes useful.
1 Like