Outils de développement pour l’iphone

Apple a lancé en début d’année une roadmap précise pour les développements sur l’Iphone avec notamment le Iphone Development Software kit (téléchargé 100,000 fois en 4 jours sur le site d’Apple après son lancement !).

Un autre programme en Béta destiné aux entreprises a été initié pour concurrencer les fonctions du Blackberry.

Le site d’Apple a un espace dédié pour les développeurs Iphone : Iphone Dev Center

Pour revenir aux SDKs de développement pour Iphone il existe plusieurs options :

- le SDK officiel vu précédemment,

- Aptana qui supporte le framework Ajax et intègre un plug-in Iphone,

- Le SDK des pirates qu’on fait soi même (open SDK)

Ci-dessous une analyse de l’officiel et du pirate :

Officiel :

Pour :

- Officiel Apple, installation via Itunes, pas besoin d’un Iphone “jailbraké” (cracké)

- Support, quand il sera disponible. Grosse documentation, simple,claire.

- Applications signées numériquement. Possibilités de revenus par téléchargement.

- IDE (XCode) parfaitement intégré, un plaisir à utiliser (= un petit wizard et on a notre premiere appli qui tourne)

Contre :

- Disponible, mais pas exploitable. En effet, le SDK est sorti et permet de faire des applications qui tournent sur l’émulateur fourni.

Cependant, pour déployer l’application sur l’iphone lui meme, il faut signer l’application via le site Apple (comprendre : l’outil sur le site n’est pas encore disponible, on ne peut donc pas signer l’application) et l’installer via Itunes ( comprendre : il faut un téléphone non piraté ). En fait, les applications développées avec le SDK officiel sont compilées pour le

firmware 2.0 qui n’est pas encore sorti (1.4 actuellement).

- Les API disponibles dans le SDK officiel sont un poil limitatives, par ex, on ne peut pas faire communiquer facilement le Javascript avec

l’application native.

Non Officiel :

Pour :

- Possible d’utiliser des API non officielles, à plus bas niveau, qui permettent de faire communiquer tres facilement le Javascript avec l’application native, ce qui permet de développer tres rapidement des UI en HTML/JS et d’avoir la puissance des transitions (par ex) natives de l’appareil.

- On peut tester dès maintenant sur le device !

Contre :

- Pas de vraie documentation. Beaucoup de taton, de recherche etc

- Impossible d’installer sur un Iphone légal, non jailbraké

- Difficile à obtenir : Il faut backuper l’Iphone sur le mac, sortir les librairies partagées (grosso modo les DLL) et exécuter un outil qui va générer des .h . Une fois qu’on à tout ca, il faut écrire le programme et faire le makefile qui va pouvoir le compiler. Une fois compilé, il faut l’installer sur l’iphone.

Android: a quick overview

Google Android is an open and free mobile platform. Android has been developed by over 30 companies (the union of them is called Open Handset Alliance) belonging to different fields such as telecommunications, semiconductors, software companies etc. The objective of those companies is to develop open standards for mobile devices. Some of them are (The complete list can be found at http://www.openhandsetalliance.com/oha_members.html):

• HTC

• Google

• Samsung

• LG

• Ebay

• Intel

• Nvidia

Android is a complete stack that includes operative system, middle-ware and applications. Some interesting features are:

• Optimized graphics powered by a custom 2D graphics library 3D graphics based on the OpenGL ES 1.0 specification

• Media support for common audio, video, and still image formats (MPEG4, H264, MP3, AAC, AMR, JPG, PNG, GIF)

• GSM Telephony

• Bluetooth, EDGE, 3G, and WiFi

• Camera, GPS, compass, and accelerometer

A bottom-up, shallow overview of the Architecture

Bottom layer. Linux 2.6 kernel. Why?

(a) The Linux kernel is used as an hardware abstraction layer. Want to bring up Android on a new device? First, bring Linux kernel on it.

(b) Linux has already a proven driver model, process management, networking, security model etc. Sometimes, drivers are already available.

(c) Linux is improved over time by a huge community. Android will benefit of this.

Middle layer: Libraries (C++) . At this level we have some libraries that constitute the core of Android. Libraries for Surface management based on SGL and OpenGLjES. Possibility to mix 2D and 3D within the same application. Then libraries for Media management, FreeType library for font management, SQLLite as a data storage, WebKit (a browser engine - the same engine that is at the basis of Safari). WebKit is modified in order to render well on small screens.

Middle layer: Runtime. At the basis of the runtime there is the “Dalvik virtual machine,” a special JVM that is developed for devices running with limited CPU power, battery and amount of memory. This virtual machine runs .Dex files that are the result (bytecode) of compiling .class files through a specific (for mobile devices) compilation process (e.g. data structures are designed to be shared among processes).

Middle layer: Java Core Libraries (On top of runtime). Here we find I/O libraries, collections, utilities and everything that is expected to be provided to the layer above.

Application layer framework (SDK). Here we find all the API provided by Google in order to build new applications. Some components of the Application layer framework are:

(a) The Window manager which is built on top of libraries for Surface management.

(b) The package manager (package installation, handling,etc).

(c) Content providers: the framework that allows to share contacts among different applications.

(d) Extensible Messaging and Presence Protocol (XMPP) service.

(e) An Activity Manager that manages the life cycle of applications and provides a common navigation backstack

3 Strenghts and weaknesses

Pros:

• Potentially, a big market because it runs on different hardware devices (Devices running Google Android expected in the second half of 2008).

• First big attempt to provide mobile phones with an innovative UI (alternative to the IPhone).

• Low-tier handset manufacturers could make cheap touchscreen phones using Android.

• Tight integration with Google products (huge customer base), tracking systems (GPS) and hardware in general.

Cons:

• Android only reuses the Java language syntax but does not provide the full class libraries and APIs bundled with Java SE or ME.

• Some parts of the SDK are still proprietary and closed source, and some believe it is a conscious decision to control the platform by Google.

• Android is, by default, an open system: good for end-users, bad for mobile network providers?

• Google Android vs OpenMoko (http://en.wikipedia.org/wiki/OpenMoko) . Which is the best open source solution?

What are Widsets?

WidSets is a mobile runtime technology, and a mobile service powered by the said technology, based on the Java MIDP 2.0 platform, from the Finnish mobile giant Nokia. It is both a widget engine and a widget deployment service where mini-applications called widgets can be uploaded to WidSets servers to be compiled and then automatically deployed to MIDP 2.0 compliant mobile phones running the WidSets client software. The widgets are created using Extensible Markup Language (XML), Cascading Style Sheets (CSS), and Helium scripting language.^[1]

WidSets was officially launched on October 2006, it worked on all Java MIDP 2.0 phones, including non-Nokia ones, and was regarded as a mobile counterpart to Netvibes.^[2] The current version as of May 2008 is version 2.0.0 for both the client and the SDK.

What can Widsets do?

In essence the widsets application allows the vast majority of mobile phones currently on the market to request information from web services and the web. Tiny applications can be downloaded to their handset which can perform functions ranging from getting the news from their favorite media source via RSS feeds to accessing their email easily on the go. Clients can use either their mobile handset or login to the widsets homepage and add widgets to their own dashboard which is then downloaded the next time they load the dashboard on their mobile handset.

One innovation of widsets is that it requires the dashboard to connect to a server that is controlled directly by Nokia. This could be seen as a negative aspect but really it is a fantastic benefit for portability. The users’ dashboard is saved on Nokia’s servers so it is easy for the user to access their own personal dashboard using any phone they wish.

Also the server process the information sent back to the client and removes any that is un-viewable not needed or not wanted by the user. This reduces the cost of sending the information and also enables the client to properly view the information they request. The user can also specify type of information they do not wish to download such as images and therefore save money. This allows non-3G phones to browse the internet without being overwhelmed with information, navigate the internet in an effective manor as well as reducing the time needed to access content over a GPRS network.

Another aspect of widsets that is very intriguing is that it uses XML for portability and accessibility. In fact any website that has its information in a RSS or ATOM feed fashion can be easily retrieved and view by the user. What’s interesting here is that many large business applications such as ERP systems (SAP, PeopleSoft) utilize XML for transferring data between their various modules. In theory a widsets widget could access information from ERP systems and deliver it to a mobile handset efficiently. Individuals could simply launch a widget from their dashboard and be able to view all sorts of statistics and information from their systems in real time on their mobile handset.

There are several limitations of widsets however. Nokia will not sell, lease or loan any of their servers that the dashboard connects to.

While the widsets API contains a lot of functionality, many aspects of it is either not implemented yet, unable to implement effectively due to restrictions on J2ME or not implemented very well. This limits some applications for the widsets framework.

Another aspect is that in order for widsets to be available to the majority of handsets on the market, limits were placed on the framework. These include not being able to save information on the phones internal memory(however an external memory card can be used for the applications to save information), no access to the phone book for privacy purposes, limiting the memory size of widgets and some graphical limitations. These was done as many phones still currently being used have limited internal memory and are not able to render some aspects of the UI effectively.

Interesting feature coming in the near future is video integration with video mobile handsets.