Développement mobile : .NET Compact Framework & Limitations
Introduction :
Le développement d’applications mobiles est quelque peu différent du développement d’applications sous Windows. En effet, le développement d’applications mobiles se base sur le .NET Compact Framework qui constitue une version allégée du .NET Framework classique de Microsoft.
Quelles sont les différences entre le Compact Framework et le Framework de base ?
Comment peut-on repousser les limites du .NET Compact Framework ?
.NET Compact Framework VS .NET Framework :
Le .NET Compact Framework présente quelques différences importantes par rapport au Framework de base. En voici une liste non exhaustive :
Classes et types : Étant une version allégée, le Compact Framework ne prend en charge qu’un sous-ensemble de la bibliothèque de classes .NET Framework. Certains espaces de noms n’existent pas et certaines classes sont allégées en termes de fonctions.
ASP.NET : Le .NET Compact Framework ne prend pas en charge l’ASP.NET.
Langages : C# et Visual Basic sont les seuls langages disponibles pour le .NET Compact Framework.
XML : Le Compact Framework .NET fournit les fonctionnalités de base pour manipuler les documents XML (DOM). De nombreuses fonctionnalités intéressantes ne sont pas prises en charge par le Compact Framework (Validation de schéma XML, Transformation XSLT, Requêtes xpath)
Accès aux données : Les classes et fonctions d’accès aux données sont également très limitées au sein du Compact Framework. “Linq To SQL” et “Entity Framework” ne sont pas supportés.
Limitations des interfaces graphiques :
Le .NET Compact Framework a été conçu pour ses performances et sa taille qui lui permet une mobilité totale. La couche “interface graphique” du .NET Compact Framework pour Windows Mobile ne concerne que des appareils avec des résolutions réduites dont la mémoire est plus limitée que celle d’un PC.
Le .NET Compact Framework comporte la plupart des contrôles graphiques du .NET Framework et aussi des contrôles spécifiques aux périphériques mobiles (InputPanel, HardwareButton).
Par rapport au Framework de base, la couche “interface graphique” possède plus de restrictions dans le .NET Compact Framework :
-
Le .NET Compact Framework ne prend pas en charge le Drag-and-drop.
-
Le .NET Compact Framework ne prend pas en charge l’impression.
-
Le .NET Compact Framework ne prend pas en charge le MDI (Multiple Document Interface).
-
Le .NET Compact Framework ne prend pas en charge les contrôles ActiveX.
-
Le .NET Compact Framework prend en charge un nombre limité de méthodes de la classe Graphics.
-
Le .NET Compact Framework ne prend pas en charge la gestion de la transparence (code alpha)
-
Le .NET Compact Framework ne prend pas en charge la propriété KeyPreview pour les formulaires.
-
Le .NET Compact Framework prend en charge un nombre limité d’évènements sur l’interface graphique.
Comment repousser les limites ?
Deux possibilités:
1) Pour repousser les restrictions liées aux contrôles graphiques, il est tout à fait possible de créer soi même toute une collection de contrôles personnalisés, en héritant de contrôles existants et en “overridant” les méthodes et évènements.
2) Pour repousser les limites du Compact Framework, il est possible d’utiliser la technique du PInvoke. Le PInvoke (Plateform Invoke) consiste à consommer une API Win32 non managée au travers de code managé .NET.
Aussi, pour certains besoins particuliers qui ne sont pas pris en charge par le Compact Framework, il peut s’avérer nécessaire d’effectuer des appels directement aux DLL systèmes de Windows Mobile.
Pour plus d’informations sur le PInvoke, voici quelques liens intéressants :
http://morpheus.developpez.com/dlldotnet/
http://www.pinvoke.net/
Exemple de PInvoke :
L’exemple ci-dessous, non détaillé, montre comment la fonctionnalité du PInvoke peut être utilisée pour repousser les limitations du .NET Compact Framework.
Dans cet exemple, la classe “SoundManager” permet la lecture simple de sons en faisant appel à la DLL Windows Mobile “codedll.dll”.
Pour que le terminal mobile joue un son, il suffit d’appeler la méthode “PlaySound” en spécifiant le chemin du fichier son.
public class SoundManager
{
[DllImport("CoreDll.dll", EntryPoint = "PlaySound", SetLastError = true)]
private extern static int PlaySound(string szSound, IntPtr hMod, int flags);
public enum PlaySoundFlags : int
{
SND_SYNC = 0x0000,
SND_ASYNC = 0x0001,
SND_NODEFAULT = 0x0002,
SND_MEMORY = 0x0004,
SND_LOOP = 0x0008,
SND_NOSTOP = 0x0010,
SND_NOWAIT = 0x00002000,
SND_ALIAS = 0x00010000,
SND_ALIAS_ID = 0x00110000,
SND_FILENAME = 0x00020000,
SND_RESOURCE = 0x00040004
}
public static void PlaySound(string soundPath)
{
PlaySound(soundPath, IntPtr.Zero, (int)(PlaySoundFlags.SND_FILENAME
| PlaySoundFlags.SND_SYNC));
}
}
Pi-R.
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :