Anass Boukalane

Android for Beginners

2012-06-06T06:35:00.003-07:00

The Android platform

Android is a software environment built for mobile devices. It’s not a hardware platform.

Android includes a Linux kernel-based OS, a rich UI, end-user applications,

code libraries, application frameworks, multimedia support, and much more. And,

yes, even telephone functionality is included! Whereas components of the underlying

OS are written in C or C++, user applications are built

for Android in Java. Even the built-in applications are

written in Java. With the exception of some Linux

exploratory exercises in chapter 13 and the Native

Developer Kit (NDK) in chapter 19, all the code

examples in this book are written in Java, using the

Android software development kit (SDK).

One feature of the Android platform is that

there’s no difference between the built-in applications

and applications that you create with the SDK.

This means that you can write powerful applications

to tap into the resources available on the device. Figure

1.1 shows the relationship between Android and

the hardware it runs on. The most notable feature of

Android might be that it’s open source; missing elements

can and will be provided by the global developer

community. Android’s Linux kernel-based OS

doesn’t come with a sophisticated shell environment,

but because the platform is open, you can write and

install shells on a device. Likewise, multimedia codecs

can be supplied by third-party developers and don’t need to rely on Google or anyone else to provide new functionality. That’s the power of an open source platform brought to the mobile market.

The layers of Android

The Android stack includes an impressive array of features for mobile applications. In

fact, looking at the architecture alone, without the context of Android being a platform

designed for mobile environments, it would be easy to confuse Android with a

general computing environment. All the major components of a computing platform

are there. Here’s a quick rundown of prominent components of the Android stack:

 A Linux kernel that provides a foundational hardware abstraction layer, as well as

core services such as process, memory, and filesystem management. The kernel

is where hardware-specific drivers are implemented—capabilities such as Wi-Fi

and Bluetooth are here. The Android stack is designed to be flexible, with

many optional components that largely rely on the availability of specific hardware

on a given device. These components include features such as touch

screens, cameras, GPS receivers, and accelerometers.

 Prominent code libraries, including the following:

• Browser technology from WebKit, the same open source engine powering

Mac’s Safari and the iPhone’s Mobile Safari browser. WebKit has become the

de facto standard for most mobile platforms.

• Database support via SQLite, an easy-to-use SQL database.

• Advanced graphics support, including 2D, 3D, animation from Scalable

Games Language (SGL), and OpenGL ES.

• Audio and video media support from PacketVideo’s OpenCORE, and

Google’s own Stagefright media framework.

• Secure Sockets Layer (SSL) capabilities from the Apache project.

 An array of managers that provide services for

• Activities and views

• Windows

• Location-based services

• Telephony

• Resources

(continued)

Contrast Apple’s approach to application distribution with the freedom Android

developers enjoy to ship applications via traditional venues such as freeware and

shareware, and commercially through various marketplaces, including their own

website! For software publishers who want the focus of an on-device shopping experience,

Google has launched and continues to mature the Android Market. For software

developers who already have titles for other platforms such as Windows

Mobile, Palm, and BlackBerry, traditional software markets such as Handango

(www.Handango.com) also support selling Android applications. Handango and its

ilk are important outlets; consumers new to Android will likely visit sites such as

Handango because that might be where they first purchased one of their favorite

applications for their prior device.

The layers of Android 11

 The Android runtime, which provides

• Core Java packages for a nearly full-featured Java programming environment.

Note that this isn’t a Java ME environment.

• The Dalvik VM, which employs services of the Linux-based kernel to provide an

environment to host Android applications.

The Intent of Android development

Let’s jump into the fray of Android development, focus on an important component

of the Android platform, and expand to take a broader view of how Android applications

are constructed.

An important and recurring theme of Android development is the Intent. An

Intent in Android describes what you want to do. An Intent might look like “I want

to look up a contact record” or “Please launch this website” or “Show the order confirmation

screen.” Intents are important because they not only facilitate navigation in

an innovative way, as we’ll discuss next, but also represent the most important aspect

of Android coding. Understand the Intent and you’ll understand Android.

NOTE Instructions for setting up the Eclipse development environment are in

appendix A. This environment is used for all Java examples in this book. Chapter

2 goes into more detail on setting up and using the development tools.

The code examples in this chapter are primarily for illustrative purposes.

We reference and introduce classes without necessarily naming specific Java

packages. Subsequent chapters take a more rigorous approach to introducing

Android-specific packages and classes.

Next, we’ll look at the foundational information about why Intents are important,

and then we’ll describe how Intents work. Beyond the introduction of the Intent,

the remainder of this chapter describes the major elements of Android application

development, leading up to and including the first complete Android application that

you’ll develop.

Four kinds of Android components

Let’s build on your knowledge of the Intent and IntentFilter classes and explore

the four primary components of Android applications, as well as their relation to the

Android process model. We’ll include code snippets to provide a taste of Android

application development. We’re going to leave more in-depth examples and discussion

for later chapters.

Activity

An application might have a UI, but it doesn’t have to have one. If it has a UI, it’ll have

at least one Activity.

The easiest way to think of an Android Activity is to relate it to a visible screen,

because more often than not there’s a one-to-one relationship between an Activity

and a UI screen. This relationship is similar to that of a controller in the MVC paradigm.

Android applications often contain more than one Activity. Each Activity displays

a UI and responds to system- and user-initiated events. The Activity employs

one or more Views to present the actual UI elements to the user.

Service

If an application is to have a long lifecycle, it’s often best to put it into a Service. For

example, a background data-synchronization utility should be implemented as a

Service. A best practice is to launch Services on a periodic or as-needed basis, triggered

by a system alarm, and then have the Service terminate when its task is complete.

Like the Activity, a Service is a class in the Android runtime that you should

extend, as shown in the following listing.

BroadcastReceiver

If an application wants to receive and respond to a global event, such as a ringing

phone or an incoming text message, it must register as a BroadcastReceiver. An

application registers to receive Intents in one of the following ways:

 The application can implement a element in the Android-

Manfest.xml file, which describes the BroadcastReceiver’s class name and

enumerates its IntentFilters. Remember, the IntentFilter is a descriptor of

the Intent an application wants to process. If the receiver is registered in the

AndroidManifest.xml file, the application doesn’t need to be running in order to be triggered. When the event occurs, the application is started automatically

upon notification of the triggering event. Thankfully, all this housekeeping is

managed by the Android OS itself.

 An application can register at runtime via the Context class’s register-

Receiver method.

Like Services, BroadcastReceivers don’t have a UI. Even more important, the code

running in the onReceive method of a BroadcastReceiver should make no assumptions

about persistence or long-running operations. If the BroadcastReceiver

requires more than a trivial amount of code execution, it’s recommended that the

code initiate a request to a Service to complete the requested functionality because

the Service application component is designed for longer-running operations

whereas the BroadcastReceiver is meant for responding to various triggers.

ContentProvider

If an application manages data and needs to expose that data to other applications

running in the Android environment, you should consider a ContentProvider. If an

application component (Activity, Service, or BroadcastReceiver) needs to access

data from another application, the component accesses the other application’s

ContentProvider. The ContentProvider implements a standard set of methods to

permit an application to access a data store. The access might be for read or write

operations, or for both. A ContentProvider can provide data to an Activity or

Service in the same containing application, as well as to an Activity or Service contained

in other applications.

A ContentProvider can use any form of data-storage mechanism available on the

Android platform, including files, SQLite databases, or even a memory-based hash

map if data persistence isn’t required. The ContentProvider is a data layer that provides

data abstraction for its clients and centralizing storage and retrieval routines in a

single place.

Sharing files or databases directly is discouraged on the Android platform, and is

enforced by the underlying Linux security system, which prevents ad hoc file access

from one application space to another without explicitly granted permissions.

Data stored in a ContentProvider can be traditional data types, such as integers and

strings. Content providers can also manage binary data, such as image data. When

binary data is retrieved, the suggested best practice is to return a string representing

the filename that contains the binary data

Introduction à log4j

2009-09-10T04:17:00.000-07:00

Introduction À Log4j - Java

log4j est un framework extensible qui permet de logger et débugger vos applications Java. Lorsqu’on commence à l’utiliser, il devient impossible de s’en passer tellement il est pratique. C’est gratuit et opensource. (Apache Software License 1.1)

Objectifs

Dans ce tutoriel nous allons apprendre les bases de log4j :

Concepts fondamentaux
Installation
Configuration
Utilisation

Prérequis

Connaître les bases de Java

Concepts fondamentaux

Le framework utilise trois types de composant :

Logger
Appender
Layout

Ces composants communiquent entre eux pour déterminer :

Quel messages doivent être loggés
La façon de logger les messages
La présentation des messages

Logger

Le Logger est le point d’entrée d’un message. C’est pratiquement une des seules classes que nous allons utiliser.
log4j gère les Logger de façon hiérarchique. C’est à dire qu’un Logger peut avoir des enfants et des parents. La hiérarchie est gérée par le nom des Logger. Les niveaux sont définis par des points, un peu comme la structure des packages de classes. Par exemple :

com 
com.liguo
com.liguo.layout

com est le parent de com.liguo et l’ancêtre de com.liguo.layout
log4j possède par défaut un Logger à la racine de la hiérarchie. Il se nomme rootLogger.
Lorsque l’on demande à log4j de créer un Logger, il vérifie dans la configuration s’il y a quelque chose de défini pour celui-ci. S’il ne trouve rien, il remonte dans la hiérarchie jusqu’à ce qu’il trouve quelque chose. C’est pourquoi le rootLogger qui est à la racine est très important.

Appender

Appender est une interface dont le rôle est de :

Filtrer les messages
Déterminer le mode de sortie des messages selon l’implémentation

Un logger peut avoir un nombre X d’appender. Pour ajouter un appender manuellement (je n’ai jamais eu à le faire), il suffit de faire :

monLogger.addAppender(monAppender);

Note : Un Logger utilise les appender de ses ancêtres. Donc les appender définis pour le rootLogger seront utilisés par tousles Logger, peu importe leur niveau.
log4j fournit de base les appender utilisés pour les tâches courantes :

ConsoleAppender - envoie les messages dans la console du système (cf. Tomcat dans le cadre d’une application web)
FileAppender - envoie les messages dans un fichier
SocketAppender - envoie les messages dans un Socket
SMTPAppender - envoie les messages par mail

Il en existe d’autres pour les utilisateurs plus avancés et il est évidemment possible de créer son propre appender custom en implémentant l’interface org.apache.log4j.Appender

Layout

Les Layout définissent le format du message. Je peux par exemple avoir la date, l’heure, le nom de la classe qui envoie le message et le niveau de logging au début de chaque message. C’est le rôle du Layout de faire ça et non celui du développeur qui envoie le message.

Niveau

Lorsqu’on envoie un message à un logger, il faut spécifier un niveau. Par défaut log4j offre les niveaux suivants :

DEBUG
INFO
WARN
ERROR
FATAL

Les niveaux sont gérés par ordre de priorité, DEBUG étant le moins important.
Par exemple, durant la période de développement, on utilise le niveau DEBUG. Une fois que l’application est déployée en production, on change le niveau pour WARN afin d’ignorer les messages de debugage, Sans modifier une seule ligne dans notre code.
Note : Il est possible de créer ses propres niveaux.

Installation

Bon c’est fini pour la théorie, passons maintenant aux choses sérieuses.
Il faut tout d’abord aller sur le site de la fondation Apache pour télécharger log4j :
http://logging.apache.org/log4j/docs/download.html
Télécharger la dernière version stable. Ensuite extraire l’archive dans n’importe quel répertoire de votre disque dur.
L’archive devrait avoir la structure de répertoires suivante :

logging-log4j-x.x.x
- build
- contribs
- dist
- docs
- exemples
- src

Le répertoire dist devrait contenir un sous-répertoire lib. Ce dernier devrait contenir le fichier log4j-x.x.x.jar (remplacez x.x.x par le numéro de version)
Pour installer log4j, il suffit d’inclure le fichier log4j-x.x.x.jar dans le classpath. Dans le cas d’une application web avec Tomcat, c’est dans le répertoire /WEB-INF/lib
Et voilà, c’est fini pour l’installation.

Configuration

Il existe plusieurs façons de configurer log4j. Celle que nous allons utiliser est assez simple et souple. Nous allons mettre ça dans un fichier de propriétés externe. Donc pas besoin de recompiler notre code pour modifier la configuration.
Créez tout d’abord un fichier nommé log4j.properties et sauvegardez le dans le classpath de votre application. Dans le cas d’une application web avec Tomcat, c’est dans le répertoire /WEB-INF/classes
Voici le contenu de notre fichier : (les lignes avec un # sont des commentaires)

#définition du niveau et des Appender du rootLogger
log4j.rootLogger=DEBUG, monAppender
 
#configuration de "monAppender"
#nous allons envoyer les messages dans la console de Tomcat
log4j.appender.monAppender=org.apache.log4j.ConsoleAppender
 
#définition du Layout pour "monAppender"
log4j.appender.monAppender.layout=org.apache.log4j.PatternLayout
 
#définition du pattern d'affichage pour "monAppender"
#voici un exemple de sortie que l'on va obtenir : 2005-06-18 14:53:37 DEBUG [Main] Hello World
log4j.appender.monAppender.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p [%c{1}] %m%n

Pour avoir plus d’infos sur la construction d’un pattern, aller faire un tour sur cette page
Si par exemple je veux modifier le niveau de logging des classes se trouvant dans le package com.liguo.layout, je n’ai qu’à ajouter la ligne suivante dans le fichier de configuration :

log4j.logger.com.liguo.layout=WARN

Utilisation

Pour l’utilisation, je vais reprendre une simple classe

import org.apache.log4j.Logger;
 
public class HelloService {
 
        /**
         *déclaration et création du Logger 
         *on le met statique afin d'économiser la mémoire
         */
        private final static Logger logger = Logger.getLogger(HelloService.class);
 
 public String helloWorld() {
                logger.debug("Le service helloWorld est invoqué");
  return "Hello, world";
 }
 
}

Si jamais la construction du message est lourde (transformation d’un DOM XML en String, concanénation de String, conversion de valeur numérique en String, etc..), il suffit d’utiliser la méthode isDebugEnabled() afin de vérifier si le logger ignorera ou non ce message.

if(logger.isDebugEnabled()){
   logger.debug("Affiche de la section #" + sectionId);
}

Conclusion

Tout ceci est suffisant pour utiliser log4j, mais ce n’est qu’un bref aperçu de tout ce qu’il peut faire. Étant un framework extensible, la seule limite à son utilisation est l’imagination du développeur !
Exemple simple : on pourrait décider d’envoyer un mail aux développeurs pour les messages de niveau ERROR et FATAL qui sont lancés dans une application qui est en production. De cette façon, on est toujours au courant de l’état de notre application sur le serveur sans toujours avoir les yeux collés sur le fichier de log.

Flex and XML, or E4X.

2009-09-07T20:37:00.000-07:00

Flex 3 and ActionScript 3.0 provide ECMAScript for XML, or E4X, implementation
that enables you to work with dot notation to access the nodes within an XML hierarchy.
E4X provides a simplified shorthand notation so you can access specific nodes or
sets of nodes by name or by index without complicated custom recursive functions. It
also defines methods and properties for accessing all parts of the XML object, including
comments, namespaces, and processing instructions. The Flex Framework and ActionScript
3.0 define two low-level objects for working with XML: the XML object and
the XMLList object. The XML object represents a single XML element, an XML document
with multiple children, or a single-value element within a document. The XMLList object
represents a set of XML elements that are siblings of one another. XMLList objects do
not require a top-level node, for example:
<item id="2" name="Chewing Gum"/>
<item id="3" name="Cotton Candy"/>
<item id="4" name="Candy Bar"/>
XML objects do require a top-level node:
<order>
<item id="2" name="Chewing Gum"/>
<item id="3" name="Cotton Candy"/>
<item id="4" name="Candy Bar"/>
</order>
To perform XML transformations or to build XML documents, both the XML and
XMLList objects define methods to append, rename, and re-parent nodes within an XML
document. To perform queries, access particular attributes, or filter XML documents,
use the E4X querying syntax. For working with XML namespaces, the XMLUtil class
defines methods of accessing and comparing namespaces.

Load an XML File :

By default, the HTTPService component converts any loaded XML into an ActionScript
object. To ensure that the HTTPService component does not convert the loaded XML
to an object, set the resultFormat property of the HTTPService object to E4X as shown:
<mx:HTTPService url="http://server/xmlDoc.xml" id="xmlService" resultFormat="e4x"
result="xmlObj = XML(xmlService.lastResult)"/>
The lastResult of the HTTPService is used to set the value of the xmlObj variable here.
If the XML file is static or you need to load it only once, it is easier and lighter to use
the flash.net.URLLoader class to load the data:
private var loader:URLLoader = new URLLoader();
private function init():void {
loader.addEventListener(Event.COMPLETE, setResult);
var req:URLRequest = new URLRequest();
req.url = "http://server/xmlDoc.xml";
   loader.load(req);
}
private function setResult(event:Event):void {
   trace(XML(loader.data).toString());
}
The Event.COMPLETE event listener must be added to the URLLoader so that the application
can be notified when the file is finished being loaded. The loaded data is stored as
the URLLoader.data property and is not cast or altered at all. If the XML data will be
dynamically generated or will need to be loaded multiple times, it may be easier to load
the file by using HTTPService. A complete code listing using both methods is shown here:
<mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml" width="400" height="300"
creationComplete="init()">

<mx:HTTPService url="http://server/xmlDoc.xml" id="xmlService" resultFormat="e4x"
result="xmlObj = XML(xmlService.lastResult)"/>
<mx:Script>

<![CDATA[
private var loader:URLLoader = new URLLoader();
[Bindable]
private var xmlObj:XML;
private function init():void {
   loader.addEventListener(Event.COMPLETE, setResult);
}
private function urlLoaderSend():void {
   var req:URLRequest = new URLRequest();
   req.url = "http://server/xmlDoc.xml";
   loader.load(req);
}
private function setResult(event:Event):void {
   xmlObj = (loader.data as XML)
}
]]>
</mx:Script>
<mx:Button click="xmlService.send()"/>
<mx:Button click="urlLoaderSend()" label="load via URLLoader"/>
<mx:TextArea text="{xmlObj.toString()}"/>
</mx:VBox>

your first google map on Flex

2009-09-05T19:18:00.000-07:00

here is a sample about using google map api in order to create your first google map Application :
Requirements :

adobe flex builder
the librerie from google "map_flex_1_16.swc" , you can download it from this link :
http://maps.googleapis.com/maps/flash/release/sdk.zip

Steps :

Before you begin coding your application, you should first set up a project within FlexBuilder. To do so, follow these simple steps:

Select File-New-Flex Project within FlexBuilder. The New Flex Project dialog box appears. Enter in the name for your project and a location to store files related to the project, leaving the Application Type as a Web Application.

Click Finish and your project will be created. FlexBuilder will also automatically create a template MXML file, as shown below:

Linking to the Google Maps API for Flash Library

Before you can compile your code, you will need to link it to the Google Maps API for Flash SWC file. To do so, select Project-Properties. A Propertiesdialog box will appear for your project. Click on Flex Build Path and then select the Library Path tab:

Click Add SWC... within the Library Path pane. An Add SWC dialog box will appear. Navigate to the location where you saved the Google Maps API for Flash SDK and select the appropriate lib/map_flex_*.swc file and click OK. (Note: Make sure you select the correct SWC. FlexBuilder will not be able to use the non-Flex SWC library.) Your dialog box should now look like the following:

Click OK. FlexBuilder will update your project and you return you to the Flex Development Perspective showing your skeleton MXML file.

You may wish to test compilation of your skeleton MXML file at this point to ensure your development environment is working correctly. open your mxml file and copy the following code :

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" initialize="init()">
<mx:Script>
<![CDATA[
import com.google.maps.Map; import com.google.maps.MapEvent;
import com.google.maps.MapType;
import com.google.maps.controls.*;
import com.google.maps.LatLng;
private var gMap:Map;
//Init function
private function init():void {
gMap = new Map();
gMap.key = "{}";
gMap.addEventListener(MapEvent.MAP_READY, mapReadyHandler); mapContainer.addChild(gMap);
}
//
private function mapReadyHandler(e:MapEvent):void {
gMap.setCenter(new LatLng(40.718119, -73.995667), 13, MapType.HYBRID_MAP_TYPE); gMap.setSize(new Point(mapContainer.width, mapContainer.height)); gMap.setZoom(14,false);
gMap.addControl(new PositionControl());
gMap.addControl(new ZoomControl());
gMap.addControl(new MapTypeControl());
} ]]>
</mx:Script>
<mx:UIComponent id="mapContainer" width="60%" height="80%"/>
</mx:Application>

Flex and Google Map

2009-09-05T09:11:00.000-07:00

i will post some samples about how to use GoogleMap in flex