• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Die Bildungsoffensive hier im Forum geht weiter! Jetzt sollen Kreativität und technische Möglichkeiten einen neue Dimension erreichen. Das Thema in diesem Monat lautet - Verkehrte Welt - Hier geht es lang --> Klick

Auf Item in einer Arraycollection zugreifen

Mole23

Grahams Jubiläumsapfel
Registriert
05.07.10
Beiträge
104
Hi zusammen,

ich versuche gerade auf eine Arraycollection/Matrix oder wie auch immer das bei IOS heißt, zuzugreifen. Genaugenommen, bekomme ich den ersten Index über eine Variable. Der Subindex ist derzeit immer an Position 0. Das Array habe ich in Form einer .plist erstellt. Evtl. erstelle ich später noch "association parameters", aber das tut ja im Moment nichts zur Sache.

Was ich auch etwas merkwürdig finde, ist die Tatsache, dass wenn ich die Liste "pictureNames.plist" in XCODE öffne alles normal aussieht. Betrachte ich die Liste hingegen im Debugger, sehe ich die Subobjekte garnicht.

Meine derzeitigen Ansätze sind folgende:

detailViewController.detailItemNames = [self.pictureNames[objectAtIndex: indexPath.row][objectAtIndex: indexPath:0]];

oder auch:

detailViewController.detailItemNames = [self.pictureNames objectAtIndex: indexPath.row][0];

Ich habe auch schon ein paar weitere Syntaxen ausprobiert, aber das hat mich noch nicht zum gewünschten Ergebnis gebracht. Laut Doku, soll das ja wie in allen anderen Sprachen auch gehen: array[2][0]...

Hier sind noch ein paar Screenshots von der .plist und dem Debugger:

Ansicht im Debugger:
http://img180.imageshack.us/img180/9610/debugger.png

Ansicht der "pictureNames.plist" in XCODE:
http://img203.imageshack.us/img203/7560/array.png

Gruß aus dem Norden, Ole!
 
Zuletzt bearbeitet:
So, ich habe schonmal eine Lösung gefunden: Ich hatte gerade festgestellt, dass wenn ich das gesamte Objekt übergebe, ich im Anschluss auf die Subobjekte zugreifen kann... Aber das muss doch auch irgendwie smarter gehen oder irre ich mich da?
 
Ohne sicher zu sein dein Post wirklich verstanden zu haben: :P

Arrays werden in Objective C normal so erstellt:

NSArray *meinArray = [NSArray arrayWithObjects: item.subobject1, item.subobject2, item.subobject3, nil];
 
Hi, ne, so einfach isses dann leider doch nicht.

Ich möchte kein Array erstellen, sondern ein Array in einer .plist Datei (mehrere Arrays enthalten) auslesen. Bei einer 2D Array ist das auch recht simpel. Bei einer mehrdimensionalen Array hingegen, kann ich nicht auf die Subitems zugreifen. Ich habe einen Lösungsansatz, bei dem ich vorher das gesamte Subobjekt einer neuen id zuweise, in etwa so:

self.rootViewItem = [self.vehicleDataList objectAtIndex: indexPath.row];

Jetzt kann ich die Subarray ansteuern, wie folgt:

[rootViewItem objectAtIndex:0];


Meine Frage ist jetzt ob ich irgendwie direkt auf die SubItems zugreifen kann, denn angenommen ich befinde mich in der zehnten Subzelle oder so, ist dieser Weg keine echte Lösung...
 
Zuletzt bearbeitet:
Ich verstehe deine Frage nicht ganz. Eine kleine Optimierung dieses Code wäre:

Code:
[[self.vehicleDataList objectAtIndex: indexPath.row] objectAtIndex:0];

Gruss ppocket
 
Hi, ich kann das im Moment nicht testen, evtl. hat sich das mit dem Post von Poljpocket schon Erledigt. Da die Problematik aber scheinbar nicht ganz klar ist, versuche ichs noch einmal. Am besten am Beispiel von oben:

Ich habe hier ein .plist File erstellt. Diese vehicleDataList...

...diese enthält eine Array in der, drei mal dürft ihr raten, genau, weitere Arrays verschachtelt sind. Also eine Matrix.

Ich würde jetzt sehr gerne auf ein Item in der verschachtelten Array zugreifen.

Wie wir alle wissen geht das bei einer typischen Matrix wie folgt z.B: vehicleDataList[0][2]... Bei dieser .plist Datei scheint es aber so zu sein, dass jedes Array als Objekt gespeichert wird. Ist ja irgendwo ganz cool...

...Da ich es leider nicht besser weiß, übergebe ich aus diesem Grund, wie oben schon beschrieben, ein Objekt an Indexstelle x an das Objekt rootViewItem.

Jetzt kann ich natürlich auf die Items in der ehemals verschachtelte Array zugreifen, da diese sich alleine in meinem Objekt "rootViewItem" befinden.

Würde ich in diesem Objekt aber wieder ein Array als Subobjekt haben, müsste ich dieses ja schon wieder an ein neues Objekt übergeben müssen. Ich könnte es z.B. "dasNeueObjekt" nennen^^... Und so weiter... Und so weiter...

Aber das ist ja ungeil... Ich will direkt auf das 1256igste SubArray zugreifen, ohne noch bis 2011 im Büro zu sitzen und wie ein Irrer Objekte zu erstellen...

Denke jetzt dürfte die Fragestellung etwas eindeutiger sein... Besten Gruß, Ole!
 
Zuletzt bearbeitet:
Mit +(id)arrayWithContentsOfFile: (NSString *)aPath bekommst wieder das komplett initialisierte Array.
 
Ah, tastsache, das scheint zu funktionieren! Vielen Dank!

Gruß, Ole!
 
Gibt es einen Grund warum du statt Objektorientierter Arrays normale C-Arrays verwendest?
Keine Ahnung ob das beim laden oder speichern Probleme geben kann.

Die Funktionen zum laden / speichern sind ja schon auf Objekte ausgelegt.

Sprich statt cArray[0][2] eben wie oben erwähnt [[arrayObject objectAtIndex:0]objectAtIndex:2]];

Sprich deine Arrays von Anfang an eben als Objekte auslegen.

NSArray *subArray1 = [NSArray arrayWithObjects:object1, object2, object3,nil];
NSArray *subArray2 = [NSArray arrayWithObjects:object1, object2, object3,nil];

NSArray *mainArray = [NSArray arrayWithObjects:subArray1, subArray2 ,nil];

Man kann aus solch einem Objekt (inkl. aller Unterobjekte) auch sehr schnell und bequem ein plist-File speichern:

[mainArray writeTo:path atomically:NO];

und eben wieder laden:

NSArray *loadedArray = [NSArray arrayWithContentsOfFile:path];

Reine C-Funktionen sind etwas schneller und belegen auch weniger Speicher.
Aber wenn es da nicht um etwas Laufzeitkritisches geht, kann man sich den "Luxus" schon gönnen.

Gerade wenn man von anderen Sprachen kommt ist das Mischen von Objekten und einfachen Datentypen (und der manchmal erforderlichen Konvertierung)
schon ein Stoplerstein.