Sur la route d'Oxiane digressions diverses

Une superbe conférence de Mario Viviani, simple et efficace pour comprendre rapidement comment utiliser l’API Wear de Google.
Lorsqu’on veut faire communiquer un smartphone et un « wearable », c’est à dire une montre, un bandeau de mesure du pouls etc, il y’a deux classes essentielles:

DataItem

Comme son nom l’indique, cette classe peut contenir des données (jusqu’à 100kb)et fonctionne sur le principe très simple de la réplication. On crée un objet sur le smartphone et il se synchronise sur le wearable. Le tout avec un simple listener, qui permet de savoir quand le nouveau contenu est disponible.
En quelques lignes…
Il faut tout d’abord initialiser le GoogleApiClient, qui va se connecter à Google Services pour faire la connexion:

mGoogleApiClient = new GoogleApiClient.Builder(this)
                .addApi(Wearable.API)
                .addConnectionCallbacks(this)
                .addOnConnectionFailedListener(this)
                .build();

Il est important de bien faire attention à appeler mGoogleApiClient.start() et mGoogleApiClient.stop() dans les méthodes onStart() et onStop() de nos contextes.

Puis, d’écrire, côté émetteur:

    //On crée une requête basée sur un path et une valeur
    PutDataMapRequest dataMap = PutDataMapRequest.create("/count");
    dataMap.getDataMap().putInt(COUNT_KEY, count++);
    PutDataRequest request = dataMap.asPutDataRequest();
    // On indique à l'API Wear que notre DataItem que l'on a wrappé
    // dans une PutDataMapRequest est prêt à être synchronisé
    PendingResult<DataApi.DataItemResult> pendingResult =
        Wearable.DataApi.putDataItem(mGoogleApiClient, request);

Côté récepteur:

@Override
public void onDataChanged(DataEventBuffer dataEvents) {
    //On écoute simplement les événements "onDataChanged"
    for (DataEvent event : dataEvents) {
        //selon le type d'événement reçu, on traite
        if (event.getType() == DataEvent.TYPE_DELETED) {
            Log.d(TAG, "DataItem deleted: " + event.getDataItem().getUri());
        } else if (event.getType() == DataEvent.TYPE_CHANGED) {
             Log.d(TAG, "DataItem changed: " + event.getDataItem().getUri());
        }
    }
}

Les Messages

De la même façon, pour envoyer un message, on a besoin d’initialiser le GoogleApiClient. Généralement, on veut envoyer le message à une Node, c’est à dire un wearable. Pour récupérer la liste des objets connectés, on peut appeler cette méthode utilitaire:

private Collection<String> getNodes() {
    HashSet <String>results= new HashSet<String>();
    NodeApi.GetConnectedNodesResult nodes =
        Wearable.NodeApi.getConnectedNodes(mGoogleApiClient).await();
    for (Node node : nodes.getNodes()) {
        results.add(node.getId());
    }
    return results;
}

Puis il suffit d’envoyer le message!

...
byte[] message = new String("Hello Oxiane!").getBytes();

SendMessageResult result = Wearable.MessageApi
    .sendMessage(mGoogleApiClient, node, "path_defini_pour_mon_message", message).await();

if (!result.getStatus().isSuccess()) {
    Log.e(TAG, "ERROR: failed to send Message: " + result.getStatus());
}
...

Une petite précision pour compliqué ce qui semble un peu trop facile: la méthode sendMessage est synchrone! Elle ne retourne pas avant d’avoir envoyé le message.

Côté récepteur, on n’a plus qu’à implémenter la méthode onMessageReceived:

@Override
public void onMessageReceived(MessageEvent messageEvent) {
    if (messageEvent.getPath().equals("path_defini_pour_mon_message")) {
       //j'ai reçu mon message!
    }
}

Pour terminer, Mario nous a présenté une petite librairie de sa conception qui facilite encore plus l’utilisation de l’API wear. Sans avoir pu la tester moi-même,

Première journée du DroidCon Paris 2014 !

Et première présentation sur le support du pulti-écran sur Android.

L’objectif

Qu’est-ce qu’on peut faire avec ce machin ? Pour commencer, le multi écran, c’est pas nouveau, et grâce aux cables HDMI et HML, on peut depuis longtemps diffuser son contenu sur un autre écran – genre j’ai toujours un xperia S alors je sais de quoi je parle quand je dis « depuis longtemps » ;) .
Cette présentation avait pour but de nous montrer l’état de l’art dans deux domaines : les outils physiques (les dongle) et les API.
Propulser son contenu sur un écran déporté, toi aussi développeur tu vas pouvoir le faire, et tu pourras même avoir un affichage sensiblement différent entre ton device et l’écran connecté.

Les moyens techniques du screencast

Aujourd’hui, on parle de deux technologies :

• Miracast
• Chromecast

Chromecast, la solution de Google, permet de se connecter via un réseau wi-fi existant, avec comme point fort : pas besoin d’appareils compatibles.

Miracast est intégré aux devices récents, et permet de se connecter sans avoir de réseau wi-fi existant. Au passage, ça permet un temps de latence très bas, pour une technologie sans fil. Problème potentiel : avoir un écran compatible avec la norme. Cette technologie a pour vocation de s’étendre dans les objets connectés, et doit permettre également de gérer des devices secondaires, comme un clavier, via l’USB Input Back Channel.

Les API Android de screencast

On entre là dans la partie intéressante, qui frise assez sérieusement avec l’expérimentation, un peu comme quand on cause de développement Android Wear ou Google Glass… la doc existe, mais elle est parfois un peu farfelue.
On note quand même que Miracast est disponible sur Android depuis l’API level 17 (4.2).
En gros comment ça marche, on a une classe qui est très proche de Dialog : la classe Presentation du MediaRouter. Il existe une autre classe, mais cette présentation ne s’étendait pas sur le sujet.
Le MediaRouter ramène une « route » de type video, laquelle expose – si il existe – un Display. Ce Display est injecté en paramètre de la Presentation, la méthode .show() fait le reste.

Au final, quelques lignes de code et on est capable de projeter son contenu !
Tout un ensemble de méthodes de callback permettent de gérer le cycle de vie, en particulier les problèmes de connexion.

Dongle Netgear Miracast

Au final, une présentation simple et claire de Xavier Hallade, avec Intel qui est venu en force à ce DroidCon 2014 !

J’ai eu la chance d’assister à la présentation sur la manipulation du byte code sous Android à la Droidcon 2014.

Deux librairies ont été présentées:

Afterburner

Une librairie qui permet d’éviter le code redondant lors de l’écriture de librairies. On peut ainsi injecter un morceau de code à des endroits bien précis, aussi précisément que « dans telle méthode de telle classe et après l’appel de telle méthode ». Par exemple, avec une classe qui ressemble à ça:

public class A {
  private int foo;
  public void bar() {}
  public void foo() {
     bar();
  }
}

On peut donner une valeur à la variable « int foo », dans la méthode « foo() », après l’appel de la méthode « bar() »:
InsertableMethod.Builder builder = new InsertableMethod.Builder( new AfterBurner() );

CtClass classToInsertInto = ClassPool.getDefaultPool().get(A.class.getName());
builder
  .insertIntoClass(A.class.getName())
  .inMethodIfExists("foo")
  .afterACallTo("bar")
  .withBody("this.foo = 2;")
  .elseCreateMethodIfNotExists("public void foo() { this.foo = 2; }")
  .doIt();

Cela reviendrait à écrire:

public class A {
  private int foo;
  public void bar() {}
  public void foo() {
     bar();
     //ADDED by AfterBurner
     this.foo = 2;
  }
}

Alors bien sûr, à priori, on ne voit pas forcément l’intérêt de la chose. Pourquoi s’embêter à injecter quand on peut écrire soi même « this.foo = 2; » dans le corps de sa méthode? Il s’avère que c’est très pratique!
Un petit projet d’implémentation a été présenté sous Android, il permet d’afficher dans les logs tous les appels aux méthode du cycle de vie des activités. Il s’agit de Loglifecycle. Avec une seule annotation sur les activités que l’on veut observer, on obtient dans les logs tous les appels aux méthodes onCreate, onContentChanged, onResume etc.
On peut imaginer tout un tas d’autres cas d’applications pour cette librairie, peut-être même la modification d’un code dont on n’a pas les sources (mais dont on connaît les classes/méthodes)!

Mimic

Mimic est une librairie qui permet, en quelque sorte, d’accéder à l’héritage multiple sous Java/Android. Le principe est de copier coller tous les attributs, constructeurs et méthodes d’une classe A dans une classe B.
Par exemple,

public class A{
    public void foo() {
    }
}

@Mimic(sourceClass = B.class,
    mimicMethods = {@MimicMethod(methodName="foo",mode=MimicMode.AT_BEGINNING)}
)
public class Aprime extends A{
    @Override
    public void foo() {
        super.foo();
    }
}

public class B{
    public void foo() {
        System.out.println("Hello B !");
    }
}

La méthode foo() de Aprime ne fait qu’appeler la méthode foo() de A. Or, comme on a appelé Mimic sur A et qu’on lui a demandé de remplacer « foo », c’est bien « Hello B! » qui sera appelé!

Un problème

Récemment j’ai eu besoin de pouvoir changer facilement et rapidement
la couleur de tous mes boutons et de tous mes titres.

Généralement, on a des images pour nos contrôles ou on utilise des couleurs
depuis le code/storyboard.

Si on le fait par image, on change donc l’image et c’est fini.
Si on utilise des couleurs via le code, on change éventuellement une macro :

//#define activeColor [UIColor redColor]
#define activeColor [UIColor blueColor]

Oui mais personnellement, je préfère définir mes couleurs dans Lire la suite du bllet »

Puisqu’iOS 8 sort bientôt…
voici un lien intéressant à consulter chaque mois pour Lire la suite du bllet »