Alors que les applications mobiles sont devenues incontournables d’un point de vue marketing pour nos clients, elles sont aussi de plus en plus complexes.

Au temps passé à développer une application riche, il faut dorénavant ajouter le temps à la porter sur différents systèmes d’exploitation. En effet, si la plupart des applications concernaient les plateformes IOS, il y a aujourd’hui une forte demande pour des applications android; ce qui est cohérent avec la courte avance qu’a pris android sur IOS récemment.

C’est dans ce contexte que plusieurs solutions de développement multiplateforme ont émergé. Titanium est l’une d’elles et propose donc de développer dans le même langage (javascript) une application pour IOS, Android et Blackberry (béta).

L’installation

L’outil est gratuit avec un support payant. L’enregistrement ne prend que quelques minutes et l’IDE s’installe sans rien faire de particulier sur mac ou PC. Afin de tester l’application sur le simulateur IOS ou pour la lancer sur un iphone, il faudra disposer d’un mac comme plateforme de développement. Toujours pour IOS, il faudra un compte développeur si l’on veut déployer sur iPhone ou iPad.

Une documentation de base (vidéos, exemples d’applications) est disponible mais rapidement c’est dans le forum de l’éditeur que l’on trouvera les réponses à ses questions ou des exemples de code. Le forum est assez vivant et la plupart des problèmes y sont déjà adressés.

L’IDE

La prise en main de l’outil est immédiate lorsque l’on connaît eclipse; on retrouve les fonctionnalités les plus couramment utilisées comme la détection des erreurs de syntaxe, la complétion automatique, le lancement des applications ou encore le debugging.

Depuis l’IDE on peut donc lancer les émulateurs ou bien directement le code sur les appareils. Il subsiste quelques différences entre les deux mais c’est globalement très satisfaisant pour tester sereinement.

Les concepts de développement

L’outil ne propose pas de WYSIWYG pour faire ses interfaces graphiques. Il faut donc créer programatiquement tous les écrans en donnant les paramètres de chaque composant visuel. Les différents composants “s’emboîtent” les uns dans les autres afin de créer le rendu final.

Il n’existe que 2 layouts différents: vertical et horizontal. C’est un peu juste pour décrire tous les types d’écran. C’est bien sûr suffisant mais parfois cela rajoute de la complexité et du code pas très intéressant à écrire.

Le langage

Entre Objective C et Java il y a un pas que beaucoup de développeurs n’ont pas franchi. En revanche, pour un développeur java il est courant d’avoir déjà manipulé du javascript ou de se faire rapidement aux concepts de base.

Ainsi, il est tout à fait possible et même recommandé de reconstruire son modèle objet, tant pour les objets métiers que pour les composants graphiques customisés.
Le gros bémol est qu’il n’est pas possible d’hériter directement des composants natifs fournis par Titanium. Il faut donc passer par un mécanisme d’encapsulation.

En revanche c’est un véritable plaisir de pouvoir passer des fonctions en paramètre d’autres fonctions, ce qui rend beaucoup plus aisé l’écriture de code ‘technique’ générique.

L’API et les librairies tierces

L’API proposée est très riche. D’un point de vue IHM, pour répondre aux besoins exprimés par les designers, nous avons pour le moment trouvé tous les composants graphiques nécessaires ou au moins les briques élémentaires qui nous ont permis de créer ce qui n’existait pas.

Techniquement, rien à redire non plus. Des appels HTTP pour faire du REST à la lecture de médias (vidéos) en passant par la localisation sur une carte ou la persistance des données dans une base SQLite beaucoup de choses sont proposées. L’éditeur vend également des composants supplémentaires (paypal, QR codes, facebook, …).

Tout ou presque. Presque parceque cet algorithme de cryptage que vous venez de créer il n’est pas dans l’API Titanium. Vous vous en servez déjà sur votre serveur node.js ? Il suffira de l’intégrer aux sources de votre application mobile! C’est donc toutes les librairies javascript que vous pouvez intégrer !

Depuis les dernières versions du SDK, titanium supporte la norme commonJS ce qui permet encore une plus grande réutilisabilité du code.

A savoir (bonnes pratiques,  recommandations, …)

Malheureusement, parfois l’API ne fonctionne pas comme cela devrait, du moins sur une des plateformes cibles (il est rare qu’une fonctionnalité ne passe ni sur android ni sur iphone). Il faut donc utiliser des solutions de contournement des problèmes et surtout être un peu inventif ! Pour contourner les problèmes, nous avons préféré faire des workarounds qui fonctionnent sur les 2 OS cibles plutôt que de faire du code spécifique pour chacune des 2 plateformes avec dans un cas le code ‘classique’ et dans l’autre le contournement. Les commentaires dans le code sont alors de rigueur pour expliquer pourquoi l’API n’a pas été utilisée comme attendue.

Par exemple le composant de barre de navigation pour l’iphone n’apparaît pas correctement lorsque l’on souhaite mettre une image en arrière plan (corrigé dans le sdk 1.7.3!) Ce composant étant en plus spécifique iPhone, nous avons choisi de le redévelopper.
C’était assez simple car ce n’est qu’une vue que l’on place en haut de l’écran, toujours de la même taille, sur laquelle on peut ajouter des boutons, des libellés et évidement une image de fond. Et nous voilà avec notre barre de navigation maison, dont on pourra en plus se servir pour notre version android.

Si l’on a choisi Titanium pour son aspect multiplateforme, il est primordial de développer et de tester en même temps sur les différents OS. En effet, avec les adaptations dues aux contraintes techniques (bugs), il y a sans cesse des allers-retours pour valider que la solution mise en place est bien fonctionnelle sur tous les environnements.

Si on s’attaque par exemple à la réalisation de la version Android après avoir fini l’application sous IOS (ou réciproquement), à moins d’avoir une très bonne expérience sur Titanium, c’est sans exagérer l’assurance de passer autant de temps à développer sur chacune des plateformes et parfois même encore plus de code spécifique pour chacun des OS. Le gain (en temps) par rapport à un développement avec les langages natifs serait donc nul.

Une question importante à se poser est la gestion de l’affichage sur les différents appareils android. Nous avons fait le choix de traiter les 2 résolutions les plus courament utilisées en laissant de coté les plus petits écrans (sur lesquels l’expérience utilisateur ne serait de toute façon pas satisfaisante) et les tablettes (pas la cible d’utilisateurs).
Chaque résolution à gérer signifie un jeu d’image en plus à adapter.

La gestion de la mémoire

Lorsque l’on parcourt les documents sur la gestion de la mémoire, on trouve rapidement 2 méthodes pour implémenter son application tout en s’assurant que les besoins de mémoire n’explosent pas et forcent la fermeture de l’application.

La gestion la plus simple et visiblement celle qui avait été pensée au départ est très bien démontrée dans l’application KitchenSink (l’application de démo).
Le concept de base est que chaque écran existe dans un contexte différent et que ce contexte est détruit lorsque l’on ferme son écran. Des mécanismes très simples aident à ouvrir et fermer les écrans et donc à bien gérer sa mémoire disponible.
On aboutit donc à une hiérarchisation d’écrans que l’on pourrait représenter avec un arbre.
Un écran est maintenu en mémoire tant qu’il est affiché ou qu’un de ses sous-écrans est lui-même actif. Le point d’entrée de l’application (racine) connaît ses écrans et c’est à elle que l’on donne l’ordre d’en ouvrir un ou d’en fermer.

C’est ce choix que nous avons retenu pour notre application et cela fonctionne pour le moment avec la vingtaine d’écrans que nous avons.

Une gestion plus complexe est souvent expliquée à l’aide de l’application tweetanium. L’idée est de se passer du mécanisme offert par l’API et de tout charger dans un seul et même contexte. Il faut donc écrire à la main le code qui permet d’instancier en mémoire ou bien de libérer les écrans chaque fois que l’on en a besoin.
Ce mécanisme sans doute plus fin car complètement géré par le développeur est sans doute meilleur mais nécessité un coût de mise en oeuvre non négligeable,  surtout quand on est pas habitué au développement avec Titanium.

Les développements spécifiques

Ce serait mentir que de dire que les applications développées avec titanium ne contiennent pas de code spécifique. D’ailleurs, ce n’est pas du tout ce que vend l’éditeur.

Dans certaines partie du code technique (non UI), il faut gérer différemment les OS. Par exemple pour gérer les droits d’accès à la géolocalisation du téléphone, l’enregistrement pour les messages Push (notifications), la navigation d’une page à l’autre, …

Au banc d’essai

La première question à se poser, mais indépendante de titanium est de savoir si on a envie de développer la même application pour android et ios. En effet, les utilisateurs android ont ils envie de retrouver une barre de navigation propre à l’iphone ? Titanium permet de lever certains points en faisant par exemple un type de rendu différent pour le gestionnaire d’onglet android et IOS.

Pour aider à répondre à cette question, l’équipe de titanium propose de faire le choix entre une application que les utilisateurs sauront immédiatement prendre en main (car s’inscrivant complètement dans les codes de développement de chaque OS) et une application avec une identité visuelle et ergonomique forte mais communes aux différents appareils mobiles.

Pour des raisons de délais (et donc de coûts) , nous avons plutôt misé sur une identité typique à l’iphone et (très) légèrement déclinée pour android. Ceci dans le but de mutualiser le plus de code possible.

Si il reste un nombre non négligeable de bugs, on parvient dans la plupart des cas à trouver des contournements pour arriver à ses fins. C’est bien sur plus coûteux en temps, notamment quand une fonctionnalité est correctement implémentée sur un système mais qu’elle comporte des dysfonctionnements sur l’autre. C’est là que l’expérience des développeurs sur la façon de traiter telle ou telle problématique permet de gagner énormément de temps en étant efficace dès la première implémentation.

Utiliser Titanium pour créer par exemple une application uniquement pour iPhone alors qu’on ne connaît pas Objective C est aussi une utilisation possible, surtout pour une application simple.
La première semaine de développement laisse une impression incroyable de simplicité et de productivité. Les “ennuis” ne commencent réellement que lorsque l’on souhaite peaufiner son interface utilisateur.

Pour une application avec énormément d’écrans, de données manipulées et stockées, il sera plus judicieux de développer en natif sous peine de se confronter à des problèmes supplémentaires (gestion plus difficile de la mémoire, des bugs sur certains composants, les tests unitaires sur des calculs en local, … ).

Le point le plus décevant restera tout de même l’abscence d’un framework de tests (unitaires et intégration). Si la tache est théoriquement faisable, la complexité de mise en place est rédibitoire.
Ainsi titanium propose pour le moment de s’appuyer sur des frameworks comme QUnit en attendant que l’éditeur ne sorte l’outillage adéquat. Mais si le test du code javascript reste accessible, c’est le rendu visuel et la navigation qui couteront le plus cher à mettre en place dans une usine logicielle.

Nous avons constaté que l’exécution est parfois moins fluide sous Android. L’éditeur promet de régler ce problème en utilisant V8 plutôt que Rhino. Les performances seraient au minimum 2x meilleures avec dans la plupart des cas une amélioration de 10x à 15x. Ceci sera disponible “dans le SDK 1.8, avant la fin de l’année”…

Valtech a choisi Titanium pour développer la 2ème version d’une application iphone qui a été téléchargée plus de 120 000 fois et pour lancer en même temps la version android qui n’existait pas jusqu’alors.

Paris Android User Group ou PAUG vise à rassembler les passionnés par Android dans la région parisienne. Depuis sa création (fin 2010), PAUG a déjà organisé quatre sessions autour de sujets techniques qui ont connu un fort succès.

Je présenterai la réalité augmentée lors de la prochaine session de PAUG qui aura lieu le lundi 6 juin 2011 à partir de 19h à l’ECE, 37 Quai de Grenelle 75015 Paris.

Dans la première partie de la soirée et après une rapide introduction de la réalité augmentée, je vais me focaliser sur le fonctionnement des navigateurs de réalité augmentée type Layar et Wikitude pour percer leur secret.

La deuxième partie de la soirée sera consacrée aux SDK de réalité augmentée et elle sera présentée par Diotasoft.

120 places sont prévues et l’inscription se passe via Meetup .

Avec la croissance fulgurante ( à 3 chiffres annuel ) des ventes aussi bien sur iPhone que sur Android, les demandes en application mobile natives sont fortes.

Le développement natif a l’avantage d’ une interface utilisateur fluide. Néanmoins la montée en compétence exige au moins quelques mois d’expérience pour des projets relativement courts (en semaines ). Chaque plateforme est spécifique, une expérience sur iPhone n’est pas forcément transférable sur Android et vice versa.

L’ idéal pour le développement multi-plateforme reste l’HTML5 rendu sur le navigateur de l’OS : webkit pour iOS et Android, Firefox pour Meego, Internet Explorer Mobile pour Windows Phone 7. HTML5 reste une solution universelle pour le front-end . Les coûts sont factorisés par le nombre d’OS ciblé.

Il existe des solutions multi plateforme tel que PhoneGap, App Titanium qui mimiquent l’interface utilisateur natif . A la différence de ces outils ,  ce tutorial vous laisse libre sur le choix de votre librairie JavaScript. Les librairies utilisées sont  iUI Project de Joe Hewitt , iWebKit de Jonathan Stark , JQTouch de David Kaneda .

Tutorial

Ce tutorial expose comment utiliser un “wrapper” de l’HTML5 sur Android. En d’autres termes , ce projet embarque de l’ HTML5  dans une application Android .

Commencez un nouveau projet Android sous Eclipse à partir d’android 2.0 ( SDK API >=5 ). Vous disposez déjà d’une application web qui tourne sans serveur. Déposez le dans le répertoire “assets” , c’est ici où tout le site web se trouve avec ses références JavaScript, CSS …

Créez un  nouveau layout “main” où on va introduire une webview . Le layout réprésente la view dans le modèle MVC . Cette webview sera la fenêtre d’entrée pour notre application HTML5 .

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent">
 
<WebView    android:id="@+id/webview"
android:layout_width="fill_parent"
android:layout_height="fill_parent"    />
 
</LinearLayout>

Dans le code source , créez une classe NaviRay qui hérite d’ Activity . Si vous n’êtes pas familier avec la notion d’activity,  je vous recommande de comprendre son cycle de vie .
La méthode  onCreate initialise le layout “main”  . La  webview pointe dans le dossier assets vers la page index.html

public class NaviRay extends Activity{
 
	private WebView browser;
 
	/** Called when the activity is first created. */
 
	@Override
	public void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		setContentView(R.layout.main);
		browser  = (WebView) findViewById(R.id.webview);
		browser.getSettings().setJavaScriptEnabled(true);	
		browser.loadUrl("file:///android_asset/index.html");
	}
}

Dans le manifest , rajoutez la permission android.permission.INTERNET

Ca y est, on peut maintenant accéder à notre site web en local.

Options

Cette application ne comporte qu’une seule Activity . Dans le code source ,  la gestion de l’historique du bouton “back” et le menu sont inclus .

Appels natifs

L’une des restrictions de l’HTML est sans aucun doute l ‘ impossibilité d’utiliser des fonctions natives (GPS , accélèromètre , contacts … ) . Quoi que on peut toujours appeler.
Sans utiliser d’intent , il est possible de passer un appel téléphonique ou d’envoyer des SMS juste avec de l’HTML ( testé sous iPhone et Android )

Pour téléphoner vers

<a href="tel:33-123-456-7891">

Pour envoyer un SMS

<a href="sms:12345678">

Pour envoyer un email

<a href="mailto:ray@ray.com?cc=ex@x.com,lisa@x.com&amp;subject=Sujet HTML5 sur Android!&ampbody=Je viens de tester!">

Code source

Le code source de l’application est disponible à cette url http://code.google.com/p/navray/source
Note : le source est géré sous Mercurial Hg . Pour ceux qui ne l’utilisent pas , le source peut être téléchargé à partir de navray_src_01.zip http://code.google.com/p/navray/downloads/list

Vous pouvez utiliser à différentes expérimentations, il ne reste plus qu’à modifier le contenu du dossier “assets”.

Si vous publiez une application à partir de ce source,  merci de modifier le nom de package Java. En effet le package sert d’identifiant pour une application publiée sur l’Android market.

La finalité est d’avoir sur toutes les plateformes mobiles (Android / Iphone / Windows Phone 7) une application permettant de gérer des projets de façon agile suivant la méthode Scrum.

Contexte

A l’origine, ce projet a été imaginé comme une plateforme de montée en compétence des consultants tant au niveau développement mobile qu’au niveau de l’utilisation du cloud. Il était donc au départ sous la forme de projet POC. Le choix du sujet s’est fait de façon naturelle, l’agilité étant la pierre angulaire de Valtech. Fort de son expertise dans ce milieu, les besoins ont été identifiés et traités comme tels. Le constat était le suivant : Les équipes agiles n’étant pas forcément géographiquement proche, et la plupart des scrum masters souvent en déplacement, un outil de “liaison” serait plus que bienvenue pour que la gestion des projets soit optimale.
(more…)

Valtech était à Devoxx 2010, une longue semaine de travail et de discussion et un retour d’Anvers fatiguée mais bourrée d’idées.

Tout d’abord félicitations à Stephen Janssen et à l’équipe de Devoxx : un cinéma avec des fauteuils confortables, une logistique pour 3 000 personnes, des conférences intéressantes sur des sujets variés et la retransmission sur Parleys pour que ceux qui n’ont pas fait le déplacement puisse profiter des meilleures présentations.

Devoxx 2010, c’est un programme quotidien très chargé (5 jours de 9h30 à 22h pour les plus assidus et jusqu’à 6 salles en parallèles) donc énormément de sujets et je ne reviendrai pas sur tout en détail.

C’est aussi beaucoup de discussions entre les sessions et plus tard en soirée sur les langages, notre métier et diverses choses qui font que des réseaux se forment.

Que contenait la fournée 2010 ?

D’abord les annonces officielles d’Oracle sur Java EE 6 et Java SE 7 ainsi que sur le devenir d’Open JDK. Open JDK restera et Java sera plus simple, plus pratique et plus facile à utiliser. Plusieurs présentations JPA/Hibernate viennent compléter ce tableau. Les évolutions les plus attractives de Java SE comme le projet Lambda (langage fonctionnel) ou le projet Jigsaw (modularité et gestion des dépendances) sont reportés à Java SE 8. La vie semble reprendre après une période difficile.

Un gros thème NoSql cette année, même si ça n’est pas strictement du Java. Cloudera (Hadoop, HBase), Cassandra, MongoDB, Infinitest et plusieurs grands site Web utilisateurs de bases NoSql avaient fait le déplacement. Des présentations assez inégales mais qui donnaient l’opportunité aux développeurs Java de découvrir cet univers. Dans ce thème aussi une présentation très intéressante des fondamentaux du cache distribué et Ehcache The essence of Caching.

Autre gros thème cette années, les interfaces utilisateur avec des sujets sur Android, HTML5 et Flex avec la même préoccupation qui revient constamment “On n’est pas obligé de faire des IHM moches avec Java”. Une très belle présentation de Romain Guy et Chet Haas Dive into Android avec du code en live et des explications sur le graphisme avec Android.

Bien sûr quelques sujets sur les fondamentaux Java sur les bonnes pratiques du développeur, avec un zeste de Cloud cette année? J’ai un peu zappé car d’autres sujets mon plus intéressé mais j’ai un peu regretté de n’avoir pu accéder à aucune  des présentations de Joshua Bloch (Effective Java, Java Puzzle), trop de monde à chaque fois. Un peu de Scala et de Groovy/Grails mais les langages n’étaient pas très représentés.

Dans  les présentations plus processus une mention spéciale pour From Dev/Ops to DevOps. Amazing the difference one character can make (en photo). DevOps est un mouvement émergeant qui vise à rapprocher les équipes de développement et les opérations (la production en français) pour mieux résoudre les problèmes de déploiement et de suivi de production. Le sujet avait aussi été abordé au CITCON en relation avec le Continuous Deployment (aussi présent à Devoxx mais on doit faire des choix vu le nombre de sujets et je ne l’ai pas vue). On en reparlera !

Et pour finir un peu d’humour les derniers jours avec les enregistrements Live des podcasts Java Posse et Les Cast Codeurs.

On attend avec impatience l’édition 2011, mais en attendant voilà des dizaines de pistes à explorer avant l’années prochaine.

Nous organisons une demi-journée centrée sur des sujets techniques pour les consultants de Valtech Technology le jeudi 21 octobre prochain. Ce sera l’occasion de discuter des sujets les plus pointus en toute convivialité.

Le programme est constitué d’un peu de Cloud Computing mélangé à du NoSQL, des retours d’expériences de migration JavaEE vers le Cloud et .Net vers Azure avec nos collègues de Valtech Toulouse suivis d’ateliers sur la mobilité (workshop, coding en groupe, etc.).

On se régale déjà à l’idée de vous faire vivre ce rendez-vous par notre compte twitter. On ne manquera pas aussi de faire un billet plus détaillé sur la rencontre.

Consultez nos postes à pourvoir si vous souhaitez nous rejoindre !

Crédits photo: Tous droits réservés par valtech103grenelle

Parmi les nombreuses fonctionnalités du SDK d’Android il existe un service de synthèse vocale qui vous permet de faire dire à votre téléphone ce que vous voulez dans plusieurs langues.
Les applications Android peuvent facilement tirer parti de cette API afin d’aider les personnes mal ou non voyantes, ou lire à voix haute un SMS qui arrive lorsque vous conduisez votre voiture par exemple.
Dans cet article nous allons nous intéresser à la mise en œuvre d’une petite application de robot parleur qui dit dans la langue choisie un message saisi au clavier.

Architecture logique

L’application est composée d’une activité principale proposant une IHM pour saisir le texte, et d’une activité secondaire accessible depuis un menu d’options, permettant de modifier les réglages de notre application.
Les constantes de l’application sont centralisées dans l’interface Constants, tandis que les fonctions de synthèse vocale sont encapsulées dans la classe Tts.
Des fichiers de ressources sont utilisés pour définir l’IHM de l’application (layout main.xml), le menu d’options (options_menu.xml) et les différentes options de réglages (settings.xml).
Tous les textes de l’application sont externalisés dans values/strings.xml, c’est la ressource utilisée par défaut; pour une version bilingue il suffit de créer une ressource values-fr/strings.xml avec les textes en français.
En somme, une organisation classique pour une application Android.

Manifeste de l’application :

< ?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="1" android:versionName="1.0" package="com.programmez.android.speechbot">
  <application android:icon="@drawable/icon" android:label="@string/app_name">
    <activity android:name=".App" android:label="@string/app_name">
      <intent -filter>
        <action android:name="android.intent.action.MAIN"/>
        <category android:name="android.intent.category.LAUNCHER"/>
      </intent>
    </activity>
    <activity android:name=".Settings"/>
  </application>
  <uses -sdk android:minSdkVersion="4" android:targetSdkVersion="7"/>
</manifest>

Activité principale et IHM

L’interface de l’application est constituée d’un titre, une invite à saisir, une zone d’édition et un bouton pour lancer la synthèse vocale.

L’activité principale est prise en charge par la classe App, qui affiche le layout et gère les interactions avec l’utilisateur :
• La première fois que l’utilisateur lance l’application un texte par défaut lui est proposé (« Bonjour !»)
• Chaque fois que le texte est modifié, il est sauvegardé et remplacera le texte par défaut pour les prochains lancements de l’application.
• Lorsque l’utilisateur clique sur le bouton « Parler », l’activité lance la synthèse vocale.
• Un menu d’options est accessible via la touche « menu » du téléphone, avec la possibilité d’accéder aux réglages ou quitter l’application. (more…)

Le SDK d’Android propose un modèle de composants et des APIs pour gérer différents dispositifs qui font la particularité des plateformes mobiles : connectivité, capteurs, téléphonie, multimédia …
Dans cet article nous allons nous intéresser à la détection d’événements liés à la téléphonie et la géolocalisation.

Un modèle de composants adapté

L’activité est le premier composant essentiel permettant de gérer le cycle de vie d’une application et l’interactivité avec l’utilisateur ; mais qu’en est-il lorsqu’on souhaite exécuter un traitement en tâche de fond, qui démarre automatiquement, et qui doit réagir à des événements externes comme un appel téléphonique ? Le framework propose pour cela des composants de type service et receiver qui utilisent des intentions (Intent) pour collaborer.

Les services : pour des traitements en tâche de fond

Le service peut être vu comme une activité à longue durée de vie (potentiellement infinie), en tâche de fond, et privée d’IHM; il est implémenté par une classe qui doit étendre android.app.Service.
Démarrage du service : à la différence d’une activité, l’utilisateur ne dispose pas de raccourci dans son bureau, il faudra donc démarrer le service explicitement de manière programmatique (souvent depuis une activité).
Les services d’une application doivent être déclarés dans son manifeste :

  <application android:icon="@drawable/icon" android:label="@string/app_name">
    <activity .../>
    <service android:name=".Service" />
  </application>

Un service peut, comme une activité, enregistrer des écouteurs spécialisés (listeners) pour obtenir des informations sur un capteur particulier, il est alors responsable du désenregistrement des listeners.

Receiver : un déclencheur léger

Le receiver est un composant susceptible de recevoir des intentions exprimées par le système Android ou d’autres applications. Les intentions symbolisent des requêtes (ou souhaits) et sont orchestrées par le framework ; cela offre un cadre simple et générique qui fait penser au style d’architecture REST (ou au Web), et confère un niveau d’abstraction intéressant pour faciliter l’intégration de composants. (more…)

Et une de plus ! Après le métronome, le slideshow et les quiz, Olivier Penhoat a produit une nouvelle application Android. SMS Speaker permet tout bonnement de lire à voix haute les SMS. Ceci en fait une appli très pratique pour les personnes visuellement déficientes ou tout simplement pour celles qui souhaitent prendre connaissance de leurs SMS sans quitter la route des yeux.

- Basé sur le module TTS (Text to Speach) intégré à Android, SMS Speaker lit les messages dans la langue de votre choix (par défaut celle du téléphone)
- Il conserve les SMS reçus et les relit
- Il reconnait l’expéditeur si celui-ci figure dans le carnet d’adresse
- Il s’exécute en tâche de fond

SMS Speaker nécessite au minimum la v 1.6 d’Android.

Cette application est téléchargeable gratuitement par terminal Android muni d’un lecteur de flashcode sur notre site Web. Pour la petite histoire, SMS Speaker a déjà été téléchargé près de 700 fois en… 6 jours.

Suite au communiqué de presse annonçant la sortie de la formation et du séminaire Android publié il y a une semaine, Olivier Penhoat, consultant et formateur chez Valtech Training, a été contacté par l’équipe de BFM. Il a enregistré hier au soir une interview pour l’Atelier Numérique. Celle-ci sera diffusée samedi 30/01 de 16h à 18h et rediffusée dimanche 31/01 de 21 à 23 heures. Le podcast sera ensuite mis en ligne quelques jours plus tard sur le site de BFM.

Mise à jour du 01/02/10 : le podcast est maintenant en ligne. Il est à écouter dans la tranche 17h-18h sous le titre “Passion selon Saint Net : Les systèmes d’exploitation sur mobile: quel navigateur ‘parfait’ sur mobile ?“