[iOS] Anfänger verzweifelt ;-)

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • [iOS] Anfänger verzweifelt ;-)

    Hallo wie schon in der Überschrift geschrieben bin ich ein Anfänger und arbeite gerade an meinem 1. Projekt, folgendes Problem beschäftigt mich seit mehreren Tagen,

    Meine App besteht aus 4 Buttons die Farblich in Rot Blau Grün und Gelb gekennzeichnet sind, nun sollte es so sein dass wenn auf einen der 4 Button gedrückt wird sich die Farbe des Hintergrundes in eine der 4 Farben ändert ich komm einfach nicht drauf wie ich das anstellen soll, mit drand48 funktionierts nicht da werden ja Gleitkommazahlen zufällig ausgegeben und ich möchte aber nur die 4 bestimmten Farben ;)

    Würd mich freuen wenn mir da wer behilflich sein kann ;)
  • Ist bestimmt nicht die schönste Lösung aber du könntest bei den Actions einfach immer die selbe Methode aufrufen, also z.B. changeColor.
    In dieser Methode lässt du dir dann mit int number = (arc4random() % 4); eine zufällige Nummer zwischen 0 und 3 ausgeben (also 4 Zahlen).
    Danach setzt du einfach bei 0 die Farbe auf Blau, bei 1 auf Rot usw.

    So könntest du es lösen, wie gesagt sicherlich nicht die eleganteste Lösung aber funktionieren sollte sie.
  • *schulterzuck*

    Irgendwie etwas unklar, wo jetzt genau das Problem liegt. Ich werfe mal diese Zeilen in den Topf:

    Quellcode

    1. let colors: [NSColor] = [.red, .green, .blue, .yellow]
    2. let i = Int(arc4random_uniform(4))
    3. let newcolor = colors[i]
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?
  • @Chronisch: Wenn das die Lösung zur Frage sein sollte, dann würde ich ein Array mit den 4 Farbobjekte anlegen, und immer mit einem Zufallswert darauf zugreifen.

    Edit: Eben gepostet, plötzlich neuer Beitrag da. - So wie das Beispiel bei Torquato.
    * Kann Spuren von Erdnüssen enthalten.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von NSObject ()

  • matz schrieb:

    Das wird dem Compiler nicht gefallen, NSColor gibt's nur für macOS

    Oach, das ist doch nur eine Frage der Import-Statements und was man dem Linker mit auf dem Weg gibt... :P

    matz schrieb:

    NSColor noch mit UIColor tauschen, dann passt's :)

    NSColor, UIColor, Shmocklor... Who cares!? Mir persönlich wäre Colour ja lieber... ;)
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?
  • torquato schrieb:

    matz schrieb:

    Das wird dem Compiler nicht gefallen, NSColor gibt's nur für macOS
    Oach, das ist doch nur eine Frage der Import-Statements und was man dem Linker mit auf dem Weg gibt... :P

    matz schrieb:

    NSColor noch mit UIColor tauschen, dann passt's :)
    NSColor, UIColor, Shmocklor... Who cares!? Mir persönlich wäre Colour ja lieber... ;)
    Ich habe zuerst "mir wäre Closure lieber" gelesen :D
    Ja, aber NSColor wird einen Anfänger dann doch noch mehr verwirren ;)
  • NSObject schrieb:

    @Chronisch: Wenn das die Lösung zur Frage sein sollte, dann würde ich ein Array mit den 4 Farbobjekte anlegen, und immer mit einem Zufallswert darauf zugreifen.

    Edit: Eben gepostet, plötzlich neuer Beitrag da. - So wie das Beispiel bei Torquato.
    @NSObject Du hattest in einer früheren Fassung, wenn ich das recht erinnere, einen kleinen Codeschnipsel drinn, der die Zufallszahl abhängig von der Array-Größe ausgibt. Das ist natürlich viel besser, als es hardcoded wie in meinem Beispiel zu machen.

    Das hat mich dazu gebracht ein bißchen rumzuspielen und das Collection-Protokoll um eine computed-Property randomElement zu erweitern. Das sieht dann bei mir so aus:

    Quellcode

    1. import Darwin
    2. extension Collection {
    3. var randomElement: Iterator.Element {
    4. guard !self.isEmpty else { fatalError("Collection is empty!") }
    5. let cnt = UInt32(self.count as! Int)
    6. let rnd = Int(arc4random_uniform(cnt))
    7. let idx = self.index(self.startIndex, offsetBy: rnd as! IndexDistance)
    8. return self[idx]
    9. }
    10. }
    Alles anzeigen

    Die Casts wirken häßlich, scheinen aber soweit korrekt zu sein und auch mit exotischen Index-Typen klar zu kommen. Wenn da jemand eine bessere Idee hat...

    Der Vorteil solch einer Extension ist, daß das auch z.B. bei Slices funktioniert, die ja ihre Indices vom Mutter-Objekt beibehalten und nicht 0-basiert sein müssen.

    Nur ein bißchen Spielerei am Rande...
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?
  • torquato schrieb:

    @NSObject Du hattest in einer früheren Fassung, wenn ich das recht erinnere, einen kleinen Codeschnipsel drinn, der die Zufallszahl abhängig von der Array-Größe ausgibt. Das ist natürlich viel besser, als es hardcoded wie in meinem Beispiel zu machen.
    Ja, das war ObjC aus der Hüfte geworfen. Da ich nicht wusste, ob das unter Swift korrekt ist hab die Zeile gelöscht.
    * Kann Spuren von Erdnüssen enthalten.
  • NSObject schrieb:

    das war ObjC aus der Hüfte geworfen. Da ich nicht wusste, ob das unter Swift korrekt ist hab die Zeile gelöscht.

    Soweit ich mich erinnere war das etwas wie arc4random() % array.count. Das geht in Swift tatsächlich so nicht. arc4random() liefert einen UInt32 zurück und array.count ist Int. Die kann man in Swift leider so nicht ohne weiteres mischen. Deswegen in meinem randomElement-Code oben ja auch so ein Schlepp wie UInt32(self.count) und Int(arc4rand…).

    Für Swift 4 werden die Integer Protokolle überarbeitet. Wenn ich das auf Swift-Evolution richtig verstanden habe, sollen dadurch auch solche Casts implizit möglich oder zumindes vereinfacht werden.
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?
  • macmoonshine schrieb:

    +lol+
    Haben die endlich erkannt, dass diese überpingelig-strenge Typisierung ein ziemlicher Krampf ist?
    Nein. Die starke Typisierung wird (zurecht !) erhalten bleiben. Es geht eher darum, die Schnittstelle über Protokoll-conformance zu vereinfachen. Caveat: Sofern ich einige Aussagen der Entwickler richtig verstanden habe.

    Im übrigen. Eine Sprache, die sowas wie NSInteger und NSUInteger nötig hat (warum eigentlich nicht auch NSMutableInteger?), bekleckert sich auf dem Feld der Zahlen nicht unbedingt mit Ruhm. :D
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?
  • torquato schrieb:

    macmoonshine schrieb:

    +lol+
    Haben die endlich erkannt, dass diese überpingelig-strenge Typisierung ein ziemlicher Krampf ist?
    Nein. Die starke Typisierung wird (zurecht !) erhalten bleiben. Es geht eher darum, die Schnittstelle über Protokoll-conformance zu vereinfachen. Caveat: Sofern ich einige Aussagen der Entwickler richtig verstanden habe.
    Im übrigen. Eine Sprache, die sowas wie NSInteger und NSUInteger nötig hat (warum eigentlich nicht auch NSMutableInteger?), bekleckert sich auf dem Feld der Zahlen nicht unbedingt mit Ruhm. :D
    Dass Swift das Konzept der starken Typisierung beibehält, ist schon klar. Der Übergang zwischen starker und schwacher Typisierung ist auch sehr fließend. Ich bezog mich lediglich auf den Umstand, dass man sich selbst bei einfachen Rechenoperationen totcastet, wenn die verwendeten Variablen nicht die gleichen Typen haben. Überpingelig-streng finde ich zum Beispiel, dass das ursprünglich sogar für Operationen zwischen Typaliase und ihren Grundtypen galt. Anscheinend wurde das inzwischen geändert.

    Dass NSInteger und NSUInteger auch nur Typedefs auf Standard-Integertypen sind, deren Variablen in der Regel veränderlich sind, ist dir bewusst?
    „Meine Komplikation hatte eine Komplikation.“