Suchergebnisse

Der Ansatz gemäß des Links von Chris funzt. Danke!

Zitat von wolf_10de: „Also mit nem Arraycontroller und nem arrangedObjects @count geht das. Sollte doch dann auch mit nem Set gehen“ Dachte ich mir eigentlich auch .. Zitat von Chris: „Du behauptest dass [mutableSet addObject: xxx] ein KVO auslöst? Bei mir nicht.“ Nein, das behaupte ich nicht. Ich behaupte, dass ich gern ein KVO auf @count der Property anmelden möchte, die das mutable Set hält. Hmm, ich klinge schon wie Amin. Aber der Link ist - denke ich - genau das, was ich gesucht und nicht g…

Jein. Mit expliziten Accessoren kann ich das auch - ich möchte aber ein KVO auf "toepfchen.@count" haben, damit ich die Standard-NSMutableSet-methoden fürs hinzufügen und entfernen nutzen kann. Bei NSMutableArray geht das ja auch.

Zitat von Amin Negm-Awad: „Das Geschwurbel hast du aber mit dem Geschwurbel für Sets probiert, nicht mit dem Array-Geschwurbel?“ Ich muss zugeben, dass ich das Geschwurbsel für Arrays genommen und angepasst habe - ich habe das für Sets nicht finden können, trotz google. Vermutlich liegt es einfach daran. Kannst Du mir einen Link geben? Leider kann man das in Xcode ja nicht mehr automatisch erzeugen lassen. @Chris: Ich möchte nicht die Anzahl wissen, sondern die Anzahl observieren.

Ich wusste, dass das kommt, denn es hat nichts mit der Frage zu tun Eine UNSORTIERTE Queue. Eine Queue, bei der ist nicht auf die Reihenfolge ankommt. Meinetwegen also keine Queue, sondern ein Topf.

Hallo, ich stehe gerade auf dem Schlauch: Ich möchte gern die Anzahl eines NSMutableSet observieren (es handelt sich um eine Queue und ich würde gern das GUI in Abhängigkeit der Zahl anpassen). Alledings funktioniert @count nicht und auch diese komische Extra-Accessoren-Gewirr mit countOfLaberLaber, wie bei NSMutableArray (früher?), geht nicht. Was mache ich falsch bzw. habt Ihr einen Tipp für mich?

iOS cached Bilddaten. Wenn Du das erste mal ein UIImage allozierst und initialisierst, wird das Bild geladen und gecached. Wenn Du dann erneut ein UIImage anlegst, wird das Bild aus dem Cache genommen, falls es noch da ist. Daher ruckelt es beim ersten Mal (HD-Zugriffe). Das Crashen auf dem Device hat den Grund den Du kennst: Low Memory. Du lädst (und iOS cached) zuviele Daten. Du hast hier einen Architekturfehler, denn wenn das passiert, ist Dein Ansatz falsch.

Der plausible Grund für das Problem scheint darin zu liegen, dass ich innerhalb des resignFirstResponder-Handlings - nämlich in textfieldDidEndEditing: - bereits den Reload initiert habe. Da das (offenbar) nicht asynchron läuft, kommt hier natürlich die ganze Dramaturgie durcheinander. Wenn ich das ganze aber entkoppele und asynchron aufbaue, scheint es zu gehen. Ist ja auch plausibel.

Ich lösche die section nicht. Ich lade die section (neu).

OK, ist doppelt (oder über), ändert aber im grundlegenden Problem nichts.

Hallo, ich habe gerade ein etwas kniffliges Problem, das mir Kopfzerbrechen bereitet. In einer (custom) TableViewCell habe ich ein Textfeld. Das Keyboard dieses Textfeldes hat drei Buttons in einem Accessory-View. Mit den Buttons kann man Dinge™ an- und ausmachen. Je nachdem, welche Dinge™ an und aus sind, verändert sich das Erscheinungsbild und die Höhe der TableViewCell. Tippt der User nun im Keyboard auf "Done", wird in textFieldShouldReturn: ein [textfield resignFirstResponder] gefeuert und …

Ein MFI Accessory mit Lightning-Anschluss, also für iPod touch 5G und iPhone 5 usw.

Das ist so. Es gibt nur einen "Kanal" zur Kommunikation bei Lightning - und der ist durch das Accessory belegt. Entweder Accessory oder Device. Beides gleichzeitig geht nicht mehr bei 5 PINs. Beim Dock-Connector waren noch zusätzliche Kanäle vorhanden, die daurchgeleitet wurden.

An Deinem Zitat "self.tableView" und dem was Du schreibst sieht man, finde ich, das große Problem der jüngsten "Verbesserungen" in Objective-C: Durch die dot-Notation spart man zwar Tipp-Arbeit, aber gerade "Migranten" von anderen Sprachen werden leider in die Irre geleitet. dot und dot sind eben nicht bzw. nicht immer vergleichbar und verhalten sich unterschiedlich. Durch die ähnliche Schreibweise wird aber suggeriert, dass auch die Konzepte identisch sind und das ist bei Objective-C zu so ziem…

Äh - Outlets? Und dann im IB mit einer Property verknüpfen? (#EDIT: .. mit ner custom-TableViewCell, hatte ich vergessen. Ansonsten das was unten steht) Das, was Du beschreibst, ist aber kein Storyboard-Problem, sondern dass Du noch nicht ganz durchschaut hast, wie das in Xcode/ObjectiveC funktioniert. Und wie sagte schon meine Mutter: "Andere Eltern, nicht ich."

Komischerweise scheint die Hürde, die man nicht kennt (custom UITableViewCell) immer höher zu sein, als die Hürde, die man nicht versteht (CoreGraphics). Oder umgekehrt. NIchts für ungut, aber das ist wirklich ein Fall für eine eigene Zelle.

Du könntest tatsächlich mal versuchen, die GestureRecoginzers des Scrollviews abzuklappern und mit Deinen Subview-GR über diese Methode zu verknüpfen: developer.apple.com/library/io…eGestureRecognizerToFail: Ich weiß aber weder, ob das geht, noch, ob man sowas in den Store bekommt. Wäre mal einen Versuch wert.

Zitat von joejohannesjoe: „Wäre sehr Leinwand, wenn mir jemand vielleicht einen brauchbaren Ansatz für mich?“ Wie meinen?

Zitat von Agenor: „1. "Nikidas" ist auf mich zu gekommen. Ich habe die App also nicht speziell zur Lizenzierung angeboten. Dort hat man sich vor der Anfrage also vermutlich Gedanken dazu gemacht, ob sich die Frage lohnt oder man lieber direkt ein eigenes Projekt startet.“ Muss nicht so sein. Ich bekomme immer wieder diese Anfragen und wenn ich denen dann einen Preis sage, der wirklich seriös ist und keinesfalls "mondig", sind die schnell wieder weg. Viele sehen eine Whitelabel-Version als Möglic…

- gelöscht -