Artículo anterior

Si aún no habéis leido el artículo anterior, podéis consultarlo en Desarrollo iOS: Primeros pasos con UICollectionView (parte I).

Introducción

No, no os creáis que vamos a hacer el nuevo Angry Birds, será algo más sencillo: el típico de emparejar cartas iguales.

Empezamos creando una nueva aplicación iOS a partir de la plantilla Single View Application que llamaremos “Memorion”. En principio, la haremos exclusivamente para iPad usando ARC y Storyboards (si, habéis leído bien: storyboards). La única precaución que tendremos al trabajar con Storyboards es desactivar el Auto Layout ya que, de lo contrario, tendremos problemas… serios problemas.

1
2
3
4
5
6
7
8
9
10
11

#import <UIKit/UIKit.h>
 
@interface ZNKViewController : UIViewController <UICollectionViewDataSource, UICollectionViewDelegate, UICollectionViewDelegateFlowLayout>
 
@property (strong, nonatomic) IBOutlet UISegmentedControl *levelControl;
@property (strong, nonatomic) IBOutlet UIButton *mainButton;
@property (strong, nonatomic) IBOutlet UICollectionView *collectionView;
 
- (IBAction)levelChanged:(id)sender;
 
@end

1
2
3
4
5
6
7
8

#import <UIKit/UIKit.h>
 
@interface ZNKMemoryCell : UICollectionViewCell
 
@property (strong, nonatomic) IBOutlet UIImageView *secretImageView;
@property (strong, nonatomic) IBOutlet UIImageView *coverImageView;
 
@end

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

#pragma mark - UICollectionView Data Source Methods
 
- (NSInteger)collectionView:(UICollectionView *)collectionView numberOfItemsInSection:(NSInteger)section
{
    return pow((_levelControl.selectedSegmentIndex + 1) * 2, 2);
}
 
- (NSInteger)numberOfSectionsInCollectionView:(UICollectionView *)collectionView
{
    return 1;
}
 
- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath
{
    // we're going to use a custom UICollectionViewCell, which will hold an image and its label
    //
    ZNKMemoryCell *cell = [collectionView dequeueReusableCellWithReuseIdentifier:@"collectionViewCell" forIndexPath:indexPath];
 
    // make the cell's title the actual NSIndexPath value
    cell.coverImageView.image = [UIImage imageNamed:@"105.png"];
 
    return cell;
 
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#pragma mark – UICollectionViewDelegateFlowLayout
 
- (CGSize)collectionView:(UICollectionView *)collectionView layout:(UICollectionViewLayout*)collectionViewLayout sizeForItemAtIndexPath:(NSIndexPath *)indexPath {
 
    int screenWidth = _collectionView.bounds.size.width;
 
    NSInteger width = screenWidth / ((_levelControl.selectedSegmentIndex + 1) * 2);
 
    CGSize cellSize = CGSizeMake(width, width);
 
    return cellSize;
 
}
 
- (CGFloat)collectionView:(UICollectionView *)collectionView layout:(UICollectionViewLayout*)collectionViewLayout minimumInteritemSpacingForSectionAtIndex:(NSInteger)section
{
    return 0;
}
 
- (CGFloat)collectionView:(UICollectionView *)collectionView layout:(UICollectionViewLayout*)collectionViewLayout minimumLineSpacingForSectionAtIndex:(NSInteger)section
{
    return 0;
}

1
2
3
4
5
6

#pragma mark - UICollectionView Delegate
 
- (void)collectionView:(UICollectionView *)collectionView didSelectItemAtIndexPath:(NSIndexPath *)indexPath
{
 
}

1
2
3
4
5

- (IBAction)levelChanged:(id)sender {
 
    [_collectionView reloadData];
 
}

1
2
3
4
5
6
7

#import <Foundation/Foundation.h>
 
@interface ZNKMemoryGame : NSObject
 
    + (id)sharedInstance;
 
@end

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

#import "ZNKMemoryGame.h"
 
@implementation ZNKMemoryGame
 
+ (id)sharedInstance {
   static ZNKMemoryGame *sharedInstance = nil;
   static dispatch_once_t onceToken;
   dispatch_once(&onceToken, ^{
       sharedInstance = [[self alloc] init];
   });
   return sharedInstance;
}
 
- (id)init {
   if (self = [super init]) {
 
   }
   return self;
}
 
@end

1
2
3
4
5
6

@property (strong, nonatomic) NSMutableArray *arrayOfItems;
@property (strong, nonatomic) NSMutableArray *arrayOfSelected;
@property (strong, nonatomic) NSMutableArray *arrayOfDiscovered;
@property int level;
 
- (void)newGameWithLevel:(int)level;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

- (id)init {
    if (self = [super init]) {
        _level = 1;
        [self newGameWithLevel:_level];
    }
    return self;
}
 
#pragma mark - Metodos para la gestión de los arrays
 
- (void)newGameWithLevel:(int)level
{
    _level = level;
    int numberOfItems = pow(((_level + 1) * 2), 2);
 
    if (!_arrayOfDiscovered) {
        _arrayOfDiscovered = [[NSMutableArray alloc] initWithCapacity:0];
    } else {
        [_arrayOfDiscovered removeAllObjects];
    }
    for (int i = 0; i < numberOfItems; i++) {
        [_arrayOfDiscovered addObject:@"NO"];
    }
 
    if (!_arrayOfSelected) {
        _arrayOfSelected = [[NSMutableArray alloc] initWithCapacity:0];
    } else {
        [_arrayOfSelected removeAllObjects];
    }
 
    if (!_arrayOfItems) {
        _arrayOfItems = [[NSMutableArray alloc] init];
    } else {
        [_arrayOfItems removeAllObjects];
    }
    for (int i = 0; i < numberOfItems / 2 ; i++) {
        [_arrayOfItems addObject:[UIImage imageNamed:[NSString stringWithFormat:@"%i.png", i+1]]];
    }
    [_arrayOfItems addObjectsFromArray:_arrayOfItems];
    [self shuffle];
 
}
 
- (void)shuffle
{
    NSUInteger count = [_arrayOfItems count];
    for (NSUInteger i = 0; i < count; ++i) {
        // Select a random element between i and end of array to swap with.
        NSInteger nElements = count - i;
        NSInteger n = (arc4random() % nElements) + i;
        [_arrayOfItems exchangeObjectAtIndex:i withObjectAtIndex:n];
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

- (void)viewDidLoad
{
    [super viewDidLoad];
    // Do any additional setup after loading the view, typically from a nib.
    _memoryGame = [ZNKMemoryGame sharedInstance];
    _levelControl.selectedSegmentIndex = _memoryGame.level;
}
 
- (IBAction)levelChanged:(id)sender {
 
    [_memoryGame newGameWithLevel:_levelControl.selectedSegmentIndex];
    [_collectionView reloadData];
 
}
 
- (NSInteger)collectionView:(UICollectionView *)collectionView numberOfItemsInSection:(NSInteger)section
{
     return [_memoryGame.arrayOfItems count];
}
 
- (CGSize)collectionView:(UICollectionView *)collectionView layout:(UICollectionViewLayout*)collectionViewLayout sizeForItemAtIndexPath:(NSIndexPath *)indexPath {
 
    int screenWidth = _collectionView.bounds.size.width;
 
    NSInteger width = screenWidth / sqrt([_memoryGame.arrayOfItems count]);
 
     CGSize cellSize = CGSizeMake(width, width);
 
     return cellSize;
 
}

1
2

- (BOOL)cellAtIndexPathCanBeSelected:(NSIndexPath *)indexPath;
- (void)checkSelectionWithCompletion:(void (^)(BOOL matched, NSArray *selectedCells))completion;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

- (BOOL)cellAtIndexPathCanBeSelected:(NSIndexPath *)indexPath
{
    if ([[_arrayOfDiscovered objectAtIndex:indexPath.row] isEqualToString:@"NO"]) {
        return YES;
    }
    return NO;
}
 
- (void)checkSelectionWithCompletion:(void (^)(BOOL, NSArray *))completion
{
    if ([_arrayOfSelected count] == 2) {
        NSIndexPath *firstSelection = [_arrayOfSelected objectAtIndex:0];
        NSIndexPath *secondSelection = [_arrayOfSelected objectAtIndex:1];
        if ([[_arrayOfItems objectAtIndex:firstSelection.row] isEqual:[_arrayOfItems objectAtIndex:secondSelection.row]]) {
            completion(YES, _arrayOfSelected);
            [_arrayOfSelected removeAllObjects];
            [_arrayOfDiscovered replaceObjectAtIndex:firstSelection.row withObject:@"YES"];
            [_arrayOfDiscovered replaceObjectAtIndex:secondSelection.row withObject:@"YES"];
            _totalDiscovered += 2;
            [self reloadScoreLabel];
        }
    }
    completion(NO, nil);
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath
{
    ZNKMemoryCell *cell = [collectionView dequeueReusableCellWithReuseIdentifier:@"collectionViewCell" forIndexPath:indexPath];
 
    cell.coverImageView.image = [UIImage imageNamed:@"105.png"];
    cell.secretImageView.image = [_memoryGame.arrayOfItems objectAtIndex:indexPath.row];
    cell.secretImageView.alpha = 0.0;
    cell.coverImageView.alpha = 1.0;
 
    if ([[_memoryGame.arrayOfDiscovered objectAtIndex:indexPath.row] isEqualToString:@"NO"]) {
        cell.backgroundColor = [UIColor colorWithRed:102.0/255.0 green:102.0/255.0 blue:255.0/255.0 alpha:1];
    } else {
        cell.backgroundColor = [UIColor redColor];
        cell.secretImageView.alpha = 1.0;
        cell.coverImageView.alpha = 0.0;
    }
 
    return cell;
 
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

#pragma mark - UICollectionView Delegate
 
- (void)collectionView:(UICollectionView *)collectionView didSelectItemAtIndexPath:(NSIndexPath *)indexPath
{
    if ([_memoryGame cellAtIndexPathCanBeSelected:indexPath]) {
        if ([_memoryGame.arrayOfSelected count] == 2) {
            for (NSIndexPath *indexPathSelected in _memoryGame.arrayOfSelected) {
                [self hideTheShowedObjectAtIndexPath:indexPathSelected];
            }
            [_memoryGame.arrayOfSelected removeAllObjects];
        } else if ([_memoryGame.arrayOfSelected count] == 1) {
            if (![indexPath isEqual:[_memoryGame.arrayOfSelected objectAtIndex:0]]) {
                [self showTheHidenObjectAtIndexPath:indexPath];
                [_memoryGame.arrayOfSelected addObject:indexPath];
            }
        } else {
            [self showTheHidenObjectAtIndexPath:indexPath];
            [_memoryGame.arrayOfSelected addObject:indexPath];
        }
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

#pragma mark - Animated selections
 
-(void)showTheHidenObjectAtIndexPath:(NSIndexPath *)indexPath
{
    ZNKMemoryCell *cell = (ZNKMemoryCell *)[_collectionView cellForItemAtIndexPath:indexPath];
    cell.secretImageView.alpha = 0.0;
    cell.coverImageView.alpha = 1.0;
 
    [UIView animateWithDuration:0.5 animations:^{
        cell.secretImageView.alpha = 1.0;
        cell.coverImageView.alpha = 0.0;
    } completion:^(BOOL finished) {
        [_memoryGame checkSelectionWithCompletion:^(BOOL matched, NSArray *selectedCells) {
            if (matched) {
                for (NSIndexPath *cell in selectedCells) {
                    [self changeTheColorOfTheCellAtIndexPath:cell];
                }
            }
        }];
    }];
}
 
-(void)hideTheShowedObjectAtIndexPath:(NSIndexPath *)indexPath
{
    ZNKMemoryCell *cell = (ZNKMemoryCell *)[_collectionView cellForItemAtIndexPath:indexPath];
    cell.secretImageView.alpha = 1.0;
    cell.coverImageView.alpha = 0.0;
 
    [UIView animateWithDuration:0.5 animations:^{
        cell.secretImageView.alpha = 0.0;
        cell.coverImageView.alpha = 1.0;
    }];
}

1
2
3
4
5
6
7

-(void)changeTheColorOfTheCellAtIndexPath:(NSIndexPath *)indexPath
{
    ZNKMemoryCell *cell = (ZNKMemoryCell *)[_collectionView cellForItemAtIndexPath:indexPath];
    [UIView animateWithDuration:0.25 animations:^{
        cell.backgroundColor = [UIColor redColor];
    }];    
}

The post Desarrollo iOS: Primeros pasos con UICollectionView (parte II) appeared first on Miguel Diaz Rubio.

Introducción

Apple lanza con iOS 6 una gran novedad para UIKit, que son las UICollectionView. Según ellos mismos indican, su objetivo es dotar al desarrollador de nuevos mecanismos para mostrar grandes cantidades de información de forma más versátil que las actuales UITableView.

Una UICollectionView esta estructurada inicialmente en filas y columnas, aunque es posible definir formas de presentación a medida, como presentación circular de elementos como si de una ruleta se tratase, y todo aquello que nos permita nuestra imaginación.

Básicamente una UICollectionView esta compuesta por los siguientes elementos:

• Items
• Supplementary Views: inicialmente pensadas para definir cabeceras para las diferentes sections de nuestra UICollectionView.
• Decoration Views: las cuales nos permiten configurar elementos adicionales a los items, como el fondo de la UICollectionView y otros.

Rellenar los datos de la UICollectionView

Para nutrir de contenido nuestro UICollectionView tenemos el protocolo UICollectionViewDataSource:

• numberOfSectionsInCollectionView: si no se implementa se asume que solo hay 1 sección.
• collectionView:numberOfItemsInSection: para cada sección se llamará a este método.
• collectionView:cellForItemAtIndexPath: que configurará cada item antes de mostrarlo. Únicamente nos debemos encargar de qué mostrar en cada item, no de donde se muestra el item en cuestión.

El concepto de reutilización de celdas también se aplica a las vistas en si mismas (dequeueReusableCellWithReuseIdentifier y dequeueReusableSupplementaryViewOfKind). Además, para el que se lo haya perdido, desde iOS 6 ya no es necesario en UITableView ni UICollectionView comprobar si al recuperar un item reusable nos ha devuelto nil, ahora en ese caso nos genera un nuevo item.

Interactuar con la UICollectionView

Para interactuar con la UICollectionView tenemos el protocolo UICollectionViewDelegate que controla los siguientes comportamientos:

• Hightlight de un item
• Selección de un item
• Menú secundario

Para gestionar estos estados de highlighting y selection tenemos dos propiedades BOOL, selected y highlighted.

Cuando el usuario pulsa un item, se ejecuta el método shouldHighlightItemAtIndexPath. Si devuelve NO, se interrumpe el proceso de selección del item, y en caso de que devuelva YES, se invoca al método didHighlightItemAtIndexPath dejando la propiedad hightlight a YES.

Una vez que el usuario separa el dedo del item seleccionado (touch up inside), se ejecuta el método shouldSelectItemAtIndexPath. Si se devuelve YES, se marca la propiedad selected como YES, de nuevo se cambia el valor de highlighted a NO, y se invoca al método didSelectItemAtIndexPath.

En el caso de la de-selección ocurre la misma secuencia que en la selección pero con los correspondientes métodos.

Algo muy interesante a comentar, es que cuando un item se marca como selected o hightlighted, el UICollectionView navegará por todo el árbol de vistas que componen dicho item, y si alguna de ellas implementa los métodos setSelected o setHightlighted, éstos serán ejecutados automáticamente. Esto nos permite establecer comportamientos especificos de los elementos que componen un item para los estados de highlight y selected sin encargarnos de dicha gestión.

Estilos de la UICollectionView

En el caso de UICollectionView no existen estilos por defecto para los items, tal y como ocurre con las UITableView (Basic, Subtitle, Left detail y Right detail). Sin embargo, incluye algunas funcionalidades interesantes como son: background view y selected background, que permiten configurar un fondo del item dependiendo del estado del mismo. Dicho cambio se realiza automáticamente sin tener que implementar ningún código, solo definir ambas vistas para sus fondos.

Jerarquía de vistas de una UICollectionViewCell

Como supongo que habréis intuido, cada un de los items que componen un UICollectionView son objetos de tipo UICollectionViewCell.

La jerarquía de vistas de una UICollectionViewCell es la siguiente:

• UICollectionViewCell: es el propio item.
• Background View: es la vista que compone el fondo de nuestro item por defecto.
• Selected Background View: es la vista que compone el fonde de nuestro item cuando éste se encuentra seleccionado.
• Content View: es la vista que contiene todos los elementos que conforman la interfaz de la misma, como puedan ser UILabels, UITextView, UIImageView, etc.

UICollectionViewLayout (UICollectionViewFlowLayout)

Todos los elementos anteriores, ya sean las vistas que componen cada item, como los metodos que debemos implementar para definir su aspecto y comportamiento, unicamente abarcan el cómo son los items de nuestra UICollectionView. Sin embargo, para definir el donde se muestran dichos items, debemos incorporar una nueva clase, que es UICollectionViewLayout.

Esta clase, y sus subclases, se encargan de definir como se distribuyen y organizan los items en nuestro UICollectionView.

Por defecto, iOS 6 nos provee de una subclase de ésta denominada UICollectionViewFlowLayout, que basicamente se podría asemejar a lo que muestra la aplicación Fotos de iOS. Nos permite distribuir en modo rejilla, los diferentes items de que dispongamos gestionando automaticamente el espacio disponible para cada uno de ellos, independientemente de su tamaño. Es decir, que si considera que en una fila van a poder mostrarse 5 items y en otra fila por tratarse de items mas grandes solo 3, él se encargará de todo lo necesario.

Dentro de las opciones de configuración o personalización de UICollectionViewFlowLayout encontramos las siguientes:

• Tamaño de los items: puede configurarse a nivel global mediante la propiedad layout.itemSize, o bien a través del método sizeForItemAtIndexPath del protocolo.
• Espacio entre items (horizontal): donde podemos definir la distancia mínima entre items. Tambié n puede definirse a nivel global o a nivel sección a través de los métodos delegados minimumInteritemSpacingForSectionAtIndex.
• Espacio entre items (vertical): donde igualmente podemos defini la distancia mínima entre dos filas de items. También puede definirse a nivel global o a nivel sección a través de los métodos delegados minimumLineSpacingForSectionAtIndex.
• Dirección del scroll (vertical u horizontal)
• Tamaño de la cabecera y pie: se pueden definir a nivel global mediante headerReferenceSize y footerReferenceSize o bien a través de los métodos delegados referenceSizeForHeaderInSection y referenceSizeForFooterInSection. El tamaño proporcionado es un CGSize con valores ancho y alto. Dependera de si nuestra colección esta en formato vertical u horizontal el que se utilice uno u otro valor.
• Padding entre secciones: podemos definir el espacio que queramos definir como margen o colchon alrededor de los items que componen uno de nuestras secciones.

Los métodos delegados indicados anteriormente corresponden al protocolo UICollectionViewDelegateFlowLayout que básicamente es una subclase de UICollectionViewDelegate.

Si por cualquier motivo necesitamos una distribución totalmente diferente a lo ofrecido por UICollectionViewFlowLayout, podemos crear nuestra propia subclase de UICollectionViewLayout, pero eso lo dejo para los mas valientes, dado que no es algo sencillo.

Práctica

Para los que no os hayáis dormido y aún sigáis leyendo, en el próximo artículo podréis poner en práctica estos conceptos en un juego para niños de encontrar parejas utilizando UICollectionView, cortesía de un nuevo colaborador del blog, Javi Moreno (@jmoreno78).

Podéis consultar el artículo en: Desarrollo iOS: Primeros pasos con UICollectionView (parte II)

¡Os esperamos en el próximo artículo!

The post Desarrollo iOS: Primeros pasos con UICollectionView (parte I) appeared first on Miguel Diaz Rubio.

Introducción

Como ya comentábamos en el artículo Desarrollo iOS: Accede a los contactos con el framework AddressBook anteriormente, desde la salida de iOS 6, Apple ha reforzado bastante la seguridad en lo referente al acceso a datos del usuario y su privacidad.

Hay ciertas cosas que nos va a permitir hacer Apple con respecto a los calendarios y que veremos con mas detalle durante el artículo:

• Acceder internamente, previa aceptación del usuario, a los diferentes calendarios disponibles y los eventos que contiene, dando incluso la posibilidad de crear eventos nuevos sin la intervención del usuario.
• Editar eventos del usuario mediante la presentación en pantalla de los controladores propios de Apple para calendarios y donde el usuario debe realizar las acciones de edición y/o eliminación. Esta tarea no la hará el EventKit.framework, sino el EventKitUI.framework.
• Crear un calendario propio para nuestra aplicación donde si podremos editar o eliminar eventos internamente sin mostrar UI al usuario.

Como veis, en el momento en que queramos hacer edición o eliminación de eventos que no pertenecen al calendario propio de nuestra aplicación, Apple como es logico no nos lo va a permitir, obligándonos a presentar al usuario cuadros de dialogo pertenecientes a la aplicación Calendario donde será el usuario quien realice o no dicha acción. Esto, aunque quita libertad a los desarrolladores, nos protege a los usuarios frente a que por un error del programador de una aplicación que acabamos de bajar de la AppStore, se nos borren todas las reuniones que teníamos para esta semana.

Solicitar acceso a EventKit

Vamos a crear una nueva aplicación de tipo Single View Application, incluiremos los framework EventKit y EventKitUI, y crearemos un UIButton, tal y como hicimos en el anterior artículo, que tendrá un IBAction denominado obtenerCalendarios.

En segundo lugar y dado que vamos a utilizar esta variable a lo largo de varios métodos de nuestro controlador, vamos a crear una variable en la cabecera:

1
2
3

@interface ViewController () {
    EKEventStore *store;
}

A continuación, debemos garantizar que cuando se carga nuestro controlador, dicha variable es instanciada. Para ello incluimos el siguiente código en el método viewDidLoad del controlador:

1
2
3
4
5

- (void)viewDidLoad {
    [super viewDidLoad];
 
    store = [[EKEventStore alloc] init];
}

A continuación vamos a ver cuales son los pasos que debemos seguir para poder solicitar acceso a los calendarios del usuario, y como hacer una consulta a dichos calendarios:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

- (IBAction)obtenerCalendarios {
 
    [store requestAccessToEntityType:EKEntityTypeEvent completion:^(BOOL granted, NSError *error) {
 
        if (!granted) {
 
            dispatch_async(dispatch_get_main_queue(), ^{
 
            [[[UIAlertView alloc] initWithTitle:@"Error" message:@"Acceso denegado" delegate:self cancelButtonTitle:@"Ok" otherButtonTitles:nil] show];
 
            });
 
        } else {
 
            NSCalendar *calendar = [NSCalendar currentCalendar];
 
            // Creamos la fecha de inicio de nuestra consulta (hace un día)
            NSDateComponents *oneDayAgoComponents = [[NSDateComponents alloc] init];
            oneDayAgoComponents.day = -1;
            NSDate *oneDayAgo = [calendar dateByAddingComponents:oneDayAgoComponents
                                                          toDate:[NSDate date]
                                                         options:0];
 
            // Creamos la fecha de fin de nuestra consulta (dentro de una semana)
            NSDateComponents *oneWeekFromNowComponents = [[NSDateComponents alloc] init];
            oneWeekFromNowComponents.week = 1;
            NSDate *oneWeekFromNow = [calendar dateByAddingComponents:oneWeekFromNowComponents
                                                               toDate:[NSDate date]
                                                              options:0];
 
            // Creamos un predicate para poder hacer la consulta con los datos generados
            NSPredicate *predicate = [store predicateForEventsWithStartDate:oneDayAgo
                                                                    endDate:oneWeekFromNow
                                                                  calendars:nil];
 
            // Solicitamos al EKEventStore el listado de eventos que cumplen
            // el predicate indicado como parámetro
            NSArray *events = [store eventsMatchingPredicate:predicate];
 
            // Recorremos los eventos recuperados
            for (EKEvent *evento in events) {
 
                // Pintamos el título del evento
                NSLog(@"%@",evento.title);
 
            }
 
            // Dado que nos encontramos en un bloque, debemos asegurarnos que las operaciones
            // relativas a UI se ejecutan en el hilo principal. Mostramos un mensaje
            // con el total de eventos para esta semana.
            dispatch_async(dispatch_get_main_queue(), ^{
 
                [[[UIAlertView alloc] initWithTitle:@"Eventos" message:[NSString stringWithFormat:@"Tienes %d eventos para esta semana",[events count]] delegate:self cancelButtonTitle:@"Ok" otherButtonTitles:nil] show];
 
            });
 
        }
    }];
}

Como se puede ver, lo que hacemos es generar un objeto NSDate con la fecha del día de ayer, y otro objeto NSDate con la fecha de dentro de una semana. Invocando al Store mediante un predicado creado previamente con estos valores, obtenemos fácilmente toda la información. Recordar que al estar utilizando bloques, debemos garantizar que la ejecución de las operaciones relativas a UIKit se ejecutan en el hilo principal. Si no sabéis a que me estoy refiriendo con esto, os recomiendo echar un vistazo al artículo Desarrollo iOS: Blocks y GCD (Grand Central Dispatch).

Crear eventos en el calendario del usuario

Aunque no es posible la edición o borrado de eventos del usuario, si es posible crear nuevos eventos en el calendario del usuario, siempre que el usuario autorice a nuestra aplicación a acceder a los calendario (tal y como hemos hecho en el ejemplo anterior).

Para ello, vamos a crear en nuestra espartana interfaz un nuevo botón, para el cual definiremos un IBAction denominado crearEvento.

En dicho método incorporaremos el siguiente código:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

- (IBAction)crearEvento {
 
    [store requestAccessToEntityType:EKEntityTypeEvent completion:^(BOOL granted, NSError *error) {
 
        if (!granted) {
 
            dispatch_async(dispatch_get_main_queue(), ^{
 
            [[[UIAlertView alloc] initWithTitle:@"Error" message:@"Acceso denegado" delegate:self cancelButtonTitle:@"Ok" otherButtonTitles:nil] show];
 
            });
 
        } else {
 
            EKEvent *event = [EKEvent eventWithEventStore:store];
 
            // Configuramos la información basica del evento que vamos a crear
            event.calendar = [store defaultCalendarForNewEvents];
 
            event.title = @"Evento para mi calendario";
 
            // set the start date to the current date/time and the event duration to two hours
            NSDate *startDate = [NSDate date];
            event.startDate = startDate;
            event.endDate = [startDate dateByAddingTimeInterval:3600 * 2];
 
            [store saveEvent:event span:EKSpanThisEvent commit:YES error:nil];
 
            dispatch_async(dispatch_get_main_queue(), ^{
 
                [[[UIAlertView alloc] initWithTitle:@"Error" message:@"Se ha producido un error guardando el evento en el calendario" delegate:self cancelButtonTitle:@"Ok" otherButtonTitles:nil] show];
 
            });
 
        }
    }];
 
}

Como se puede ver, es muy sencillo crear nuevos eventos en el calendario del usuario. Como veiamos al principio, tambien es posible crear nuevos calendarios específicos para nuestra aplicación. Aunque en este artículo no vamos a abordar esta posibilidad, os recomiendo leer la guía Calendar and Reminders Programming Guide.

Como siempre, os dejo el código del ejemplo para que podáis descargarlo.

Espero que os haya gustado el artículo. ¡Nos vemos en el siguiente!

The post Desarrollo iOS: Accede a los calendarios con el framework EventKit appeared first on Miguel Diaz Rubio.

Introducción

Desde hace unos años, prácticamente la totalidad de apps importantes del mercado, hacen uso de plataformas en la nube para permitir entre otras cosas, la sincronización entre varios dispositivos, creación de redes sociales temáticas, entornos colaborativos, etc.

Son muchas las aplicaciones como Facebook, Instagram, Twitter, WhatsApp, Line, Pocket, Flipboard, Foursquare, que no solo cuentan con una app para iPhone o iPad, sino que ademas, por su tipología, requieren un backend donde almacenar toda esa información en la nube, compartida por todos o algunos de los usuarios que la utilizan.

Si nuestra intención es crear aplicaciones digamos de tipo offline, no necesitamos nada de lo que vamos a comentar en este artículo, pero si nuestra idea para una app va mas allá muy posiblemente necesitemos utilizar este tipo de servicios en la nube.

Servicios y funcionalidades

Existen múltiples y con diversas funcionalidades: Amazon Web Services, Microsoft Windows Azure, Parse (recientemente adquirida por Facebook) y otras muchas.

Normalmente estos servicios on-line, ofrecen parte o la totalidad del siguiente catalogo de funcionalidades:

• Modelo de datos: capacidades para la creación de una BBDD online con la que poder interactuar desde los distintos dispositivos que tienen nuestra app.
• Sistemas de autenticación centralizados: que facilitan a nuestra app la creación de cuentas de usuario, autenticación, etc.
• Almacenamiento en la nube: capacidades para almacenar ficheros de todo tipo en la nube (fotografías, archivos, …), que puedan ser utilizados por nuestros usuarios.
• Notificaciones Push: nos permite enviar notificaciones de tipo push a nuestros usuarios siguiendo el criterio que queramos definir.
• Ejecución de código en el servidor: nos permite definir proceso que se ejecutan en el lado servidor.
• Y otros muchos…

Costes y amortización

Estos servicios normalmente son de pago, pero en muchos casos cuentan con versiones gratuitas que podemos utilizar si el volumen de tráfico y peticiones que tiene nuestra aplicación es moderado.

Tener siempre en cuenta, que si creamos una app donde el modelo de negocio este bien definido, y tenemos tantos usuarios que necesitamos pagar mensualmente una ampliación de servicio a Amazon o Parse, éste sera el menor de nuestros problemas, porque significará que la aplicación es de mucho éxito y si tiene un ROI claramente definido, no supondrá ningún problema asumir dicho coste.

¿Como aprendo a utilizar estos servicios?

Sin duda, aprender a utilizar todos estos servicios, o ser capaz de identificar cual es el mas idóneo para implementar en nuestra aplicación, es fruto de la práctica y de la experiencia con cada uno de ellos.

Normalmente todos estos servicios cuentan con una documentación medianamente extensa, la gran mayoría en inglés, pero sin duda éste puede ser un problema porque no es una labor sencilla y no hay demasiados tutoriales o ejemplos por internet.

Yo, después de darle muchas vueltas, he optado seguir el camino mas fácil y con menos riesgo, y voy a asistir como algunos me habréis oído comentar en Twitter al curso que organiza AGBO “Curso de Introducción a los Backends de Terceros”.

El temario del curso no puede ser mas atractivo:

Amazon Web Services

• Visión general de los servicios más significativos para un desarrollador iOS (S3, CDN, EC2, DynamoDB, etc..)
• Cómo esarrollar contra AWS: AWS SDK for iOS (Instalación, configuración del SDK en xCode)
• Práctica 1: App para hacer fotos almacenándolas en S3
• Token Vending Machine o cómo usar credenciales temporales en nuestras Apps
• Práctica 2: Extendiendo la App de Fotografía, usaremos una pequeña BD (DynamoDB) para añadir comentarios a las imágenes.
• Costes

Microsoft Windows Azure

• Visión general de los servicios más significativos para un desarrollador iOS (Queues, Storage, Tables, Mobile Services)
• Caminos para desarrollar contra Azure: API REST vs Windos Azure Toolkil for iOS.
• Práctica 1: Utilizando Mobile Services, usaremos una base de datos SQL Server para almacenar y consultar nuestras canciones favoritas.
• Practica 2: Usaremos API REST para combinar el manejo de Tables y Storage tomando como punto de partida la App de fotos.
• Costes

Parse

• Visión general de los servicios de la plataforma
• Instalación, configuración de un proyecto con el SDK de Parse
• Práctica 1: Login & Signup Views
• Costes
• Distribución de nuestras Apps controlada: TestFlight
• Descripción del servicio
• Comparación con la distribución ad-hoc que nos permite Apple
• Práctica 1: Creación de perfil de distribución, invitación a testers, distribución de una App
• Práctica 2: Explorando el Api de TestFlight – Logging Remoto – Symbolicated Crash Reports – OTA
• Costes.

Mapas: No solo existe Google Maps

• OpenStreetMaps: Alternativa Abierta
• Configuración de un xCode usando MapBox o Route-me SDKs
• Práctica 1: Uso de MapBox o directamente Route-me para localizar nuestra posición
• Google Maps – Licenciamiento & Características de la plataforma)
• Práctica 2: Uso de mapas embebidos en nuestra App

¿Qué hace mi app? ¿Cuántos usuarios usan una determinada funcionalidad?: Estadísticas integradas en las Apps

• Visión general
• Descripción de Google Analitycs for Mobile (GA) y Flurry Analitycs
• Configuración de xCode para integrar GA en nuestras Apps
• Práctica 1: Integración en nuestra App de fotografía GA.
• Configuración de xCode para integrar Flurry Analitycs.
• Práctica 2: Integración en nuestra App de fotografía con Flurry.
• Comparación entre las dos plataformas y otras alternativas.

Cómo usar APNS sin desarrollar un servidor de notificaciones

• Descripción del Apple Push Notification Service
• Practica 1: Provisionar una App para usar APNS
• Servicios de terceros que nos permiten hacer notificaciones “sin desarrollar”
• Urban Airship
• Practica 2: Incorporar el api de Urban Airship Push en la App de fotografías.

Un fin de semana del 31 de mayo al 2 de junio, repleto de conocimiento, donde salir con la maleta llena, con todo lo necesario para afrontar un proyecto de app en condiciones.

Precio y promoción AGBO

El precio el curso, considerando la calidad del docente y del temario a impartir, es mas que razonable. Os recomiendo echarle un vistazo a la web y a todos los detalles del curso.

Además, AGBO esta haciendo una promoción, con la que podéis haceros con una plaza completamente gratis. Podéis consultar toda la información en Curso Backend de Terceros para Apps ¡Gratis!.

Yo estaré en la convocatoria que se imparte los días 31 de mayo, 1 de junio y 2 de junio. ¡Espero veros allí a muchos de vosotros y que podamos frikear un rato y tomarnos una caña!¡No tardéis, quedan muy pocas plazas!

A mi vuelta intentaré escribir algún artículo con los temas que mas interesantes me hayan  parecido, tal y como hice cuando asistí al Curso iOS Intermedio, también en AGBO e impartido por Fernando Rodríguez (@frr149).

The post Desarrollo iOS: Curso de Introducción a los Backends de Terceros appeared first on Miguel Diaz Rubio.

Introducción

Por norma general cuando desarrollamos una app que usa servicios web o accede a páginas a través de un UIWebView, las cookies de estas conexiones nos son transparentes, ya que son gestionadas de forma autónoma por el sistema o el framework que utilicemos para este tipo de acciones.

El servidor en el response envía un Set_Cookie, con el valor de la cookie y el cliente, en este caso la app, la almacena para enviarla cuando se envíen requests al dominio de la cookie.

Pero, ¿que pasa si quiero saber las cookies que tengo almacenadas para una app, reutilizar una cookie para otro dominio , eliminar una o todas las cookies, añadir una nueva o modificar una existente? Aquí nos empiezan a surgir dudas…

Bien, para estos casos tenemos a nuestro servicio desde la versión 2.0 de iOS NSHTTPCookie y NSHTTPCookieStorage que nos van a ayudar con estas tareas.

NSHTTPCookieStorage: es un singleton que gestiona el almacenamiento de cookies, las cuales se mantienen sincronizadas entre procesos, pero a diferencia de OSX, en iOS las cookies no se comparten entre aplicaciones, aunque si la política para aceptarlas, al cambiar el valor de esta propiedad afectará a todas las aplicaciones. El valor por defecto es NSHTTPCookieAcceptPolicyAlways.

NSHTTPCookie: representa una cookie HTTP. Es un objeto inmutable inicializado con un diccionario que contiene los atributos de la cookie. Entre los atributos podemos encontrar:

• Name
• Value
• Domain
• ExpireDate
• Path

Todos los atributos tienen una constante asociada para clave del diccionario y de esta forma, es muy cómodo acceder a los distintos valores.

Visto un poco el escenario y de que disponemos,  vamos a centrarnos en situaciones concretas y ver como actuar. Al final del artículo tenéis un link a un proyecto de ejemplo del que he extraído las imágenes y código que uso a continuación.

Listado de cookies

Para obtener una relación de las cookies almacenadas para una app podemos hacer lo siguiente:

1
2
3
4
5
6
7
8

NSMutableArray *cookies = [NSMutableArray new];
int counter = 1;
for (NSHTTPCookie *cookie in [[NSHTTPCookieStorage sharedHTTPCookieStorage] cookies]) {
        [cookies addObject:[NSString
                            stringWithFormat:@"%d: Nombre = %@ \n Valor = %@\n Dominio = %@\n Path = %@ \n Caduca =%@", counter++, cookie.name, cookie.value, cookie.domain, cookie.path, cookie.expiresDate]];
    }
 
self.textView.text = [cookies componentsJoinedByString:@"\n\n"];

Creamos un NSMutableArray “cookies” para almacenar las cookies del NSHTTPCookieStorage.
Recorremos las cookies y creamos una cadena de strings con las propiedades que queremos mostrar, añadiéndolas a “cookies”.

Las mostramos en un UITextView.

Para probar que funciona el código anterior vamos a utilizar la web de la ATP http://es.atpworldtour.com, que nos devolverá unas cookies en el response.

Antes de visitar la web nuestro listado de cookies luce así:

Después de visitar la página web, el resultado es:

Con estos sencillos pasos, ya tenemos nuestro listado de cookies.

Modificar una cookie

¿Como modificamos una cookie si es inmutable?. Pues lo que hacemos es crear una nueva a partir de la que queremos modificar y asignársela al NSHTTPCookieStorage. Para ello, lo que vamos a hacer es modificar el valor las cookies a “New Value”.

Si solo quisiéramos modificar una de las cookies, podríamos hacerlo comprobando su propiedad “Name”.

1
2
3
4
5
6
7
8
9

for (NSHTTPCookie *cookie in [[NSHTTPCookieStorage sharedHTTPCookieStorage] cookies]) {
 
        NSMutableDictionary *cookieProperties = [cookie.properties mutableCopy];
        [cookieProperties setObject:@"New Value" forKey:NSHTTPCookieValue];
 
        NSHTTPCookie *newCookie = [[NSHTTPCookie alloc] initWithProperties:cookieProperties];
        [[NSHTTPCookieStorage sharedHTTPCookieStorage] setCookie:newCookie];
 
    }

Después de esta modificación el listado de cookies mostraría lo siguiente:

Pero, ¿realmente se envía esto en la request que hacemos? Vamos a comprobarlo utilizando una  aplicación llamada Charles  http://www.charlesproxy.com, de lo mejor que he probado para capturar el tráfico de red. Además si nuestro dispositivo iOS está conectado a la misma red WIFI que nuestro ordenador,  podemos acceder a la configuración de la WIFI en el dispositivo, e indicar que vamos a utilizar nuestro ordenador como proxy, añadiendo tu IP local y el puerto 8888.

De esta forma podrás captura el trafico de red del dispositivo fácilmente.

Esto sería lo que veríamos en la aplicación Charles antes de modificar las cookies:

Una vez modificadas las cookis, Charles sin embargo mostraría lo siguiente:

Como veis, la modificación de las cookies es real, y está siendo usada.

Si quisiéramos, podríamos también reutilizar una cookie para otro dominio. Para ello, tendríamos que crear una cookie igual a la que queremos reutilizar y cambiarle la propiedad “Domain”.

A priori, si pensamos en modificar una cookie, a muchos os vendrá a la cabeza la idea de modificar directamente el NSURLRequest o su equivalente en el framework que estés utilizando.  Esto tiene algunos inconvenientes que me gustaría contaros a continuación:

En primer lugar, Header con Name Cookie solo puede haber 1, por lo que si quieres modificar una cookie tendrías que reescribirlas todas incluida la modificada, si no estaríamos sobrescribiendo las cookies actuales. Las cookies, en el caso que nos ocupan, viajan en la request de la siguiente manera:

“Cookie: __utma=113228507.637317221.1367666511.1367666511.1367666511.1; __utmz=113228507.1367666511.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); “

Por tanto, sería bastante laboriosa la modificación de una de ellas.

Otro problema, es que NSURLRequest es inmutable, y por tanto, habría que utilizar NSMutableURLRequest, y quizás no dependa de nosotros o no tengamos acceso a este objeto, por lo que acabemos modificando un objeto en  una capa superior,  y al enviar la request, la cookie sea de nuevo sustituida por el contenido de NSHTTPCookieStorage y volvamos a estar como al principio.

Eliminando las cookies

Para eliminar una cookie utilizaremos el método delete de NSHTTPCookieStorage. Con este código eliminaremos todas las cookies de nuestra app:

1
2
3

for (NSHTTPCookie *cookie in [[NSHTTPCookieStorage sharedHTTPCookieStorage] cookies]) {
        [[NSHTTPCookieStorage sharedHTTPCookieStorage] deleteCookie:cookie];
}

Igualmente, si solo queremos eliminar una o varias cookies, podríamos filtrar por cualquiera de las propiedades de NSHTTPCookie: Name, domain, expireDate,….

Añadiendo una nueva cookie

A estas alturas, seguro que no tenéis problemas para añadir una nueva cookie, no obstante vamos a analizar los pasos que habría que dar para ello.

Vamos a crear una cookie, cuyo nombre va a ser “customCookie” y valor “Custom Value”, para que se añada a las que ya tenemos en la request al servidor, y le vamos a indicar el mismo dominio que tienen las demás “.atpworldtour.com”. De esta forma, nuestra nueva cookie se añadirá al resto en la request.

Veamos los pasos que deberemos seguir en nuestro código:

Creamos un diccionario para las propiedades de la cookie.

1
2
3
4
5

NSMutableDictionary *cookieProperties = [@{NSHTTPCookieName:    @"CustomCookie",
                                             NSHTTPCookieValue:     @"Custom value",
                                             NSHTTPCookieDomain:    @".atpworldtour.com",
                                             NSHTTPCookieExpires:   [NSDate dateWithTimeIntervalSinceNow:64000],
                                             NSHTTPCookiePath:      @"/”  }mutableCopy];

Creamos la cookie con el diccionario creado.

1

NSHTTPCookie *newCookie = [[NSHTTPCookie alloc] initWithProperties:cookieProperties];

Añadimos la cookie a NSHTTPCookieStorage.

1

[[NSHTTPCookieStorage sharedHTTPCookieStorage] setCookie:newCookie];

Las cookies en nuestra siguiente request ahora serán:

“Cookie: NREUM=h=1367677984548&r=42047&p=0; __utma=113228507.1891220335.1367675684.1367675684.1367675684.1; __utmc=113228507; __utmz=113228507.1367675684.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); CustomCookie=New Value”

Como siempre, os dejamos un ejemplo que ha elaborado Pedro Muñoz con los conceptos aprendidos en este artículo para que podáis descargarlo.

The post Desarrollo iOS: Lidiando con las cookies en Objective-C appeared first on Miguel Diaz Rubio.

Con la llegada de iOS 6 aparece en nuestra aplicación de Ajustes un nuevo menú denominado Privacidad, que nos permite gestionar los permisos que otorgamos a aplicaciones de iOS para acceder a nuestros contenidos, más concretamente: GPS, contactos, calendarios, recordatorios, fotos, y cuentas de Twitter y Facebook.

De esta forma el usuario puede tener total control sobre estas configuraciones, e incluso modificarlas una vez autorizada o denegada una petición de acceso.

Para poder llevar a cabo este acceso a los contactos del dispositivo, vamos a utilizar un framework provisto por Apple, denominado AddressBook.

Vamos a crear una nueva aplicación, de tipo Single View Application, a la cual añadiremos el framework que indicábamos anteriormente, y donde nuestra única interfaz para este ejemplo será un UIButton, para el cual definiremos un IBAction cuyo método denominaremos obtenerContactos.

En primer lugar, vamos a crear una variable para albergar la referencia a nuestra agenda, dado que la vamos a utilizar en varios métodos de nuestra aplicación.

1
2
3
4

@interface ViewController () {
    ABAddressBookRef addressBookRef;
}
@end

La implementación del método obtenerContactos será la siguiente:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

- (IBAction)obtenerContactos {
 
    // Solicitamos al usuario acceso a los contactos (no funciona en el Simulador)
    addressBookRef = ABAddressBookCreateWithOptions(NULL, NULL);
 
    // Comprobamos el estado de permisos de usuario
    if (ABAddressBookGetAuthorizationStatus() == kABAuthorizationStatusNotDetermined) {
        ABAddressBookRequestAccessWithCompletion(addressBookRef, ^(bool granted, CFErrorRef error) {
            // Es la primera vez que accedemos a dichos contactos
            NSLog(@"Primer vez");
            [self pintaContactos];
        });
    }
    else if (ABAddressBookGetAuthorizationStatus() == kABAuthorizationStatusAuthorized) {
        // El usuario ya nos había autorizado previamente el acceso
        NSLog(@"Segundas veces");
        [self pintaContactos];
    }
    else {
        // El usuario ya nos había denegado previamente el acceso
        NSLog(@"Permiso denegado");
        [[[UIAlertView alloc] initWithTitle:@"Error" message:@"Permiso denegado!" delegate:self cancelButtonTitle:@"Ok" otherButtonTitles:nil] show];
    }
 
}

Como observaréis la solicitud de permisos al usuario es bien sencilla, y pueden producirse tres situaciones diferentes:

• El estado de la autorización no esta determinado: por tanto invocamos a la autorización mediante un bloque de finalización que nos permitirá invocar a nuestro método que pinta en el log los contactos una vez dispongamos de la autorización.
• El estado de la autorización se ha definido como permitida anteriormente: por tanto invocaremos a nuestro método que pinta contactos directamente.
• El estado de la autorización se ha definido como denegada anteriormente: mostraremos en pantalla un mensaje de error que permita al usuario entender lo ocurrido.

Es muy importante tener en cuenta, que si utilizamos este ejemplo en el Simulador de XCode no observaremos este comportamiento, dado que solo es funcional en un dispositivo real. En el caso del simulador, siempre funcionará como si se hubiera aceptado el acceso a la agenda, no mostrando en ningún caso el aviso al usuario.

A continuación, vamos a implementar nuestro método pintaContactos:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

- (void)pintaContactos {
 
    // Obtenemos todos los contactos del usuario en base a la referencia obtenida
    CFArrayRef all = ABAddressBookCopyArrayOfAllPeople(addressBookRef);
 
    // Obtenemos el total de contactos encontrados
    CFIndex n = ABAddressBookGetPersonCount(addressBookRef);
 
    // Recorremos todos los contactos
    for( int i = 0 ; i < n ; i++ )
    {
        // Obtenemos el contacto
        ABRecordRef ref = CFArrayGetValueAtIndex(all, i);
 
        // Obtenemos el nombre del contacto
        NSString *firstName = (__bridge NSString *)ABRecordCopyValue(ref, kABPersonFirstNameProperty);
 
        // Pintamos en el log el nombre del contacto
        NSLog(@"First Name: %@",firstName);
 
        // Obtenemos los teléfonos disponibles
        ABMultiValueRef phoneNumberProperty = ABRecordCopyValue(ref, kABPersonPhoneProperty);
        NSArray *phones = (__bridge NSArray*)ABMultiValueCopyArrayOfAllValues(phoneNumberProperty);
 
        for (NSString *telefono in phones) {
            // Pintamos el teléfono del contacto
            NSLog(@"%@",telefono);
        }
 
        // Obtenemos los emails disponibles
        ABMultiValueRef emailProperty = ABRecordCopyValue(ref, kABPersonEmailProperty);
        NSArray *emails = (__bridge NSArray*)ABMultiValueCopyArrayOfAllValues(emailProperty);
 
        for (NSString *email in emails) {
            // Pintamos el email del contacto
            NSLog(@"%@",email);
        }
    }
 
    // Convertimos a NSUInteger el total de contactos
    NSUInteger total = (NSUInteger)n;
 
    // Mostramos una alerta con el total de contactos encontrados
    [[[UIAlertView alloc] initWithTitle:@"Agenda" message:[NSString stringWithFormat:@"Tienes un total de %d contactos",total] delegate:self cancelButtonTitle:@"Ok" otherButtonTitles:nil] show];
}

Para acceder a cada una de las propiedades de un contacto, existen una serie de constantes como kABPersonFirstNameProperty, kABPersonPhoneProperty o kABPersonEmailProperty que nos hacen mas sencilla la labor.

Si queréis más información sobre el acceso a contactos a través de esta API, os recomiendo echar un vistazo a la guía Address Book Programming Guide for iOS, disponible en developer.apple.com.

Os dejo como siempre el código del ejemplo.

Espero que os haya gustado el artículo y ¡hasta el próximo!

The post Desarrollo iOS: Accede a los contactos con el framework AddressBook appeared first on Miguel Diaz Rubio.

Herramientas de analítica Web

Es bien conocido desde hace muchos años, que la analítica web ha permitido a los webmasters un mayor control sobre lo que ocurre en sus páginas web. Ahora es fácil saber si tenemos muchas visitas de España o del resto de países, en qué horario es cuando mas visitas tenemos, cual es la página más vista este mes, y un largo etcétera.

¿Por qué no tener estas mismas ventajas para aplicaciones iOS?

Pues eso es lo que ha debido pensar Google cuando ha incorporado a su producto Google Analytics la posibilidad de analizar la operativa en aplicaciones móviles. De hecho, los desarrolladores de iOS tenemos un SDK para hacernos mas fácil la vida.

Google Analytics SDK

Ahora mismo la versión estable es la 1.0. Sin embargo, Google ya esta trabajando en la versión 2.0, que se encuentra en fase beta y también podemos utilizar.

Para este artículo vamos a utilizar la versión 2.0 beta 4, que es la disponible en el momento en que escribo este artículo.

Lo podéis descargar desde aquí: https://developers.google.com/analytics/devguides/collection/ios/resources

Esta versión de Google Analytics nos va a permitir hacer seguimiento de entre otras, las siguientes acciones:

• El numero de usuarios activos que utilizan vuestra app.
• Desde qué zonas geográficas se utiliza vuestra app.
• Uso que hacen los usuarios de determinadas funcionalidades de la app.
• Compras in-app.
• El número y tipo de errores que hagan terminar nuestra app.
• Y otras muchas métricas…

Dar de alta nuestra app en la web de Google Analytics

Para poder disfrutar de todas estas ventajas, lo primero que tenemos que hacer es obtener un código de seguimiento para nuestra app, y para ello debemos dar de alta la aplicación en el portal de Google Analytics.

Si accedemos a la sección Listado de cuentas, veremos un botón para crear una nueva cuenta.

Se mostrará un formulario sencillo que deberemos rellenar, donde deberemos en primer lugar indicar que somos una aplicación y no un sitio web.

En la parte inferior deberemos indicar el nombre de cuenta que deseemos, que será lo que aparecerá en nuestro listado del portal.

Al pulsar el botón inferior “Obtener ID de seguimiento” se mostrarán las condiciones del servicio, que deberemos aceptar.

Tras estos sencillos pasos, se mostrará una pantalla donde ya tendremos nuestro ID de seguimiento, que será pieza fundamental para todo lo que vamos a hacer a continuación. Éste es el identificador real de nuestra aplicación, y es único.

Integrar el SDK en nuestra aplicación

Una vez descargado el SDK de la web que os indicaba anteriormente, debemos añadir a nuestro proyecto todas las clases que contiene el directorio Library. Os recomiendo crear un nuevo grupo (carpeta) para ello y ubicar todas las clases dentro.

Como Google Analytics para iOS utiliza internamente algunos frameworks de iOS, debemos añadirlos a nuestro proyecto, en la sección “target linked libraries” como hemos hecho en otras ocasiones. Concretamente debemos incorporar los siguientes frameworks:

• libGoogleAnalytics.a
• CoreData.framework
• SystemConfiguration.framework

Para inicializar el tracker de Google en nuestra app, deberemos incluir el siguiente código en el AppDelegate de nuestra aplicación (haciendo previamente import de la clase principal “GAI.h“):

1
2
3
4
5
6
7
8
9
10

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
  // Opcional: envia automáticamente excepciones no controladas de nuestra app a Google.
  [GAI sharedInstance].trackUncaughtExceptions = YES;
  // Opcional: establece 20 segundos como intervalo para comunicar con Google.
  [GAI sharedInstance].dispatchInterval = 20;
  // Opcional: activa el modo debug para obtener información adicional.
  [GAI sharedInstance].debug = YES;
  // Creamos la instancia del tracker indicando el ID de seguimiento que hemos obtenido anteriormente.
  id tracker = [[GAI sharedInstance] trackerWithTrackingId:@"UA-YOUR-TRACKING-ID"];
}

Como se puede observar cuando instanciamos el tracker, se esta utilizando una sharedInstance (patrón Singleteon) que nos devolverá siempre la misma instancia, aunque llamemos en varias ocasiones y desde diferentes puntos de nuestra app.

Hacer tracking de uno de nuestros View Controllers

Para hacer tracking de una de las pantallas de nuestra aplicación, Google nos ofrece dos métodos distintos: automático o manual.

Si optamos por la opción automática, bastará con que nuestro View Controller extienda de la clase GAITrackedViewController, y que incluyamos el siguiente código en el método viewDidLoad del mismo:

1
2
3
4

- (void)viewDidLoad {
  [super viewDidLoad];
  self.trackedViewName = @"Pantalla Acerca de";
}

Esta opción esta muy bien, pero habrá ocasiones en donde nos suponga un problema tener que heredar de dicha clase. Para ello, existe una segunda opción manual que consiste en invocar al tracker directamente. Para ello deberemos instanciarlo, e invocar al siguiente método del mismo:

1

[tracker sendView:@"Pantalla Acerca de"];

Con estos sencillos pasos, vamos a poder obtener mucha información acerca del uso que hacen los usuarios de nuestra aplicación.

Para los que quieran un poquito más

Si queremos obtener aún mas información sobre nuestra app, tal y como indicábamos al principio, tenemos algunas opciones bastante interesantes.

Por ejemplo, es posible que nos interese hacer tracking de cuando nuestros usuarios añaden una nueva tarea a nuestra aplicación de gestión de tareas. Pues bien, para ello tenemos el reporte de eventos. Os pongo un ejemplo a continuación:

1
2
3
4

[tracker sendEventWithCategory:@"Acción de usuario"
                     withAction:@"Nueva tarea añadida"
                      withLabel:nil
                      withValue:nil];

También podemos registrar posibles errores que se produzcan excepciones en nuestra aplicación. Para ello, tenemos el siguiente método:

1
2
3
4
5
6

@try {
  NSArray *resultados= [self obtenerResultadosXML];
}
@catch (NSException *exception) {
  [tracker sendException:NO withNSException:exception);
}

Éste método enviara a Google Analytics la description de la excepción producida automáticamente.

Si queréis información más profunda sobre las posibilidades adicionales que ofrece el SDK os recomiendo que os deis una vuelta por la información disponible en la web del proyecto en Google: https://developers.google.com/analytics/devguides/collection/ios/v2/#headers

Espero que os haya gustado el artículo y que muy pronto lo integréis en vuestras aplicaciones.

Recordar seguirme en twitter para estar a atento a todas las novedades!

The post Desarrollo iOS: Integra Google Analytics en tu app appeared first on Miguel Diaz Rubio.

UDID (Unique Device Identifier)

UDID (Unique Device Identifier) era nuestro mejor candidato hasta hace bien poco. Sin embargo, con iOS 6 Apple lanza al mercado una nueva forma de obtener un identificador de este tipo. En este caso se denomina UUID (Universally Unique Identifiers).

UUID (Universally Unique Identifiers)

Este nuevo método, fue una propuesta de Apple para dar respuesta a la polémica formada alrededor de estos identificadores y de la violación de la privacidad que suponen.

Para que todo el mundo lo entienda, el identificador UDID identifica el dispositivo unívocamente. Sin embargo, el nuevo UUID es un identificado generado en base a información del dispositivo, y utiliza como parte de su algoritmo de generación el número de bloques de 100 nanosegundos transcurridos desde el 15 de octubre de 1582.

Por esto último, si generamos consecutivamente dos identificadores, éstos serán distintos. Es por ello, que mas adelante veremos formas de conservar el valor obtenido inicialmente y conservarlo a lo largo del ciclo de vida de la aplicación.

¿Como obtener el UUID desde mi código?

Hasta ahora, para obtener el UDID hacíamos uso de un método de la case UIDevice:

1

NSString *UDID = [[UIDevice currentDevice] uniqueIdentifier];

Esto nos devolvía una cadena hexadecimal de 40 caracteres como esta:
6f6c9dc83d77134bca4n1c53l1202b395b05582b

Sin embargo, a partir del 1 de mayo de 2013, cualquier aplicación que haga uso de esta llamada a uniqueIndentifier, será rechazada.

En su lugar, si queremos dar soporte a versiones anteriores a iOS 6 deberemos utilizar lo siguiente:

1
2
3
4

CFUUIDRef theUUID = CFUUIDCreate(NULL);
CFStringRef string = CFUUIDCreateString(NULL, theUUID);
CFRelease(theUUID);
NSString *UUID = (__bridge_transfer NSString *)string;

Si en nuestro caso, podemos únicamente dar compatibilidad a partir de iOS 6, podemos hacer uso de este otro método, mucho mas directo:

1

NSString *UUID = [[NSUUID UUID] UUIDString];

Esto generará una cadena hexadecimal separada por guiones del tipo:
68753A44-4D6F-1226-9C60-0050E4C00067

¿Cómo conservo el UUID obtenido?

Una de las opciones que Apple propone para conservar el UUID generado en la primera ejecución de la aplicación, es almacenarlo en el NSUserDefaults. Para ello, tendríamos algo como lo que sigue a continuación:

1
2
3
4
5
6
7

// Comprobamos la existencia en el NSUserDefaults de una variable UUID
NSUserDefaults *prefs = [NSUserDefaults standardUserDefaults];
NSString *UUID = [prefs stringForKey:@"UUID"];
if (!UUID) {
    NSString *miUUID = [[NSUUID UUID] UUIDString];
    [prefs setObject:miUUID forKey:@"UUID"];
}

De esta forma, y ejecutando este código en el arranque de nuestra aplicación, obtendremos un UUID la primera vez, y dicho UUID en las próximas ejecuciones.

Recordar cuando se vaya a cerrar la aplicación, y para evitar pérdida de la información guardada en el NSUserDefaults, hacer un synchronize:

1

[[NSUserDefaults standardUserDefaults] synchronize];

Para los más avanzados, existen otras opciones de persistencia de este UUID, mediante por ejemplo el Llavero (o Keychain), o incluso mediante iCloud, facilitando con éste último la posibilidad de compartir dicho UUID entre dos dispositivos del mismo usuario.

¿Y entonces ya no hay ningún método para identificar un dispositivo unívocamente?

Pues a raíz de esta problemática, han surgido otras alternativas, porque como dice el refrán español: “hecha la ley, hecha la trampa”. Por ejemplo, existen librerías en Github para obtener la MAC de la interfaz de red del dispositivo.

Personalmente, mi consejo sería que os hicierais la siguiente pregunta: ¿realmente lo necesito? La respuesta en muchos casos, os garantizo que será NO. La opción UUID, cubrirá vuestras necesidades en un 90% de los casos.

Espero que os haya gustado el snippet de hoy y ya sabéis que para cualquier duda, tenéis los comentarios más abajo.

The post Snippets iOS: Obtener un identificador único del usuario (UUID) appeared first on Miguel Diaz Rubio.

Este framework se llama MWFeedParser (https://github.com/mwaterfall/MWFeedParser) y su autor es Michael Waterfall (@mwaterfall).

Un poco de teoria

Principalmente la utilización de este framework se basa en el siguiente modelo de datos:

• MWFeedParser: es el servicio que nos va a permitir realizar todas las operaciones de parseo con nuestro feed, que proporcionaremos como parámetro de tipo NSURL. Podemos configurar la recuperación de los datos en modo síncrono o asíncrono. Tambien podemos definir si queremos parsear todos los items recibidos, o bien solo la cabecera del feed.
• MWFeedInfo: que contiene la información relativa al feed que queremos recuperar y parsear, y del cual obtiene los siguientes atributos: title, link y summary.
• MWFeedItem: representa cada uno de los artículos o elementos que se han recuperado del feed indicado. Para cada uno de estos items, podemos consultar la siguiente información: title, link, date, updated, summary, content, enclosured y identifier.

Además de estas clases principales, el framework incluye algunos otros elementos interesantes, como una categoría para NSString denominada NSString+HTML que nos va a permitir hacer encoding/decoding de los tags HTML que contentan los campos que recuperemos del feed en cuestión.

Para el ejemplo que vamos a hacer a continuación, he utilizado Cocoapods para importar la librería MWFeedParser. Si no sabéis de qué estoy hablando, os recomiendo leer el siguiente artículo: Desarrollo iOS: Gestionar dependencias con Cocoapods

Nuestra interfaz

Basicamente nuestra aplicación de ejemplo va a tener dos pantallas: un listado de los artículos encontrados en migueldiazrubio.com (UITableViewController), y una pantalla de detalle con el contenido del artículo seleccionado (UIViewController y UIWebView), ambos embebidos dentro de una navegación (UINavigationController).

En mi caso y para poder dotar de mas espacio a las etiquetas que mostraremos en nuestro UITableViewController, he decidido crear una celda personalizada, que he denominado ArticuloCell y que como veis unicamente tiene dos labels multilinea.

A continuación os muestro el código correspondiente a dicha celda:

ArticuloCell.h

1
2
3
4
5
6

@interface ArticuloCell : UITableViewCell
 
@property (weak, nonatomic) IBOutlet UILabel *titulo;
@property (weak, nonatomic) IBOutlet UILabel *descripcion;
 
@end

Nuestro listado de artículos

En primer lugar vamos a implementar toda la lógica correspondiente a nuestro ListadoArticulosViewController, que es el primer controlador que mostrará nuestra aplicación en pantalla, y que contiene una UITableView con todos los artículos encontrados en el feed del blog.

Dado que vamos a necesitar utilizar en este controlador nuestro MWFeedParser, debemos importar el framework en la cabecera, y definir nuestro controlador como delegado para el MWFeedParserDelegate:

1
2
3

#import <MWFeedParser/MWFeedParser.h>;
 
@interface ListadoArticulosViewController : UITableViewController

A continuación en nuestro fichero de implementación, debemos definir el parser y una colección que nos permita almacenar los artículos que posteriormente pintaremos en el UITableView.

1
2
3
4
5

@interface ListadoArticulosViewController (){
    MWFeedParser *feedParser;
    NSMutableArray *listadoArticulos;
}
@end

Para empezar, deberemos hacer ciertos trabajos de inicialización en los métodos que corresponden al ciclo de vida de nuestro controlador:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

- (void)viewDidLoad
{
    [super viewDidLoad];
 
    NSURL *feedURL = [NSURL URLWithString:@"http://www.migueldiazrubio.com/feed/"];
    feedParser = [[MWFeedParser alloc] initWithFeedURL:feedURL];
 
    feedParser.delegate = self;
 
    feedParser.feedParseType = ParseTypeFull;
 
    feedParser.connectionType = ConnectionTypeAsynchronously;
 
    listadoArticulos = [[NSMutableArray alloc] init];
 
    UIRefreshControl *refreshControl = [[UIRefreshControl alloc] init];
 
    [refreshControl addTarget:self action:@selector(cargaArticulos) forControlEvents:UIControlEventValueChanged];
    self.refreshControl = refreshControl;    
}
 
- (void)viewWillAppear:(BOOL)animated {
    [super viewWillAppear:animated];    
    [self cargaArticulos];
}
 
- (void)cargaArticulos {
    [feedParser parse];
}

Básicamente estamos inicializando el parser, configurando sus parámetros, y hemos creado un método cargaArticulos que será quien se encargue de invocar a nuestro parser para que comience la consulta del feed y su posterior parseo.

Recordar que para poder definir el refreshControl de nuestro UITableView, debemos indicarselo en el Storyboard en la pestaña Attributes, en el campo Refreshing con el valor Enabled:

Al habernos definido como delegate del protocolo MWFeedParserDelegate, existen un total de 5 métodos, todos ellos opcionales, que podemos implementar en nuestro controlador:

1
2
3
4
5

- (void)feedParserDidStart:(MWFeedParser *)parser;
- (void)feedParser:(MWFeedParser *)parser didParseFeedInfo:(MWFeedInfo *)info;
- (void)feedParser:(MWFeedParser *)parser didParseFeedItem:(MWFeedItem *)item;
- (void)feedParserDidFinish:(MWFeedParser *)parser;
- (void)feedParser:(MWFeedParser *)parser didFailWithError:(NSError *)error;

El método feedParserDidStart se ejecutará cuando invoquemos el método parse del MWFeedParser y por tanto incluiremos la siguiente lógica:

1
2
3
4
5
6
7
8
9
10

- (void)feedParserDidStart:(MWFeedParser *)parser {
    NSLog(@"Comienza el parseo");
 
    // Vaciamos el listado de artículos para evitar que se acumulen
    // en llamadas posteriores
    [listadoArticulos removeAllObjects];
 
    // Ponemos el marcha el refresh control
    [self.refreshControl beginRefreshing];
}

Como veis, comenzamos borrando todos los elementos que pudiera tener nuestro array y posteriormente activamos el icono de refresco de nuestro UIRefreshControl.

A continuación, lo primero que detectará el parser será la información del feed, e invocará al método didParseFeedInfo. Allí incluiremos el siguiente código que nos va a permitir cambiar el title de nuestro controlador, con el nombre del blog que estamos descargando:

1
2
3

- (void)feedParser:(MWFeedParser *)parser didParseFeedInfo:(MWFeedInfo *)info {
    self.title = info.title;
}

El siguiente paso que hará el parser es ir recuperando uno a uno los artículos disponibles en dicho feed, e invocando al método didParseFeedItem. Para ello, iremos guardando en nuestro array los items que vayamos recuperando de la siguiente manera:

1
2
3
4

- (void)feedParser:(MWFeedParser *)parser didParseFeedItem:(MWFeedItem *)item {
    // Añadimos al array el item descargado
    [listadoArticulos addObject:item];
}

Por último, cuando finalice el parseo de todos los artículos disponibles, se invocará el método feedParserDidFinish, donde incluiremos el siguiente código:

1
2
3
4
5
6
7
8
9
10
11

- (void)feedParserDidFinish:(MWFeedParser *)parser {
 
    // Como ya ha finalizado el parse, denemos el parser
    [feedParser stopParsing];
 
    // Detenemos el refresh control
    [self.refreshControl endRefreshing];
 
    // Refrescamos el table view
    [self.tableView reloadData];
}

Como se puede observar, detenemos el parser, detenemos tambien el UIRefreshControl, y actualizamos el UITableView para que muestre la información cargada.

Para que nuestro UITableView pueda mostrar la información de nuestro array, deberemos evidentemente implementar los métodos correspondientes:

1
2
3
4
5
6
7
8
9
10
11
12
13

#pragma mark UITableViewDelegate / UITableViewDataSource
 
-(UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    ArticuloCell *cell = [tableView dequeueReusableCellWithIdentifier:@"ArticuloCell"];
    MWFeedItem *item = [listadoArticulos objectAtIndex:indexPath.row];
    cell.titulo.text = item.title;
    cell.descripcion.text = item.link;
    return cell;
}
 
-(NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
    return listadoArticulos.count;
}

Ya tenemos todo listo en nuestro listado, y podemos pasar a la pantalla de detalle.

Nuestro detalle de un artículo seleccionado

Dado que nuestro pantalla en el Storyboard cuenta con un UIWebView, deberemos indicar en nuestro controlador que nos hacemos cargo como delegados del mismo. Así mismo, deberemos implementar el método shouldStartLoadWithRequest:

1
2
3

- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType {
    return YES;
}

Tambien deberemos contar con un objeto donde poder guardar desde la pantalla anterior el artículo para el cual queremos mostrar el detalle.

Con ello, nuestro fichero de cabecera DetalleViewController.h quedaría así:

1
2
3
4
5
6

#import <MWFeedParser/MWFeedParser.h>;
 
@interface DetalleViewController : UIViewController 
@property (nonatomic, strong) MWFeedItem *item;
@property (weak, nonatomic) IBOutlet UIWebView *webView;
@end

A continuación, implementaremos la logica que queremos que se ejecute cuando se muestre este controlador:

1
2
3
4
5
6
7
8

- (void)viewWillAppear:(BOOL)animated
{
    [super viewWillAppear:animated];
 
    [self.webView setDelegate:self];
    self.title = self.item.title;
    [self.webView loadHTMLString:self.item.content baseURL:nil];
}

Para finalizar, cuando el usuario seleccione una de las celdas de nuestro UITableView queremos que en el controlador del detalle se muestre el contenido del artículo seleccionado. Para ello deberemos implementar el método prepareForSegue en el ListadoArticulosViewController.m para que pase como parametro el artículo seleccionado:

1
2
3
4
5
6

-(void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {
    ArticuloCell *celda = (ArticuloCell *)sender;
    MWFeedItem *item = [listadoArticulos objectAtIndex:[self.tableView indexPathForCell:celda].row];
    DetalleViewController *detalleVC = (DetalleViewController *)segue.destinationViewController;
    [detalleVC setItem:item];
}

Conclusiones

Basta con navegar un poco por internet y por GitHub para encontrar fantásticas librerías como esta, que sin duda van a hacer que nuestras aplicaciones puedan centrarse en los detalles, y olvidarnos de las partes más engorrosas.

Pues nada, espero que os haya gustado el artículo, y recordar que si encontráis alguna librería que os gustaría que analizáramos aquí, hacérmelo saber.

Como siempre, os dejo aqui el enlace para descargar el ejemplo completo por si queréis verlo con más detalle.

The post Desarrollo iOS: Crea tu propio lector RSS con MWFeedParser appeared first on Miguel Diaz Rubio.

En este artículo vamos a hablar sobre los diferentes métodos existentes para recorrer colecciones en Objective-C.

Métodos para recorrer colecciones

Principalmente existen 4 métodos, que quizás podrían verse como la evolución cronológica de una misma problemática: bucle básico, NSEnumerator, NSFastEnumeration, y por último el reciente método mediante bloques. A continuación vamos a ir viendo ejemplos de cada uno de ellos, analizando cuales son las diferentes y qué debemos elegir en cada caso.

Bucle básico (for)

1
2
3
4
5

NSArray *array = ...;
for (NSUInteger i = 0 ; i < [array count]; i++) {
	id objeto = [array objectAtIndex:i];
	// Hacemos lo que queramos con el objeto
}

Este es el mas simple de todos los métodos, y común a muchos lenguajes de programación, estamos ante un método que normalmente no se utilizará en aplicaciones para iOS. No esta mal, pero no es nada eficiente.

NSEnumerator

1
2
3
4
5

NSEnumerator *enumerador = [array objectEnumerator];
id objeto;
while(objeto = [enumerador nextObject]) {
	// Hacemos lo que queramos con el objeto
}

En este caso, estamos empleando un enumerador (Lo que sería en Java un objeto Iterator), que nos permite no tener que analizar previamente y durante el transcurso del recorrido, el tamaño del array o el elemento en que nos encontramos.

Aunque esto supone una clara ventaja de rendimiento, supone así mismo una desventaja en algunos casos, como es no contar con el índice en el que nos encontramos.

NSFastEnumeration

1
2
3

for (id objeto in array) {
	// Hacemos lo que queramos con el objeto
}

En este tercer caso, la enumeración es aún mas rápida que la anterior, y ademas estamos reduciendo considerablemente el tamaño del código. Sin embargo, y aunque efectivamente su rendimiento es superior al anterior, seguimos encontrándonos con el problema del índice.

1
2
3
4

for(id key in diccionario) {
	id objeto = [dictionario objectForKey:key];
        // Hacemos lo que queramos con el objeto
}

Además, en el caso de estar aplicando esto mismo a un NSDictionary, ya sea mediante el método NSEnumerator o bien NSFastEnumeration, en ambos casos estaríamos ante un mismo problema: en la iteración recuperaríamos únicamente el key del diccionario, y sería necesaria una segunda llamada para obtener el objeto asociado a dicho key. Esta segunda llamada echa por tierra la eficiencia aportada por NSFastEnumeration.

Mediante bloques: enumerateObjectsUsingBlock

En este caso, estaríamos haciendo uso de bloques, lo cual obliga al usuario a tener al menos iOS 4 (¿quedará alguien con iOS 3?).

El código quedaría como sigue:

1
2
3

[array enumerateObjectsUsingBlock: ^(id objeto, NSUInteger indice, BOOL *stop) {
        // Hacemos lo que queramos con el objeto
}];

Como se puede ver, en este caso cubrimos mucho de los comentado anteriormente. Tenemos acceso al índice gratuitamente, y ademas contamos con una variable BOOL que nos permite salir de la sentencia de control en cualquier momento, como si de un break se tratase.

1
2
3

[diccionario enumerateKeysAndObjectsUsingBlock: ^(id key, id objeto, BOOL *stop) {
        // Hacemos lo que queramos con el objeto
}];

En el caso de NSDictionary, podemos ver que de nuevo contamos con una gran ventaja, y es la capacidad de recuperar los key y los value del diccionario de forma simultanea y sin código adicional. Esto supone un ahorro considerable.

Resumen final

Pues aunque llegados a este punto del artículo, todos podáis estar pensando que la mejor opción es la última, quizás debe ser algo que valoréis en cada caso. En enumeraciones muy sencillas, el recorrer mediante un bloque, puede tener un rendimiento inferior a NSFastEnumeration, y en casos en que nos encontremos con NSDictionary puede que el mejor camino si sean los bloques.

Quizás los dos primeros métodos si podrían descartarse en el día a día.

Tratar de lograr un código lo más limpio posible, y adaptar las posibilidades que Apple nos ofrece, a cada caso concreto en vuestros desarrollos. Ese creo que puede ser, el mejor consejo.

The post Snippets iOS: Métodos para recorrer colecciones appeared first on Miguel Diaz Rubio.