Los mejores enfoques arquitectónicos para crear aplicaciones de red iOS (clientes REST)

De acuerdo con el objetivo de esta pregunta, me gustaría describir nuestro enfoque de arquitectura.

Enfoque de arquitectura

La arquitectura general de nuestra aplicación iOS se basa en los siguientes patrones: Capas de servicio, MVVM, Enlace de Datos de Interfaz de Usuario, Inyección de dependencia ; y paradigma Programación Reactiva Funcional.

Podemos cortar una aplicación típica de cara al consumidor en la siguiente lógica capas:

• Asamblea
• Modelo
• Servicios
• Almacenamiento
• Gerentes
• Coordinadores
• UI
• Infraestructura

Assembly layer es un punto de arranque de nuestra aplicación. Contiene un contenedor de Inyección de dependencias y declaraciones de los objetos de la aplicación y sus dependencias. Esta capa también puede contener la configuración de la aplicación (url, claves de servicios de terceros, etc.). Para este propósito usamos la biblioteca Typhoon .

Model layer contiene clases de modelos de dominio, validaciones, asignaciones. Usamos la biblioteca Mantle para mapear nuestros modelos: admite serialización/deserialización en formato JSON y modelos NSManagedObject. Para la validación y representación de formularios de nuestros modelos utilizamos las bibliotecas FXForms y FXModelValidation.

Services layer declara los servicios que utilizamos para interactuar con sistemas externos en para enviar o recibir datos que están representados en nuestro modelo de dominio. Por lo general, tenemos servicios para la comunicación con API de servidor (por entidad), servicios de mensajería (como PubNub), servicios de almacenamiento (como Amazon S3), etc. Básicamente, los servicios empaquetan objetos proporcionados por SDK (por ejemplo, PubNub SDK) o implementan su propia lógica de comunicación. Para redes generales utilizamos la biblioteca AFNetworking .

El propósito de Storage layer es organizar el almacenamiento local de datos en el dispositivo. Utilizamos Core Data oRealm para esto (ambos tienen pros y contras, la decisión de qué usar se basa en especificaciones concretas). Para la configuración de Core Data usamos la biblioteca MDMCoreData y un montón de clases - almacenamientos - (similares a los servicios) que proporcionan acceso al almacenamiento local para cada entidad. Para Realm solo usamos almacenamientos similares para tener acceso al almacenamiento local.

Managers layer es un lugar donde viven nuestras abstracciones/envoltorios.

En un gestor el papel podría ser:

• Gestor de credenciales con sus diferentes implementaciones (keychain, NSDefaults, ...)
• Administrador de sesión actual que sabe cómo mantener y proporcionar la sesión de usuario actual
• Canalización de captura que proporciona acceso a dispositivos multimedia (grabación de video, audio, toma de fotografías)
• BLE Manager que proporciona acceso a servicios bluetooth y periféricos
• Geo Location Manager
• ...

Entonces, en el papel de gerente podría ser cualquier objeto que implementa la lógica de un aspecto particular o preocupación necesaria para el funcionamiento de la aplicación.

Tratamos de evitar Singletons, pero esta capa es un lugar donde viven si son necesarios.

Coordinators layer proporciona objetos que dependen de objetos de otras capas (Servicio, Almacenamiento, Modelo) para combinar su lógica en una secuencia de trabajo necesaria para cierto módulo (característica, pantalla, historia de usuario o experiencia de usuario). Por lo general, las cadenas operaciones asíncronas y sabe cómo reaccionar en sus casos de éxito y fracaso. Como ejemplo, puede imaginar una función de mensajería y el objeto MessagingCoordinator correspondiente. El manejo de la operación de envío de mensajes podría tener este aspecto:

1. Validar mensaje (capa modelo)
2. Guardar mensaje localmente (almacenamiento de mensajes)
3. Archivo adjunto de mensaje de carga (servicio amazon s3)
4. Actualice el estado del mensaje y las url de los archivos adjuntos y guarde el mensaje localmente (almacenamiento de mensajes)
5. Serializar el mensaje en formato JSON (capa modelo)
6. Publicar mensaje en PubNub (servicio PubNub)
7. Actualice el estado y los atributos de los mensajes y guárdelos localmente (almacenamiento de mensajes)

En cada uno de los pasos anteriores se maneja un error correspondiente.

La capa UI consiste en las siguientes subcapas:

1. ViewModels
2. ViewController
3. Vistas

Para evitar Controladores de Vista Masivos, usamos MVVM pattern and implement logic needed for UI presentation in ViewModels. Un ViewModel generalmente tiene coordinadores y gerentes como dependencias. ViewModels usados por ViewController y algunos tipos de Vistas (por ejemplo, celdas de vista de tabla). El pegamento entre ViewController y ViewModels es el enlace de datos y el patrón de comandos. Para que sea posible tener ese pegamento utilizamos la biblioteca ReactiveCocoa .

También utilizamos ReactiveCocoa y su concepto RACSignal como interfaz y valor de retorno tipo de todos los coordinadores, servicios, métodos de almacenamiento. Esto nos permite encadenar operaciones, ejecutarlas de forma paralela o en serie, y muchas otras cosas útiles que proporciona ReactiveCocoa.

Tratamos de implementar nuestro comportamiento de interfaz de usuario de manera declarativa. El enlace de datos y el Diseño automático ayudan mucho a lograr este objetivo.

Infrastructure layer contiene todos los helpers, extensiones, utilidades necesarias para el trabajo de la aplicación.

Este enfoque funciona bien para nosotros y para aquellos tipos de aplicaciones que solemos construir. Pero usted debe entender, que esto es solo un enfoque subjetivo que debe ser adaptado/cambiado para el propósito concreto del equipo.

¡Espero que esto te ayude!

También puedes encontrar más información sobre el proceso de desarrollo de iOS en esta entrada de blog Desarrollo de iOS como servicio

Debido a que todas las aplicaciones de iOS son diferentes, creo que hay diferentes enfoques aquí para considerar, pero por lo general voy de esta manera:
Cree una clase central manager (singleton) para manejar todas las solicitudes de API (generalmente llamadas APICommunicator) y cada método de instancia es una llamada de API. Y hay un método central (no público):

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

Para el registro, utilizo 2 bibliotecas/marcos principales, ReactiveCocoa y AFNetworking. ReactiveCocoa maneja redes asíncronas respuestas perfectamente, puede hacer (sendNext:, sendError:, etc.).
Este método llama a la API, obtiene los resultados y los envía a través de RAC en formato' raw ' (como NSArray lo que devuelve AFNetworking).
Luego, un método como getStuffList: que llamó al método anterior se suscribe a su señal, analiza los datos sin procesar en objetos (con algo como Motis) y envía los objetos uno por uno a la persona que llama (getStuffList: y métodos similares también devuelven una señal a la que el controlador puede suscribirse).
El el controlador suscrito recibe los objetos por el bloque subscribeNext: y los maneja.

Probé muchas maneras en diferentes aplicaciones, pero esta funcionó mejor de todas, así que he estado usando esto en algunas aplicaciones recientemente, se adapta a proyectos pequeños y grandes y es fácil de extender y mantener si algo necesita ser modificado.
Espero que esto ayude, me gustaría escuchar las opiniones de otros sobre mi enfoque y tal vez cómo otros piensan que esto podría mejorarse.

En mi situación suelo usar la biblioteca ResKit para configurar la capa de red. Proporciona un análisis fácil de usar. Reduce mi esfuerzo en configurar el mapeo para diferentes respuestas y cosas.

Solo añado algún código para configurar la asignación automáticamente. Defino la clase base para mis modelos (no protocolo debido a la gran cantidad de código para comprobar si algún método se implementa o no, y menos código en los propios modelos):

Entrada mapable.h

@interface MappableEntity : NSObject

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

@end

Entrada mapable.m

@implementation MappableEntity

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

+(NSArray*)keyPathes {
    return nil;
}

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

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

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

@end

Las relaciones son objetos que representan objetos anidados en respuesta:

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

Entonces estoy configurando la asignación para RestKit de la siguiente manera:

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

Algunos ejemplos de aplicación de la entrada cartográfica:

Usuario.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

Usuario.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

Ahora sobre el empaquetado de solicitudes:

Tengo un archivo de encabezado con definición de bloques, para reducir la longitud de la línea en todas las clases APIRequest:

APICallbacks.h

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

Y Ejemplo de mi clase APIRequest que estoy usando:

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

Y todo lo que necesitas para hacerlo en código, simplemente inicialice el objeto API y llámelo cuando lo necesite:

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

Mi código no es perfecto, pero es fácil de configurar una vez y usar para diferentes proyectos. Si es interesante para alguien, mb podría pasar algún tiempo y hacer una solución universal para él en algún lugar en GitHub y CocoaPods.

En mi opinión, toda la arquitectura de software está impulsada por la necesidad. Si esto es para fines de aprendizaje o personales, a continuación, decidir el objetivo principal y tienen que conducir la arquitectura. Si se trata de un trabajo de alquiler, entonces la necesidad del negocio es primordial. El truco es no dejar que las cosas brillantes te distraigan de las necesidades reales. Encuentro esto difícil de hacer. Siempre hay nuevas cosas brillantes que aparecen en este negocio y muchas de ellas no son útiles, pero no siempre se puede decir que por adelantado. Centrarse en la necesidad y ser dispuesto a abandonar las malas decisiones si puedes.

Por ejemplo, recientemente hice un prototipo rápido de una aplicación para compartir fotos para un negocio local. Dado que la necesidad del negocio era hacer algo rápido y sucio, la arquitectura terminó siendo un código de iOS para abrir una cámara y un código de red adjunto a un botón de envío que cargaba la imagen en una tienda S3 y escribía en un dominio SimpleDB. El código era trivial y el costo mínimo y el cliente tiene una colección de fotos escalable accesible a través de la web con llamadas REST. Barata y tonta, la aplicación tenía muchos defectos y bloquearía la interfaz de usuario en ocasiones, pero sería un desperdicio hacer más por un prototipo y les permite implementar a su personal y generar miles de imágenes de prueba fácilmente sin problemas de rendimiento o escalabilidad. Arquitectura de mierda, pero se ajustaba a la necesidad y costaba perfectamente.

Otro proyecto consistió en implementar una base de datos segura local que se sincroniza con el sistema de la empresa en segundo plano cuando la red está disponible. Creé un sincronizador de fondo que usaba RestKit ya que parecía tener todo lo que necesitaba. Pero tuve que escribir tanto código personalizado para RestKit para lidiar con JSON idiosincráticos que podría haberlo hecho todo más rápido escribiendo mi propio JSON en transformaciones CoreData. Sin embargo, el cliente quería traer esta aplicación en casa y sentí que RestKit sería similar a los marcos que usaban en otras plataformas. Esperaba ver si era una buena decisión.

De nuevo, el la cuestión para mí es centrarme en la necesidad y dejar que eso determine la arquitectura. Trato como el infierno de evitar el uso de paquetes de terceros, ya que traen costos que solo aparece después de que la aplicación ha estado en el campo durante un tiempo. Yo trato de evitar hacer jerarquías de clase ya que rara vez se paga. Si puedo escribir algo en un período de tiempo razonable en lugar de adoptar un paquete que no encaja perfectamente, entonces lo hago. Mi código está bien estructurado para la depuración y adecuadamente comentado, pero de terceros los paquetes rara vez lo son. Dicho esto, me parece que AF Networking es demasiado útil para ignorar y bien estructurado, bien comentado y mantenido, ¡y lo uso mucho! RestKit cubre muchos casos comunes, pero siento que he estado en una pelea cuando lo uso, y la mayoría de las fuentes de datos que encuentro están llenas de peculiaridades y problemas que se manejan mejor con código personalizado. En mis últimas aplicaciones solo uso los convertidores JSON incorporados y escribo algunos métodos de utilidad.

Un patrón que siempre uso es para obtener el la red llama al hilo principal. Las últimas 4-5 aplicaciones que he hecho configurar una tarea de temporizador en segundo plano utilizando dispatch_source_create que se despierta de vez en cuando y hace tareas de red según sea necesario. Necesitas hacer algo de trabajo de seguridad de subprocesos y asegurarte de que el código de modificación de la interfaz de usuario se envíe al subproceso principal. También ayuda a hacer su incorporación/inicialización de tal manera que el usuario no se sienta agobiado o retrasado. Hasta ahora esto ha funcionado bastante bien. Sugiero mirar en estos cosa.

Finalmente, creo que a medida que trabajamos más y a medida que el sistema operativo evoluciona, tendemos a desarrollar mejores soluciones. Me ha llevado años superar mi creencia de que tengo que seguir patrones y diseños que otras personas afirman que son obligatorios. Si estoy trabajando en un contexto donde eso es parte de la religión local, ejem, me refiero a las mejores prácticas de ingeniería departamentales, entonces sigo las costumbres al pie de la letra, eso es por lo que me están pagando. Pero rara vez encuentro que siguiendo diseños más antiguos y patrones es la solución óptima. Siempre trato de ver la solución a través del prisma de las necesidades del negocio y construir la arquitectura para que coincida y mantener las cosas tan simples como pueden ser. Cuando siento que no hay suficiente, pero todo funciona correctamente, entonces estoy en el camino correcto.

Utilizo el enfoque que he obtenido de aquí: https://github.com/Constantine-Fry/Foursquare-API-v2 . He reescrito esa biblioteca en Swift y se puede ver el enfoque arquitectónico de estas partes del código:

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

Básicamente, hay una subclase NSOperation que hace la NSURLRequest, analiza la respuesta JSON y agrega el bloque de devolución de llamada con el resultado a la cola. La clase API principal construye NSURLRequest, inicializa esa subclase NSOperation y la agrega a la cola.

Utilizamos algunos enfoques dependiendo de la situación. Para la mayoría de las cosas, AFNetworking es el enfoque más simple y robusto, ya que puede establecer encabezados, cargar datos de varias partes, usar GET, POST, PUT & DELETE y hay un montón de categorías adicionales para UIKit que le permiten, por ejemplo, establecer una imagen desde una url. En una aplicación compleja con muchas llamadas a veces abstraemos esto a un método de conveniencia propio que sería algo como:

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

Hay algunos sin embargo, situaciones en las que AFNetworking no es apropiado, como cuando está creando un marco u otro componente de biblioteca, ya que AFNetworking puede estar ya en otra base de código. En esta situación, usaría una NSMutableURLRequest ya sea en línea si está haciendo una sola llamada o abstraída en una clase request / response.

Evito los singletons al diseñar mis aplicaciones. Son una opción típica para mucha gente, pero creo que puedes encontrar soluciones más elegantes en otros lugares. Normalmente lo que hago es construir mis entidades en CoreData y luego poner mi código REST en una categoría NSManagedObject. Si por ejemplo quisiera crear y PUBLICAR un nuevo Usuario, haría esto:

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

Utilizo RestKit para el mapeo de objetos y lo inicializo al iniciar. Me parece enrutar todas sus llamadas a través de un singleton para ser un pérdida de tiempo y añade un montón de repeticiones que no es necesario.

En NSManagedObject+Extensiones.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];
}

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

¿Por qué agregar clases auxiliares adicionales cuando puede extender la funcionalidad de una clase base común a través de categorías?

Si está interesado en información más detallada sobre mi solución, hágamelo saber. Estoy feliz de compartir.

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

Cree solicitudes de API en clases separadas.

STNetTaskQueue se ocupará de los subprocesos y delegar/callback.

Ampliable para diferentes protocolos.

Desde una perspectiva puramente de diseño de clases, generalmente tendrá algo como esto:

• Sus controladores de vista controlando una o más vistas

• Clase de modelo de datos - Realmente depende de cuántas entidades distintas reales está tratando, y cómo están relacionadas.

  Por ejemplo, si tiene una matriz de elementos que se mostrarán en cuatro representaciones diferentes (lista, gráfico, gráfico, etc.), tendrá una clase de modelo de datos para la lista de artículos, uno más por un artículo. La lista de la clase de elemento será compartida por cuatro controladores de vista, todos hijos de un controlador de barra de pestañas o un controlador de navegación.

  Las clases de modelo de datos serán útiles no solo para mostrar datos, sino también para serializarlos en donde cada uno de ellos puede exponer su propio formato de serialización a través de métodos de exportación JSON / XML / CSV (o cualquier otra cosa).

• Es importante entender que también necesita API request builder classes ese mapa directamente con sus endpoints de API REST. Supongamos que tiene una API que registra al usuario, por lo que su clase Login API builder creará una carga útil POST JSON para la api de inicio de sesión. En otro ejemplo, una clase API request builder para la API list of catalog items creará la cadena GET query para la api correspondiente y activará el RESTO GET query.

  Estas clases de generador de solicitudes de API generalmente recibirán datos de los controladores de vista y también pasarán los mismos datos a los controladores de vista para la actualización de la interfaz de usuario / otras operaciones. Los controladores de vista decidirán entonces cómo actualizar los objetos del Modelo de datos con esos datos.

• Finalmente, el corazón del cliente REST - API data fetcher class que es ajeno a todo tipo de solicitudes de API que realiza su aplicación. Esta clase será más probable que sea un singleton, pero como otros señalaron, no tiene que ser un singleton.

  Tenga en cuenta que el enlace es solo una implementación típica y no tiene en cuenta escenarios como sesión, cookies, etc., pero es suficiente para que te pongas en marcha sin usar ningún marco de terceros.

Esta pregunta ya tiene muchas respuestas excelentes y extensas, pero siento que tengo que mencionarla ya que nadie más lo ha hecho.

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

Es creado por las mismas personas que AFNetworking, pero está diseñado más directamente con Swift en mente.