CoreData + Email + Irre Karin = ???

    • CoreData + Email + Irre Karin = ???

      Ok Ihr Lieben, Ihr habt alle Recht, aber ich ticke sowieso nicht ganz richtig und drum will ich es angehen. :)
      Wichtig wären mir Eure Meinungen und vielleicht der eine oder andere Tipp, wie ich es angehe.

      Vorgeschichte:
      Ich habe meine Verkaufsapp für den Auslieferungsfahrer fertig und die funktioniert richtig gut. Der Fahrer fährt ab März übers Land und wird verkaufen können.

      Mein Problem:
      Ich möchte Ihm per Email ein komplettes SQLite-File mit den neuen Preisen und Sonderangeboten sowie Bildern schicken.In der DB gibt es also Text, Zahlen, Binary Data...
      Die App will ich nun so einstellen, dass diese für das Format empfänglich ist und dann halt das File reinholen, die DB updaten und er ist auf dem neuesten Stand.
      Am Ende des Tages drückt der Fahrer aufs Sendeknöpchen, die App versendet seinerzeit ihre SQLite mit allen Verkaufsdaten und Belegbildern (wichtig, wegen der Unterschrift) und wenn denn der Versand geklappt, hole ich mir die SQLite-Datei in mein System und Karin ist glücklich.

      Hat das schon einmal jemand gemacht? Server geht nicht, es bleibt nur Email aus ganz bestimmten geheimnisumwitterten Gründen :)

      Danke für Tipps und für alle: Frohe Weihnachten, schnabuliert weniger als ich. Ich habe jetzt schon 3 kg zugenommen. Mist...
      8| 8|
      Liebe Grüße
      Karin

    • Ja, hast Du bestimmt Recht. aber am wichtigsten ist mir, dass er die neuen Preise nebst Bilder bekommt.
      Anhand der Bilder, in sicherlich ruhigeren Momenten kann er in einem Teil der App sehen, wie manche Sträuße arrangiert werden sollen.
      Ich will keinen ausgebildeten Blumenhändler auf die Reise schicken. Mir reicht ein affiner Mensch mit einem hinreichend glücklichen Händchen.
      Ob ich die Verkaufszahlen danach habe oder nicht ist mir egal. Wenn er aber mit Gestecken zwei Tage unterwegs ist, muss ich die DB aktualisieren können.

      Außerdem will ich wissen, wie es geht :rolleyes:

      Ich bastel dann mal, 2 Weihnachtsfeiertage habe ich und bis Ende des Jahres ist auch noch Zeit. Ich gebe da nicht auf.

      Liebe Grüße
      Karin

      P.S.: Stress auch nicht. Wenn alles schief geht, verkauft er und auch nett :)

    • Finde schon, dass es eine gute Idee ist.
      Es geht nicht an, dass beispielsweise mit jeder Aktualisierung einer App alle Binary Data futsch ist. Ausser man konvertiert dann in ein Format was Json ab kann.
      Die Datensicherung in Core Data ist ein sehr stiefmütterlich behandeltes Thema und irgendwie erinnert mich der ganze Umgang damit an C64-Zeiten und Datasette.
      Ich probier das mal und dann sehen wir weiter.

      Mir ist eine missglückte Email lieber, als plötzlich so zu tun, dass der Webserver nun das sicherste der Welt und Allheilmittel wäre.

      Lieben Dank für Deinen sicherlich berechtigten Einwand, aber Firmendaten gehen auf keinen Webserver.

      Liebe Grüsse
      Karin

      Schlafen sollte ch auch mal wieder ^^

    • Mit Sicherheit brauchst Du hier nicht argumentieren! Emails werden auf zig Servern abgelegt, ehe Sie beim Empfänger ankommen. Dort liegen sie rum wir Postkarten. Offen und für alle lesbar (ausser verschlüsselte). Jeder kann Deine Email nehmen und damit weiterarbeiten. Es gibt viele Tutorials, wie man Daten auf einem Server ablegt. Einfach mal googlen....

    • Hi Kai,

      nun ja, haste sicherlich recht.

      Werde trotzdem den Weg --> Server und den Weg --> Email nehmen und bin gebranntes Kind, was Servergeschichten angeht und da kann ich schon argumentieren. Mich gezielt bei einem allgemeinen Mailanbieter finden, die Email raussuchen, wo das SQLite-File drin ist, im Gegensatz zu unserer Internetpräsenz halte ich schlicht für unmöglich.
      Bei einer miesen Verbindung landet die nicht versendbare Email im Entwurf und eine SQLite von einigen MBs auf einen Server zu speditieren, verlangt auf dem Land schon eine ziemlich lange und stabile Verbindung. Mich wundert es sowieso, dass sich die Menschen dort das gefallen lassen :wacko:
      Insofern präferiere ich Email und ja: Ich argumentiere weiter :)

      Beide Wege werden beschritten und dann entschieden.

      Schöne Weihnachten und lecker Essen wünscht
      Karin

    • Wenn Du nicht die komplette DB sondern nur die geänderten Daten austauschst, dann sollte der Up-/Download auch nicht mehr so lange dauern. ;)

      Alternativ kannst Du anstelle von JSON oder XML auch einfach ein Archiv, welches Du per NSKeyedArchiver erstellt hast, austauschen. Wenn Du als Output für den NSKeyedArchiver NSPropertyListBinaryFormat_v1_0 wählst, dann sollte das Archiv auch recht klein und handlich werden,

    • Bevor man mit dem Programmieren anfängt, würde ich erst mal die Eckdaten sammeln oder zumindest abschätzen:
      - Wie groß ist die gesamte Datenbank?
      - Wie oft muss man aktualisieren?
      - Wie viele Daten gehen für die Aktualisierung durchs Netz?
      - Wie viel (und welche) Sicherheit wird gebraucht?
      Ich vermute zwar, dass bei deinem Anwendungsfall eh alle Zahlen so klein sind, dass man mit keinem Ansatz fundamentale Probleme bekommt - aber gerade wenn man viel mit Bildern arbeitet, kann das Datenvolumen auch schnell ausufern…
      CoreData beispielsweise hat beim lesenden Zugriff eigentlich nie Probleme - aber wenn man erst einmal einige Hunderttausend Objekte in der DB hat, ziehen sich Updates gewaltig in die Länge (sprich: Ein paar Tausend einzelne Objekte zu aktualisieren dauert länger, als die ganze DB neu zu übertragen).

      Wenn es darum geht, dass Daten nicht in die Hände von Unbefugten gelangen, tust du dir mit Email jedenfalls keinen Gefallen: Ein falscher Empfänger eingetragen, und belästigt man einen Unbeteiligten mit internen Daten…. und die andere Richtung geht natürlich auch wunderbar: Man braucht nur sehr wenig Know-How, um sich in die Kommunikation reinzumogeln, und falsche Daten ins System zu bringen.

      Kurzum: Wenn es eigentlich eh egal ist, wer die Daten sieht (und man sich darauf verlassen möchte, nicht das Ziel von Angriffen zu werden) kann man die Kommunikation auch per Email abwickeln - das ist zwar etwas leichtfertig* und nicht sehr professionell, aber wenn die Kosten-Nutzen Relation stimmt…

      [* man kann die Mailkommunikation natürlich auch wasserdicht absichern - aber statt dem Mehraufwand dafür kann man dann eigentlich auch gleich ein richtiges Backend bauen]

    • parse.com bietet z.B. ein Backend für Synchronisation, Dateiupload usw.

      Und da du keine tausend Kunden für dein kleines Tool hast, wirst du auch kein Problem mit den max. 1.000.000 API Aufrufen pro Monat haben (erst danach kostet es was).
      Der kostenlose Speicherplatz von 1GB für Files sollte ebenfalls reichen. ;)

      Gibt eine schöne und einfache Objective-C API inkl. leicht verständlicher Einführung.
      Du könntest an sich alles dort lagern:
      - Inhalte was jetzt in der DB ist, wie Bilder und Beschreibungen
      - Kundenbelege die vom "Fahrer" zurückkommen
      usw.

      Statt hin- und herschicken von Dateien müsste er nur Reload drücken (bzw. das kann man auch automatisch über applicationWillEnterForeground und applicationDidFinishLaunching triggern).

      Zum Daten einpflegen kannst du dir entweder auch eine Desktop App machen die damit synct,
      oder du nutzt den Data-Browser auf deren Website.
      Damit kannst du die Daten deiner App auch über das Webinterface bequem einsehen oder manipulieren (oder direkt dort neue Inhalte erstellen).