Créer un nouveau projet GitHub sous Eclipse

Créer un nouveau projet GitHub sous Eclipse

Bonjour, après plus d’un mois d’absence, je reviens avec un tutoriel sur « Comment créer un projet Github sur Eclipse » (prononcer jithub guithub).

Tout d’abors qu’est-ce que GIT ? Et bien GIT est un gestionnaire de versions tout comme CVS ou SVN mais comparé aux autres, GIT n’as pas besoin d’avoir un point centralisé pour fonctionner. De plus, il gère mieux (pas vraiment tester) toute la partie merge des différentes branches.

Tout se passera exclusivement sous Eclipse sauf la partie création du repository (et initialisation si vous voulez faire une partie trunk/branche/tag). 

I – Création du repository sous GitHub

Bien. Pour commencer, rendez-vous dans le backoffice de GitHub après vous être authentifier. Lorsque vous êtes sur la liste de vos repositories, cliquez juste sur le petit bouton « add repository » (figure 1)

Figure 1 - Le bouton est vraiment petit

Ensuite, rien de particulier, vous nommez votre Repository, ajoutez une description. SURTOUT, n’oubliez pas de sélectionner d’initialiser le repository avec un README et le tour est joué. A la suite de quoi, vous arriverez sur le récapitulatif des commandes git et des liens servant à rattacher votre projet eclipse.

II – Rattachement de son projet à GitHub

Maintenant, nous allons créer notre projet à rattacher à GitHub. Pour cela, nous devons d’abord importer un projet existant depuis GIT pour créer notre projet dedans (je sais c’est compliqué mais nous ne pouvons pas faire autrement). Pour cela, vous devrez juste faire clic droit dans l’arborescence des projets puis import. Vous sélectionnez projet GIT puis suivant et là vous arrivez sur une page d’informations de connexion (figure 2)

figure 2 - Nous nous connectons à github

Vous avez juste à rentrer les informations suivantes :

  • Lien du repository (qui rempli environ 80% du formulaire)
  • Indiquer que vous vous connectez en HTTPS
  • Votre login/password

Quand c’est fait, vous cliquez sur Suivant, Eclipse va regarder s’il trouve une branche à importer, vous sélectionnez la seule existante (master) et vous continuez jusqu’à tomber sur l’action à effectuer à l’import. Vous sélectionnez Use New Project Wizard ou Import existing Project. C’est selon vos envies et le tour est joué. Ici, je vais demander un nouveau Projet Android.

Quand le projet est créer, il faut lui réindiquer à quel GIT se relier (je trouve ça très très très chiant de le réindiquer). Pour cela, faites un clic droit sur votre projet => team => share Project (figure 3)

figure 3 - Partager Projet ne fait que SVN alors que Share Project gère GIT

Maintenant la fenêtre de sélection du système de versionning apparaît. Sélectionnez le système GIT puis cliquez sur Suivant. Là, vous devez indiquer à quel Repository GIT vous voulez le relier. Indiquez dans la liste déroulante celui vous concernant, puis cliquez sur terminer (figure 4).

figure 4 - Sélection du Repository cible

A partir de maintenant, on peut commencer les commits Locaux. Oui, car GIT utilise deux choses lors du partage des données. Le commit local qui permet de commiter seulement à soi même les changements et le commit distant, appelé Pull, permettant d’envoyer toutes ses modifications aux autres collaborateurs.

Pour le Commit local, vous n’avez qu’à cliquer sur le projet => team => commit (figure 5) puis après la fenêtre de dialogue pour les infos du commit est exactement comme pour celle de SVN/CVS. Vous validez et c’est bon, vous venez d’effectuer votre premier Commit.

figure 5 - Quel grand menu

 Il ne nous reste plus qu’à envoyer nos commit locaux sur GitHub. Il suffit de refaire clic droit sur le pojet => team =>Push to Upstream

Vous devriez voir maintenant une fenêtre identique à celle du commit Local mais recensant cette fois-ci tous les commit locaux à déployer. Vous acceptez et c’est fini. Votre projet est maintenant présent sur GitHub.

Débuter sur Backbone.JS

Débuter sur Backbone.JS

Aujourd’hui aucun tutoriels mais la présentation d’une technologie Web que je commence à apprendre à utiliser et qui s’avère rudement bien pensée.

Comme le nom de l’article le suggère, Backbone est une library Javascript. Mais cette library a la particularité d’utiliser le patern MV* (je ne dis pas le C car il n’y a pas réellement de controllers). De là vous pouvez rattacher des événements à vos models pour effectuer des actions javascript. Si en plus vous rajoutez une couche médiateur/façade, vous aurez une base en béton.

Malheureusement je n’ai pas assez d’expérience dessus pour vous faire une introduction ou vous en dire plus donc voici les différents liens utiles pour découvrir cette library et peut-être voudriez vous l’adopter :

Et voici une liste non exhaustive des sites utilisant cette technologie :
  • DocumentCloud
  • Flow
  • Foursquare
  • Groupon
  • Basecamp
  • Stripe
  • Trello
  • Diaspora (oui il est bien vivant ce facebook killer)
Voilà, si vous avez d’autres liens utiles sous le coude n’hésitez surtout pas à les partager. Je suis très intéressé par tout ce qui touche à cette library.
Teinter parallèlement la même ressource
Notre image drapeau

Teinter parallèlement la même ressource

by Throrïn 0 Comments

Il est difficile de donner un titre court à ce que je vais expliquer aujourd’hui. A côté de ça, l’explication sera courte car très simple. Donc, pour en revenir à nos moutons, nous allons voir comment afficher sur le même écran deux fois la même ressource teinté d’une manière différente comme le montre l’image ci dessous.

Notre image drapeau

De base, lorsque l’on charge une ressource, même si c’est plusieurs fois dans différentes variables, Android répercuter les changements faits sur toutes les variables pointant sur cette ressource. Mais heureusement, il existe une fonction à appeler permettant de bloquer cette répercussion. Il suffit de rendre muette votre ressource. Dans les lignes suivantes, nous allons voir comment :

//chargement de nos ressources
Drawable flagGreen  = getResources().getDrawable(R.drawable.ic_menu_slide_flag);
Drawable flagRed = getResources().getDrawable(R.drawable.ic_menu_slide_flag);

//maintenant, on les rend muettes pour ne pas répercuter 
//les changements aux autres appeles de cette ressource
flagGreen.mutate();
flagRed.mutate();

La fonction permettant ceci est la fonction mutate(). Voici ce que dit la documentation à propos de cette fonction :

Make this drawable mutable. This operation cannot be reversed. A mutable drawable is guaranteed to not share its state with any other drawable. This is especially useful when you need to modify properties of drawables loaded from resources. By default, all drawables instances loaded from the same resource share a common state; if you modify the state of one instance, all the other instances will receive the same modification. Calling this method on a mutable Drawable will have no effect.

Returns
  • This drawable.

Maintenant que « nos ressources » sont dissociées l’une de l’autre, nous allons pouvoir leur appliquer un filtre de couleur. Le filtre est appliquable sur les Drawables grâce à la fonction setColorFilter() :

flagGreen.setColorFilter(Color.parseColor("#52D052"), Mode.MULTIPLY);
flagRed.setColorFilter(Color.parseColor("#D11717"), Mode.MULTIPLY);

Pour effectuer un effet différent de filtre, on peut faire comme pour les calques sous Photoshop ou Paint.net, on sélectionne un « mode de calque ». Ici j’ai opté pour un mode de multiplication pour obtenir le résultat souhaité. Maintenant vous pouvez peindre vos Drawables dans des Canvas, les afficher dans une ImageView, ils apparaîtrons comme la capture de début de l’article. Si vous oubliez d’appeler la fonction mutate() sur vos Drawable, ils s’afficheront avec le dernier filtre appliqué (ici tous en rouge).

Gestion des différents écrans de même densité

Gestion des différents écrans de même densité

by Throrïn 1 Comment

Si vous vous êtes essayés au développement Android, vous avez pu constater que son plus gros défaut, c’est les différentes résolutions d’écran (et les Roms constructeurs/opérateurs). Dans la plupart des cas, on peut se débrouiller avec les différents dossiers de ressource de base comme ceci :

  • ldpi (ex : HTC tatoo)
  • mdpi (ex : Samsung Galaxy Spica)
  • hdpi (ex : Nexus One/S)
  • xhdpi  (ex : Asus EEEPad Transformers)

Le souci, c’est que certaines de ces densitées peuvent être utilisées par des résolutions utilisant un ratio différent. Par exemple, le Nexus One et le Motorola Milestone ont chacun une densité HDPI mais l’un a une résolution de 480×800 (ou WVGA800) et l’autre une résolution de 480×854 (ou WVGA854).

Si vous utilisez une ressource de taille fixe (comme une image de SplashScreen) vous vous retrouverez avec une bande noire sur les écrans WVGA854. Nous allons donc voir comment renseigner à Android que nous allons chercher le même fichier (même nom) mais uniquement pour l’un ou l’autre des écrans.

Pour ce faire, nous allons créer deux machines virtuelles Android différentes. L’une utilisant un écran en WVGA800 avec une densité de 240dp et l’autre avec un écran WVGA854 d’une même densité que la précédente.

notre émulateur milestone

notre émulateur nexus One

Maintenant nous allons créer un projet Android de base avec comme layout main.xml le suivant :

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:orientation="vertical" >

    <ImageView
        android:id="@+id/imageView1"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:src="@drawable/splash" />

</LinearLayout>

Et voici l’image splash.png utilisée dans notre ImageView. Elle est à placer dans /res/drawable-hdpi :

[]1

Splash pour le N1

Pour bien voir sa contenance sur l’écran, nous allons mettre notre application en fullScreen tout en désactivant la barre de titre (la barre grise moche qui dit le nom de l’application). Rajoutez ces lignes suivantes dans la méthode onCreate de votre application juste avant l’appel à setContentView():

requestWindowFeature(Window.FEATURE_NO_TITLE);  
getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN);

Maintenant lancez l’application sur les deux émulateurs afin de voir le rendu sur chacun :

Résultat sur le WVGA800

Résultat sur le WVGA854

Comme vous pouvez le voir, nous nous retrouvons avec une bande noire apparaissant sur notre émulateur WVGA854. Nous allons donc rajouter le répertoire suivant : drawable-port-hdpi-854×480. Si on le décompose cela donne :

  • drawable            : type de ressource
  • port                : orientation (land pour paysage, port pour portrait)
  • hdpi                : densité de l’écran
  • 854×480             : résolution de l’écran

Nous allons donc pouvoir rajouter le splash suivant dans ce dossier afin d’avoir le bon rendu sur chacun des émulateurs. N’oubliez pas de le nommer de la même façon que l’autre splash à savoir splash.png.

[]2

notre nouveau splash pour WVGA854

Et voilà le résultat :

Résultat final sur le WVGA800

Résultat final sur le WVGA854

Maintenant avec ceci vous savez utiliser les ressources pour toutes les résolutions existantes et à venir sur Android. Mais rassurez-vous, la plupart du temps les répertoires citées au début de l’article suffisent amplement pour couvrir l’ensemble du parc. Source :

http://developer.android.com/guide/practices/screens_support.html 

Utilisation de Zend REST : Partie 2

Utilisation de Zend REST : Partie 2

Comme promis, voici la partie 2 du tutoriel sur Zend REST. Dans celui-ci, nous allons aborder les choses suivantes :

  • Création et Utilisation d’une APIKEY
  • Utilisation des différentes méthodes http et test des retours JSON avec CURL.
  • Mise en place de codes retours http pour dire s’il y a eu une erreur ou non

Sachez que ce tutoriel est le dernier concernant Zend REST. Le prochain touchera à l’accès sur notre plateforme REST via Android.

I- Création et utilisation d’une APIKEY :

1 – Introduction :

L’APIKEY sert aux utilisateurs à s’authentifier sur votre application simplement, sans avoir quelque chose à taper. Vous pouvez avoir une APIKEY globale (ce que l’on va voir ici), une par utilisateurs, une par plateforme ou un mélange de tout ceci à la fois. A vous de voir ce qui vous convient le mieux. Pour notre exemple, nous allons choisir le plus simple, une APIKEY gobale. Si la requête n’est pas envoyée avec cette APIKEY, elle renverra une erreur. L’APIKEY de notre example sera la suivante :

6a0071dbe561c89581c56d1ecf3a4f54

Pour ceux qui aimeraient savoir ce que c’est, cette APIKEY n’est qu’un simple MD5 de throrinstudio. 

2 – Mise en place :

Maintenant, il faut peut-être dire à Zend que nous voulons utiliser cette APIKEY et, si elle est mauvaise, refuser la requête. Nous allons donc créer un plugin pour notre Controller. Si vous ne savez pas ce que c’est, voici un petit rappel de la documentation :

L’architecture MVC de Zend Framework propose l’injection de plugins de code, qui vont intervenir à différents niveaux dans le processus complet. Le contrôleur frontal enregistre des plugins, et utilise un gestionnaire de plugins (« plugin broker »), qui va se charger de faire intervenir chaque plugin, à chacun des instants clés à votre disposition.

Donc, nous allons créer le plugin RestAuth suivant :

class App_Controller_Plugin_RestAuth extends Zend_Controller_Plugin_Abstract{

    public function preDispatch(Zend_Controller_Request_Abstract $request)
    {
        $apiKey = $request->getHeader('Api-Key');

        //on récupère notre fichier de configuration
        //car notre apikey est stoquée dedans
        $config = Zend_Registry::get('config'); 


        //Si notre apikey est mauvaise alors qu'on essaie d'accéder à notre module rest et qu'on est pas sur la page d'erreur, 
        //on renvoie vers la page d'erreur
        if($apiKey != $config['tutorest']['apikey'] && $request->getModuleName() == "rest" && $request->getControllerName() != "error") {
            //Ici, on met le code 403 ACCES_DENIED à notre réponse HTTP
            $this   ->getResponse()
                    ->setHttpResponseCode(403);
            //Et on redirige vers le controller d'erreur
            $request->setModuleName('rest')
                    ->setControllerName('error')
                    ->setActionName('api')
                    ->setDispatched(true);
        }

    }
}

Comme on peut le voir, on redirige en cas d’erreur sur un controller d’erreur créé pour l’occasion. Voici son code :

class Rest_ErrorController extends Zend_Controller_Action{

    public function init()
    {
        $bootstrap = $this->getInvokeArg('bootstrap');
        $options = $bootstrap->getOption('resources');

        $contextSwitch = $this->_helper->getHelper('contextSwitch');
        $contextSwitch  ->addActionContext('api', array('json'))
                        ->initContext('json');
    }

    public function apiAction(){
        $this->view->error = "APIKEY is wrong";
    }
}

Et maintenant, nous allons dire à Zend de charger notre plugin pour faire le test. Nous allons l’initialiser dans le Bootstrap de notre module Rest :

class Rest_Bootstrap extends Zend_Application_Module_Bootstrap
{
    protected function _initAutoload()
    {
            $moduleLoader = new Zend_Application_Module_Autoloader(array(
            'namespace' => 'Rest',
            'basePath' => APPLICATION_PATH . '/modules/rest'));
            return $moduleLoader;
    }

    protected function _initPlugins(){
        $bootstrap = $this->getApplication();
        $bootstrap->bootstrap('frontcontroller');
        $front = $bootstrap->getResource('frontcontroller');

        $front->registerPlugin(new App_Controller_Plugin_RestAuth());
    }
}

Maintenant, si vous essayez d’accéder au site via http://votresite/rest/ vous devriez avoir le JSON suivant :

{"error":"APIKEY is wrong"}
Attention, il se peut qu’à la place vous ayez le message suivant :  Fatal error: Uncaught exception ‘Zend_Exception’ with message ‘No entry is registered for key ‘config »… Si vous avez ce message, rien de grave, c’est que vous n’avez pas initialisé la variable de registre config à partir du Bootstrap principal. Si c’est votre cas, voici la fonction à rajouter :

protected function _initConfig()
{
Zend_Registry::set(‘config’, $this->getOptions());
}

Maintenant que nous avons mis en place l’apikey, nous allons voir comment la renseigner à notre requête.

3 – Utilisation :

Pour cette partie, nous allons effectuer nos requêtes via curl en ligne de commande linux. Ici j’utilise putty connecté sur mon serveur de test. Avant de pouvoir utiliser CURL, vous devez l’avoir d’installé sur votre machine. Si ce n’est pas le cas, faites le :

sudo apt-get install curl

Ensuite pour interroger le serveur comme le fait votre navigateur, vous aurez juste à taper la commande suivante. Attention, elle vous retournera la même erreur que par le navigateur.

curl http://localhost/tutosite/rest/tuto -v

Si vous avez bien regardé le plugin de vérification de l’apiKey, vous pouvez voir que l’on récupère cette clé directement dans le header HTTP de la façon suivante :

$apiKey = $request->getHeader('Api-Key');

Nous allons donc dire à CURL de rajouter une nouvelle en-tête à la requête HTTP du nom ‘Api-Key’ et contenant notre clé :

curl http://localhost/tutosite/rest/tuto -H Api-Key:6a0071dbe561c89581c56d1ecf3a4f54 -v

En retour vous devriez avoir le bon JSON. Voilà, maintenant vous savez comment renseigner votre api-key directement dans les headers HTTP. Maintenant nous allons passer aux différents types de requête.

II- Méthodes HTTP et REST :

1 – index et GET :

C’est la méthode la plus courante pour demander une ressource. Une requête GET est sans effet sur la ressource, il doit être possible de répéter la requête sans effet. la méthode getAction() sera appelée lorsque l’on cherche à récupérer une ressource en particulier. Si nous ne demandons rien de particulier, c’est la méthode indexAction() qui est appelée à la place. Par exemple pour récupérer une liste, on va dans index, pour récupérer un livre en particulier, on va dans get. 

La commande curl précédente nous permettait d’aller dans notre méthode index. Pour accéder dans la méthode get, il suffit juste d’effectuer la commande suivante en renseignant dans le lien l’id de l’élément à chercher :

curl http://localhost/tutosite/rest/tuto/1 -H Api-Key:6a0071dbe561c89581c56d1ecf3a4f54 -v

En réponse vous devriez avoir le JSON correspondant à celui de getAction.

2 – POST :

Cette méthode doit être utilisée pour soumettre des données en vue d’un traitement à une ressource (typiquement depuis un formulaire HTML). L’URI fournie est l’URI d’une ressource à laquelle s’appliqueront les données envoyées.

Le résultat peut être la création de nouvelles ressources ou la modification de ressources existantes. À cause de la mauvaise implémentation des méthodes HTTP par les navigateurs, cette méthode est souvent utilisée en remplacement de la requête PUT, qui devrait être utilisée à la fois pour la création et la mise à jour de ressources.

Voici la commande permettant de tester le POST :

curl -d "article=myarticle"   http://localhost/tutosite/rest/tuto/ -H Api-Key:6a0071dbe561c89581c56d1ecf3a4f54 -v

3 – PUT :

Cette méthode permet de remplacer ou d’ajouter une ressource sur le serveur. L’URI fourni est celui de la ressource en question. PUT et POST pourraient être tous les deux utilisés pour effectuer la même chose. Normalement j’utilise POST pour la création et PUT pour la modification. Après à vous de voir ce que vous préférez. Voici la commande permettant de tester le PUT:

curl -d "article=myarticle" -X PUT  http://localhost/tutosite/rest/tuto/ -H Api-Key:6a0071dbe561c89581c56d1ecf3a4f54 -v

4 – DELETE :

Cette méthode permet de supprimer une ressource du serveur. Normalement, après exécution de cette requête il ne devrait pas y avoir de réponse HTTP mis à par le status HTTP. Ici nous allons avoir un retour car nous n’avons pas établis les codes retours :

curl -X DELETE  http://localhost/tutosite/rest/tuto -H Api-Key:6a0071dbe561c89581c56d1ecf3a4f54

III- Codes retours :

Afin de savoir si nos requêtes se sont bien passées ou pas, nous regarderont le code retour HTTP avant de traiter le JSON de retour. Comme cela, nous saurons s’il s’agit d’un JSON de ressources à traiter, de confirmation, d’erreur, … Pour faire ceci, nous rajouterons à chacune de nos fonction la commande suivante :

$this->getResponse()->setHttpResponseCode($code);

Nous nous baserons sur les codes retour HTTP. Ce sera plus simple pour les traiter et en même temps ça servira de piqûre de rappel pour certains 😉 :

  • 200 : Requête traitée avec succès (utilisée pour index et GET
  • 201 : Requête traitée avec succès avec création d’un document (utilisée pour PUT et POST)
  • 204 : Requête traitée avec succès mais pas d’information à renvoyer (utilisée par DELETE)
  • 400 : La syntaxe de la requête est erronée (peut être utilisée si vous passez les mauvais paramètres de recherche et/ou d’ajout)
  • 403 : L’authentification est refusée. (utilisée quand APIKEY est invalide)
  • 404 : Ressource non trouvée (peut être utilisée dans GET et PUT/POST quand la ressource à récupérer/modifier n’existe pas)
  • 500 : Erreur interne du serveur (utilisée pour toute erreur PHP ou tests invalides autre que ceux gérés au dessus)
Après à vous de décider. Je n’ai pas mis toute la liste mais seulement l’énumération et les Use Cases des principaux codes de retour.

Le code de retour 204 ne retournera aucun contenu même si vous en renseignez un. Donc pour vérifier que l’action DELETE s’est effectuée avec succès, testez juste le code de retour. Si c’est 204, tout s’est bien passé.

Conclusion Partie 2.

Dans cette partie vous aurez vu comment toucher au header HTTP, comment modifier le code de retour et comment vérifier tout ceci sous Zend. Vous aurez aussi appris à vous servur de curl en ligne de commande (peut être un tutoriel sur curl et Zend dans un prochain tutoriel ?). Avec ceci vous avez toutes les bases pour créer votre propre service REST. La prochaine fois nous verrons comment consommer ce service grâce à une application Android. Sur ce, je vous souhaite une bonne fin de semaine.