IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Dotnet Discussion :

Développement d'un client pour tablette : web ou natif ?


Sujet :

Dotnet

  1. #1
    En attente de confirmation mail
    Profil pro
    Inscrit en
    Septembre 2007
    Messages
    223
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2007
    Messages : 223
    Points : 401
    Points
    401
    Par défaut Développement d'un client pour tablette : web ou natif ?
    Bonjour,

    On développe une application orientée service. On a le serveur en C#/WCF et un client Windows en C#/WinForm qui consomme le service.

    Il s'agit d'une application dédiée, pour une utilisation chez des clients, pas une application grand public. En gros, c'est un logiciel assez simple, qui permet de prendre des commandes/réservations. L'interface du client ressemble à une liste ou pour chaque ligne on saisie un champs texte (quinzaine de caractères), et 2 ou 3 valeurs sélectionnées dans des listes déroulantes.

    Le serveur et le client Windows fonctionnent correctement. Maintenant, on prévoit de développer un client pour pouvoir prendre des commandes/réservations avec une tablette, style iPad.

    Je vois 2 possibilités :
    • Un client web : le serveur WCF est déjà hébergé par IIS et le client web a l'avantage de pouvoir être utilisé indifféremment sur une tablette IOS/Android/Windows 8.
    • Un client natif : si on ne visait que des tablettes Windows, on pourrais probablement porter le client Windows actuel à peut de frais. Mais si on veut offrir un client pour les 3 types de tablettes, il nous faut un outil multiplateforme.


    Nos choix sont assez ouvert, sachant qu'on pourrait même forcer l'utilisation de tablettes Windows 8 si cela vaut le coup.

    Notre priorité c'est la simplicité/robustesse du développement, en évitant de devoir toucher à plein de technologies différentes. Le client web étant déjà bien avancé, on se rend compte que la gestion des évènements, rafraichissements en cours d'éditions ...etc. c'est pas si évident par rapport à du natif.

    Des avis ?

  2. #2
    Membre chevronné Avatar de Er3van
    Homme Profil pro
    Architecte Logiciel
    Inscrit en
    Avril 2008
    Messages
    1 430
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte Logiciel
    Secteur : Industrie

    Informations forums :
    Inscription : Avril 2008
    Messages : 1 430
    Points : 2 227
    Points
    2 227
    Par défaut
    Si tu veux du multi-plateforme sans devoir mettre les mains dans du Objective-C, il ne te reste que le web.

    Rien ne t'empêche du coup d'avoir un site web en ASP.net.
    Normalement, tu devrais pouvoir réussir à faire la même chose que ton application WPF, grâce notamment aux toolkits AJAX et du javascript.

    Ceci étant, javascript étant ce qu'il est, il y aura peut-être quand même du travail à faire pour que ça marche avec les différents navigateurs des tables (Safari/Chrome Lite/IE).

  3. #3
    En attente de confirmation mail
    Profil pro
    Inscrit en
    Septembre 2007
    Messages
    223
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2007
    Messages : 223
    Points : 401
    Points
    401
    Par défaut
    Citation Envoyé par Er3van Voir le message
    Si tu veux du multi-plateforme sans devoir mettre les mains dans du Objective-C, il ne te reste que le web.
    C'est un peut ce que je me dit depuis le début, merci de me le confirmer.

    Citation Envoyé par Er3van Voir le message
    Normalement, tu devrais pouvoir réussir à faire la même chose que ton application WPF, grâce notamment aux toolkits AJAX et du javascript.
    A vrai dire le 1er contact est un peut rude, tout me parait plus compliqué et Visual Studio me parait moins "friendly" dés qu'il s'agit d'éditer de l'aspx, surtout que j'ai pas mal de refresh et d'accès concurrents aux même données.

    Citation Envoyé par Er3van Voir le message
    Ceci étant, javascript étant ce qu'il est, il y aura peut-être quand même du travail à faire pour que ça marche avec les différents navigateurs des tables (Safari/Chrome Lite/IE).
    Pour l'instant je test avec mon Asus Transformer sous Android, il va falloir que je dégote un iPad.

    Merci pour tes conseils

  4. #4
    Membre chevronné Avatar de Er3van
    Homme Profil pro
    Architecte Logiciel
    Inscrit en
    Avril 2008
    Messages
    1 430
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte Logiciel
    Secteur : Industrie

    Informations forums :
    Inscription : Avril 2008
    Messages : 1 430
    Points : 2 227
    Points
    2 227
    Par défaut
    Citation Envoyé par Pat_AfterMoon Voir le message
    A vrai dire le 1er contact est un peut rude, tout me parait plus compliqué et Visual Studio me parait moins "friendly" dés qu'il s'agit d'éditer de l'aspx, surtout que j'ai pas mal de refresh et d'accès concurrents aux même données.
    Visual Studio a fait beaucoup de progrès à ce niveau là, et sur la version 2010 je trouve que c'est très similaire à ce qui est fait pour du XAML, mais c'est sans doute juste une question d'habitude... et de la complexité de ton besoin.

  5. #5
    Modérateur

    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Avril 2007
    Messages
    1 996
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Chef de projet NTIC
    Secteur : Service public

    Informations forums :
    Inscription : Avril 2007
    Messages : 1 996
    Points : 3 106
    Points
    3 106
    Par défaut
    Je partage l'avis d'Er3van : si vous voulez être présents sur plusieurs plateformes sans pour autant développer une appli spécifique à chacune d'entre elles, il faut passer par une appli web.
    Vous pouvez aussi regarder du côté des SDK cross-plateformes (Titanium, Unity, etc.)

  6. #6
    Membre expert
    Avatar de GuruuMeditation
    Homme Profil pro
    .Net Architect
    Inscrit en
    Octobre 2010
    Messages
    1 705
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : Belgique

    Informations professionnelles :
    Activité : .Net Architect
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2010
    Messages : 1 705
    Points : 3 570
    Points
    3 570
    Par défaut
    Un peu comme toujours, c'est une question d'argent. Le web a ses avantages (Plus multi-plateformes comme déjà dit) mais l'avantage du natif est que tu peux faire une meilleure appli dans le sens ou tu peux utiliser toutes les fonctionnalités de l'OS. Exemple en phone7 : les tiles.

    J'ai du développer une ampli mobile multi OS a partir d'un Framework pour MS Dynamics et c'est zéro point de vue UX a cause des limitations. Frustré que j'etais...

Discussions similaires

  1. Générer un client pour un Web Service sous Eclipse
    Par yous18 dans le forum Services Web
    Réponses: 7
    Dernier message: 15/02/2016, 10h22
  2. Développement d'un almanach pour sites web
    Par gabrielmoz dans le forum Général Conception Web
    Réponses: 4
    Dernier message: 21/12/2011, 18h28
  3. Réponses: 0
    Dernier message: 08/09/2011, 21h01
  4. Réponses: 0
    Dernier message: 08/09/2011, 21h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo