Tag : Android

07

mai

On ne présente plus Twitter, service de microblogage qui, à l’instar de Facebook, est de plus en plus présent dans les applications mobiles afin de partager des informations avec son réseau social. Son intégration dans nos applications est donc une tâche récurrente que je me propose de décrire. Dans cet article, je m’intéresse à son intégration dans une application Android.

Étape préliminaire : déclarer son application sur Twitter

L’objectif de cette étape est de récupérer les consumer key et consumer secret indispensables à l’authentification de l’application Android. Pour cela, il faut en premier lieu déclarer son application auprès de Twitter. Très important : l’Application Type doit être défini à Browser, ce qui implique de spécifier une URL de retour (Callback URL) valide (n’importe quelle URL valide fera l’affaire, celle-ci pouvant ensuite être modifiée dans l’implémentation), et Twitter doit être utilisé pour l’authentification (la case Use Twitter for login doit nécessairement être cochée). Notez les valeurs de consumer key et consumer secret pour les utiliser dans votre application.

Première étape : récupérer la librairie OAuth

OAuth est un protocole libre qui permet l’authentification à une API sécurisée d’une façon simple et standard. Une implémentation Java d’OAuth est disponible à cette URL. Dans l’onglet Downloads, récupérez les dernières versions de signpost-core.jar et signpost-commonshttp.jar. Ajoutez ces deux fichiers au répertoire libs de votre application Android puis référencez les en tant que librairies dans les propriétés de votre projet. L’utilisation d’OAuth dans votre application requiert évidemment la permission d’accéder à Internet : pensez à ajouter cette permission dans votre Manifest :

<uses-permission android:name="android.permission.INTERNET"></uses-permission>

Deuxième étape : créer les objets communs

CommonsHttpOAuthConsumer mConsumer = new CommonsHttpOAuthConsumer(CONSUMER_KEY, CONSUMER_SECRET);
OAuthProvider mProvider = new CommonsHttpOAuthProvider("http://twitter.com/oauth/request_token", "http://twitter.com/oauth/access_token", "http://twitter.com/oauth/authorize");
mProvider.setOAuth10a(true);

Troisième étape : autoriser l’application

La première chose à faire est de récupérer l’URL qui permettra à l’utilisateur de s’authentifier puis d’autoriser l’application :

String authUrl = mProvider.retrieveRequestToken(mConsumer, CALLBACK_URL);

Une fois cette URL récupérée, il faut présenter à l’utilisateur la page web correspondante. La solution la plus simple consiste à présenter une WebView en utilisant startActivityForResult. La page web affichée demande à l’utilisateur de s’identifier puis d’autoriser l’application. L’URL de retour est appelée  si ces deux étapes sont réussies. Il faut donc intercepter cette URL pour rediriger l’utilisateur vers l’application. Une implémentation possible est donnée ci-dessous :

mWebView.setWebViewClient(new WebViewClient() {
@Override
public void onPageStarted(WebView view, String url, Bitmap favicon) {
    if (url.startsWith(CALLBACK_URL)) {
        Intent data = new Intent();
        data.setData(Uri.parse(url));
        setResult(RESULT_OK, data);
        finish();
    }
}
...
}

Quatrième étape : récupérer les éléments d’authentification

De retour dans l’application, il faut récupérer le token et le token_secret :

@Override protected void onActivityResult(int requestCode, int resultCode, Intent data) {
    if (resultCode == RESULT_OK) {
        Uri uri = data.getData(); String authToken = uri.getQueryParameter(OAuth.OAUTH_TOKEN);
        String authVerifier = uri.getQueryParameter(OAuth.OAUTH_VERIFIER);
        Assert.assertEquals(authToken, mConsumer.getToken());

        // retrieveAccessToken renseigne les éléments token et token_secret de l'objet mConsumer
        mProvider.retrieveAccessToken(mConsumer, authVerifier);
        // Ces deux éléments sont désormais accessibles via les méthodes getToken() et getTokenSecret()
    }
}

Ici, il convient de sauvegarder les éléments token et token_secret pour ne pas les redemander ultérieurement (et ainsi sauter la troisième étape intégralement). En effet, d’après Twitter, ces deux éléments n’expirent pas tant que l’utilisateur ne les révoque pas.

Cinquième étape : poster un message sur Twitter

L’ultime étape consiste à poster un message sur Twitter :

HttpClient client = new DefaultHttpClient();
HttpPost post = new HttpPost("http://twitter.com/statuses/update.json");
final List<BasicNameValuePair> parameters = new ArrayList<BasicNameValuePair>();
parameters.add(new BasicNameValuePair("status", status));
post.setEntity(new UrlEncodedFormEntity(parameters, HTTP.UTF_8));
post.getParams().setBooleanParameter("http.protocol.expect-continue", false);
mConsumer.sign(post);
HttpResponse response = client.execute(post);
int status = response.getStatusLine().getStatusCode();
String reason = response.getStatusLine().getReasonPhrase();
response.getEntity().consumeContent();
if (status != 200) Log.e("Status update failed", reason);

Et voilà ! Si tout s’est bien passé, votre message apparaîtra sur la page Twitter de votre utilisateur. A vous de jouer !

Vincent

25

avr

Jnlf 2012 sur iPhone et Android

Pour cette nouvelle édition des Journées de Neurologie de Langue Française (Jnlf), découvrez l’application qui vous guidera tout au long du congrès. Accédez facilement aux programme, résumés, infos pratiques…

Cette application est désormais compatible avec tous les smartphones Android, Haploid a su tirer profit du HTML5 pour réaliser cette application en optimisant le temps de développement grâce à notre méthode socle tout en tenant compte de la spécificité des principaux terminaux mobiles du marché.

 

Téléchargez l’application sur Google Play ou l’AppStore 

Available on AppStore Get it on Google Play

27

oct

La semaine dernière, en grandes pompes, Google et Samsung ont présenté Android   »Ice Cream Sandwich » et le Samsung « Galaxy Nexus » à Hong Kong. Toute proportion gardée, il s’agit d’un tournant majeur dans l’évolution du système.

Depuis les versions Android 1 puis 2, Google a fait évoluer un système mobile fonctionnel conçu essentiellement pour les smartphones. Critiqué souvent pour son manque d’ergonomie, il a néanmoins eu l’avantage de proposer une grande flexibilité dans le développement et son utilisation.

Android 3 a été présenté en janvier 2011, conçu à la hâte pour contrer l’arrivée de l’iPad en rendant Android accessible sur des écrans plus grands, notamment la tablette Xoom de Motorola (et éviter de se retrouver avec un « gros » téléphone comme l’a pu l’être la première GalaxyTab de Samsung équipée d’Android 2.2).

Avec la version 4, Android fait la synthèse entre l’interface smartphone et les avantages de la tablette. Le système se veut donc plus souple que jamais dans l’utilisation de son éco-système (smartphone, tablette et télévision demain). Avantage direct : une accessibilité et un apprentissage de le philosophie de l’OS facilité pour l’utilisateur.

 

Concrètement, il s’agit plus d’un portage de Android 3 « Honeycomb » sur smartphone que d’une réelle révolution du système.

 

La grosse déception est le déplacement de la status bar qui, sur tablette, se transforme en une grosse bar de « menu démarrer » à la Windows en bas de l’écran. L’accès aux menus de configuration et aux réglages est très différente (comme Android 3 Honeycomb), il est difficile d’adopter rapidement des automatismes quand on est depuis longtemps utilisateur d’Android version smartphone.

 

 

Qu’est ce qui va changer pour les utilisateurs ?

 

Au final, pas de grands changements. Les utilisateurs de smartphones Android verrons une nouvelle interface plus aérée habillée de bleu et de noir. On joue une nouvelle fois la carte de la sobriété héritée de la philosophie Google.

 

L’interface est plus dynamique, boostée par les performances des équipements récents, de nouvelles interactions rendent l’utilisation d’Android plus fluide :

  • réorganisation des bureaux
  • création de dossiers
  • ajout des widgets
  • centralisation des applications et des widgets dans un même menu

La nouvelle typographie « Roboto » est la touche finale qui fait la différence, déjà critiquée mais qui justifie à l’OS une certaine maturité. Elle facilite néanmoins la lecture, notamment sur les écrans à forte densité de pixels (dpi) et les tablettes.

Côté fonctionnalités techniques on retrouve l’intégration par défaut des derniers outils Google : NFC/Google Wallet, Google+ (synchronisation des photos en ligne sur les serveurs de Google), une meilleure gestion du Bluetooth, de la batterie et de la consommation « data ».

Enfin, autre élément notable, les boutons physiques ne sont plus indispensables physiquement, les applications pourront utiliser les icones natives en fonction de leur utilité.

La prochaine étape ?
  • Une vraie cohérence d’utilisation (entre un écran de grand taille et un smartphone : statusbar et menu démarrer) ?
  • Une nouvelle version d’Android pour la télé sans doute en 2012 ?
  • Des profils utilisateur, quand on sait qu’une tablette est généralement utilisée par plusieurs personnes d’un même foyer ?

 

Des profils utilisateurs ?

Le smartphone et la tablette sont voués à être utilisable ensemble, dans un univers qui doit être partagé entre les deux périphériques. Ice Cream Sandwich commence à répondre à cette problématique. Il manque maintenant à basculer complètement dans cette convergence en misant sur l’interactivité. Partage de contenu, envoi en temps réel d’url, d’informations, de photos, d’un écran déporté pour regarder une vidéo, interagir avec un flux vidéo en direct avec son smartphone synchronisé avec la tablette.

Haploid travaille sur cette vision de l’évolution des systèmes mobiles. Nous sommes d’ores et déjà compatible avec Android 4 et travaillons nos applications dans une logique de complémentarité entre les différents équipements.

Pour en savoir plus :
Présentation détaillée d’Android 4.
Interview de  Matias Duarte, designer d’Android 4, sur la philosophie d’Ice Cream Sandwich.

SUIVEZ-NOUS