Variabeln im globalen Speicher ablegen?

  • Variabeln im globalen Speicher ablegen?

    Hallo,

    in HTML gibt es SESSION, wo man Daten ablegen kann auf die man später leicht zugreifen kann.

    Ich habe in meiner Test App eine Anmeldung gebaut. Die Benutzerdaten benötige ich auch in den anderen Fenstern. Zusätzlich muss ich z.B. den Status (ein Feld meines Objects) meines Benutzerobjects ändern. Wie kann ich Variabeln global (wie Sessions unter HTML) über alle Klassen hinweg zur Verfügung stellen?

    Viele Grüße,

    xdever

  • Was meint ihr dazu?

    do this in class 1
    YourAppDelegate *mainDelegate = (YourAppDelegate *)[[UIApplication sharedApplication]delegate];

    mainDelegate.mystring = Label1.text;


    in class 2
    YourAppDelegate *mainDelegate = (YourAppDelegate *)[[UIApplication sharedApplication]delegate];

    label2.text = mainDelegate.mystring;

  • Ist Session wirklich etwas, was es denknotwendig nur einmal geben kann?

    Also auf jeden Fall würde ich mir mutmaßlich ne Klasse Session machen. Und du kannst dir dann immer noch überlegen, ob du für Vereinfachungszwecke (Was genau wird vereinfacht?) eine Klassenmethode +currentSession machst.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • xdever schrieb:

    Was meint ihr dazu?

    Du greifst über Setter und Getter auf die Variablen deines Application Delegates zu.
    Damit ist die Variable nicht global im Speicher abgelegt, dennoch kommst du jederzeit aus jedem Teil deiner Anwendung ran.

    Mit anderen Worten: gut so!
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Lucas de Vil schrieb:

    xdever schrieb:

    Was meint ihr dazu?

    Du greifst über Setter und Getter auf die Variablen deines Application Delegates zu.
    Damit ist die Variable nicht global im Speicher abgelegt, dennoch kommst du jederzeit aus jedem Teil deiner Anwendung ran.

    Mit anderen Worten: gut so!

    Man hat dann das Problem, dass die funktionale Klasse von der Klasse des App-Delegates abhängt. Das geht zwar, ist aber nicht schön. Als einfache Lösung aber zu gebrauchen.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Ändert dann nix an dem was Amin geschrieben hat. Ich finde das einfach eine bescheuerte Lösung. Wenn die Klasse meinetwegen Benutzername und Passwort braucht, dann gibt man ihm diese. Wenn es sich die aus einer festen Stelle holt, dann ist diese Klasse für nichts anderes zu gebrauchen oder wenn man sie mal wo anders gebrauchen will dann hat man nur Probleme.

    Was ist denn so schwer daran benötigte Objekte an eine Klasse zu übergeben ?

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Plany schrieb:

    Amin Negm-Awad schrieb:

    Also auf jeden Fall würde ich mir mutmaßlich ne Klasse Session machen. Und du kannst dir dann immer noch überlegen, ob du für Vereinfachungszwecke (Was genau wird vereinfacht?) eine Klassenmethode +currentSession machst.


    ich denke ein singleton klasse wäre hier genau richtig :P

    Wenn es denknotwendig nur eine Session gibt. Schau mal, was ich oben gefragt hatte. ;)

    Aber denknotwendig ist das eben nicht so. Und wieso ist es erforderlich? Wenn man das in eine eigene Klasse Session packt, dann muss die außerhalb der funktionalen Klasse, die die Session anlegt, nicht einmal bekannt sein. Ich kann auch ohne Weiteres Tests drauf anlegen.

    Dieses Hilfskonstrukt mit AppDelegate ist zwar bequem – ich mache das ja auch häufig aus Faulheit, aber eigentlich nicht schön.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Thallius schrieb:

    Ändert dann nix an dem was Amin geschrieben hat. Ich finde das einfach eine bescheuerte Lösung. Wenn die Klasse meinetwegen Benutzername und Passwort braucht, dann gibt man ihm diese. Wenn es sich die aus einer festen Stelle holt, dann ist diese Klasse für nichts anderes zu gebrauchen oder wenn man sie mal wo anders gebrauchen will dann hat man nur Probleme.

    Was ist denn so schwer daran benötigte Objekte an eine Klasse zu übergeben ?

    Gruß

    Claus

    Es wäre schon besser. Ob sich eine eigene Klasse lohnt, ist natürlich Tatfrage. Aber eine solche Sessionklasse könnte als reine Helferklasse nach außen unsichtbar sein.

    Wenn man allerdings jedes Mal alles über das AppDelegate löst, ist das nicht nur sichtbar, sondern auch noch collagiert. Dann kommt User-Management. Macht ich über das AppDelegate. Dann kommt wasweißichManagement. Mache ich über AppDelegate. Am Ende bekomme ich das nur noch mit Copy&Paste isoliert (fröhles Methodengesuche) und gar nicht getestet.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?