Datenbank/SQL/XML

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

  • Datenbank/SQL/XML

    Hallo Zusammen,
    ich hab gerade eine Ausbildung als Fachinformatiker angefangen (ca. 6 Monate dabei).
    Wir arbeiten hauptsächlich mit VB.net somit ist das Wissen über Xcode beschränkt, um es vorsichtig auszudrücken.
    Ich hab mich eigenständig die letzten Wochen mit Xcode beschäftigt um da rein zu kommen. Jetzt soll ich eine App schreiben.

    Da kommt schon meine erste Frage: Swift oder Objective-C?
    Nachdem was ich gelesen hab würde ich Swift sagen, aber was sagt ihr dazu?

    Meine zweite Frage geht um die MVC-Struktur. Hier auf der Arbeit hab ich das bis jetzt nicht gelernt oder gesehen, bin da selber darauf gestoßen.
    Wir arbeiten Hauptsächlich so, dass wir alles in die Klasse der View reinschreiben und so nicht wirklich OOP nutzen.
    Da man mir gesagt hat ich hätte eine grüne Wiese und könnte die App so umsetzten wie ich wolle überlege ich ob ich die MVC-Struktur verwenden solle.
    Ist das schwerer?
    Was sagt ihr dazu?
    Kenn ihr eine guten Tutorium dazu?

    Mein größtes Problem bzw. der meiste Aufwand macht mir die Verbindung zu unserem Server.
    Ich mach das mit Hilfe eines Webservice. Dieser zu schreiben ist keine große Sache aber wenn dann die XML-String ankommt wird es sehr aufwendig.

    Momentan verwende ich einen eventbasierten XML-Parser (ich glaub sogar von apple) und eine SQLite Datenbank
    Ich lass mir vom Webservice meistens eine Tabelle in XML-Form geben.
    Ich schreibe für jede Anfrage an den Webserver ein Klasse.
    Ich brauche für jede Spalte der Tabelle je zwei Variablen einmal ein NSMutableArray und ein bool.
    In das NSMutableArray schreib ich Zeile für Zeile das richtige Element rein.
    In das Bool halt ich fest ob ich gerade das Element bei der Vorgang bearbeitet wird.
    Zum Schluss schreib ich noch Zeile für Zeile in die lokale SQLite-Datenbank auf dem Gerät.
    Geht das nicht einfacher?
    Immerhin ist doch im Xml-String die Tabelle-Struktur enthalten, da müsste es doch eine Möglichkeit geben sie eins zu eins in die SQLite-Datenbank zu übernehmen?

    ich hab mal ein bisschen Code rein kopiert um meine Vorgehensweise zu verdeutlichen.

    Wäre schön wenn ihr mir helfen könntet.

    Quellcode

    1. - (void)parser:(NSXMLParser *)parser didStartElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName attributes:(NSDictionary *)attributeDict
    2. {
    3. if([elementName isEqualToString:@"Kundennummer"])
    4. {
    5. KundennummerB= true;
    6. Daten = @"";
    7. }
    8. if([elementName isEqualToString:@"Bezeichnung1"])
    9. {
    10. Bezeichnung1 = true;
    11. Daten = @"";
    12. }
    13. if([elementName isEqualToString:@"Bezeichnung2"])
    14. {
    15. Bezeichnung2 = true;
    16. Daten = @"";
    17. }
    18. if([elementName isEqualToString:@"Kurzname"])
    19. {
    20. Kurzname = true;
    21. Daten = @"";
    22. }
    23. if([elementName isEqualToString:@"PLZ"])
    24. {
    25. PLZ = true;
    26. Daten = @"";
    27. }
    28. if([elementName isEqualToString:@"Stadt"])
    29. {
    30. Stadt = true;
    31. Daten = @"";
    32. }
    33. if([elementName isEqualToString:@"Strasse"])
    34. {
    35. Strasse = true;
    36. Daten = @"";
    37. }
    38. if([elementName isEqualToString:@"Vorwahl"])
    39. {
    40. Vorwahl = true;
    41. Daten = @"";
    42. }
    43. if([elementName isEqualToString:@"Telefon1"])
    44. {
    45. Telefon1 = true;
    46. Daten = @"";
    47. }
    48. if([elementName isEqualToString:@"Telefon2"])
    49. {
    50. Telefon2 = true;
    51. Daten = @"";
    52. }
    53. if([elementName isEqualToString:@"Email"])
    54. {
    55. Email = true;
    56. Daten = @"";
    57. }
    58. if([elementName isEqualToString:@"EMail_buchhaltung"])
    59. {
    60. EMail_Buchhaltung = true;
    61. Daten = @"";
    62. }
    63. if([elementName isEqualToString:@"Fax"])
    64. {
    65. Fax = true;
    66. Daten = @"";
    67. }
    68. if([elementName isEqualToString:@"Faxvorwahl"])
    69. {
    70. Faxvorwahl = true;
    71. Daten = @"";
    72. }
    73. Daten = @"";
    74. }
    75. - (void)parser:(NSXMLParser *)parser foundCharacters:(NSString *)string
    76. {
    77. if((Daten != nil) && (KundennummerB == true || Faxvorwahl == true || Fax == true || Bezeichnung1 == true || Bezeichnung2 == true || Kurzname == true ||PLZ == true ||Stadt == true || Strasse == true || Vorwahl == true || Telefon1 == true ||Telefon2 == true || Email == true || EMail_Buchhaltung == true ))
    78. Daten = [Daten stringByAppendingString:string];
    79. }
    80. - (void)parser:(NSXMLParser *)parser didEndElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName
    81. {
    82. if (Daten!=nil)
    83. {
    84. NSLog(@"Endelemt gefunden: %@ mit Inhalt: %@", elementName, Daten);
    85. if (KundennummerB == true)[ArrKundennummer addObject:Daten];
    86. if (Bezeichnung1 == true)[ArrBezeichnung1 addObject:Daten];
    87. if (Bezeichnung2 == true)[ArrBezeichnung2 addObject:Daten];
    88. if (Kurzname == true)[ArrKurzname addObject:Daten];
    89. if (PLZ == true)[ArrPLZ addObject:Daten];
    90. if (Stadt == true)[ArrStadt addObject:Daten];
    91. if (Strasse == true)[ArrStrasse addObject:Daten];
    92. if (Vorwahl == true)[ArrVorwahl addObject:Daten];
    93. if (Telefon1 == true)[ArrTelefon1 addObject:Daten];
    94. if (Telefon2 == true)[ArrTelefon2 addObject:Daten];
    95. if (Email == true)[ArrEmail addObject:Daten];
    96. if (EMail_Buchhaltung == true)[ArrEMail_Buchhaltung addObject:Daten];
    97. if (Fax == true)[ArrFax addObject:Daten];
    98. if (Faxvorwahl == true)[ArrFaxvorwahl addObject:Daten];
    99. KundennummerB = false;
    100. Bezeichnung1 = false;
    101. Bezeichnung2=false;
    102. Kurzname =false;
    103. PLZ =false;
    104. Stadt =false;
    105. Strasse =false;
    106. Vorwahl =false;
    107. Telefon1 =false;
    108. Telefon2 =false;
    109. Email =false;
    110. EMail_Buchhaltung =false;
    111. Fax =false;
    112. Faxvorwahl =false;
    113. Daten = nil;
    114. }
    115. }
    116. - (void)parserDidEndDocument:(NSXMLParser *)parser;
    117. {
    118. //UIAlertView *Hinweis = [[UIAlertView alloc] initWithTitle:@"Daten empfangen" message:[ArrName objectAtIndex:0] delegate:self cancelButtonTitle:@"OK" otherButtonTitles:nil, nil];
    119. //[Hinweis show];
    120. //for (int i=0; [ArrID count]-1; i++) {
    121. //NSLog(@"daten: %@",[ArrID objectAtIndex:i]);
    122. //}
    123. //NSLog(@"DBPfand ist: %@", DBPfad);
    124. FMDatabase *DB = [[FMDatabase alloc] initWithPath:DBPfad];
    125. [DB open];//"
    126. //SQL =@"CREATE TABLE IF NOT EXISTS \"KundenDaten\" (\"ID\" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL , \"Kundennummer\" INTEGER, \"Bezeichnung1\" CHAR,\"Bezeichnung2\" CHAR,\"Kurzname\" CHAR,\"PLZ\" CHAR,\"Stadt\" CHAR,\"Strasse\" CHAR,\"Vorwahl\" CHAR,\"Telefon1\" CHAR,\"Telefon2\" CHAR,\"Fax\" CHAR,\"Faxvorwahl\" CHAR,\"Email\" CHAR,\"EMail_Buchhaltung\" CHAR);";
    127. //[DB executeUpdate: SQL];
    128. //NSLog(@"Tabelle erstellen Fehler: %@",[DB lastError]);
    129. for (int Zähler =0 ; Zähler <= [ArrKundennummer count]-1; Zähler++)
    130. {
    131. FMResultSet *RS;
    132. RS = [DB executeQuery:[NSString stringWithFormat:@"SELECT * FROM KundenDaten WHERE Kundennummer = %@", [ArrKundennummer objectAtIndex:Zähler]]];
    133. if ([RS next])
    134. {
    135. NSString *SQL =[NSString stringWithFormat: @"UPDATE KundenDaten SET Bezeichnung1= '%@', Bezeichnung2 = '%@', Kurzname = '%@' WHERE Kundennummer = %@",[ArrBezeichnung1 objectAtIndex:Zähler],[ArrBezeichnung2 objectAtIndex:Zähler],[ArrKurzname objectAtIndex:Zähler],[ArrKundennummer objectAtIndex:Zähler]];
    136. //NSLog(@"%@", SQL);
    137. if([DB executeUpdate:SQL])
    138. {
    139. //NSLog(@"UPDATE erfolgreich");
    140. }
    141. else
    142. {
    143. //NSLog(@"UPDATE fehlgeschlagen");
    144. //NSLog(@"Fehler: %@", [DB lastError]);
    145. }
    146. }
    147. else
    148. {
    149. SQL = [NSString stringWithFormat: @"INSERT INTO KundenDaten( Kundennummer,Bezeichnung1, Bezeichnung2, Kurzname,PLZ,Stadt,Strasse,Vorwahl,Telefon1,Telefon2,Email,Email_Buchhaltung,Fax,Faxvorwahl) VALUES (%@ ,'%@' ,'%@', '%@', '%@', '%@', '%@', '%@', '%@', '%@', '%@', '%@', '%@', '%@')",[ArrKundennummer objectAtIndex:Zähler],[ArrBezeichnung1 objectAtIndex:Zähler],[ArrBezeichnung2 objectAtIndex:Zähler],[ArrKurzname objectAtIndex:Zähler],[ArrPLZ objectAtIndex:Zähler],[ArrStadt objectAtIndex:Zähler],[ArrStrasse objectAtIndex:Zähler],[ArrVorwahl objectAtIndex:Zähler],[ArrTelefon1 objectAtIndex:Zähler],[ArrTelefon2 objectAtIndex:Zähler],[ArrEmail objectAtIndex:Zähler],[ArrEMail_Buchhaltung objectAtIndex:Zähler],[ArrFax objectAtIndex:Zähler],[ArrFaxvorwahl objectAtIndex:Zähler]];
    150. if(![DB executeUpdate:SQL])
    151. {
    152. NSLog(@"INSERT hat nicht geklappt: %@", SQL);
    153. NSLog(@"Fehler: %@", [DB lastError]);
    154. }
    155. else
    156. {
    157. NSLog(@"INSERT erfolgreich");
    158. }
    159. }
    160. }
    161. [DB close];
    162. }
    Alles anzeigen
  • Ich habe das nur überflogen aber ich glaube das wird so nichts.

    Was passiert wenn sich Deine XML Struktur mal ändert? Dann stehen in Deinem Array plötzlich ganz andere Werte an anderen Stellen. Deine ganze Datenstruktur kommt dann komplett durcheinander. Du must für Deinen Kunden schon eine eigene Klasse anlegen und die XML Daten dann in die Attribute der Klasse schreiben. Danach kannst du die Klasse dann meinetwegen in sqlite abbilden. Natürlich wäre es viel einfacher diese dann in CoreData zu speichern.

    Überhaupt glaube ich das es keine gute Idee ist eine produktiv App zu schreiben mit Deinem Wissensstand. Du solltest Dich erstmal 1-2 Jahre mit iOS beschäftigen und kleine Übungsapps schreiben. Ich fürchte nur das wird dir dein Arbeitgeber nicht bezahlen.

    Aus eigener Erfahrung kann ich Dir (und vor allem Deinem Arbeitgeber) aber sagen, dass spätestens nach 1 Jahr Deine App dermassen verkorkst sein wird, dass eh professionelle Hilfe gefragt ist und ihr jemaden dafür bezahlen müßt der es dann richtig macht.

    Nichts für ungut

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Ein paar Kommentare:

    1) Nimm die Sprache, die Dir am Meisten liegt. Wenn Ihr nur VisualBasic nutzt, ist das allerdings schwierig abzuschätzen. Vermutlich ist es Swift.

    2) Rechne mit 6 Monaten für die App. Mindestens. Wenn Dir oder Deinem Chef das zu langwierig ist, dann lasst es bleiben.

    3) Es ehrt Dich, den MVC Ansatz nutzen zu wollen. Ehrlich gesagt hast Du auch gar keine andere Möglichkeit. ;)

    4) Fang an, Dich durch sämtliche Apple Dokumentation zu wühlen. Schön am Anfang anfangen und alles Mögliche durchspielen.
    Beispielsweise developer.apple.com/library/io…le_ref/doc/uid/TP40011343
    Ein direktes Programmziel vor Augen ist prima, allerdings als Einstiegsziel völlig ungeeignet.

    5) Falls bei euch nicht Gang und Gäbe, nutze ein Source Code Management System. Git ist prima, wenn ihr SVN oder CVS nutzt, dann nimm das. Aber nutze es auf jeden Fall.

    6) Den XML Parser kannste so machen. Geht aber sicherlich auch besser. Wenn Du weit genug bist, kannst Du das ganze Projekt ja mit Core Data umsetzen. Dann bist Du die öddelige SQLite Tabelle los.
    «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
  • Ich bastele auch gerade an einem größeren Projekt. Hier als Hilfe, was ich da gemacht habe:

    1. Bilde deine Datenbank auf Core Data Entities ab ( ist ziemlich einfach )
    2. Erstell dir NSManagedObject Subclasses über XCode. Damit hast du automatisch für jede Entity eine eigene Klasse.
    3. Erstell dir für jede dieser automatisch erstellte Klassen eine Kategorie als Erweiterung. Das werden dann wieder eigene Dateien in XCode
    4. Erstell dir eine eigene, generische Klasse für den Zugriff auf Core Data . Darin sind Methoden für den Aufbau und die Abfrage des NSManagedObjectContext und Methoden, um Daten in die Entitys abzulegen und abzufragen. Das am besten unabhängig von der Entity. Brian Advent hat da 3 coole Videos für Objective-C (youtube.com/watch?v=icB_6ZydCUM&spfreload=10 ist Teil 1 ) Eine Anpassung an Swift sollte nicht so schwer sein. Brian ist jetzt auf Swift gewechselt. Ich hab noch nicht geschaut, ob da die Entsprechung für Swift vorhanden ist.
    5. In den Kategoriedateien aus 3. erstellst du Methoden, um die Daten mit Vorabchecks in Core Data abzulegen. Darin übergibst du die zu speichernden Daten, testest ab, was du musst ( z.B. ob Zahlen > 0 sind, wenn sie das müssen oder andere Checks ) und rufst dann zum Speichern die Methoden aus 4. mit der entsprechenden Klasse auf.
    6. Bau dir in eigenen Dateien den Parser für XML bzw JSON, wobei ich auch zu JSON greifen würde. Diese Dateien gehören dann zum Model und verwenden die vorher definierten Methoden zum Ablegen der Daten.

    Warum das so ?
    Zur Wiederverwertung des Codes und zum klaren und strukturierten Trennen von Daten, Views und View Controler, halt MVC :) Diese ganzen Dateien legst du in ein Unterverzeichnis in XCode und nennst den Model. Das ist dein M.
    Dann erstellst du die einzelnen View Controller, die die Methoden des Models nutzen, um die Daten in Core Data abzulegen und dazu die Views entsprechend verändert
    => sauberes MVC

    Ein großer Vorteil ist, dass dein M identisch für eine Mac App und eine iPhone/iPad App ist. Da ändern sich nur View und View Controller.

    Zur Klarstellung: 4. arbeitet allgemein für Core Data, während 5. spezifisch auf die entsprechende Entity und deren Anforderungen angelegt ist.
    Es gibt zwei Dinge, die sind unendlich. Das Universum und die menschliche Dummheit. Wobei beim Universum bin ich mir nicht sicher - Albert Einstein
  • Erstmal vielen Dank für euere Hilfe. Ihr hab mir schon viel geholfen und mir sehr viele Infos gegeben.

    Thallius schrieb:

    Überhaupt glaube ich das es keine gute Idee ist eine produktiv App zu schreiben mit Deinem Wissensstand. Du solltest Dich erstmal 1-2 Jahre mit iOS beschäftigen und kleine Übungsapps schreiben. Ich fürchte nur das wird dir dein Arbeitgeber nicht bezahlen.


    Ich glaube auch kaum, dass ich da eine große Wahl hab.

    Marco Feltmann schrieb:

    Git ist prima


    Beim erstellen eines Projektes kann man ein Haken setzen ("Create Git repository on my Mac"), reicht das erstmal?
    Oder muss ich da noch was extra installieren?
    Ich werden mich nachher noch etwas über Git recherchieren. Hatte leider gestern keine Zeit mehr zu.

    FWerewolf schrieb:

    3. Erstell dir für jede dieser automatisch erstellte Klassen eine Kategorie als Erweiterung. Das werden dann wieder eigene Dateien in XCode


    Was meinst du mit Kategorie als Erweiterung?


    Und dann hab ich da noch eine Frage allgemein. Wie bekomme ich am besten die Daten vom Webservice auf das Gerät?
    Also vor allem was für eine Form erwartet iOS?
    So wie ich das bis jetzt mache ist das doch sehr unschön. Serverseitig kann mir wieder mein Ausbilder helfen, deswegen kann ich mir da bestimmt Erleichterung schaffen.
    Die Daten vom Webservice in das Core Data zu bekommen macht mir noch am meisten Bauchschmerzen.
  • Zunächst mal wäre zu klären ob Du mit der App die Daten auch ändern können must und wieder auf den Server zurückladen. Dann hast du nämlich wirklich ein Problem wenn die App auch offline arbeiten können muss. Da gibt es eigentlich kein brauchbares System beides immer vernünftig synchron zu halten.

    Die Daten würde ich wie bereits erwähnt als JSON vom Webservice holen.

    Diese kannst du dann, wie bereits erwähnt ganz einfach mit dem JSONParser in ene eigene Klasse Kunde oder so parsen und das Speichern in CoreData ist dann wirklich sehr enfach zumindest mit Objective-C. Wie die Swift Anbindung mittlerweile ist weis ich nicht da ich kein Swift mache.

    Ich finde trotzdem Du solltest erstmal mit einem leichteren Übunsprojekt anfangen. Sonst wird Dir das alles über den Kopf hinaus wvachsen

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

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

    Beim erstellen eines Projektes kann man ein Haken setzen ("Create Git repository on my Mac"), reicht das erstmal?

    Jau, das reicht. :)
    «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
  • Marco Feltmann schrieb:

    kaark schrieb:

    Beim erstellen eines Projektes kann man ein Haken setzen ("Create Git repository on my Mac"), reicht das erstmal?

    Jau, das reicht. :)


    Wenn du Xcode installierst, installiert du auch die CommandLineTools und damit git.
    Was heißt das reicht?
    Es nützt ihm doch nichts, wenn er bloß ein Repo anlegt und nicht mit arbeitet :P

    Immer wieder sehr empfehlenswert:
    macoun.de/video2011ksso3.php
  • matz schrieb:

    Was heißt das reicht?

    Das heißt, dass eine lokale Installation von Git dafür ausreichend ist.
    Es ist ja wohl selbstverständlich, dass man Git dann auch verwenden muss. :P

    Allerdings bedeutet für mich der Satz

    kaark schrieb:

    Ich werden mich nachher noch etwas über Git recherchieren.

    dass das mit dem Verwenden bereits auf der Tagesordnung steht. ;)
    «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
  • ... dann noch mal ein bisschen generelle Manöverkritik ;)

    kaark schrieb:

    KundennummerB= true;

    Funktioniert, ist streng genommen aber falsch:Eine der lästigen Altlasten von Objective-C sind die Booleans - true gibt es inzwischen, aber eigentlich ist "YES" richtig
    (auf die schnelle: iosdevelopertips.com/objective-c/of-bool-and-yes.html erklärt da ein bisschen was zu)

    kaark schrieb:

    if([elementName isEqualToString:@"Bezeichnung1"])

    uiuiui... das hätte man euch eigentlich auch in Basic schon nicht beibringen sollen - nicht das "if" an sich ist schlecht (switch geht hier leider nicht), aber das magische "else if" spart mitunter den einen oder anderen Taktzyclus (wenn ein String "Kundennummer" lautet, kann nicht auch noch "PLZ" drin stecken). Guter Code ist keine vorzeitige Optimierung, und selbst wenn es nicht viel kostet:
    Wenn man etwas macht, sollte man es richtig machen.

    kaark schrieb:

    KundennummerB == true

    Nein, nicht noch mal "YES": Einfach nur "KundennummerB". In diesem Fall wird es dem Compiler wohl egal sein, aber das Statement ist eh schon viel zu lang. Man könnte die Variable auch "has..." nennen, damit die Bedeutung offensichtlich ist.

    kaark schrieb:

    if([elementName isEqualToString:@"Fax"])
    {
    Fax = true;

    Wenn sich sowas im Source häuft, ist eigentlich eine gute Gelegenheit, sich einmal mit KVC (key-value coding) zu beschäftigen - solange man die ganze Dynamik noch in der Sprache hat, kann man damit auch ein bisschen Arbeit sparen ;)

    Die ganzen bools und "didStartElement" kann man sich wahrscheinlich auch sparen:
    Wenn ein Element aufhört, kann man dort alle Informationen aufsammeln - die attributes brauchst du ja anscheinend nicht (und falls doch: Es reicht ja, wenn man die zwischenspeichert, und ansonsten nicht auf den Tag guckt).

    Viel Erfolg!
    Tino
  • ich wollte mich zuerst nochmals bedanken für die nette Hilfe.
    Ich hab das Gefühl, dass ich mit eure Hilfe und viel lesen/recherchieren langsam voran komme.

    Ich hab mich gestern erstmal Core Data beschäftigt. Sehr viel Theorie gelesen und mal eine Grundstruktur aufgebaut. (Im Dateianhang ist eine .png dazu)
    Naja die erste Erkenntnis die ich machen musste ist: Man könnte sich wahrscheinlich Monate allein mit Core Data beschäftigen. Leider hab ich dafür nicht die nötige Zeit.

    Ich werde erstmal eine TestApp schreiben, um das importieren von Daten zu testen und dem Umgang mit Core Data zu üben (sprich Daten löschen, erstellen und manipulieren).
    Ich hoffe nur mein Chef sieht auch die Notwendigkeit dieser TestApp :D

    Zudem hab ich da noch einige Fragen:

    FWerewolf schrieb:

    2. Erstell dir NSManagedObject Subclasses über XCode. Damit hast du automatisch für jede Entity eine eigene Klasse.

    Das hab ich so gemacht, die Frage ist nun was ich damit machen kann?
    Kann ich mit diesen Klassen schon auf die Daten Zugreifen und Objekte erstellen die dann den Objekten aus der Datenbank entsprechen?

    kann ich ganze JSON-Objekte in Core Data importieren?
    Ich sehe da nur ein Problem bei den Relationships.

    Ich hab mehrfach gehört, Core Data sei keine Datenbank. So richtig versteh ich das nicht. Ist es dann mehr eine Schnittstelle mit dessen Hilfe man auf Datenbänke zugreifen kann??
    Naja ich glaub nicht, dass ich das unbedingt wissen muss aber es interessiert mich.

    Dann noch zur MVC-Struktur:
    Model: ist die Logik und die Datenbank (Daten) beides in Core Data...wenn ich das so richtig verstanden hab
    View: sind wohl die Klassen die die View's ansteuern zB eine Klasse mit "UIViewController" als Superklasse und im "Stroyboard" mit einem View "verlinkt" (bin mir bei den Begriffen nicht sicher)
    Controller: Leider weiß ich nicht wie das auf Xcode zu übertragen ist. und auch nicht richtig die Funktion.

    Vielleicht kann mich einer was MVC angeht etwas erhellen.



    Zudem wollte ich erstmal vorstellen was meine App können soll:
    -ich brauch ein Login.
    -dann soll der User zur Kundenauswahl kommen ("vorher alle Kunden vom Webservice laden mit minimalen Details")
    -hier sucht der User die zu bearbeitenden Kunden aus und kann dann alle Nötigen Daten per Button laden (Webservice)
    -Dann soll es unterschiedliche View's geben womit der User die Daten ansehen, löschen, erstellen und manipulieren kann (Preise ändern, Umsatz ansehen usw.)
    - zum Schluss soll der User die Daten wieder verschicken können (über den Webservice). Der Webservice soll dann die Daten in unsere Datenbank einpflegen.
    Dateien
  • So wie ich das sehe, solltest du dir ein Buch über Objective-C schnappen und erstmal die Grundlagen lesen. Dann wird sicher einiges klarer.
    Du versuchst gerade den Ärmelkanal zu durchschwimmen und kannst ein bissel Brustschwimmen :) Nimm dir die Zeit, kauf dir ein Buch oder Google dir die Infos und fang bei Null an. Du wirst ein so komplexes Projekt nicht hinkriegen, wenn du nicht die Grundlagen verstehst.
    Es gibt zwei Dinge, die sind unendlich. Das Universum und die menschliche Dummheit. Wobei beim Universum bin ich mir nicht sicher - Albert Einstein
  • Ich hab mir schon ein Buch gekauft (hanser-fachbuch.de/buch/Apps+f…+entwickeln/9783446440180). Ich hab es auch schon zur Hälfte gelesen aber leider fehlt mir schlicht die Zeit mich ausführlich damit zu beschäftigen. Ich schaff es leider nicht in drei Wochen ein Fachbuch zu lesen, komplett zu verstehen und Code Beispiele zu schreiben. Ich gebe dir recht, wenn es nach mir gehen würde, würde ich erstmal ein Jahr iOS, Xcode, Swift und Objective-C lernen und nur ÜbungsApps schreiben. Aber ich bin nun mal nicht mein eigener Chef und muss für das Unternehmen wirtschaftlich sein. Mein Chef hat mir gesagt die App soll dieses Jahr veröffentlich werden (er geht von Sommer aus) und dann hab ich auch noch andere Aufgaben im Unternehmen (Support einer anderen Firmer im Haus und Debugging bei einer anderen App).
  • kaark schrieb:

    Ich hab mir schon ein Buch gekauft (hanser-fachbuch.de/buch/Apps+f…+entwickeln/9783446440180). Ich hab es auch schon zur Hälfte gelesen aber leider fehlt mir schlicht die Zeit mich ausführlich damit zu


    Auch wenn ich bei dem Thema befangen bin: da hast Du Dir leider das wohl schlechteste der verfügbaren Bücher gekauft. Das Buch ist nicht viel mehr als eine Aufzählung von Klassen und Controllern. Bei Grundlagen versagt es leider vollständig.

    Um meine Befangenheit zu minimieren: versuch' es mal mit unserem kostenlosen Openbook.