La « Google Experience » telle qu’elle s’invite dans la rumeur depuis quelques jours devrait être confirmée d’ici peu par Mountain View. Dès à présent pourtant, Scott Main et David Braun, chez Google, indiquent aux développeurs comment « préparer leur application SMS pour KitKat« .
La team de Google s’adresse aujourd’hui aux développeurs qui utilisent des API (Application Programmation Interface) cachées pour construire leur propre application SMS (ex : le ContentProvider content://sms/sent). Le risque est multiple : pour chaque nouvelle version du système ou pour chaque constructeur venant modifier la base Android, la compatibilité n’est pas assurée.
Scott Main et David Braun confirment dans leur post sur le blog android-developers non pas l’intégration des SMS dans Hangouts à proprement parler, mais celle d’une application SMS par défaut que l’utilisateur pourra modifier dans les paramètres de son appareil. En parallèle, Google clarifiera la situation en mettant à disposition des APIs publiques utilisables par tous. Des modifications s’imposent par conséquent « pour que les applications continuent à fonctionner lorsque Android 4.4 sera déployé plus tard dans l’année« .
Concrètement, une seule et unique application pourra recevoir les nouveaux Intent (= message) SMS_DELIVER_ACTION et WAP_PUSH_DELIVER_ACTION, car désormais une seule application pourra être sélectionnée par l’utilisateur pour répondre à chacune de ces actions. Les autres applications devront, quant à elles, se contenter de l’Intent SMS_RECEIVED_ACTION qui permet uniquement de recevoir les messages, mais pas d’en rédiger. Google met en garde les développeurs afin qu’ils mettent rapidement à jour leurs applications, sans quoi elles ne pourront plus envoyer des SMS. L’utilisateur ne sera toutefois pas perturbé, car l’ancienne méthode affichera simplement une erreur.
Concrètement, les développeurs devront implémenter dans leur application :
- Dans un BroadcastReceiver, ajouter un Intent-Filter pour SMS_DELIVER_ACTION, sans oublier la permission BROADCAST_SMS dans l’AndroidManifest pour recevoir les SMS.
- Toujours dans un BroadcastReceiver, ajouter un Intent_filter pour WAP_PUSH_DELIVER_ACTION (android.provider.Telephony.WAP_PUSH_DELIVER) avec le MIME-type (application/vnd.wap.mms-message). La permission BROADCAST_WAP_PUSH sera également requise, ici dans le but de recevoir des MMS.
- Dans votre Activity, un Intent-Filter pour ACTION_SENDTO (android.intent.action.SENDTO) avec les schémas sms:, smsto:, mms: et mmsto: sera nécessaire afin qu’elle reçoive les Intents des autres applications qui veulent envoyer un message.
- Dans un service, ajouter l’Intent-Filter ACTION_RESPONSE_VIA_MESSAGE (android.intent.action.RESPOND_VIA_MESSAGE) avec les mêmes schémas. La permission SEND_RESPIND_VIA_MESSAGE suivra. Cela permettra ainsi de répondre aux appels avec un SMS (fonctionnalité d’Ice Cream Sandwich).
D’autres conseils peuvent être utiles aux développeurs, notamment la désactivation de certaines fonctionnalités lorsque l’application n’est pas utilisée comme messagerie par défaut. L’application ne disposant plus de la capacité à écrire au SMS Provider, elle devra masquer cette possibilité en fonction de la réponse renvoyée par la méthode Telephony.Sms.getDefaultSmsPackage(). Ces modifications concernent également les applications de type Sauvegarde et Restauration de SMS qui devront demander temporairement les droits, avant de les retourner à l’application par défaut.
Un tel billet, s’il a le mérite de rappeler des notions de développement utiles aux créateurs d’applications de messagerie, rappelle surtout un fait : l’Experience telle que l’aura définie Google dans son Android 4.4 KitKat promet de revoir une partie des fonctionnements auxquels l’utilisateur final était habitué, mais aussi et surtout de donner du fil à retordre aux concepteurs d’applications indépendantes venant concurrencer les applications créées par Google.
Google conclut son billet en indiquant qu’un SDK sera proposé très prochainement pour tester ces nouveautés. Aura-t-on droit à une sortie avant l’annonce officielle sur les terminaux comme ce fut le cas pour Honeycomb ou Cupcake ?
Si vous voulez recevoir les meilleures actus Frandroid sur WhatsApp, rejoignez cette discussion.
Sors de la , troll!
Didn't read. LOL
Je tiens à préciser que c'est ce que j'ai retenu en lisant l'article dont il est question ici en diagonale hier soir. Il est possible que tout ne soit pas parfaitement exact. ;-)
Super, merci beaucoup pour les corrections, je n'aurais pas osé demander mieux. Un truc en moins de pas clair dans ma tête.
Mais sinon, je confirme, l'a fin de l'article est parfaitement fausse : les développeurs tiers sont désormais en bien meilleure position pour fournir leur propre remplacement à l'application SMS. Si effectivement la transition va demander un peu de boulot, ça reste raisonnable, et la suite n'en sera que meilleure…
N'importe quelle application ayant la permission nécessaire était jusqu'à maintenant capable d'envoyer un SMS via l'API correspondante, documentée. Les SMS envoyés de cette manière n'étaient par contre pas stockés sur le téléphone, et donc pas visibles depuis l'application SMS de base, par exemple. Cela dit, l'application SMS met à disposition un ContentProvider public, bien que non documenté. À partir de là, deux possibilités jusqu'à maintenant : - Envoyer ses SMS via l'API documentée, stocker ses SMS à la main, mais être limité à sa propre application (l'utilisateur ne voit pas les SMS envoyés via cette application sur l'application de base) - Utiliser le ContentProvider non documenté, et risquer que ça pète à chaque mise à jour. Dans tous les cas, l'API a toujours été publique (elle se présentait déjà sous la forme d'un ContentProvider), mais elle n'était pas considérée comme telle : elle était susceptible de changer d'une version à l'autre sans avertissement. Ils profitent de cette mise à jour pour mettre en place quelque chose de standardisé, documenté. Fondamentalement, ça va pas changer grand chose, ce qui était déjà possible le sera toujours, simplement de manière plus robuste.
C'est bien technique et il faudrait demander à un dev mais je pense qu'il y a quelques erreurs d'interprétation de la source. Je me trompe peut être mais je crois me souvenir que jusqu'à présent, seul l'appli SMS de base avait le droit d'envoyer des SMS et que les autres devait passer par cette appli de base. Si je comprends bien (et j'espère me faire corriger si c'est faux) la différence avec ici c'est que n'importe quelle appli peut servir d'interface (comme avant) et en plus, n'importe quelle appli peut servir à envoyer les messages. En gros, google a fait une API là où avant c'était une fonction inclue dans une appli donc ça va bien simplifier la vie des devs (là pour le coup j'en suis sûr et l'article se plante).
Donner du fil à retordre ??? Je pense qu'au contraire, cette API clarifie les choses et assure aux développeurs qu'elle ne disparaîtra pas du jour au lendemain. Bref, plutôt du positif pour les développeurs !
On veut une release nous bordel !!! lol
Ce contenu est bloqué car vous n'avez pas accepté les cookies et autres traceurs. Ce contenu est fourni par Disqus.
Pour pouvoir le visualiser, vous devez accepter l'usage étant opéré par Disqus avec vos données qui pourront être utilisées pour les finalités suivantes : vous permettre de visualiser et de partager des contenus avec des médias sociaux, favoriser le développement et l'amélioration des produits d'Humanoid et de ses partenaires, vous afficher des publicités personnalisées par rapport à votre profil et activité, vous définir un profil publicitaire personnalisé, mesurer la performance des publicités et du contenu de ce site et mesurer l'audience de ce site (en savoir plus)
Gérer mes choix