Meilleures approches architecturales pour la création d'applications réseau iOS (clients REST)

Selon le but de cette question, j'aimerais décrire notre approche architecturale.

Approche de l'Architecture

L'architecture de notre application iOS générale repose sur les modèles suivants: couches de Service, MVVM, liaison de données UI, injection de dépendance ; etprogrammation réactive fonctionnelle paradigme.

Nous pouvons découper une application de consommateur typique en suivant logique couches:

• Assemblée
• Modèle
• Services de
• Stockage
• Gestionnaires
• Coordonnateurs
• UI
• Infrastructure

La couche D'assemblage est un point d'amorçage de notre application. Il contient un conteneur D'Injection de dépendances et des déclarations des objets de l'application et de leurs dépendances. Cette couche peut également contenir la configuration de l'application (URL, clés de services tiers, etc.). À cette fin nous utilisons Typhon bibliothèque.

La couche de Modèle contient des classes de modèles de domaine, des validations, des mappages. Nous utilisons la bibliothèque Mantle pour mapper nos modèles: elle prend en charge la sérialisation/désérialisation au format JSON et aux modèles NSManagedObject. Pour la validation et la représentation de nos modèles, nous utilisons les bibliothèques FXForms et fxmodelvalidation.

La couche Services déclare les services que nous utilisons pour interagir avec des systèmes externes dans afin d'envoyer ou de recevoir des données qui sont représentées dans notre modèle de domaine. Nous avons donc généralement des services de communication avec les API serveur (par entité), des services de messagerie (comme PubNub), des services de stockage (comme Amazon S3), etc. Fondamentalement, les services enveloppent les objets fournis par les SDK (par exemple PubNub SDK) ou implémentent leur propre logique de communication. Pour la mise en réseau générale, nous utilisonsAFNetworking bibliothèque.

Le but de la couche de stockage est d'organiser le stockage de données local sur l'appareil. Nous utilisons des données de base ou Realm pour cela (les deux ont des avantages et des inconvénients, la décision de ce qu'il faut utiliser est basée sur des spécifications concrètes). Pour la configuration des données de base, nous utilisons mdmcoredata bibliothèque et tas de classes - stockages - (similaires aux services) qui fournissent un accès au stockage local pour chaque entité. Pour Realm, nous utilisons simplement des stockages similaires pour avoir accès au stockage local.

Managers layer {[42] } est un endroit où vivent nos abstractions/wrappers.

Dans un gestionnaire le rôle pourrait être:

• Gestionnaire D'informations d'identification avec ses différentes implémentations (keychain, NSDefaults,...)
• Gestionnaire de Session en cours qui sait comment conserver et fournir la session utilisateur en cours
• Pipeline de Capture qui permet d'accéder aux périphériques multimédias (enregistrement vidéo, audio, prise de photos)
• gestionnaire BLE qui donne accès aux services et périphériques bluetooth
• Gestionnaire De Géolocalisation
• ...

Donc, dans le rôle de gestionnaire pourrait être n'importe quel objet qui implémente la logique d'un aspect ou d'une préoccupation particulière nécessaire au fonctionnement de l'application.

, Nous essayons d'éviter les Singletons, mais cette couche est un endroit où ils vivent, s'ils sont nécessaires.

La couche Coordinators fournit des objets qui dépendent des objets d'autres couches (Service, Stockage, modèle) afin de combiner leur logique en une séquence de travail nécessaire pour certains modules (fonctionnalité, écran, histoire d'utilisateur ou expérience utilisateur). Il chaînes habituellement opérations asynchrones et sait comment réagir sur leurs cas de réussite et d'échec. À titre d'exemple, vous pouvez imaginer une fonctionnalité de messagerie et un objet MessagingCoordinator correspondant. La gestion de l'opération d'envoi de message peut ressembler à ceci:

1. valider le message (couche modèle)
2. Enregistrer le message localement (stockage des messages)
3. Télécharger la pièce jointe du message (service amazon S3)
4. mettre à jour l'état du message et les URL des pièces jointes et enregistrer le message localement (stockage des messages)
5. sérialiser le message au format JSON (couche de modèle)
6. publier un message à PubNub (service PubNub)
7. mettez à jour l'état et les attributs du message et enregistrez-le localement (stockage des messages)

Sur chacune des étapes ci-dessus, une erreur est traitée en conséquence.

La couche D'interface utilisateur se compose des sous-couches suivantes:

1. Viewmodel
2. ViewControllers
3. Vues

Afin d'éviter les contrôleurs de vue massifs, nous utilisons MVVM pattern et implémenter la logique nécessaire pour la présentation de L'interface utilisateur dans ViewModels. Un ViewModel a généralement des coordinateurs et des gestionnaires comme dépendances. ViewModels utilisés par ViewControllers et certains types de vues (par exemple, les cellules de vue de table). La colle entre ViewControllers et ViewModels est la liaison de données et le modèle de commande. Afin de permettre d'avoir cette colle, nous utilisonsreactivecocoa library.

Nous utilisons également ReactiveCocoa et son concept RACSignal comme interface et valeur de retour type de tous les coordinateurs, services, méthodes de stockage. Cela nous permet d'enchaîner les opérations, de les exécuter en parallèle ou en série, et de nombreuses autres choses utiles fournies par ReactiveCocoa.

Nous essayons d'implémenter notre comportement D'interface utilisateur de manière déclarative. La liaison de données et la mise en page automatique aident beaucoup à atteindre cet objectif.

La couche D'Infrastructure contient toutes les aides, extensions et utilitaires nécessaires au travail de l'application.

Cette approche fonctionne bien pour nous et pour types d'applications que nous construisons habituellement. Mais vous devriez comprendre, que c'est juste une approche subjective qui devrait être adaptée/changée pour le but concret de l'équipe.

J'espère que cela vous aidera!

Vous pouvez également trouver plus d'informations sur le processus de développement iOS dans cet article de blog développement iOS en tant que Service

Parce que toutes les applications iOS sont différentes, je pense qu'il y a différentes approches ici à considérer, mais je vais généralement de cette façon:
Créez une classe de gestionnaire central (singleton) pour gérer toutes les demandes D'API (généralement nommées APICommunicator) et chaque méthode d'instance est un appel D'API. Et il y a une méthode centrale (non publique):

-(RACSignal *)sendGetToServerToSubPath:(NSString *)path withParameters:(NSDictionary *)params;

Pour mémoire, j'utilise 2 bibliothèques/frameworks majeurs, ReactiveCocoa et AFNetworking. ReactiveCocoa gère le réseau asynchrone réponses parfaitement, vous pouvez faire (sendNext:, sendError:, etc.).
Cette méthode appelle L'API, obtient les résultats et les envoie via RAC au format ' raw '(comme NSArray what AFNetworking returns).
Ensuite, une méthode comme getStuffList: qui a appelé la méthode ci-dessus s'abonne à son signal, analyse les données brutes en objets (avec quelque chose comme Motis) et envoie les objets un par un à l'appelant (getStuffList: et des méthodes similaires renvoient également un signal auquel le contrôleur peut s'abonner).
Le le contrôleur souscrit reçoit les objets par le bloc de subscribeNext: et les gère.

J'ai essayé de nombreuses façons dans différentes applications, mais celui-ci a fonctionné le mieux de tous, donc je l'ai utilisé dans quelques applications récemment, il s'adapte à la fois aux petits et aux grands projets et il est facile d'étendre et de maintenir si quelque chose doit être modifié.
J'espère que cela aide, j'aimerais entendre les opinions des autres sur mon approche et peut-être comment les autres pensent que cela pourrait être amélioré.

Dans ma situation, j'utilise généralement la bibliothèque ResKit pour configurer la couche réseau. Il fournit une analyse facile à utiliser. Cela réduit mes efforts pour configurer le mappage pour différentes réponses et autres choses.

J'ajoute seulement du code pour configurer le mappage automatiquement. Je définis la classe de base pour mes modèles (pas le protocole en raison de beaucoup de code pour vérifier si une méthode est implémentée ou non, et moins de code dans les modèles eux-mêmes):

MappableEntry.h

@interface MappableEntity : NSObject

+ (NSArray*)pathPatterns;
+ (NSArray*)keyPathes;
+ (NSArray*)fieldsArrayForMapping;
+ (NSDictionary*)fieldsDictionaryForMapping;
+ (NSArray*)relationships;

@end

MappableEntry.m

@implementation MappableEntity

+(NSArray*)pathPatterns {
    return @[];
}

+(NSArray*)keyPathes {
    return nil;
}

+(NSArray*)fieldsArrayForMapping {
    return @[];
}

+(NSDictionary*)fieldsDictionaryForMapping {
    return @{};
}

+(NSArray*)relationships {
    return @[];
}

@end

Les relations sont des objets qui représentent des objets imbriqués en réponse:

RelationshipObject.h

@interface RelationshipObject : NSObject

@property (nonatomic,copy) NSString* source;
@property (nonatomic,copy) NSString* destination;
@property (nonatomic) Class mappingClass;

+(RelationshipObject*)relationshipWithKey:(NSString*)key andMappingClass:(Class)mappingClass;
+(RelationshipObject*)relationshipWithSource:(NSString*)source destination:(NSString*)destination andMappingClass:(Class)mappingClass;

@end

RelationshipObject.m

@implementation RelationshipObject

+(RelationshipObject*)relationshipWithKey:(NSString*)key andMappingClass:(Class)mappingClass {
    RelationshipObject* object = [[RelationshipObject alloc] init];
    object.source = key;
    object.destination = key;
    object.mappingClass = mappingClass;
    return object;
}

+(RelationshipObject*)relationshipWithSource:(NSString*)source destination:(NSString*)destination andMappingClass:(Class)mappingClass {
    RelationshipObject* object = [[RelationshipObject alloc] init];
    object.source = source;
    object.destination = destination;
    object.mappingClass = mappingClass;
    return object;
}

@end

Ensuite, je configure le mappage pour RestKit comme ceci:

ObjectMappingInitializer.h

@interface ObjectMappingInitializer : NSObject

+(void)initializeRKObjectManagerMapping:(RKObjectManager*)objectManager;

@end

ObjectMappingInitializer.m

@interface ObjectMappingInitializer (Private)

+ (NSArray*)mappableClasses;

@end

@implementation ObjectMappingInitializer

+(void)initializeRKObjectManagerMapping:(RKObjectManager*)objectManager {

    NSMutableDictionary *mappingObjects = [NSMutableDictionary dictionary];

    // Creating mappings for classes
    for (Class mappableClass in [self mappableClasses]) {
        RKObjectMapping *newMapping = [RKObjectMapping mappingForClass:mappableClass];
        [newMapping addAttributeMappingsFromArray:[mappableClass fieldsArrayForMapping]];
        [newMapping addAttributeMappingsFromDictionary:[mappableClass fieldsDictionaryForMapping]];
        [mappingObjects setObject:newMapping forKey:[mappableClass description]];
    }

    // Creating relations for mappings
    for (Class mappableClass in [self mappableClasses]) {
        RKObjectMapping *mapping = [mappingObjects objectForKey:[mappableClass description]];
        for (RelationshipObject *relation in [mappableClass relationships]) {
            [mapping addPropertyMapping:[RKRelationshipMapping relationshipMappingFromKeyPath:relation.source toKeyPath:relation.destination withMapping:[mappingObjects objectForKey:[relation.mappingClass description]]]];
        }
    }

    // Creating response descriptors with mappings
    for (Class mappableClass in [self mappableClasses]) {
        for (NSString* pathPattern in [mappableClass pathPatterns]) {
            if ([mappableClass keyPathes]) {
                for (NSString* keyPath in [mappableClass keyPathes]) {
                    [objectManager addResponseDescriptor:[RKResponseDescriptor responseDescriptorWithMapping:[mappingObjects objectForKey:[mappableClass description]] method:RKRequestMethodAny pathPattern:pathPattern keyPath:keyPath statusCodes:RKStatusCodeIndexSetForClass(RKStatusCodeClassSuccessful)]];
                }
            } else {
                [objectManager addResponseDescriptor:[RKResponseDescriptor responseDescriptorWithMapping:[mappingObjects objectForKey:[mappableClass description]] method:RKRequestMethodAny pathPattern:pathPattern keyPath:nil statusCodes:RKStatusCodeIndexSetForClass(RKStatusCodeClassSuccessful)]];
            }
        }
    }

    // Error Mapping
    RKObjectMapping *errorMapping = [RKObjectMapping mappingForClass:[Error class]];
    [errorMapping addAttributeMappingsFromArray:[Error fieldsArrayForMapping]];
    for (NSString *pathPattern in Error.pathPatterns) {
        [[RKObjectManager sharedManager] addResponseDescriptor:[RKResponseDescriptor responseDescriptorWithMapping:errorMapping method:RKRequestMethodAny pathPattern:pathPattern keyPath:nil statusCodes:RKStatusCodeIndexSetForClass(RKStatusCodeClassClientError)]];
    }
}

@end

@implementation ObjectMappingInitializer (Private)

+ (NSArray*)mappableClasses {
    return @[
        [FruiosPaginationResults class],
        [FruioItem class],
        [Pagination class],
        [ContactInfo class],
        [Credentials class],
        [User class]
    ];
}

@end

Quelques exemples de mappableentry implémentation:

de l'Utilisateur.h

@interface User : MappableEntity

@property (nonatomic) long userId;
@property (nonatomic, copy) NSString *username;
@property (nonatomic, copy) NSString *email;
@property (nonatomic, copy) NSString *password;
@property (nonatomic, copy) NSString *token;

- (instancetype)initWithUsername:(NSString*)username email:(NSString*)email password:(NSString*)password;

- (NSDictionary*)registrationData;

@end

de l'Utilisateur.m

@implementation User

- (instancetype)initWithUsername:(NSString*)username email:(NSString*)email password:(NSString*)password {
    if (self = [super init]) {
        self.username = username;
        self.email = email;
        self.password = password;
    }
    return self;
}

- (NSDictionary*)registrationData {
    return @{
        @"username": self.username,
        @"email": self.email,
        @"password": self.password
    };
}

+ (NSArray*)pathPatterns {
    return @[
        [NSString stringWithFormat:@"/api/%@/users/register", APIVersionString],
        [NSString stringWithFormat:@"/api/%@/users/login", APIVersionString]
    ];
}

+ (NSArray*)fieldsArrayForMapping {
    return @[ @"username", @"email", @"password", @"token" ];
}

+ (NSDictionary*)fieldsDictionaryForMapping {
    return @{ @"id": @"userId" };
}

@end

Maintenant à propos de L'emballage des requêtes:

J'ai un fichier d'en-tête avec une définition de blocs, pour réduire la longueur de ligne dans toutes les classes APIRequest:

APICallbacks.h

typedef void(^SuccessCallback)();
typedef void(^SuccessCallbackWithObjects)(NSArray *objects);
typedef void(^ErrorCallback)(NSError *error);
typedef void(^ProgressBlock)(float progress);

Et exemple de ma classe APIRequest que j'utilise:

LoginAPI.h

@interface LoginAPI : NSObject

- (void)loginWithCredentials:(Credentials*)credentials onSuccess:(SuccessCallbackWithObjects)onSuccess onError:(ErrorCallback)onError;

@end

LoginAPI.m

@implementation LoginAPI

- (void)loginWithCredentials:(Credentials*)credentials onSuccess:(SuccessCallbackWithObjects)onSuccess onError:(ErrorCallback)onError {
    [[RKObjectManager sharedManager] postObject:nil path:[NSString stringWithFormat:@"/api/%@/users/login", APIVersionString] parameters:[credentials credentialsData] success:^(RKObjectRequestOperation *operation, RKMappingResult *mappingResult) {
        onSuccess(mappingResult.array);
    } failure:^(RKObjectRequestOperation *operation, NSError *error) {
        onError(error);
    }];
}

@end

Et tout ce dont vous avez besoin pour faire dans le code, initialisez simplement L'objet API et appelez-le chaque fois que vous en avez besoin:

SomeViewController.m

@implementation SomeViewController {
    LoginAPI *_loginAPI;
    // ...
}

- (void)viewDidLoad {
    [super viewDidLoad];

    _loginAPI = [[LoginAPI alloc] init];
    // ...
}

// ...

- (IBAction)signIn:(id)sender {
    [_loginAPI loginWithCredentials:_credentials onSuccess:^(NSArray *objects) {
        // Success Block
    } onError:^(NSError *error) {
        // Error Block
    }];
}

// ...

@end

Mon code n'est pas parfait, mais il est facile à définir une fois et à utiliser pour différents projets. Si c'est intéressant pour tout le monde, mb je pourrais passer du temps et faire une solution universelle quelque part sur GitHub et CocoaPods.

À mon avis, toute l'architecture logicielle est motivée par le besoin. Si cela est à des fins d'apprentissage ou personnelles, puis décider de l'objectif principal et ont qui conduisent l'architecture. Si c'est un travail à louer, alors le besoin d'affaires est primordial. L'astuce est de ne pas laisser les choses brillantes vous distraire des besoins réels. Je trouve cela difficile à faire. Il y a toujours de nouvelles choses brillantes qui apparaissent dans cette entreprise et beaucoup d'entre elles ne sont pas utiles, mais vous ne pouvez pas toujours le dire à l'avance. Se concentrer sur le besoin et être prêt à abandonner mauvais choix si vous le pouvez.

Par exemple, j'ai récemment fait un prototype rapide d'une application de partage de photos pour une entreprise locale. Puisque le besoin commercial était de faire quelque chose de rapide et sale, l'architecture a fini par être un code iOS pour faire apparaître une caméra et un code réseau attaché à un bouton D'envoi qui a téléchargé l'image dans un magasin S3 et a écrit à un domaine SimpleDB. Le code était trivial et le coût minime et le client dispose d'une collection de photos évolutive accessible sur le web avec des appels REST. Bon marché et stupide, l'application avait beaucoup de défauts et verrouillerait l'interface utilisateur à l'occasion, mais ce serait un gaspillage de faire plus pour un prototype et cela leur permet de déployer leur personnel et de générer des milliers d'images de test facilement sans problèmes de performance ou d'évolutivité. Architecture merdique, mais il correspond parfaitement au besoin et au coût.

Un autre projet impliquait la mise en œuvre d'une base de données sécurisée locale qui se synchronise avec le système de l'entreprise en arrière-plan lorsque le réseau est disponible. J'ai créé un synchroniseur d'arrière-plan qui utilisait RestKit car il semblait avoir tout ce dont j'avais besoin. Mais j'ai dû écrire tellement de code personnalisé pour RestKit pour traiter le JSON idiosyncratique que j'aurais pu le faire plus rapidement en écrivant mon propre JSON en transformations CoreData. Cependant, le client voulait apporter cette application en interne et je sentais que RestKit serait similaire aux frameworks qu'ils utilisaient sur d'autres plates-formes. J'attends pour voir si c'était une bonne décision.

Encore une fois, le le problème pour moi est de se concentrer sur le besoin et de laisser cela déterminer l'architecture. J'essaie comme l'enfer d'éviter d'utiliser des paquets tiers car ils apportent des coûts qui n'apparaissent qu'après que l'application a été sur le terrain pendant un certain temps. J'essaie d'éviter de faire des hiérarchies de classe car elles rapportent rarement. Si je peux écrire quelque chose dans un délai raisonnable au lieu d'adopter un paquet qui ne correspond pas parfaitement, alors je le fais. Mon code est bien structuré pour le débogage et commenté de manière appropriée, mais tiers les paquets sont rarement. Cela dit, je trouve le réseautage AF trop utile pour ignorer et bien structuré, bien commenté, et maintenu et je l'utilise beaucoup! RestKit couvre beaucoup de cas courants, mais j'ai l'impression de me battre quand je l'utilise, et la plupart des sources de données que je rencontre sont pleines de bizarreries et de problèmes qui sont mieux gérés avec du code personnalisé. Dans mes dernières applications, j'utilise simplement les convertisseurs JSON intégrés et j'écris quelques méthodes utilitaires.

Un modèle que j'utilise toujours est d'obtenir le le réseau appelle le thread principal. Les 4-5 dernières applications que j'ai faites ont mis en place une tâche de minuteur en arrière-plan à l'aide de dispatch_source_create qui se réveille de temps en temps et effectue des tâches réseau au besoin. Vous devez effectuer un travail de sécurité des threads et vous assurer que le code de modification de L'interface utilisateur est envoyé au thread principal. Cela aide également à faire votre intégration / initialisation de telle sorte que l'utilisateur ne se sente pas accablé ou retardé. Jusqu'à présent, ce travail a été plutôt bien. Je suggère de regarder dans ces chose.

Enfin, je pense qu'à mesure que nous travaillons davantage et que le système d'exploitation évolue, nous avons tendance à développer de meilleures solutions. Il m'a fallu des années pour surmonter ma conviction que je dois suivre des modèles et des conceptions que d'autres personnes prétendent être obligatoires. Si je travaille dans un contexte où cela fait partie de la religion locale, ahem, je veux dire les meilleures pratiques d'ingénierie du ministère, alors je suis les coutumes à la lettre, c'est ce qu'ils me paient. Mais je trouve rarement que suivant des conceptions plus anciennes et patterns est la solution optimale. J'essaie toujours de regarder la solution à travers le prisme des besoins de l'entreprise et de construire l'architecture pour le match et de garder les choses aussi simples qu'elles peuvent être. Quand j'ai l'impression qu'il n'y en a pas assez, mais que tout fonctionne correctement, alors je suis sur la bonne voie.

J'utilise l'approche que j'ai obtenu à partir d'ici: https://github.com/Constantine-Fry/Foursquare-API-v2. J'ai réécrit cette bibliothèque rapide et vous pouvez voir l'approche architecturale de ces parties de code:

typealias OpertaionCallback = (success: Bool, result: AnyObject?) -> ()

class Foursquare{
    var authorizationCallback: OperationCallback?
    var operationQueue: NSOperationQueue
    var callbackQueue: dispatch_queue_t?

    init(){
        operationQueue = NSOperationQueue()
        operationQueue.maxConcurrentOperationCount = 7;
        callbackQueue = dispatch_get_main_queue();
    }

    func checkIn(venueID: String, shout: String, callback: OperationCallback) -> NSOperation {
        let parameters: Dictionary <String, String> = [
            "venueId":venueID,
            "shout":shout,
            "broadcast":"public"]
        return self.sendRequest("checkins/add", parameters: parameters, httpMethod: "POST", callback: callback)
    }

    func sendRequest(path: String, parameters: Dictionary <String, String>, httpMethod: String, callback:OperationCallback) -> NSOperation{
        let url = self.constructURL(path, parameters: parameters)
        var request = NSMutableURLRequest(URL: url)
        request.HTTPMethod = httpMethod
        let operation = Operation(request: request, callbackBlock: callback, callbackQueue: self.callbackQueue!)
        self.operationQueue.addOperation(operation)
        return operation
    }

    func constructURL(path: String, parameters: Dictionary <String, String>) -> NSURL {
        var parametersString = kFSBaseURL+path
        var firstItem = true
        for key in parameters.keys {
            let string = parameters[key]
            let mark = (firstItem ? "?" : "&")
            parametersString += "\(mark)\(key)=\(string)"
            firstItem = false
        }
    return NSURL(string: parametersString.stringByAddingPercentEscapesUsingEncoding(NSUTF8StringEncoding))
    }
}

class Operation: NSOperation {
    var callbackBlock: OpertaionCallback
    var request: NSURLRequest
    var callbackQueue: dispatch_queue_t

    init(request: NSURLRequest, callbackBlock: OpertaionCallback, callbackQueue: dispatch_queue_t) {
        self.request = request
        self.callbackBlock = callbackBlock
        self.callbackQueue = callbackQueue
    }

    override func main() {
        var error: NSError?
        var result: AnyObject?
        var response: NSURLResponse?

        var recievedData: NSData? = NSURLConnection.sendSynchronousRequest(self.request, returningResponse: &response, error: &error)

        if self.cancelled {return}

        if recievedData{
            result = NSJSONSerialization.JSONObjectWithData(recievedData, options: nil, error: &error)
            if result != nil {
                if result!.isKindOfClass(NSClassFromString("NSError")){
                    error = result as? NSError
            }
        }

        if self.cancelled {return}

        dispatch_async(self.callbackQueue, {
            if (error) {
                self.callbackBlock(success: false, result: error!);
            } else {
                self.callbackBlock(success: true, result: result!);
            }
            })
    }

    override var concurrent:Bool {get {return true}}
}

Fondamentalement, il existe une sous-classe NSOperation qui effectue NSURLRequest, analyse la réponse JSON et ajoute le bloc de rappel avec le résultat à la file d'attente. La classe API principale construit NSURLRequest, initialise cette sous-classe NSOperation et l'ajoute à la file.

Nous utilisons quelques approches en fonction de la situation. Pour la plupart des choses, AFNetworking est l'approche la plus simple et la plus robuste en ce sens que vous pouvez définir des en-têtes, télécharger des données en plusieurs parties, utiliser GET, POST, PUT & DELETE et il y a un tas de catégories supplémentaires pour UIKit qui vous permettent par exemple de définir une image à partir d'une url. Dans une application complexe avec beaucoup d'appels, nous résumons parfois cela à une méthode de commodité qui serait quelque chose comme:

-(void)makeRequestToUrl:(NSURL *)url withParameters:(NSDictionary *)parameters success:(void (^)(id responseObject))success failure:(void (^)(AFHTTPRequestOperation *operation, NSError *error))failure;

Il y en a quelques-uns les situations où AFNetworking n'est pas approprié, par exemple lorsque vous créez un framework ou un autre composant de bibliothèque, car AFNetworking peut déjà se trouver dans une autre base de code. Dans cette situation, vous utiliseriez un NSMutableURLRequest en ligne si vous effectuez un seul appel ou abstrait dans une classe request / response.

J'évite les singletons lors de la conception de mes applications. Ils sont typiques pour beaucoup de gens, mais je pense que vous pouvez trouver des solutions plus élégantes ailleurs. Typiquement, ce que je fais est de construire mes entités dans CoreData, puis de mettre mon code REST dans une catégorie NSManagedObject. Si par exemple je voulais créer et poster un nouvel utilisateur, je ferais ceci:

User* newUser = [User createInManagedObjectContext:managedObjectContext];
[newUser postOnSuccess:^(...) { ... } onFailure:^(...) { ... }];

J'utilise RESTKit pour le mappage d'objets et l'initialise au démarrage. Je trouve que le routage de tous vos appels via un singleton pour être un perte de temps et ajoute beaucoup de passe-partout qui n'est pas nécessaire.

Dans NSManagedObject + Extensions.m:

+ (instancetype)createInContext:(NSManagedObjectContext*)context
{
    NSAssert(context.persistentStoreCoordinator.managedObjectModel.entitiesByName[[self entityName]] != nil, @"Entity with name %@ not found in model. Is your class name the same as your entity name?", [self entityName]);
    return [NSEntityDescription insertNewObjectForEntityForName:[self entityName] inManagedObjectContext:context];
}

Dans NSManagedObject + Networking.m:

- (void)getOnSuccess:(RESTSuccess)onSuccess onFailure:(RESTFailure)onFailure blockInput:(BOOL)blockInput
{
    [[RKObjectManager sharedManager] getObject:self path:nil parameters:nil success:onSuccess failure:onFailure];
    [self handleInputBlocking:blockInput];
}

Pourquoi ajouter des classes d'aide supplémentaires lorsque vous pouvez étendre la fonctionnalité d'une classe de base commune à travers les catégories?

Si vous êtes intéressé par des informations plus détaillées sur ma solution faites le moi savoir. Je suis heureux de partager.

Essayez https://github.com/kevin0571/STNetTaskQueue

Crée des requêtes API dans des classes séparées.

STNetTaskQueue traitera le threading et le delegate / callback.

Extensible pour différents protocoles.

D'un point de vue purement de conception de classe, vous aurez généralement quelque chose comme ceci:

• Vos contrôleurs de vue contrôlant une ou plusieurs vues

• Classe de modèle de données - Cela dépend vraiment du nombre d'entités distinctes réelles avec lesquelles vous traitez, et de la façon dont elles sont liées.

  Par exemple, si vous avez un tableau d'éléments à afficher dans quatre représentations différentes (list, chart, graph etc), vous aurez une classe de modèle de données pour list of articles, un de plus pour un article. La liste de la classe d'élément sera partagée par quatre contrôleurs de vue - tous les enfants d'un contrôleur de barre d'onglets ou d'un contrôleur de navigation.

  Les classes de modèle de données seront utiles non seulement pour afficher les données, mais aussi pour les sérialiser, chacune d'elles pouvant exposer son propre format de sérialisation via des méthodes d'exportation JSON / XML / CSV (ou toute autre chose).

• Il est important de comprendre que vous avez également besoin de API request builder classes cette carte directement avec vos points de terminaison D'API REST. Disons que vous avez une API qui connecte l'utilisateur - donc votre classe login API builder va créer post JSON payload for login api. Dans un autre exemple, une classe de générateur de requête API pour la liste des éléments de catalogue API créera une chaîne de requête GET pour l'api correspondante et déclenchera la requête GET REST.

  Ces classes de générateur de requêtes API reçoivent généralement des données des contrôleurs de vue et transmettent également les mêmes données aux contrôleurs de vue pour la mise à jour de L'interface utilisateur / d'autres opérations. Les contrôleurs de vue décideront alors comment mettre à jour les objets du modèle de données avec ces données.

• Enfin, le cœur du client REST - classe de récupération de données API ce qui est inconscient de toutes sortes de demandes D'API faites par votre application. Cette classe sera plus probablement un singleton, mais comme d'autres l'ont souligné, il ne doit pas nécessairement être un singleton.

  Notez que le lien est juste une implémentation typique et ne prend pas en considération des scénarios comme la session, les cookies, etc., mais il suffit de vous lancer sans utiliser de frameworks tiers.

Cette question a déjà beaucoup de réponses excellentes et étendues, mais je pense que je dois le mentionner puisque personne d'autre ne l'a fait.

Alamofire pour Swift. https://github.com/Alamofire/Alamofire

Il est créé par les mêmes personnes que AFNetworking, mais est plus directement conçu avec Swift à l'esprit.