
Ce matin j'ai assisté à une présentation de Rogers et
RIM au sujet du développement d'application pour Blackberry. Tout d'abord, je dois dire que je ne m'attendais à rien... dans le fond, j'y allais pour le déjeûner et le dîner, sur le bras de Rogers!
Finalement, j'ai été agréablement surpris. Non pas que je deviens un crinqué du développement sur BB, mais plutôt que je comprends nettement mieux comment on doit s'y prendre... et on était dans le champ!
La présentation était faite par Brent Thornthon, de RIM. Il a trouvé l'autidoire un peu... disons... froid. M'enfin, comme l'a dit un participant, peut-être était-ce la barrière de la langue, Brent étant uniligue anglophone... Malgré tout, j'ai profité des quelques pauses pour l'assaillir de questions (comme mes collègues d'ailleurs).
Je ne suis pas un amateur de ces petits écrans aux capacités limitées, à la bande passante anémique et aux contraintes majeures. Et quand on a dû migrer, il y a plusieurs mois, une application Web développée en Java pour qu'elle fonctionne également sur ces petites bébelles pathétiques, j'ai plus d'une fois récité le chapelet!
Or, je dois faire mon mea culpa... Tout est dans la façon de s'y prendre. Tout d'abord, de prendre une application Web et de la faire fonctionner directement dans le navigateur du BB était... disons... une grave erreur de notre part. C'est entièrement dû à notre méconnaissance du produit.
Bien que, pour certains, ce dont je vais parler ici est du connu, je dois dire que ce n'était pas le cas chez nous lorsque l'on a commencé à travailler avec les BB et que ça aurait été bien utile de connaître un peu plus l'environnement. M'enfin, vaut mieux tard que jamais, non? Peut-être était-ce là un manque d'effort de notre part, ou bien que nous ne cherchions pas au bon endroit... Mais nous avons appris de nos erreurs, et je veux l'éviter aux autres!
Revoir notre approche face à l'envoi de données
Ces appareils, quels qu'ils soient, nécessitent des soins particuliers. Entre autre, au niveau de l'envoi des données... on va privilégier une approche en push plutôt qu'en pull. Ce que ça veut dire, c'est qu'on doit penser envoyer la données sur l'appareil alors que celui-ci est en état de le recevoir.
L'avantage est double: on facilite l'utilisation des dites données et on augmente la longévité de la batterie, le BB étant en mode réception plutôt qu'émission!
Bon, il faut donc revoir complètement notre façon de faire. Traditionnellement, nous n'envoyons des données que lorsque le poste client les demande (sauf avec AJAX, je sais...), c'est un genre de conversation. Pour ce qui est du BB, il semblerai que ce soit mieux de faire un monologue, du serveur à l'appareil...
Trois approches de développement
Lorsque l'on décide de faire du développement pour les BB, il y a trois grandes approches, soit:
- Utilisation du navigateur interne
- Développer avec MDS Studio (un genre de SDK)
- Développer Java mur à mur
Utilisation du navigateur interne
Pour ce qui est de l'application que nous avons développé, nous avons pris la première approche... ce qui était une mauvaise idée!
Le navigateur BB est un simulacre de navigateur. Il ne supporte pas toutes les propriétés CSS, ni même la structure de celles-ci. Il a beaucoup de difficulté avec le javascript. Bref, il a fallu créer deux applications parallèles, soit une pour les ordinateurs et une autre pour les BB. Ça fait le double de code à maintenir.
Brent a mentionné ce problème, qui semblerait assez commun. Peut-être aurait-il mieux valu regarder du côté des autres options...
Développer avec MDS Studio (un genre de SDK)
MDS Studio, ou le plug-in MDS Studio pour Microsoft Visual Studio, permettent de développer rapido des petites applications résidentes sur le BB. Et c'est assez rapide pour qu'il ait pu en faire une en moins de 2 minutes! en direct!
C'est une approche intéressante, dans la mesure où:
- On a une approche de services Web dans l'organisation;
- On a l'infrastructure suffisante;
- Nous sommes prêts à être confinés à l'univrers BB uniquement (pas de Palm ou autres ordinateurs de poche, car ce n'est pas compatible)
- Nous sommes prêts à revenir avec une approche près du client serveur (plutôt que le client léger Web)
L'avantage d'un développement avec MDS, c'est que c'est du RAD pour BB. On se branche sur le bon service Web (protocol SOAP - mais je ne suis pas très ferré là dedans), et ça fonctionne pratiquement tout seul (vive les démos live! ça fonctionne toujours tout seul... dans la mesure où l'émulateur ne plante pas, ce qui est arrivé au pauvre Brent!)
Développer Java mur à mur
La troisième approche, et non la moindre, est de faire du développement Java. Une application Java. BB est basé sur ce langage et permet donc beaucoup de choses. Or, c'est aussi plus complexe que l'utilisation du MDS.
Une autre approche
Il est aussi possible de faire affaire avec des logiciels tiers, développés par des partenaires. On a alors accès à des applications qui sont en mode fureteur, MDS ou en Java, selon le type et le fournisseur.
Une décision à prendre
La véritable question à se poser c'est: doit-on vraiment développer pour le BB? Si oui, quelle approche privilégier?
Désire-t-on avoir des applications qui soient portables d'un appareil et d'un fournisseur à l'autre? Veut-on être dépendant du BB? Désirons-nous avoir des applications complexes qui interagiront avec le système d'exploitation du BB?
Personnellement, je ne suis pas en mesure de faire de tels choix pour mon organisation. Je ne suis pas un décideur, seulement un exécutant. On verra bien quel sera le choix de mes supérieurs...
Libellés : blackberry, développement