I'm interested in how apps like WhatsApp implement this feature.
I've just read that it's bad practice to send the message directly from device to device, because someone can eventually get to the API key and send messages as my application.
What's the solution then? Having a server and making the devices only communicate with this server, so when I want to send a message to another device, it goes to the server and from server to that target device?
Also another question:
public void onMessageReceived(String from, Bundle data)
This is a method of the GcmListenerService. When is "from" different than the default senderID? Because I tried sending the message directly from one device to another and the "from" was still the default senderID that I got when I registered the app on the website.
Basically, you need a server to listen to upstream messages and broadcast then again to intended recipients.
You can find an article describing this here: http://javapapers.com/android/android-chat-with-google-gcm-xmpp/
The approach is pretty limited and not as flexible as having your own messaging server, but should be enough for a proof of concept.
Related
I'm new in Android BLE so my question may be uncorrect or naive in some way. If this is the case please explain me where I'm wrong and kindly show me the correct way to manage this scenario.
Scenario is the following: my Android app communicates with a BLE device sending commands and getting answers from device using BLE characteristics.
Sequence is:
Device wakes up the app (the onConnectionStateChange method is called)
My app writes a command in a characteristic (I call writeCharacteristic putting the command in value parameter).
Device sends back the answer to command to my app (the onCharacteristicChanged method is triggered and value parameter contains the answer)
After waking up the app, the device doesn't do anything until a command is sent via writeCharacteristic. The device accepts different commands.
All good so far, but recently I developed a second different app to communicate with same device.
When I run both apps on same Android phone, one app sends a command to the device and the response is received by both apps! Of course the app that didn't sent the command receives an unexpected answer and goes to an unexpected status.
Ok, knowing the problem I can modify both my apps to handle this situation, but the question is: Is this behavior normal when two apps in same device communicate with same BLE device?
Is there a way for an app to establish a communication channel with a BLE device to avoid sending answer to specific commands to any other app except the one that sent the request?
My guess is that writeCharacteristic and onNotificationChanged aren't the right functions for such kind of communication, but in this case which are the alternatives?
The Bluetooth standard itself doesn't define anything how multiple apps would behave if both have a GATT connection to the same device. In the standard there is just one "GATT client".
Now both iOS and Android have taken one step further in a way that might seem unintuitive. Instead of only allowing one app at a time to communicate, multiple apps can be connected over the same GATT client to a device. The OS "multiplexes" the communication from/to the apps. The behaviour is that responses to read and write requests can only be seen by the app that made the request. So if you do readCharacteristic only that app will get the onCharacteristicRead callback. Notifications however will be delivered to both apps to the onCharacteristicChanged callback, since it wouldn't make any sense to send the notification to only one.
When you say that the "response" to a write request is the notification, that's not correct in terms of GATT terminology. The response to a write request is always empty per specification (or an error). If your peripheral emits a notification, then in your case that might be the "answer" according to your own logic, but it's not a response or any way related to your write request per the GATT specification. That's why Android can't (and shouldn't) send the notification to only one device.
I suggest that you simply ignore notifications you are not expecting. If you want to associate an "answer" to a write request, you can change your protocol to include a transaction id in both packets so they can be matched.
When I write "app" above, I really mean BluetoothGatt objects. You can call connectGatt twice with the same remote device in the same app, which will behave the same as if you connected from two different apps.
I am trying to make an app that connect to the server.
The app is used by some devices.
If one of the devices upload something to the server, I would like other devices receive the notification about the server has something new.
My question is, how to check the server is change or not? How often we must check the server?
I wonder how the Online Messaging work, because someone send something, we receive the message ASAP
Is the concept can be use with my app?
Sounds like you want to take advantage of Google Could Messaging or GCM for short.
http://developer.android.com/guide/google/gcm/index.html
This could be a lightweight message telling the Android application that there is new data to be fetched from the server (for instance, a movie uploaded by a friend), or it could be a message containing up to 4kb of payload data (so apps like instant messaging can consume the message directly).
GCM is the standard for how your apps "talk" to your servers. Either for a message in it's entirety or just a message to go check the server because it's been updated.
Is it possible to open my mobile Java program with an SMS?
And I don't want this SMS to be stored in the inbox. I'm looking for the kind of "Control SMS" that banks use for their mobile applications. I want the same in my application: send SMS to the mobile, the mobile device shows a message on screen that will be opened by the program, and this SMS should not be saved in the inbox.
Are you sure that you're not mistaking push notifications/cloud to device messages for SMS's?
Push/C2D messages are similar to SMS's inasmuch as a central server sends a message out to devices and many apps then display a popup based on that message, but the implementation is completely different. If you're not mistaking the two, is there a reason you'd prefer to use SMS's that are handled differently than most instead of push/C2D messages?
Here's the documentation for Apple's Push Notification Service.
Here's Android's Cloud to Device Messaging documentation which serves the same purpose.
Have a look and see if that would serve your needs.
If you are looking for completely client side J2ME based solution for feature phones - then try push registry. It is available above MIDP2. I don't know the exact details but there you can define event and triggers which will be stored by phone OS and invoked automatically when particular type of event occurs.
SMS sending is separate issue but there are tools available for that definitely.
Is there a way to listen for incoming/outgoing email messages or access the inbox directly?
I read that since there is no default mail client in the Android SDK it is not possible unless the client used on the phone implements some custom mechanisms. Is this still the case?
Emails are not part of the Android OS so you cannot code a global Broadcast Receiver (like you would for incoming SMS). The obvious workaround is to code Broadcast Receivers for the top X most popular email clients on Android OS which do broadcast incoming emails.
K9 does give you the flexibility of registering Broadcast Receivers for incoming emails - see https://github.com/k9mail/k-9/wiki/Intents.
Gmail does not have any official / documented API for receiving info about incoming emails. But until a while back, you could make use of Content Observers for monitoring changes to Gmail. I believe this no longer works though.
I think the real issue here is privacy and security. Emails contain much more info compared to SMS. As a user, you really would not want an app ecosystem where third party apps can start monitoring your personal and professional emails.
I am configuring my J2ME app to get an event from the push registry on receipt of an SMS.
Would I be able to access the SMS message, before it reaches the inbox?
I have read that messages sent to port0 of the mobile go directly to native inbox and we can't access it. Is there any way of diverting or even sniffing these messages so as to perform an operation on them from within the J2ME app.
According to this discussion, it is not possible to receive a SMS on port 0 using a MIDlet before it enters the inbox. And while I am not familiar with the
Wireless Messaging API, various other posts seems to indicate that you cannot access the inbox either (I might be wrong on this).
What I think you could do instead is to open a serial connection to the modem part of the phone and listen for an UR code (Unsolicited Response, "events") indicating
that a new SMS is arrived, read it and if it matches your criteria delete it (from the inbox, you still have your copy) using AT commands.
See the AT+CNMA command (New Message Acknowledgement) and similar in the standard (most mobile phone AT commands are by the way specified in 27.007).
For the following I have no idea if if even makes sense/is possible. I only mention it for completeness.
As for processing the SMS before it arrives in the inbox I think the
only option (without it having being sent to a specific port that you listen for) is
SIM application toolkit (which can do a hell of a lot of things), although that is way outside the scope of J2ME and highly obscure and highly un-trivial. Only follow this route if you are really, really desperate.