Les terminaux mobiles sont partout
Il y a de cela plus de dix ans, alors que nous assistions à une conférence "Microsoft Professional Developers", nous avons visionné une vidéo à propos du l'avenir du mobile. La vidéo futuriste présentait des téléphones fonctionnant sous Windows, utilisés pour des tâches telles que la localisation du médecin le plus proche. À une époque où le Palm VII était ce qui se rapprochait le plus d'un smartphone, la vidéo présentait un avenir impressionnant.
Avance rapide en 2013 : Aucun doute, nous vivons dans ce futur. Les smartphones et autres terminaux mobiles sont partout. Ils sont disponibles à différents niveaux de prix et sont de plus en plus abordables. En fait, pour beaucoup, dans les pays en développement, leur seul ordinateur est le puissant smartphone qu'ils possèdent.
Développement d'applications mobiles : prévisions de croissance de Gartner
Gartner prédit i que d'ici 2016, au moins 50 pour cent des utilisateurs de messagerie d'entreprise n'utiliseront plus qu'un navigateur, une tablette ou un client mobile en lieu et place d'un client riche.
Compte tenu de la croissance de l'adoption des appareils mobiles, il est également prévu que le développement d'applications mobiles ciblant ces terminaux, va considérablement augmenter dans les prochaines années. Encore une fois, Gartner prévoit que d'ici 2015, les projets de développement d'applications mobiles pour les smartphones et tablettes seront plus nombreux que les projets PC pour un ratio de 4 pour 1. En outre, Gartner indique que les smartphones et tablettes vont représenter plus de 90 pour cent de la croissance nette de l'adoption des terminaux au cours des quatre prochaines années.
L'App Store d'Apple compte désormais plus de 500.000 applications. Android dispose à peu près du même nombre, et le Windows Phone Marketplace, un concurrent beaucoup plus récent, vient de franchir récemment le cap des 50.000 et croît à un rythme rapide.
Secteur des applications mobile : le défi posé par la fragmentation
Compte tenu de ce contexte plutôt excitant, nous pouvons être certains, que dans un futur immédiat, la plupart des gammes d'applications seront disponibles pour les plateformes mobiles. Comme pour toute autre opportunité, le développement d'applications mobiles, avec toutes ses promesses, apporte ses propres défis.
Un des principaux défis est la question de la fragmentation. Les estimations du troisième trimestre 2012 ont indiqué que le marché des systèmes d'exploitation mobiles est très fragmenté. Les variantes d'Android ont représenté environ 72% des appareils vendus au cours de ce trimestre. iOS représentait environ 14%. Research in Motion (RIM / Blackberry) représentait environ 5% et la plateforme Windows Phone, environ 2% (Sources Gartner).
Développer une gamme d'applications qui fonctionne sur tous ces terminaux, implique de travailler avec des technologies très différentes :
Plateforme | Plateforme de développement principale | Langage de développement principal | IDE principal | Plateformes de développement |
---|---|---|---|---|
Android | Java (basé sur) | Java | Eclipse | Windows, Mac OSX, Linux |
iOS | Framework Cocoa Touch | Objective-C | X-Code | Mac OSX |
RIM | Java ME | Java | Eclipse | Windows, Mac OSX |
Windows Phone 8 | .NET/native | C#/C++ | Visual Studio | Windows |
Les plateformes, langages et outils concernés sont très différents, et les efforts nécessaires à la production d'une solution fonctionnant sur toutes les plateformes, sont considérables.
Il est intéressant de noter, qu'il existe une fragmentation importante au sein même de certaines de ces plateformes. C'est tout particulièrement vrai pour la plateforme, actuellement dominante, Android. Etant donné qu'Android est ouvert et que les fournisseurs sont libres d'apporter leurs propres modifications, il y a sur le marché, aujourd'hui, littéralement des centaines d'appareils basés sur Android. Un bon nombre d'entre eux, ne travaillent uniquement qu'avec des niveaux spécifiques de l'API Android. Certains, parmi eux, ont des problèmes avec des applications ciblant certaines fonctionnalités, même avec un niveau d'API pris en charge (supporté). En résumé, la fragmentation du marché mobile ne diminue pas. Cela rend la réalisation d'applications natives multi-plateformes assez difficile.
Les applications web mobiles : la solution à la fragmentation ?
Les applications web sont une alternative aux applications natives. Tous les plateformes mobiles importantes offrent des navigateurs très puissants. De plus, à l'exception du navigateur de Windows Phone, la plupart des navigateurs des autres plateformes sont basés sur le navigateur open-source WebKit, qui est le composant principal de Safari d'Apple et de Google Chrome. Il apporte un excellent support de Javascript sur les navigateurs de ces plateformes; jQuery est entièrement pris en charge sur les appareils mobiles les plus récents. En outre, une conformité croissante avec HTML 5 et les standards Web connexes rend le navigateur encore plus attrayant en tant que plateforme de développement. Il est possible de construire des sites web très fonctionnels qui fonctionnent très bien sur les appareils mobiles avec la technologie disponible aujourd'hui.
Les applications web mobiles : considérations supplémentaires
Construire un site web mobile n'offre pas la même expérience qu'une application native. Les utilisateurs de plateformes matérielles spécifiques sont habitués à l'expérience améliorée offerte par les applications natives. Ces applications sont installées en mode natif et sont toujours disponibles sur le "launcher" (lanceur d'applications) de l'appareil. Les applications natives respectent également des règles d'interface utilisateur spécifiques à l'appareil. Par exemple, sur Android, le bouton du menu de gauche affiche généralement un menu contextuel. Les utilisateurs sont habitués à ceci et l'attendent. Les applications Web peuvent être installées comme des raccourcis sur le lanceur pour la plupart des appareils, mais ils n'obéissent pas aux règles de l'interface utilisateur spécifiques au terminal concerné. Un autre inconvénient pour les applications web, c'est qu'elles n'ont pas d'accès natif aux matériels en dehors de ce qui est exposé par HTML et les normes web associées. Par exemple, il n'y a pas d'accès direct aux contacts, images ou à l'appareil photo de l'appareil. Pour de nombreuses applications, l'accès aux principaux éléments matériels du terminal est importante.
Les applications hybrides : le meilleur du web et des applications natives
Les applications hybrides sont des applications natives à part entière, qui embarquent un contrôle "navigateur web" spécifique à la plateforme considérée. Il existe un contrôle "navigateur web" pour toutes les plateformes mobiles majeures, dont Android, iOS, Windows Phone 8, et Blackberry / RIM. Comme le socle de l'application est entièrement natif, bien souvent, les utilisateurs ne savent même pas qu'ils utilisent une application web. Il est ainsi, tout à fait possible pour l'application de fournir une expérience utilisateur de navigation identique à une navigation native.
Il est également possible pour les pages web affichées dans le navigateur, d'interagir avec le matériel grâce à un "pont" Javascript, disponible pour chacune des plateformes majeures. L'utilisation de ces appels à la plateforme native permet d'accéder aux contacts, capturer ou sélectionner des images, lire des médias. En fait, tout ce qui peut être fait avec du code natif, peut l'être avec le pont Javascript. Le code du pont devra bien entendu être ré-écrit pour chacune des plateformes cibles, mais ce n'est généralement qu'une petite partie de l'ensemble du code de votre application.
En outre, plusieurs frameworks de "pont" Javascript existent, le plus populaire étant le projet open source PhoneGap, qui fournit une partie substancielle de cette plomberie. Nous n'utiliserons ici aucun framework. Nous allons à la place illustrer le concept avec un simple "wrapper" Android.
ASP.NET MVC: un framework éléguant pour votre backend
Les applications hybrides peuvent être construites avec n'importe quel backend web, mais nous sommes fermement convaincus qu'ASP.NET MVC est idéalement adapté ii à la mise en oeuvre d'applications hybrides. Voici quelques aspects qui font qu'ASP.NET MVC est un bon choix pour de telles applications.
Séparation nette des responsabilités
La séparation claire des responsabilités offerte par l'environnement MVC permet d'avoir un contrôle très précis du rendu HTML. Cela permet de générer très facilement du code HTML à destination des mobiles. L'indépendance des tiers Contrôle et Modèle, facilite la maîtrise du code HTML produit.
Partager plus de code entre les clients web "de bureau" ou tablette
Si vous avez une application ASP.NET MVC existante qui cible les navigateurs de bureau, une grande partie du code peut être partagée avec votre application mobile. La majeure partie du code du contrôleur et du modèle peut être partagée. Seule la vue doit être changée. Il n'est pas difficile de spécifier une vue personnalisée pour les clients mobiles, même avec la version actuelle d'ASP.NET MVC, mais la prochaine version d'ASP.NET MVC rend ceci encore plus simple. Pour plus de détails sur les caractéristiques mobiles dans la prochaine version d'ASP.NET MVC, vous pouvez vous référer à ASP.NET MVC.
Une friction minimale avec le modèle de développement Web sous-jacent
ASP.NET MVC ne construit pas plusieurs couches d'abstraction par desssus les applications web "stateless" (sans état). À la place, il offre un modèle très simple qui fonctionne parfaitement avec la plateforme existante, ce qui facilite grandement les appels AJAX ou l'utilisation de jQuery au niveau client. Nous n'avons pas à nous préoccuper d'abstraction complexe telle le "ViewState" des WebForms d'ASP.NET.
En plus de ce qui précède, il est important de rappeler que les couches métier et d'accès à la base de données, qui existent déjà dans vos applications .NET actuelles, peuvent être efficacement réutilisées dans des application ASP.NET MVC. ASP.NET MVC est totalement agnostique sur les couches métier et de base de données et peut travailler efficacement avec n'importe quel système actuellement en place.
Exemple d'application hybride
Nous allons maintenant étudier un exemple très simple pour illustrer le développement de bout en bout d'une application hybride en utilisant la plateforme ASP.NET MVC. L'exemple affiche des informations sur les étudiants qui fréquentent une université fictive nommée Contoso University. Il y a deux liens vers des informations générales ainsi que l'accès à un répertoire d'étudiants où les élèves peuvent être retrouvés par leur nom.
Afin de maintenir la simplicité de l'exemple, il n'implémente pas la sécurité ou la gestion des erreurs. Il n'y a pas de code complexe puisque l'objectif de l'exemple n'est pas de démontrer la puissance de la plate-forme ASP.NET MVC, mais de démontrer sa pertinence en tant que plateforme de backend pour le développement d'applications mobiles natives hybrides.
Le code complet de cet exemple est disponible à bit.ly/mvc-native-mobile-apps.
Les prérequis pour utiliser le code d'exemple:
- ASP.NET MVC 3 avec Visual Studio 2010 (toutes versions, y compris l'édition Express).
- Une installation fonctionnelle du SDK Android et du plug-in Android Development Tools pour Eclipse.
- Les instructions détaillées et les prérequis sont disponibles ici : http://developer.android.com/sdk/index.html.
- jQuery et jQuery Mobile. Une copie locale n'est pas nécessaire puisque le code de l'exemple fera simplement référence au CDN jQuery.
Le backend ASP.NET MVC
Dans l'exemple de code fourni, _Layout.cshtml contient les références de script vers les librairies jQuery et jQuery Mobile. Elles ne sont pas obligatoires pour construire une application mobile ASP.NET MVC, mais elles se chargent d'une grande partie du travail de base. Nous utilisons jQuery Mobile dans notre exemple pour simplifier le formattage du contenu pour terminaux mobiles.
<link rel="stylesheet" href="http://code.jquery.com/mobile/1.0/jquery.mobile-1.0.min.css" />
<link href="@Url.Content("~/Content/Site.css")" rel="stylesheet" type="text/css" />
<script type="text/javascript" src="http://code.jquery.com/jquery-1.6.4.min.js"></script>
<script type="text/javascript" src="http://code.jquery.com/mobile/1.0/jquery.mobile-1.0.min.js"></script>
La plupart des client web mobiles supposent qu'une page web a une taille d'environ 900 pixels et est automatiquement mise à l'échelle pour afficher la totalité de cette page sur le terminal. Avec un site mobile optimisé pour un appareil plus petit, nous pouvons fournir une indication pour que l'appareil ne change pas l'échelle, mais plutôt utilise toute la largeur du terminal. Ceci est accompli grâce à l'utilisation de la balise meta viewport comme indiquée ci-dessous:
<meta name="viewport" content="width=device-width, initial-scale=1.0 ">
La méthode d'action par défaut index
du contrôleur "home" est associée à la vue suivante:
<nav >
<ul id="menu" data-role="listview">
<li>@Html.ActionLink("About Us", "AboutUs", "Home")</li>
<li>@Html.ActionLink("Contact Us", "ContactUs", "Home")</li>
<li>@Html.ActionLink("Student Directory", "StudentDirectory", "Home")</li>
</ul>
</nav>
Nous avons une simple liste non ordonnée avec trois liens d'action. Nous spécifions que la vue doit être automatiquement formatée à l'exécution comme une "list view" par jQuery Mobile, grâce à la valeur de l'attribut data-role="listview"
. C'est tout ce qui est nécessaire pour afficher l'interface utilisateur de démarrage sur un appareil mobile, comme ci-dessous.
Figure 1. Écran de démarrage
Le runtime jQuery Mobile prend soin de le formater comme une "list view". Comme mentionné précédemment, jQuery Mobile n'est pas nécessaire. Vous pouvez choisir le format et l'approche de script qui convient le mieux à vos besoins.
L'exemple contient les vues affichées lorsque les options "About Us" ou "Contact Us" sont invoquées. Ces écrans sont simples et ne nécessitent pas de plus amples explications.
Figure 2. Écran initial de l'annuaire des étudiants
En cliquant sur un élément de la liste, une liste d'étudiants s'affiche comme on peut le voir ci-dessous :
Figure 3. Annuaire des étudiants
Les vues de l'annuaire des étudiants sont également assez simples. Elles itérent puis affichent les données dans une liste. La vue affichant les détails d'étudiants est illustré ci-dessous.
@{
ViewBag.Title = "Student Directory";
Layout = "~/Views/Shared/_Layout.cshtml";
var random = new Random();
}
<ul data-role="listview">
@foreach (string student in ViewBag.Students)
{
<li>
@{var number = random.Next(1000, 9999); }
<img src="@Url.Content("~/Content/images/UserImages/80-80/" + student + ".jpg")" alt="@student"/>
<h3>@student</h3>
<h4>919-555-@number</h4>
</li>
}
</ul>
C'est une bonne idée de lancer le backend ASP.NET MVC dans un navigateur de bureau et de le tester avant de procéder à l'examen du "wrapper" Android sur lequel nous allons travailler par la suite.
Vous pouvez également faire le test directement sur un navigateur mobile fourni par le site de test accesible à partir de votre terminal de test. Si le PC de développement et votre terminal de test sont sur le même réseau, il est possible de changer les réglages du navigateur de développement d'ASP.NET ou de IIS Express, pour permettre l'accès à l'application web par votre terminal de test. Cet accès est bloqué par défaut.
Une approche alternative plus facile consiste à utiliser un proxy qui redirige simplement le trafic sur un port externe pour le serveur interne. C'est l'approche que nous utilisons souvent. Le proxy que nous utilisons est téléchargeable sur GitHub iii.
"Wrapper" Android
Le code du "wrapper" Android qui embarque l'application web à l'intérieur de l'application native Android est reproduit ci-dessous:
package com.syncfusion.contoso;
import android.app.Activity;
import android.os.Bundle;
import android.util.Log;
import android.view.KeyEvent;
import android.view.View;
import android.webkit.WebView;
import android.webkit.WebViewClient;
public class ContosoActivity extends Activity {
WebView mWebView;
private class ContosoWebViewClient extends WebViewClient {
@Override
public boolean shouldOverrideUrlLoading(WebView view, String url) {
view.loadUrl(url);
return true;
}
}
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
mWebView = (WebView) this.findViewById(R.id.webview);
// Disable scrollbars
mWebView.setVerticalScrollBarEnabled(false);
mWebView.setHorizontalScrollBarEnabled(false);
// Scrollbar Overlay Content
mWebView.setScrollBarStyle(View.SCROLLBARS_INSIDE_OVERLAY);
mWebView.getSettings().setJavaScriptEnabled(true);
mWebView.getSettings().setAppCacheEnabled(false);
mWebView.loadUrl("http://your-web-link");
mWebView.setWebViewClient(new ContosoWebViewClient() );
}
@Override
public boolean onKeyDown(int keyCode, KeyEvent event) {
if ((keyCode == KeyEvent.KEYCODE_BACK) && mWebView.canGoBack()) {
mWebView.goBack();
return true;
}
return super.onKeyDown(keyCode, event);
}
}
Le code est assez simple à suivre.
WebView
est l'équivalent Android du contrôle WebBrowser. C'est un "wrapper" du navigateur Android par défaut basé sur WebKit.- Nous obtenons un accès à une instance du contrôle Android
WebView
(défini dans un fichier XML de description et instancié à l'exécution par le runtime Android). - Nous activons l'utilisation de JavaScript par l'instance de cette
WebView
, car JavaScript est désactivé par défaut. - Nous faisons alors quelques ajustements pour désactiver l'affichage de base des scrollbars pour imiter le look and feel d'une application native.
- Nous chargeons ensuite l'application web à l'aide d'un appel à l'API
loadUrl
, dans l'instance de laWebView
. Vous devez changer"http://your-web-link"
pour pointer vers votre application web. - La dernière section de code gère le bouton matériel de retour, déclenchant la navigation de la WebView intégrée vers la page précédente.
Comme vous pouvez le voir, ce code n'est pas lié directement à l'application web et ne changera pas considérablement d'une application à une autre. Vous aurez seulement besoin d'ajouter du code supplémentaire lorsque vous aurez besoin d'accéder à des fonctionnalités spécifiques du matériel. Nous ne creusons pas plus le sujet dans cet article, mais si vous souhaitez aller plus loin, vous pouvez consulter les informations sur la méthode addJavascriptInterface
de la WebView.
Par souci de simplicité, nous avons uniquement décrit le "wrapper" Android. Des "wrappers" similaires et autres mécanismes d'extension existent sur toutes les plateformes mobiles majeures.
Figure 4. La page Contact Us affichée sur un émulateur Android 4.0, à l'intérieur d'une application native
Conclusion
Les applications hybrides représent une solution très prometteuse qui mérite d'être étudiée pour tout type d'application mobile. Elles ne sont pas adaptées pour des scénarios où une utilisation intensive du matériel natif est nécessaire (comme les jeux), mais fonctionnent très bien dans la plupart des autres scénarios. Toute solution réalisée avec un "backend" web est également susceptible d'être eligible. La norme HTML a évolué doucement au fil des ans et est peu susceptible de changer de façon spectaculaire comme les solutions propriétaires peuvent souvent le faire. Elle offre une base stable sur laquelle les applications peuvent être construites avec la certitude qu'elles continueront à fonctionner dans un avenir prévisible. Les fournisseurs de plateformes mobiles ont déployé d'extraordinaires efforts dans la mise en oeuvre d'HTML 5 et les normes associées. Cela servira aussi à construire des applications web plus puissantes et capables d'accomplir une partie importante de ce qui est possible avec les applications natives.
Vous pouvez tirer parti de vos compétences en développement .Net et produire des solutions puissantes qui fonctionnent sur un large éventail de terminaux. Chez Syncfusion, nous sommes excités par l'immense potentiel offert par les applications hybrides.
A propos de l'Auteur
Daniel Jebaraj, en tant que vice-président, dirige les développement de produits chez Syncfusion. Daniel supervise la globalité du développement produit et planifie les versions spécifiquement. En s'engageant activement avec les clients, Daniel garantit que chaque nouveau produit bénéficie d'améliorations basées sur les retours d'informations des clients. Auparavant, en tant que vice-président du développement, Daniel était concentré sur la conduite du développement des produits chez Syncfusion. Avant de rejoindre Syncfusion en 2001, Daniel a dirigé des équipes de développement chez Rogue Wave Software. Daniel est titulaire d'une maîtrise en génie industriel de l'Université de Clemson.