[Offre d'emploi] – Développeur ActionScript / Flex / AIR sur Paris 14e
Développeur ActionScript / Flex / AIR (Paris 14e) – Offre d'emploi
- Titre: Développeur ActionScript / Flex / AIR
- L'entreprise: The Great Factory(http://www.potati.com/blog/49-jobs-potati/610-job-developpeur-actionscriptflexair-hf-paris)
Profil Recherché
- Profil recherché:
- Vous avez un minimum de 3 ans d'expérience en matière de développement ActionScript et FLEX
- Vous aimez le travail en équipe
- Vous êtes autonome, passionné(e) par l’Internet et le développement avec les langages de dernière génération
- Vous avez des notions d'architecture SOA avec FLEX Un plus si vous connaissez bases de données et SQL, AMFPHP, JSON, Objective C
- Vous possédez le sens de l’équipe et êtes attiré(e) par la culture « start-up »
- Compétences Techniques Requises:
- Développement FLEX/AIR -Développer notre navigateur desktop en collaboration avec d'autres développeurs
- Développer des widgets pour notre navigateur
- Développer des applications FLEX
- Développement FLASH -Possibilité de réaliser des développements en Flash (jeux éducatifs)
- Expérience Requise: 3 ans
- Disponibilité: Immédiate
Conditions d'embauche
- Lieu : Paris (14e)
- Rémunération: à négocier
- Contrat: CDI
- Contact:
- Par e-mail : christophe.michot AT potati POINT com
Développement mobile AIR (Approche Flex Tutorial) – Architecture projet
Dans un de mes derniers billets, je présentais une vidéo qui montre l'avancement de mon "framework mobile", un peu en marge de Hero:
Flex et composants mobile (AIR pour Android – iOS) – Mon approche
Cette fois-ci, je vais expliquer de manière globale, quelle est l'architecture des applications mobile que je crée.
Recyclage de projets? Non. Recyclage de librairies? Oui!
A la vue des dernières améliorations de Flex, notamment de Hero, certains doivent penser qu'ils peuvent simplement prendre leur projet, et le rendre compatible pour mobile. Ce n'est pas vraiment le cas pour plusieurs raisons.
Tout d'abord, on est dans un contexte d'application native, pas une application Web. On est donc du côté AIR et non Flex. Rien que pour cela, le type de projet change, il n'y a pas de réutilisation directe.
Ensuite, la philosophie des applications mobiles est différente, notamment au niveau du comportement des composants. Ceux-ci doivent être plus gros par exemple ou répondre aux évènements TOUCH.
Pour créer une application mobile, il vous faudra donc un nouveau projet de type Desktop AIR. Mais cela ne veut pas pour autant dire qu'il faut jeter vos projets par la fenêtre et tout refaire. En effet, vous pouvez ré-utiliser les classes / composants qui se trouvent dans des projets de type Flex Library. Il vous suffit pour cela d'ajouter ces projets au "Library Path" de votre projet AIR et vous pourrez en profiter dans votre code.
C'est là où vous allez voir si votre application est plutôt "monolithique" ou plus modulaire. En effet, si vous avez créé un projet Flex dans lequel se trouve toutes vos classes et que vous n'avez pas utilisé de librairie, vous allez devoir effectuer un travail important pour passer toutes ces classes dans un / des librairies.
Si votre code est bien organisé, vous n'aurez pas de mal à effectuer cette opération. Si vous avez trop de dépendances (couplage) entre vos classes, cet exercice va se révéler périlleux voire impossible. N'ayez pas peur de créer des librairies, quitte à découper des librairies en plusieurs librairies. Au final, votre code pourra être ré-utilisé bien plus facilement et les temps de compilation seront plus rapide. Pour un projet mobile par exemple, j'utilise entre 6 et 8 projets de type Flex Library.
Pour faire simple, les librairies sont des ressources et les projets Flex Project sont des assemblages de ces ressources.
Architecture d'un projet mobile chez Business Geografic (simplifiée)
Voici en version simplifiée, la structure des projets chez BG en terme de librairies / projets.Vous verrez souvent mention de "Aigle" qui est la marque de notre produit phare.
Cette version est simplifiée car certaines librairies contiennent en fait d'autres librairies (AigleFramework contient par exemple une librairie cartographie):
Un petit point rapide sur l'objectif de chaque projet:
- AigleFrameworkCommunication: Contient les classes permettant de communiquer avec un service Aigle
- AssetsLibrary: Contient la majorité des icônes utilisés ainsi que des classes static permettant d'y accéder. Cette librairie est très peu souvent modifiée ce qui a permit de réduire considérablement le temps de build des autres projets
- FlexUtils: Contient des classes utilitaires, type manipulation de String, de couleurs, Logger, HashMap, …
- FlexComponents: Ensemble de composants Flex ré-utilisables et non-métier. Par exemple un champ de texte avec suggestions, un fieldset, une image avec cache, …
- AigleCharting: Permet d'afficher les statistiques renvoyées par Aigle
- AigleDataViz: Contient une AdvancedDataGrid bidouillée
- AigleFramework: Librairie pivot contenant tous les composants ortientés métiers, tous les MVC métiers. Cette librairie utilise toutes les librairies citées précédemment
- Projets Web 1-N: Projets de type Flex Project, utilisant AigleFramework pour intégrer des composants métier + modules spé à chaque application
- MobileComponents: Librairie contenant uniquement des composants à destination des mobiles (listes, conteneurs, vues pour mobiles…). Pas de composants métier
- MobileTopLevelComponents: Librairie permettant de partager des "composants métier mobiles" entre plusieurs application AIR. Par exemple, la vue "Carte" de base sera dans cette librairie et héritée par une classe dans chaque projet AIR
- Projets AIR Mobiles 1-N: Projets faisant l'assemblage des composants mobiles métiers et des composants spécifiques à chaque application.
Voilà pour l'architecture des projets qu'il faut mettre en place. On bien sûr avoir tout dans un même projet, cela fonctionnerait. Mais lorsque vous allez vouloir créer une 2e application, vous aurez un gros travail à faire. Il faut aussi garder à l'esprit qu'il est préférable de séparer les classes / composants ré-utilisables des classes / composants métiers pour ne pas créer de couplage.
Adobe confirme la reprise de dév du Packager for iPhone
Les nouvelles vont très vite ces jours-ci. D'abord, l'annonce étonnante d'Apple:
Apple retourne sa veste encore une fois, fausse joie ou vraie bonne nouvelle?
Et après cette annonce hier du changement des termes de licence Adobe en ce qui concerne le développement avec des "third party tools", Adobe annonce qu'il reprend le développement de son packager pour iPhone ce matin:
Adobe a donc l'air de prendre très au sérieux cette annonce d'Apple et ne redoute plus d'interdiction de la part d'Apple. Pour rappel, je ne travaille pas chez Adobe, je n'ai donc pas d'infos en exclu 
.
Adobe va donc reprendre le développement du packager pour iPhone d'Adobe CS5 qu'il avait arrêté il y a quelques mois lors du premier changement des termes de licence Adobe. Pour info, de nombreuses applications développées avec le packager ont été acceptées récemment alors qu'elles étaient refusées depuis des mois. La lumière au bout du tunnel ^^.
Etant très curieux, surtout dans ce genre de situation, j'ai téléchargé la version de démo de Flash CS5 (gros bébé de plus d'1Go) avec le packager iPhone. Après reprise de mon framework perso (toutes mes classes dans un swc), j'ai codé une petite application simple en ActionScript qui se connecte à un serveur (par Internet) et récupère des cartes (images). Grâce au travail que j'avais déjà fait sur mon framework, en 100 lignes de codes, j'avais une carte qui fonctionne exactement comme la version SWF. Les "tap" sont considérés comme des évènements souris donc j'ai pu naviguer tranquillement dans ma carte, tout fonctionnait bien 
.
Le mieux est que j'ai compilé exactement la même application pour Android et le résultat était identique à celui de l'iPhone, un vrai bonheur. Je n'ai pas réussi à faire fonctionner le packager en ligne de commande (pfi.jar) mais j'étais vraiment à deux doigts. Pour l'instant, il manque un peu de documentation de ce côté là. J'espère qu'Adobe va ouvrir un forum de pre-release comme il l'a fait pour Android afin de donner plus de billes aux développeurs.
Apple retourne sa veste encore une fois, fausse joie ou vraie bonne nouvelle?
Après les multiples rebondissements de l'aventure Apple – Adobe, en voici un que personne n'avait vu venir. Apple vient de publier sur son site officiel, cette annonce:
Statement by Apple on App Store Review Guidelines
Dans les grandes lignes, Apple revient sur sa décision d'interdire les outils de développement qui ne font pas partie de la famille Apple (xCode). Apple avait déjà révisé sa décision en autorisant uniquement les outils "third party" ayant une autorisation écrite de la part d'Apple.
Et là, il semblerait que cette interdiction soit bel et bien terminée, les développeurs auraient donc droits de coder dans l'IDE qu'ils souhaitent, avec le langage qu'ils préfèrent.
Cela voudrait donc dire que le packager iPhone d'Adobe (inclus dans la CS5) serait de retour dans les clous. Mais avant de trop s'enflammer, je préfère attendre une réaction officielle de la part d'Apple. Pour l'instant, voici la première réponse qu'il y a eu sur le forum prerelease d'Adobe:
Arno Gourdol
No comments for now. We’re looking into it and we’ll let you know.– Arno ? @arnog ? Director of Engineering, Adobe AIR
Alors info ou intox, on a aussi un commentaire d'un utilisateur:
Steve Broome
My long-pending (since before the TOS update ) app mi-toons was just approved 12 minutes ago.
Voilà, soyez sûr que si Adobe fait revivre PFI de ses cendres (pour Adobe MAX 2010?), vous en entendrez parler sur ce blog !
Doc?, une application AIR de consultation des Livedocs AS3/Flex/AIR offline
La plupart des développeurs Flex vous le diront, le plus difficile dans l'apprentissage d'Adobe Flex est de connaître la totalité de l'API Flex mais aussi certaines ressources AS3 pures. En effet, pour pas mal de problème communs, "il y a une propriété, un composant ou une méthode pour ça". Alors on peut les découvrir en allant voir sur certains forums, les gens qui tombent sur les mêmes problèmes ou bien en consultant la documentation Adobe en ligne (Language Reference).
Cette documentation en ligne est très bien faîte et très complète avec beaucoup d'explications et des exemples. Vous la trouverez en ligne ou bien directement dans Flex Builder (F1). Mais si vous êtes un habitué des livedocs, vous savez à quel point cette documentation est lente et c'est parfois assez frustrant.
Pour pallier à ce problème, des développeurs belges ont conçu une application Air nommée "Doc?" qui vous permet de consulter la documentation en mode offline. Il suffit de télécharger une fois la documentation complète et d'attendre quelques minutes que l'application crawle et indexe tout et vous aurez tout d'accessible en quelques clics. Notamment, une fonction de recherche bien pratique et qui renvoie des résultats bien plus pertinents que la recherche de la livedocs (pour cela, Google se débrouille mieux, c'est un peu triste à dire ). Rajoutez à cela un design épuré qui fait plaisir aux yeux, vous obtenez une application très sympa à utiliser.
On regrettera juste le fait que l'on ne peut pas trier selon le type de résultat que l'on veut (classe, property, méthod par ex.) mais l'outil en reste néanmoins très pratique.L'application est gratuite, vous pouvez faire un don si elle vous à permet de gagner du temps 
Que vous soyez développeur Flex débutant ou chevronné, cette application peut vous intéresser:
Mes projets (Open Source)
Autres
