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

Affichage des résultats du sondage: Développement mobile : préférez-vous le développement natif ou multiplateforme ?

Votants
51. Vous ne pouvez pas participer à ce sondage.
  • Je préfère le développement natif

    18 35,29%
  • Je préfère le développement multiplateforme

    26 50,98%
  • Je n'ai aucune préférence particulière

    4 7,84%
  • Autre (à préciser)

    2 3,92%
  • Pas d'avis

    1 1,96%
Mobiles Discussion :

Développement mobile : préférez-vous le développement natif ou multiplateforme ?


Sujet :

Mobiles

  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    Juillet 2013
    Messages
    2 873
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Data Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 2 873
    Points : 86 887
    Points
    86 887
    Billets dans le blog
    2
    Par défaut Développement mobile : préférez-vous le développement natif ou multiplateforme ?
    Développement mobile : préférez-vous le développement natif ou multiplateforme ?
    Quelles ont été vos expériences dans les deux cas ?

    Pour le développement mobile, faut-il utiliser des outils de développement natifs ou multiplateformes ? Du point de vue de la performance et de l'expérience utilisateur, ce sujet ne doit pas faire débat, parce que les applications natives offrent de nombreux avantages. Une application native est en effet développée spécifiquement pour une plateforme et avec un langage qui permet de tirer parti des avantages de la plateforme (par exemple Java pour Android, Objective-C et Swift pour iOS, C# pour Windows Phone).

    Une application native peut être un meilleur choix si elle doit avoir accès à l’ensemble des fonctionnalités de l’appareil et du système d’exploitation, étant donné qu’elle peut mieux tirer parti des fonctionnalités du système mobile ciblé et de l’appareil de l’utilisateur. En termes de performance et de vitesse, il ne devrait y avoir aucune limitation particulière avec une application native. Si vous voulez une interface utilisateur fluide et très réactive, une application native fera également l’affaire. L’un des véritables problèmes, c’est le coût de développement, car il va falloir réécrire l’application plusieurs fois si vous devez cibler plusieurs plateformes. Un inconvénient que le développement multiplateforme permet de résoudre.

    Les technologies de développement multiplateforme permettent d'écrire le code de base (par exemple en HTML, CSS, JavaScript ou autre langage) et ensuite de l’adapter pour cibler différentes plateformes mobiles. La plus grande partie du code de base pourra être partagée entre les différentes versions de l’application. Mais les contraintes relatives au développement multiplateforme, selon les technologies utilisées, peuvent être nombreuses.

    Si vous voulez développer un prototype et lancer une application relativement simple sur plusieurs plateformes rapidement, alors une application multiplateforme serait une bonne option. Surtout si votre application dispose d'une interface utilisateur simple et limite les interactions avec l'utilisateur. Il faut donc avoir à l’esprit que l’application risque de ne pas être en mesure d’interagir avec tous les composants matériels du dispositif, comme la caméra et le microphone. Le développement multiplateforme peut également ne pas être un choix à faire si votre application doit traiter des données complexes ou utiliser l'audio ou la vidéo.

    Le développement natif est idéal pour des applications qui doivent tirer parti de certaines fonctionnalités de la plateforme ciblée. Il faut toutefois noter que tous les projets n’ont pas les mêmes contraintes et avec des technologies comme Xamarin (qui permet aux développeurs d’utiliser C# pour créer des applications natives pour Android, iOS et Windows), un nombre croissant de développeurs s’adonne au développement multiplateforme. Encore faut-il choisir les bons outils et savoir comment les utiliser.

    Et vous ?

    Pour le développement mobile, préférez-vous le développement natif ou multiplateforme ? Pourquoi ?
    Quelles ont été vos expériences dans les deux cas ? Quelles technologies avez-vous utilisées ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Février 2010
    Messages
    30
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Février 2010
    Messages : 30
    Points : 66
    Points
    66
    Par défaut
    J'utilise Appcelerator (permet de dev des app en JS) depuis 2 ans et c'est vraiment intéressant.
    Ils sont un peu à la bourre niveau ES6 mais ils essaient d'aller de l'avant !

    Sinon ils ont sorti Hyperloop qui permet d’accéder au API native via le JS.

  3. #3
    Membre habitué
    Homme Profil pro
    Ingénieur Informatique
    Inscrit en
    Décembre 2005
    Messages
    146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur Informatique

    Informations forums :
    Inscription : Décembre 2005
    Messages : 146
    Points : 158
    Points
    158
    Par défaut Et cordova?
    C'est dommage de ne pas parler de Cordova, en évoquant le crossplateform natif / non natif.
    D'autant plus que les personnes habituées à faire du dev web sur des technos comme AngularJS, il est très simple de faire des application avec Cordova qui vont couvrir 80% des besoins et très maintenable dans le temps.

    Pour les 20% restant, il sera nécessaire de passer sur du natif pour des questions de performances principalement.
    Mon blog est sur https://arphonis.fr et bientôt d'autres fonctionnalités seront disponible dessus.

  4. #4
    Expert confirmé

    Homme Profil pro
    Développeur .NET
    Inscrit en
    Novembre 2010
    Messages
    2 064
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Novembre 2010
    Messages : 2 064
    Points : 4 229
    Points
    4 229
    Par défaut
    Oui c'est dommage de ne pas faire la différenciation entre app multiplateforme générant du code natif et les autres qui sont simplement des apps web s'exécutant dans le navigateur du mobile.
    Sachant qu'on peut coder en JS et générer du natif (Telerik) ...

  5. #5
    Membre éclairé Avatar de seeme
    Profil pro
    Inscrit en
    Octobre 2005
    Messages
    430
    Détails du profil
    Informations personnelles :
    Âge : 36
    Localisation : France

    Informations forums :
    Inscription : Octobre 2005
    Messages : 430
    Points : 791
    Points
    791
    Par défaut
    Toujours fait 99% du développement en C++.
    Il y a des avantages et des inconvénients et c'est très lié au produit.

  6. #6
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    Décembre 2011
    Messages
    1 320
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : Décembre 2011
    Messages : 1 320
    Points : 3 740
    Points
    3 740
    Billets dans le blog
    12
    Par défaut
    J'ai un peu fait des deux, Android pour le natif et Ionic pour le multiplateforme (JS/Typescript).

    Ce qui m'a marqué est que j'ai eu plus de facilités avec le natif, ça a été beaucoup plus rapide à prendre en main, en gros je lis la doc, je code, je vois mes erreurs avant la phase de compilation, et j'ai un résultat correct assez rapidement. Avec le multiplateforme, je lis la doc, je code, j’inclue certaines libs et je ne comprends pas forcément pourquoi Cordova ne fonctionne pas, aussi je ne vois pas tous mes erreurs avant la compilation (ou en mode watch), l'IDE ne détecte pas certaines syntaxes et le compilateur non plus, on se rend compte assez vite que ces outils, en plus d'être limités (du au fait qu'ils sont adaptés pour plusieurs systèmes), ne sont pas suffisamment matures.

    Le multiplateforme c'est un peu le rêve absolu, mais je trouve la phase de développement assez frustrante.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  7. #7
    Membre éprouvé
    Avatar de landry161
    Homme Profil pro
    C#,PHP,MySQL,Android...
    Inscrit en
    Juillet 2010
    Messages
    423
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : C#,PHP,MySQL,Android...

    Informations forums :
    Inscription : Juillet 2010
    Messages : 423
    Points : 1 059
    Points
    1 059
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Gugelhupf Voir le message
    l'IDE ne détecte pas certaines syntaxes et le compilateur non plus
    Ouais sauf le navigateur qui t affichera rien à moins que tu fasses une inspection.

  8. #8
    Membre éprouvé
    Avatar de landry161
    Homme Profil pro
    C#,PHP,MySQL,Android...
    Inscrit en
    Juillet 2010
    Messages
    423
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : C#,PHP,MySQL,Android...

    Informations forums :
    Inscription : Juillet 2010
    Messages : 423
    Points : 1 059
    Points
    1 059
    Billets dans le blog
    1
    Par défaut
    L article l a si bien dit le multiplatforme c est un code écrit pour plusieurs plateformes. Apres pour ce qui est du choix, je pense que cela dépendra du la nature du projet et des différentes fonctionnalités à implémenter.

  9. #9
    Invité
    Invité(e)
    Par défaut
    Le dev natif, sans hésiter.
    Je suis dev Android, donc habitué au Java et le sdk Android.
    J'ai pu tester 2 technos ces derniers mois, robovm (un jeu dev avec libgdx, pour gwt, android, ios, desktop), et React native (android, ios).

    libGDX (robovm)
    Le premier constat que je fais, c'est que le code "générique" et rapide à mettre en oeuvre. La partie "core" a été relativement facile à coder. Nous souhaitions intégrer AdMob et Google Game Services pour IOS et Android. Finalement, seul Android a un leaderboard, mais les deux plateformes disposent d'une intégration AdMob.

    Ce qui nous a posé problème, c'est le code spécifique IOS. Là, ça ne sert plus à grand chose de connaitre java... On fait bien du java, mais dans un contexte IOS, donc si vous ne connaissez pas vous allez perdre un temps fou (et de l'argent...) pour essayer d'intégrer des librairies pour lesquelles il existe plusieurs versions de binding, certaines ne link pas le projet, d'autre link mais plante l'executable à cause de référence inconnue (hello GADRequest et NSObject). Du coup, pour être productif, je pense qu'il est malgré tout indispensable de bien connaitre le fonctionnement des plateformes, être sûre que la communauté derrière est là pour vous aider (chez vous, vous avez peut être toute la vie pour attendre des réponses, pas toujours en entreprise). Finalement, seule la version Android va finir sur le store pour le moment. En plus, j'ai eu un problème bizarre, genre le garbage collector qui mange TOUT sur IOS. Surtout les pauvres petits callbacks que je passe au core du projet pour afficher les ads et que je ne veux pas passer en "static" comme un cochon.

    Et là il s'agit d'un jeu, donc tout ca passe principalement par libGDX. Mais quand est-il du développement d'applications "classique" sans libgdx, avec des ListView, des boutons etc ? J'aimerais bien avoir le retour de quelqu'un qui a pu s'y essayer. Gain de temps, ou perte d'argent?


    React native
    Là, c'est différent. On ne fait plus du tout de java, mais du React (enfin, je crois). Un mélange de Javascript et de JSX si j'ai bien compris. Cela peut paraître bizarre les premières heures, mais c'est plutôt sympa par la suite. Un gros problème que j'ai eu, c'est de trouver un bon IDE pour coder. Je m'en sors plutôt pas mal avec vscode, mais atom (avec plugin nuclide) est pas mal aussi, si vous visez IOS. Pour Android, il faut repasser un autre jour pour pouvoir débugger correctement. Cela ne fonctionne que partiellement (c'est écrit dans la doc), et pourtant j'y ai passé plusieurs heures (même à la maison, mais l'OS et la config sont différentes dont bon...).

    Donc là c'est du Javascript (ECMAscript 6), plutôt facile à prendre en main. Le code générique, une fois le fonctionnement de React assimilé est plutôt rapide à écrire. Pour le code spécifique à chaque plateforme, c'est plus ou moins le même problème que libgdx et robovm (je cite libgdx mais il s'agit juste d'un framework...). Si vous devez utiliser du code natif "à vous" ou celui d'un autre et que le binding n'existe pas, vous allez devoir le faire vous même, et donc connaître ObjectiveC et Java pour vous interfacer avec le JS.

    Un autre problème, c'est qu'en utilisant du code "all-in-one", on perd souvent certaines "spécificités" des systèmes. Par exemple, sur android, la TabBar, le CoordinatorLayout ? Avec React, il n'y a pas ces composants natif. Je ne suis pas adepte des applications Android qui sont semblables aux versions IOS comme deux gouttes d'eau. Pour les clients, c'est souvent quelque chose d'important, mais je pense aussi que ce n'est pas bon pour l'écosystème des applications et les habitués de chaque système, mais je sort un peu du sujet là.

    Cependant il faut y penser. Vous utilisez "Navigator", et "NavigatorIOS", bien, maintenant, vous risquez de finir avec des if android /else ios, ou bien vous allez une fois de plus écrire ou chercher des binding en fonction de ce que vous voulez (et l'heure tourne). J'imagine que cela doit être pris en compte avant de lancer le projet, mais combien ce sont fais piéger, ou n'ont pas eu le choix ?

    Pour conclure, le dev cross plateforme semble intéressant à priori, mais il faut faire attention. Sans experience dans les outils utilisés c'est un parie risqué. Pour faire des applications simple cela ne doit pas poser trop de problèmes, même sans connaitre en details le fonctionnement des plateformes pour lesquels le projet sera réalisé, mais pour des applications plus poussées, il faut faire attention. Vous pouvez me dire que l'appli Facebook EST poussée et que c'est un bon exemple, oui mais Facebook est aussi derrière React native, donc ca ne compte pas Et puis je n'ai pas d'autres exemple, là, comme ca.

  10. #10
    Membre du Club
    Homme Profil pro
    Développeur Senior
    Inscrit en
    Octobre 2013
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Indre et Loire (Centre)

    Informations professionnelles :
    Activité : Développeur Senior
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Octobre 2013
    Messages : 18
    Points : 59
    Points
    59
    Par défaut
    Personnellement j'utilise Xamarin.Forms car il est le seul à réellement faire du natif sur Windows ET IOS en même temps. Le soucis c'est que les applications sont complexe et qu'il arrive souvent qu'il y ai des problème de compatibilité entre les OS et Xamarin (merci iOS et xCode 8). De plus, le réel problème et que Xamarin nous montre chaque jour que nous sommes dépendant de lui et des bibliothèques des autres utilisateurs. Un outil complexe et puissant mais qui va encore demander du temps avant de devenir réellement mature.

  11. #11
    Membre éprouvé
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Août 2014
    Messages
    476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : Août 2014
    Messages : 476
    Points : 1 042
    Points
    1 042
    Par défaut
    Natif definitivement (C++ principalement). L'avantage en connaissant un seul langage de ne devoir s'adapter qu'au framework associé mais en conservant les habitudes de programmation habituelle.

    Les dev "multiplateformes" (type Xamarin) je m'en suis rapidement eloigné apres avoir pratiqué.
    Pour des trucs super simples ca peut passer par contre pour des applis pro ca devient d'une complexité sans nom (voir xamarin - une appli qui ne fait pas grand chose pese tout de suite 50 Mo - la quantité de libs java embarquées est surrealiste). Tu passes plus de temps a essayer de comprendre pourquoi ca marche pas que de coder ce que tu as a faire (bref trop de temps passé dans la mecanique inutile).

  12. #12
    Nouveau membre du Club
    Homme Profil pro
    Géophysicien
    Inscrit en
    Novembre 2015
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : Géophysicien
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2015
    Messages : 11
    Points : 34
    Points
    34
    Par défaut
    Le cross-platform natif...
    Avec Delphi ou C++Builder. Du vrai code, compilé au niveau du processeurs, donc même Android passe outre les horribles couches java et autres consommateurs de ressources.

  13. #13
    Membre expert

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    658
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Deux Sèvres (Poitou Charente)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Finance

    Informations forums :
    Inscription : Novembre 2006
    Messages : 658
    Points : 3 598
    Points
    3 598
    Billets dans le blog
    2
    Par défaut
    Bonjour,

    Comme sjordi, j'utilise Delphi. Certes, les binaires sont plus gros mais c'est la simplicité. Dans une solution, j'ai un module pour tablettes et smartphones. Le client est passé de tablettes à la pomme à des tablettes Android : j'ai juste recompilé le module (aucune modification nécessaire). Je n'utilise pas de fonctionnalités trop liées à l'OS mais le capteur photo, le module GPS et Wifi. J'apprécie également la fonctionnalité FireUI du concepteur d'interface graphique qui est pratique et qui permet d'adapter et prévisualiser en direct ce que ça va rendre (que la cible soit une application bureau, une tablette 10", un smartphone 5" ou encore une montre connectée par exemple).
    Mon site - Mes tutoriels - GitHub - N'oubliez pas de consulter les FAQ Delphi et les cours et tutoriels Delphi

  14. #14
    Membre régulier
    Profil pro
    Inscrit en
    Octobre 2006
    Messages
    89
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2006
    Messages : 89
    Points : 102
    Points
    102
    Par défaut
    Bonjour,

    Personnellement, j'utilise Embarcadero C++ Builder qui me permet de générer un seul code et 4 cibles principales (Windows, Mac-OS, Android et IOS). L'an prochaine, on passera à 5 avec l'ajout de Linux (en mode texte seulement).

    Les avantages :
    - Un seul code.
    - Le langage C++
    - Des outils simples permettant de ne pas avoir à tenir compte des résolutions d'écran des différents devices.
    - Un vrai binaire ou package par OS.

    Les inconvénients :
    - Pour des opérations spécifique à un OS, il faut créer une condition "Si OS = Android alors..."
    Exemple : la fonction Close() n'est pas autorisée d'emploi sous IOS, alors qu'elle l'est sous les autres OS.

    Cordialement

    Carmichael

  15. #15
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    436
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2006
    Messages : 436
    Points : 963
    Points
    963
    Par défaut
    J'utilise Xamarin Forms pour le multi platforme natif depuis 2 ans.

    C'était très laborieux au début. Maintenant que j'ai mon framework perso que je connais mieux ce qui fonctionne ou pas, je dois dire que j'aime énormément.
    Mais il faut beaucoup investir en temps, recréer des composants / comportement soit même.

    J'ai travaillé avec de nombreux dév iOS et Android (purement natif).
    Et bien je peux facilement dire que de façon général, le code XForms était bien plus cohérant, lisible et compréhensible.

    Une fois qu'on maitrise le proces de publication d'apk/ipa, qu'on a fait plusieurs appli XForms, je vous assure qu'on est à l'aise.
    Et on ne le dit pas assez mais XForms supporte aussi les Universal App dans la quasi intégralité (il n'y a que le composant Map que je n'ai pas réussi à faire fonctionner de XForms à Universal App) et pas seulement Android et iOS.

    Pour terminer, Xamarin est maintenant un produit Microsoft, un produit Open Source. Du coup je pense qu'il va encore s'améliorer énormément.
    "S'adapter, c'est vaincre" - Cellendhyll de Cortavar

  16. #16
    Membre averti
    Inscrit en
    Février 2006
    Messages
    707
    Détails du profil
    Informations forums :
    Inscription : Février 2006
    Messages : 707
    Points : 366
    Points
    366
    Par défaut Le problème des applications natives mobile
    Bonjour,

    Selon une information que j'ai trouvé sur le site de Ubuntu touch, seuls les applications multiplates formes HTML 5 ou Qml Fonctionne avec cette plate-forme . Le développement d'applications multiplates formes me semble privilégier mais je reconnais que dans certains cas cela n'est techniquement pas possible .
    Donc il faut faire une analyse bien poussé avons le développement d'une application station que pour l'instant Des systèmes d'exploitation peu connu ne pourront certainement pas faire tourner votre application. Cela peut également posé un problème le jour où l'utilisateur veux changer de système Un développement non multiplates formes n'est aussi pas bon pour la visibilité du système plus connus .

    Que pensez-vous ?

    Meilleures salutations
    Battant

  17. #17
    Membre du Club
    Profil pro
    Inscrit en
    Janvier 2008
    Messages
    120
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2008
    Messages : 120
    Points : 69
    Points
    69
    Par défaut
    Bonjour

    Personne n'a d'expérience avec Qt ?
    Je vais devoir choisir une techno et j'ai besoin d'accéder aux données bluetooth 4.
    Aujourd'hui, j'ai une app android à 90 % terminée et et je dois faire une version iOS.

    D'un coté, je suis très intéressé pour apprendre le dev iOS natif, un bouquin sur swift m'a
    fait penser que ça pourrait être un langage sympa à l'usage mais partant de 0 en macOS,
    en swift et en cocoa, le ticket d'entrée n'est pas nul et l'ide me semble un peu, comment dire ?,
    disons cabalistique.... surtout vs la tuerie qu'est android studio.
    L'autre inconvénient, c'est évidemment que toute fonction nouvelle devra être implémentée
    deux fois.

    D'un autre coté, j'ai déjà une expérience Qt pour du dev desktop. (en 4.8). J'avais mis de
    coté cette possibilité à ce moment là pour deux raisons : il n'y avait pas de classes pour l'accès à
    BT4 et à ce moment là, il ne suffisait pas de faire "clic" et tout marche, il y avait du travail
    en configuration et en déploiement.
    J'ai, il y a qq semaines installé la version de Qt courante et beaucoup de choses ont bien changées.
    Cela semble bien plus abouti mais je n'ai pas creusé plus d'une journée.

    Le pb, c'est que c'est bien sûr un choix très engageant donc si qqun a une expérience significative
    et dev, déploiement, maintenance vs les nouvelles versions de os et idéalement utilisation de BT4,
    j'en suis preneur.

    Merci
    Henri

  18. #18
    Membre régulier

    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    Janvier 2010
    Messages
    120
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Janvier 2010
    Messages : 120
    Points : 120
    Points
    120
    Billets dans le blog
    1
    Par défaut Xamarin : le multiplateforme natif
    Je rejoins un peu kilroyFR et moltroon : xamarin est laborieux :
    - problèmes de compilation
    - problèmes d'émulation
    - problèmes avec VS
    Cependant, je continue à m'investir sur xamarin.forms en espérant coder une seule fois pour 3 OS voir plus à l'avenir.
    jdd deschamps
    RPL - VB6 - C# - Wordpress - Python3 - Xamarin

  19. #19
    Membre du Club
    Inscrit en
    Novembre 2004
    Messages
    58
    Détails du profil
    Informations forums :
    Inscription : Novembre 2004
    Messages : 58
    Points : 44
    Points
    44
    Par défaut Codage multiplate forme
    Bonjour,
    j'ai découvert XOJO pour ne pas aller au VB.net, seule issue imposée par microsoft aux nombreux utilisateurs du défunt VB6 !
    XOJO est entièrement POO , la syntaxe très proche de Vb tout étant multi plate forme (Win,Mac,Linux) 32 et 64 bits,console, développement web, iOS, raspberry Pi2.
    Le seule inconvénient, il est avare en controls comparé a Vb6, d'où l'achat de plug in !

  20. #20
    Expert confirmé

    Homme Profil pro
    Développeur .NET
    Inscrit en
    Novembre 2010
    Messages
    2 064
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Novembre 2010
    Messages : 2 064
    Points : 4 229
    Points
    4 229
    Par défaut
    Citation Envoyé par Kikuts Voir le message
    J'utilise Xamarin Forms pour le multi platforme natif depuis 2 ans.

    C'était très laborieux au début. Maintenant que j'ai mon framework perso que je connais mieux ce qui fonctionne ou pas, je dois dire que j'aime énormément.
    Mais il faut beaucoup investir en temps, recréer des composants / comportement soit même.
    ton framework tu l'as mis à disposition sur un github par hasard ?

Discussions similaires

  1. Quel framework Javascript utilisez vous en développement mobile HTML5
    Par randriano dans le forum Bibliothèques & Frameworks
    Réponses: 3
    Dernier message: 09/04/2014, 10h22
  2. Quelle plateforme mobile avez-vous l'intention d'utiliser pour vos développements ?
    Par Stéphane le calme dans le forum Débats sur le développement - Le Best Of
    Réponses: 11
    Dernier message: 29/11/2013, 07h12
  3. Rendez-vous TTFX -Développement pour les mobiles
    Par alain31tl dans le forum Flex
    Réponses: 0
    Dernier message: 30/08/2011, 18h23
  4. Réponses: 6
    Dernier message: 29/05/2009, 23h02
  5. Réponses: 0
    Dernier message: 19/05/2009, 18h45

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