Programmation de droid : le client lourd

Magazine
Marque
GNU/Linux Magazine
Numéro
123
Mois de parution
janvier 2010


Résumé

Dans cet article, nous allons voir comment faire une application de carnet d’adresses électronique en mode 3 tiers. Autrement dit, nous allons aborder la mise en place d’une couche de persistance via Hibernate, la notion de couche métier, et enfin une couche d’interface graphique. J’avais en effet envie de montrer (et c’est le principal but de ces lignes) comment, en découpant bien notre application, et en choisissant avec soin les briques de base, il est possible de fournir 2 interfaces graphiques très différentes. La première est une interface type « client lourd » à utiliser sur son PC de bureau. La deuxième permet d’utiliser les mêmes données que la précédente, mais fonctionnera sur le téléphone portable de Google « Android ».


1. Présentation de notre application de carnets d’adresses

Le but de cet article est de voir comment faire une petite application de carnets d’adresses électronique qui puisse avoir plusieurs interfaces graphiques différentes. Le but du jeu est donc qu’avec chacune des interfaces, nous accédions aux informations du carnet contenues dans une base de données.

Avec ce synopsis, il y a au moins deux façons de faire notre film.

La technique du programmeur a l’ancienne. Ce genre de personnage va monter son application de A à Z en optimisant son code pour que cela marche bien. Le principal avantage de cette approche est un programme relativement court, bien écrit et rapide.

Enfin le premier désavantage de cette approche est un temps de développement plus long. Le deuxième, et non des moindres, est que ce type de programmeur est un artisan, un esthète de l’informatique. L’un dans l’autre, cela peut se révéler sympathique, mais le principal souci est...

Cet article est réservé aux abonnés. Il vous reste 98% à découvrir.
S'abonner à Connect
  • Accédez à tous les contenus de Connect en illimité
  • Découvrez chaque semaine un nouvel article premium
  • Consultez les nouveaux articles en avant-première
Je m'abonne


Article rédigé par

Par le(s) même(s) auteur(s)

Base de données embarquée dans un navigateur

Magazine
Marque
GNU/Linux Magazine
Numéro
164
Mois de parution
octobre 2013
Spécialité(s)
Résumé

Cela fait quelques années que je vends du logiciel et… soit je n’ai pas de chance, soit c’est le marché qui veut ça, mais pour une application client lourd (QT,Swing,GTK…) que j’écris, je vends 3 applications Web. Ces applications Web sont des applications style « desktop », mais vivantes, soit dans un navigateur Internet « standard », soit sur le navigateur d’un téléphone/tablette. Là où ça se complique, c’est qu’une application lourde interagit rapidement et « fonctionne » sans Internet… Deux trucs « difficiles » à mettre en place pour les applications Web.Il devient assez complexe de faire comprendre à son client qu’une application Web 2.0 ne peut fonctionner sans Internet alors qu’une vieille application client lourd (Pre-Web 1.0 ?) le peut.

Les derniers articles Premiums

Les derniers articles Premium

Game & Watch : utilisons judicieusement la mémoire

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Au terme de l'article précédent [1] concernant la transformation de la console Nintendo Game & Watch en plateforme de développement, nous nous sommes heurtés à un problème : les 128 Ko de flash intégrés au microcontrôleur STM32 sont une ressource précieuse, car en quantité réduite. Mais heureusement pour nous, le STM32H7B0 dispose d'une mémoire vive de taille conséquente (~ 1,2 Mo) et se trouve être connecté à une flash externe QSPI offrant autant d'espace. Pour pouvoir développer des codes plus étoffés, nous devons apprendre à utiliser ces deux ressources.

Raspberry Pi Pico : PIO, DMA et mémoire flash

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Le microcontrôleur RP2040 équipant la Pico est une petite merveille et malgré l'absence de connectivité wifi ou Bluetooth, l'étendue des fonctionnalités intégrées reste très impressionnante. Nous avons abordé le sujet du sous-système PIO dans un précédent article [1], mais celui-ci n'était qu'une découverte de la fonctionnalité. Il est temps à présent de pousser plus loin nos expérimentations en mêlant plusieurs ressources à notre disposition : PIO, DMA et accès à la flash QSPI.

Programmation des PIO de la Raspberry Pi Pico

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

La carte Pico de Raspberry Pi est appréciable à bien des égards. Ses ressources, son prix, ses deux cœurs ARM... Mais ce morceau de silicium qu'est le RP2040 renferme une fonctionnalité unique : des blocs PIO permettant de créer librement des périphériques supplémentaires qu'il s'agisse d'éléments standardisés comme SPI, UART ou i2c, ou des choses totalement exotiques et très spécifiques à un projet ou un environnement donné. Voyons ensemble comment prendre en main cette ressource et explorer le monde fantastique des huit machines à états de la Pico !

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous