Quelles sont les différences entre les API Web ArcGIS (JavaScript / WPF / Silverlight / Flex)?

Esri propose actuellement 3 API Web différentes qui peuvent être téléchargées gratuitement.

Sont-ils tous égaux?

Sinon, quelles sont les forces / faiblesses relatives de chacune de ces API?

Dans une perspective de gestion totalement abstraite, les trois API sont égales. Ils représentent du code qui s'exécute dans un navigateur Web, dont le but est d'afficher des données cartographiques à un utilisateur sur Internet. Vous pouvez créer une application de cartographie réussie et significative avec n'importe laquelle des API.

De plus, l'impact de chaque force / faiblesse (différence) dans chaque API variera en fonction du public. Les programmeurs seront vivement intéressés par les fonctionnalités ou les inconvénients du langage, vos employés de réseau voudront connaître les exigences de bande passante et les conditions préalables du serveur, les employés de SIG seront profondément préoccupés par le fait que la carte affichée est vraiment rendue, et vos utilisateurs finaux se moquent de tout cela. et je veux juste faire ce qu'ils ont commencé à faire.

Voici donc quelques éléments clés sur les trois API:

• Gestion des ressources inter-domaines : Silverlight et Flex peuvent utiliser un fichier de "stratégie inter-domaines" qui existe sur le serveur TARGET. Ainsi, les éditeurs de cartes tiers peuvent vous autoriser à y accéder. Avec l'API Javascript, les requêtes inter-domaines sont généralement traitées en implémentant une "page proxy" en utilisant un langage côté serveur de votre choix (PHP, JSP, ASP, etc.). Cette «exigence souple» n'est pas un problème énorme pour la plupart des serveurs, mais ajoute une autre couche de complexité. Notez que rien ne vous empêche d'utiliser la même page proxy avec les API de plug-in, si votre ressource souhaitée N'EXPOSE PAS les fichiers inter-domaines nécessaires.

• Graphiques : Silverlight et Flex vous permettent de peindre facilement des pixels arbitraires sur l'interface utilisateur. Javascript le permet également, mais vous pouvez rapidement surcharger la capacité du navigateur sans code et préparation minutieux. De même, fonctionner directement avec des formats binaires ou du trafic réseau ne peut se faire qu'en Javascript à l'aide de services web.

• Environnement développeur : je suis partisan ici. Silverlight est mon préféré pour le développement. l'environnement Visual Studio est mature, rapide et dispose d'un débogueur de premier ordre. Javascript vient en deuxième position; les outils disponibles maintenant sont meilleurs que jamais et s'améliorent toujours, mais nous ne pouvons jamais sembler échapper à la malédiction de "vous devez tester sur tous les navigateurs pris en charge, puis corriger ces choses étranges qui se produisent". L'environnement Flex semble désuet et gonflé, et gêne fondamentalement le développement.

Contre Silverlight / WPF

• Nécessite un plugin
• L'avenir est moins certain que javascript (HTML5)

Avantages Silverlight / WPF

• Entièrement pris en charge par Visual Studio
• A un meilleur support multithreading (au moins par rapport à flex ).
• Meilleur support SOAP (le SOAP d'Esri est plus complet que REST).

Je suppose que toutes ces réponses sont bonnes mais un peu dépassées. Flex et Silverlight étaient sûrement très populaires par rapport à Javascript et certains pourraient soutenir que la création d'une application à l'aide de ces API était vraiment facile, mais le PLUS GRAND DÉFICIT de Flex et Silverlight est qu'ils sont des PLUGINS . Et c'est la cause de leur anéantissement.

Avec le début de HTML5 et Javascript étant la partie intégrante du développement d'applications Web, l'avenir est l'API Javascript. Adobe ayant abandonné Flash et Silverlight 5 étant la dernière mise à jour de Microsoft, Flex et Silverlight sont désormais des technologies redondantes.

Donc, si vous commencez le développement d'applications Web GIS à l'aide des API ESRI, commencez à apprendre l'API Javascript car c'est le seul avenir dans un avenir proche.

Les API Silverlight et Flex sont de loin les API ArcGIS les plus populaires et ont l'avantage d'être des plug-ins de navigateur qui offrent une expérience utilisateur beaucoup plus riche et cohérente, ce qui est souvent très important avec les applications Web SIG. Silverlight est probablement le meilleur choix si vous privilégiez le développement .NET et Flex serait le meilleur pour les développeurs qui préfèrent l'environnement Adobe. Flex a également l'avantage d'une adoption plus large en tant que plug-in de navigateur que Silverlight.

L'API Javascript a l'avantage d'avoir une portée plus multiplateforme, car les plug-ins de navigateur ne sont pas nécessaires, donc ils peuvent être utilisés dans des appareils iOS comme l'iPhone et l'iPad. L'inconvénient est que vous pouvez souvent voir des différences dans le comportement des applications dans les différents navigateurs tels que IE, Chrome, Firebox, Safari, etc.

En ce qui concerne leurs fonctionnalités, ils sont vraiment très similaires, ce que Esri a toujours essayé de faire avec ceux-ci et semble déterminé à continuer de maintenir une forte parité entre eux à l'avenir. Je pense donc que cela dépend vraiment de la force de Flex et de Silverlight en tant que clients riches et portée multiplateforme Javascripts.

Il existe une visionneuse ArcGIS pour Flex .

Il existe une visionneuse ArcGIS pour Silverlight .

Mais il n'y a actuellement aucune visionneuse ArcGIS prise en charge par Esri pour Javascript, et aucune n'est prévue .

Voir la question connexe .

«Visionneuse» est un terme qu'Esri utilise pour les applications Web qui permettent à un utilisateur de créer des applications Web de mappage sans écrire de code. En règle générale, ces applications de cartographie Web créées seront des visualiseurs, mais avec les compléments (ou widgets) appropriés, il est possible de créer des visualiseurs avec des capacités d'édition.

Aucun d'entre eux ne prend en charge les normes ouvertes , vous souffrez donc du blocage des fournisseurs et du risque de perdre votre investissement si ESRI décide que 3 est 1 ou 2 de trop.