Xcode auf "großen" Monitor/Display

anhe

Aktives Mitglied
Thread Starter
Dabei seit
13.11.2007
Beiträge
1.899
Reaktionspunkte
309
Hallo zusammen,

ich persönlich nutze privat "nur" ein 13" MBPr ohne externen Bildschirm. Ich komme beim Programmieren (lernen) mit Xcode und dem verhältnismäßig kleinen Bildschirm einigermaßen zurecht, da ich bisher nur Konsolenanwendungen schreibe. Je nach Ausgabe muss ich halt die untere Zeile relativ hoch einstellen und kann nicht so viel Code anzeigen. Habe ich mehrere innerhalb eines Projektes zu bearbeiten, dann öffne ich mehrere Tabs und springe zwischen diesen hin-und-her.

Nun hatte ich heute Gelegenheit mir Xcode auf einem iMac 5k bildschirmfüllend anzuschauen. Natürlich könnte ich dort mehr Zeilen anzeigen, profitieren würde ich aber nur von der Höhe und nicht von der Breite des Bildschirms.

Wie handhabt Ihr das? Lassen sich auch mehrere Dateien nebeneinander anzeigen, ohne das zwischen der Tabs gesprungen werden muss. Kommt ein großes Display erst beim Programmieren mit GUI und/oder im iDevice-Simulator zur Geltung?

Grundsätzlich könnte ich mir nämlich auch die Anschaffung eines iMac 5k oder eines 5k-Displays (wenn denn auch DP1.3 in den Macs verfügbar ist) vorstellen. Bei anderen Anwendungen sind mir die Vorteile eines großen Displays klar. Beruflich nutze ich unter Windows einen 27"-Bildschirm und dort dann aber meistens zwei Anwendungen nebeneinander dargestellt.

Viele Grüße und ein schönes Wochenende

André
 
das wirst du wohl nur selber für dich entscheiden können
ich habe im Büro einen 27" iMac + 24" Monitor und zu Hause ein 13" MBPr mit 27" Thunderbolt Display + 24" Monitor
ich benutze den IB und Storyboard Mist nicht, aber wenn wäre hier ein großes Display wohl sehr von Vorteil
genauso habe ich auch nicht mehrere Datein gleichzeitig auf, das kannst du aber über den Assistent Editor lösen oder einfach einen doppelklick auf ein Projektfile
ich arbeite in einem File und springe per TastenKombi zwischen .h und .m hin und her, oder vorherige und nachfolgendes Projektfile
ich für mich sehe keinen Grund mehrere Files gleichzeitig aufzuhaben, die CodeCompletion zeigt mir schon was eine andere Klasse kann oder halt nicht
ich möchte es nicht mehr missen die Console immer ausgefahren zu haben, dafür nutze ich den Debugger/Breakpoints etc viel zu viel um das immer ein und auszublenden, genau so den Projektnavigator (Spalte links) oder den Utilities auf der rechten Seite

aber da hast du anscheinend einen anderen Workflow, wenn du deb Bedarf danach hast, mehrere files gleichzeitig auf zu haben
 
Hallo nussratte,

danke für Deine Antwort. Das heist zum Programmieren nutzt/benötigst Du gar nicht so viele Platz in der Breite? Von Workflow kann man bei mir noch nicht sprechen. Ich lerne das Programmieren (immer) noch ... Den Bedarf werde ich erst beurteilen können, wenn ich mich mit IB etc. beschäftigen werde. Da ich bei den Übungen mehrere Klassen erzeuge(n muss) hilft es mir hin-und-her zu springen.

Viele Grüße

André
 
Hallo,

meine Meinung dazu:

Für die Entwicklung von tollen Anwendungen bedarf es keinen großen Monitor.
Ganz im Gegenteil, es ist für mich sogar hinderlich.

Früher hätte ich immer kleine Rechner und als die Kohle am Start war hatte ich dann immer das größte Display. Später dann den 27er iMac etc.

Ich hatte die gleiche Meinung, wie so viele hier im Forum.
Auf einem großen Bildschirm lässt sich besser arbeiten.

Für mich hat sich das als Plunder herausgestellt.
Letztendlich hat man viel mehr Sachen gleichzeitig auf einer Fläche offen, die viel mehr ablenken.
D.h. neben Xcode war bei mir Mail, Skype etc. offen.
Aber mit "besser arbeiten" hatte das alles nichts zutun.

Ich habe früher 12 Stunden und mehr täglich gearbeitet.
Alles total ineffizient, da die Ablenkungen viel zu viel waren.
Mail, Skype etc.
Also reine netto Arbeitszeit mit produktiven Ergebnissen waren vielleicht 50%.

Heute arbeite ich fokussiert in kleinen Etappen an einem Projekt.
Damit ist man viel mehr bei der Sache und alle anderen Anwendungen bleiben geschlossen.

Und genau aus diesem Grund bin ich wieder zu 13".
Für mich die perfekte Größe.

Auch bei der Entwicklung von Programmen habe ich eine eigene Art entwickelt.
Bei mir macht jede Methode genau nur eine Sache.
Langen Code gibt es bei mir nicht. Deshalb brauche ich kein großes Display.

Muss ich eine Oberfläche aktualisieren, dann gibt es eine -updateInterface: die dann "Untermethoden" wie -updateTitleTextField:, -updateContentTable: etc aufruft.

Was will ich damit sagen?
Ich brauche eben genau auf Grund dieser Qualität an Quelltext, die ich an mich selbst stelle, schon gar kein so großes Display.
Meine Aufmerksamkeit liegt immer genau auf dieser einen Sache, also der Methode, die ich implementiere.
Und die sind auch keine Monster, die fünfzig Sachen erledigen.

Interface Builder und Storyboards etc. nutze ich eh nicht.
Für mich überwiegen die Nachteile der Wartung und Pflege etc. eh gegenüber dem Code.
Code ist viel schneller angepasst und nachvollziehbar.

Aber klar, wer Storyboards verwendet, für den ist ein großes Display sehr hilfreich.

Somit ist klar, dass die Displaygrösse auf die Arbeitsweise angepasst werden muss.
11" ist mir zu klein und 15" zu groß.

Mein MacBook Air mit über fünf Jahre alt ist das beste Preis-/Leistungsverhältnis Ding, das ich je gekauft habe.
Geld verschwenden für 27" iMac etc. würde ich nie wieder.

Meine Argumentation ist natürlich auf die Entwicklung von Anwendungen bezogen.
Für Grafiker etc. ist das natürlich nicht zutreffend.

Viele Grüße
 
Hallo little_pixel,

vielen Dank für Deine ausführliche Antwort. Das klingt alles sehr vernünftig und nachvollziehbar was Du schreibst. Zum Programmieren erlaube ich mir mal noch keine Meinung ("Programmieren lernen" betreibe ich momentan als Hobby zur Entspannung, alles was bei mir so Datenverarbeitung anfällt bearbeite ich mit Matlab. Also nicht "Coden" sondern nur "Skripten" ;) ). Leider kann ich das mit der Ablenkung durch Mails etc. bestätigen und habe auch weniger Disziplin konsequent Mails nur fokussiert zu bearbeiten als ich mir wünsche. So viel zum Thema Ablenkung und fokussierten Arbeiten.

Mit der aktuellen Displaygröße komme ich auch gut (beim Programmieren) zurecht, der Treiber für ein größeres Display wären hier andere Gründe und ich wollte eher schauen, ob sich dadurch auch hierfür Vorteile ergeben.

Auch wenn ich hier jetzt OT werde, so möchte ich gerne auf Deine Anmerkungen zu den Methoden eingehen um etwas zu lernen bzw. es rechtzeitig richtig zu lernen. Bisher habe ich Klassen erstellt die Methoden enthalten (ich hatte ja gerade im anderen Thread ein Beispiel mit den Song, Playlisten, etc.). Dort gibt es zum Beispiel die voneinander unabhängigen Methoden listAllSongs und listAllPlaylists. Was meinst Du mit "Untermethoden". Ist das jetzt eine Formulierung von Dir, oder lassen sich Methoden (z.B. list) und Untermethoden list_AllSongs und list_AllPlaylists erstellen?

Verwendest Du keine IB etc., weil Du keine GUIs erstellst oder nutzt Du andere Werkzeuge?

Und zu guter Letzt: Ich wollte Dir auch schon seit längerem Mal schreiben, dass ich Dich und Deine Beiträge sehr schätze. Sowohl hier bei macuser.de als auch im Entwicklerforum (wo ich mich nur lesend rumtreibe). Du hast eine vernünftige Einstellung zu den Dingen und sehr oft teile ich Deine Meinung.

Viele Grüße

André
 
Gude,

was die Größe angeht, wenn du mit dem IB und Storyboards arbeitest ist Bildschirmgröße mit nichts zu ersetzen. Mit meinem 13" MBA hat das keine Spaß gemacht, mit meinem 15" MBPr von der Firma geht es. Zum reinen Code schreiben reichen auch 11". Ein zweiter oder größerer Bildschirm lohnt sich z.B. auch wenn man gerade ein Buch/Tutorial liest und dabei Xcode und das Buch nebeneinander anzeigen möchte. Hier drehe ich auf dem Arbeits Mac die Auflösung hoch und kann Xcode und Vorschau bequem nebeneinander anzeigen und habe genügend Platz. Auf meinem MBA muss ich halt die Fenstergrößen anpassen wenn gerade kein 2. Monitor zur Hand ist, auch so kann man arbeiten. Letzten Endes musst du halt einfach testen was für dich am Besten ist.

Ich verstehe nur nicht warum man die Debug-Area die ganze Zeit offen haben muss. Hier sollten du und @nussratte evtl. mal einen Blick auf die Behaviors von Xcode werfen, findet ihr in den Preferences. Ich habe es z.B so eingestellt, dass die Debug-Area angezeigt wenn ich ein Programm starte und danach wieder ausgeblendet wird. Sollte ich sie zwischendurch brauchen um irgendwelche Logs zu prüfen hilft Shift+cmd+y.

Zu deiner letzten Frage, mit Untermethoden meint er dass er eine Methode updateUI: hat und diese Methode andere aufruft die einzelne Teile des UI updaten. das ist prinzipiell eine sinnvolle Sache, da die einzelnen Methoden kurz und übersichtlich bleiben, man muss nur aufpassen, dass man es nicht übertreibt. Im obigen Beispiel würde ich mich z.B. fragen ob updateTitleTextField: nötig ist. Aber hier kommt es einfach darauf an was die Methode macht, setzt sie nur einen anderen Text, würde ich mir den Overhead den ein Methodenaufruf macht sparen, wird aber z.B noch die Größe des Textfeldes neu berechnet und evtl. was an der Schriftart und -größe oder sonstiges geändert kann das schon wieder Sinn machen.

Gruß
Pierre
 
Hallo Pierre,

vielen Dank auch für Deine Antwort hier in diesem Thread. Bisher komme ich was das Programmieren angeht ja auch ganz gut mit meinen 13" MBPr (eingestellt auf 1440x900 Bildpunkte) ganz gut aus. Meistens habe ich mein iPad Air2 neben dem MB und lese dort das Buch in iBooks zum Lernen. Der Bedarf/Wunsch zu einem größeren Display ist eigentlich anderen Anwendungen geschuldet. Es hat mich halt nur interessiert, welche Vorteile ich "hier" auch zusätzlich geniesse.

Die Debug-Area habe ich offen, da ich mir dort die Meldungen meines Programms anschaue. Bisher sind es ja ausschliesslich Konsolenanwendungen, wie soll ich die Meldungen anders anschauen?

Danke zu Deinen Anmerkungen zu den Untermethoden. Soweit bin ich auch noch nicht, dass ich mit mit Update von UI-Elementen beschäftige.

Viele Grüße und noch einen schönen (3. Advent)-Sonntag

André
 
Zurück
Oben Unten