Appcelerator vient de lancer la version 1.0 de Titanium, l’environnement de développement permettant de créer des applications natives pour iPhone, Android ou BlackBerry, ainsi que les systèmes d'exploitation PC.
Titanium vs Adobe AIR
Titanium tente de faire de l’ombre à AIR d’Adobe en proposant un système qui facilite grandement le développement d’applications pour PC et plateformes mobiles. Titanium permet de créer des programmes qui disposent d'une interface et des fonctions similaires aux programmes natifs, ce qui n'est pas toujours le cas d'AIR. C’est donc un sérieux concurrent au potentiel important.
Pour les développeurs web
Titanium utilise les langages web tels que le HTML, le PHP, le JavaScript ou Ruby. Le but est d’éviter aux développeurs web d’avoir à apprendre à programmer pour chacun des systèmes (Windows, Mac OS X, Linux, iPhone OS, Android ou BlackBerry), puisque c’est le traducteur qui se charge de créer une application native en Objective-C ou en Java par exemple.
Contrairement aux autres environnements de ce genre, comme Rhomobile Rhodes, les programmes écrits sous Titanium peuvent accéder aux fonctionnalités des terminaux, comme l’appareil de photos ou la base de données et la gestion du Push. Ce sont en tout plus de 100 fonctions natives qui sont à la disposition du développeur.
Performances et prix
La nouvelle version a des temps de chargement en dessous de 3 secondes, contre 10 à 20 secondes auparavant. Les transitions entre les pages sont instantanées et le traitement des données a été multiplié par cinq.
Appcelerator propose deux offres : Titanium Community qui est gratuit et Titanium Professional qui coûte 199 $ (env. 150 €) par mois et inclut une assistance technique, six mois de solutions analytiques et la possibilité de profiter des nouvelles plateformes. L’éditeur devrait d’ailleurs gérer l’iPad d’ici une semaine.
Et pourtant une application native pour Android est belle et bien dans un dérivé de Java...
Je vais peut-être dire une bêtise, mais ça n'existe pas les processeurs exécutant directement le code JAVA ?
PicoJava, Majc (quoi que c’est du code compilé JIT là), Cjip, aJ-100/aJ-102, JStar (dans une certaine mesure, vu que c’est plutôt un « accélérateur JAVA » à incorporer à un CPU existant)…
Si tu connaissais ton sujet, t'insulterais pas : y a pas mal d'appareils mobiles qui sont capables de travailler directement sur du bytecode java, notamment ce qui est basé sur du ARM (il y a une extension du jeu d'instruction adaptée à ça)
Java = ByteCode = Language Interpreté != de code natif.
Donc après, je ne crois pas qu'il existe une réelle définition de code natif .... A la limite tant que le processeur comprend directement une commande on pourrait dire que c'est natif (et du coup Zymoth a tord - j'ai dit que j'étais seulement "un peu" d'accord). Mais après si même exécuté directement par le processeur, le code est "lent" dû à un assemblage de commandes pas toutes nécessaires (c'est le problème d'utiliser des fonctions génériques), alors je ne sais pas si ça correspond à ce que la plupart des développeurs entendent par code natif ....
Voilà, tout ça pour apporter un peu d'eau au moulin de Zymoth même si je pense que le terme "natif" est mal défini.
JAZELLE (et d'autres), c'est du java en natif, en l'occurence sans passer par une machine virtuelle logicielle, donc.
Non, mais on te dit que les CPU lisent le ByteCode directement.
On a l'impression que les couches logicielles sont passées dans les processeurs. Du coup ils sont moins rapides qu'en théorie sur le papier ... et le code natif d'antan n'est plus forcément le même aujourd'hui.
Enfin, en intégrant les langages de haut niveau dans les processeurs on facilite la vie des programmeurs. C'est marrant comme on revient aux machines qui avaient un langage de haut niveau en ROM (sauf que là c'est au niveau processeur).
C'est pas une couche en plus, c'est le fonctionnement du CPU, prévu pour fonctionner en RISC et adapté pour accepter du CISC en entrée, mais c'est dans le design, ça accélère, ça ralentit pas.