We had a long discussion with Mr. Bulldog, resulting in the following:
Packages refactoring
Modularity in my own taste of order. :-) Well, I refactored those packages a bit - I think I did a good job naming them, or do you find a module/packagename misleading? I can then explain it to you. The only choice I regret is putting things in the gpio package that don't belong there (e.g. AnalogInput.java or even the Pin class!). A lot of people think a GPIO is the pin that you can touch, the outlet of a signal. That is plainly wrong and when I realized it, it was too late. GPIO is just a feature of a pin. This term is often used loosely and often times wrong on the web. This specific thing should be refactored or else real electrical engineers will face palm. Pi4j has the same problem, btw.
Overall architecture
Libbulldog was intended as an easy to use API for makers and tinkerers - thus the naive approach with the board as an entry point to get everything. Due to this target audience, I also broke with the concept of providers (like pi4j does for example). I thought that for the average tinkerer, in contrast to the skilled programmer, such wordings would only add complexity. The concept of pin features was born as I thought about the problem domain. A pin by itself is nothing but a connector on a PCB. It can be connected to various features and thus I concluded it would be wrong to implement features directly into a Pin class. So I created it as a container which can be connected to a "feature". This abstraction is still not 100% correct, however, because there are features that can be used which have not really a PIN as an outlet (yes, of course, there are lines on the pcb but they are not intended to be accessible).
By now I think the correct abstraction would be to have a feature, configure it and then eventually map it to a possible outlet (e.g. a pin).
Also, find attached the revised architecture that Robert Savage, me and a few others had worked out after long discussions. We had plans for Android support, a daemon for server usage, transparent networking (like EJB/.NET Remoting), and, of course, support for many platforms (Banana Pi, Hummingboard, all the Cubies and the Intel Galileos).
{quote}
sbunciak
commented
8 years ago
We had a long discussion with Mr. Bulldog, resulting in the following:
Packages refactoring
Overall architecture