I have a server(called A) running on a custom protocol built with Erlang. To reach A from another server(called B) written in java, I wrote a TCP client library(called C) speaking the protocol using the beautiful Netty library. However, I have another use case, Server A, should also be reach by client applications running on android. In library C, I have the protocol parsing abstraction built using Netty's netty-buffer.jar (4.1.15) and netty-common.jar (4.1.15) only. My question is, can I used that same abstraction in the android client code? Working with Netty's ByteBuff is far more lifesaving the Java's ByteBuffer. I know that android runs on the Dalvik VM which is different in some aspect from the normal java JVM .
The min supported android API is 16 (If it matters)
Yes, it's fine to use Netty in Android. Use ProGuard to make sure you only bring in the parts you need.
Android doesn't necessarily run on Dalvik anymore. There's also ART.
Related
I'm attempting to write a desktop application that connects to bluetooth smart / BLE devices, for example, Polar Heart monitor.
Is there a generally recognised way to do this, Java API or library?
This is for a desktop application not android. Everything I see online is year(s) out of date or specifically android. I would rather try to avoid writing some platform specific JNI shenanigans.
Thanks.
I've used NRJSerial in a desktop application (Linux based) with Java. It has native in it but I didn't have to deal with that directly. There are ways to read from the USB/Serial port in Java but I found this to be portable and easy.
A word of warning though - it's low level. I was dealing with a PulseOximeter that just dumped binary so it wasn't too bad. If you start to get into GATT and so on it will be a decent amount of work to handle that.
If you plan on using a linux based system you can use bluez5.
Bluez5 exposes interfaces in the DBus thus interaction with bluez can be done with the dbus bindings of your choice(C, python, C#Mono.. ). Using the dbus-api you'll be able to scan, connect, pair, notify, read/write, advertise and much more
You can find a description of the dbus api exposed by bluez here (I suggest looking at the adapter-api, device-api and gatt-api) : https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc
Before diving into the code you can play around with bluetoothctl (a tool that you can use for pairing, connecting, services discovery, gatt attributes reading & writing etc).
Also, you can find the source code of bluetoothctl here : https://git.kernel.org/cgit/bluetooth/bluez.git/tree/client/main.c
bluetoothctl was built using GLib GDBus (dbus bindings for Glib in C) and you will find code examples for pretty much everything you'd like to do with bluez.
I'm afraid the answer to my question is no, but I'm asking it anyway just in case.
What I would like to do is stream audio from a chrome browser to a server written in Java via WebRTC. My understanding is that to accomplish this I need a Java implementation of peerconnection. All I've found so far is the libjingle Java API for android but that hasn't been particularly useful for integrating into my server app (I'd prefer an actual Java implementation, not just a C++ wrapper).
If a library to do what I want really doesn't exist does anyone have any pointers for how I might approach actually implementing the WebRTC spec myself? When I look at such a large spec I don't really know where to start.
You can use IceLink. We (I helped develop it) wrote a Java implementation for it, as well as .NET and Objective C.
This is a complete Java WebRTC signal server written with Java i/o sockets. https://code.google.com/p/jfraggws/ Just make a project, include the .Java file and include rt.jar in the project. Next set the port on the Html 5 client and plug in your servers IP. You now have java webrtc.
I am having problems with the interconnection between two modules of my system, I hope you can help me.
My hardware is:
Desktop computer running Windows.
Linux server that runs a Java daemon.
I have a Java app that connects to the daemon and shares information properly, basically it is a TCP connection, but it creates objects to operate with the send, receive methods.
However, it is mandatory for other reasons to send and receive data from Matlab to the server, and viceversa.
I have never used Matlab for connections, so I was wondering if you know how can I connect these modules.
I have thought about including the Java code into Matlab, but I am doubting about its feasibility, as it uses very particular libraries.
I also thought about using tcpip Matlab Function, but I think it won't work.
Thank you for your help!
George.
Well, basically there's only three options:
Use tcpip - if the corresponding toolbox is available.
Use Java: This should be straightforward - you could either use the standard java environment to open sockets and perform the read/write operations or try to include your own java libraries.
Implement the connection in C/C++ and include it via mex - which seems to be the most inconvenient alternative.
Given that you seem to have working Java classes doing your work, option 2 seems to be the best approach, imho.
Including third party libraries in MATLAB usually can work pretty good.
For a start, see e.g.:
http://www.mathworks.de/de/help/matlab/matlab_external/bringing-java-classes-and-methods-into-matlab-workspace.html
I happened to work within alternative 2 using a third party library for object-based communication with some database-interface.
I'm trying to write a plugin for a Java Application. The plugin should be able to tell the Java Application that new events have been recognized (Observer Design Pattern, Polling ... thats not the point). The problem is that the events are tracked gestures coming from a Microsoft Kinect controller (I´m using C++ and the Microsoft Kinect SDK because I have to). So that means I have to communicate between the Java Application and my Kinect Application.
I thought of something like an adapter design pattern where the Java application is "including" the interface (c++ header file, dll etc.). First I thought of JNI but then I have to write a DLL that will be used on both application sides, right? Another thing I thought of was to provide the gesture data via a protocol like UDP (or something more lightweight?). The last thing I heard of was to write a COM+ assembly ... but to be honest my knowledge about COM+ is rather little.
JAVA APPLICATION << ----- ??? ----- >> KINECT APPLICATION
May be you should have a look at google's Protocol Buffers.
Since you are considering JNI.
I'd suggest you refer to this IBM tutorial.
JNI allows the java application to call c/c++ methods and vice-versa.
Also have a look at this
question, if you are calling java from c++.
I have found some examples such as here, here and here which recommend you either used a shared memory structure or else use sockets.
I think that in this case, letting your programs communicate through sockets would be the best idea since your applications will not be that tightly coupled, so you just need to expose an IP, a port and a set of commands.
According to this it seems possible to create a C++ server on the Kinect, but other than that I can't say much since I have never worked on Kinect related projects.
JNI (Java Native Interface) allows the java application to call c/c++
methods.
All this requires that we have a means of communicating (Integrating Java
with C++) between Java and C++. This is provided by the JNI (Java Native
Interface).
For a practical example of using the JNI and calling native methods from Java, see this InfoWorld article.
We need to use a Java library from C++ code. An idea that I had is that if we could build a C++ client for Java RMI (ideally using some framework or wizard), than we could run the Java lib as a separate server. This seem cleaner than trying to run Java VM within a C++ application.
Alternatively, if you have any other idea on how to use Java from C++, I'd be glad to hear. We work on Linux.
thanks a lot,
David
RMI is intimately linked with the JVM (and Java serialisation), so that isn't reasonable. Not unless the C++ client includes a JVM.
CORBA is the obvious platform-independent equivalent. It is a bit design-by-committee and is now considered very untrendy. WS-/JAX-WS is kind of the modern equivalent with lots of XML, but may be considered a bad attempt at CORBA. REST is an attempt at a lightweight WS-, but see Joel's Stackoverflow DevDay rant on claimed "simplicity".
You could go old school and just shove byte over TCP/IP (or pipes). Or if local, just exec the C++ program. Or use a native interface: JNI built into the JRE, or JNA a nicer layer over the top.
Don't bother with RMI. If you're willing to take the step of making the Java application a separate server, have your C++ client communicate via JMS (Java Messaging Service). ActiveMQ is a free JMS message broker implementation that provides embedded services as well as C++ client libraries. The JMS protocol is dead simple to use (at least from Java). Its probably not as flexible as doing REST, but it would likely be an easier implementation.
JNI was the intended solution to the problem of C/C++ to Java integration. It's not difficult.
Message Queues are better for larger grained interactions, or remote interactions where the message queue is accessible over the network.
CORBA and RMI were also intended to be network access mechanisms.
From your description you don't want that. You want to consume a Java library in C++, and to do that, you use JNI.
How to start the JVM and invoke a Java method, from C++ (JDK doc)