Suchergebnisse

Falls Du kein AutoLayout Verneiner bist, kannst zur Laufzeit bequem LayoutConstraints setzen. Beispielsweise kann der VisualFormatString etwa so aussehen: View mit Button 0 Punkt hoch (unsichtbar) : Quellcode (1 Zeile) View mit Button 40 Punkt hoch (sichtbar) : Quellcode (1 Zeile) Hier ist das schön beschrieben.. (Klick)

Bist Du sicher, dass der Webserver (vermute wegen der NTLM Authentifizierung IIS) überhaupt für URL Authentification konfiguriert ist? Standardmäßig ist das nicht aktiv.

OK, dann weiter wie bisher. Danke.

Ist es "heutzutage" eigentlich immer noch richtig oder gar notwendig, dealloc zu überschreiben und erzeugte Observer (z.B. für das Default NotificationCenter) mit "removeObserver" zu bereinigen? Die Apple Doku hat dazu "uralte" Beispiele und Referenzen. Bisher überschreibe ich Dealloc (ohne super.Dealloc aufzurufen) und nehme die Observer weg, bevor ich meine Instanzen zerstöre. Aber selbst Großmeister Jüstel handhabt dies offenbar unterschiedlich. In allen älteren Videos weist er jedesmal darau…

Klappt super. Ich habe jetzt alle unnötigen setNeedDisplay und collectionView.performUpdate Aufrufe rausgeworfen. setNeedDisplay setze ich nur noch in den Settern der Zellenklasse und collectionView.PerformUpdates muss nur noch im NavigationControllerDelegate und bei Orientation Änderung aufgerufen werden. Sehr übersichtlich... Danke euch beiden..

Gefunden... Aber vorher nochmal kurz zum Verständnis. Ich rufe setNeedsDisplay jetzt für jede Zelle in cellForItemAtIndexPath und sizeForItemAtIndexPath auf. Damit ist sicher, dass setNeedsDisplay beim Erstellen der Zelle und beim Ändern der Orientation für jede Zelle mindestens einmal aufgerufen wird. Ist das zu oft? Behoben hat es das Problem allerdings nicht, obwohl ihr mit dem Reuse Problem beide richtig lagt. In der meiner Cell Class hatte ich die Methode "prepareForReuse" überschrieben. Do…

Ah.. Danke. Dann baue ich mal ein bisschen um.

Das klingt irgentwie logisch, aber verstehen tue ich es trotzdem nicht so ganz. Wenn ich mir die ObjC Implementierung anschaue, dann mache ich, -wenn ich das richtig interpretiere- nichts anderes. Quellcode (14 Zeilen)

hasAmbiguousLayout ist eine Instanz-Methode von UIView Ich debugge das mal in Einzelschritten durch. Wenn ich was gefunden habe, hänge ich das hier noch für die Nachwelt dran.

Zitat: „Keine Sorge, als ich noch klein war, habe ich auch mal in Pascal entwickelt. +grusel+ ;)“ Oxygene ist das "Not Your Daddy's Pascal". Hat Sprachfeautures von denen C#'per, Java Entwickler, Delphi Menschen (wie ich) und auch ObjC'ler nachts träumen können und compiliert gegen .Net, WinRT, Java und ObjC (cocoa). Ich finds super. =) setNeedsDisplay rufe ich nicht explizit auf. Dafür habe ich "hasAmbigousLayout" der Zelle überschrieben und gebe dort immer "True" zurück. Vorher gab es den Effe…

Jetzt wird es glaube ich etwas kompliziert. Ich entwickle mit Qxygene. Das ist Pascal Code, der gegen die Objc Runtime compiliert wird. (Der ByteCode des Kompilats ist 100% identisch mit dem, den Xcode auch erstellen würde). collectionview:cellForItemAtIndexPath ist wir folgt implementiert... (ich kommentiere das mal stark, phonetisch entspricht die Syntax der ObjC "." Notation) Quellcode (15 Zeilen)

Die Datenquelle ist zur Zeit noch ein einfaches NSArray mit Werten von 1 bis 12. Das ist aber nun wirklich einfach Später wird es ein gefilterter Bereich aus dem EKEventStore, damit ich Tage mit Ereignissen noch ein bisschen bunt hinterlegen kann .. Ich glaube, dass mit das Standard-FlowLayout des CollectionViews diesen Streich spielt. Das Displayformat ist ja im Endeffekt der einzige echte Unterschied... Wenn der Detailcontroller geschlossen wird, dann stimmt die Ansicht während der "Dismiss An…

Ich habe einen merkwürdigen Effekt mit einem CollectionView (Universal App). Das iPad Storyboard habe leer erstellt und alle Inhalte vom iPhone Storyboard per Copy&Paste dort eingefügt. Die Eigenschaften der Views,Coltroller, Segues usw. sind 1:1 übernommen worden. Also aus meiner Sicht gleiche App mit gleich konfigurierten Storyboard. Wenn ich die App auf dem iPhone und dem iPad starte sieht sie grundlegend gleich aus und alle 12 Zellen des CollectionViews (Kalender) sind auf Basis der Datasour…

Zitat von macmoonshine: „Warum so kompliziert? Du musst einfach nur eine eigene View-Klasse schreiben, in der Du drawRect: überschreibst. Davon erzeugst Du pro Zelle einen View, den Du (wie oben) in den Contentview der Zelle legst“ Sag ich doch "Vermutlich bleibt aus Ausweg nur eine zusätzliche UIView, deren "drawRect" ich stattdessen überschreibe und die ich als subView auf den contentView der Zelle lege..." Danke. Du hast mich genau in die richtige Richtung geschupst...

Habe es jetzt wie folgt umgebaut.. In der CollectionDataSource erstelle ich mir beim Laden der CollectionView mit Hilfe der NSDateComponents vorbereite Kalenderdaten für das ganze Jahr. Dann habe ich die Methode drawRect der benutzerdef. Zellen-Klasse überschrieben und zeichne dort mit "TagXinWocheY".stringValue.drawInRect(...) den Kalender in den CG Context der Zelle. Die positiven Effekte sind: - der Aufbau der UI ist auf diesem Wege wirklich "rattenschnell" - da ich nur noch eine grafische Re…

Zitat von macmoonshine: „ Übrigens liegt Dein Perfomance-Leak an diesen vielen Labels. Es ist wahrscheinlich wesentlich performanter, die Zahlen direkt zu zeichnen. Dann brauchst Du auch Deine Views nicht zu cachen.“ Das habe ich auch immer geglaubt, ist aber nicht so. Wir hatten das Thema vor einiger Zeit schon einmal. Mein CollectionView liegt auf einem UIPageController. Wenn ich die Zellen nicht cache, sondern direkt in "MyCellClass.initWithFrame" fülle, dann hängt der PageController 2-4 Seku…

Für den inneren View klappt das in der Tat. Da habe ich an zu vielen Schrauben gedreht. Manchmal ist weniger mehr Die 50 UILabel im inneren werden aber noch nicht skaliert. Hast Du dafür auch noch eine Idee?

Hi, ich erstelle zur Laufzeit ein Array mit 12 UIViews, jeweils mit einer Größe von 94x94 px. In jeder dieser 12 Views liegen 50 UILabel (Font Size 7). Diese Views bereite ich aus Performancegründen beim Applikationsstart vor und lege sie in "cellForItemAtIndexPath" in die entsprechenden CollectionView Zellen. Den Zellen habe ich in "collectionview() Layout() sizeForItemAtIndexPath" eine feste Größe gegeben, so dass im Hochformat 3 Zellen nebeneinander liegen und im Querformat 4 Zellen. Im Hochf…

Falls mal jemand auf diesen Thread stößt und ein ähnlich gelagertes Problem lösen muss.... Die ScrollViewDelegate Methoden sind vermutlich der richtige Weg. Das Zeichnen von 500+ Zahlen mit <NSString>.drawInRect ... dauert beim Scrollen exakt genauso lange als würde man 500+ UILabel Instanzen verwenden. Das Problem ist vermutlich das 600malige Errechnen der Position, "an der etwas getan werden soll". Nicht erschrecken. Das ist Oxygene Code. (Wird aber genau wie Objektive-C über die ObjC Runtime …

Die UIKit Methoden zum "zeichnen" von Text entsprechen fast meinen Delphi Methoden "Canvas.TextOut(...)". Danke für den Link. Damit komme ich bestimmt klar. Zitat von macmoonshine: „ BTW. Warum verwendest Du nicht nur einen Collectionview mit horizontalem Scrollen und Abschnitten für die Darstellung aller Kalenderseiten? “ Hatte ich probiert, aber irgendwie habe ich es nicht geschafft, dass die Sections für die Kalenderseiten beim Scrollen jahresweise "einschnappen" (wie nennt man das ?). Mit de…