Der Kurs ist sogar ganz gut zwar ist bis jetzt nur die erste Woche verfügbar, aber ich habe zumindest schon eine ganze Menge gelernt.

Vorkenntnisse sind also nötig. Kann mir jemand ein gutes Buch/Video/andere Quelle empfehlen, die mir einen sanften Einstieg in das Ganze ermöglicht? Ich würde gerne einmal in diese Welt reinschnüffeln!

Edit: das Bild bringt wohl nix..

Es gibt bei YouTube ein paar gute SWIFT-Tutorials. Auch auf deutsch.
Es macht Sinn das Video jeweils einmal anzuschauen, dann einmal mitzuprogrammieren, danach das gleiche Projekt erneut, aber ohne Video. Es reicht, dies bei 5 Videos durchzuziehen und man hat eine gute Basis auf der man aufbauen kann.
Voraussetzung ist dass man eine andere Sprache bereits kennt. Komplett bei null anzufangen ist vermutlich nicht ganz so einfach.

The C Programming Language von Kernighan & Ritchie, den Erfindern von C. Das Buch ist sehr alt, aber immer noch relevant. Es deckt aber nicht die Feinheiten von C ab, deshalb empfehle ich auch Expert C Programming von van der Linden. Ich habe beide Bücher gelesen, und die Empfehlung hatte ich von hier:
http://fabiensanglard.net/c/index.php
http://fabiensanglard.net/books_recommendations/index.php

Und wenn dir jemand sagt dass C veraltet ist und nicht mehr benutzt werden sollte, dann ignorier ihn. Es gibt sehr viele C Bibliotheken die heute noch geschrieben werden, und C ist die Grundlage von Objective-C. Wenn du Swift benutzen willst, wirst du es mit Objective-C Code zu tun haben, und damit zwangsweise auch mit C.

Und dann wenn du C beherrschst kannst du das Swift Buch von Apple aus dem iBooks Store lesen. Swift führt auch einige neue Konzepte ein, die es in der C-Familie (C, Objective-C, C++) bisher nicht gab, wie etwa funktionales Programmieren (Funktionen als Typen erster Klasse, also dass man zum Beispiel Funktionen als Variablen haben kann oder dass Funktionen neue Funktionen zurückgeben).

Menschen lernen verschieden. Ich wäre aber sehr schnell motivationsbefreit wenn ich mit C anfangen müsste.
Da würde ich sogar eher Javascript als Basis vorziehen.

Ich hatte mit C# begonnen (Ende 2001 zur Beta), zu dem es damals recht schnell gute Bücher für Einsteiger gab. Allerdings würde ich dies, wenn das Ziel Swift sein soll, auch nicht empfehlen da man vom .NET-Framework schnell verwöhnt ist. Viele alltägliche Dinge sind sowohl in ObjC, wie auch in Swift, ziemlich umständlich. Auch XCode ist nicht wirklich hilfreich für Neulinge (schlechtes Intellisense/Auto-Complete, keine Namespaces, keine gute Suche nach Funktionen/Methoden/Eigenschaften beim Coden, wenig Automatisierung bei Verbindung von Views und Code). Im Vergleich zu Visual Studio finde ich XCode wirklich nicht gut. Leider. Man muss deutlich mehr Zeit investieren um Basics zu verstehen.

Objective-C-Kenntnisse braucht man bei der reinen Swift-Programmierung mittlerweile kaum noch. Die Sprache lesen zu können ist ein Vorteil, das lernt man aber schnell wenn man Swift versteht. Ich musste bisher (insgesamt!) eine Zeile Obj-C-Code in meinen Swift-Apps verwenden. Bei der ersten Beta (ich begann mit Swift am Tag 1) gab es allerdings noch keine Code-Beispiele der neuen Sprache in den Foren und Blogs (SourceForge & Co). Das ist mittlerweile allerdings deutlich besser geworden.

wow vielen lieben Dank für die zahlreichen Antworten - ich werde mir die Tipps zu Herzen nehmen

Hm, Menschen lernen offenbar wirklich verschieden. Sprachen wie C# kämen mir nie als Einstieg in den Sinn, weil sie so komplex im Sinne von umfangreich sind. C hingegen ist super-simpel und vor allem so elementar, dass man wirklich versteht, was man tut; das halte ich für einen guten Einstieg für entscheidend. Sonst ist man schnell bei denen, die das Schreiben von Excel-Makros für Programmieren halten.
Kannst Du ein paar Beispiele nennen?
Also abgesehen davon, dass Namespaces nichts mit der Entwicklungsumgebung, sondern mit der Programmiersprache zu tun haben, würde ich jetzt sagen, das ist so ein klobiges Konstrukt, das nur jemand gut finden kann, der mit sowas Komplexem wie C# statt sowas Simplem wie C begonnen hat.

Dafür darf man sich dann auch mit Dingen wie um eine manuelle Speicherverwaltung kümmern, der fehlenden Nähe zur Objektorientierung, fehlende Typsicherheit, prozedurale Programmierung, Pufferüberläufe etc.
C wirkt wie ein Relikt gegenüber den moderneren Sprachen. Sicher hat C seine Berechtigung, aber für einen Anfänger der Swift lernen will? Eine Sprache die ein komplett anderes Konzept verfolgt?
Ja:
- Generieren von 256-bittigen Hashwerten die mit den Standard-Hash-Funktionen anderer Sprachen kompatibel sind (z.B. PHP, Java, C# etc.)
- Berechnen von Zeiten (z.B. Zeitzonenberechnungen). Im Vergleich zu C# ein Grauen und umständlich!
- Anbindung an XML-basierten Webservices, selbst bei JSON-WS muss man verdammt viel von Hand machen. Da kann man schon mit einer wirklich mit mehreren Services kompatiblen Erkennung von Datumswerten mehrere Stunden verbringen wenn man keine externen Libraries von Drittherstellern einbinden will. Unter .Net eine Sache von Sekunden. Mit Bordmitteln.
- In Swift keine Statics innerhalb von Klassen möglich, man muss Workarounds schaffen (z.B. durch Structs)
- Eventhandling ist zwar vom Coding her ähnlich, in XCode aber nervig umgesetzt im Vergleich zu VS
- Exceptionhandling in Swift nervt. Es gibt Szenarien, gerade bei I/O, da ist ein try/catch/finally praktisch und durchaus angebracht.
- Konvertieren von Datentypen: In Swift meganervig, allerdings auch da sich in der Betaphase ständig was geändert hat.
- Datentypen wie String enthalten viel zu viele selten genutzte Funktionen, aber nicht so elementare wie .length. (Nur Swift, bei ObjC ist es drin)
- Mir fehlt ein Gegenstück zu z.B. int.TryParse(string, out int)
- Höhe von TextViews oder ScrollViews müssen manuell errechnet werden. Insbesondere bei TextViews bei dynamischen Inhalten ziemlich aufwändig.
- Anbindung anderer Datenbanken als CoreData nervt (Swift in iOS).

Ein paar Kleinigkeiten finde ich auch in Swift angenehmer (z.B. Arrays), aber das sind ehrlich gesagt wenige Dinge. Auch das Grundkonzept var / let finde ich angenehm und einleuchtend.
Sein Ziel ist aber nicht C, sondern Swift. Die Sprachsyntax hat sehr wenig gemeinsam. Wenn es um simples Lernen der Sprache geht, kann er auch wunderbar direkt im Playground mit Swift beginnen. Mittlerweile gibt es auch deutschsprachige Anfängerbücher zu Swift. Ich lerne ja auch nicht Autofahren in einem LKW. Oder umgekehrt.
Und Namespaces wird jeder gut finden der mal versucht hat irgendwelche Funktionen im UIKit zu finden. Z.B. mathematische Operationen/Konstanten (Wurzel, Pi, Sinus etc.) Bei Swift direkt irgendwo auf Root-Ebene, zusammen mit gefühlt 3000 anderen Funktionen. Bei c# sind mathematische Operationen in System.Math alle zusammengefasst,einigermaßen logisch sortiert.
Suche durch Intellisense? Fehlanzeige in XCode.

Apple hat mit Swift schon vieles besser gemacht... aber insbesondere XCode braucht dringend ein paar Verbesserungen... Partial Classes wären nett (in Kombination mit der Anbindung von Views an Code) und Namespaces wären auch sehr hilfreich für Swift gewesen um das Wirrwarr mal ein wenig zu entwirren. Wenn ich so drüber nachdenke: Ich finde C#/.NET sehr viel mehr Apple-like als Swift.

@Megaseppi

Die ganzen C# Features die du aufgezählt hast sind keine C# Features sondern .NET Features. Genauso wie zum Beispiel NSString keine Objective-C Klasse sondern ein Cocoa Klasse ist. Und in beiden Fällen musst du eine Bibliothek importieren, also wo ist der Unterschied ob du nun in C eine XML Bibliothek importierst oder in C#? So wie du es geschrieben hast klingt es als wären das alles Bestandteil des Sprachstandards.

Aber zurück zu C, ich habe C absichtlich empfohlen weil C eine sehr kleine und einfache Sprache ist die einen nicht an der Hand hält. Man kann mit dem K&R C Buch die Sprache an einem Wochenende lernen und schon nützliche Programme schreiben und lesen. Es geht hier rein darum einem Anfänger zu helfen in kurzer Zeit eine brauchbar Sprache beizubringen damit er den Kursen folgen kann.

Javascript ist keine echte Programmiersprache, es muss immer von einem anderen Programm interpretiert werden, damit fällt es schon einmal weg. Geschichten wie Python oder Ruby auch. Nichts gegen Skriptsprachen, sie haben ihre Einsatzgebiete, aber darum geht es nicht.

Dass C kein automatisches Speichermanagement und keine Objektorientierung hat ist in diesem Fall sogar gut. Betriebssysteme werden heute noch in C geschrieben, aber in C# wird nie jemand ein Betriebssystem schreiben.

Manuelles Speichermanagement und Zeiger sind gut damit ein Anfänger versteht wo seine Daten entlangfließen, wie ein Speicherleck entsteht, was der Heap und was der Stack ist und wie Daten an eine Funktion weitergegeben werden. Der Anfänger wird bestimmt ein Speicherleck erzeugen, aber das ist gut, denn dann lernt er warum es passiert ist und weiß wie man den Fehler vermeiden kann. C# hingegen hat einen Garbage Collector der das Problem einfach unter den Teppich kehrt. Und wenn man den Fehler sehr oft macht, dann kriegt man plötzlich Performance Einbrüche weil der Garbage Collector nicht kostenlos ist.

Objektorientierung fehlt wirklich in C, aber prinzipiell ist das nicht notwendig, die Mächtigkeit der Sprache ändert sich nicht. Aber wer in C objektorientiert programmieren will, der kann einfach in Objective-C schreiben. Objective-C ist nichts anderes als eine Spracherweiterung von C, und wer Objective-C lernen will, der muss C beherrschen. Objective-C ist damit eine echte Obermenge von C, jeder C Code läuft in Objective-C.

Dann kommen wir dazu dass du angeblich kein C in deinem Code hast. Das glaube ich dir nicht, du verwendest garantiert Cocoa Klassen, und die sind in Objective-C geschrieben, also verwenden sie C. Jeder wird sich früher oder später damit auseinander setzen müssen wenn er die Dokumentation einer Klasse lesen will.

Und zuletzt IDEs (Integrated Development Environments): Ich habe Xamarin Studio verwendet und genau das ist der Grund warum ich keine IDEs verwende, sondern nur noch Vim und Befehlszeilenprogramme wie Make, Git oder Ctags.

IDEs haben den Nachteil dass sie den Benutzer an sich binden, man kann ein XCode Projekt nicht einfach so auf einen Linux Rechner ziehen und öffnen. Der Benutzer hat auch nur indirekt Kontrolle darüber was er an den Compiler schickt. Überhaupt hat man nur indirekt Kontrolle darüber was im Projekt passiert und ich habe oft genug alte XCode Projekte heruntergeladen die nicht mehr kompiliert werden konnten weil das Projektformat sich geändert hatte und man irgendwo irgendein Häkchen anders setzen musste.

Das bedeutet nicht dass jeder sofort mit Vim oder Emacs anfangen muss, für den Anfang tut's auch ein Editor wie Sublime Text. Ein Makefile muss auch nicht fünfzig verschiedene Targets enthalten, für den Anfang reichen zwei, drei Zeilen an Anweisungen. Man kann dann mit seinen Fähigkeiten wachsen und mit der Zeit entwickelt man sein eigenes Verständnis dafür was am besten funktioniert. Dann kann man auf Vim oder Emacs umsteigen, Plugins installieren oder schreiben und Vorgänge automatisieren.

Das einzige was man dabei verliert sind Tools wie der Interface Builder, aber es ist ohnehin besser sein Interface programmatisch zu erzeugen. Und notfalls kann man die XIB Dateien auch im Texteditor bearbeiten, sie sind normale XML Dateien. Dann kann man sie mittels Ibtool (Befehlszeile) zu einer NIB kompilieren. Natürlich alles mittels Makefile automatisiert.

Der Punkt ist, der Quellcode wird nicht auf magische Art zu einer App, und wenn man versteht welche Zwischenschritte da stattfinden, dann hat man auch die Kontrolle über sein Projekt. Man kann sein Projekt nicht automatisieren wenn man nicht versteht was man automatisieren soll. Und dann muss man es auch nur einmal lernen und nicht in ein paar Monaten wieder schauen dass das Projekt auch mit XCode 7 kompatibel ist.

EDIT: ich sehe auch gerade dass du eine Unwahrheiten über Swift geschrieben hast
- Statische Methoden in Swift heißen Type Methods
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Methods.html
- Exception handling läuft über NSError (hallo Cocoa und Objective-C)
Wahrscheinlich sind noch mehr Fehler da, aber mir geht die Zeit zum editieren aus.

Es ist ziemlich irrelevant ob das Feature in C# oder in .Net ist. Letztlich geht es darum ein Problem möglichst schnell zu lösen. Mit Swift / Cocoa braucht man für viele Dinge einfach länger da viele alltägliche Dinge dort fehlen.
Programmierung nur auf die Sprache zu reduzieren ist zu wenig. Mit Swift kam ich in wenigen Stunden klar, die Herausforderung sind die Frameworks.

Die von mir beschriebenen Libraries sind Bestandteil des .net Frameworks. Für Swift / ObjC gibt es nur irgendwelche Lösungen die entweder Open Source sind und etwa 6 Monate am leben bleiben - oder aber kostenpflichtige Lösungen.

Natürlich "verwende" ich Cocoa Klassen, die in ObjC geschrieben sind - das ist aber total irrelevant da ich dafür null Zeilen ObjC verstehen, geschreibe denn schreiben muss.



Nicht statische Methoden, sondern statische Variablen. Da hieß es zuletzt als ich sie zu verwenden versuchte etwas in der Richtung "static variables are not implemented yet".
http://stackoverflow.com/questions/26804066/does-swift-has-static-variable-in-class
Es kann sich aber in der aktuellen Beta geändert haben, bin hier gerade unter Windows und kann es nicht testen.

Exception handling gibt es, aber wie geschrieben nicht wie in ObjC oder C# mit try/catch/finally. NSError nervt. http://owensd.io/2014/07/09/error-handling.html

Mit Xamarin kam ich überhaupt nicht klar.

BITTE, kann mir jemand etwas empfehlen, wie man von REALbasic/Xojo auf XCode umsteigen kann, egal ob ObjC oder Swift, Hauptsache es geht mit XCode. Ich will nach all den Jahren und fruchtlosen Versuchen endlich mit iOS-Development anfangen!
Es gibt zwar jetzt seit Dez. 2014 einen iOS-Compiler in Xojo, der ist auch ziemlich nett, da sooo schön einfach. Aber leider auch eingeschränkt und nicht gerade billig. Für einfachere Apps auf jeden Fall in Ordnung. Aber es gibt z.B. viele Controls nicht. Nur ein Open-Event, was einem WillLoad entspricht und keinem DidLoad (wo ich dann auch entsprechende Dimensionen vom Objekt bekommt, was vor dem Laden ja nicht da ist, bzw. eben falsche Werte hat) - hab dafür zwar schon ein Workaround gefunden, aber:
Ich will 2D-Spiele machen, habe da schon ein paar im Sinn. Und im Xojo gibt es nur den Canvas. Da kann man zwar schön der Reihe nach zeichnen, wie es gehört, und auch Scale, Rotate, Transform ist drin, aber habe:

1. Angst wegen Performance. Wenn das auf irgendeinem lahmen Framework basiert ist das bei 20-30 Sprites schon überfordert. k.A. ob das OpenGL nutzt, müsste ich erst rausbekommen.

Und 2. In SpriteBuilder (wäre dann auch für Android-Ports geeignet) und Apple's eigenem SpriteKit ist eben schon alles drin für Collision Detection, Physik, usw. usf. Das müsste ich in Xojo alles selber machen. Klar Collision für Rechtecke und Kreise ist ja noch recht einfach. Komplizierter wird es aber, wenn dann Drehung von Rechtecken dazu kommt.
In Xojo würde ich eine SubKlasse vom Canvas machen und müsste dann alles komplett selbst implementieren. Würde das vermutlich dann ähnlich, wie beim SpriteIrgendwas machen, dass ein Timer drin ist, der alle Bewegungen abarbeitet, so dass man eben auch sagen kann:
ObjektX.MoveTo(x, y, Zeit) - das schöne in SpriteKit/SpriteBuilder (basiert auf Cocos2D), da wäre eben alles schon drin & es basiert auf OpenGL, ist also mit Sicherheit auch flott genug. Dazu gratis, bzw. OpenSource (SpriteBuilder) und bei letzterem auch Android-Port möglich.

3. Natürlich der Preis. Allein für iOS 299$ pro Jahr. Und das braucht man jedes Jahr, wegen dauernden Änderungen bei Apple.

Leider braucht man aber für beides Objective-C oder Swift. Habe auch keine Ahnung von C# oder .NET oder Mono oder Xamarin. Nur RB/Xojo und ein paar ganz einfache Sachen in XCode habe ich schon hinbekommen (meist mit Tutorials)

Also das ganze Objektorientierte mit den Pointern, Properties, Methoden, usw. usf. ist klar, RB/Xojo ist ja Objekt-Orientiert, aber das ganze XCode/Cocoa-Zeug ist einfach so derbe kompliziert (wirkt zumindest so), während Xojo so extrem simpel ist. (wirkt auf mich zumindest so)

Da kann ich nur absolut zustimmen! XCode ist ein Graus. Alles muss man auswendig wissen oder irgendwo raussuchen, mit Namespace wäre das VIEL einfacher.
Ein schöner Dot-Syntax wäre auch fein, und Parameter einer Methode einfach in Klammern angeben, anstatt so seltsam, wie derzeit.
Selbst einfachste Sachen sind ziemlich kompliziert, und die Dokumentation hilft auch nicht viel, da NIE ein Beispielcode dabei ist, (Bei Xojo steht für jede Methode einer jeden Klasse Beispielcode drin) da muss man dann immer rumprobieren, wie der Syntax passt, usw.
Und das schlimmste: 1-2 Jahre später ist alles wieder deprecated und ich habe absolut keinen Plan, wie man sowas auf den aktuellen Stand bringen soll. Mit viel Mühe habe ich irgendwann mal einen Ersatz für irgendwas ausgelaufenes gefunden (war irgendwas wegen einer KeyboardWillShowNotification, das rect vom Keyboard wegen den Dimensionen), aber absolut NULL Erklärung, wie man das jetzt ersetzten soll. (in Xojo geht das vollautomatisch beim Öffnen des Projekt, man wählt bei den Warnings Check All, Resolve und fertig - warum kann XCode sowas nicht )

Bitte DRINGEND um Rat, wo ich ein Xojo nach XCode Tutorials oder ein Buch, o.ä. finde!
Besten Dank im Voraus!

PS: Für Desktop-Apps reichen alte SDKs, da kann man mit RB2007 auch noch nette Programme basteln, bei iOS ist nach 1 (spätestens 2) Jahr(en) aber wieder alles veraltet. D.h. bei Xojo müsste ich auch quasi zwingend die 1-Jahresupdates immer verlängern. (am Desktop reicht alle paar Jahre mal, und ist dazu noch umfangreicher & billiger)

Also würde ich gerne endlich den Weg zu XCode schaffen (seit 2009 mehrmals vergeblich versucht)

Stefab

Irgendwie machst Du auf mich den Eindruck, dass Du dir selbst ziemlich im Weg stehst.

Einerseits scheinst Du bereits eine Menge Ahnung von / Erfahrung mit Programmieren zu haben; das suggeriert jedenfalls Dein längeres Posting.

Andererseits hast Du anscheinend eine völlig irrationale Angst vor Objective-C und Xcode.

Da beides super-simpel ist, lässt sich das für mich nur so erklären, dass Du durch Deine bisherigen Erfahrungen so sehr auf bestimmte Muster fixiert und „verformt“ bist, dass alles andere Dir schwierig erscheint.

Nur ein Beispiel pars pro toto:

Versuche mal einen Moment Deine bisherigen Erfahrungen mit Syntax von Programmiersprachen völlig zu vergessen und schaue Dir die beiden folgenden Zeilen an:


und


Was von beidem kannst Du ohne jegliches Vorwissen besser verstehen?

Und doch schreibst Du:
Ist Dir klar, dass die Dot-Syntax jedem natürlichem Sprachverständnis komplett zuwiderläuft? Ein Punkt beendet in natürlichen Sprachen einen Satz! Und doch scheint die Dot-Syntax Dir „schön“ und die der natürlichen Sprache nachgebildete Syntax „seltsam“.

(100, 10, rot, blau, 75, 5) findest Du einfacher zu verstehen als Durchmesser:100 randstärke:10 flächenFarbe:rot randFarbe:blau mittelpunktX: 75 mittelpunktY:5? Ohne Vorprägung nie und nimmer!

Und mit Xcode ist’s genau dasselbe!
wirkt – genau das ist Dein Problem. Ich habe dereinst als blutiger Laie mit Objective-C begonnen, weil ich es so super-simpel fand, einfacher zu verstehen als alles andere! Aber ich kannte auch kein RealBasic und keine Dot-Syntax …

Statt Zeit und Energie damit zu vergeuden, Angst zu haben und auf ein ominöses Wundertutorial zu warten, verwende Deine Energie drauf, einfach loszulegen und Deine „Schreibhemmung“ zu überwinden! Nichts kann Dein eigenes Schreiben ersetzen. Versuche, Deine bisherigen Erwartungen an Syntax etc. einfach mal zu vergessen. Das Netz ist voll von Cocoa- und Objective-C-Tutorials, und falls Du ein Buch magst: Hillegass / Cocoa Programming for Mac OS X ist das Standardwerk (aber das dürftest Du ja vermutlich längst mitbekommen haben).

Und übrigens: für wirklich jede Cocoa-Methode gibt es in der Xcode-Hilfe ein oder mehrere Beispielprojekte, die man direkt aus der Hilfe öffnen und kompilieren kann – und dann siehst Du bei einem tatsächlich laufenden Programm sofort, wie’s gemacht wird.

Mut!

weia: Stimmt schon zum Teil, die Sache ist halt immer, woher weiß ich, was ich da angeben muss, bzw. wie komme ich überhaupt auf erzeugeKreis?

Wenn ich in Xojo eingebe:

grafik. und Tab drücke, erscheint schon mal alles, was da hinkommen kann, z.B. erzeugeKreis, wähle ich das aus (sehe grad, man muss mit Mauszeiger rüberfahren, ob das früher nicht immer auch schon beim tippen stand?), steht unter dem Codeeditor:

zeichneKreis(Durchmesser As Double, Randstaerke As Double, Flaechenfarbe As Color, RandFarbe As Color, MittelpunktX As Double, MittelpunktY As Double)

Vorausgesetzt, ich habe mir so eine Methode angelegt und grafik ist eine Instanz der Klasse mit dieser Methode.
Also weiß ich auch gleich, was in die Klammern gehört. Wenn ich mir die Methode so nicht selber bastel, sieht der Code standardmäßig so aus (für iOS, bei OS X leicht anders)

Fahre ich über das FillOval steht unten:
iOSGraphics.FillOval(x As Double, y As Double, width As Double, height as Double)

Koordinaten sind da immer links oben (habe MittelpunktY von 5 auf 105 geändert, da sonst teilweise außerhalb), d.h. für das zeichneKreis, wie angegeben, müsste ich mir die eigene Klasse basteln, aber das ist ja auch gleich gemacht.
Mehr als den Code oben, braucht es aber für die GANZE App nicht! Man muss vorher noch den Canvas ins iOSView ziehen, mit z.B. Rechtsklick darauf: Add Event Händler und Paint auswählen, dort den Code rein, kompilieren, fertig.

Wie gesagt, es ist mir ein wenig eingeschränkt, da ich mir ein komplettes SpriteSurface selber basteln müsste.

Aber da is nix von irgendwelchen App-Delegates, komischen Definitionen und vor allem, in das Paint-Event wird übergeben "g As iOSgraphics", also wenn ich wissen will, was kann ich zeichnen, gebe ich ein g. und drücke Tab, mehr nicht.

In Xcode sind es immer tausende Sachen die zur Verfügung stehen, man hat aber keine Ahnung was. Und wenn man jetzt irgendwelche Events haben will, muss man wissen, wie die passenden zur Klasse heißen, manchmal sind die gar nicht da, wie eine KeyboardWillShowNotification, dann muss ich wieder irgendein Delegate irgendwo kompliziert einbauen - woher soll ich wissen, woher ich das nehmen soll, also wie das richtige heißt und wo genau ich das dann hinschreibe? Und wie da z.B. dann die passenden Events heißen? Und die passenden Events? Das mit der KeyboardWillShowNotification habe ich nur zufällig in einem Tutorial gefunden.

Und die sind z.T. wieder deprecated, weil das "UIKeyboardBoundsUserInfoKey" nicht mehr passt und die Events daher nicht mehr richtig funktionieren - das Textfield wird jetzt immer weiter nach oben geschoben, anstatt richtig zu funktionieren, wie früher.) Bei dem Projekt ging es um einen SMS-Zähler, was je eh überflüssig ist, aber trotzdem.

Ich will das endlich mal verstehen!

Ja, aber da gilt eben wirklich: Es gibt nicht Gutes, außer man tut es.

Ich verstehe, dass die Vielfalt von Cocoa zu Beginn erschlagend ist. Aber Delegates zum Beispiel sind ein extrem mächtiges Konzept, mit dem Du ganz viel machen kannst. Klar, wenn Du wie in RealBasic nur einen Ausschnitt der Funktionalität abbildest, dann kannst Du das Ganze auch viel einfacher verpacken. Die Komplexität ist halt der Preis für die Möglichkeiten. Aber gemessen an den Möglichkeiten ist Cocoa sehr gut strukturiert.

Es ist ein bisschen so wie z.B. beim Fitnesstraining: Am Anfang hast Du nur Muskelkater und siehst Null Erfolg. Wenn Du in dieser Phase aufgibst und es ein paar Monate später wieder mal probierst usw. usw., wirst Du zu dem Ergebnis kommen: das bringt alles nix, x-mal probiert und ich schaffe das nie. Du musst einmal so lange am Ball bleiben, bis plötzlich die Zahnräder beginnen ineinanderzugreifen.

Und wie gesagt, wenn Du gerne mit einem Buch anfängst, wäre das von Hillegass meine wärmste Empfehlung. Sobald Du Tritt gefasst hast, kannst Du aus den Unmengen von Apples Beispielcode Dir auch einfach ein Projekt aussuchen, das Dich interessiert, und anfangen, damit herumzuprobieren.

PS: In RB gab es auch noch nicht immer die Namespaces, sondern vieles global, die kamen erst mit Xojo (soweit ich weiß), da musste man auch auswendig wissen oder nachsehen. Es geht immer noch beides, z.B. xoxo.Core.Point bzw. nur Point oder xojo.Core.Math.RandInt bzw. nur RandInt, finde die Namespaces aber weitaus sinnvoller, da man dann eben die entsprechende Auflistung für Math-Funktionen kriegt, wenn ich eingebe xojo.Math. - Tab.

Weia: Und irgendein Plan, wo man online gut einsteigen kann? Die Bücher sind so schnell veraltet. Hab noch das "Beginning with iPhone Developement" für iOS 2 bzw. Videokurse für iOS 5, aber das ist ja alles schon wieder mindestens 3x überholt.
Und das iOS-Framework ist bei xojo noch mehr eingeschränkt, da sehr neu. Da müsste ich mir eben so ein SpriteSurface erst selber basteln (z.B. als Subklasse vom Canvas) mit Timer, usw. wo alles abgearbeitet wird, so dass man einem Sprite auch so Befehle geben kann, wie SpriteX.MoveTo(x, y, Zeit) usw. Schwierig wird dann die Kollisions-Detektion, für Rechtecke & Kreise ok, aber sobald das Rechteck gedreht wird, wird es schon wieder kompliziert. Und sowas, wie Physik kann ich wohl komplett vergessen (zu viel Aufwand). Auch habe ich keinen Plan, was die Performance angeht. Weiß man ja nicht, ob das mit OpenGL zeichnet oder irgendwas langsamen. Leider bringt ein Stresstest im Simulator wenig, da geht auf meinem Core2Duo auch das SpriteKit schnell in die Knie, welches nativ aber superschnell ist.

Wegen all dem (und späterer Möglichkeit, nach Android zu portieren) würde ich am liebsten den SpriteBuilder (basiert auf Cocos2D & anderen Frameworks) nutzen. Aber auch da muss man den Code in ObjC oder Swift schreiben. SpriteKit ist ja ähnlich, wenn ich da ein neues Projekt mache, der Code in GameScene.swift bzw. GameScene.m geht ja noch so, aber der GameViewController ist schon wesentlich undurchsichtiger. Da fangen einige Sachen sogar mit einem Punkt an, ist also umgekehrte Logik?

Womit kann ich anfangen?

(Was mich auch ein wenig stört: Man muss alles immer speichern und es wird auch jede Änderung sofort gespeichert, also keine ungesicherten Testprojekte möglich, ansonsten muss man sich wohl angewöhnen, Snapshots zu machen, bevor man irgendwas rumexperimiert, was dann nicht funktioniert und das Projekt ruiniert - da muss ich wohl durch - allerdings habe ich es auch nicht geschafft, ein angefanges Projekt nachträglich umzubennen)

Weiters stellt sich natürlich die Frage, ob das neue Swift einfacher verständlich ist oder ObjC mehr Sinn hat? An Swift gefällt mir schon mal, dass es keine .h Files mehr gibt, also etwas mehr Übersicht. Sonst seh ich da nicht soo viel Unterschied. Ob ; oder nicht, ist mir relativ egal.

Und dieses: Hillegass / Cocoa Programming for Mac OS X - da kann man ziemlich viel schon in der Buch-Vorschau auf der Amazon-Homepage sehen. Frage mich aber, ob das nicht auch schon wieder überholt ist? Auch ist das Ziel OS X und nicht iOS.
Bisschen was habe ich ja auch schon mitbekommen und ganz, ganz einfache Sachen krieg ich auch hin - aber viel nicht.

Bei den Tutorials zu folgen ist ja auch um einiges einfacher, als selbst was zu machen. Super wäre, wenn ich jemanden, der sich auskennt, mal im Chat bisschen was fragen kann oder so …

Der Sinn von Namespaces ist aber natürlich eigentlich nicht das einfachere Finden von Methoden …

Xcode listet Dir für eine gegebene Klasse beim Tippen auch sofort alle passenden Methoden auf – nur sind das halt fast immer sehr, sehr viele aufgrund von Cocoas Umfang.

Es kommt ganz sicher der Tag, wo Du Xcode sehr dankbar sein wirst, dass es alles immer gleich speichert. Rumprobieren ist trotzdem problemlos möglich, denn die Snapshots arbeiten absolut zuverlässig (basieren auf git).

Ich mag, wie Du dir vielleicht denken kannst, Swift aufgrund seiner Mainstream-Syntax und einiger anderer Sachen nicht sehr, aber Du könntest dann vielleicht Deine schlechten Angewohnheiten beibehalten … Nur ist Swift halt noch jung, instabil (gerade auch was die API betrifft) und viel weniger gut mit Beispielen dokumentiert; von daher würde ich jetzt so oder so noch zu Objective-C raten. Eines wird grundsätzlich bleiben: Wenn Du irgendwelche ausgefuchsten Low-Level-Sachen in C machen (bzw. als Open Source aus dem endlosen öffentlichen Reservoir an C-Code übernehmen) und in Dein Programm integrieren willst, dann geht das in Objective-C weitaus einfacher als in Swift. Für mich persönlich fiele Swift schon deswegen aus.

Wegen der Aktualität von dem Hillegass-Buch brauchst Du dir keine Sorgen machen. In Xcode sieht irgendein Button jetzt vielleicht anders aus, aber alles Wesentliche ist aktuell. Und stimmt, es ist für OS X – wenn Du iOS only machen willst, gibt’s aber glaube ich auch ein Buch aus der Reihe – aber das kenne ich nicht.

Meine wegen dem Speichern jetzt eher, dass es etwas nervt, jedes Beispiel abspeichern zu müssen, da man nachher wieder alles löschen muss, das macht das Testen von Examples zeitaufwendiger (nachher immer aufräumen notwendig, wenn man da mal ein paar Dutzend Sample-Sachen nur mal schnell kompilieren und ansehen will, was das macht, kann da schon was zusammenkommen). Aber ok, kann man nix machen …
Das mit dem Auto-Speichern ist ja ok (nur bisschen Umgewöhnung), dank Snapshots. (auch wenn ich mir angewöhnt habe, bei jeder sinnvollen Änderungen -s zu drücken, selbst, wenn noch so klein)

Weiß halt nicht so recht, ob ich jetzt mit Swift oder Objective-C anfangen soll. Auch wenn Swift wohl noch nicht so ausgereift ist, schätze ich mal, das es die Zukunft sein wird.

Welche schlechte Angewohnheiten meinst du? Und ansonsten wollte ich noch hinzufügen (damit das nicht falsch rüberkommt), dass ich nicht sagen wollte, dass Xojo nicht nur für iOS eingeschränkt ist, sondern natürlich auch bei Desktop-Apps, aber bei iOS ist es eben (noch) ein gutes Stück mehr, gibt z.B. gerade mal eine Hand voll Controls - da fehlt vieles. Ist halt generell eher für einfachere Apps geeignet (und wir wollten damals ein MMORPG mit RB machen - wegen Windows - einiges ging schon, haben sogar OpenGL verwendet). Man kann es zwar mit PlugIns und Declares erweitern, also mit Tricks geht schon vieles. Aber naja … dann lieber gleich Xcode. Kommt auch deutlich billiger.
Ein ziemlich großer Vorteil von Xojo finde ich aber, ist, dass man auch 10 Jahre alten Code noch "fast" ohne Änderungen öffnen und ausführen kann. Alles was überholt ist, kann man automatisch ersetzen lassen und dann muss man maximal noch irgendeine (oder 2) Kleinigkeit(en) anpassen.
Es haben sich natürlich auch paar Sachen geändert (anscheinend wegen iOS), z.B. verwendet man dort statt String Text, was jetzt, wie Integer, Double, Single usw. jetzt auch echte Klassen sein dürften und keine simplen Datatypes mehr. Aber alles Kleinigkeiten, die man sofort raus hat. Anstatt "s = str(i)" schreibt man jetzt "s = i.ToText" (wobei s ist String/Text, i Integer) und das .irgendwas geht normal nur bei "richtigen" Klassen.

Und habe jetzt zum Glück einen alten Freund gefunden, der vor 3 Jahren den Wechsel auf Xcode geschafft hat, der kann mir sicher viel helfen! Leider ist aber noch bis nächstes WE im Prüfungsstress.
Hat mir z.B. mal diese Tutorials vorgeschlagen: (falls ich gleich mit Swift anfange, da kann ich mich einfach nicht recht entscheiden)
Das Android-PlugIn von SpriteBuilder unterstützt zB noch kein Swift, aber so schnell, wie alles geht, kommt das sicher in paar Monaten auch.

Was ich bei Swift schon mal ein bisschen komisch finde, dass man bei einer Subklasse, wenn man dort die gleichnamige Methode, wie im Super implementiert, ein "func override" oder so reinschreibt. k.A. wozu das gut sein soll. Ist ja sowieso klar, dass die Methode vom Child immer zuerst dran kommt und die vom Super nur, wenn die darin dann auch aufruft.
Gut aber, dass ARC jetzt seit einiger Standard ist. Ist ja auch wesentlich sinnvoller, als eine Garbage Collection. (auch wenn sie recht lange dafür gebraucht haben)
Wie auch immer, das sprengt hier schon bei weitem den Rahmen, und werde da jetzt dann auch aufhören oder maximal ganz kurze Antworten geben & keine Romane mehr schreiben.

Eine Frage noch: Wenn ich eigene Klassen/Methoden/Properties, was auch immer, in XCode gebastelt habe, erscheint das dann auch bei der Autocompletion?

Schwer zu sagen. Hier und heute ist Swift, wenn überhaupt, erstmal eher eine Sprache für simplere Projekte.

Objective-C ist mit Cocoa in einer fast 30-jährigen Geschichte tief verbunden und wird vermutlich immer die „native“ Sprache bleiben. Andere Sprachen kommen und gehen. Klar, die „Neu = Besser“-Fraktion sieht in Swift jetzt natürlich die Zukunft. Aber wenn Du so um 2001/2002 jemanden ohne allzu tiefe Kenntnisse gefragt hättest, hätte Dir jeder gesagt, dass Java die Programmiersprache der Zukunft für Cocoa ist und Objective-C bald nicht mehr unterstützt werden wird …

Aber der wichtigste Punkt ist, dass das relativ egal ist. Der steilste Teil der Lernkurve bei Cocoa ist, einen Überblick über die vielen Klassen und ihre Möglichkeiten zu bekommen, ganz egal, ob man sie nun in Swift oder Objective-C anspricht. Swift und Objective-C selbst (ohne Cocoa) könntest Du jeweils problemlos vollständig an einem Wochenende lernen. Und wenn Du die Klassen erstmal kennst, ist es kein großes Ding, sie mit Swift statt mit Objective-C anzusprechen (oder umgekehrt).

Ich persönlich vermute, dass es noch auf Jahre hinaus weit mehr Code-Beispiele für Cocoa in Objective-C als in Swift geben wird und meine, dass schon allein deshalb jeder Cocoa-Programmierer auch Objective-C verstehen können sollte.
Dot-Syntax „schön“ finden
Aber natürlich! Ich frage mich schon, woher Xcodes hundsmiserabler Ruf bei Dir kommt – Du traust dem Programm ja offenbar jede Hirnlosigkeit zu …

PS: Bevor ich's lasse, noch abschließende Erklärungen: Werde jetzt eben einfach mal dran bleiben. Zuerst mit Online-Turials und Fragen im Chat, wenn das nicht reichen sollte, werde ich mir ein Buch suchen.

Und das mit dem Speichern ist eben wie bei neueren OS X Version eine gewisse Umgewöhnung. Da gibt es ja auch kein "Speichern unter …" mehr, sondern nur Duplizieren/Exportieren und jede Änderung wird sofort gespeichert, dafür kann man mit Snapshots zurück gehen.
(z.B. Füge ich jetzt 4 Seiten eines PDF (für die Arbeit) zusammen alle in Vorschau öffnen, Seite 2-4 an Seite 1 hängen, Exportieren und bei Seite 1 alles rückgängig. Vergess ich letzteres vor dem schließen muss zu dem vorigen Snapshot. Ist jetzt nicht schlechter oder besser (denke ich), sondern einfach nur anders und eine Umgewöhnung.)

Und wegen Dokumentation: Würde voll & ganz reichen, wenn Apple zu jeder Methode/Property 1-3 Zeilen Sample-Code dazu schreibt, damit man gleich sieht, wie das im Code aussieht (wie es in der Xojo Language Reference auch ist). Würde vieles einfacher machen. Auch wäre es natürlich schön, wenn man veraltetes Zeug (deprecated) automatisch aktualisieren lassen könnte. Aber was soll man machen …

Und Xojo für iOS ist extra teuer, da: 1. Kostet US$299,- für 1 Jahr Updates (statt 99 wie je 1 Plattform Desktop) und 2. braucht man quasi zwingend jährliche Updates (bei Desktop reicht auch alle paar Jahre). Desktop-Apps kann man mit älteren SDKs auch noch gut machen, bei iOS ändert sich aber ständig (noch) sehr viel mehr, da könnte man z.B. jetzt mit einer 3 Jahre alten Entwicklungsumgebung nix brauchbares mehr anfangen.
Hab zwar jetzt wieder angefangen, WEIL Xojo endlich iOS kann, verwenden will ich es aber trotzdem nicht wirklich, da es die ganzen Frameworks eben nicht dafür gibt (hab auch nur die gratis Testversion drauf). Heutzutage baut man sich seine Engine nicht mehr von Null an, sondern nimmt was fertiges (am besten Open Source), sonst sieht man alt aus.

Nun gut, dann fange ich mal mit den Tutorials in Swift (die vom Link oben) einfach mal an. Kann ja zwischendurch auch mal welche in ObjectiveC machen, aber werde die mal als Einstiegspunkt nehmen, mit irgendwas muss ich ja mal anfangen.
Und bei Java mochte ich nie, dass es immer über einen Interpreter läuft (soweit ich das verstanden habe), darum hat mich das auch nie interessiert & habs auch nie probiert.
Ach so, das. Ja, ich find's nicht schlecht. Man sollte natürlich auch schnell sehen können, was für Parameter übergeben werden können/müssen.
Ist gut! Dann werde ich wohl mal loslegen …