|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 5 of 6
Though small, the API includes some subtle design details, namely use of the Singleton pattern. Considering only one active
device is enabled at a time, invoking the org.scavino.jtwain.jtwain class methods through the getInstance() static method as prescribed in the Singleton pattern seemed appropriate.
Note: If you change the package structure, for example, renaming the org.scavino package to fit your corporate standards, you must regenerate the JNI header class using the javah compiler. Also, make sure to use the fully qualified class name as a parameter
to javah so the entire package name generates in the resulting C header file. JNI is string-based, and changing the package
structure name without regenerating the JNI headers will give you an UnsatisfiedLinkError exception.
I have included a test client in the source code for your viewing pleasure. JTwacker first checks for Twain's existence with a call to isTwainAvailble(). As the library is a Singleton, the native DLL loads during the first method call. You should see an initialization message
stating such in your output window. The application fills the combo box with the String array result from the getAvailableSources() call. The first call will be the slowest because the Twain library loads during this time. The user now has a list of available
devices. Note this great trick of the trade: You don't need to install an actual Twain device to see things work. The folks
at http://www.twain.org have provided the Twain community with a sample Twain source. Download the Twain Developer Toolkit from that site and you
can test right away. This allows the entire development team to unit-test the code and acquire images without sharing the
sometimes expensive hardware device from machine to machine.
Finally, we call the acquire (String sourceName), and the name of the resulting JPEG file returns. I merely display the BufferedImage in a JPanel (see the source code). You can do more.
I hope you'll appreciate this architecture's value. Knowing how all the image pieces fit together and mitigating the greatest risks first leads to quality software. While the desire to quickly cobble together code after a night of Red Bull is seductive, the long-term costs of poorly architected software far out weighs the short-run gains of making something compile. This architecture provides a set of blueprints that ensures you build the best API for the right people, with the best setup requirements for the appropriate budget, and on time. Specifically, I have outsourced all the tricky bits to existing libraries that do one task but do that task well. This way, we have a best-of-breed solution and the ability to change out subsystems if better solutions surface along the way. In effect, I am describing a component-driven architecture, which proves the whole can be greater than the parts. On the surface, Twain, EZTwain, JNI, and the Intel JPEG Library might not have much in common, but putting these parts together builds a rather useful subsystem.