Najlepsze podejścia architektoniczne do budowania aplikacji sieciowych iOS (klienci REST)

Zgodnie z celem tego pytania, chciałbym opisać nasze podejście do architektury.

Podejście do architektury

Nasza ogólna Architektura aplikacji iOS opiera się na następujących wzorach: warstwy usług, MVVM, powiązanie danych interfejsu użytkownika, Dependency Injection; and Functional Reactive Programming paradygmat.

Możemy pokroić typową aplikację konsumencką w następujące logiczne warstwy:

• montaż
• Model
• usługi
• Przechowywanie
• menedżerowie
• Koordynatorzy
• UI
• Infrastruktura

Warstwa montażowa jest punktem bootstrap naszej aplikacji. Zawiera kontener iniekcji zależności oraz deklaracje obiektów aplikacji i ich zależności. Ta warstwa może również zawierać konfigurację aplikacji (adresy URL, klucze usług innych firm itp.). W tym celu korzystamy z biblioteki Typhoon .

Warstwa Modelu zawiera klasy modeli domenowych, walidacje, mapowania. Używamy biblioteki Mantle do mapowania naszych modeli: obsługuje serializację/deserializację do formatu JSON i modeli NSManagedObject. Do walidacji i reprezentacji formularzy naszych modeli używamy bibliotek FXFormsi fxmodelvalidation.

Warstwa usług deklaruje usługi, których używamy do interakcji z zewnętrznymi systemami w aby wysyłać lub odbierać dane, które są reprezentowane w naszym modelu domeny. Zazwyczaj mamy więc usługi do komunikacji z API serwera( na jednostkę), usługi wiadomości (jak PubNub ), Usługi pamięci masowej (jak Amazon S3) itp. Zasadniczo usługi zawijają obiekty dostarczane przez zestawy SDK (na przykład PubNub SDK) lub implementują własną logikę komunikacji. Do ogólnych zastosowań sieciowych używamy biblioteki AFNetworking.

Celem warstwy Storage layer jest organizacja lokalnego przechowywania danych na urządzeniu. Używamy do tego podstawowych danych lub Realm (oba mają plusy i minusy, decyzja o tym, czego użyć, opiera się na konkretnych specyfikacjach). Do konfiguracji podstawowych danych używamy biblioteki MDMCoreData oraz kilku klas - storage - (podobnych do usług), które zapewniają dostęp do lokalnego magazynu dla każdej jednostki. Dla Realm używamy tylko podobnych magazynów, aby mieć dostęp do lokalnej pamięci masowej.

Managers layer to miejsce, w którym żyją nasze abstrakcje/wrappery.

W Menedżerze rola może być:

• Menedżer poświadczeń z różnymi implementacjami (keychain, NSDefaults, ...)
• Menedżer bieżącej sesji, który wie, jak zachować i zapewnić bieżącą sesję użytkownika
• Przechwytywanie rurociągu, który zapewnia dostęp do urządzeń multimedialnych (nagrywanie wideo, audio, robienie zdjęć)
Ble Manager, który zapewnia dostęp do usług bluetooth i urządzeń peryferyjnych [24]}
• Geo Location Manager
• ...

Więc, w roli menedżera może to być dowolny obiekt, który implementuje logikę określonego aspektu lub troski potrzebnej do działania aplikacji.

Staramy się unikać singletonów, ale ta warstwa jest miejscem, w którym żyją, jeśli są potrzebne.

Coordinators layer dostarcza obiekty, które zależą od obiektów z innych warstw (Service, Storage, Model) w celu połączenia ich logiki w jedną sekwencję pracy potrzebną dla określonego modułu (feature, screen, user story lub user experience). Zwykle łańcuchy operacje asynchroniczne i wie, jak reagować na ich przypadki sukcesu i porażki. Jako przykład można sobie wyobrazić funkcję przesyłania wiadomości i odpowiadający jej obiekt MessagingCoordinator. Obsługa operacji wysyłania wiadomości może wyglądać tak:

1. Validate message (model layer)
2. Zapisz wiadomość lokalnie (przechowywanie wiadomości)
3. załącznik do przesłania wiadomości (usługa amazon S3)
4. zaktualizuj status wiadomości i adresy URL załączników i zapisz wiadomość lokalnie (przechowywanie wiadomości)
5. Serializowanie Wiadomości do formatu JSON (warstwa modelu)
6. opublikuj wiadomość do PubNub (usługa PubNub)
7. zaktualizuj status i atrybuty wiadomości i zapisz je lokalnie (przechowywanie wiadomości)

Na każdym z powyższych kroków błąd jest odpowiednio obsługiwany.

Warstwa interfejsu składa się z następujących podwarstw:

1. ViewModels
2. ViewControllers
3. Views

W celu uniknięcia ogromnych kontrolerów widoku używamy Wzorzec MVVM i implementacja logiki potrzebne do prezentacji UI w ViewModels. ViewModel zazwyczaj ma koordynatorów i menedżerów jako zależności. ViewModels używane przez Viewcontrollery i niektóre rodzaje widoków (np. komórki widoku tabeli). Klejem pomiędzy kontrolerami ViewControllers i ViewModels jest powiązanie danych i wzorzec poleceń. Aby możliwe było posiadanie tego kleju używamy biblioteki ReactiveCocoa .

Używamy również ReactiveCocoa i jego koncepcji RACSignal jako interfejsu i zwracającej wartość rodzaj wszystkich koordynatorów, usługi, metody przechowywania. Pozwala nam to na łańcuchowe operacje, uruchamianie ich równolegle lub szeregowo oraz wiele innych przydatnych rzeczy dostarczanych przez ReactiveCocoa.

Staramy się zaimplementować nasze zachowanie UI w deklaratywny sposób. Powiązanie danych i układ Automatyczny bardzo pomagają w osiągnięciu tego celu.

Warstwa Infrastructure zawiera wszystkie helpery, rozszerzenia, narzędzia potrzebne do pracy aplikacji.

To podejście sprawdza się dobrze dla nas i tych typy aplikacji, które zwykle tworzymy. Ale powinieneś zrozumieć, że jest to tylko subiektywne podejście, które powinno być dostosowane/zmienione do konkretnych celów zespołu.

Mam nadzieję, że to ci pomoże!

Ponieważ wszystkie aplikacje na iOS są różne, myślę, że istnieją różne podejścia tutaj do rozważenia, ale zwykle idę w ten sposób:
Utwórz klasę Central manager (singleton) do obsługi wszystkich żądań API (Zwykle o nazwie APICommunicator), a każda metoda instancji jest wywołaniem API. I jest jedna centralna (Niepubliczna) metoda:

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

Dla przypomnienia, używam 2 głównych bibliotek / frameworków, ReactiveCocoa i AFNetworking. ReactiveCocoa obsługuje sieci asynchroniczne odpowiedzi doskonale, można zrobić (sendNext:, sendError:, itp.).
Metoda ta wywołuje API, pobiera wyniki i wysyła je przez RAC w formacie ' raw ' (jak nsArray co zwraca AFNetworking).
Następnie metoda jak getStuffList:, która wywołała powyższą metodę subskrybuje jego sygnał, przetwarza surowe dane do obiektów (z czymś w rodzaju Motis) i wysyła obiekty jeden po drugim do wywołującego (getStuffList: i podobne metody również zwracają sygnał, który kontroler może subskrybować).
Na subskrybowany kontroler odbiera obiekty za pomocą bloku subscribeNext: i obsługuje je.

Próbowałem na wiele sposobów w różnych aplikacjach, ale ten działał najlepiej ze wszystkich, więc używam tego w kilku aplikacjach ostatnio, pasuje zarówno do małych, jak i dużych projektów i jest łatwy do rozszerzenia i utrzymania, jeśli coś wymaga modyfikacji.
Mam nadzieję, że to pomoże, chciałbym usłyszeć opinie innych o moim podejściu i być może, jak inni myślą, że można to poprawić.

W mojej sytuacji zwykle używam biblioteki ResKit do konfiguracji warstwy sieciowej. Zapewnia łatwe w użyciu parsowanie. To zmniejsza mój wysiłek na ustawienie mapowania dla różnych odpowiedzi i rzeczy.

Dodaję tylko trochę kodu do ustawienia mapowania automatycznie. Definiuję klasę bazową dla moich modeli (nie protokół z powodu dużej ilości kodu do sprawdzenia czy jakaś metoda jest zaimplementowana czy nie, a mniej kodu w samych modelach):

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

Relacje to obiekty reprezentujące zagnieżdżone obiekty w odpowiedzi:

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

Potem ustawiam mapowanie dla Restkitu tak:

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

Jakiś przykład implementacja MappableEntry:

użytkownik.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

użytkownik.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

Teraz o żądaniach:

Mam plik nagłówkowy z definicją bloków, aby zmniejszyć długość linii we wszystkich klasach APIRequest:

APICallbacks.h

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

I przykład mojej klasy APIRequest, której używam:

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

And all you need aby zrobić to w kodzie, po prostu zainicjuj obiekt API i wywołaj go, gdy potrzebujesz:

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

Mój kod nie jest idealny, ale jest łatwy do jednorazowego ustawienia i użycia dla różnych projektów. Jeśli jest to dla kogoś interesujące, mb mógłbym spędzić trochę czasu i zrobić dla niego uniwersalne rozwiązanie gdzieś na Githubie i CocoaPods.

Według mnie cała architektura oprogramowania jest napędzana potrzebami. Jeśli jest to do celów edukacyjnych lub osobistych, a następnie zdecydować główny cel i mieć, że napęd architektury. Jeśli jest to praca na wynajem, to potrzeba biznesowa jest najważniejsza. Sztuczka polega na tym, żeby błyszczące rzeczy nie odciągały Cię od prawdziwych potrzeb. Trudno mi to zrobić. W tym biznesie zawsze pojawiają się nowe błyszczące rzeczy i wiele z nich nie jest przydatnych, ale nie zawsze można to powiedzieć z góry. Skupić się na potrzebie i być gotów porzucić złe wybory, jeśli możesz.

Na przykład niedawno zrobiłem szybki prototyp aplikacji do udostępniania zdjęć dla lokalnej firmy. Ponieważ potrzeba biznesowa polegała na szybkim i brudnym zrobieniu czegoś, Architektura skończyła się kodem iOS, aby wyskoczyć z kamery i trochę kodu sieciowego dołączonego do przycisku Wyślij, który przesłał obraz do sklepu S3 i napisał do domeny SimpleDB. Kod był banalny i koszt minimalny, a Klient ma skalowalną kolekcję zdjęć dostępną przez www z telefonami REST. Tanie i głupie, aplikacja miała wiele wad i zablokować interfejs użytkownika na czas, ale byłoby stratą zrobić więcej dla prototypu i pozwala im wdrożyć do swoich pracowników i generować tysiące obrazów testowych łatwo bez problemów z wydajnością lub skalowalnością. Gówniana architektura, ale idealnie pasuje do potrzeb i kosztów.

Kolejny projekt polegał na wdrożeniu lokalnej bezpiecznej bazy danych, która synchronizuje się z systemem firmy w tle, gdy sieć jest dostępny. Stworzyłem synchronizator tła, który używał Restkitu, ponieważ wydawał się mieć wszystko, czego potrzebowałem. Ale musiałem napisać tyle niestandardowego kodu dla RestKit, aby poradzić sobie z idiosynkratycznym JSON, że mogłem zrobić to szybciej, pisząc własne JSON do transformacji CoreData. Jednak klient chciał wprowadzić tę aplikację do domu i czułem, że RestKit będzie podobny do frameworków, które używali na innych platformach. Czekam, czy to była dobra decyzja.

Znowu dla mnie problemem jest skupienie się na potrzebie i niech to determinuje architekturę. Staram się jak cholera, aby uniknąć korzystania z pakietów innych firm, ponieważ przynoszą koszty, które pojawiają się dopiero po aplikacji jest w polu na chwilę. Staram się unikać tworzenia hierarchii klasowych, ponieważ rzadko się opłacają. Jeśli mogę napisać coś w rozsądnym czasie, zamiast przyjąć pakiet, który nie pasuje idealnie, to robię to. Mój kod jest dobrze skonstruowany do debugowania i odpowiednio skomentowany, ale strona trzecia Pakiety rzadko są. Mając to na uwadze, uważam Af Networking za zbyt przydatny do ignorowania i dobrze zorganizowany, dobrze skomentowany i utrzymany, a ja go często używam! RestKit obejmuje wiele typowych przypadków, ale czuję się, jakbym walczył, gdy go używam, a większość źródeł danych, z którymi się spotykam, jest pełna dziwactw i problemów, które najlepiej radzić sobie z niestandardowym kodem. W moich ostatnich kilku aplikacjach po prostu używam wbudowanych konwerterów JSON i piszę kilka metod użytkowych.

Jeden wzór, którego zawsze używam, to uzyskanie sieć odwołuje główny wątek. Ostatnie aplikacje 4-5, które zrobiłem, skonfigurowały zadanie timera w tle za pomocą dispatch_source_create, które budzi się co jakiś czas i wykonuje zadania sieciowe w razie potrzeby. Musisz wykonać pewne czynności związane z bezpieczeństwem wątku i upewnić się, że kod modyfikujący interfejs użytkownika zostanie wysłany do głównego wątku. Pomaga to również w przeprowadzaniu/inicjalizacji w taki sposób, aby użytkownik nie czuł się obciążony lub opóźniony. Do tej pory działa to dość dobrze. Proponuję przyjrzeć się tym rzeczy.

Na koniec myślę, że w miarę jak pracujemy więcej i ewoluujemy SYSTEM OPERACYJNY, mamy tendencję do opracowywania lepszych rozwiązań. Zajęło mi lata, aby przezwyciężyć moje przekonanie, że muszę podążać za wzorcami i projektami, które inni ludzie twierdzą, że są obowiązkowe. Jeśli pracuję w kontekście, w którym jest to częścią lokalnej religii, mam na myśli najlepsze praktyki inżynierskie, to podążam za zwyczajami do listu, za to mi płacą. Ale rzadko stwierdzam, że po starszych projektach a wzorce to optymalne rozwiązanie. Zawsze staram się patrzeć na rozwiązanie przez pryzmat potrzeb biznesowych i budować architekturę dopasowaną do niego i utrzymywać rzeczy tak proste, jak to tylko możliwe. Kiedy czuję, że nie ma wystarczająco dużo, ale wszystko działa poprawnie, to jestem na dobrej drodze.

Używam podejścia, które dostałem stąd: https://github.com/Constantine-Fry/Foursquare-API-v2 . przepisałem tę bibliotekę w języku Swift i widać podejście architektoniczne z tych części kodu:

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}}
}

Zasadniczo istnieje podklasa NSOperation, która tworzy zapytanie NSURLRequest, parsuje odpowiedź JSON i dodaje blok zwrotny z wynikiem do kolejki. Główna klasa API konstruuje NSURLRequest, inicjuje tę podklasę NSOperation i dodaje ją do Kolejka

Stosujemy kilka podejść w zależności od sytuacji. Dla większości rzeczy AFNetworking jest najprostszym i najbardziej solidnym podejściem, ponieważ można ustawić nagłówki, przesłać dane wieloczęściowe, użyć GET, POST, PUT & DELETE i istnieje kilka dodatkowych kategorii Dla UIKit, które pozwalają na przykład ustawić obraz z adresu url. W złożonej aplikacji z wieloma wywołaniami czasami abstrakujemy to do wygodnej metody naszej własnej, która byłaby czymś w rodzaju:

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

Jest kilka sytuacje, w których AFNetworking nie jest jednak odpowiedni, takie jak tworzenie frameworka lub innego komponentu bibliotecznego, ponieważ AFNetworking może już znajdować się w innej bazie kodu. W tej sytuacji można użyć nsmutableurlrequest albo inline, jeśli wykonujesz pojedyncze wywołanie lub abstrakcyjne do klasy request / response.

Przy projektowaniu aplikacji unikam singletonów. Są one typowe dla wielu ludzi, ale myślę, że można znaleźć bardziej eleganckie rozwiązania gdzie indziej. Zazwyczaj to, co robię, to buduję moje podmioty w CoreData, a następnie umieszczam mój kod REST w kategorii NSManagedObject. Jeśli na przykład chciałbym utworzyć i opublikować nowego Użytkownika, zrobiłbym to:

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

Używam RESTKit do mapowania obiektów i inicjalizuję go przy starcie. Uważam, że przekierowanie wszystkich połączeń przez singleton jest strata czasu i dodaje dużo kotła, który nie jest potrzebny.

W 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];
}

W 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];
}

Po co dodawać dodatkowe klasy pomocnicze, skoro można rozszerzyć funkcjonalność wspólnej klasy bazowej poprzez kategorie?

Jeśli jesteś zainteresowany bardziej szczegółowymi informacjami na temat mojego rozwiązania daj mi znać. Chętnie się podzielę.

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

Tworzenie żądań API w rozdzielonych klasach.

STNetTaskQueue zajmie się threadingiem i delegowaniem / oddzwanianiem.

Możliwość rozszerzenia dla różnych protokołów.

Z czysto klasowego punktu widzenia, zazwyczaj masz coś takiego:

• Twój kontroler widoku kontrolujący jeden lub więcej widoków

• Klasa modelu danych - to naprawdę zależy od tego, z jaką liczbą rzeczywistych odrębnych podmiotów masz do czynienia i jak są ze sobą powiązane.

  Na przykład, jeśli masz tablicę elementów, które mają być wyświetlane w czterech różnych reprezentacjach( list, chart, graph itp.), będziesz miał jedną klasę modelu danych dla list of przedmioty, jeszcze jeden za przedmiot. Lista klasy pozycji będzie współdzielona przez cztery kontrolery widoków - wszystkie dzieci kontrolera paska kart lub kontrolera nav.

  Klasy modeli danych przydadzą się nie tylko w wyświetlaniu danych, ale także serializowaniu ich, w którym każda z nich może ujawnić swój własny format serializacji za pomocą metod eksportu JSON / XML / CSV (lub czegokolwiek innego).

• Ważne jest, aby zrozumieć, że potrzebujesz również klasy API request builder mapowanie bezpośrednio z punktami końcowymi REST API. Załóżmy, że masz API, które loguje użytkownika - więc twoja klasa Login API builder utworzy POST JSON payload dla login api. W innym przykładzie, Klasa API request builder dla list of catalog items API utworzy ciąg zapytania GET dla odpowiedniego api i odpali zapytanie Rest GET.

  Te klasy API request builder zazwyczaj otrzymują dane z kontrolerów widoku, a także przekazują te same dane z powrotem do kontrolerów widoku w celu aktualizacji interfejsu użytkownika / inne operacje. Kontrolery widoku będą wtedy decydować, jak aktualizować obiekty modelu danych o te dane.

• Wreszcie, serce reszty KLIENTA - klasa API data fetcher który jest nieświadomy wszelkiego rodzaju żądań API, które sprawia, że aplikacja. Ta klasa najprawdopodobniej będzie singletonem, ale jak zauważyli inni, nie musi to być singleton.

  Zauważ, że link jest tylko typową implementacją i nie bierze pod uwagę scenariusze, takie jak sesja, pliki cookie itp., ale wystarczy, aby przejść bez korzystania z frameworków innych firm.

To pytanie ma już wiele doskonałych i obszernych odpowiedzi, ale czuję, że muszę o tym wspomnieć, ponieważ nikt inny nie ma.

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

Jest tworzony przez tych samych ludzi co AFNetworking, ale jest bardziej bezpośrednio zaprojektowany z myślą o Swift.