2016-04-15 1 views
0

Ich baue eine einfache App, die Anfragen an die API stellt. Nichts zu kompliziert. Ich frage mich nur, ob das ein gutes Designmuster für die App ist. Ich mache etwas anderes als das, was ich normalerweise mache, weil dieses Designmuster viel besser aussieht. Ich weiß, es gibt Meinungen darüber, was das bessere Designmuster ist, aber es gibt einen klaren Unterschied zwischen akzeptabel und nicht akzeptabel. Das versuche ich herauszufinden.iOS: Ist das ein vernünftiges Entwurfsmuster für eine einfache iOS App?

Edit: Um die Fragen zu vereinfachen, ist dies ein gutes Design-Muster für eine App, die API-Anfragen an den Server und die Weitergabe von Objekten zwischen den Controllern macht?

View Controller 1.m.

- (IBAction)login:(id)sender { 
    NSMutableDictionary *params = [[NSMutableDictionary alloc] init]; 
    [params setValue:self.usernameField.text forKey:@"username"]; 
    [params setValue:self.passwordField.text forKey:@"password"]; 

    [apiClient loginRequest:params onSuccess:^(User *userInfo) { 

     ViewController2 *viewController2 = [[ViewController2 alloc] initWithNibName:@"ViewController2" bundle:nil]; 
     viewController2.userInfo = userInfo; 
     [self.navigationController pushViewController:viewControllers animated:YES]; 

    }onFailure:^(NSError* error) { 

    }]; 
} 

APIClient.m

- (void)loginRequest:(NSMutableDictionary *)params 
      onSuccess:(void(^)(id response))successBlock 
      onFailure:(void (^)(NSError *))failureBlock 
{ 
    AFHTTPSessionManager *manager = [[AFHTTPSessionManager alloc]initWithSessionConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration]]; 

    [manager POST:[NSString stringWithFormat:@"%@/login", URL] parameters:params progress:nil success:^(NSURLSessionDataTask * _Nonnull task, id _Nullable responseObject) { 
     User *user = [[User alloc]init]; 
     user.name = [responseObject objectForKey:@"name"]; 
     successBlock(user); 
    } failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) { 
     failureBlock(error); 
    }]; 
} 

User.h (dies ist das Modellobjekt)

#import <Foundation/Foundation.h> 

@interface User : NSObject 

@property (nonatomic,copy) NSString *name; 
// There is more properties, but I excluded them from this example 

@end 
+0

Was ist Ihre eigentliche Frage? Was ist mit dem Code, nach dem du fragst? – rmaddy

+0

Ist das ein guter Architekturentwurf für eine App, die API-Anforderungen an den Server stellt und Objekte zwischen Controllern umgeht? – Weakman10122

+1

Auf welches Architekturdesign beziehen Sie sich? – rmaddy

Antwort

0

Sie sollten nicht Implementierung in eine Header-Datei-setzen (wie in APIClient.h).

Ihr Code sieht gut aus, aber geben Sie bitte weitere Details zur Struktur Ihrer App an.

+0

Das war ein Tippfehler. Ich hatte die .m und .h zwischen Benutzer und Client gemischt. Das ist so ziemlich meine App. Der Benutzer meldet sich an, geht zu einem anderen View-Controller, wo der Benutzer alles dort machen kann. – Weakman10122

1

Es gibt zwei Aspekte in diesem Muster, die meiner Meinung nach mit wenig Aufwand besser sein könnten.

1) Aktuelle Benutzer Da Ihr Beispiel für die aktuellen Benutzer besser ist es, um in einem Singleton mit wie diese verwendet zu werden (von parse.com iOS SDK):

PFUser *currentUser = [PFUser currentUser]; 
if (currentUser) { 
    // do stuff with the user 
} else { 
    // show the signup or login screen 
} 

ist wirklich einfach zu Implementieren Sie dies und ist ein besserer Ort, um den Benutzer zu speichern, anstatt es von VC zu VC zu übergeben.

2) Ein API-Aufruf für ein Modell vor dem VC, in dem das Modell verwendet wird, ist meiner Meinung nach nicht der beste Weg. Ich würde die vc und onViewLoad mit einem Aktivitätsindikator schieben, während der API-Aufruf das Modell abholt.

Verwandte Themen