I am talking about components that can be externally attached to a computer system via some port or other means, not about any of the component that is part of or peripheral of computer itself.
Actually, working on a college project for controlling traffic lights and boom barrier at railway crossing. I've got knowledge in Java but I do not know how can I get the traffic lights and boom barrier working on events in a Swing based application?
One thing is I can create a electronic circuit which can read the small output voltages at computer ports such as a USB port and used them as a trigger for controlling the devices. But how can I generate that small voltages using Java application?
Is JavaPOS can be the solution? or something else?
Any ideas? Suggestions? Articles? Samples?
I'd work backwards from the external device. Answer this 1st: What's the easiest way to communicate with it? If you say USB, ok, use usb. Then ask, what's the easiest way to interface with USB. Then build in whatever language you find to be easiest this USB interface. Finally, call from your Java swing application to this USB-wrapping application... it could be that simple invoke the app using something like ProcessBuilder.
In other words, I think it might be a mistake to solve the problem of interfacing to something like this device with Java, unless it's easy to do so directly.
Have you considered communicating with these external devices by sending digital signals to a serial port using Java? It's then a simple matter of either using those digital signals directly, or using an Analog-to-digital converter to get a voltage of desirable magnitude.
Same for input from the serial port. The RXTX library can help you do this (communicate with the serial port).
On the other hand, if you have access to MATLAB, then this sort of stuff is a piece of cake. Take a look at the Data Acquisition Toolbox and Instrument Control Toolbox.
I think your looking at this the wrong way. Most lights are them selves computer controlled. The lights are running on a computer system. If your project is to write this start to end, then you need to write a loaded to the light controller that does many things, one controls light color and direction, also allow connections via an out side computer. This connection could be USB, Ethernet ext. Now write a program facilitating connecting to the lights and pass commands to the light controller.
Related
I'm writing an application that needs access to a serial port (it's a credit card reader). I'd like to be able to read and write to the port. The following seems like it would let me do exactly that: http://www.activexperts.com/serial-port-component/howto/html/. However, this deals with ActiveX/COM which means I'm tied to Windows.
Any better solutions for me? Would be nice if the solution would work on multiple platforms, not just Windows.
I'm using PHP.
Does the device emulate a keyboard? You'd be much better off getting the user to position the cursor inside a textbox (or putting the cursor there programmatically) and swiping the card if that's the case.
I spent a lot of time writing a userspace driver in C for a Magtek Mini-Mag card reader only to realize years later that it was academic more than anything. I mean we used the code, only if we'd have gone with the keyboard solution there would have been tons of time to focus on other things.
For the Mini-Mag the USB/HID support in the kernel would recognize the device, hopefully there's something similar for the device you're getting.
Also, Windows has it's own variant of USB/HID so the 'treat it as a keyboard' solution works pretty much out of the box for devices that act that way.
this is the first time I´m posting something here.
I´m working on a Project where I want to control the Windows Media Player through different Input Modalities (like Multitouch, a 3D Mouse...). At the moment I´m trying to find a way to control the Windows Media Player remotely.
Write now I´m stuck on controlling the Player through a Java Program using the Jacob Library. It seems to be connecting to the WMP, but it does not execute my controls (Play in this case).
Does anybody have any experience with controlling the WMP remotely? My preferred language would be Java, do you know about an alternative/better way than using Jacob for the COM Bridge? Or do you know about a different approach, with which it would be easier to control the WMP?
I have to keep in mind, that i will need to be able to read out the input from the different devices and make the device work with the control of the WMP.
I hope somebody can help me!
thank you so much in advance!
You will probably need to take a look at the Windows Media Player SDK and in order to controll it remotely you may have to implement a small client server application which does the remote control job for you.
The goal is to use Processing as a scripting environment for creating graphics and to have the output display on a custom display device that is something like an LED light panel. The server running the program will be on a 1U rack. The idea is all the LED stuff is custom hardware, but rather than reinvent the wheel, it would be better to use an existing stack to drive the display. The problem is getting java to display on this device.
My initial thoughts are:
1. Run Java in headless mode.
2. Use Xvbf as the framebuffer.
3. Have a program run that reads the framebuffer, unpacks it, and then displays it on the remote device, at 30 fps.
4. Use Processing scripts to generate the graphics.
Does this make sense? Is there a better way? I'm not that knowledgeable about this area, but it seems better than trying to create a new java.awt.
I routinely use JFreeChart in headless mode with VNC to generate charts in servlets using ChartUtilities. It seems like you could just download the pictures to a picture frame via USB.
Another proposed option is to use Processing's createGraphics() and write the result to a file. I don't know about the tradeoffs of this option. It doesn't support OPENGL. And I'm concerned that the write will be a synchronous operation so calculations can't be going on during the write, which would make it difficult to get a high frame rate I would think.
If the "remote device" is just something directly attached by USB or some PCI controller, this seems sound (and exactly the sort of thing xvfb is made for). But if the remote device is something connected by ethernet or wifi, depending on it's resolution you might find the naive approach of copying all the data each frame requires too much bandwidth and before you know it you'll be rolling your own frame-differencing image compression. If you find yourself going down that route look at the VNC/TightVNC class of software which (at least in the form it's normally used on headless servers) provides an Xvfb-like virtual framebuffer/X-server accessible by a TCP/IP protocol which can transmit the content reasonably efficiently using compression and display it with VNC client software.
Hello I want write my own desktop sharing application in Java.
The application should have some very default features:
Capture screen;
Allow a remote connected user to click / edit fields.
I was thinking to use Java Robot class for mouse movements / key pressing.
The problem is i don't know what screen capture strategy to use.
Should I make sequentially screen captures (on the hosting computer) every second, and send those captures with UDP via network, so that the clients can intercept the data-grams ? Isn't this a little overkill for the network ?
What other strategies are available ? (Except trying an already existing app).
PS: If necessary I can even write native code using JNI (still that's the last thing I planning to do).
Later edit:
After some investigation I've come to the conclusion of #Thorbjørn Ravn Andersen . Java is probably not the best choice for this kind of application. I can try to use JNI, but that code will cover 75%+ of my project.
I will try to find other alternatives.
Have a good long look at the Ultra VNC project on SourceForge. Great place to start.
In pure Java you cannot access structured information on system windows, nor monitor all relevant system events, so the performance of the display synchronization will not be optimal. Also there are privileged windows, which do not accept mouse or key events from Robot. Remote video streaming is not an option!
With named restrictions your attempt with the Robot class is valid.
Robot.createScreenCapture(Rectangle) will put a Desktop section into a BufferedImage, which you can send to the client window.
On client side you can capture keyboard and mouse events and send them to a Robot object on the server side.
Without knowing the actual extent of system windows, it will makes sense to work on a grid of Desktop tiles:
captured BufferedImage-s of tiles may fit into the buffer of the transfer protocol.
capturing period may locally be optimized for tiles with high entropy (-> Capturing Strategy).
Further traffic minimization
Consider differences of subsequent Desktop contents, only
Compression of tiles by PNG or a PCX-like method
For sharing over internet, Peer-to-Peer connection may be established by
a public proxy server
UDP hole punching with, for connection establishing, a necessarily public mediator server
In any case the protocol needs to be secured and delivery asserted.
is it possible to create java application that will
work as background process on symbian smartphones?
You can approximate it but J2ME (the version of java on mobile phones) may not be the right technology to do this.
starting a MIDlet (a Java application for mobile phones) when the phone is switched on is tricky at best without coding a small Symbian OS C++ module that will start it for you. If you want to try anyway, look at the PushRegistry class in the MIDP specs
(http://java.sun.com/javame/reference/apis/jsr118/). The Content Handling API might provide some way to do it too (http://java.sun.com/javame/reference/apis/jsr211). When you are ready to give up, do it in C++.
Backgrounding a MIDlet isn't hard. The phone's "menu" key will do it for you. Programatically, Canvas.setCurrent(null) has a good chance of working. Trying to trick the phone by providing a fully transparent GUI and not handling any keypad activity will absolutely not work. Creating and starting a separate Thread in the MIDlet should allow you to keep something running even after your overload of MIDlet.pauseApp() has been called by the application management system.
The real issue is that the MIDlet will not have any Inter Process Communication system unless you make one. The usual way of doing that is a loopback socket connection over which you transfer data. Not a nice or efficient way of simulating IPC. Sharing a RMS record can only be done from within the same MIDlet suite (you can package several MIDlets into the same .jar file), I think. The code to create a provider/consumer data flow over a file connection is even uglier and will raise security issues.
Without any more information about what you want to use it for, my answer is : maybe but you should probably not try.
You will have in-built MIDP support for background MIDlets in MIDP 3.0 (http://jcp.org/en/jsr/detail?id=271). Don't hold your breath for devices to appear, however - might be some time.
(Note that a few Symbian OS devices have more than just MIDP - the S-E p990 for instance, https://developer.sonyericsson.com/site/global/products/phonegallery/p990/p_p990.jsp).
As already pointed out, it might be helpful to have more information on what product functionality you are trying to implement - often more than one way to skin a cat.