Est-ce que quelqu'un connaît une API Java "standardisée" pour travailler avec des capteurs, et qui est étroitement liée à Java ME comme c'est le cas avec JSR 256? Je suis en train d'écrire une bibliothèque Java pour l'interfaçage avec un réseau de capteurs composé de plusieurs types de capteurs différents (la plupart du temps simples comme la température, l'humidité, le GPS, etc.). Jusqu'à présent, j'ai roulé ma propre interface, et les utilisateurs doivent écrire des applications par rapport à cela. Je voudrais changer cette approche et implémenter une API "standard" afin que les implémentations ne soient pas étroitement liées à ma bibliothèque. J'ai regardé JSR 256, mais ce n'est vraiment pas une bonne solution car c'est pour Java ME, et ma bibliothèque est surtout utilisée par les appareils Android ou les ordinateurs portables exécutant la version complète de Java SE.Existe-t-il une API de capteur Java SE?
Répondre
Dans android, il y a le paquet android.hardware qui contient une classe Sensor, dans l'ensemble assez similaire à l'API du capteur JSR 256. S'il vous plaît voir ce que vous pouvez faire en utilisant cela. Peut-être que c'est même une approche raisonnable pour implémenter cela dans Java SE, car pour autant que je sache, il n'y a pas d'API api Java SE.
J'ai regardé Android.le matériel, mais il est encore moins extensible que JSR-256, il est limité à Android, et il ne me permet pas d'étendre avec mes propres capteurs (aka étant limité aux capteurs du combiné). –
JSR-256 ne semble pas être limité ou restreint dans les types de capteurs qu'il prend en charge. L'Annexe E contient des définitions de capteurs, mais celles-ci ne sont que les données recommandées qu'un certain type de capteur doit gérer. Rien ne semble empêcher quelqu'un de définir des types de capteurs supplémentaires.
Je vous suggère de mettre en œuvre pour JSR-256 et il suffit d'inclure ses forfaits:
- javax.microedition.sensor
- javax.microedition.sensor.control
... dans votre distribution. Comme ils ciblent des périphériques limités, la bibliothèque est forcément très compacte. Tant qu'il ne vous sera pas interdit de redistribuer l'implémentation de référence de la JSR-256, il serait logique de prévoir de le faire.
Pas tout à fait. JSR-275 était censé avoir une partie de sa fonctionnalité (Quantités et un type d'unité très similaire à celui de 256) mais le CE SE/EE l'a refusé.
Consolidation entre SE et ME comme mentionné par Oracle peut conduire à une API de capteur plus commune et un cadre unitaire un certain temps, mais il est peu probable avant Java 8.
Werner
En effet, Oracle propage maintenant les nouvelles , une certaine forme d'API sE Sensor a été souhaitée pour Java 8.
Il a été ajouté à OpenJDK Java après 8: http://openjdk.java.net/projects/dio/ fonctionne à la fois avec Java ME et sE (embedded).
Où cela a-t-il été annoncé? –
C'est une bonne question. Je suppose que je l'ai supposé, parce qu'il a été accepté comme projet OpenJDK. De toute façon, j'avais tort. Commentaire supprimé. – Tuupertunut
Non, ça ne veut rien dire ;-) Il y a aussi un projet OpenJDK Kona: http://openjdk.java.net/projects/kona/ mais il n'a pas vu beaucoup d'activité depuis juillet 2015, ni sur les mailing lists: http : //mail.openjdk.java.net/pipermail/kona-dev/ ni ailleurs. –
JSR-256 est destiné à J2ME, selon ceci: http://jcp.org/en/jsr/tech?listBy=1&listByType=platform – skaffman
Oui, malheureusement, la JSR-256 ne vous permet pas de prolonger avec vos propres capteurs. Vous êtes limité aux capteurs de votre appareil. Dans mon cas, j'ai besoin d'interfacer un réseau de capteurs qui ne fait pas partie d'un appareil mobile, ce qui n'est pas une option (sauf que JSR-256 est destiné à J2ME qui le supprime pour commencer). –
Des exemples de capteurs de température, d'humidité et de localisation (GPS) sont donnés aux pages 68-69 de la version 1.2 de la spécification JSR-256. – shadit