2016-09-20 4 views
2

Ich entwickle eine App, die Daten von der API empfängt und sie in einer Art Cache speichern soll, um sie an UI-Ansichten zu binden. Diese Daten werden auch für mehrere Ansichten verwendet, und jede Änderung sollte in Ansichten widergespiegelt werden. Was ist die beste und schnellste Option für NativeScript? Wäre toll, etwas Ähnliches wie SenchaTouch Stores/Models mit Proxy zu haben. Vielen Dank.NativeScript: bester persistenter Cache/Speicher mit View-Datenbindung

Antwort

1

Erstellen Sie einfach ein Singleton und fordern/importieren Sie das, genau wie in jeder anderen Javascript-App. Solange Sie Ihre Daten in einer Observable halten und Änderungen daran werden sofort in den Ansichten wiedergegeben.

z.

Datei: myData.js

var observableArray = require("data/observable-array"); 
var observable = require("data/observable"); 
var DATA = new observable.Observable({ 
    something: 'a value here', 
    somethingElse: 1 
    somethingMany: new observableArray.ObservableArray(['a', 'b', 'c']) 
}); 

exports.getData = function() { return DATA; }; 
exports.fetchFromAPI = function() { /* something that fetches and updates DATA */ } 

in einer beliebigen Datei, wo Sie diese Daten lesen möchten:

var data = require("./myData.js"); 
console.log(data.getData()); 

Lesen Sie mehr über Observables in NativeScript

+0

Das ist, was ich im Moment tun. Das Problem ist, dass ich dies ständig mit jedem dauerhaften Speicher synchronisieren muss. Ich benutze das SQLite-Plugin dafür. Aber der ganze Prozess ist ziemlich anspruchsvoll. Ich muss die Typen prüfen und konvertieren. Um SQLite-Plugin zu verwenden, schrieb ich einen benutzerdefinierten SQL-Abfrageadapter. Ich mag die Implementierung nicht wirklich. Also, ich suche eine fertige Lösung wie in jedem anderen Frameworks. Ich kam von Appcelarator und Sencha Touch-Entwicklung, wo all das ziemlich gut implementiert ist ... – terreb

+0

Afaik gibt es kein Out-of-the-Box-Paket, um dies für Sie in einer NativeScript-Umgebung zu tun. Es ist jedoch nicht so eine große Sache zu implementieren. In Ihrem Fall können Sie den App-Status (im obigen Beispiel "DATA") einfach als Master behandeln und dann alle Änderungen an einem persistenten Speicher speichern, indem Sie dem Ereignis "propertyChangeEvent" einen Ereignis-Listener hinzufügen und dann speichern. –

+0

Und nochmal, das ist was ich schon mache :) Ich bin vor kurzem zu weakEvenListeners gewechselt, allerdings wegen meiner Bedenken, ob NS Müll richtig sammelt. Ich habe 20 verschiedene "Läden" und viele "Nachkommen" von ihnen, die an Ansichten binden. Während der Arbeit mit der App sehe ich, wie die Speichernutzung schnell wächst. Es ist sogar vorher abgestürzt, aber als ich einige Optimierungen implementiert habe, hat es damit aufgehört. Aber ich bin immer noch nicht glücklich mit all dem Chaos und würde es lieben, zumindest eine Drittanbieter-Lösung zu sehen. – terreb