iD.apps en route pour la WWDC

iD.apps envoie cette année deux de ses meilleurs Experts iOS à la fameuse WWDC d’Apple. Cette conférence est le point d’orgue de l’année pour les Développeurs iOS. On y attend à chaque fois des annonces importantes autant pour les utilisateurs des périphériques Apple que pour les créateurs d’applications.

Voyons qui sont ces Experts et quelles sont leurs attentes pour cette conférence.

F93B8C88-C174-46D1-AA80-07DFE0D09DE5  François-Xavier Payet      Architecte iOS iD.apps      Twitter

nBPdMR8_  David Douard      Lead Developer iOS     Twitter

Pourriez-vous rapidement vous présenter et nous indiquer votre rôle au sein d’iD.apps ? 

FXP : Je m’appelle François-Xavier Payet, et je suis Expert technique iOS chez iD.apps depuis la création de la société. Attiré très tôt par les nouvelles technologies, j’ai commencé à utiliser les produits Apple au début des années 80 avec l’Apple. Loin d’être cantonné aux technologies Apple, je m’intéresse à tout ce qui touche de près ou de loin à l’informatique, des objets connectés aux supercalculateurs.

DD : Je m’appelle David Douard, je suis Développeur sur iOS chez iD.apps. Je suis passionné de nouvelles technos et forcément de tout ce qui touche de près ou de loin à l’environnement Apple. Cela fait maintenant 4 ans que je développe sur iOS et loin d’avoir fait le tour de la techno, mon expérience me permet aujourd’hui de prendre du recul et de mieux appréhender les challenges techniques.

Que représente pour vous la WWDC ? 

FXP : La WWDC est depuis de nombreuses années l’occasion pour Apple de présenter de manière privilégiée ses nouvelles technologies logicielles aux Développeurs. Elle a en fait deux aspects :

  1. Une discussion avec les Développeurs, permettant d’avoir leurs retours sur les plateformes Apple, ainsi que de les former aux nouvelles technologies proposées par Apple. Cet aspect n’est bien sûr pas altruiste ; former au plus tôt les Développeurs permet à Apple de s’assurer que ces nouveautés seront très vite implémentées, dès la sortie des produits.
  2. Une keynote d’ouverture présentant au grand public les nouveautés logicielles, et dans certains cas matérielles, des mois à venir.

Le deuxième point à pris énormément d’importance depuis qu’Apple ne participe plus aux différents salons, y compris ceux réservés aux produits Apple. Ces keynotes ont été popularisées par Steve Jobs, l’ancien CEO et co-fondateur d’Apple, qui savait tenir en haleine son audience, et livrait un véritable One Man Show.
Bien que ces keynotes soient moins spectaculaires depuis que Steve Jobs a quitté la direction d’Apple, elles restent un moment attendu par tous les afficionados d’Apple. La keynote de la WWDC est traditionnellement, depuis 5 ans, dévolue à la présentation de la version d’iOS à venir pour la fin de l’été, ainsi que sur les nouveautés à venir dans OS X.

Le second point est directement lié au premier. En effet, à l’heure actuelle, nous ne connaissons pas la moité du contenu des sessions de formation qui seront proposées par Apple. Et pour cause, la majorité de ces sessions auront pour thème des nouveautés qui auront été présentées à la keynote d’ouverture le 2 juin.

La WWDC permet également aux Développeurs de rencontrer directement les ingénieurs Apple lors de labs, pour discuter avec eux de leurs problèmes spécifiques.

DD : La WWDC c’est un peu la grand-messe annuelle d’Apple. C’est un des moments qu’Apple choisit pour présenter ses nouvelles technos. Nouvelles machines, nouveaux OS, comme toujours on attend la “révolution”. Chaque année, c’est la même ferveur. On en attend tellement qu’on est souvent déçu malgré de véritables bonnes annonces! Pas évident pour Apple de changer le monde tous les ans 😉

La WWDC, c’est aussi une semaine de conférences et de labs pour en apprendre davantage sur les nouveautés annoncées et surtout pour les mettre en œuvre. C’est un moyen pour Apple de s’assurer de la présence de ces nouveautés sur les Stores d’applications dès leur sortie publique quelques mois plus tard.

Quelles sont les annonces les plus attendues/espérées à la WWDC côté consommateur ?

FXP : Il faut bien garder en mémoire que la WWDC concerne en majorité les nouveautés logicielles. Il est clair que ce que le consommateur attend le plus est la présentation d’un nouvel iPhone, plus grand. On peut dire avec certitude que ce nouvel iPhone ne sera pas présenté à la WWDC, il ne le sera qu’à la fin de l’été.
Les annonces très intéressantes pour le consommateur, selon les dernières rumeurs, devraient principalement porter sur HealthBook, un nouveau module d’iOS, ainsi que sur la domotique.
La présentation d’HealthBook est quasiment acquise à la vue du nombre de fuites ayant eu lieu depuis le début de l’année. HealthBook est en fait un passeport santé dans l’iPhone qui permettrait de suivre ses activités sportives, sa pression sanguine, son rythme cardiaque …
La présentation d’une solution de domotique est beaucoup moins certaine, étant donné que les rumeurs sur ce dossier sont assez faibles. Néanmoins une entrée d’Apple dans ce domaine aurait clairement du sens. Si Apple le fait aussi bien que tous ses autres produits, il est possible que, comme pour la micro-informatique dans les années 70, l’audio personnelle au début des années 2000, et la téléphonie à la fin des années 2000, Apple révolutionne encore un nouveau segment de marché!

Et il y aura bien sûr des annonces que personne ne peut attendre! Attention néanmoins à ne pas porter ses espoirs trop hauts : Apple ne peut pas révolutionner le monde tous les ans.

DD : Coté consommateur évidemment, tout le monde veut en savoir plus sur le prochain iPhone! On est quasiment sûr qu’il sera plus grand, plus large pour se rapprocher des derniers smartphones Android! Pour en utiliser régulièrement c’est vrai que les grands écrans des derniers Nexus sont un vrai confort. Alors il ne faut pas rêver, on ne saura rien ou presque sur le prochain iPhone 6. Ils sont habituellement annoncés courant septembre. Par contre il est quasiment acquis qu’iOS 8 sera annoncé et il sortira dans quelques mois, en même temps que le prochain iPhone. Nous pouvons donc espérer qu’en analysant les nouveautés du nouvel iOS on en apprenne plus sur le prochain smartphone!

En tant qu’Experts iOS sur quoi se portent le plus vos attentes ? Sur quels domaines souhaitez-vous renforcer votre expertise grâce à la WWDC ?

FXP : En tant que Développeur iOS, mes attentes portent bien sûr sur les nouvelles API qu’Apple pourrait présenter pour les Développeurs.
Il est évident que depuis quelques années, Apple a perdu l’avance qu’il avait sur les fonctionnalités fournies par Android. On reproche beaucoup la fermeture de l’écosystème Apple. Bien qu’il soit faux que l’écosystème soit fermé, ce qui est vrai est que l’OS en lui même est extrêmement verrouillé. Cet aspect a un avantage : il n’y a pas de virus sur iOS, et la plupart des failles critiques sont d’une part plus rares, et d’autre part moins graves que sur les systèmes concurrents.
En contrepartie, les utilisateurs eux-mêmes commencent à voir certaines limites de ce système. Ainsi, le système de partage sur les réseaux sociaux d’Android mériterait d’être copié sur iOS. On croise les doigts pour cette année.
Autre chose que j’attends avec impatience, même si les chances de le voir cette année sont extrêmement faibles, pour ne pas dire nulles, serait de pouvoir choisir ses applications par défaut (navigateur, client mail, …). Cette fonctionnalité amènerait beaucoup plus de poids aux applications que l’on développe.
Enfin, il y a une fonctionnalité que nous avons de grandes chances de voir, à savoir, la communication inter-applications. Aujourd’hui, à part certains cas très particuliers (comme l’audio ou l’échange de fichiers), il est très difficile pour deux applications de communiquer entre elles. Cela devrait changer cette année et je suis impatient de voir comment!

Au delà des nouveautés logicielles, le gros plus pour nous, Développeurs, est bien sûr les sessions de développement. Ayant déjà participé aux Tech Talks de Londres, je sais à quel point elles sont intéressantes, et qu’elles nous feront gagner énormément de temps sur l’apprentissage des nouvelles technologies. Les labs quant à eux nous permettront de répondre aux questions potentiellement bloquantes que nous avons.

DD : On sait qu’un nouvel OS pour les Mac va être annoncé, sûrement des nouveautés hardware, mais ce qui nous intéresse le plus c’est le prochain iOS, iOS 8 en l’occurrence. Après la petite révolution graphique d’iOS 7 qui nous a donné pas mal de travail l’année dernière, cette fois on s’attend surtout à des nouveautés fonctionnelles. Chaque sortie d’une nouvelle version d’iOS est un véritable évènement pour la communauté de Développeurs, souvent un challenge comme faire fonctionner une application sur deux ou trois OS différents, n’est pas simple mais c’est très stimulant.  Et c’est aussi cela qui fait que développer dans la mobilité et particulièrement sur iOS est passionnant. On a hâte de voir ce que le prochain système d’exploitation d’Apple sait faire! Durant cette semaine de conférences, différents ateliers pratiques vont nous permettre de mettre en œuvre les nouvelles API  afin d’explorer les nouvelles possibilités qu’offre l’OS. C’est un peu comme retourner à l’école pour une semaine : cour magistral, puis TP!

Le but de cette WWDC c’est aussi de confronter notre vision à celle des autres Développeurs et même à celle des ingénieurs Apple. Comme dans tous les métiers, on acquiert des automatismes, des habitudes, on ne se pose même plus la question sur la manière d’implémenter certaines choses et pourtant les autres font peut être différemment! Il y a forcement des choses auxquelles on ne pense pas des contournements et même carrément des API qu’on ne pense pas à utiliser et qui pourtant peuvent nous apporter beaucoup. J’espère me dire souvent lors de cette semaine de conférences : “Mais oui mais évidemment, pourquoi n’y ai-je pas pensé avant!”.

Comment comptez-vous faire profiter les collaborateurs iD.apps des informations et du savoir-faire technique acquis lors de cette conférence ?

FXP : Le contenu de la WWDC est très dense, et il n’est pas possible à deux, d’assister à toutes les sessions. Nous avons donc déjà mis en place des outils permettant de communiquer avec les équipes d’iD.apps pour choisir ce à quoi nous allons participer. Chaque Développeur d’iD.apps ayant le même poids, chacun vote pour les sessions qu’il ou elle souhaite que nous allions voir, et David et moi ferons notre emploi du temps en fonction. La plus grosse partie de l’emploi du temps sera bien sûr réalisée lundi après-midi, lorsque le contenu des sessions sera connu.

Nous avons également mis en place un tableur partagé afin de pouvoir regrouper les questions à poser aux ingénieurs Apple.

Nous partagerons ensuite au fur et à mesure des journées nos notes directement avec les collaborateurs, et organiserons une réunion de présentation à notre retour en France.

DD : Notre rôle là-bas va surtout être de faire du tri! Il sera impossible de tout suivre, certaines conférences ont lieu en même temps que d’autres, certains labs durent toute la journée etc…

Nous avons déjà demandé aux collaborateurs quelles étaient les conférences / labs qu’ils souhaitaient voir. Puis nous leur avons demandé de nous lister des questions, et des cas pratiques qui nous serviront de support lors des labs. Toutes les vidéos des conférences seront disponibles sur l’application de la WWDC, nous serons là pour dire : “regardez ça, c’est intéressant!”.

Parallèlement, nous partagerons nos prises de notes et nos exemples de code afin de synthétiser les points les plus importants pour mieux appréhender l’arrivée du nouvel OS en septembre.

Au delà de l’aspect technique, nous avons la chance d’aller à San Francisco! Croiser le gratin de la Silicon Valley, voir le lieu de naissance d’Apple, FaceBook, Google… on en profitera pour décrire un peu l’ambiance sur place, mettre quelques photos. Un voyage initiatique pour les Développeurs que nous sommes.

 A bientôt sur le blog alors ?  

DD : Si vous n’êtes pas à la WWDC, ce blog est “the place to be” 🙂

Ok Glass, when is the next Bus ?

iD.apps étudie depuis quelques temps déjà le développement pour les Google Glass.

Nul besoin de présenter les Google Glass (si c’est le cas aller voir ici), en revanche le développement sur les Glass est un peu moins connu. Nous vous proposons donc un exemple concret de développement sur les Glass. Pour comprendre tous les points techniques, des connaissances en développement Android sont conseillées.

Pour rappel, d’un point de vue technique, les Google Glass sont un smartphone Android embarqué dans un prisme équipé des principaux capteurs suivants :

  • Une caméra;
  • Un micro;
  • Un accéléromètre/gyroscope (pour le mouvement de la tête);
  • Un capteur de luminosité;
  • Une surface tactile : la branche droite des Google Glass.

Les Glass sont connectées à internet soit via la connexion de votre smartphone qu’elles exploitent par bluetooth, soit directement via wifi.

Cet article vous décrit la mise en oeuvre d’une application utilisant la reconnaissance vocale, la caméra et la connexion internet. Celle-ci permet de récupérer les horaires des prochains bus rennais d’un arrêt. Pour cela nous allons nous appuyer sur les données ouvertes qui fournissent en temps réel les temps d’attente aux arrêts. Enfin pour identifier les arrêts nous allons nous appuyer sur les QR Codes qui sont affichés dessus.

Concrètement, au lancement de l’application l’utilisateur est dirigé sur une vue affichant ce que capte la caméra. Cela, afin de lui permettre de viser le QR code à scanner. Sur cette vue,  l’utilisateur scanne le QR code en prenant une photo de celui-ci par une action de tap. Lorsqu’il a scanné le QR code, et que celui-ci est détecté, l’utilisateur est dirigé sur une LiveCard ajoutée à la timeline des Glass. Sur cette Livecard l’utilisateur voit les horaires des prochains bus.

Pour développer cette application, nous nous appuyons sur le site de développement Google Glass (Glass developpement overview) et sur les références Android.

Avant toute chose

Le développement sur Google Glass se fait dans un environnement Android. Il est donc nécessaire d’avoir un SDK à jour jusqu’à la version Android 4.4.2 (API19) ainsi que le Glass Development Kit Preview (cf. Quick Start). Lors de la création d’un projet pour Glass il faut régler la version cible du SDK et la version minimum de celui-ci sur la version 19 de l’API. C’est la seule supportant le GDK Preview. Ensuite, pour la compilation, il faut régler le paramètre de compilation sur GDK Preview. Il est aussi conseillé d’enlever toutes indications de thème.

Lancer une application sur Google Glass

Toute application sur Google Glass doit commencer par une commande vocale. La création de celle-ci permet aussi un accès à l’application via le menu principal des Glass accessible en utilisant le touch pad. Les commandes vocales utilisables sont limitées aux commandes officielles (VoiceTriggers). Si aucune des commandes ne correspond à ce dont vous avez besoin, il est possible d’en faire enregistrer une nouvelle mais cela prend du temps et elle doit être conforme à la checklist de Google (VoiceTrigger checklist). Il est donc conseillé d’entamer les démarches très tôt si vous voulez que votre GlassWare puisse être disponible sur le store MyGlass. Toutefois, il est aussi possible d’autoriser ses propres commandes dans le manifeste pour des besoins de développement ; c’est  ce que nous utilisons actuellement.

Pour ajouter une commande personnalisée, il faut d’abord ajouter une string en ressource pour définir le nom de la commande vocale.

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <string name="glass_voice_trigger">When is the next bus ?</string>
</resources>

Ensuite, il faut créer une ressource xml dans res/xml/<ma_commande_vocale>.xml, dans laquelle on ajoute une composante trigger avec un attribut keyword référençant la ressource string définie plus tôt.

<?xml version="1.0" encoding="utf-8"?>
<trigger keyword="@string/glass_voice_trigger"/>

Si la commande vocale est une commande déjà enregistrée, correspondant à une Voice Triggers, l’attribut n’est plus keyword mais command (pour plus d’information cf. Starting Glassware). Ensuite, il faut enregistrer, dans le manifeste, l’intention associée à la commande vocale et autoriser la commande.

<activity | service ...>
        <intent-filter>
            <actionandroid:name=
                    "com.google.android.glass.action.VOICE_TRIGGER"/>
        </intent-filter>
        <meta-dataandroid:name="com.google.android.glass.VoiceTrigger"
            android:resource="@xml/ma_commande_vocale"/>
    </activity | service>
<uses-permission
     android:name="com.google.android.glass.permission.DEVELOPMENT"/>

When is the next bus ? icon

Une fois l’application installée sur les Glass, vous devriez voir une nouvelle commande vocale et une nouvelle application dans le menu d’applications.

Scanner un QR code avec des Google Glass

Maintenant que nous pouvons lancer notre application, nous devons pouvoir scanner le QR code présent sur l’arrêt de bus.

La prise de photo avec les Glass peut se faire de deux façons : soit avec l’activité native Google Glass qui ne permet pas d’aperçu, soit grâce à la Camera API d’Android qui permet de fonctionner de la même façon qu’une application photo sur un smartphone Android.

Ici, une preview nous semblait nécessaire et devait donner la possibilité à l’utilisateur de viser le QR code à scanner avec la caméra intégrée. Pour cela, on crée donc un SurfaceHolder pour afficher cette preview.

private final SurfaceHolder.Callback mSurfaceHolderCallback =
              new SurfaceHolder.Callback() {

	@Override
	public void surfaceCreated(SurfaceHolder holder) {
		try {
			mCamera.setPreviewDisplay(holder);
			mCamera.startPreview();
		} catch (IOException e) {
			e.printStackTrace();
		}
	}

	@Override
	public void surfaceDestroyed(SurfaceHolder holder) {
		// Nothing to do here.
	}

	@Override
	public void surfaceChanged(SurfaceHolder holder, int format, int width,
			int height) {
		// Nothing to do here.
	}
};

Attention, lors de l’utilisation intensive de la caméra des Glass veillez à bien libérer celle-ci après avoir pris une photo pour éviter de bloquer les Glass.

private void releaseCamera() {
	if (mCamera != null) {
		if (mSurfaceHolderCallback != null) {
			mPreview.getHolder().removeCallback(mSurfaceHolderCallback);
			mCamera.release();
		}
	}
}

Ensuite, si vous souhaitez la réutiliser, il faut réinitialiser complètement la caméra.

Ici, nous avons besoin d’effectuer un zoom pour pouvoir scanner un QR code sans que l’utilisateur soit obligé de coller sa tête devant.

private void initCamera() {
	mCamera = getCameraInstance();
	mPreview.getHolder().addCallback(mSurfaceHolderCallback);
	Camera.Parameters parameters = mCamera.getParameters();
	int maxZoom = parameters.getMaxZoom();
	if (parameters.isZoomSupported()) {
		if (mCamera.getParameters().getZoom() >= 0
				&& mCamera.getParameters().getZoom() < maxZoom) {
			int i = maxZoom / 2;
			parameters.setZoom(i);
		} else {
			// zoom parameter is incorrect
		}
	}
	mCamera.setParameters(parameters);
}

Ainsi, après avoir initialisé la preview et saisi la caméra, nous pouvons effectuer un takePicture et définir les opérations de CallBack nécessaires à la prise de photo proprement dite. Nous n’avons utilisé que le CallBack JPEG dans lequel nous affichons le résultat de la prise de photo avant de scanner l’image à la recherche du QR code. Enfin nous démarrons la LiveCard permettant d’afficher les horaires des prochains bus.

private final PictureCallback mJPEGCallback = new PictureCallback() {

	@Override
	public void onPictureTaken(byte[] data, Camera camera) {

		mPreview.setVisibility(View.GONE);
		BitmapFactory.Options options = new BitmapFactory.Options();
		options.inSampleSize = 5;

		mPicture = BitmapFactory.decodeByteArray(data, 0, data.length,
				options);
		mImageTaken.setImageBitmap(mPicture);
		mImageTaken.setVisibility(View.VISIBLE);

		String result = scanQRCode(data);

		if (!TextUtils.isEmpty(result)) {
			Toast.makeText(ScanQrCodePictureActivity.this, result,
					Toast.LENGTH_SHORT).show();
			Intent startPublishIntent = new Intent(
					ScanQrCodePictureActivity.this,
					PublishScheduleIntoLiveCardService.class);
			startPublishIntent.putExtra(Poc_Horaires_Constants.URL, result);
			startService(startPublishIntent);
		} else {
			Toast.makeText(ScanQrCodePictureActivity.this,
					getString(R.string.detection_failed),
					Toast.LENGTH_SHORT).show();
		}
		releaseCamera();
		finish();
	}
};

Un scan avec le scanner Zbar ne se fait que sur une image au format Y800.

private String scanQRCode(byte[] data) {
	Bitmap imageRes = BitmapFactory.decodeByteArray(data, 0, data.length);
	String symbol = null;
	int width = imageRes.getWidth();
	int height = imageRes.getHeight();
	int[] pixels = new int[width * height];

	imageRes.getPixels(pixels, 0, width, 0, 0, width, height);
	Image qrcode = new Image(width, height, "RGB4");
	qrcode.setData(pixels);

	int result = mScanner.scanImage(qrcode.convert("Y800"));

	if (result != 0) {
		SymbolSet syms = mScanner.getResults();
		for (Symbol sym : syms) {
			symbol = sym.getData();
		}
	}
	return symbol;
}

Les horaires de bus dans une LiveCard

Le résultat du scan du QR code se présente sous la forme d’une URL de laquelle on extrait le numéro de l’arrêt. Celui-ci nous sert ensuite dans l’appel à l’API Keolis. Dans notre application, l’extraction, l’appel à l’API et l’affichage du résultat se font dans un service qui va mettre à jour une LiveCard au travers d’une RemoteView.

Une LiveCard est une carte Google Glass donnant des informations pertinentes dans l’instant. Les LiveCards se placent dans la Timeline à gauche de l’écran d’accueil des Glass et sont régulièrement mises à jour pour le temps où leur utilisation est pertinente.

private LiveCard mLiveCard;
private RemoteViews mLiveCardView;
...
public int onStartCommand(Intent intent, int flags, int startId) {
	if (mLiveCard == null) {
		
		URL = intent.getStringExtra(Poc_Horaires_Constants.URL);
		busStop = extractBusStop(URL);

		mLiveCard = new LiveCard(this, LIVE_CARD_TAG);
		mLiveCardView = new RemoteViews(getPackageName(),
				R.layout.service_live_card);
		...
		mLiveCard.publish(PublishMode.REVEAL);

		// Queue the update text runnable
        mHandler.post(mUpdateLiveCardRunnable);
	}
	return START_STICKY;
}

La mise à jour de notre LiveCard se fait via un thread qui va appeler l’API Keolis au travers de Retrofit toutes les minutes. Retrofit permet de transformer une interface java en objet permettant l’appel d’une API REST.

public interface KeolisApiCalls {
	@GET("/?cmd=getbusnextdepartures")
	void getHoraires(@Query("version") String version,
			@Query("key") String key, @Query("param[mode]") String mode,
			@Query("param[stop][]") String stop, Callback<OpenData> cb);
}

Interface permettant de faire appel à l’API Keolis dans notre application.

private RestAdapter mKeolisRestAdapter;
private KeolisApiCalls mKeolisApiCalls;
...
public void run() {
	if (!isStopped()) {

		mKeolisRestAdapter = new RestAdapter.Builder()
				.setEndpoint(KeolisApiCalls.ENDPOINT)
				.setConverter(new SimpleXMLConverter()).build();
		mKeolisApiCalls = mKeolisRestAdapter
				.create(KeolisApiCalls.class);

		Callback<OpenData> cb = new Callback<OpenData>() {
			@Override
				public void success(OpenData retour, Response qResponse) {
				String scheduleToDisplay = "";

				if (retour.getAnswer().getStatus().getCode() != 0) {
					scheduleToDisplay = ""
							+ retour.getAnswer().getStatus().getCode()
							+ " : "
							+ retour.getAnswer().getStatus()
									.getMessage();

					updateScheduleError(scheduleToDisplay);
				} else {
					updateSchedule(FormatBusSchedule
							.listSchedules(retour));
				}
			}
			...
		};

		mKeolisApiCalls.getHoraires(KeolisApiCalls.VERSION,
				KeolisApiCalls.API_KEY, Poc_Horaires_Constants.STOP,
				busStop, cb);

		// Queue another schedule update in 60 seconds.
		mHandler.postDelayed(mUpdateLiveCardRunnable, DELAY_MILLIS);
	}
}

Dans le thread de mise à jour de notre LiveCard, on initialise un objet de type RestAdapter implémentant l’interface Retrofit que nous avons définie. Cet objet permet d’appeler l’API Keolis. L’appel du WebService prend en paramètre une callBack dans laquelle nous récupérons le résultat de notre requête. Nous pouvons ensuite l’afficher dans notre LiveCard.

Et voilà, notre utilisateur sait quels sont les prochains passages de Bus à son arrêt.

Conclusion

Au travers de cette application, nous mettons en oeuvre un bon exemple de développement sur Google Glass.  On se familiarise ainsi avec l’utilisation de la caméra, des LiveCards, de Retrofit et enfin de Zbar. Vous pouvez constater que le développement sur Glass est très similaire à celui pour Android, du moins pour ce qui est du code, car pour les usages c’est une autre histoire que nous développerons dans de prochaines applications 😉

iD.apps lance son Blog

Avec près de 200 applications publiées sur les stores, iD.apps s’affirme au fil des années comme l’un des leaders français de la réalisation d’applications mobiles.

Ce leadership s’est construit  autour de notre savoir-faire et de nos valeurs, à savoir :

  • L’humain
  • L’expertise
  • L’innovation
  • La réactivité
  • Le sens de l’engagement

Quand bien même nos réalisations et nos références parlent en faveur de ce savoir-faire (références iD.apps), nous pensons qu’un blog permettra de le présenter d’une manière nouvelle et d’être créateur de valeur pour nos partenaires comme pour les communautés d’experts et de développeurs passionnés d’innovation mobile.

Ce blog a donc pour vocation de partager nos retours d’expérience sur les aspects techniques et moins techniques qui entrent en jeu dans ces projets complexes.

Chez iD.apps nous ne manquons pas d’idées et au fil des mois vous verrez apparaître sur ce site des articles variés comme :

  • Le développement sur les différentes plateformes ;
  • Des retours d’expériences projet ;
  • Des tests de nouveaux périphériques ;
  • Des tests de SDKs spécialisés mobiles ;
  • Des recommandations sur le design d’applications mobiles ;
  • etc.

Nous espérons que ce contenu saura retenir votre attention et parfois rendre aux communautés de développeurs un peu du savoir faire qu’elles nous ont permis d’acquérir (communautés open source notamment).

Let’s move forward with innovation

Bonne Lecture