PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV Mobile 2025 → Impression Android
Impression Android
Débuté par ap17, 25 jan. 2024 10:58 - 8 réponses
Membre enregistré
98 messages
Posté le 25 janvier 2024 - 10:58
Bonjour à tous,
Petite question d'ordre général, arrivez-vous à faire des impressions à partir d'un appli Android (développée avec WindevMobile) de même qualité qu'avec une appli Windows (développé avec Windev)

Il semble qu'Android ait des limitations qui empêche d'obtenir la même qualité, en particulier au niveau des cadres, des images, etc...
Actuellement ça oblige nos utilisateurs à imprimer avec le logiciel Windows des rapports saisis sur le terrain avec l'appli Android.

Ma question fait appel à vos connaissances et expériences afin de savoir si nous devons continuer à essayer ou bien s'il n'y a pas de solution sous Android (et dans ce cas comment contournez-vous le problème ? comme nous ? )

Merci de me faire part de vos expériences
Membre enregistré
482 messages
Posté le 25 janvier 2024 - 11:04
Bonjour

juste pour avoir plus de précisions, quand vous dites sur le terrain vous entendez quoi : dans vos locaux mais pas dans les bureaux par exemple, ou en extérieurs à votre entreprise ? vos utilisateurs pourraient avoir des imprimantes nomades ?
Posté le 25 janvier 2024 - 11:31
Bonjour,

Nous sommes dans le même cas de figure : rapports effectués sur le terrain, génération d'un PDF et envoi aux contacts.
J'arrive à un résultat similaire appli (iOS et Android) / soft au prix de quelques adaptations :
- pas de RTF, remplacé par du Markdown
- attention aux polices
- pas de requêtes dans l'état mais des fichiers HFSQL locaux initialisés avant l'impression
- calcul de la largeur des textes pour le surlignage en couleur
- à qualité égale, les PDF générés avec l'appli sont plus volumineux qu'avec le soft, donc compression si besoin
- pour le reste (cadres, etc.) pas vraiment de problème, à voir où sont les cadres : blocs eux-mêmes, libellés, .... Sachant qu'on a les blocs standards, des ruptures, des blocs d'itération et qu'on enchaine plusieurs états.

Donc oui, je pense que ça vaut le coup de continuer.
Membre enregistré
98 messages
Posté le 25 janvier 2024 - 12:45
Bonjour Dimitri,
Dans notre cas sur le terrain ça veut dire en général chez le client ou sur des chantiers. Le résultat du rapport doit être un PDF envoyé par mail dans 90 % des cas ou imprimé et laissé sur place dans 10% (mais dans tous les cas le PDF est envoyé par mail)
Membre enregistré
98 messages
Posté le 25 janvier 2024 - 12:52
Bonjour ap18 (pseudo créé pour répondre à ap17 ? :o)
Merci pour ce retour, en effet on est sur ces pistes mais ça nécessite de recalculer beaucoup de chose dans l'état (tailles, positions, etc..) ça prend beaucoup de temps pour un résultat parfois aléatoire. On va donc continuer quand même un peu dans ce sens....
Je ne comprends pas pourquoi il ne faut pas utiliser de requêtes mais des tables ??? vous avez une explication sur l'intérêt ?
Posté le 25 janvier 2024 - 15:35
Pour le pseudo oui je me suis senti proche en lisant le post ;)
Je confirme que ça prend du temps, mais j'ai pas eu le choix, les utilisateurs enchaînent les chantiers et n'ont pas toujours envie de repasser le soir au bureau pour créer et envoyer les PDF.
Pour les requêtes aucun intérêt non, simplement certaines requêtes bloquaient - je ne me souviens trop du pourquoi - du coup j'avais dû procéder comme ça. Donc si pas de souci de ce côté là pour vous tant mieux.
Je me souviens aussi avoir cherché du côté d'un webservice pour générer le PDF directement sur le serveur mais j'avais vite abandonné car il tournait sous linux et il fallait installer et configurer des librairies graphiques, pas mon domaine du tout...
Membre enregistré
98 messages
Posté le 25 janvier 2024 - 16:33
amusant, car nous avons aussi envisagé d'installer un webservice (dont le développement a d'ailleurs été aussi commencé) ce qui nous paraissait au final la solution la plus simple. Mais notre appli fonctionne aussi en mode déconnecté (car sur le terrain pas toujours de réseau) et dans ce cas, le web service ne sert à rien... vous me direz qu'il faut de toute façon retrouver du réseau pour envoyer le mail...mais pour les impressions papier laissées sur les machines il n'y aurait pas besoin de réseau
je vois que nous avons des problématiques très similaires ..et solutions qui le sont forcément aussi ;)
Membre enregistré
7 messages
Posté le 26 janvier 2024 - 01:57
Bonjour, de mon côté, j'ai également réussi à mettre en place l'impression directe d'un ticket de caisse en créant une bibliothèque Java distincte. En outre, j'ai pris en charge les trois modes de communication : Réseaux, USB et Bluetooth. Dès que j'aurai le temps, je mettrai en ligne les instructions et la bibliothèque associée.





Message modifié, 26 janvier 2024 - 02:17
Membre enregistré
1 message
Posté le 15 mars 2025 - 00:53
Ibrahim a écrit :
Bonjour, de mon côté, j'ai également réussi à mettre en place l'impression directe d'un ticket de caisse en créant une bibliothèque Java distincte. En outre, j'ai pris en charge les trois modes de communication : Réseaux, USB et Bluetooth. Dès que j'aurai le temps, je mettrai en ligne les instructions et la bibliothèque associée.





Message modifié, 26 janvier 2024 - 02:17

Salut Ibrahim, j'essaie de faire quelque chose de semblable sans beaucoup de succès, pourrais-tu partager l'astuce de la bibliothèque Java stp? Merci d'avance!