En observant depuis un certain moment l’évolution des technologies et plateformes actuelles, je me rends compte que le business modèle en ce qui concerne le développement et la publication des applications est en train de s’orienter vers une situation ou le développeur perd de plus en plus son autonomie.

Cette idée à commencer à fleurir dans mon esprit depuis très longtemps, lorsque j’avais été frustré par une première tentative d’inscription pour publication d’application sur le marketplace Windows Phone 7, qui avait été un échec avec pour principale cause la non-prise en charge de ma zone géographique.

Ensuite vint mon inscription à Windows Azure pendant les 30 jours de test gratuit et pour le projet Folding@home sur DVP de la plateforme Cloud de Microsoft qui n’a bien évidement abouti à aucun résultat avec, toujours pour cause, la zone géographique. Et finalement, les sujets qui pullulent actuellement en ligne sur la guerre des brevets et les contraintes liées au développement mobile m’ont poussé à écrire ce billet de blog.

Avant d’évoluer, je tiens à préciser que je suis un développeur .NET indépendant, qui réside actuellement au Cameroun, un pays plutôt pauvre – faut le dire – de l’Afrique centrale, ou l’évolution technologique est à la traine. Néanmoins, il fait bon d’y vivre ;). La n’est pas le but de cet article.

L’ère du PC a offert une certaine liberté au développeur dans le choix de sa plateforme d’exécution, de ses outils et langages de développement. On pouvait se vanter d’être un Geek avec un ordinateur sur lequel sont installés plusieurs OS avec de multiples plateformes de développement.

Couplé à l’avènement de l’Internet dans les années 80, les développeurs pouvaient publier le fruit de leur labeur beaucoup plus simplement, quasiment bon marché.

Internet est venu donc favoriser la distribution des applications sur le Web en dehors des standards industriels. Les logiciels sur le Web sont pour la plupart développés par des personnes physiques (développeurs indépendants) – par opposition à la personne morale qu’est l’entreprise.

Dès lors, on a assisté même à un essor des développeurs indépendants. Certains ont même quitté l’entreprise qui les employait pour se lancer avec beaucoup de succès dans une activité personnelle avec le maximum de liberté.

Avec l’avènement des terminaux mobiles et des tablettes qui rencontrent un succès énorme de nos jours. On aperçoit de plus en plus des avis des personnes annonçant la fin de l’ère PC.

On assiste également à l’attrait de bon nombre de développeurs pour le développement des applications mobiles. Cependant, la distribution des applications est désormais centralisée au sein d’un seul canal de diffusion officiel pour chaque éditeur de système d’exploitation mobile : les galeries d’applications.

Certes, cela permet de cibler un public beaucoup plus large, et offre une plus grande lisibilité à l’application du développeur, permettant ainsi de générer de plus gros revenu pour les applications mobiles populaires.

Mais d’un autre côté, pour pouvoir publier son application, le développeur doit remplir plusieurs conditions et est contraint d’utiliser un langage bien précis, qui est propre à chaque système d’exploitation mobile (.NET pour Windows Phone, Objective-C pour iOS, etc.).

Pour le cas de l’App Store d’Apple par exemple, le processus de validation de l’application passe par une vérification stricte de celle-ci, qui ne doit pas avoir accès à certaines ressources système. De plus, votre pays de résidence conditionne également votre possibilité d’accès à la galerie (comme cela a été le cas pour moi avec Windows Phone).

En contrepartie de la visibilité offerte par la galerie et les outils misent à la disposition du développeur pour le suivi de ses publications, une bonne partie du revenu généré par l’application est versée à l’éditeur de la plateforme.

De plus, cette possibilité de faire tourner un système d’exploitation de son choix sur un dispositif n’est quasiment plus possible.

Mais là n’est pas l’aspect le plus critiquable de la chose. La violation des propriétés intellectuelles fait de plus en plus parler d’elle.

On se souvient encore certainement de l’affaire Lodsys LLC, cette entreprise qui avait adressé des lettres individuelles par le service de transport de fret FedEx à de nombreux éditeurs d’applications exigeant un dividende de 0.575 % sur les revenus générés par les applications de ceux-ci.

Le développeur après des efforts considérables de programmation pour mettre sur pied son application, peut à tout moment être face à des personnes faisant valoir un droit à une partie de son travail sans toutefois y avoir participé, tout simplement parce que celles-ci ont fait valider un papier décrivant théoriquement une idée.

Bien évidemment, le développeur ne dispose pas d’assez de ressource pour se défendre. Les frais de justice à eux seuls prendront pratiquement tout le revenu généré par l’application et peut-être même par toute son activité.

De ce fait, les développeurs qui se sont lancés dans une activité indépendante n’auront plus que comme alternative pour survivre de travailler pour des entreprises qui disposent d’assez de ressources pour pouvoir faire face à de telle situation.

Et le Cloud Computing ?

Le Cloud Computing fait également beaucoup parler de lui ses deux dernières années. Même s’il est clair que les cibles principales du Cloud sont les entreprises, les plateformes d’hébergement d’applications dans le Cloud sont aussi proposées aux développeurs.

L’accès à celles-ci en plus d’être conditionné une fois de plus à la zone géographique, limite également le choix des langages de développement pour le développeur.

Pour chaque plateforme, l’éditeur assure d’abord la promotion du langage de programmation qu’il a créé (le cas de Go pour la plateforme App Engine de Google) avant d’intégrer les autres langages de programmation les plus populaires (JAVA, PHP, Python, etc.).

L’adoption de ces écosystèmes pourrait tout simplement entrainer la fin de certains langages de programmation, et ne laisse pas une grande liberté au développeur dans le choix de son langage, qui est désormais limité à ceux qui sont supportés par la plateforme ciblée.

Pour conclure, je me rends compte que le développement d’application pour les écosystèmes mobiles, pour les plateformes de Cloud Computing, tend à contraindre de plus en plus le développeur au respect de certaines conditions et le prive de liberté dans le choix d’outils et langages de développement, et n’encourage pas également à se lancer à son propre compte comme développeur indépendant.

Sans toutefois vouloir lancer un quelconque troll, ceci n’est qu’une analyse personnelle, fondée sur l’état actuel des choses, qui peut s’avérer cependant critiquable.

Avec ces nouveautés, nous avons sans apporter aucune modification à nos modèles et contrôleurs, créé des vues personnalisées pour les navigateurs Desktop et les navigateurs mobiles.

Dans ce billet, nous verrons comment procéder autrement en utilisant le package Nuget JQuery.Mobile.MVC.

Le package jQuery.Mobile.MVC installe la librairie JQuery Mobile qui va permettre la création des interfaces Web optimisées pour les smartphones et autres terminaux tactiles, ainsi que plusieurs autres fichiers pour faciliter la tâche au développeur.

Ouvrons notre application ASP.NET MVC 4 avec votre éditeur Visual Studio 2010 SP 1 ou Visual Web Developper Express 2010 SP 1.

Nous allons dans un premier temps intégrer la bibliothèque JavaScript à notre projet en utilisant le gestionnaire de packages Nuget.

Pour cela, nous allons faire un clic droit sur notre projet dans l’explorateur de solution. Dans le menu contextuel qui s’affiche, sélectionnons « Manage Nuget Packages ».

La fenêtre de gestion des packages Nuget s’affiche. Nous devons rechercher le package jQuery.Mobile.MVC en tapant son nom dans la zone de recherche.

Nous allons ensuite cliquer sur Install pour que Nuget télécharger et installe automatiquement dans notre projet le package ainsi que toutes ses dépendances.

Nous allons nous rendre compte que plusieurs fichiers ont été ajoutés au projet, dont un nouveau fichier _Layout.Mobile.cshtml, _ViewSwitcher.cshtml ou encore ViewSwitcherController.cs.

Procédons maintenant à l’exécution de notre page pour voir ce qui sera affiché à l’écran en utilisant notre navigateur Firefox, et en définissant comme agent utilisateur iPhone (voir mon précédent billet de blog pour définir l’agent utilisateur sous Firefox).

View Switcher.

Revenons maintenant voir ce qui se trouve sous le capot.

Sur la page affichée dans notre navigateur, nous remarquons qu’une bande noire s’est ajoutée en début de celle-ci avec un lien permettant de basculer sur la vue desktop de la page.

D’où provient cette bande ?

Ouvrons avec notre éditeur la page affichée à l’écran (Index.cshtml).

@{
    ViewBag.Title = "Home Page";
}

<h2>@ViewBag.Message</h2>
<p>
    To learn more about ASP.NET MVC visit <a href="http://asp.net/mvc" title="ASP.NET MVC Website">http://asp.net/mvc</a>.
</p>

<ul data-role="listview" data-inset="true">
    <li data-role="list-divider">Navigation</li>
    <li>@Html.ActionLink("About", "About", "Home")</li>
    <li>@Html.ActionLink("Contact", "Contact", "Home")</li>
</ul>

À première vue, on se rend compte qu’aucune modification n’a été effectuée dans ce fichier.

Puisque ce fichier est intégré dans le Layout avant d’être affiché, jetons maintenant un coup d’œil sur notre fichier _Layout.Mobile.cshtml. Nous allons apercevoir la ligne de code suivante :

@Html.Partial("_ViewSwitcher")

Qui fait référence à la vue partielle _ViewSwitcher.cshtml. C’est cette vue qui ajoute un lien sur toutes les pages mobiles permettant de basculer du mode d’affichage mobile pour Desktop et vice-versa. Par défaut, elle n’est pas incluse dans les vues Desktop. Pour remédier à cela, vous pouvez juste copier @Html.Partial(« _ViewSwitcher ») dans le fichier _Layout.Mobile.cshtml et le coller dans le fichier _Layout.cshtml.

Dans le code de la vue partielle ViewSwitcher, la méthode GetOverriddenBrowser() est utilisée pour retourner un objet HttpBrowserCapabilitiesBase, qui va donner des informations sur les capacités du navigateur qui a fait la demande. La propriété IsMobileDevice retourne une valeur booléenne permettant de savoir si c’est un navigateur mobile qui effectue la demande.

@if (Request.Browser.IsMobileDevice && Request.HttpMethod == "GET")
{
    <div class="view-switcher ui-bar-a">
        @if (ViewContext.HttpContext.GetOverriddenBrowser().IsMobileDevice)
        {
            @: Displaying mobile view
            @Html.ActionLink("Desktop view", "SwitchView", "ViewSwitcher", new { mobile = false, returnUrl = Request.Url.PathAndQuery }, new { rel = "external" })
        } 
        else 
        {
            @: Displaying desktop view
            @Html.ActionLink("Mobile view", "SwitchView", "ViewSwitcher", new { mobile = true, returnUrl = Request.Url.PathAndQuery }, new { rel = "external" })
        }
    </div>
}

Browser Overriding

Penchons-nous maintenant sur le contrôleur qui est associé à cette vue.

using System.Web.Mvc;
using System.Web.WebPages;

namespace MvcApplication3.Controllers
{
    public class ViewSwitcherController : Controller
    {
        public RedirectResult SwitchView(bool mobile, string returnUrl) {
            if (Request.Browser.IsMobileDevice == mobile)
                HttpContext.ClearOverriddenBrowser();
            else
                HttpContext.SetOverriddenBrowser(mobile ? BrowserOverride.Mobile : BrowserOverride.Desktop);

            return Redirect(returnUrl);
        }
    }
}

Le View Switcher utilise une nouvelle fonctionnalité « Browser Overriding », permettant de traiter les demandes d’une application comme si elles provenaient d’un autre navigateur (Agent utilisateur).

Le Browser Overriding est une caractéristique de base d’ASP.NET MVC 4, et peut de ce fait être utilisé même si vous n’avez pas installé le package jQuery.Mobile.MVC. Avec cette fonctionnalité, en fonction du lien sur lequel l’utilisateur à cliquer (Desktop view ou Mobile view), le contrôleur de la vue Switcher va simuler un agent utilisateur (BrowserOverride.Mobile ou BrowserOverride.Desktop) qui sera utilisé pour charger les vues correspondantes au choix de l’utilisateur malgré que l’agent utilisateur transmit par son navigateur ne soit pas le même.

Le code ci-dessous va donc permettre de substituer l’agent utilisateur du navigateur. Par défaut, les données sur l’agent utilisateur simulé sont stockées en utilisant un cookie.

Conclusion

Nous venons d’apercevoir une fois de plus la puissance fonctionnelle d’ASP.NET MVC 4 pour le développement d’application mobile et Web. Dans le prochain billet de blog, notre attention sera portée sur le Template Web du Framework.