iPhone, iPad y Android

Last post in this URL

2012-05-19T22:12:00.003+02:00

This is the last post in this blog. You can continue reading my new posts at http://angelolloqui.com/blog where I have already published some interesting articles.

Este es mi último post en este blog. Puedes seguir leyendo mis nuevos posts en http://angelolloqui.com/blog, donde ya he publicado algunos artículos interesantes.

Manteniendo compatibilidad con versiones anteriores de iOS

2011-03-08T10:51:00.005+01:00

Este post se ha movido de forma permanente a http://angelolloqui.com/blog/12-Manteniendo-compatibilidad-con-versiones-anteriores-de-iOS

Es muy habitual encontrarnos con la necesidad de dar soporte a usuarios que no estén actualizados con el último iOS en nuestras aplicaciones iPhone o iPad, pero los SDKs nuevos dan soporte únicamente para un conjunto muy reducido de versiones anteriores, lo que normalmente no es suficiente.

Ante esto, muchos developers no tienen muy claro como conseguirlo, y recurren a soluciones muy poco prácticas (y con varios problemas). La más habitual es tener diferentes SDKs instalados en su máquina, para compilar usando uno u otro dependiendo del iOS al que quieran dar compatibilidad. Esta solución, además de ser poco elegante, ocupar mucho espacio en disco y dar problemas a la hora de subir la app al AppStore, tiene otros dos problemas muy grandes:

La arquitectura de los simuladores cambia cada cierto tiempo. Esto hace que una librería compilada para un simulador en la 4.3 por ejemplo, no pueda ejecutarse en un simulador en la 3.0. Si usamos librerías de terceros (como Flurry por ejemplo) podemos vernos en un problema para conseguir ejecutar nuestra aplicación en un simulador. Seguimos pudiendo ejecutar en dispositivo, pero la falta de simulador puede hacer el desarrollo mucho más lento.
No podemos utilizar funcionalidad agregada en SDKs posteriores. Esto parece de perogrullo, pero si compilamos con un SDK3.0 no podremos hacer uso de cosas como FastApp Switching y similares.

Todo esto tiene una solución mucho más sencilla y elegante, que es utilizando el llamado "Deployment Target".

Pero antes de nada, voy a explicar la diferencia entre algunos conceptos que no siempre están claros y pueden mezclarse:

Versión de iOS: iOS es el sistema operativo que corre en el dispositivo del usuario. Aquí caben muchísimas opciones, y nuestros usuarios estarán en una u otra. Así pues, si nuestra aplicación da soporte para versiones iOS3.0 o posterior, cualquier usuario con una versión iOS3.0 o posterior podrá ejecutar nuestra app. Según la versión de su iOS, el usuario podrá tener unas funcionalidades u otras (por ejemplo, los mapas se introdujeron en la 3.0 o el FastAppSwitch en la 4.0).
Versión de SDK instalada: Este concepto se refiere a la versión del SDK de desarrollo que te descargaste e instalaste en tu máquina. Si te lo has bajado de la página de Apple, será la última versión disponible. (Por ejemplo, ahora mismo estamos en la 4.3)
Base SDK: Establece con que versión de SDK se va a compilar un proyecto. El BaseSDK siempre tiene que ser igual o inferior a tu versión de SDK instalada. Normalmente, un SDK incluye varios Base SDKs anteriores, por si el usuario desea compilar con alguno previo.
Deployment Target: Establece a partir de qué versión de iOS podrá ejecutarse tu aplicación. El deployment target por defecto se establece igual al BaseSDK utilizado, pero puede cambiarse a uno anterior.

Una vez explicados estos conceptos, que en muchos casos parecen iguales o pueden resultar confusos, voy a tratar de explicar como solucionar el problema de dar soporte a usuarios con versiones previas de forma elegante , sin perder la compatibilidad con librerías compiladas para simulador y pudiendo dar a usuarios con versiones avanzadas de iOS una funcionalidad extra de los nuevos SDKs.
El truco está en configurar correctamente el DeploymentTarget. Para ello, basta con ir a las propiedades del proyecto (abre XCode, pincha en la raiz del proyecto con el botón derecho, "Get Info", Pestaña "Build") y busca el campo "iOS Deployment Target". Verás que te da un listado de versiones de iOS mucho más extenso del que tienes en las opciones del BaseSDK. Seleccionas tu deployment target deseado y listo.

La dificultad de esta solución viene cuando tu app usa alguna funcionalidad que se introdujo en alguna versión de SDK posterior a la que has seleccionado en Deployment Target.
Digamos que pretendes usar Notificaciones locales (introducidas en el 4.2), pero quieres dar soporte a usuarios que sigan en la 3.0. En este caso, puedes compilar con un BaseSDK 4.2 y configurar el Deployment Target a la 3.0. Hasta aquí todo bien (el compilador se lo traga y todo parece funcionar bien en simulador y en un dispositivo con iOS 4.2 o posterior). El problema está en que en el momento en que tu app trate de ejecutar el código asociado a las notificaciones locales, la app se cerrará si el iOS del usuario no es el 4.2 o posterior, ya que no será capaz de ejecutar ese código.
¿Cómo nos protegemos? la solución pasa por estar muy atento a qué métodos utilizas que no estuviesen presentes en el SDK 3.0, para comprobar si existen antes de usarlos en tiempo de ejecución. Para ello, en caso de ser una clase, debes comprobar si la clase existe antes de usarla mediante la ejecución de "NSClassFromString", mientras que deberás usar el "respondsToSelector" en caso de tratarse de un método.

Ej. 1 - Comprobación de clases - ¿Dispositivo soporta Local Notifications?

if (NSClassFromString(@"UILocalNotification")!=nil)
{
// Soporta LocalNotifications
}
else
{
// No soporta Local Notifications
}

Ej. 2 - Comprobación de métodos - ¿Dispositivo soporta multitasking:?

if ([[UIDevice currentDevice] respondsToSelector:@selector(isMultitaskingSupported)])
{
// Soporta multitasking
}
else
{
// No soporta multitasking
}

Si el usuario no soporta la funcionalidad, dependerá de tí decidir que hacer (le muestras un mensaje, no haces nada, le das otra alternativa,...), pero por lo menos garantizas que la app se ejecuta correctamente en todos los iOS y que los usuarios con versiones avanzadas podrán disponer de toda la funcionalidad. Y ya de paso, permites compilar para simulador aunque estés usando librerías de terceros y te ahorras los muchos GBs que ocupa cada SDK :)

¿Cómo afectará a los desarrolladores el nuevo dispositivo de Apple?

2011-03-07T12:48:00.001+01:00

Este post se ha movido de forma permanente a http://angelolloqui.com/blog/11--C-mo-afectar-a-los-desarrolladores-el-nuevo-dispositivo-de-Apple-

Hoy me han pedido en el trabajo que escribiese sobre esto. Como ya está hecho el trabajo, aprovecho y dejo por aquí el link al post:

http://www.mobivery.com/blog/general/%C2%BFcomo-afecta-el-ipad2-a-los-desarrolladores-analizamos-el-nuevo-dispositivo-de-apple/

Facebook Like Button on iOS

2010-11-06T18:03:00.012+01:00

This post has been permanently moved to http://angelolloqui.com/blog/10-Facebook-Like-Button-on-iOS

The problem

Some days ago a client asked us for including a Like Facebook button in one of his iPad applications. We have previously used Facebook iOS SDK (https://github.com/facebook/facebook-ios-sdk) for including things like the user's profile photo, friends, and so on so we were pretty sure that this button would be easy to implement.
Upppssss, what an error! Facebook iOS API doesn't include a FB Like button, and the Rest API either. The only way that Facebook seems to give to developers is a HTML button or iframe, both of them thinked for being in a web enviroment. Of course we have the chance to include a webview in the iPad app to include this button, but we should take care of the login process and some other issues, so I did some research and I found this:

http://petersteinberger.com/2010/06/add-facebook-like-button-with-facebook-connect-iphone-sdk/

This web has the solution that I was looking for, but, after including it's code (with a minor change due to a miss method), it didn't work as expected. The FB login dialog opens and then immediatly closes.

The solution
Here are the changes and improvements I have done for resolving it, with the complete code:

First, we have to customize a FBDialog for taking care of the login process:

//FBCustomLoginDialog.h
@interface FBCustomLoginDialog : FBDialog {
}
@end

//FBCustomLoginDialog.m
@implementation FBCustomLoginDialog

- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request
navigationType:(UIWebViewNavigationType)navigationType {
NSURL* url = request.URL;
if ([[url absoluteString] rangeOfString:@"login"].location==NSNotFound) {
[self dialogDidSucceed:url];
return NO;
}else if (url!=nil){
[_spinner startAnimating];
[_spinner setHidden:NO];
return YES;
}
return NO;
}
@end

As you may see, I changed the method "containsString" by "rangeOfString" because the first doesn't exists on iOS SDK. Another minor change I made is that I included a few sentences for start the spinner animation after the user submits the login form, and I had to put and extra "if" because sometimes the URL is null and it can't be loaded.

OK, so now we have a customized login view, but we need to make the button view for the "I like" UI. In order to build this view, my first option was to inherit my view directly from UIWebView, but after a while I decided to use a UIView over it because it gives me the chance to disable the webview scroll (the webpage generated for the FB Like button usually is heigher that the view itself, resulting in an awful scroll).
I also made some additions for customizing a little the colors showed in the webview, but I found a problem because the CSS of the page are loaded asynchronously with AJAX, so I can't know the exact moment in which I have to inject my javascript that changes the colors. This may be improved overriden the AJAX onreadystate to do it at the exact moment, but I didn't have so much time to investigate on this to only change a color, so I finally took the easy way, injecting the javascript a while after the page loads (3 secs in the code below). If you find a better solution for this I would appreciate if you post your code :)

Anyway, this is my final code:

//FBLikeButton.h
#define FB_LIKE_BUTTON_LOGIN_NOTIFICATION @"FBLikeLoginNotification"

typedef enum {
FBLikeButtonStyleStandard,
FBLikeButtonStyleButtonCount,
FBLikeButtonStyleBoxCount
} FBLikeButtonStyle;

typedef enum {
FBLikeButtonColorLight,
FBLikeButtonColorDark
} FBLikeButtonColor;

@interface FBLikeButton : UIView {

UIWebView *webView_;

UIColor *textColor_;
UIColor *linkColor_;
UIColor *buttonColor_;
}

@property(retain) UIColor *textColor;
@property(retain) UIColor *linkColor;
@property(retain) UIColor *buttonColor;

- (id)initWithFrame:(CGRect)frame andUrl:(NSString *)likePage andStyle:(FBLikeButtonStyle)style andColor:(FBLikeButtonColor)color;
- (id)initWithFrame:(CGRect)frame andUrl:(NSString *)likePage;

@end

//FBLikeButton.m
//LoginDialog es estatica para abrir unicamente un login en toda la app
static FBDialog *loginDialog_;

@implementation FBLikeButton

@synthesize textColor=textColor_, buttonColor=buttonColor_, linkColor=linkColor_;

- (id)initWithFrame:(CGRect)frame andUrl:(NSString *)likePage andStyle:(FBLikeButtonStyle)style andColor:(FBLikeButtonColor)color{
if ((self = [super initWithFrame:frame])) {
NSString *styleQuery=(style==FBLikeButtonStyleButtonCount? @"button_count" : (style==FBLikeButtonStyleBoxCount? @"box_count" : @"standard"));
NSString *colorQuery=(color==FBLikeButtonColorDark? @"dark" : @"light");

NSString *url =[NSString stringWithFormat:@"http://www.facebook.com/plugins/like.php?layout=%@&show_faces=true&width=%d&height=%d&action=like&colorscheme=%@&href=%@",
styleQuery, (int) frame.size.width, (int) frame.size.height, colorQuery, likePage];

//Creamos una webview muy alta para evitar el scroll interno por la foto del usuario y otras cosas
webView_ = [[UIWebView alloc] initWithFrame:CGRectMake(0, 0, frame.size.width, 300)];
[self addSubview:webView_];
[webView_ loadRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:url]]];
webView_.opaque = NO;
webView_.backgroundColor = [UIColor clearColor];
webView_.delegate = self;
webView_.autoresizingMask = UIViewAutoresizingFlexibleWidth;
[[webView_ scrollView] setBounces:NO];
self.backgroundColor=[UIColor clearColor];
self.clipsToBounds=YES;

[[NSNotificationCenter defaultCenter] addObserver:webView_ selector:@selector(reload) name:FB_LIKE_BUTTON_LOGIN_NOTIFICATION object:nil];

}
return self;
}

- (id)initWithFrame:(CGRect)frame andUrl:(NSString *)likePage{
return [self initWithFrame:frame andUrl:likePage andStyle:FBLikeButtonStyleStandard andColor:FBLikeButtonColorLight];
}

- (void)dealloc {

[[NSNotificationCenter defaultCenter] removeObserver:webView_ name:FB_LIKE_BUTTON_LOGIN_NOTIFICATION object:nil];

[webView_ stopLoading];
webView_.delegate=nil;
[webView_ removeFromSuperview];
[webView_ release]; webView_=nil;

self.linkColor=nil;
self.textColor=nil;
self.buttonColor=nil;

[super dealloc];
}

- (void) configureTextColors{
NSString *textColor=[textColor_ hexStringFromColor];
NSString *buttonColor=[buttonColor_ hexStringFromColor];
NSString *linkColor=[linkColor_ hexStringFromColor];

NSString *javascriptLinks = [NSString stringWithFormat:@"{"
"var textlinks=document.getElementsByTagName('a');"
"for(l in textlinks) { textlinks[l].style.color='#%@';}"
"}", linkColor];

NSString *javascriptSpans = [NSString stringWithFormat:@"{"
"var spans=document.getElementsByTagName('span');"
"for(s in spans) { if (spans[s].className!='liketext') { spans[s].style.color='#%@'; } else {spans[s].style.color='#%@';}}"
"}", textColor, (buttonColor==nil? textColor : buttonColor)];

//Lanzamos el javascript inmediatamente
if (linkColor)
[webView_ stringByEvaluatingJavaScriptFromString:javascriptLinks];
if (textColor)
[webView_ stringByEvaluatingJavaScriptFromString:javascriptSpans];

//Programamos la ejecucion para cuando termine
if (linkColor)
[webView_ stringByEvaluatingJavaScriptFromString:[NSString stringWithFormat:@"setTimeout(function () %@, 3000)", javascriptLinks]];
if (textColor)
[webView_ stringByEvaluatingJavaScriptFromString:[NSString stringWithFormat:@"setTimeout(function () %@, 3000)", javascriptSpans]];

}

///////////////////////////////////////////////////////////////////////////////////////////////////
#pragma mark -
#pragma mark UIWebViewDelegate

- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType {

if (loginDialog_!=nil)
return NO;

// if user has to log in, open a new (modal) window
if ([[[request URL] absoluteString] rangeOfString:@"login.php"].location!=NSNotFound){
loginDialog_= [[[FBCustomLoginDialog alloc] init] autorelease];
[loginDialog_ loadURL:[[request URL] absoluteString] get:nil];
loginDialog_.delegate = self;
[loginDialog_ show];
[loginDialog_.delegate retain]; //Retenemos el boton que ha abierto el login para que pueda recibir la confirmacion correctamente
return NO;
}
if (([[[request URL] absoluteString] rangeOfString:@"/connect/"].location!=NSNotFound) || ([[[request URL] absoluteString] rangeOfString:@"like.php"].location!=NSNotFound)){
return YES;
}

NSLog(@"URL de Facebook no contemplada: %@", [[request URL] absoluteString]);

return NO;
}

- (void)webViewDidFinishLoad:(UIWebView *)webView{

[self configureTextColors];
}

///////////////////////////////////////////////////////////////////////////////////////////////////
#pragma mark -
#pragma mark Facebook Connect

- (void)dialogDidSucceed:(FBDialog*)dialog {
[loginDialog_.delegate release];
loginDialog_.delegate=nil;
loginDialog_=nil;

//Lanzamos la notificacion para que se actualicen los botones
[[NSNotificationCenter defaultCenter] postNotificationName:FB_LIKE_BUTTON_LOGIN_NOTIFICATION object:nil];
}

/**
* Called when the dialog succeeds and is about to be dismissed.
*/
- (void)dialogDidComplete:(FBDialog *)dialog{
[self dialogDidSucceed:dialog];
}

/**
* Called when the dialog succeeds with a returning url.
*/
- (void)dialogCompleteWithUrl:(NSURL *)url{
[self dialogDidSucceed:loginDialog_];
}

/**
* Called when the dialog get canceled by the user.
*/
- (void)dialogDidNotCompleteWithUrl:(NSURL *)url{
[self dialogDidSucceed:loginDialog_];
}

/**
* Called when the dialog is cancelled and is about to be dismissed.
*/
- (void)dialogDidNotComplete:(FBDialog *)dialog{
[self dialogDidSucceed:loginDialog_];
}

/**
* Called when dialog failed to load due to an error.
*/
- (void)dialog:(FBDialog*)dialog didFailWithError:(NSError *)error{
[self dialogDidSucceed:loginDialog_];
}

@end

You may notice that I added a lot of code and methods to the original example. Almost all of them are for customizing the UI and make a proper use of our customized login dialog (the FBDialogDelegate methods).
The only important changes are the use of the NSNotificationCenter for sending notifications when the dialog success (and so every existing Like button could refresh with the new credentials) and the static reference to the FBCustomDialog to avoid multiple login popups at the same time.

The UIColor extensions used on the code above can be found here:
http://arstechnica.com/apple/guides/2009/02/iphone-development-accessing-uicolor-components.ars

Finally, you would see a method that doesn't exists on a standard UIWebView:

[[webView_ scrollView] setBounces:NO];

this method is a little hack I use sometimes to disable the scroll or bounces of the webview, but it may fail on future iOS versions. Anyway, if you still want to use it, this is what it does (I have it in a UIWebView category)

- (UIScrollView *) scrollView{
NSArray *subviews = [self subviews];
for (UIView *view in subviews){
if ([view isKindOfClass:[UIScrollView class]])
return (UIScrollView *) view;
}
return nil;
}

And thats all! with these 2 classes you are able to include your FB Like buttons in your views in an easy way, just with something like the following:

FBLikeButton *likeButton = [[FBLikeButton alloc] initWithFrame:frame andUrl:@"www.mylikeurl.com"];
[view addSubview:likeButton];
[likeButton release];

or even with customized colors:

FBLikeButton *likeButton = [[FBLikeButton alloc] initWithFrame:frame andUrl:@"www.mylikeurl.com"];
[likeButton setTextColor:COLOR_DARK_GRAY];
[likeButton setLinkColor:COLOR_CLEAR_GRAY];
[view addSubview:likeButton];
[likeButton release];

I hope it helps you all!

Known issues

Login Dialog has a double title bar, the FBDialog title and the FB webpage title. I don't think there is an easy solution for this, but I consider it as a minor issue.
FBCustomLoginDialog and FBLoginDialog uses different login methods, so the user have to make login twice if you use the FB iOS SDK for other staff. I don't think there is a workaround for this issue.
UI colors may change a little time after the button loads, as commented before, and it may stop working on the future if FB changes it's webpage structure.
There is no easy way for customizing layout or even alignment of the elements.
UIWebview have a little render delay as it loads remote content.

Las ventajas de nil en Objective-C

2010-07-16T01:01:00.003+02:00

Este post se ha movido de forma permanente a http://angelolloqui.com/blog/9-Las-ventajas-de-nil-en-Objective-C

Para los que venimos de lenguajes como Java o C++ donde un objeto null es un peligro, cuando llegamos a Objective-C descubrimos la gran ventaja que tenemos en este lenguaje.

En objective-C, un puntero apuntando a nil es un objeto sobre el que se pueden invocar métodos.

Es decir, cualquiera de las siguientes líneas son perfectamente válidas:

id objeto=nil;
[objeto metodo];
[nil metodo];

Quizá te preguntes que pasa si se ejecuta un método sobre nil? pues nada, cualquier ejecución sobre nil simplemente devuelve a su vez un nil. Por ejemplo, en este código:

id objeto1= [nil metodo];
id objeto2 = [objeto1 metodo];

En ambos casos, objeto1 y objeto2 serán nil a su vez, pero ningún error habrá ocurrido (en vez de los "Null pointer exception" que tendríamos en Java).

Quizá pienses que esto tampoco aporta nada, ya que simplemente con hacer una comprobación de si objeto1 es nil antes de invocar nada sobre él sería suficiente, pero lo cierto es que se convierte en algo muy práctico, cómodo y sobre todo robusto frente a errores. No significa que nunca tengas que comprobar si algo es nil, ya que es probable que en muchos casos tengas que hacer una ejecución diferente en un caso o en el otro, pero sí ahorra muchas comprobaciones innecesarias y por tanto código, además de reducir los errores por un "descuido de comprobación de null".

Un ejemplo muy claro de este buen uso es en las properties y en los deallocs. Por ejemplo, un dealloc típico podría ser algo como:

- (void)dealloc {
[titleLabel_ release]; titleLabel_=nil;
[subtitleLabel_ release]; subtitleLabel_=nil;
[introLabel_ release]; introLabel_=nil;
[authorLabel_ release]; authorLabel_=nil;
[dateLabel_ release]; dateLabel_=nil;
[commentsLabel_ release]; commentsLabel_=nil;
[textLabels_ release]; textLabels_=nil;
[contentScroll_ release]; contentScroll_=nil;
[multimediaView_ release]; multimediaView_=nil;
[remoteImageView_ release]; remoteImageView_=nil;
[multimediaFooterLabel_ release]; multimediaFooterLabel_=nil;
[twitterAlertViewController_ release]; twitterAlertViewController_=nil;
[bannerView_ release]; bannerView_=nil;

[super dealloc];
}

Imaginate la cantidad de líneas extras que llevaría el dealloc anterior si tenemos que comprobar cada variable antes de liberarla para evitar provocar un "null pointer exception" sobre variables que no estén creadas!
Por cierto, puedes ver que después de cada release hago una igualación a nil. Esto no es obligatorio pero sí es una muy buena práctica porque si este release se hace en otro punto es bueno que el puntero lo apuntemos a nil para que no de errores en un hipotético uso posterior.

Consideraciones

A pesar de que la ejecución de métodos sobre nil sea correcta, no significa que lo sea por fuerza en los parámetros de un método. Por ejemplo, en un array no podemos agregar un nil como objeto ya que lanza un error:

[array addObject:nil]; // Error

Por esto, aunque podemos relajarnos con las comprobaciones a nil al invocar métodos, hay que tener cuidado cuando se usa como parámetro de un método de otro objeto. El nil es mucho mejor que el null de Java, pero no perfecto ;)

Gestión de memoria en iPhone SDK

2010-07-07T00:34:00.005+02:00

Este post se ha movido de forma permanente a http://angelolloqui.com/blog/8-Gesti-n-de-memoria-en-iPhone-SDK

El desarrollo de aplicaciones para iPhone o iPad, a diferencia de Android y otras plataformas, tiene un tema bastante espinoso y que a la gente le suele parecer complicado al principio: la gestión de memoria. Debido a que la aplicación es compilada a código nativo, sin máquinas virtuales de por medio, no contamos con un recolector de basura que nos haga la limpieza de memoria de las variables en desuso. En esta entrada trataré de exponer las convenciones y consideraciones que debes tener en cuenta al enfrentarte a este tipo de desarrollos.

Como decía anteriormente, lo más importante es saber que aunque en Objective-C puede existir un recolector de basura cuando programamos para MacOs, no existe en iPhone o iPad, por lo que toda la gestión es manual. ¿Qué significa manual? pues que toda memoria que quieras utilizar tienes que crearla (normalmente mediante alloc), retenerla si es necesario (lo veremos después), y liberarla cuando dejes de necesitarla (con release). Esta forma de trabajar es chocante si vienes de lenguajes donde no sea necesario, tales como los interpretados (Java, .Net,...) o los de scripting (ruby, php,...).

Si no hacemos la gestión de memoria de forma correcta pueden ocurrir dos cosas:

1.- Se queda memoria sin liberar: el iPhone emepezará a quedarse sin memoria con cada uso de la aplicación, y será necesario reiniciar el dispositivo pasados unos cuantos usos según la cantidad de memoria dejada. A este tipo de lagunas de memoria los llamamos "leaks".
2.- Se libera la memoria antes de tiempo: cuando el código trate de acceder a un área de memoria que ya ha sido liberada, la aplicación lanzará una excepción y se cerrará.

Como veis, ambas cosas con muy preocupantes y hay que evitarlas por todos los medios.

Para facilitarnos la vida, Apple nos ha aportado un mecanismo de "reference counting" en el objeto NSObject y ha creado dos convenciones que deberás seguir si quieres hacer esta gestión de memoria de forma correcta, y que te ayudarán a determinar qué clase debe hacer que retain/release y en que momento.

Pero expliquemos por partes:

Reference counting.

El reference counting es un mecanismo por el cuál los objetos llevan algo parecido a un contador de punteros que le apuntan. De esta forma, si un objeto está apuntado por varios otros, no podemos liberarlo hasta que deje de ser apuntado por el resto. La diferencia con otros entornos con Garbage Collector es que en Objective-C este conteo se realiza de forma manual, realizándose más o menos de esta forma:
R.1.- Cuando reservamos un objeto mediante su método "alloc" o "copy", el nuevo objeto (llamémosle MiObjeto) pasa a tener un contador de +1.
R.2.- A partir de este momento, cuando otro objeto apunta a MiObjeto debe indicarselo mediante la invocación del método "retain". El método "retain" sumará un +1 al contador de referencias de MiObjeto.
R.3.- Cuando otro objeto deja de apuntar a MiObjeto, se invoca el método "release". El método "release" decrementará en 1 el contador de referencias. Si MiObjeto pasa a tener un contador de 0 se invoca el método "dealloc", que es donde se realiza la liberación.

Como podeis ver, de esta forma no invocamos directamente los métodos de liberación de memoria (dealloc), sino que lo que hacemos es invocar siempre el método "release" para permitir que, si otros objetos tienen retenido el que queremos liberar, se destruya la memoria y se produzca el fallo 2.- del primer párrafo. Esta liberación ocurrirá cuando los otros objetos realicen a su vez el release de MiObjeto (ojo, como queda claro, cada retain y alloc debe ejecutar en algún momento un release, dado que de otra forma tendremos un leak como se indica en 1.-)

Ejemplo de reference counting:

for (int i=0; i<1000;i++){
//Creamos memoria
id objeto =[ [ClaseCreadora alloc] init];
//Pasamos el objeto a otra clase
[ClaseB nuevoObjeto:objeto];
//Liberamos la memoria
[objeto release];
}

En este ejemplo vemos cómo se ha hecho un release por cada alloc, y se puede suponer que ClaseB estará haciendo un retain sobre objeto si lo necesita utilizar más tarde.

Convención ownership

El reference counting nos ayuda a evitar gran cantidad de problemas surgidos al compartir memoria entre diferentes clases y objetos, pero plantea problemas a la hora de decidir dónde y quién debe hacer los releases. Por ejemplo, sin un método tiene que devolver un objeto nuevo, y no guarda ningún puntero al mismo, ¿cómo libera la memoria de este nuevo objeto? como no guarda el puntero no puede hacer el release más tarde, tampoco lo puede ejecutar inmediatamente porque si lo hace se liberará la memoria en este mismo momento y producirá el fallo 2.- al intentar usarla, y tampoco es buena idea devolverlo sin el release porque en ese caso se producirá un leak si la otra clase no lo libera. Aquí entra en juego la convención Ownership.

Según esta convención, todo objeto es responsable de liberar la memoria que crea o retiene, pero aporta un par de reglas extras para solucionar el problema anterior:

O.1.- Cuando un objeto va a utilizar memoria creada por otro método debe hacer un retain para evitar su liberación prematura.
O.2.- Todo objeto debe liberar la memoria creada (mediante métodos alloc, copy o new) y retenida (mediante método retain), invocando el método release en algún momento en su ciclo de vida. Por cada alloc/retain ejecutado debe hacerse un release.
O.3.- Si un método devuelve un objeto que no va a liberar, el método deberá llamarse allocXXX, copyXXX o newXXX (donde XXX se sustituye por el nombre que elijas). De esta forma, el que invoca el método puede conocer esta característica y, aplicando la regla O.2.- podrá liberarla. Esta misma regla podría aplicarse N veces si cada método devuelve a su vez el objeto nuevo a su padre.

Ejemplo convención Ownership:

- (Clase *) newObjectWithData:(NSData *)data{
//Creamos el objeto
Clase *object = [[Clase alloc] init];
//Ejecutamos lo que sea
[object setData:data];
//Devolvemos el objeto
return object;
}En este ejemplo podemos hacer la devolución gracias a haber nombrado al método newXXX, que indicará al que lo invoque que el objeto de tipo Clase * devuelto está sin liberar.

Autorelease

Por último, tenemos un último recurso que nos ayudará a gestionar la memoria. Lo he dejado al final porque es el poco óptimo y propenso a erores, por lo que deberías tratar de evitarlo donde sea posible. Se trata del método autorelease, que nos permite indicar que una variable debe ejecutar un release pero más tarde. ¿Cuándo? pues no lo sabes a ciencia cierta porque dependerá de la pila de llamadas, pero el autorelease funciona así:

A.1.- Un método ejecuta un autorelease sobre un objeto (MiObjeto) que tenía retenido (retain) o que había creado previamente (alloc/copy).
A.2.- El método autorelease busca la NSAutoreleasePool en la pila de llamadas más cercana y programa la ejecución del release sobre este objeto
A.3.- La ejecución de la pila de llamadas termina, se ejecuta el NSAutoreleasePool release y se realizan todos los releases programados (se realiza el release sobre MiObjeto).

Así, durante todo el espacio entre A.1 y A.3 la variable seguirá retenida, pero no se tratará de un leak aunque se pierda el puntero ya que este release está programado en la AutoreleasePool. El espacio entre A.1 y A.3 normalmente será la pila de llamdas del sistema (por ejemplo, si se pulsa un botón en el interfaz gráfico se crea una pila y se destruye cuando se termina de procesar el evento de pulsación), pero pueden crearse pilas dentro de otras para hacer las liberaciones de una forma más frecuente.

Ejemplo devolución con autorelease:

- (Clase *) objectWithData:(NSData *)data{
//Creamos el objeto
Clase *object = [[Clase alloc] init];
//Ejecutamos lo que sea
[object setData:data];
//Devolvemos el objeto
return [object autorelease];
}
En este ejemplo a diferencia del utilizado en el patrón ownership vemos que hemos ejecutado un autorelease sobre el objet, por lo que el método no deberá llamarse newXXX porque el padre no tiene que preocuparse de la gestión de memoria de dicho object (el release no se ha ejecutado todavía pero lo hará más tarde).

Ejemplo de uso de NSAutoreleasePool:

//Creamos una nueva pool
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] ini];
for (int i=0; i<1000;i++){
//Creamos memoria
id objeto =[ [ClaseCreadora alloc] init];
//Pasamos el objeto a otra clase
[ClaseB nuevoObjeto:objeto];
//Programamos el autorelease para hacerlo más tarde
[objeto autorelease];
}
//Liberamos toda la memoria con autorelease desde la creación de la pool
[pool release];

Resumen

La gestión de memoria es una tarea que al principio parece compleja, pero una vez comprendidas las normas y el funcionamiento acaba siendo un tema bastante más sencillo de lo que es en otros lenguajes sin reference counting o patrones ownership. Al final, normalmente se resumen en:

a. Toda memoria creada en tu clase con métodos alloc, copy o new debe llevar un release o autorelease en su ciclo de vida

b. Toda memoria que uses creada por otra clase deberías protegerla con retain y liberarla cuando no sea necesaria (idem a punto a.)

c. Si un método devuelve memoria sin liberar debe llamarse newXXX, allocXXX o copyXXX

d. Puedes ejecutar autorelease si necesitas posponer la ejecución de un release, pero no puedes saber el instante exacto en el que se realizará a priori (por ello, debes seguir b. si se usa esa memoria también a posteriori desde otro punto)

e. Los métodos y clases de Apple cumplen los apartados anteriores.

Liberación de memoria en IBOutlets

2010-07-06T23:50:00.000+02:00

Este post se ha movido de forma permanente a http://angelolloqui.com/blog/7-Liberaci-n-de-memoria-en-IBOutlets

Hoy voy me he encontrado con un problema en el trabajo relacionado con la liberación de memoria y la convención Ownership. Bajo esta convención, las clases solo son responsables de liberar aquella memoria que reservan directamente (mediante alloc, retain o copy), pero resulta que no siempre es así.

El problema surge cuando nos enfrentamos a un proyecto iPhone/iPad donde tenemos parte del código creado de forma gráfica mediante Interface Builder. Al usar IB las variables se enlazan con el código mediante el etiquetado de las mismas con la palabra clave IBOutlet sin necesidad de reservar memoria.

Es decir, si tenemos un UILabel que querecemos enlazar desde IB, lo que hacemos es declararla de forma:

IBOutlet UILabel *label;

y desde Interface Builder conectarla con nuestro label creado gráficamente.

Hasta aquí todo OK, el problema aparece cuando te enfrentas a la liberación de memoria. Bajo el patrón ownership, como no hemos hecho nosotros la reserva de memoria, no deberíamos hacer nosotros su liberación, ya que de hacerlo podemos estar decrementando en exceso su retain count y acabar liberando antes de tiempo este objeto (con el consiguiente BAD ACCESS). Pues bien, parece que con estas variables IBOutlet el patrón Ownership no se cumple, porque es el desarrollador el responsable de su liberación en el dealloc, y opcionalmente en el viewDidUnload.

Podeis ver la documentación oficial aquí:
http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmNibObjects.html

En resumen, las variables declaradas IBOutlet deben ser liberadas explícitamente por el desarrollador, y además Apple recomienda usar una property tipo retain en su declaración y liberarlas también en el viewDidUnload para mejorar la gestión de memoria en situaciones de Memory Warning.

Recursos de desarrollo para iPhone

2010-07-02T01:28:00.000+02:00

Este post se ha movido de forma permanente a http://angelolloqui.com/blog/6-Recursos-de-desarrollo-para-iPhone

Voy a utilizar este post para hacer un recopilatorio de aquellos cursos que sean de interés en el desarrollo para iPhone y iPad. Si teneis buenos enlaces, publicadlos en los comentarios para agregarlos a este listado:

Links útiles

Portal de desarrollo de iPhone: Principal sitio de referencia y punto de partida para gestionar y desarrollar tus aplicaciones. Mételo en favoritos.

Objective-C

Introducción a Objective-C oficial: Introducción al lenguaje Objective-C oficial por Apple. Muy buen recurso, imprescindible su lectura antes de lanzarse a desarrollar. Cuidado porque este curso es general de Objective-C, por lo que trata algunos aspectos como el recolector de basura de los que no disponemos en iPhone.

Wikipedia: Objective-C: Breve introducción a Objective-C en la Wikipedia. No tiene mucho valor pero sirve para tener una primera visión del lenguaje.

Objective-C para programadores Java: Tutorial muy bien montado donde se explican las diferencias entre Java y Objective-C. Altamente recomendado si eres un programador con experiencia en Java.

Cursos y Tutoriales

Introducción a iPhone por la Universidad de Standford: Muy buen curso de introducción. Empieza con conceptos básicos y acaba con temas muy avanzados como OpenGLEs. Altamente recomendable

Introducción a iPhone por el MIT: Buen curso de introducción. Lo renuevan a menudo por lo que es un buen recurso para introducirse, pero no lleva tanta profundidad como el anterior.

Otros

Human Interfaces Guidelines: Recurso de imprescindible lectura si pretendes dedicarte de forma profesional al desarrollo para iPhone. En él se explican los componentes que existen, las normas que deben seguirse en su utilización y aspectos de usabilidad y navegabilidad que deben tener tus aplicaciones.

Desarrollar para iPhone/iPad: ¿Qué necesito y por dónde empiezo?

2010-07-02T01:25:00.000+02:00

Este post se ha movido de forma permanente a http://angelolloqui.com/blog/5-Desarrollar-para-iPhone-iPad-Qu-necesito-y-por-d-nde-empiezo-

Voy a empezar a escribir en este blog sobre iPhone/iPad, y como no puede ser de otra forma, empezaré por el principio: ¿Qué necesito y por dónde empiezo a programar para iPhone/iPad?

Vamos allá, pero aviso que no entraré en ningún detalle técnico todavía.

Requisitos previos

1.- Lo primero es hacerte con un Mac. Existen emuladores con los que podríais llegar a probar el entorno y hacer pequeños pinitos, pero el SDK de iPhone consume bastantes recursos, por lo que es imprescindible que os hagais con un MacOSX. Por cierto, a día de hoy sólo hay soporte para SnowLeopard, por lo que aseguraos que además vuestro Mac está actualizado.
2.- Crearte una cuenta en en Apple Developer Portal (http://developer.apple.com/iphone). Existen diferentes tipos de cuentas, desde las gratuitas hasta las de pago. Con las gratuitas podrás probar el SDK, pero no podrás subir aplicaciones al AppStore. Mi consejo es que desde el primer momento te des de alta como un desarrollador de pago, ya que el proceso de alta puede tardar algunos días y este tipo de cuentas te dan acceso a todo el material por unos 70€ al año.
3.- Descargarte el SDK de desarrollo de iPhone de http://developer.apple.com/iphone/. Bájate la versión más actual. En el momento de redactar este post era la 4.0, pero posiblemente las haya más actuales cuando lo leas. Independientemente de la versión, bája e instala el SDK en tu equipo. Ten paciencia porque son más de 2GB. Este SDK incluye, entre alguna otra, 4 grandes herramientas: XCode, Interface Builder, Simulator e Instruments. Ten en cuenta que el SDK de desarrollo para iPhone y iPad es el mismo, por lo que a partir de ahora hablaré de iPhone para referirme a ambos.

Con esto ya estarías listo para empezar a probar el SDK con los primeros ejemplos y tutoriales en un simulador. No obstante, si tu intención es probar la aplicación en un dispositivo, es imprescindible que te des de alta en el Provisioning Portal y añadas tu dispositivo a un provisioning profile válido. En las siguientes líneas te explico como hacerlo (sáltatelas si no te intersa probar sobre dispositivos reales):

4.- Logueate en el Developer Portal y accede a iPhone Provisioning Portal.
5.- Crear un certificado (de development): Entra en Certificates y sigue los pasos para crear un certificado nuevo. A grandes rasgos, lo que hay que hacer aquí simplemente es crear un nuevo certificado con el Keychain (Acceso a Llaveros en español) y subirlo y validarlo en el portal. Te aconsejo además que entres en tu Keychain y exportes la clave privada del certificado en un p12 y la guardes en un lugar seguro, porque si un día necesitas utilizar el certificado en otro equipo te hará falta.
6.- Dar de alta tus dispositivos: Entra en la sección devices y añade nuevos dispositivos con el UDID. Este UDID lo puedes obtener utilizando el iTunes o mediante el Organizer (incluido en el Xcode, dentro de herramientas). Si utilizas el iTunes, conecta tu dispositivo (no es necesario sincronizar) y accede a él desde el menu lateral izquierdo. En la pestaña de resumen verás el UDID (puede aparecer "Número de serie" en su lugar, si es así simplemente pincha sobre él para que cambie y te muestre el UDID). Cópialo (comando+c funciona, no lo hagas a mano!) y agrégalo en el portal junto con un nombre asociado.
Cuidado porque el portal limita a 100 el número de dispositivos que se pueden dar de alta, y NO se pueden borrar, así que mucho cuidado con utilizarlo indiscriminadamente porque pueden no ser tantos.
7.- Crear un appID: Un AppId no es una aplicación en sí misma, sino un identificador para una o más aplicaciones. Se utiliza para discriminar entre provisioning profiles y son fundamentales tenerlos bien configurados para temas más avanzados como APNS o InAppPurchase. De momento, con un AppId genérico será suficiente. Para crearlo, simplemente asignale un nombre ("all apps" por ejemplo) y pon como bundle identifier un *. El * es un comodin que nos permitirá referirnos a cualquier aplicación usando este AppId.
8.- Crear un provisioning profile (de development): Entra en provisioning y crea uno nuevo. Te pedirá asignarle un nombre, seleccionar un AppId y una lista de dispositivos. Mi consejo para el nombre es que independientemente de cuál elijas lleve la palabra "Development" y algo que te permita reconocer que es el provisioning genérico para todas las apps, ya que es posible que te juntes con muchos provisioning en el futuro si vas subir la aplicación al AppStore, tienes diferentes cuentas o utilizas temas avanzados como comentaba anteriormente. Por ejemplo, un buen nombre podría ser algo como "AngelAllAppsDevelopmentProfile". Con esto hecho, solo te falta descargar el profile que acabas de crear y instalarlo (basta con hacer doble click sobre él, o moverlo a la carpeta $user/Library/MobileDevice/Provisioning Profiles)

Antes de terminar con esta parte de los certificados, voy a explicar brevemente para que se usan:
Los provisioning profiles son archivos utilizados para firmar las aplicaciones en el momento de compilarlas. Los profiles de development te permiten compilar para ser instalados de forma directa en los dispositivos configurados (ver pasos anteriores), pero tienen una caducidad de 3 meses y no pueden tener más de 100 dispositivos dados de alta. Además, es necesario que el dispositvo tenga instalado el certificado para poder instalar la aplicación, pero como veremos si usamos las herramientas de desarrollo esto será automático. Si lo que pretendes es mandar la aplicación a una tercera persona, asegurate de que te ha dado su UDID, está dado de alta en el profile que corresponda y lo tiene instalado en su dispositivo antes de intentar instalar la aplicación. Para instalar el certificado en el dispositivo, al igual que una aplicación, puede hacerse también arrastrándolo a la biblioteca de su iTunes y sincronizando el dispositivo (cuidado porque en Windows no funciona bien, así que mejor si puede hacerlo en un Mac).

Vistazo de las herramientas del SDK

Tras la instalación del SDK tendrás 4 programas que utilizarás continuamente en tus desarrollos. Vamos a mencionarlos brevemente para que sepas para que se utilizan:

- XCode: Este es el IDE de desarrollo, por lo que es la principal herramienta que utilizarás para programar. El XCode tiene muchas herramientas, atajos de teclados y truquitos, pero los irás aprendiendo con la práctica (posiblemente en el futuro haga un post sobre esto, pero ahora es demasiado). Lo principal de esta herramienta es que entiendas que a la izquierda tienes el árbol lógico de ficheros (digo lógico porque lo que organices en este árbol no se cambiará en el sistema de ficheros, sólo aquí dentro de XCode, así que cuidado con el desorden), y a la derecha la zona de escritura. Un elemento importante de esta herramienta es el selector que aparece arriba a la izquierda (entre el menú de la aplicación y el árbol de ficheros), con la que podrás elegir si quieres desplegar en un simulador o un dispositivo, así como la configuración (debug o release). Ambas configuraciones te sirven igual, únicamente es recomendable que uses el modo debug para hacer pruebas durante el desarrollo puesto que llevan más información de trazas. Volveremos a esto cuando hagamos un HelloWorld.
- Interface Builder: Esta herramienta es el IDE gráfico. Te servirá para crear vistas de forma sencilla, arrastrando componentes desde una paleta de componentes sobre un lienzo, editar sus propiedades principales (color, tamaño, posición, opacidad, ...) y enazarlos con el código.
- iPhone Simulator: Es un simulador de iPhone. Se arranca cuando configuras la aplicación para ejecutar sobre un simulador. A casi todos los efectos funciona igual que un dispositivo, pero es importante saber que este simulador no tiene límites de memoria y tiene una capacidad de CPU sensiblemente superior a los dispositivos reales. Por ello, no podemos estar seguros de que una aplicación funciona correctamente hasta probarla en un dispositivo auténtico. La gran ventaja es que se arranca e instalan aplicaciones más rápido que en un dispositivo real por lo que es muy útil para el día a día.
- Instruments: Esta herramienta la usareis menos, pero nos permitirá revisar la aplicación en busca de leaks de memoria o consumo de CPU. No entraré en más detalle puesto que es un tema más avanzado.

De aquí en adelante
Y de momento esto es todo lo que considero importante para un post de introducción. No quiero extenderme más por ahora, pero el próximo día haré un pequeño HelloWorld donde explicaré en mayor profundidad las herramientas y en el futuro me meteré con temas más técnicos de Objective-C (el lenguaje de programación utilizado), arquitectura de Cocoa Touch (el framework sobre el que programamos), APIs, etc.

Servidores en Amazon con EC2 y EBS

2010-06-19T17:33:00.000+02:00

Este post se ha movido de forma permanente a http://angelolloqui.com/blog/4-Servidores-en-Amazon-con-EC2-y-EBS

Llevo ya más de un año pegándome con Amazon y su servicio AWS. Concretamente, con servidores virtuales EC2, almacenamiento en su sistema S3 y su interconexión con EBS.

Hoy me esta tocando hacer una limpieza de una instancia que tengo con un antiguo cliente que resulta que se cayó recientemente y me ha apetecido compartir una reflexión y así escribir la primera entrada técnica (muy light), aunque no tiene nada que ver con dispositivos móviles.

Así pues, antes de exponer el grave problema al que me podría haber enfrentado si no hubiese hecho las cosas bien, os expongo un poco las partes de AWS que estoy utilizando (hay más, pero estas son las más comunes):

- EC2 (Elastic Compute Cloud): Este es el servicio de Amazon que simula los servidores virtuales. Su funcionamiento es sencillo, seleccionas una imagen (AMI) de la que partir (puede ser una imagen genérica como una distribución Ubuntu o una imágen muy personalizada en la que tengas multitud de software ya configurado), seleccionas unas características de tu instancia en función del RAM, procesador, etc del que quieras disponer y la lanzas. En pocos segundos tendrás un servidor virtual con acceso vía SSH y con las características de tu AMI seleccionada. Sobre esta instancia, dado que es a todos los efectos un servidor virtual, puedes instalar el resto de software que desees, así como configurar cuentas, permisos,...

- S3 (Simple Storage Service): Este servicio proporciona un espacio persistente donde almacenar datos. A modo de simplificación, podemos entenderlo como un disco duro virtual y persistente.

- EBS (Elastic Block Storage): Con este servicio podremos interconectar los dos anteriores, simulando que el S3 es una unidad más de nuestra instancia EC2. Quizá te estás preguntando la necesidad de este servicio. Pues bien, la respuesta es que EC2 por sí mismo no tiene persistencia de datos! sí sí, como lo has oido, las instancias EC2 son instancias virtuales, que tienen su sistema de ficheros como cualquier otro servidor, pero a diferencia de un servidor estándar, este sistema de ficheros es volátil, lo que significa que si por alguna razón tienes que terminar con la instancia perderás los datos que has introducido desde que lanzaste la instancia a partir de un AMI.

- Elastic IP: Este servicio nos permite mapear cualquier instancia con una IP externa y única. Es necesario si queremos que este servidor esté accesible externamente por ejemplo por un nombre de dominio. La gran ventaja de esto es que al arrancar nuevas instancias podemos seguir usando la misma IP y así no tenemos que esperar a que los DNS se refresquen para cambiar de máquina (tardan hasta 48h).

Y ahora que he comentado las principales partes implicadas, os expongo lo ocurrido: Una instancia que llevaba meses funcionando (y en producción), resulta que ha dejado de funcionar. No sólo el servidor web está caido, sino que la instancia está completamente inaccesible, sin posibilidad de conectarte por SSH, FTP ni similares! Arggghhhh!!
¿Qué hacemos? pues no nos queda otra que entrar en la consola de administración de Amazon AWS, arrancar una nueva y apuntar la IP pública a la nueva, pero ¿perderemos todos los datos desde el último backup? esto sería muy grave porque además no hacemos backups con toda la frecuencia que deberíamos. Por otra parte, ¿que pasa con el software que instalé para adaptar mi instancia? ¿tendré que volver a instalarlo?

Bueno, calma, para resolver el primer problema (y más grave) tenemos el EBS. Gracias a este servicio, toda nuestra BD estará trabajando en una unidad persistente, que NO habrá perdido la información y que podremos enlazar con la nueva instancia. Os dejo un enlace donde se explica una forma sencilla y clara sobre como montar este tipo de sistemas, moviendo los datos de MySQL a la unidad de EBS:
http://lab.redmallorca.com/servidor-mysql-persistente-sobre-ec2-y-ebs/

¿Y el segundo problema? ¿tengo que volver a instalar todo el software? pues la respuesta es que tendrías que hacerlo, a no ser que hayas sido precavido y hayas generado una nueva AMI a partir de tu instancia una vez configurada. ¿Como hacerlo?, de nuevo, os enlazo a un post en donde lo explica muy clarito:
http://lab.redmallorca.com/crea-tu-propio-ami-basado-en-ubuntu-para-ec2/

Así que, para todos los que trabajéis con Amazon EC2, ni se os ocurra hacerlo sin contemplar posibles cortes o caídas porque ocurren! Mi consejo, aunque tengo poca experiencia, es que una vez instalado todo el software en tu instancia a partir de la AMI pública generes un AMI privada con esta configuración, posteriormente configures el sistema para que la BD trabaje sobre la unidad EBS, y por último, opcionalmente me crearía otra AMI privada con todo esto montado. Ojo, esta última AMI es posible que os de problemas al arrancar, por estar enlazada al EBS (a mí me los ha dado), por eso os recomiendo que hagáis la AMI preEBS para poder recuperar todo si tenéis problemas con esta segunda AMI (solo tendríais que repetir los pasos de montaje de EBS, pero los datos seguirían estando ahí y el software funcionando).

Así que ya sabéis, haced las cosas bien al principio aunque os lleve un par de horas extras de trabajo y luego no tendréis que lamentar las pérdidas!

Mi primera entrada

2010-06-19T17:19:00.000+02:00

Este blog se ha movido de forma permanente a http://angelolloqui.com/blog

Si estás leyendo esto, bienvenido! esta es mi primera entrada en un blog que aún no sé que rumbo tomará.
¿Por qué? porque simplemente aún no sé de que voy a hablar. Muchas veces me levanto pensando "esto debería compartirlo para que a nadie más le pase", "que dificil se hace trabajar con clientes como XXX", "que bueno lo nuevo en este SDK, versión, etc" o simplemente un "me siento bien!".

Así que aquí estoy, escribiendo a la nada y a todos a la vez. De momento, lo único que sé seguro es que al principio habrá un poco de todo, comentarios técnicos muy centrados en desarrollo con plataformas móviles como iPhone y Android y alguna otra entrada que poco o nada tenga que ver.

Saludos!