Suchergebnisse

Um mich als Autor des oben zitierten Artikels hier mal einzuschalten: das Ein- und Ausschalten des Network Activity Indicators ist eine Funktionalität von UIKit. Und UIKit-Methoden darf man (von wenigen Ausnahmen abgesehen) meines Erachtens nur aus dem Main Thread aufrufen. Also musst du in jedem Fall sicher stellen, dass der Code zum Setzen des Network Activity Indicator im Main Thread läuft. Ich würde die Methoden generell immer so aufrufen: Quellcode (3 Zeilen) oder: Quellcode (3 Zeilen)

Zitat von Manfred Kreß: „Die Ablage ist voll bis zum Rand mit Apps, die im Hintergrund warten.“ Die Ablage ist immer voll bis zum Rand mit Apps (solange man sie nicht manuell abschießt). Das heißt aber noch lange nicht, dass diese Apps auch alle im Speicher sind. Die Ablage ist lediglich eine Anzeige der zuletzt benutzten Apps. Sie trifft keinerlei Aussage darüber, ob eine App im Hintergrund ist oder nicht. Zitat von Manfred Kreß: „Und wie ist das dann zu handhaben, wenn man selbst keinen Speich…

Zitat von Thallius: „P.S. vlt weißt du jetzt warum ich sagte du baust Dir Stolpersteine. Hätte jeder Tab seinen eigenen ViewController hättest Du dieses Problem nicht“ Das mit den Stolpersteinen ist in meinen Augen Quatsch. Es hat doch jedes Tab seinen eigenen View Controller. Dass all diese View Controller dieselbe Klasse haben, ist völlig unerheblich. Hauptsache, es sind unterschiedliche Instanzen. @dyna: Aus meiner Sicht ist dein Ansatz völlig problemlos. Um den einzelnen View Controllern etw…

Andere Möglichkeit: NSDateFormatter hat eine Klassenmenthode namens Quellcode (1 Zeile)Wenn du der als Template sowas wie Quellcode (1 Zeile) übergibst, liefert sie einen zur Locale passenden Formatstring zurück.

YYYY != yyyy Siehe Referenz unter unicode.org/reports/tr35/tr35-10.html#Date_Format_Patterns

Twitter unterstützt HTTP Auth für die Authentifizierung nicht, sondern OAuth. Da NSURLConnection nur HTTP Auth unterstützt, musst du OAuth selber implementieren (oder eine Third-Party-Library dafür verwenden).

Zitat von gritsch: „der timer ruft eine methode auf.“ Wenn wir schon genau sind: der Timer sendet eine Nachricht an sein Target. Dadurch wird i.d.R. eine Methode gleichen Namens aufgerufen, das muss aber nicht so sein.

Leg in deinem Target eine neue Build Phase an (Copy Files) und gib als Zielordner "Resources" und als Subpath einen von dir gewählten Verzeichnisnamen an. Dann zieh die Bilder aus dem Xcode-Projekt in diese Build Phase und sie sollten auch im App-Bundle in diesem Unterverzeichnis landen.

Zitat von teeqemm: „bei mir dann allerdings auch weiter in den negativen Zahlen (während die Queue weiter abgearbeitet wird), bis die App dann irgendwann nen MemoryWarning bekommt.“ Testest du das, während der Debugger an der App hängt? In diesem Fall schießt das OS deine App nie ab. Das wahre Verhalten musst du ohne Debugger testen.

Ohne es ausprobiert zu haben, würde ich sagen: Erstelle eine ABPersonRef und rufe Quellcode (1 Zeile)auf.

Wie du in der Doku nachlesen kannst, liefert "YYYY" nicht notwendigerweise das aktuelle Kalenderjahr, sondern das Jahr, zu dem die aktuelle Kalenderwoche gehört. Und das ist eben noch 2010: Zitat: „YYYY: Year (of "Week of Year"), used in ISO year-week calendar. May differ from calendar year.“ Das Datumsformat, das du willst, ist "MMMM yyyy".

Zitat von junky94: „danke erstmal für die Antworten. Aber kann mir niemand sagen, wie ich schnell zu den ViewObjects kommen kann? Ich will nicht alle durchegehen. Ich will nur die gesuchten Objekte erhalten.“ Wie hast du denn gemessen, dass die Schleife ein Performance-Problem in deiner App ist? Optimiere nichts, was du nicht vorher gemessen und als Problem identifiziert hast. Wenn du keine Schleife benutzen willst, musst du dir die Objekte von Interesse eben von vorneherein in eigenen ivars mer…

Zitat von junky94: „wieso würde jetzt die for-Schleife for (ViewObject* object in view.subviews) alle Subviews als Resultat angeben und nicht nur die ViewObjects?“ Weil for ... in eben so funktioniert. Welchen Typ du in der Schleife angibst, ist für die Runtime völlig unerheblich. Er dient nur dem Compiler, die Anweisungen in der Schleife zu checken. Um dein Problem zu lösen: Quellcode (5 Zeilen)

Zitat von zerm: „Ausserdem ist %f ein FLOAT.“ Stimmt nicht. %f erwartet einen 64-Bit-Floating-Point-Wert (double). Sagt zumindest die Doku.

Zitat von tschloss: „Quellcode (1 Zeile)“ Diese Methode ist nicht Teil der Apple-API. viewWillAppear: ist eine Methode von UIViewController, nicht von UIView.

Zitat von raegtime: „:-) ... wenn ich über der ImageView eine transparente UIView lege in dem ich dann die Buttons habe sind diese auch anklickbar... wobei mich schon wundern warum ich einem imageview kein funktionstüchtigen Button adden kann... jemand ne Anmerkung dazu warum das nicht klappt?“ Weil UIImageView standardmäßig userInteractionEnabled = NO gesetzt hat. Damit reagieren weder der ImageView noch dessen Subviews auf Touches jedweder Art. Wenn du userInteractionEnabled = YES setzt, geht'…

Verstehe ich nicht. Die Asset-URL wird dir doch im completionBlock auf dem Silbertablett gereicht.

Laut Doku musst du kCGImageAlphaFirst verwenden. Mit kCGImageAlphaNoneSkipLast wird es wohl kaum funktionieren.

Der View Controller bleibt so lange am Leben, wie du oder ein anderes Objekt ihn retainst, er schmeißt bei einer Speicherwarnung lediglich seinen View aus dem Speicher. Wäre das anders, hießen die Methoden wohl nicht -viewDidLoad/Unload, sondern -viewControllerDidLoad/Unload. Diese Vorgehensweise ist sinnvoll, weil nicht sichtbare Views entbehrlich sind und potenziell sehr viel Speicher belegen. Dennoch solltest du bei einer Speicherwarnung natürlich nicht nur deine Outlets freigeben, sondern au…

Zitat von Koala: „Das würde ja heißen, dass wenn man mit dem View zuvor gearbeitet hat und einige Daten noch nicht gespeichert sind (z.B. wenn der Nutzer was in ein Textfield eintippt, was nicht gespeichert wird), diese dann verloren gehen.“ Stimmt. Unter anderem (aber nicht nur) deswegen solltest du Views nie zur Datenhaltung verwenden (Stichwort MVC).