Les présentations iD.apps de la Droidcon Paris 2014

La Droidcon Paris 2014 a eu lieu les lundi 22 et mardi 23 derniers.

iD.apps, sponsor de l’événement, y tenait un stand et animait 2 conférences.

En attendant les vidéos de ces présentations, bientôt mises à disposition par l’organisateur de l’événement (BeMyApp) nous mettons d’ors et déjà à disposition les supports et contenus de ces 2 présentations.

La première présentation de Guilhem Duché avait lieu lors des Barcamps et concernait les usages et la mise en oeuvre d’un micro serveur http embarqué dans une application Android.

Voici les slides :

Voici les projets open source associés :

https://github.com/guiguito/Cardeto

https://github.com/guiguito/AIRShare

https://github.com/guiguito/SlidesCast

La seconde présentation réalisée par Quentin Sallat était elle en grand format et expliquait les actions à prendre pour réaliser le passage d’Holo à Material Design, nouvelles Guidelines Design de la prochaine version de l’OS de Google : Android L.

Les slides :

Le projet open source associé :

https://github.com/Neferetheka/Steam-Explorer

Vous retrouverez le descriptif détaillé de celles-ci dans notre précédent article.

Nous vous mettrons les vidéos de ces conférences à disposition dès qu’elles arriveront.

 

Happy coding !

 

 

 

iD.apps sponsor de la Droidcon Paris 2014 les 22 & 23 septembre prochains

Cette année encore, iD.apps sponsorise la Droidcon Paris : l’événement dédié au développement Android.

iD.apps tiendra un stand afin de vous accueillir et vous présenter son activité. Un concours surprise vous y sera proposé vous permettant de gagner une SmartWatch Motorola 360. Enfin 2 experts Android d’iD.apps, Quentin et Guilhem animeront une conférence chacun.

Quentin Sallat

Quentin, expert Android chez iD.apps, vous proposera une conférence d’1 heure sur le passage d’Holo à Material Design.

Avec l’arrivée d’Android L, Google a décidé d’apporter à son OS mobile un nouvel ensemble de règles visuelles nommé Material Design. Mais il n’est pour autant pas nécessaire de changer intégralement le design de son application pour respecter ces nouvelles guidelines. 
Cette conférence vous montrera en direct comment passer de Holo à Material au travers d’une application. Du floating button aux cartes à la Google Now, en passant par les nouvelles APIs d’animation, vous saurez tout ce qui est nécessaire pour effectuer une transition en douceur.

A vos agendas : conférence mardi 23 septembre à 15h55

Guilhem Duché

Guilhem, responsable innovation et expert Android animera un Barcamp sur l’utilisation d’un microserveur http dans une application Android.

Certaines applications bien connues comme Airdroid proposent aux utilisateurs d’interagir avec leur application mobile depuis le navigateur de leur ordinateur de bureau. Ce Barcamp vous présentera comment utiliser ce type de fonctionnalité. Il évoquera les cas d’usage qui peuvent en découler et vous montrera en détail des cas d’implémentation concrets avec une application de partage et une application ChromeCast orientée données.

A vos agendas : Barcamp lundi 22 septembre à 14h20

Nous espérons vous voir nombreux à ces présentations et échanger plus longuement autour de nos experts Android sur le stand d’iD.apps.

A très bientôt!

 

Ok Glass, Treat an incident (2/2)

Following our previous article, we are still working on MBAAS and GPS guiding. In this article, we focus on retrieving the information saved in Parse and then talk about the geo-point search.

This time, we will talk about treating an incident already registered. First, we need to choose among the declared incidents, and then go to its location. To do that, we retrieve from Parse the ten closest incidents still in progress. When they are retrieved, the user can choose among them the one he wants to treat. He is then directed to a map displaying his current location and the incident location. On this view he can also access the incident description and a related picture. Then he can go through to a simple guiding screen. At this point, the user can only see the distance as the crow flies and the incident general direction. He can also access a map that shows his current location and the incident location. However, the map won’t actualize as the user moves.

This time the speech recognition understands what I said on the first trial. Oh, again don’t try to search for any car there is none.

Retrieve closest incident with Parse

Incident_retrieved

We begin our flow by searching for the ten closest incidents that are still in progress. Each of them is displayed in its own card as follow: in first its id, then its type and finally its creation date. The cards are bundled in a ScrollView as for the type choosing part in the report application. We also retrieve the first report and the incident picture. Since we cannot display them right away, we pass those to the next screen.

public void onLocationChanged(Location location) {
	// Called when a new location is found by the network location provider.
	mUserLatitude = location.getLatitude();
	mUserLongitude = location.getLongitude();

	mLocation = new ParseGeoPoint(mUserLatitude, mUserLongitude);

	ParseQuery<ParseObject> query = ParseQuery
			.getQuery(Poc_TreatAnIncident_Constants.INCIDENT_LOCATION);

	query.whereNear("location", mLocation);
	query.whereEqualTo(Poc_TreatAnIncident_Constants.INCIDENT_TREATED,
					false);
	query.setLimit(10);

	query.findInBackground(new FindCallback<ParseObject>() {

		@Override
		public void done(List<ParseObject> objects, ParseException e) {
			if (e == null) {
				Card card;
				mCards = new ArrayList<Card>();
				String _footer = "/" + objects.size();
				ParseObject po;

				for (int i = 0; i < objects.size(); i++) {
					card = new Card(IncidentSearchActivity.this);
					po = objects.get(i);
					mClosestIncidents.add(po);

					card.setText(dispalyIncidentInfo(po));
					card.setFootnote((i + 1) + _footer);
					mCards.add(card);
				}

				mCardScrollView = new CardScrollView(
						IncidentSearchActivity.this);
				IncidentTypeCardScrollAdapter adapter = new IncidentTypeCardScrollAdapter();
				mCardScrollView.setAdapter(adapter);
				mCardScrollView.setOnItemClickListener(mClickAdapter);
				mCardScrollView.activate();
				setContentView(mCardScrollView);
				mLocationManager.removeUpdates(mLocationListener);
			} else {
				Toast.makeText(IncidentSearchActivity.this,
						"Failed to retrieve incidents", Toast.LENGTH_SHORT)
						.show();
			}
		}
	});
}

Here, we retrieve the ten nearest incidents with findInBackground() with the query whereNear(). We specify that we only want the ten closest with setLimit().

Additional information: location, picture and description

incident_map

On this activity the user can see where the incident is located and he can consult its description by swiping backward. The picture of the incident is also available by swiping forward when the map is displayed. As in our previous application, the map comes from Google static maps. Here, we didn’t use a card because it doesn’t seem to be in any way able to display only an image, apart in background. On cards you can only have text, a background image or a mosaic of pictures on the left side of the card.

Direction with Glass

To guide the user to the incident scene, we chose to give only a general direction and the distance as the crow flies. To provide this guiding we have a mark that moves depending on the Glass camera orientation regarding the incident.

direction front When the user is heading in the rigth direction the mark moves from one side of the screen to the other in accordance to the incident direction. direction left When the direction to the incident isn’t in front of the user but on his left. direction right When the direction to the incident isn’t in front of the user but on his right.

Caution: the camera is located on the movable arm used to tune the angle of the prism. This might introduce a small difference regarding the real angle.

Provided with only this indicator, it would be pretty hard for the user to direct himself solely with this information. Thus, we provide him with the possibility to check his position. By swiping backward, the user can access a map where his current location and the incident location are displayed. As for all of our maps, this one is also a static one and will not be refreshed as the user is moving. It will only refresh when the user will check again his position.

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:id="@+id/orient"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context="com.example.orientingtest.DirectionActivity$PlaceholderFragment" >    
    <ImageView
        android:id="@+id/incident_on_left"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_alignParentLeft="true"
        android:layout_centerVertical="true"
        android:src="@drawable/mleft"
        android:visibility="gone" />

    <ImageView
        android:id="@+id/incident_on_right"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_alignParentRight="true"
        android:layout_centerVertical="true"
        android:src="@drawable/mright"
        android:visibility="gone" />

    <ImageView
        android:id="@+id/incident_in_front"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_alignParentLeft="true"
        android:layout_centerHorizontal="false"
        android:layout_centerVertical="true"
        android:src="@drawable/mfront" />
    
    <ImageView android:id="@+id/map_current_position"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:visibility="gone" />

    <TextView
        android:id="@+id/information"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_alignParentTop="true"
        android:layout_centerHorizontal="true"
        android:layout_marginTop="@dimen/card_margin"
        android:ellipsize="end"
        android:singleLine="true"
        android:text="@string/swipe_left_for_info"
        android:textAppearance="?android:attr/textAppearanceSmall" />
    
    <TextView
        android:id="@+id/distance"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_alignParentBottom="true"
        android:layout_centerHorizontal="true"
        android:layout_marginBottom="@dimen/card_margin"
        android:ellipsize="end"
        android:singleLine="true"
        android:text="@string/wait_result"
        android:textAppearance="?android:attr/textAppearanceSmall" />
</RelativeLayout>

At initialization, the default orientation is north. You need to move to refresh your real orientation. There can be some time before it properly refresh.

public void directionTo(double heading) {
	float bearing = MathUtils.getBearing(mUserLatitude, mUserLongitude,
			mIncidentLatitude, mIncidentLongitude);
	float differentialAngle = (float) (bearing - heading);

	if (differentialAngle < 0)
		differentialAngle += 360;

	// The view displays 90 degrees across its width so that one 90 degree head rotation is
	// equal to one full view cycle.
	float pixelsPerDegree = (mTipsContainer.getWidth() - 68) / 90.0f;

	double distancem = 1000 * MathUtils.getDistance(mUserLatitude,
			mUserLongitude, mIncidentLatitude, mIncidentLongitude);

	mTipsView.setText(mDistanceFormat.format(distancem) + " m");

	if ((differentialAngle >= 45 && differentialAngle <= 180)) {
		mLeftMark.setVisibility(View.GONE);
		mRightMark.setVisibility(View.VISIBLE);
		mMarkFront.setVisibility(View.GONE);
	} else if ((differentialAngle > 180 && differentialAngle <= 315)) {
		mLeftMark.setVisibility(View.VISIBLE);
		mRightMark.setVisibility(View.GONE);
		mMarkFront.setVisibility(View.GONE);
	} else if ((differentialAngle >= 0 && differentialAngle < 45)
			|| differentialAngle == 360) {
		mLeftMark.setVisibility(View.GONE);
		mRightMark.setVisibility(View.GONE);
		mMarkFront.setVisibility(View.VISIBLE);

		mMarkFront.setLayoutParams(positionL);
		RelativeLayout.LayoutParams pos = positionL;
		int margin = (int) (((mTipsContainer.getWidth() - 68) / 2) + (pixelsPerDegree * differentialAngle));

		pos.setMargins(margin, 0, 0, 0);
		mMarkFront.setLayoutParams(pos);
	} else if (differentialAngle > 315 && differentialAngle < 360) {
		mLeftMark.setVisibility(View.GONE);
		mRightMark.setVisibility(View.GONE);
		mMarkFront.setVisibility(View.VISIBLE);

		mMarkFront.setLayoutParams(positionL);
		RelativeLayout.LayoutParams pos = positionL;
		int margin = (int) ((pixelsPerDegree * (differentialAngle - 315)));

		pos.setMargins(margin, 0, 0, 0);
		mMarkFront.setLayoutParams(pos);
	}
}

If differentialAngle is between 0 and 180 degrees, the incident is on the left of the user. It is only true once we have normalize differentialAngle between 0 and 360 degrees.

Intent intent = new Intent(Intent.ACTION_VIEW);
intent.setData(Uri.parse("google.navigation:q=48.649469,-2.02579"));
startActivity(intent);

Instead of our rough guiding, it also would have been possible to give a turn by turn guiding but we wanted to test how the Glass handles direction and orientation by ourselves. This intent came from people analyzing the log of the Glass embedded command “Get direction”, so it might change in future updates, making this possibly not reliable (see How can I launch Directions from GDK).

Once the user is within ten meters from the incident, he can use a tap interaction to continue with the flow.

Picture and report after the incident is treated

After the incident is treated, the user must take a picture of the solved incident and issue a final report.  The user takes the picture as in the previous applications. He can preview it and retry until he is satisfied. In the same way, we use the speech recognition to record the user final report after the picture has been taken. We use the same implementation as for our previous application. The report and the picture are then saved in Parse with the saveInBackground() function.

Conclusion

With this application we have been able to test out the orientation sensor, alongside with the location providing features of Glass. We have also seen that it is really simple to retrieve data from Parse even with just a location constraint. The complexity is nicely hidden behind a nice and friendly function.

This article concludes our work on location and MBAAS. We will continue to work on Glass and we will come back to you when we have more to share.

Retour de WWDC (2/2) : Regard à froid sur les annonces

Le D de WWDC = “Developer”.

Tous les ans, durant la WWDC Apple présente à ses développeurs enregistrés les nouvelles API et fonctionnalités qu’ils pourront utiliser quelques semaines plus tard.

Il y a néanmoins un moment de la WWDC qui n’est traditionnellement pas réservé aux développeurs : la keynote d’ouverture. Cette dernière est l’occasion pour Apple de présenter à la presse ainsi qu’au grand public les nouveautés fonctionnelles des prochaines versions d’iOS et de OSX, ainsi que des principaux logiciels de la firme.
Bien que ce fût encore le cas cette année, cette keynote a eu un goût particulier pour les développeurs. En effet, plus du tiers de cette keynote leur était réservé. Alors que le grand public a regardé de façon étonnée, sans trop y comprendre grand chose, cette fin de keynote, pour les développeurs, l’excitation est tout de suite montée, et l’on pouvait s’attendre à un très grand cru 2014 de la WWDC. Vous trouverez dans cet article uniquement les nouveautés intéressant les développeurs iOS. Je n’évoquerai donc pas, ou très peu, les nouveautés concernant uniquement les utilisateurs (notifications interactives, App Preview, …).

Swift, bien sûr

L’annonce la plus importante de la keynote de la WWDC, pour les développeurs, fût bien évidemment l’arrivée de Swift : un langage de programmation entièrement nouveau.

swift-logo-hero

Pour comprendre le pourquoi de Swift, il faut faire un peu d’histoire. En 1996, alors qu’Apple est au bord du gouffre, la société rachète NeXT fondée par Steve Jobs, pour fournir un nouveau système d’exploitation aux Macintosh. NextSTEP, le système d’exploitation de NeXT évoluera vers Mac OSX, puis vers OSX. En plus de ce système d’exploitation, Apple récupère le langage utilisé pour toutes les API de NextSTEP : l’Objective-C.
L’Objective-C est, comme le C++, une surcouche du C. Il est donc compatible avec ce dernier. Il est en revanche beaucoup plus confidentiel que le C++. Bien que GCC et d’autres compilateurs populaires sachent très bien compiler du code Objective-C, aucun système d’exploitation, mis à part OSX et iOS, ne propose d’API Objective-C, cantonnant par la même l’Objective-C à l’écosystème Apple. L’Objective-C est de plus un langage à la syntaxe très particulière, et très éloignée de tout ce que les développeurs ont l’habitude de voir. Bien que les développeurs familiers avec Objective-C apprécient énormément cette syntaxe, elle pose un frein énorme à l’entrée vers la plateforme. En effet, il est beaucoup plus facile de former, par exemple, un expert Java vers le C++ (ou vice-versa) que vers l’Objective-C. L’Objective-C porte également le poids de son héritage : le C, langage développé dans les années 70, dont il ne peut se défaire, malgré de nombreuses lourdeurs telles qu’une gestion problématique du multi-thread, une gestion complexe et entièrement manuelle de la mémoire, un typage faible, …
Depuis plusieurs années, Apple travaille à corriger ces derniers points en masquant la complexité du C aux développeurs, avec par exemple Grand Central Dispatch pour la gestion du multithread, ou l’Automatic Reference Counting pour la gestion de la mémoire.
Malgré tous ces efforts, Apple ne peut que masquer cette lourdeur du C, sans la supprimer entièrement, et ne résout pas le problème de la difficulté d’accès à la syntaxe de l’Objective-C.

Enters Swift

Le but de Siwft est exactement celui-ci : fournir un langage moderne, rapide, puissant, et léger avec une syntaxe proche des langages de script populaires d’aujourd’hui.

Une évolution en douceur

Apple a l’habitude des évolutions matérielles ou logicielles lourdes : que ce soit au niveau du passage des API Carbon vers Cocoa, de l’architecture PowerPC vers X86, ou encore X86 vers ARM, Apple a fait un grand nombre de switch que la concurrence est bien souvent incapable de mener à bien. Afin de s’assurer que les développeurs réussiront à passer vers Swift en douceur, et sans avoir à réécrire tout leur code, Swift est entièrement inter-opérable avec le code Objective-C existant. Pour faire simple : on peut rajouter du code Swift dans une application Objective-C, et on peut rajouter du code Objective-C dans une application Swift. Dans la pratique, malgré quelques problèmes (voir plus bas), cette intégration se passe sans que le développeur s’en rende compte, et permet aux développeurs de se mettre immédiatement au Swift, y compris sur des projets pré-existant.

Un langage optimisé

Swift a été développé sous la direction de Chris Lattner, le créateur de Clang et LLVM, depuis 2010. En éliminant la lourdeur historique du C, l’équipe de Lattner a réussi à créer un langage particulièrement efficace. Apple parle de gain de performances de 20 à 30% entre Objective-C et Swift.
Bien que nous n’ayons pas obtenu de chiffres aussi spectaculaires, nous avons pu, dans nos propres tests, atteindre facilement les 15% d’amélioration de performances.
Ce gain de performances tient autant de l’optimisation de LLVM à Swift, que des fonctionnalités intrinsèques du langage. Toutes les fonctions extrêmement consommatrice en cycles CPU ont été optimisées avec Swift. Nous pouvons nous en rendre compte ainsi dès la première ligne de code : les boucles, les switch de thread, la gestion des compteurs, … sont fait de manière extrêmement moderne, les rendant facile à coder, et optimaux dans leur exécution.

Un langage simple

Vous n’aimez pas les .h ? Moi non plus, comme la plupart des développeurs de moins de 50 ans. Bien que ces fichiers de header aient été obligatoires pour déclarer l’interface d’une classe dans les années 70, pour séparer le code exécutable des simples déclarations, cela fait très longtemps que ce n’est plus le cas. Tous les langages modernes, Java, C#, Ruby, Perl, … se passent de ces fichiers de header, et c’est naturellement le cas pour Swift. La déclaration et l’implémentation sont maintenant réunies dans un même fichier. Et, comme pour tous les langages modernes, les développeurs n’auront pas à regarder ces fichiers, mais uniquement la documentation générée pour savoir utiliser les API.
Swift supprime également, du moins en surface, les pointeurs. Le développeur n’a plus à s’occuper de la gestion de la mémoire. Cette suppression reste néanmoins uniquement une suppression en surface. Il est en effet indispensable, pour des fonctionnalités de bas niveau, de reprendre la main sur la gestion de la mémoire, et Swift laisse cette possibilité aux utilisateurs avancés.
Un autre point très important pour la simplicité d’utilisation de Swift est la syntaxe du langage en elle même. Alors que l’Objective-C prenait clairement une approche très différente des autres langages, la syntaxe de Swift est, pour sa part, très proche de celle des autres langages utilisés aujourd’hui. Cela pour permettre aux développeurs de rapidement se l’approprier.

Un langage sûr

Un des mots clefs du développement de Swift a certainement été le typage. Contrairement au C et à l’Objective-C, Swift est un langage extrêmement typé : dès la déclaration d’une variable ou d’une constante, cette dernière est typée, et il est impossible de modifier son type.
Ce typage peut être fait de façon dynamique, en affectant une valeur à la variable dès sa déclaration (si on met une String dans une variable à sa déclaration, on ne pourra pas y mettre un int à posteriori), soit de façon statique, en précisant le type de la variable lors de sa déclaration.
Ce typage s’étend à tous les types : une classe, une énumération, un protocol, … sont tous typés et peuvent tous être stockés dans des variables. Cette approche permet de très facilement stocker n’importe quel type dans une variable : un type primitif, un objet, ou même une classe, une méthode, ou un protocol.
La vérification de type étant faite dès la compilation, le développeur est immédiatement averti lors d’une erreur de typage.

To be nil or not to be nil

Swift n’aime pas le nil, mais alors pas du tout. Il n’aime tellement pas le nil, qu’il est impossible pour une variable, ou une constante, d’être nil. Il y a là un avantage indéniable : fini les tests systématiques d’existence d’une variable, et surtout, fini les accès à des variables non initialisées, entraînant les tant redoutés segfault (que nos amis Javaistes connaissent mieux en tant que NullPointerException).
En revanche, un nouveau problème se pose bien évidemment : comment avoir une variable sans valeur? Nous avons tous, dans nos expériences de développeur, eu besoin de variables qui, a un moment ou a un autre, ne seront pas initialisées. Avec Swift, cela reste bien évidemment possible avec les variables optionnelles. Celles-ci sont un peu particulières dans le sens ou elle contiennent une énumération à deux états : None ou Any. Dans le cas None, la variable est vide, dans le Cas Any elle contient une valeur, encapsulé dans le Any. Pour une variable optionnelle, le développeur devra obligatoirement (sinon le compilateur le “gronde”) vérifier si elle est None ou Any avant son utilisation.

Un langage et des outils très jeunes

Tout n’est malheureusement pas rose dans le joli monde de Swift. Loin de là.
Swift est un langage extrêmement jeune, et certainement pas encore mature. La dernière béta en date (béta 3 à l’heure de la rédaction de ces lignes) le montre avec un changement en profondeur de certains éléments de syntaxe. Ces changements nous ont fait, chez iD.apps, repousser notre date de démarrage des développements en Swift : nous ne voulons pas perdre de temps à créer du code qui ne compilera plus en septembre.
Un autre point montrant la jeunesse de Swift est le manque de certaines fonctionnalités fondamentales. Il est par exemple impossible, aujourd’hui, de déclarer des variables privées en Swift.

chat_schrodinger

Enfin, les outils de développement ne sont aujourd’hui absolument pas au niveau. Nous avons l’habitude des beta de Xcode difficilement utilisables. Avec Xcode 6, Apple franchit un nouveau pas : nous sommes au niveau du chat de Schrödinger : il est impossible de savoir, avant de compiler son code, si ce dernier va compiler ou non. Ce problème vient principalement de l’intégration entre Swift et Objective-C. Pour pouvoir faire ces intégrations, Xcode crée des header permettant de faire le bridge entre les deux langages. Dans certains cas, ce bridge fonctionne très bien, et tout va pour le mieux dans le meilleur des mondes. Dans d’autres cas, nous nous retrouvons obligé de supprimer les fameux DerivedDatas pour réussir à compiler. Et dans le pire des cas, le chat est mort : nous n’avons pas réussi à faire fonctionner les header de bridge sans refondre en profondeur le projet.

Au final Swift est un langage extrêmement prometteur. Ses défauts de jeunesse ne remettent absolument pas en question le fait qu’il sera très clairement utilisé par une majorité de développeurs, et ce dès cette année.

Il n’y a pas que Swift dans la WWDC

Bien que Swift ait occupé une grande partie de notre temps à la WWDC, et de nos tests depuis, il est très loin d’être la seule nouveauté importante proposée par Apple lors de cette semaine.

CocoaTouch, revu et corrigé

Encore un peu d’histoire ici. Apple a créé le premier iPhone avec une taille de 3.5″ en 2007. Cette taille, considérée comme énorme à l’époque pour un téléphone, est devenue ridicule au fil du temps. Apple a donc créé un nouvel iPhone, à peine plus grand, en 2012, de 4″. Entre temps une nouvelle famille d’appareil iOS est apparue : l’iPad, avec une taille de 9.7″ (et son corollaire mini de 7.9″). Nous le savons déjà : nous aurons cette année de nouvelles tailles des périphériques : l’iWatch (ou autre nom) d’un écran qui sera à priori autour de 2″, et les nouveaux iPhone, avec des tailles autour de 5″. Je vois déjà les développeurs Android dans le fond se mettre à rigoler doucement : la fragmentation arrive chez Apple.

semi-restore-restore-iOS-device-without-loosing-jailbreak-FSMdotCOM

Alors que nous avions, hier, à gérer deux tailles d’écrans : 3.5″ et 9.7″, et avant-hier une seule avec le 3.5″, nous aurons demain à en gérer 7 : 3.5″, 4″, 5.x” et 6.x” pour les nouveaux iPhone, 9.7″ et 7.9″ pour les iPad, et 2.x” pour la montre. Il est évident que nous allons devoir changer notre méthode de développement des interfaces graphiques.
Et heureusement, encore une fois, Apple a pensé à nous, et y a même pensé en avance. Depuis 2012 et iOS 6, nous pouvons utiliser des contraintes pour designer nos interfaces graphiques. iD.apps y est passé depuis 2012, et j’espère que c’est également le cas pour vous, sinon le passage de l’hiver 2014 risque d’être difficile.
Les contraintes permettent de spécifier le positionnement des éléments à l’écran, non pas de façon absolue, ou uniquement en fonction de leur conteneur, comme dans les versions précédentes d’iOS, mais les uns par rapport aux autres. L’utilisation des contraintes est relativement difficile à appréhender, mais une fois le concept maitrisé, il est d’une puissance sans pareil.
Avec iOS 8, Apple propose une nouvelle abstraction : les rapports de taille. On peut maintenant designer dans Xcode des XIB un peu particuliers : des XIB carrés. Ces XIB carrés signifient une chose et une seule : ils ne sont pas spécifiques à une catégorie d’appareils, mais représentent une interface commune à tous les appareils. Les éléments et contraintes rajoutés dans ces XIB carrés seront les mêmes pour toutes les interfaces.
Vous savez, néanmoins, qu’il est impossible de faire la même interface pour tous les périphériques : iPad, iPhone, et iWatch. Ces nouveaux XIB carrés permettent de le faire.
Comme pour les contraintes, il va falloir apprendre une nouvelle gymnastique. Ces XIB génériques permettent, en fonction des tailles, de définir des contraintes, des éléments, des placements spécifiques. Les tailles sont définies en fonction de la hauteur et de la largeur, en Small ou Regular. En jouant sur toutes ces tailles, il va être possible de définir une interface très personnalisée à chaque taille d’écran, et ce dans un seul et unique XIB.
La gestion des tailles d’écrans n’est bien sûr pas limitée aux XIB, et tout peut également être géré depuis le code. Les différentes classes de taille sont accessibles dans le code, et on peut interagir avec à souhait. Il est par exemple possible dans une animation de savoir si on devient Regular en largeur, et de faire l’animation convenant.

Une autre nouveauté intéressante proposée par le SDK 8 est la réunification des différents contrôleurs iPad et iPhone. Nous pouvons ainsi utiliser un SplitViewController sur un iPhone. Sur iPad, le SplitViewController se comportera exactement comme aujourd’hui. Sur iPhone en revanche, la vue Master s’affichera en tant que RootViewController d’un NavigationController, et les vue détails seront poussées sur ce NavigationController. Il est également possible de faire des UIPopover sur iPhone : ces dernières s’afficheront en modale sur l’iPhone, alors qu’elles continueront à s’afficher normalement sur iPad.
Tous ces changements sont clairement faits pour faciliter le développement d’applications sur plusieurs types de périphériques, et à l’usage, c’est extrêmement agréable.

iCloudDrive et CloudKit

Depuis 2007, les développeurs et les utilisateurs critiquent ouvertement la fermeture d’iOS, et en particulier la quasi-impossibilité des applications de discuter entre elles. iCloudDrive, avec les extensions, sont deux grands pas vers la communication inter-applications dans iOS 8.
Alors que iCloud, depuis iOS5, permettait aux applications de lire et de sauvegarder uniquement leurs propres données, avec iCloudDrive, les applications peuvent enregistrer des documents, qui pourront être lues par n’importe quelle autre application gérant le format.

apple-to-challenge-dropbox-and-box-with-icloud-drive

Sur le papier il s’agit d’une excellente fonctionnalité. Dans la réalité, Apple retombe dans ses vieux démons. Toutes les solutions Cloud d’Apple, que ce soit d’abord MobileMe, puis iCloud et maintenant iCloudDrive ont eu des démarrages plus que laborieux : perte de connexion, perte de données, données à moitié synchronisées…
Dans le cas de iCloud, malheureusement, il n’y a pas le démarrage qui fût laborieux laborieux… Bien que les choses soient un peu mieux depuis un an, les développeurs se sont tous détournés de l’utilisation de iCloud pour passer par des services tiers, tellement la qualité de services était mauvaise. Nous sommes aujourd’hui avec iCloudDrive dans le même cas. Nous sommes bien sûr qu’au début de la technologie, mais il va falloir qu’Apple inverse sérieusement la tendance si la société ne veut pas que sa technologie soit complètement inutilisée par les développeurs.

CloudKit pour sa part est un MBAAS, comme Parse et d’autres. Il a l’avantage d’être gratuit pour une application de taille moyenne. Comme pour iCloudDrive, sur le papier il est excellent, mais à l’utilisation pas encore suffisamment fiable.

Extensions

Les extensions sont un nouveau moyen d’étendre les fonctionnalités du système. Apple a introduit quatre types d’extensions avec le SDK 8. Toutes ces extensions ont deux points communs : elles sont livrées avec une application, et ne peuvent pas communiquer directement avec cette application (ce sont deux binaires différents, s’exécutant dans des espaces mémoire différents). Elles peuvent en revanche avoir accès aux données de l’application.

1402068118-Screen Shot 2014-06-06 at 05.20.12 PM-2

Les widgets

Attention les amateurs d’Android, je vous vois encore ricaner dans le fond! Les widgets d’iOS 8 ne sont clairement pas comparables avec ceux d’Android. Alors que sur Android on peut rajouter des widgets absolument n’importe où, sur iOS cela ne sera qu’à un seul endroit : dans le panneau Aujourd’hui. Les widgets permettront de fournir des informations, comme des itinéraires, des images, des infos météo…
A l’utilisation, mis à part sur la beta 3 extrêmement bugée, les widgets sont très faciles à développer. Composés d’une seule vue, de préférence simple, ils ont comme seule contrainte de devoir se charger très rapidement, pour fournir aux utilisateurs une expérience optimale.

Les extensions de partage

Les extensions de partage étaient très attendues. Elles permettent, comme sur Android, de fournir un service centralisé de partage. En s’enregistrant comme extension de partage, les utilisateurs pourront utiliser votre service de partage de photos, vidéos, textes, … depuis n’importe quelle application utilisant la popup de partage du système, et ce sans aucune modification de l’application utilisant la popup de partage.
Les extensions de partage peuvent utiliser l’interface native proposée par le système, ou fournir leur propre interface graphique. Leur développement est relativement aisé, mis à part la validation des données à partager et le partage de plusieurs données.
Pour le premier point, la validation des données à partager est étonnamment compliquée de la part d’Apple. Toutes les données sont à désencapsuler et convertir, avant de voir si elle seront compatibles avec notre service de partage. Pour le deuxième point, l’upload des données passent par les services en background d’Apple (ce qui est une très bonne chose). L’extension se faisant tuer pratiquement dès sa fenêtre fermée, il est impossible de faire les upload directement depuis l’extension. Dans le cas où nous avons plusieurs données à partager, il faudra donc lancer plusieurs tâches d’upload en background.

Les extensions Safari

Les extensions de Safari permettent d’interagir directement avec le navigateur. 1Password l’utilise par exemple déjà dans sa dernière beta pour remplir automatiquement les mots de passe sur les pages Web.

En plus de ces trois types d’extensions, Apple a ajouté une extension permettant d’ajouter directement des filtres aux images.

TouchID

Lors de la présentation de l’iPhone 5S, la première question que nous avons reçue de la plupart de nos clients était : “pourrais-je l’utiliser dans mon application“. La réponse était malheureusement non à l’époque.

iphone-touch-id-logo

A partir du SDK8, cela sera maintenant possible. La technique va même plus loin que TouchID : il sera possible d’utiliser le mot de passe du périphérique pour déverrouiller des fonctionnalités de l’application.
Dans la technique, tout cela passe par la keychain. Les développeurs peuvent maintenant stocker des informations dans la keychain qu’ils définiront comme nécessitant l’authentification de l’utilisateur. Quand l’application souhaite accéder à ces données, le système demandera automatiquement à l’utilisateur son empreinte ou son mot de passe. Si la mauvaise empreinte, ou le mauvais mot de passe, est saisi, l’application n’aura alors pas accès aux données protégées.

Home Automation

Avec Home Automation, Apple veut faire son entrée dans la domotique, et pas par la petite porte. Home Automation n’est pas une application, mais un framework, permettant d’interagir avec le matériel compatible.
Home Automation a l’avantage d’utiliser une base de données unifiée. Après avoir rajouté un matériel, et réglé ce dernier, dans une application utilisant Home Automation, il sera disponible, et avec ses réglages, dans toutes les autres. Il sera donc possible de choisir de changer d’application frontend de Home Automation sans perdre toute sa configuration.

screen-shot-2014-06-02-at-11-36-26-am

Home Automation est composé, dans l’ordre : de maisons, de pièces, et d’équipements (chaque pièce fait partie d’une maison, et chaque équipement d’une pièce). Ce groupement permet de faire des actions automatisées comme éteindre toutes les lumières d’une maison, ou fermer tous les volets électriques d’une pièce, …
L’intégration avec Siri marche extrêmement bien. Nous n’avons pu la tester que via le simulateur d’équipement (il n’y a pas, à notre connaissance, de périphériques Home Automation sur le marché), et nous avons facilement pu dire à notre Smartphone d’ouvrir notre portail, ou d’éteindre toutes nos lumières.

Cet article ne se veut pas exhaustif : il a pour but de vous présenter ce que nous considérons comme le plus important de la WWDC. Il nous serait impossible sur un seul article de vous parler de tout ce que nous avons appris pendant cette WWDC, qui s’est avéré être un excellent cru.

Retour de Google I/O

Jérémy, un de nos meilleurs Experts Android a eu la chance de participer cette année à la Google I/O qui s’est déroulée à San Francisco. Retour d’expérience avec lui !

Salut Jérémy, comment s’est passé ton voyage à San Francisco ? 

Le voyage s’est très bien passé. J’avais peur du décalage horaire mais je l’ai très bien encaissé dans le sens Paris – San Francisco. C’était la première fois que j’allais aux États-Unis et bizarrement j’étais soulagé une fois la frontière américaine passée.

Pour résumer : un bon moment avec beaucoup de marche, beaucoup d’informations et de nombreuses rencontres enrichissantes.

Comment s’est déroulée pour toi la Google I/O ? 

La Google I/O s’est déroulée sur 2 jours : les 25 et 26 juin derniers.

Je suis arrivé à San Francisco le 23 juin après-midi, le temps de faire face au jet-lag et je suis allé à l’enregistrement le lendemain après-midi.

Droid Intel

Deux jolis “Droids” Intel m’ont invité à la soirée organisée par la société. Celle-ci fut très riche tant socialement que professionnellement. J’ai ainsi rencontré des développeurs Intel qui m’ont présenté leurs produits. Celui qui a retenu le plus mon attention fut le XDK. Il permet de faire facilement des applications Web et hybrides ; un outil à surveiller pour les futures applications Web.

Puis, levé à 3h30 pour la Keynote – 1er arrivé dans la file à 4h00 ! 5 heures d’attente, heureusement les rencontres furent nombreuses ! Keynote suivie d’un contre la montre où se succédaient les sessions un peu moins intéressantes qu’espéré. Celles du premier jour ressemblaient à un speech de présentation, mettant en avant les nouveautés en les présentant comme des “révolutions”. Les sessions étaient malgré tout très enrichissantes car elles nous révélaient les moindres détails sur les nouveautés et les cheminements intellectuels qui leur avait donné vie.

Et pour finir cette journée mouvementée, une petite soirée Google où j’ai pu rencontrer des développeurs russes, français et bien sûr américains autour de bières et de burgers.

After Hours Google I/O

 

La seconde journée de sessions fut plus intéressante pour les développeurs. Nous avons pu jouer avec notre nouveau gadget en début de journée : la LG G Watch … que nous avons maintenant chez iD.apps aussi 🙂

LG G Watch

Plus complètes et réellement dédiées aux développeurs, les sessions du deuxième jour nous ont montré comment exploiter et s’interfacer avec les nouveautés. Mais à part cette partie développement intéressante, une atmosphère se dégageait des sessions : “Ce que l’on vous a préparé est génial mais ce n’est pas tout à fait prêt.”. Un peu frustrant devant notre IDE pour coder… Mais avec un peu de patience, ces sessions ont pu nous montrer toute l’étendue qu’auront ces nouveautés sur notre travail quotidien et sur les prochaines demandes de nos clients.

2 jours exceptionnels que je referais avec plaisir !

Quelles sont les annonces qui t’ont le plus marqué? Pour les utilisateurs et pour les développeurs?

4 annonces me viennent à l’esprit : Android L, Android Wear, Android TV et Android Auto.

Android L : pour les utilisateurs, le Material Design est l’annonce la plus importante. En plus de modifier le design du système, elle permet aux développeurs de faire “enfin” de belles animations.

Autre annonce importante sur Android : les notifications sur l’écran de déverrouillage qui permettent à l’utilisateur de voir directement les informations importantes de ses notifications sans déverrouiller son Smartphone.

Android Wear et Android Auto : pour les utilisateurs, Android Wear et Android Auto fonctionnent comme un écran déporté, l’intelligence reste sur le Smartphone. Cela empêche ainsi l’utilisateur d’être trop “dépendant” du Smartphone dans des contextes d’utilisation qui ne sont pas adaptés au Smartphone ou à la Tablette. Côté développeur, cela donne d’autres interfaces à exploiter.

Android TV : malgré l’échec de la Google TV, Google a annoncé et présenté Android TV. Pour les utilisateurs, Android TV est une évolution de la Chromecast avec des applications permettant d’avoir une Box TV complète. Mêlée avec des FAI comme Bouygues (partenaire sur l’Android TV), cela procure à l’utilisateur une Box TV performante avec le support du Chromecast intégré dans l’univers Google.

Quelles sont les conférences qui ont le plus retenu ton attention ? Pourquoi ? 

  • What’s new in Android development tools

     Un bon aperçu de ce que sera notre prochain IDE.

  • Android Wear : The developer’s perspective

Une session pour les développeurs qui désirent monter en compétence sur Android Wear. 

  • Material science: Developing Android applications with Material Design et Material witness: How Android material applications work

Deux sessions sur le nouveau design et les animations : comment l’exploiter et l’implémenter.

et

Ces 4 sessions ont été pour moi les plus intéressantes car vraiment destinées aux développeurs.

Qu’as-tu pensé d’Android Wear, Android TV et Android Auto? Quel lien fais-tu entre ces annonces/plateformes? Quelles sont les opportunités pour les nouveaux usages et les développeurs?

Android Wear n’était pas franchement une nouveauté car déjà présenté sur le blog développeur.

L’annonce d’une Android TV m’a surprise pour deux raisons : premièrement l’ancienne Google TV n’a pas été un succès, deuxièmement le lancement de ChromeCast a été une réussite et est pour partie en concurrence avec Android TV.

Android Auto m’a étonné par le nombre de partenaires.

Comme expliqué lors de la Keynote, Android TV, Auto, Wear ne sont qu’un moyen d’affichage. C’est un peu moins vrai pour Android TV, mais le contrôleur reste le Smartphone.

Cela donne énormément d’opportunités aux développeurs de créer un affichage embarqué (vêtement ou Auto) pour leurs applications et ainsi permettre à l’utilisateur de ne plus être “dépendant” de son Smartphone.

Les petits bémols sont la complexité et le multi-développement que subiront les équipes de développement. En effet, créer une application pour Wear est un travail à part entière. Cela nécessite un travail d’ergonomie en plus, ainsi que le développement d’une couche de communication entre les deux applications (Wear et device).

Un mot sur les technos autres qu’Android  ! 

Côté Web ? 

Côté Web les annonces de l’I/O ont été relativement peu nombreuses. Il a été question durant la Keynote de Polymer, un projet de Google ayant pour but de démocratiser certaines APIs présentes dans HTML5, en utilisant les composants natifs dans les navigateurs compatibles, et du Javascript pour les simuler si ce n’est pas le cas. Il est  ainsi possible de créer ses propres éléments HTML, via la norme web components, et ce sur tous les navigateurs modernes, bien que l’API ne soit pas compatible partout pour le moment.

Polymer existait déjà auparavant, mais en l’évoquant durant la Keynote, Google met clairement en avant cette technologie, la présentant comme la base de leurs futurs développements Web. Cela se fait quelque peu au détriment d’Angular, un autre framework Web de Google qui dispose de nombreuses fonctionnalités communes avec Polymer. Néanmoins les deux devraient encore coexister un moment.

Il a également été annoncé que Polymer allait être totalement compatible avec le Material Design, permettant ainsi de mettre en pratique dès à présent les nouvelles guidelines de Google, avant même de pouvoir les utiliser sur les applications Android. Un Site Web (http://www.polymer-project.org/docs/elements/material.html) dédié a été créé pour l’occasion, regroupant toutes les informations nécessaires pour cela. A noter que si vous utilisez Angular, il est également possible d’implémenter du Material Design très facilement grâce au Site Web suivant : https://material.angularjs.org/#/

Côté Cloud ? 

Google a annoncé Google Cloud Dataflow : un service permettant de gérer des pipelines de données, de transformer et d’analyser les données.

Google a ajouté un outil dans Google Cloud Platform pour déboguer, tracer et monitorer une application en production. De nombreuses fonctionnalités pour le mobile ont été ajoutées à GCP.

Quelle est, d’après toi, la techno Google la plus sous-estimée ? Quel impact pour les années à venir ?

Android Wear sans hésiter ! Ou plutôt Android sur les outils de la vie quotidienne.

Quand on regarde les tests sur le Web, l’idée générale qui en ressort est que c’est sympa mais sans réelle utilité. Beaucoup ne voient pas l’intérêt des montres connectées, mais personnellement je pense que cela va se démocratiser et devenir un outil indispensable du quotidien. Et d’ailleurs, pas uniquement sur les montres, mais aussi sur n’importe quel outil de la vie quotidienne.

Qu’as-tu ramené comme goodies 😀 ? 

Des autocollants, une cuillère Android, une gourde Android, un jeu de carte Android, une figurine et quelques T-shirts.

Ton TOP 3 de la Google I/O ? 

  • L’ambiance dans les files d’attente
  • La Keynote grandiose
  • L’after hours de Google, enrichi par de nombreuses rencontres

Tes conseils pour ceux qui voudraient s’y rendre ? 

Surtout dormez bien avant d’y aller !

Profitez du premier jour de conférences pour aller au Box Talk afin de d’échanger avec les développeurs Google. Vous ne raterez pas grand chose et cela vous permettra de discuter plus longuement avec eux.

La teneur de ton prochain article technique sur le blog ? 

Android Wear je pense. Pour moi, c’est un des concepts les plus intéressants qu’a apporté la Google I/O.

Merci Jérémy pour toutes ces infos et à bientôt pour ton article technique !

Retour de WWDC (1/2) : Ambiance

2 de nos Experts iOS, David et FX sont rentrés de San Francisco avec des souvenirs plein la tête et bien évidemment une expertise renforcée. Pour cela, nous vous proposons un retour sur l’expérience WWDC de nos Experts en 2 articles.

1. L’ambiance de l’événement et des lieux

2. Un retour à froid sur les annonces techniques de la WWDC                            Quelles sont les avancées vraiment importantes pour les utilisateurs, pour les développeurs ? Y-a-t-il eu des annonces un peu “surfaites” ?

–  L’ambiance de l’événement et des lieux –

Vous retrouverez dans ce premier article une interview de David sur l’ambiance de la WWDC et de San Francisco.

Salut David, alors comment s’est passé ce voyage à San Francisco ?

C’était top, 10 jours de bonheur.

Concernant l’organisation, l’hôtel était très bien placé, à 5 minutes du Moscone Center. Il est très facile de se déplacer : entre le métro, le tram, le bus et le train, les moyens de transport sont nombreux. Un bémol tout de même, il n’y a pas une, mais au moins trois sociétés de gestion des transports, il faut donc autant de tickets et/ou de pass hebdomadaires.

Ensuite, au sujet de la WWDC en elle-même, après une Keynote bien plus chargée que ce à quoi nous nous attendions, nous avons assisté à 4 jours de conférences claires et rondement menées. Bref des journées studieuses pour assimiler toutes les nouveautés.

Peux-tu nous raconter en quelques mots votre découverte de la ville et son ambiance ? Est-ce réellement le paradis des geeks ?

“Paradis des Geeks” : je ne sais pas. Honnêtement d’après nos impressions, je dirais que non . 😉 Ce qui est certain, c’est que la WWDC ne pouvait pas passer inaperçue. En effet, plus de 6000 ingénieurs fans de la marque à la pomme se sont promenés dans les rues de San Francisco pendant une semaine. Et nous étions reconnaissables grâce à une “jolie” veste estampillée WWDC 14, offerte à l’inscription. Difficile de nous rater !

IMG_2865

Tiens! Des gens avec la veste WWDC 14 !

Hormis les participants à la WWDC, San Francisco ne nous a pas laissé une impression de ville de geeks. Nous étions en plein centre-ville alors que l’activité informatique se trouve plus au sud de la baie : du côté de Palo Alto et Sunnyvale.

IMG_2759

Ballade en vélo

Selon vous, comment s’est déroulée la WWDC ? Comment se passe une conférence avec 2000 personnes ?

Il a fallu, tout d’abord récupérer notre pass le dimanche, puis direction le Moscone où iOS 8 et Mac OS Yosemite étaient déjà à l’affiche.

IMG_2864

A conserver précieusement !

Le lendemain : levé à 4h30 du matin pour la Keynote! FX n’avait pas sommeil 😉 et a patienté jusqu’à 10h00 que la Keynote commence. De mon côté, je suis arrivé à 7h00 avec les cafés à la main et j’ai pu rejoindre FX à quelques mètres de l’entrée. Il n’y avait pas de places pour tout le monde dans la plus grande salle de conférence. Si nous étions arrivés trop tard nous aurions assisté à la Keynote dans une 2ème salle en vision conférence 🙁 Tant qu’à être à San Francisco, autant voir Tim Cook en chair et en os !

IMG_2871

La longue file d’attente à 7h00 qui fait le tour complet du bloc…

Avec 2000 personnes, les conférences se sont étonnamment bien passées! Il faut dire que les moyens étaient là : une sonorisation de qualité avec deux ingénieurs son dans chaque salle, des écrans de grandes tailles et une gestion de la foule au cordeau. Les ingénieurs Apple étaient parfaitement rodés et leurs présentations claires avec quelques touches d’humour. Les Macs étaient toujours en double voire en triple pour assurer les démos. Néanmoins, nous avons eu droit à quelques crashs sur les Macs tournant avec la bêta de Mac OS Yosemite et celle de Xcode 6. Cela n’a pas manqué de faire réagir l’assemblée.

Et concernant la Keynote : quelle ambiance, quelle population ?

Lors des conférences, l’ambiance était très studieuse : chacun sur son Mac à prendre des notes. Il faut dire que plus de 30% de la population n’est pas anglophone. Il faut être concentré pour ne rien manquer. Les intervenants étaient vraiment bons. J’ai déjà vu des conférences en français moins compréhensibles. Chacune impose une heure de concentration à essayer d’assimiler le plus possible les nouveautés sur lesquelles nous devrons travailler dès notre retour en France. Septembre va arriver vite !

Le premier soir, une rencontre francophone fut organisée à proximité du Moscone. Ce fut un bon moment pour rencontrer des compatriotes et échanger nos impressions sur cette Keynote. Tout le monde était très emballé par les nouveautés annoncées !

Et le retour, alors pas trop dur… ?

Non, cela a été. Le décalage horaire a été moins difficile que prévu. Dès le mardi, nous avons fait le bilan avec FX et préparé des retours pour nos collègues développeurs. Nous partagerons ainsi bientôt avec vous certains de ces éléments.

Ton top TOP 3 des souvenirs Whaouu!! ?

  • La Keynote en Live et Tim Cook en vrai 😉
  • Tous les monuments de SF en vrai
  • 6000 fans de la marque à la Pomme dans un seul et même bâtiment !

 Ton TOP 3 des “si je devais y retourner, je …” ?

  • Je retournerais avec FX pour qu’il fasse la queue à 4h30 pour la Keynote 2015.
  • Je ferais un tour sur les campus Apple, Google plus au sud de la baie de SF.
  • Je passerais plus de temps dans le Parc National de Yosemite 🙂

Le mot de la fin ?

Vraiment une superbe expérience, autant sur le plan professionnel que personnel. Nous espérons pouvoir y retourner tous les ans mais il va falloir laisser la place à ceux restés au bureau cette année.

A bientôt pour le retour technique sur la WWDC !

Ok Glass, report an incident (1/2)

Here is a new article where we are going to continue our trip with Google Glass. If you missed the previous one, it’s this way (in french).

This time, we decided to explore the possibility to use Glass with a MBAAS (Mobile Backend As A Service). To complete this next trial of Glass capabilities we also wanted to be able to give direction with Glass and test its GPS tracking features. Here we chose to use Parse as our MBAAS one of the reason was the fairly easy use of geo-points to search in the database after they are saved.

In this article, we will work on an application that helps the user to report an incident around him. When a user encounters an incident, he can launch the application and choose the kind of problems he is meeting. In our case, we consider that an incident is something like a theft, a deterioration or a defacement. After he has made his choice, he is able to take a picture of the scene and add a first vocal report. Then the location is stored and a map indicates the incident location so the user can confirm it.

I have a terrible accent and a stuffy nose, so the two mixed together make it often nearly impossible for Glass to understand me. And don’t search for the car, it isn’t in the picture.

Scrolling through a set of types on Glass

Like all Glassware our application has a voice command as a launch trigger. Here the voice trigger is “Report an incident”. It is also possible to launch the application with the touchpad, just like in the previous video.

scrollView-first-encounter

The first step to report an incident is to specify its type. We limit the user to a certain set of types, so it eases the incident declaration. Given that, it appears that we couldn’t use the speech recognition.

Speech recognition gives to the user too much freedom, making it tricky to recognize the incident type we want. So, we decide to use a set of predefined cards grouped in a ScrollView that the user could interact with to browse through the set. The user navigates through the set by swiping to choose a card, and then use a tap interaction in order to select one.

private List<Card> mCards;
private CardScrollView mCardScrollView;

private AdapterView.OnItemClickListener mClickAdapter = new AdapterView.OnItemClickListener() {
	public void onItemClick(AdapterView<?> parent, View view, int position,
			long id) {
		Intent _toPictureActivity = new Intent(TypeAnIncidentActivity.this,
				PictureMainActivity.class);
		_toPictureActivity.putExtra(
				Poc_DeclareAnIncident_Constants.INCIDENT_TYPE,
				Poc_DeclareAnIncident_Constants.INCIDENT_TYPES
						.get(position));
		startActivity(_toPictureActivity);
	}
};

@Override
protected void onCreate(Bundle savedInstanceState) {
	super.onCreate(savedInstanceState);

	createCards(); //create cards to be displayed 
	mCardScrollView = new CardScrollView(this);
	IncidentTypeCardScrollAdapter adapter = new IncidentTypeCardScrollAdapter();
	mCardScrollView.setAdapter(adapter);
	mCardScrollView.setOnItemClickListener(mClickAdapter);
	mCardScrollView.activate();
	setContentView(mCardScrollView);
}

private void createCards() {
	...
}

private class IncidentTypeCardScrollAdapter extends CardScrollAdapter {

	@Override
	public int getPosition(Object item) {
		return mCards.indexOf(item);
	}

	@Override
	public int getCount() {
		return mCards.size();
	}

	@Override
	public Object getItem(int position) {
		return mCards.get(position);
	}

	@Override
	public int getViewTypeCount() {
		return Card.getViewTypeCount();
	}

	@Override
	public int getItemViewType(int position) {
		return mCards.get(position).getItemViewType();
	}

	@Override
	public View getView(int position, View convertView, ViewGroup parent) {
		return mCards.get(position).getView(convertView, parent);
	}
}

Our ScrollView is based on the exemple of the developer site for Google Glass. We added the click adapter so that it would meet our needs and pass an intent with the type of incident.

Save a picture and a report in Parse

Once the user has selected an incident type, he is prompted to take a picture of the scene to add it to the report. For this step we used the same code as for the bus schedule application. Thus, the user can preview the picture he will take and use the camera button to take it. But this time, we gave the possibility for the user to retake the picture if it didn’t meet is standard. When he is satisfied by the picture he can add a quick voice description of the incident to the report. For this we use the speech recognition activity embedded in Glass.

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
	if (requestCode == SPEECH_REQUEST && resultCode == RESULT_OK) {
		List<String> results = data
				.getStringArrayListExtra(RecognizerIntent.EXTRA_RESULTS);
		String _report = results.get(0);

		mIncidentDescription.put(
				Poc_DeclareAnIncident_Constants.INCIDENT_DESCRIPTION,
				_report);

		voice = true;

		mInstructionView
				.setText(Poc_DeclareAnIncident_Constants.RECORD_REPORT);
	}
	super.onActivityResult(requestCode, resultCode, data);
}

private GestureDetector createGestureDetector(Context context) {
	GestureDetector gestureDetector = new GestureDetector(context);
	//Create a base listener for generic gestures
	gestureDetector.setBaseListener(new GestureDetector.BaseListener() {
		@Override
		public boolean onGesture(Gesture gesture) {
			if (gesture == Gesture.TAP && ending) {
				...

				Intent _speechIntent = new Intent(
						RecognizerIntent.ACTION_RECOGNIZE_SPEECH);
				_speechIntent.putExtra(RecognizerIntent.EXTRA_PROMPT,
						"Please speak your incident report");
				startActivityForResult(_speechIntent, SPEECH_REQUEST);

				releaseCamera();
				...
				return true;
			} else if (gesture == Gesture.SWIPE_LEFT) {
				if (voice) {
                voice = false;

                Intent _speechIntent = new Intent(
                      RecognizerIntent.ACTION_RECOGNIZE_SPEECH);
                _speechIntent.putExtra(RecognizerIntent.EXTRA_PROMPT,
                      "Please speak your incident report");
                startActivityForResult(_speechIntent, SPEECH_REQUEST);
             }
             return true;
			}
			return false;
		}
	});

	return gestureDetector;
}

/*
 * Send generic motion events to the gesture detector
 */
 @Override
 public boolean onGenericMotionEvent(MotionEvent event) {
    if (mGestureDetector != null) {
        return mGestureDetector.onMotionEvent(event);
    }
    return false;
 }

The embedded speech recognition activity is started with activity for result. The result is the first element of an array of strings in the result intent. Here we add gesture management to be able to restart the activity to record anew the report if needed.

speech_prompt_treat

In addition this time we need to save the picture and the report of the incident. It’s here that Parse will come in handy. Before we continue, I want to explain quickly what Parse is. Most of you might already know what it is, but that will help me explain what we were looking for by using Parse.

Parse is a MBAAS, a Mobile Backend As A Service, sometimes referred to as Backend as a Service (BaaS). Basically, it’s a cloud computing category that’s comprised of companies that make it easier for developers to setup, use and operate a cloud backend for their mobile, tablet and web apps.

With a MBAAS, you don’t need to setup either a physical infrastructure for your servers, nor all the software part for those servers. It also provides data management tools, so you do not need to build a database. All of those tools are meant to ease the work of developers, so to easily integrate those tools you have at your disposal SDKs. Parse also have embedded possibilities to help the developers manage location point. This will prove useful in the future and I will talk more about this feature later on.

/**
 * Callback function when the picture is saved in parse
 */
private SaveCallback mPictureSaved = new SaveCallback() {
	@Override
	public void done(ParseException e) {
		if (e == null) {
			mIncidentDescription.put(
					Poc_DeclareAnIncident_Constants.INCIDENT_PICTURE,
					mIncidentPicture);

			mIncidentDescription.saveInBackground(mIncidentSaved);
			mProgress.setMessage("Saving incident...");
		} else {
			Toast.makeText(PictureMainActivity.this,
					"Failed to save incident picture", Toast.LENGTH_SHORT)
					.show();
		}
	}
};

/**
 * Callback function when the incident is saved in parse
 */
private SaveCallback mIncidentSaved = new SaveCallback() {

	@Override
	public void done(ParseException e) {
		if (e == null) {
			String incidentId = mIncidentDescription.getObjectId();

			Intent locationIntent = new Intent(
					PictureMainActivity.this,
					com.glass.poc.poc_declareanincident.location_feed.IncidentLocationActivity.class);

			locationIntent
					.putExtra(Poc_DeclareAnIncident_Constants.INCIDENT_ID,
							incidentId);
			startActivity(locationIntent);
			mProgress.dismiss();
		} else {
			Toast.makeText(PictureMainActivity.this,
					"Failed to save incident report", Toast.LENGTH_SHORT)
					.show();
		}
	}
};

@Override
public boolean onGesture(Gesture gesture) {
	if (gesture == Gesture.TAP && ending) {
		if (ending && !voice) {
			...
		}

		if (ending && voice) {
			...
			mIncidentPicture.saveInBackground(mPictureSaved);
		}
		return true;
	} else if (gesture == Gesture.SWIPE_LEFT) {
		...
		return true;
	}
	return false;
}

Here we save asynchronously the picture, as a ParseFile, and the rest of the incident report with the saveInBackground function of Parse. (Here for more information)

Once we retrieved the picture and the vocal report, we save them along with other information into Parse. Then we can proceed to adding the incident location to those information.

Location on Glass

Before adding the incident location, we need to retrieve it. Glass can find its own location through Wi-Fi information or GPS one (Location on Glass developer guide). Actually, Glass uses the same mechanism as in Android and uses its API to retrieve location updates (Location update on Glass). Hence we have to create a criteria, a location manager and a location listener as in any Android application.

private Criteria mLocationCriteria;
private LocationManager mLocationManager;

private LocationListener mLocationListener = new LocationListener() {
	public void onLocationChanged(Location location) {

		// Called when a new location is found by the network location provider.
		double mIncidentLatitude = location.getLatitude();
		double mIncidentLongitude = location.getLongitude();

		mLocation = new ParseGeoPoint(mIncidentLatitude, mIncidentLongitude);

		ParseQuery<ParseObject> query = ParseQuery
				.getQuery(Poc_DeclareAnIncident_Constants.INCIDENT_LOCATION);

		query.getInBackground(mIncidentId, new GetCallback<ParseObject>() {
			public void done(ParseObject object, ParseException e) {
				if (e == null) {
					object.put(
						Poc_DeclareAnIncident_Constants.INCIDENT_Loc,
						mLocation);
					object.saveInBackground(new SaveCallback() {

						@Override
						public void done(ParseException e) {
							if (e == null) {
								Toast.makeText(
									IncidentLocationActivity.this,
									"Incident location saved Tap to dismiss",
									Toast.LENGTH_SHORT).show();

								end = true;
							} else {
								Toast.makeText(
									IncidentLocationActivity.this,
									"Failed to save incident location",
									Toast.LENGTH_SHORT).show();
								finish();
							}
						}
					});
				} else {
					Toast.makeText(
						IncidentLocationActivity.this,
						"Failed to retrieve incident",
						Toast.LENGTH_SHORT).show();
				}
			}
		});

		mMapView = new ImageView(IncidentLocationActivity.this);
		setContentView(mMapView);
			loadMap(mIncidentLatitude, mIncidentLongitude, 17);
		mLocationManager.removeUpdates(mLocationListener);
	}

	public void onStatusChanged(String provider, int status, Bundle extras) {
	}

	public void onProviderEnabled(String provider) {
	}

	public void onProviderDisabled(String provider) {
	}
};

When we get the location update, we can retrieve the corresponding incident from Parse and add the user current location as our incident location.

@Override
public void onCreate(Bundle savedInstanceState) {
	super.onCreate(savedInstanceState);
	setContentView(R.layout.location_immersion);

	mLocationCriteria = new Criteria();
	mLocationCriteria.setAccuracy(Criteria.ACCURACY_FINE);

	mLocationManager = (LocationManager) this
			.getSystemService(Context.LOCATION_SERVICE);

	...

	// Queue the location research runnable
	mHandler.post(mUserLocationRunnable);
}

private class UserLocationRunnable implements Runnable {

	private boolean mIsStopped = false;

	public void run() {
		if (!isStopped()) {
			String provider = mLocationManager.getBestProvider(
					mLocationCriteria, true);

			boolean isEnabled = mLocationManager
					.isProviderEnabled(provider);

			if (isEnabled) {
				// Register the listener with the Location Manager to receive location updates
				mLocationManager.requestLocationUpdates(
						LocationManager.NETWORK_PROVIDER, 10000, 0,
						mLocationListener);
			} else {
				String s = "No provider enable.";

				txtV.setText(s);
			}

			setStop(true);
		}
	}

	public boolean isStopped() {
		return mIsStopped;
	}

	public void setStop(boolean isStopped) {
		this.mIsStopped = isStopped;
	}
}

Do not forget to add the appropriate permission in the manifest.

Now we have our incident location. To confirm it is a valid one, we provide the user a map where the location is displayed. Here we had to use a static map because we couldn’t add play Services, and Google maps in particular, to a Google Glass project (Map image for Google Glass). The map loading  is done in the location listener, just after the location is saved in Parse.

/**
 * Template for a static map
 */
private static final String STATIC_MAP_URL_TEMPLATE = "https://maps.googleapis.com/maps/api/staticmap"
		+ "?center=%.5f,%.5f"
		+ "&zoom=%d"
		+ "&sensor=true"
		+ "&size=640x360"
		+ "&markers=color:red%%7C%.5f,%.5f"
		+ "&scale=1"
		+ "&style=element:geometry%%7Cinvert_lightness:true"
		+ "&style=feature:landscape.natural.terrain%%7Celement:geometry%%7Cvisibility:on"
		+ "&style=feature:landscape%%7Celement:geometry.fill%%7Ccolor:0x303030"
		+ "&style=feature:poi%%7Celement:geometry.fill%%7Ccolor:0x404040"
		+ "&style=feature:poi.park%%7Celement:geometry.fill%%7Ccolor:0x0a330a"
		+ "&style=feature:water%%7Celement:geometry%%7Ccolor:0x00003a"
		+ "&style=feature:transit%%7Celement:geometry%%7Cvisibility:on%%7Ccolor:0x101010"
		+ "&style=feature:road%%7Celement:geometry.stroke%%7Cvisibility:on"
		+ "&style=feature:road.local%%7Celement:geometry.fill%%7Ccolor:0x606060"
		+ "&style=feature:road.arterial%%7Celement:geometry.fill%%7Ccolor:0x888888";

/** Formats a Google static maps URL for the specified location and zoom level. */
private static String makeStaticMapsUrl(double latitude, double longitude,
		int zoom, double markLat, double markLong) {
	return String.format(STATIC_MAP_URL_TEMPLATE, latitude, longitude,
			zoom, markLat, markLong);
}

private ImageView mMapView;

Here we added a red mark at the incident location.

/** Load the map asynchronously and populate the ImageView when it's loaded. */
private void loadMap(double latitude, double longitude, int zoom) {
	double tlat = latitude;
	double tlong = longitude;
	String url = makeStaticMapsUrl(latitude, longitude, zoom, tlat, tlong);
	new AsyncTask<String, Void, Bitmap>() {
		@Override
		protected Bitmap doInBackground(String... urls) {
			try {
				HttpResponse response = new DefaultHttpClient()
						.execute(new HttpGet(urls[0]));
				InputStream is = response.getEntity().getContent();
				return BitmapFactory.decodeStream(is);
			} catch (Exception e) {
				Log.e(TAG, "Failed to load image", e);
				return null;
			}
		}

		@Override
		protected void onPostExecute(Bitmap bitmap) {
			if (bitmap != null) {
				mMapView.setImageBitmap(bitmap);
			}
		}
	}.execute(url);
}

location_first_encounter

Conclusion

Through this reporting application we have been able to put to the test the location providing features of Glass, alongside with the use of a MBAAS. We also got to use scrollViews and Glass cards. Oddly there seem to be only this to display scrollable content, the use of listViews being broken since a while (issue 484).

Next time, we will talk about resolving the incident we saved with the reporting application we talked about.

MBaas – Retrouvez l’intervention en vidéo d’un de nos Experts au PAUG

Tour d’horizon des MBaas

Les applications mobiles reposent de nos jours presque toutes sur l’exploitation d’un BackOffice. Cependant l’implémentation d’un BackOffice, l’administration de machines associées, la gestion de la scalabilité et le TTM du marché actuel sont autant de difficultés à résoudre pour des petits ou moyens acteurs. Pourtant un nouveau type de service appelé MBaas voit le jour et permet de gérer une bonne partie de ces problématiques à moindre coût. Google a d’ores et déjà proposé son Mobile Backend aux développeurs mais d’autres acteurs pointent depuis un moment le bout de leur nez.

Cette présentation vous propose donc de parcourir les éléments suivants :
• Tour d’horizon des MBaas
• Fonctionnalités proposées
• Exemples d’implémentations

Vous pouvez télécharger l’application Android de démo ici.

Vous pouvez trouver les slides de la présentation  ici :

iD.apps à la Google I/O

Cette année la Google I/O, conférence des Développeurs utilisant les technologies Google, aura lieu le 26 Juin. iD.apps a une forte expertise dans le domaine d’Android, c’est donc en toute logique que nous avons souhaité y participer. La demande pour être présent à cet événement étant extrêmement importante, Google a mis en place un tirage au sort. Heureusement nous avons été chanceux et Jérémy d’iD.apps aura la chance de s’y rendre. Voyons quelles sont ses attentes.

Jérémy Samzun Lead Developer Android

Pourrais-tu rapidement te présenter et nous indiquer ton rôle chez iD.apps ? 

JS : Je m’appelle Jérémy Samzun, je suis Expert sur Android chez iD.apps. Je suis passionné de nouvelles technos et forcément par tout ce qui touche de près ou de loin à Google. Je m’intéresse bien entendu à la mobilité que ce soit chez Google, Apple ou encore Microsoft. Cela fait maintenant 5 ans que je développe sur Android ce qui me permet d’avoir un certain recul sur les futurs challenges techniques associés aux annonces divulguées à la Google I/O et donc aux futures demandes de nos clients.

Que représente pour vous la Google I/O? 

JS : La Google I/O est la conférence Google/Android/Chrome de l’année. Étant Développeur, il s’agit du rendez-vous à ne pas manquer que ce soit sur mon canapé devant la keynote ou au bureau pour les sessions. Durant cette conférence, nous aurons l’aperçu des problématiques sur lesquelles nous travaillerons au cours des deux prochaines années, voire plus (ainsi, quand Google a annoncé les fragments, cela a changé notre manière de développer depuis ce jour).

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

JS : Comme la WWDC pour iOS, la Google I/O est faite pour les Développeurs. Les annonces sont logicielles principalement. Nous attendons tout de même des annonces concernant une possible Nexus 8 et une montre Android Wear notamment. Elles permettent aussi de voir les prochaines évolutions liées à Android 4.5 ou 5.0.

Les annonces très intéressantes pour le consommateur sont l’arrivée d’Android Wear, l’évolution de Nest (domotique) et les prochaines évolutions d’Android. Il s’agit de rumeurs bien entendu! Mais sachant que l’Android Wear a été présentée sur l’Android Developpers Blog et des sessions ont été mises en place spécialement pour celle-ci, il est fort probable qu’elle soit donc présentée.

Concernant l’évolution de Nest, une session est planifiée sur ce sujet mais nous ne savons pas si ces évolutions seront majeures ou non.

Concernant l’évolution d’Android, des rumeurs indiquent qu’elle se nommerait Android 5.0 Lollipop, qu’il y aurait une refonte design pour coller au maximum au « flat design », l’intégration de Google Babel (unified chat service) ainsi qu’un un merge possible entre Chrome OS et Android.

Il n’y a pas qu’Android à la Google I/O, on peut donc espérer des annonces concernant aussi Chrome, Dart, l’arrêt des devices Nexus ou encore des robots.

En tant qu’Expert Android sur quoi se portent le plus tes attentes ?

JS : Étant Développeur Android, j’attends avec impatience l’Android Wear. Pour moi, cela sera l’annonce majeure de la Google I/O. En effet, cela positionnerait Android comme leader dans ce domaine en innovant sur un sujet très attendu par les consommateurs.

Les nouveautés Android auront aussi leur place même si je doute que les innovations sur ce sujet ne soient pas énormes. J’espère me tromper sur ce point.

Merci pour ton témoignage Jérémy!

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” 🙂