Einstieg Daten (DB) extern/Webserver einlesen/speichern

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Thallius schrieb:

    Naja ich weiß nicht. Wenn ich meine ersten Apps schreibe und ich bekomme die Daten von einer SQL DB und habe (was eben sehr wahrscheinlich ist) schon Erfahrung in SQL, dann ist es wesentlich einfacher und schneller die Lösung auch mit SQLite aufzubauen als sich erst in CoreData einzuarbeiten.

    Sehe ich ein.
    Nur wenn du auf Android versuchst erst mal mit Core Data Dinge umzusetzen wirst du nicht weit kommen. Du musst dich erst einmal in SQLite einarbeiten.
    Warst du nicht auch der Meinung, man solle sich vernünftig auf seine Zielplattform vorbereiten statt einfach mit Bekanntem drauf los zu hacken?

    Thallius schrieb:

    Weiterhin sollte man auch nicht vergessen, dass man mit CoreData seine Exchangeability komplett auf den Mac begrenzt. Mit einer SQlite DB bist du wesentlich flexibler was den Austausch und Einsatz auf anderen Plattformen angeht.

    Wenn ich meine Core Data Objekte mit $irgendwas austauschen muss, stopfe ich sie in ein NSData und verschicke sie als serialisierte PLIST. Da gibt es von nahezu jeder Programmiersprache mindestens ein Framework, welches das auseinanderfummelt. Falls nicht ist das Format so gut dokumentiert, dass ich mir das selbst zusammenbaue.

    Wie synchronisierst du deine SQLite Datenbank mit iCloud?
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Lucas de Vil schrieb:

    Thallius schrieb:

    Naja ich weiß nicht. Wenn ich meine ersten Apps schreibe und ich bekomme die Daten von einer SQL DB und habe (was eben sehr wahrscheinlich ist) schon Erfahrung in SQL, dann ist es wesentlich einfacher und schneller die Lösung auch mit SQLite aufzubauen als sich erst in CoreData einzuarbeiten.

    Sehe ich ein.
    Nur wenn du auf Android versuchst erst mal mit Core Data Dinge umzusetzen wirst du nicht weit kommen. Du musst dich erst einmal in SQLite einarbeiten.

    Naja an SQL kommt eigentlich keiner vorbei der irgendwie mal irgendwas mit Programmieren zu tun gehabt hat. Das hat nun absolut nichts mit Android zu tun.


    Warst du nicht auch der Meinung, man solle sich vernünftig auf seine Zielplattform vorbereiten statt einfach mit Bekanntem drauf los zu hacken?

    Jein, ich bin der Meinung man sollte sich machbare Ziele setzen. Wenn ich am Anfang zu all dem neuen das iOS mir abverlangt, auch gleich noch CoreData dazu nehme ist das schon ein ganz schöner Brocken. Kann ich bereits SQL bleibt alles deutlich übersichtlicher.


    Thallius schrieb:

    Weiterhin sollte man auch nicht vergessen, dass man mit CoreData seine Exchangeability komplett auf den Mac begrenzt. Mit einer SQlite DB bist du wesentlich flexibler was den Austausch und Einsatz auf anderen Plattformen angeht.

    Wenn ich meine Core Data Objekte mit $irgendwas austauschen muss, stopfe ich sie in ein NSData und verschicke sie als serialisierte PLIST. Da gibt es von nahezu jeder Programmiersprache mindestens ein Framework, welches das auseinanderfummelt. Falls nicht ist das Format so gut dokumentiert, dass ich mir das selbst zusammenbaue.

    Ich meinte in dem Fall eigentlich auch eher, daß ich bei der Umsetzung der Software auf andere Plattformen den SQL Ansatz ebenfalls benutzen kann.


    Wie synchronisierst du deine SQLite Datenbank mit iCloud?


    Ja das ist echt zum kotzen das Apple das nicht unterstützt.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • entwickler schrieb:

    Ich verstehe deine Frage nicht. Wozu willst du einem Objekt Instanzvariablen geben, die es nicht speichern soll?

    Ich habe zum Beispiel eine Liste in der Datenbank mit „physikalischen Schaltern“ <- Also Schalter, die in der Realität ihre Zustände ändern. Der Zustand der Schalter (kann sich alle paar Sekunden ändern) wird aber nicht gespeichert, sondern immer nur zur Laufzeit erfasst.
    Ja. Ich könnte ein Feld dafür vorsehen, aber das wäre immer auf false, weil ich die Liste nur beim Starten der app lade und auch beim Beenden werden die Zustände wieder „verworfen“. Denn im Moment des Speicherns könnte die sich schon wieder geändert haben.
    Wenn du Daten nicht speichern möchtest, dann lege sie halt nicht als Instanzvariablen an.
    Aber die gehören ja „trotzdem“ zum Model. Wie würdest Du die denn „verwalten“?

    Nach wie vor verstehe ich aber den Anwendungsfall nicht.
    Der Schalter ist für mich jetzt einfach eine Instanz von UISwitch. Wenn ich diesen umschalte, dann merkt der Schalter sich ja seinen Zustand - speichert in also.
    Wenn ich den Schalter weg packe, dann packe ich ihn immer mit seinem Zustand weg.
    (Geh in den Baumarkt, schau dir die Kippschalter an, kipp einen Schalter und leg das Ding weg: es behält seinen Zustand.)

    Wenn du den Schalter nicht speichern willst, dann gehört er auch nicht zum Datenmodell.
    Datenmodell und Objektmodell brauchen ja nicht deckungsgleich sein.

    C-Quellcode

    1. //Datenmodell in oder im Core Data Model:
    2. // Schaltertabelle
    3. // | Artikelnummer | Hersteller | Art | Maximal zulässige Spannung | feuchtraumgeeignet |
    4. // Objektmodell in Objective-C
    5. @interface Schalter : NSManagedObject
    6. @dynamic NSNumber * artikelnummer;
    7. @dynamic NSString * hersteller;
    8. @property TypeObject* art; // Im Modell als 'Transformable' gesetzt
    9. @dynamic NSNumber* maximalZulaessigeSpannung;
    10. @dynamic BOOL istFeuchtraumgeeignet;
    11. @property BOOL istAktiv;
    12. - (void)anschalten;
    13. - (void)ausschalten;
    14. @end
    Alles anzeigen


    Es mag sein, dass 'transient' etwas Ähnliches tut.

    Thallius schrieb:

    Naja an SQL kommt eigentlich keiner vorbei der irgendwie mal irgendwas mit Programmieren zu tun gehabt hat. Das hat nun absolut nichts mit Android zu tun.

    Also seit ich für den Mac programmiere hatte ich mit SQL überhaupt nichts zu tun. Die Art der Datenhaltung wird auch immer unwichtiger.
    Und neben SQL gibt es auch vernünftige Datenbankmanagementsysteme, mit denen Mensch sich beschäftigen kann.

    Thallius schrieb:

    Jein, ich bin der Meinung man sollte sich machbare Ziele setzen. Wenn ich am Anfang zu all dem neuen das iOS mir abverlangt, auch gleich noch CoreData dazu nehme ist das schon ein ganz schöner Brocken. Kann ich bereits SQL bleibt alles deutlich übersichtlicher.

    Das halte ich für einen Trugschluss. Spätestens wenn deine Anwendung gewachsen ist meckerst du über die beschissene Integration von iOS mit SQL und bemerkst gar nicht, dass du von Anfang an den falschen Weg gegangen bist.

    Thallius schrieb:

    Ich meinte in dem Fall eigentlich auch eher, daß ich bei der Umsetzung der Software auf andere Plattformen den SQL Ansatz ebenfalls benutzen kann.

    Auf einer anderen Plattform musst du deinen SQL-Ansatz dann auf diese Plattform portieren. Ich sehe keinen Unterschied darin, ob ich jetzt meinen eigenen SQL-Ansatz in eine andere Programmiersprache portieren oder den Datenhaltungsansatz auf die Programmiersprache anpassen muss.

    Thallius schrieb:

    Ja das ist echt zum kotzen das Apple das nicht unterstützt.

    Ansichtssache. So kann Apple wenigstens sicher sein, dass da kein altkluger Besserwisser mit seinem unglaublich geilen altbewährten in 10 Minuten zusammengezimmerten SQL-Ansatz die Performance des gesamten iCloud Universums lahm legt.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Nach wie vor verstehe ich aber den Anwendungsfall nicht.
    Das besondere ist, dass die meisten Schalterveränderungen von außen, über das Netzwerk kommen. Da kann auch schon mal eine Information verloren gehen (was nicht schlimm ist). Wenn die app. nicht aktiv ist, bekommt es überhaupt keine Änderungen mit, und in diesem nicht aktiven Zustand müssen keine Werte gespeichert werden.

    Nachtrag: das hatte ich vorhin per iPhone beantwortet. nun etwas genauer ausgeführt.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von entwickler ()

  • Also, ich würde jemanden, der aus der Webentwicklung kommt und sich schon mit Datenbanken auskennt empfehlen, das erste Projekt mit Sqlite zu machen. Ich habe das jedenfalls so gemacht und bereue es nicht. Dann landet man nämlich erstmal auf der Plattform und lernt erst mal die gröbsten Handgriffe. Wenn man sich dann sicherer geworden ist, ist genau der richtige Zeitpunkt gekommen Core Data zu benutzen.


    Dass Core Data fast immer Vorteile hat bezweifle ich nicht. Nur ist es sicher nicht schlau, sich gleich damit zu 'konfrontieren', wenn die anderen Konzepte der Sprache noch nicht im Hirn eingrannt sind.

    Übrigens: wenn man nur kleine Datenmengen hat, kann es manchmal völlig reichen ein Dictionary als Model zu benutzen. Diese kann man auch direkt als plist speichern, solange man einfache Datentypen benutzt.
  • Lucas de Vil schrieb:

    Ansichtssache. So kann Apple wenigstens sicher sein, dass da kein altkluger Besserwisser mit seinem unglaublich geilen altbewährten in 10 Minuten zusammengezimmerten SQL-Ansatz die Performance des gesamten iCloud Universums lahm legt.
    LOL, das iCloud Universum legt sich schon selbst gerne mal lahm ;)

    SQL hat nach wie vor seine Berechtigung, ORM hin oder her. Vor allem, weil es in vielen Geschmacksrichtungen und Plattformen vorhanden ist, und wenn man es ein mal gelernt hat, eine minimale Einarbeitungszeit auf einer anderen Plattform erlaubt.
  • Leider verstehe ich das meiste noch nicht ganz über das hier geredet wird aber ich habe mich mit meinen fragen weiter beschäftigt und hier eine gute Lösung gefunden.
    Jetzt noch um einen token erweitern das nicht jeder die URL einfach aufrufen kann (auch bin ich für jede Idee Dankbar)

    Beispielcode:

    Quellcode

    1. - (void)viewDidLoad
    2. {
    3. [super viewDidLoad];
    4. // Do any additional setup after loading the view, typically from a nib.
    5. NSError *error = nil;
    6. NSData *jsonData = [NSData dataWithContentsOfURL:[NSURL URLWithString:@"http://mein.testfile.de/json.php"]];
    7. if (jsonData) {
    8. id jsonObjects = [NSJSONSerialization JSONObjectWithData:jsonData options:NSJSONReadingMutableContainers error:&error];
    9. if (error) {
    10. NSLog(@"error is %@", [error localizedDescription]);
    11. // Handle Error and return
    12. return;
    13. }
    14. if ([jsonObjects isKindOfClass: [NSArray class]]){
    15. // probably iterate through whtever is in it
    16. NSLog(@"probably iterate through whtever is in it");
    17. for (NSString *string in jsonObjects) {
    18. NSLog(@"%@", string);
    19. }
    20. }
    21. else if ([jsonObjects isKindOfClass: [NSDictionary class]]){
    22. // dictionary at the top level. Hooray!
    23. NSLog(@"dictionary at the top level. Hooray!");
    24. NSArray *keys = [jsonObjects allKeys];
    25. // values in foreach loop
    26. for (NSString *key in keys) {
    27. NSLog(@"%@ => %@",key, [jsonObjects objectForKey:key]);
    28. }
    29. } else{
    30. // something went horribly wrong, deal with it.
    31. NSLog(@"omething went horribly wrong, deal with it.");
    32. }
    33. } else {
    34. // Handle Error
    35. }
    36. }
    Alles anzeigen


    Hier ein Json was NSArray auslöst:

    Quellcode

    1. [{"user":{"vorname":"Simpsons","name":"Bart","age":"10"}},{"user":{"vorname":"Simpsons","name":"Lisa","age":"8"}}]


    Hier eins was NSDictionary auslöst:

    Quellcode

    1. {"pos1":"test","pos2":"abc"}