Create an asp.net mvc3 mobile app with jQuery Mobile

A 7 minutes video to show how to create an asp.net mvc3 mobile app with jQuery Mobile from the scratch

Complete sources is here

Links :
Using 51Degrees.Mobi Foundation for accurate mobile browser detection on ASP.NET MVC 3 by  Steve Sanderson
A Better ASP.NET MVC Mobile Device Capabilities ViewEngine by Scott Hanselan

Truc pour débugger des pages "Mobile" et ASP.NET MVC 3

Pour manager mes pages Mobile, je me suis inspiré de l'excellent article de Scott Hanselmann "A Better ASP.NET MVC Mobile Device Capabilities ViewEngine".
Mais quand vous voulez inspecter l'HTML ou tracer du javascript, les émulateurs ne sont pas très pratiques.
Je préfère utiliser le couple Firefox/FireBug.
Pour ce faire j'ai créer un faux moteur pour mobile pour pouvoir les utiliser sur des pages mobiles

Premièrement, j'ai ajouté mon faux moteur mobile dans CustomMobileViewEngine cs (sources complètes ici)

public static class MobileHelpers
{
    ...
    //Add firefox + firebug for help to debug
    public static void AddFireBug(this ViewEngineCollection ves) 
                  where T : IViewEngine, new()
    {
        ves.Add(new CustomMobileViewEngine(c =>
                c.UserAgentContains("firefox"), "Mobile",
                new T()));
    }
}

Deuxièmement dans  "Global.asax.cs" (Sources complètes ici) , je l'ai ajouté à ma fabrique de moteur

protected void Application_Start()
{
  AjaxHelper.GlobalizationScriptPath =
  "http://ajax.microsoft.com/ajax/4.0/1/globalization/";
  AreaRegistration.RegisterAllAreas();
  RegisterGlobalFilters(GlobalFilters.Filters);
  RegisterRoutes(RouteTable.Routes);

  // Add the auto mobile detection & redirection
  ViewEngines.Engines.Clear();
  ViewEngines.Engines.AddIPhone<RazorViewEngine>();
  ViewEngines.Engines.AddWindowsMobile<RazorViewEngine>();
  ViewEngines.Engines.AddGenericMobile<RazorViewEngine>();
#if DEBUG
  // Just use it for debug JS in firebug & inspect HTML
  ViewEngines.Engines.AddFireBug<RazorViewEngine>();
#endif
  // Std engine
  ViewEngines.Engines.Add(new RazorViewEngine());} 

Je pense qu'il est tout à fait possible de faire la même chose pour IE et l'option F12

Debug tip for ASP.NET MVC 3 in mobile context

For manage Mobile page, I'm inspired from this excellent post "A Better ASP.NET MVC Mobile Device Capabilities ViewEngine" by Scott Hanselmann
But, when I want inspect some html parts or if I want trace a javascript behavior, I want and I prefer use Firefox and FireBug.
So, I create a fake mobile engine which use Firefoxe+firebug

First, I have added my new engine in globlal.asax.cs 
In "Global.asax.cs" (full source here)

protected void Application_Start()
{
  AjaxHelper.GlobalizationScriptPath =
  "http://ajax.microsoft.com/ajax/4.0/1/globalization/";
  AreaRegistration.RegisterAllAreas();
  RegisterGlobalFilters(GlobalFilters.Filters);
  RegisterRoutes(RouteTable.Routes);

  // Add the auto mobile detection & redirection
  ViewEngines.Engines.Clear();
  ViewEngines.Engines.AddIPhone<RazorViewEngine>();
  ViewEngines.Engines.AddWindowsMobile<RazorViewEngine>();
  ViewEngines.Engines.AddGenericMobile<RazorViewEngine>();
#if DEBUG
// Just use it for debug JS in firebug & inspect HTML
  ViewEngines.Engines.AddFireBug<RazorViewEngine>();
#endif
  // Std engine
  ViewEngines.Engines.Add(new RazorViewEngine());} 

Second, I had in my custom mobile engine my new "Firefox+firebug" fake mobile engine

in CustomMobileViewEngine cs (full source here)

public static class MobileHelpers
{
    ...
    //Add firefox + firebug for help to debug
    public static void AddFireBug(this ViewEngineCollection ves) 
                  where T : IViewEngine, new()
    {
        ves.Add(new CustomMobileViewEngine(c =>
                c.UserAgentContains("firefox"), "Mobile",
                new T()));
    }
} 

You could do the same thing with "F12" on IE if you are used it.

Une astuce pour Asp.net MVC 3 avec jQuery Mobile et HTML 5

Si vous utilisez HtmlHelper dans Asp.net MVC 3, vous pourriez avoir quelques difficultés à définir des propriétés personnalisées.
Par exemple, en utilisant jQuery Mobile,et j'ai eu besoin d'initialiser «data-theme» ou «data-transition» sur un ActionLink
Si vous l'écrivez avec le séparateur '-' , vous obtenez une erreur de syntaxe. Les gars de Redmond nous ont mijotés une petite surprise, il faut remplacer le '-' par des '_'comme ceci :

@Html.ActionLink("My team", "UsersList", "Home", null,
 new { data_theme = "b", data_transition = "fade",
 data_icon = "star" })

et, automatiquement, les '_' sont remplacés par des '-'

<a data-icon="star" data-theme="b" data-transition="fade"
 href="/Home/UsersList">My team</a>

Je pense que cela marche aussi pour propriétés spécifiques à Html 5

A tip about dashes for Asp.net MVC 3 in jQuery Mobile and HTML 5 context

if you use HTMLhelper in Asp.net MVC 3, you could have some difficulties to set custom properties.
For example, I'm using jQuery Mobile, and I need to set 'data-theme' or 'data-transition' on an ActionLink.
If you write it with '-' separator, you have a syntax error. The Redmond guys have cooked a small surprise for us, you should replace the '-' by '_' like this

@Html.ActionLink("My team", "UsersList", "Home", null,
 new { data_theme = "b", data_transition = "fade",
 data_icon = "star" })

and automaticly, they replace '_' by '-' in Hmtl code

<a data-icon="star" data-theme="b" data-transition="fade"
 href="/Home/UsersList">My team</a>

I think we can do the same thing for HTML 5 properties

ASP.NET MVC & mobiles

During my last visit to Redmond, I was fortunate to have been received by Vishal Joshi (Senior Program Manager in the team "Web Platform & Tools").
As a VS end user and with my focus on the Web Application Mobile, Vishal was curious to know how I would consider the architecting and writing of my next application with the available Microsoft techniques.

Preamble

Developments for the mobile Web leverage some specifics issues:
• Weight control pages and transmitted data is important
• There are usually fewer functions (or they are easier/less sophisticated) in a mobile Web application from its Web equivalent
• Ergonomics of mobile Web applications is very different from conventional applications: they must be less complex, numerous interactions should be obvious and the results of actions must be visible and unambiguous
• Since there is a market in full expansion, our applications must also be easily and highly upgradable to accommodate all sorts of new devices. Manufacturers are offering us a bunch of varied & heterogeneous pads, not to mention the screens of our television turned into browser and innovative game consoles. An illustrative form of a motto which I liked from MS is 'three screens for one app".

« Device » definition

In this article, I will use the term "device" to refer to the different mobile platforms in a generic term.
These devices can be schematically and briefly described as follows:

We can extend this definition of "device" to browsers and their endless compatibility problems.

For example, I have recently met a client who still uses IE 4.7, I had the idea to address this problem by considering that IE 4.7 was a particular device with screens much simpler and with less features.

I found this system more elegant than the long lists of conditional comments “[if lt IE 6]..." directly in the web page.

I now consider the old browsers (and their 'problems') as individual devices. It's better for my codes and for my mind.

Development Focus

Vishal’s first question was: ASP.NET "classic" or MVC?

I replied without hesitation MVC, why? A better control of HTML, far fewer compatibility problems with browsers, And last but not least, a better mastering of pages weight, that’s an important criterion in the development of mobile Web applications.

MVC Style

Then he listed, on his whiteboard, few ways to consider the actual development in ASP.NET MVC in the perspective of implementing multi-devices (web, mobile web to phone and mobile web for pads...).

1.    An area for each "device"

• Advantages:

• Clearer, more readable

• Allows you to isolate the different devices components (especially at the JavaScript and CSS)

• Disadvantages:

• Require having as many controllers, models and views that devices, which can induce a lot of redundant code and, in case of many devices, some difficulties maintenance, especially when we would change some work process, and therefore, the bunch of models of each area.

2.    "Model" and "Controller" same but "Views" by various devices.

• Advantages:

• Only the views are suitable for devices, which simplify writing and maintaining only one controller and one model. This way is appropriate in addressing solutions to very similar devices (e.g. mobile phones) with very similar behavioral and data.

• Disadvantages:

• Not very appropriate for writing a complete solution: WEB + "mobile web". With The single controller/Single model, it becomes difficult to have a good code readability, but also to have good control of the weight of pages/data.

3.    One "Model View Controller" with conditional choice in the "controllers"

• Advantages:

• Efficient and fast when you have  to write code for less than 3 devices

• Disadvantages:

• The code can quickly become complicated, even illegible, though the number of devices increases

• It's difficult to code some complex behaviors

4.    Different "View" and "Controller" but based on a single "model"

• Advantages:

• Provides a good adaptation of the views and behaviors to devices

• Keeps a single model and therefore the uniqueness of objects "Business / Work" underlying the concept of model

• Disadvantages:

• The weight of the data to send to the devices is not well calibrated and the data are not necessarily appropriate

5.    Different "View-models" & "View" for each device:

• Advantages:

• Suitable finely models for each device (or each screen) and then, good control of the weight of data to send.

• Allows model "primary" legacy  code that gives a code more concise and thus more maintainable

• Disadvantages:

• More object “Model” to maintain and therefore more codes, and finally, increased risk of bugs.

To learn more about MVVM apply to MVC : Stephen Walther blog. 

An example : “NerdDinner Step 6”: ViewData and ViewModel

 

My choice

My first choice is the 5: "ViewModel/View"; it has the advantage of adapting a single model (in sense of business object) to multiple views (and therefore device) through the mechanism of "ViewModel". This is good for readability and maintainability of code, even if there are more objects than other.
This decoupling of the models and views allows good control of data sent to devices and, thus, the possibility of reducing the data weight. Remember, it is common not to have all data and features in a Web mobile application.
My second choice would be the 2: "Various views/devices"
This is the method I use currently, because I write mainly Web Mobile applications, and, therefore, my controllers & models are simpler than I have to write a Web and Web Mobile applications

Conclusion

As a conclusion, the different ways of proceeding described in this article are not the only options offered by ASP.NET MVC, the important thing is to find a simple and elegant solution to your problem.
Web applications, that we are currently writing, will be increasingly used on mobile phones, PDAs and tablets. We must start to write them with the right technologies, so that the user experience is as successful as possible regardless of the device.

Thanks

Thanks to Vishal for welcoming me and taking time to talk with me about the product he makes with his team and that I use.
I was very pleasantly surprised by the focus of these Microsoft teams for the feelings and perceptions of end users about their products.
Even if I'm MS Friendly, I try to be objective, and everything is not perfect at MS, but I really liked this closeness.

Thank to Philippe Limantour (Director, Cloud Computing & Innovation Center at Neos-SDI) for his help in English

ASP.NET MVC et mobiles

Lors de ma dernière visite à Redmond, j’ai eu la chance d’avoir été reçu par Vishal Joshi (Senior Program Manager dans l’équipe « Web platform & tools »).

En tant qu’utilisateur final de VS et avec mon penchant pour l’écriture d’application Web Mobile, Vishal était curieux de savoir comment, avec les techniques mises à notre disposition par Microsoft, j’envisageais l’architecture et l’écriture de ma prochaine application.

Préambule

Le développement pour le WEB mobile a quelques particularités :

•    La maitrise du poids des pages et des données transmises est importante

•    Il y a généralement moins de fonctions (ou elles sont plus simple) dans une application WEB mobile par rapport à son équivalent WEB

•    L’ergonomie des applications WEB Mobile est très différentes des applications classiques : elles doivent être moins complexes et moins nombreuses, les interactions doivent être évidentes et les résultats des actions doivent être visibles et sans ambiguïtés

•    Du fait qu’il s’agit d’un marché en plein extension, nos applications doivent elles aussi être facilement et fortement upgradable pour prendre en compte toutes sortes de nouveaux périphériques, les constructeurs nous préparent des tablettes diverses et variées, et je ne parle même des écrans de nos télévisions transformés en navigateur et des consoles de jeux. Une forme d’illustration d’un slogan de MS qui m’avait accroché une appli trois supports.

Définition de « Device »

Dans la suite de cet article, je vais utiliser le terme de « Device » pour nommer les différentes plateformes mobile dans un terme générique.

Ces devices peuvent être schématiquement et succinctement décrit comme suit :

Nous pouvons étendre cette définition de « device » aux browsers et leurs sempiternels problèmes de compatibilité.

Par exemple, J’ai encore rencontré récemment un client équipé d’IE 4.7, j’ai eu l’idée de traiter ce problème en considérant qu’IE 4.7 était un device particulier ayant des écrans plus simples et beaucoup moins de fonctions.

J’ai trouvé ce système plus élégant que les longues énumérations « if (browser LT 6)… » Directement dans les page WEB, Je considère maintenant les navigateurs « à problèmes » comme des devices particuliers. Mon code n’en n’est que plus maintenable et plus lisible.

Réflexion sur le développement

Sa première question était : ASP.NET « classique » ou MVC ? Je lui réponds sans hésiter MVC en le justifiant par les arguments : un meilleur contrôle de code HTML, moins de problèmes de compatibilité avec les browsers et enfin et surtout, une taille des pages mieux maîtrisée, c’est un critère important dans le cadre du développement d’application Web Mobile.

L’architecture MVC

Ensuite, il m’énumère sur son tableau blanc quelques façons d’envisager le développement proprement dit en ASP.NET MVC vu sous l’angle d’application « multi-devices » (web, web mobile pour le téléphone, web mobile pour les tablettes…).

1. Une area pour chaque « device »

• Avantages :

• Plus claire, plus lisible

• Permet de bien isoler les différents devices (notamment au niveau des scripts JavaScript et CSS)

• Inconvénients :

• Oblige à avoir autant de contrôleurs, de modèles et de views que de devices, ce qui peut induire pas mal de code redondant et une maintenance difficile dans les cas de nombreux devices

2. « Model » et « Controller » identique mais des « Views » différentes par devices.

• Avantages :

• Seule les vues sont adaptés aux devices ce qui simplifie l’écriture et maintient seulement un contrôleur et un seul modèle, ce qui est adapté dans des solutions s’adressant à des devices très similaires (par exemple les mobiles) et aux comportements et données très similaires

• Inconvénients :

• Pas très adapté à l’écriture d’une solution complète : WEB + « WEB Mobile », Le contrôleur unique et le modèle unique devenant handicapant autant dans la lisibilité du code que dans le poids des données envoyées aux device 

3.    Un seul « Model View Controller » avec des choix conditionnels au sein des « controllers »

• Avantages :

• Un seul et même contrôleur pour tous les devices qui change directement dans le code le comportement à adopter pour chaque device. Efficace et rapide quand on a moins de 3 devices à supporter

• Inconvénients :

• Le code peut rapidement devenir compliqué, voire illisible, si le nombre de devices augmentent
• Rend difficile les comportements complexes ou très différenciés

4.    Différents « View » et « Controller » mais basés sur un même « model »

• Avantages :

• Permet une bonne adaptation des vues et des comportements aux devices

• Permet de garder un seul et même modèle et donc l’unicité des objets « Business/Work »

• Inconvénients :

• Le poids des données à envoyer aux devices n’est pas bien calibré et elles ne sont pas forcément adaptées

5.    Différente « View-models» & « View » pour chaque devices :

• Avantages :

• Adapte finement les modèles à chaque device (ou à chaque écran) et donc, calibre bien le poids des données à envoyer.

• Permet l’héritage d’un modèle « principal » qui donne un code plus concis et donc plus maintenable

• Inconvénients :

• Plus d’objets « Model » à maintenir, et donc plus de codes, et en définitive, plus de risque de bogues.

A différencier du MVVM applicable à WPF/Silverlight : Blog de Stephen Walther. 

En résumé, la « view-model » est une forme de modèle adaptée au device.

cf. “NerdDinner Step 6”: ViewData and ViewModel

Les différents modèles

Mon choix

Nous entamons une sorte de brainstorming sur les différentes manières de faire et j’argumente sur mon point de vue « utilisateur final » sur les avantages/inconvénients de chaque solution.

Mon premier  choix est le « ViewModel/View », il a l’avantage d’adapter un seul et même modèle à plusieurs vue (et donc device) par le mécanisme des « Vue-Modèle ». Et cela, c’est bon pour la lisibilité et la maintenabilité du code, même s’il y a des objets en plus, ce découplage du modèle vis-à-vis des vues permet une bonne calibration et un bon contrôle des données envoyés aux devices et donc la possibilité d’alléger les téléchargements des données pour les devices parce qu’il est courant de ne pas avoir autant de données et de fonctions sur un device mobile que sur un PC.

Mon deuxième choix serait « Différents « View » et « Controller » mais basés sur un même « model », c’est celui que j’ai l’habitude d’utiliser pour sa simplicité de compréhension et  sa logique « un modèle »  et des vues et contrôleurs adaptés aux différents devices.

Conclusion

En conclusion, les différentes façons de procéder exposée dans cet article ne sont pas les seules possibilités offertes pas ASP.NET MVC, l’important est de trouver une solution simple et élégante à son problème.
Dans l’optique où les applications Web que nous écrivons sont probablement de plus en plus utilisées sur des téléphones, Smartphones et tablettes, nous  nous devons de les écrire dans tes technologies les plus adaptées, pour que l’expérience utilisateur soit la plus réussie possible quel que soit le support.

Remerciements

Un grand remerciement à Vishal pour m’avoir reçu et avoir pris le temps de discuter avec moi du produit qu’il fabrique et que j’utilise. Le souci de ces équipes MSFT d’avoir les sentiments et ressentis des utilisateurs finaux sur leurs produits m’a beaucoup et agréablement surpris. Même si je suis MS Friendly, j’essaye d’être objectif, et tout n’est pas parfait chez MS, mais cette proximité m’a beaucoup plu.