How can I handle incoming asynchronous messages using Android's USB Host - java

I'm going to be connected to a device which will send JSON messages asynchronously and would like my connection to the device to be open and waiting for those messages so that I can process them.
I've already completed the following steps:
Requested proper permissions
Found and connected to device
Claimed the interface
Once I have the device connection object and the endpoint objects how to I wait asynchronously for input messages?
It seems like UsbRequest sends data to the device to request data back, but the device I'm connected to will be sending data regardless of whether I request it or not

Related

How does whatsapp instantly receive a message?

I'm trying to make a communication between my App and the server side. The app needs to receive messages from the server because it's remotely controlled. It works as a Background Service.
I'm currently getting the messages from the external MySQL by using HTTPPost, doing requisitions every 20 seconds, but it spends much battery.
I tried doing a Socket connection to a server (build in java): device connects to the server every 20 seconds and close the conn when it just receive the data, but it also spends much battery.
Is there a way of receiving these messages instantly as Whatsapp does?
If the app is open it's most likely a socket connection. This is usually how messengers work.
In the background though it's most probably using push notifications (Check FCM - Firebase Cloud Messaging). This source of info can be unreliable so making a service with requests once a minute or two could be cool
In our messenger, we use long-live HttpsURLConnection as the main channel. The connection is hosted in Service and it is run in separate thread. In case of disconnect, we try to establish a new one. And we stop the service after our application is inactive for 2 minutes.
As the second channel, we use FCM.
This is what concerns messages. We also use WebRTC for multimedia data transfer. And we are going to use SIP calls to init voice- and video- call.

Delay when closing Tyrus WebSocket Sessions

I'm building a service with Tyrus in Standalone Mode (Grizzly Server) where I send huge amounts of binary data via WS to a client. In my setup, the service is located behind a proxy server, so all data that is send, is first buffered at the proxy and after the proxy in the unix send buffer.
At a certain point in this transfer, I want to serverside close the connection. When i do so, the client gets the onClose event as soon as all the data waiting in the buffer and proxy is sent.
This behavior, where all messages are handled sequentiell and therefore the close message is the last one recieved by the client, is understandable.
But what I need is a way to close the WebSocket connection in realtime. Like the underlying TCP connection would close and therefor the client won't ever get the remaining data stored in the send buffer and proxy.
Does anyone got an idea how to create such an behavior with the Tyrus API?

How to config push notification on my own server?

For Some reasons , GCM is not my target !
i'm trying to push notification from my server to android application , do i need use Sockets ? , when we use sockets , user is always communicating to server but i am just looking for this :
"server aware user for notifications , user request notification from server" no more data transfer or "keep-alive" connection
If GCM is not your target, then go for TCP Sockets
Create persistent TCP Connection from device to Server.
Design custom protocol for notification subscription and un-subscription. And Push messages to the respective devices.
Points to Note:
Your application won't be able to maintain persistent TCP connection
when device is in power saver mode.

Let a connection to server be open all the time

I am working on SMS application for a company, that sends SMS messages (SUBMIT_SM command) and receives the response from the SMSC (SUBMIT_SM_RESP command) to indicates if it is delivered to the customer. I am using JSMPP API.
What is the best practice to connect to the SMSC server? Should I open one connection (one session) and use it through the whole application to send SMS messages (any memory leakage here)? Or should I connect/disconnect to/from the SMSC server every time I send SMS message (any delays here)?
Note that, we are sending about 1000-2000 SMS messages per hour. Also I noticed that JSMPP API receives the response message (SUBMIT_SM_RESP) only when the connection is open.
That depends on the connection implementation. If your connection won't "die" during a long break than use one connection as it will save you time openeing/closing per request.
If your application is multi-threaded (where more than one thread can send a message) I advice you to implement a connection pool mechanism (or use an available one which supports SMSC sessions).

web server sending command to a J2ME app

Can a J2ME app be triggered by a message from a remote web server. I want to perform a task at the client mobile phone as soon as the J2ME app running on it receives this message.
I have read of HTTP connection, however what I understand about it is a client based protocol and the server will only reply to client requests.
Any idea if there is any protocol where the server can send a command to the client without client initiating any request?. How about Socket/Stream based(TCP) or UDP interfaces?.
If the mobile device doesnt allow you to make TCP connections, and you are limited to HTTP requests, then you're looking at implementing "long polling".
One POST a http request and the web-server will wait as long time as possible (before things time out) to answer. If something arrives while the connection is idling it can receive it directly, if something arrives between long-polling requests it is queued until a request comes in.
If you can make TCP connections, then just set up a connection and let it stay idle. I have icq and irc applications that essentially just sit there waiting for the server to send it something.
You should see PushRegistry feature where you can send out an SMS to a specific number have the application started when the phone receives that SMS and then make the required HTTP connection or whatever. However, the downside of it is that you might have to sign the application to have it working on devices and you also need an SMS aggregator like SMSLib or Kannel
You can open socket connection and implement "Hide" (or "Minimize") functionality in your app. Call this to hide:
Display.getDisplay(MyMIDlet.instance).setCurrent(null);
Listen to the server in a loop, and if you receive some message, popup the applicaion by calling this from canvas:
Display.getDisplay(MyMIDlet.instance).setCurrent(this);
But it dosen't work on all devices.
Socket push are supported by j2me. But it could work only if your server could deliver data to your mobile phone. Most likely that operator gateway don't allow to do this.
Maybe it would be possible if your mobile has static external IP address - some operators could provide this for $$.

Categories