ARM sort un IDE gratuit pour le développement natif sous Android

ARM sort un IDE gratuit pour le développement natif sous Android
L'édition communautaire d'ARM Development Studio 5



ARM ltd, développeur de l'architecture éponyme, vient d'annoncer la disponibilité de Development Studio 5 (DS-5) en édition communautaire (CE).

Cette édition permettra de développer sans frais de licence, des applications Android natives en C/C++ allant jusqu'à quatre fois plus vite que le code Java.

Ce toolkit est fondé sur Eclipse. Il vient compléter les SDK et NDK (Native Developement Kit) d'Android de Google, en s'y distinguant par une meilleure optimisation de la consommation énergétique, affirme le constructeur britannique.

ARM DS-5 CE intègre un débogueur graphique pour le code natif donnant accès à des informations-processeur avancées.

Cette édition communautaire intègre aussi une version adaptée à Android de l'outil d'analyse des performances ARM Streamline. Ce dernier permet de localiser les goulets d'étranglement dans le code et isoler ce qui les provoque.

DS-5 Community Edition est réservée aux développeurs indépendants et aux entreprises de moins de dix employés. L'IDE est disponible en version plus complète (et payante) depuis septembre 2010.

Le Toolkit requiert à la fois le SDK et le NDK d'Android et s'installe à partir d'Eclipse via la source http://tools.arm.com/eclipse.

http://www.youtube.com/watch?v=QXN9XgCU8Wc


:fleche: Site de l'édition communautaire

Source : ARM

Et vous ?

:fleche: Avez-vous installé/utilisé cette solution ?
:fleche: Qu'en pensez-vous ?

Si il y en a dans le coin qui ont le temps de tester un peu et de faire des retours, je suis fortement intéréssé. :D

Très bonne nouvelle. Cependant, bien que le développement natif sous Android permettent d'avoir des applications rapides (utile pour certains jeux et application de contrôle temps réel), cela casse la logique d'Android, dans le sens où l'on perd l’intérêt de la protection mémoire offerte par l'OS et de la concurrence gérée par l'OS afin d'offrir un maximum de sécurité et de longévité de la batterie.

Je ne vois pas en quoi : l'OS est seul responsable de la protection de la mémoire, que ce soit sous Android ou Windows ou n'importe quel OS moderne. Que ce soit en C++ ou en Java les memory leaks sont possibles et sont la responsabilité du développeur. Du c++ moderne esquivera sans aucun souci ce genre de problème de la même façon qu'avec Java et la mémoire de l'application sera de toutes façons isolée.

Pour la batterie, a part si l'implémentation de l'API d'Android est foireuse, à ce que je sache, utiliser C++ peut permettre de réduire de manière importante les consomations. Il n'y a pas que pour les performances que ça peut être utile.

Evidemment, le prix a payer est la complexité de l'environnement de dev et les temps de compilation...et puis connaitre le C++ moderne. :aie:

Citation:

---

Envoyé par Klaim

Je ne vois pas en quoi : l'OS est seul responsable de la protection de la mémoire, que ce soit sous Android ou Windows ou n'importe quel OS moderne. Que ce soit en C++ ou en Java les memory leaks sont possibles et sont la responsabilité du développeur. Du c++ moderne esquivera sans aucun souci ce genre de problème de la même façon qu'avec Java et la mémoire de l'application sera de toutes façons isolée.

Pour la batterie, a part si l'implémentation de l'API d'Android est foireuse, à ce que je sache, utiliser C++ peut permettre de réduire de manière importante les consomations. Il n'y a pas que pour les performances que ça peut être utile.

Evidemment, le prix a payer est la complexité de l'environnement de dev et les temps de compilation...et puis connaitre le C++ moderne. :aie:

---

Ces arguments sont valides seulement si votre application est la seule à fonctionner (avec ou sans OS) sur le terminal. Cela n'est pas le cas sur un smartphone. Il y a et il y aura plein de process et d'applications qui fonctionnent et devront fonctionner en parallel à votre application.
D'un autre coté, les applications natives ne sont pas forcément les bienvenues, car dans les smartphone on considère qu'une application et plus un module offrant des services aux autres applications qu'une application indépendante (au sens application PC). Cette complémentarité services<>consommateurs de services est bien gérée (et facilité) par la machine virtuelle d'Android. Quand on écrit une application native, il y a plein de services que l'on perd et si on ne se restreint pas à une certaine discipline, on risque même de casser cette interopérabilité, ce qui rendra rapidement (et facilement) le terminal inutilisable.

Citation:

---

Envoyé par Klaim

...et puis connaitre le C++ moderne. :aie:

---

Je ne vois pas en quoi il faudra connaitre le "C++ moderne" va servir (à moins que je ne comprenne pas trop ce que vous voulez dire par Moderne).
PS. Les API natives d'Android on existée depuis la publication d'android et il y a plein de jeux qui les utilisent. On pouvait compiler via les api native et en utilisant simplement GCC. Là l'initiative de la société ARM est louable juste dans le sens où ils offrent un environnement un peu plus élaboré (et surtout ils le font pour continuer à coincer les développeurs sur les processeur ARM ... peut être par peur de ce qui se prépare chez Inter en processeur basse consommation pour tablette 8O ).

Citation:

---

Envoyé par octal

Ces arguments sont valides seulement si votre application est la seule à fonctionner (avec ou sans OS) sur le terminal. Cela n'est pas le cas sur un smartphone. Il y a et il y aura plein de process et d'applications qui fonctionnent et devront fonctionner en parallel à votre application.
D'un autre coté, les applications natives ne sont pas forcément les bienvenues, car dans les smartphone on considère qu'une application et plus un module offrant des services aux autres applications qu'une application indépendante (au sens application PC). Cette complémentarité services<>consommateurs de services est bien gérée (et facilité) par la machine virtuelle d'Android. Quand on écrit une application native, il y a plein de services que l'on perd et si on ne se restreint pas à une certaine discipline, on risque même de casser cette interopérabilité, ce qui rendra rapidement (et facilement) le terminal inutilisable.

---

A ce que je sache, pour avoir bossé un peu sur des smartphones pré-iphone (et oui yen avait), l'OS décide quand il veut de tuer les applications gourmandes qui ne sont pas utilisées et donc ce n'est plus du ressort du développeur, a part le fait qu'il doit faire son maximum pour limiter la casse de son coté quand l'application est fermée.

De plus, pour peu que l'on veuille utiliser C++ pour ce genre de plateformes, justement le coup de l'application en mémoire sera réduit par rapport à la même application en Java. Donc c'est bénéfique pour la gestion de différentes applications (mais tout le monde n'a pas que ça a faire de passer en C++, evidemment).

Pour les services qu'il manque, pour Android je pensais que les derniers NDK permettaient justement d'avoir tous les services et de s'abstraire complètement du Java. M'aurais-t-on menti? (ça se peut)

Citation:

---

Je ne vois pas en quoi il faudra connaitre le "C++ moderne" va servir (à moins que je ne comprenne pas trop ce que vous voulez dire par Moderne).

---

Ce qu'on appelle le "c++ moderne" c'est en gros du c++ qui exploite l'idiom RAII et par conséquent des pointeurs intélligents, qui gèrent le temps de vie des resources pour soit (dans notre cas la mémoire, mais c'est vrai pour les threads etc.). En gros, c'est la C++ idiomatique qui est différent de beaucoup de code C++ qu'on voit un peu partout, qui est plus proche du "C with classes". En C++ moderne, on se prends rarement la tete avec la gestion de la mémoire (entre autre) qui est partiellement gérée naturellement par les smart pointers.

Ce que je sous entendais, pour être clair, c'est qu'aujourd'hui (et depuis qu'on a des compilateurs plus proche du standard qu'auparavant), on peut coder plus ou moins comme dans un language managé en C++, tout en ayant à tout moment l'option de mettre les mains dans le camboui pour les micro-optmizations (qui peuvent être interessantes comme dit dans les jeux gourmands, pas tous). Ca n'améliore pas les temps de compilation mais ça permet d'éviter tous les problèmes classiques du C et du C with classes comme par exemple les memory leak, les dépassement de tableau (en utiliste boost::array ou std::array au lieu des tableaux natifs) etc.

Donc en gros, coté dev aussi a priori aujourd'hui il est plutot facile (pour peu qu'on utilise du C++ "moderne") de ne pas avoir de problèmes de gestion de mémoire, tout en ayant une consomation de celle-ci et de l'energie somme toutes assez faible.

Hors "grosse appli" evidemment 8-)

Citation:

---

Envoyé par Klaim

A ce que je sache, pour avoir bossé un peu sur des smartphones pré-iphone (et oui yen avait), l'OS décide quand il veut de tuer les applications gourmandes qui ne sont pas utilisées et donc ce n'est plus du ressort du développeur, a part le fait qu'il doit faire son maximum pour limiter la casse de son coté quand l'application est fermée.

---

Si les choses étaient aussi simples que cela, tout le monde aurait utilisé Linux embdeded il y a bien longtemp avant l'arrivée d'Android. Si Android a fait une percé (en dehors du support d'une grosse boite comme google) c'est qu'il y a bien une raison. Essayez de revoir la gestion des applications sous Android et du fonctionnement de Dalvik et vous comprendrez!

Pour le C++ "moderne" c'est plus un paradigme de programmation qu'un nouvel outil de développement. On peut tout aussi bien et toujours utiliser le C++ "ancien" (ou à l'ancienne pour être plus précis) avec les outils nécessaires pour éviter et traquer les fuites mémoires sans aucun problème.

Citation:

---

Pour le C++ "moderne" c'est plus un paradigme de programmation qu'un nouvel outil de développement. On peut tout aussi bien et toujours utiliser le C++ "ancien" (ou à l'ancienne pour être plus précis) avec les outils nécessaires pour éviter et traquer les fuites mémoires sans aucun problème.

---

On peut, mais c'est totalement contre-productif. Cela reviens à dire qu'on pourrait regarder les feux rouges avant de traverser, mais autant juste traverser et faire confiances aux services d'urgences et aux ambulances pour régler le reste. (voir tous les livres "récents" (moins de 12 ans) sur le C++)


Note : le C++ moderne c'est plutot l'exploitation des idioms du language, ce n'est pas un "paradigme" (voir la définition de paradigme). C'est du C++ idiomatique, tout comme le Python idiomatique n'a plus grand chose a voir avec le Python que pond quelqu'un qui fais du Python seulement de temps en temps et qui n'as pas connaissance des idioms du language (en Python on est safe et productif sans connaitre les idioms, en C++ si on ne les connait pas on est guaranti de faire appel aux ambulances un jour pas si lointain...)

J'ai un peu cherché a propos de Dalvik mais je ne vois rien de spécial, ça reste une JVM. Je ne trouve pas l'info sur est-ceque les apllis native dans les derniers NDK sont toujours gérés via Dalvik? J'imagine que oui.

Dans tous les cas je ne vois pas bien en quoi cela change la gestion de la sécurité de la mémoire entre C++ et Java. Si ils sont sous le même environnement non-partagé, ils subissent les mêmes règles de gestion non?