Con respecto al enfoque alternativo (usando methods y variables de class) a las variables globales en iOS

Recuerdo haber luchado en un momento particular de mi fase de aprendizaje con la implementación del concepto de variables 'globales' en iOS que se puede acceder en cualquier class a lo largo de la aplicación. Leí a través de muchos tutoriales excelentes como este por Matt Galloway .

Acabo de pasar por el código que finalmente implementé y me doy count de que lo había hecho de una manera muy diferente a cualquiera de estos tutoriales. Quería saber las posibles desventajas / ventajas del método que adopté

Mi file h fue algo así como:

@interface GlobalVariables : NSObject +(void)setUsername:(NSString *)string; +(NSString *)getUsername; @end 

y mi file m fue:

 static NSString *name; @implementation GlobalVariables +(void)setUsername:(NSString *)string{ name = string; } +(NSString *)getUsername{ return name; } @end 

Establecería la variable global en cualquier otra class como

 [GlobalVariables setUsername:@"user1"]; 

y getlo en otras classs como

 self.nameLabel.text = [GlobalVariables getUsername]; 

¿Hay algo malo / correcto en lo que hice? Cualquier comentario hacia la dirección correcta sería muy apreciado. Gracias 🙂

Lo que está haciendo es maloliente, pero cómo lo está haciendo está bien (casi – vea más abajo) …

básicamente hay situaciones inevitables en las que necesita almacenar el estado global …

deberías intentar tanto como puedas para evitarlos … aquí están mis divagaciones:

Si el estado que está guardando es realmente global y se accede con poca frecuencia, entonces guárdelo en los valores pnetworkingeterminados del usuario utilizando NSUserDefaults :

 [[NSUserDefaults standardUserDefaults] setObject:@"123456789" forKey:@"apiKey"]; [[NSUserDefaults standardUserDefaults] synchronize]; 

si su estado no es verdaderamente "global", entonces debería tratar de encontrar el context correcto, incluso si es artificial:

 @interface EncryptionContext: NSObject @property int someProperty @end 

Lo que está haciendo está bien, y lo prefiero a un singleton … básicamente cualquier cosa que pueda hacer con un singleton que puede hacer con un +[Class classMethod] o incluso un nakedCFunction()

en una aplicación multihilo, asegúrese de @synchronize sus @synchronize y progtwigdores para que siempre estén en un estado consistente.

En el código contado de reference, deseará conservar los nuevos objects y liberar los antiguos …

 static NSString *name; @implementation GlobalVariables +(void)setUsername:(NSString *)string{ id tmp = name; name = [string copy]; [tmp release]; } +(NSString *)getUsername{ return name; //or for more atomic operation [[name copy] autorelease] } @end