Sur la route d'Oxiane digressions diverses

Un petit clin d’oeil à Urbancycle et tous les coursiers parisiens !
Rue 89 consacre un article pas mal fait à la course et en particulier à Urbancycle qui fêtait ses 10 ans cette année dans la chistole générale.

Co-fondateur d »Urban Cycle, la plus respectée et ancienne des sociétés de livraison où ne sévissent que des cyclistes, après avoir été lui-même à longueur de journées sur le pavé, Patrick, la quarantaine, a accompagné l’émergence du phénomène.

Dans les années 90, il a débuté dans une filiale d’une boîte américaine. Après sa chute pour des défauts de gestion, il a décidé de se lancer avec deux anciens collègues.

Avec une belle photo de notre JB national.
Tout ça augure d’un superbe pre-event Parisien aux championnats du monde 2013 qui devraient se dérouler à Loz !

Il y a quelques jours une personne me demandait comment récupérer une donnée d’une vue modale s’affichant avec une transition « Partial Curl » (soulèvement partiel de la vue parente comme une page d’un livre) dans son UIViewController parent.

Son problème étant que son code fonctionne parfaitement sous iOS 4 mais pas sous iOS 5.

Je regarde son code et là je remarque que tout est bien compliqué pour une chose aussi simple.

En effet, il observe la valeur de sa vue modale et si elle est à nil (l’animation de fermeture de la vue a eu lieu) alors il déclenche un callback sensé transmettre une donnée à sa vue parente, représentée par une propriété de type UIViewController, sachant que la vue modale se ferme elle-même.

Seulement, le changement d’état de la vue modale n’est pas intercepté et donc la valeur n’est pas transmise.

Outre ce soucis, il aurait dû paraître étrange que la vue modale se supprime et qu’elle possède une propriété UIViewController car dans iOS (et bien d’autres langages objets) on prend la bonne habitude d’étendre les classes de base et ce pour permettre la réutilisabilité par exemple.

Dans iOS, un design pattern est très souvent utilisé, c’est le delegate (délégation ou proxy).

Le principe est simple : déléguer à un autre objet des traitements, c’est une inversion de responsabilité.

Pour démontrer que c’est simple, je vais vous indiquer les étapes à suivre sous iOS 5 avec les storyboards :
- créez un nouveau projet de type « Single View Application » dans iOS
- déposez un UIButton dans la vue du contrôleur principal de votre storyboard
- donnez lui un titre
- déposez un nouveau UIViewController dans votre storyboard
- faîtes un segue modal (ça se prononce ségoué) à partir du bouton vers le nouveau UIViewController

(pour rappel : le segue va instancier le nouveau UIViewController et faire la transition comme définie dans le code ou l’inspecteur)

- cliquez sur le segue et donnez lui un identifiant

- cliquez sur le nouveau UIViewController et fixez le style de transition à « Partial Curl » ou bien faîtesle directement sur le segue.
- ajoutez un UIButton par exemple

- créez une nouvelle classe héritant de UIViewController : PageCurlController et ajouter un protocole PageCurlDelegate déclarant une méthode (style dismissWithData:), dans votre déclaration de classe ainsi qu’une propriété de type id répondant à ce protocole afin d’être réutilisable. Vous pouvez l’appeler… delegate
Ce qui est important : la référence vers cet objet est faible (« weak ») car le contraire n’aurait aucun sens ici, si la référence était forte alors si PageCurlController disparaît le délégué aussi mais comme c’est son parent… tout disparaît ! On ne veut pas cela n’est-ce pas ?

@protocol PageCurlDelegate <NSObject>

-(void)dismissWithData:(NSString *)data;

@end

@interface PageCurlController : UIViewController

@property(nonatomic, weak) id<PageCurlDelegate> delegate;

@end

- n’oubliez pas de la synthétiser :

@synthesize delegate = _delegate;

- retournez dans le storyboard et changer la classe du nouveau UIViewController en PageCurlController (par exemple) dans l’inspecteur d’identité

- reliez le bouton à l’action closePage, c’est ici que l’on fait appel au délégué afin de lui dire que PageCurlController est prêt à disparaître et qu’il lui transmet une donnée.

- (IBAction)closePage:(UIButton *)sender
{
    //faisons appel au delegate afin de transmettre nos données
    //et de fermer cette vue
    [_delegate dismissWithData:sender.titleLabel.text];
}

- on complète notre contrôleur principal (logiquement le pointeur est donc fort sur page) :

@interface PageTrickViewController : UIViewController<PageCurlDelegate>
    @property(nonatomic, strong) IBOutlet PageCurlController * page;
@end

- et dans l’implémentation (on n’oublie pas de synthétiser) :

@synthesize page = _page;

//méthode déclenchée à chaque fois qu'un segue est déclenché
-(void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
    //vérification du segue déclenché
    if([segue.identifier isEqualToString:@"modalCurl"]){
        //ici l'exemple est simple mais il serait judicieux de tester la classe
        //avec isKindOfClass !
        _page = segue.destinationViewController;
        //très important !
        _page.delegate = self;
    }
}

-(void)dismissWithData:(NSString *)data
{
    //ici j'ai juste affiché dans le debug la String transmise
    //mais on peut imaginer la stocker dans une ivar ou l'employer dans une autre méthode
    NSLog(@"%@", data);
    //c'est notre contrôleur principal qui supprime la vue !
    [_page dismissModalViewControllerAnimated:YES];
    //si vous n'avez plus besoin de _page
    _page = nil;
}

Et voici le résultat en image :

Pour les curieux, voici comment Apple voit la délégation : http://developer.apple.com/library/ios/#documentation/General/Conceptual/DevPedia-CocoaCore/Delegation.html

Toutes les équipes d’OXiane se joignent à moi pour vous souhaiter d’agréables fêtes de fin d’année et une excellente année 2012.

Voilà depuis le temps que l’on attendait un bon plugin WYSIWYG (What You See Is What You Get) sous Eclipse, WindowBuilder Pro fait son apparition.

WindowBuilder Pro, ancien produit de l’entreprise Instantiations (Spécialisée dans la technologie Smalltalk) , devient open source suite au rachat de cette société par Google. Intégré comme plugin java pour Eclipse, il permet de concevoir des interfaces graphiques très simplement via des composants drag’n'droppable (glissé déposé).

On peut utiliser plusieurs bibliothèques de composant JAVA comme AWT, SWT, GWT et SWING. Pour ma part je me suis surtout intéressé à l’utilisation des composants SWING dans ce plugin.

L’avantage de ce plugin outre sa simplicité de prise en main, c’est la qualité du code java généré. Que nous verrons plus tard.

Comme vous pouvez le voir ci-contre, le plugin jouit d’une vu « Design » qui donne accès aux composants que l’on souhaite utiliser dans notre interface (ici SWING).

On retrouve donc tout naturellement les JPanel, JLabel, JTextField, les layouts et bien entendu le fameux GridBagLayout qui a fait s’arracher les cheveux à plus d’un!

Autre plus intéressant, la gestion des évènements, il est désormais possible au travers de quelques clics (deux! ) de générer les méthodes liées aux évènements.

Nous rentrerons dans les détails, de tout cela par la suite.

Pour l’instant il est bon de savoir que ce plugin est disponible pour les versions Eclipse Ganymède (3.4) à Indigo (3.7) et comment l’installer !

Lire la suite du bllet »

Je vais vous parler dans cet article d’un composant qui est disponible à partir de la version 3.0 d’android ou alors à partir de 1.6 via l’ACP. Il s’agit du ViewPager. Ce composant permet de présenter une galerie en plein écran. C’est à dire que pour pourrez scroller horizontalement d’un écran à un autre.
Vous pouvez voir notre démo de ce composant à la fin de cet article.
Ce composant à été présenté par Rich Hyndman ici : http://android-developers.blogspot.com/2011/08/horizontal-view-swiping-with-viewpager.html

On peut trouver des utilisation du ViewPager entre autres sur le Market ou encore sur Google+.

Il est également possible d’adapter le composant Gallery pour obtenir le même effet mais vous allez devoir vous creusez pas mal les méninges pour éviter certains problèmes.

Parmi ces problèmes vous aurez des composants qui interceptent le onClick alors que vous faite un slide, ou encore, plusieurs composants qui prennent en même temps l’état state_pressed alors que vous en touchez qu’un seul.

Bref il est beaucoup plus simple d’utiliser un composant fait pour : le ViewPager. La bonne surprise c’est qu’il est disponible à partir des version 1.6 grâce au package de compatibilité. Ce package développé par google. Il permet de rendre disponible des nouvelles API notamment les fragments, le ViewPager, etc…

Voilà comment utiliser ce composant étape par étape :

Installer le package de compatibilité Android (ACP)

Pour installer ce package, il suffit d’utiliser l’ AndroidSDK Manager, de développer le répertoire Extras et cocher « Android Support Package ».

Lire la suite du bllet »