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.
Related
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.
Is it possible to transfer SMS's from a Java based phone (either generic Java ME or Nokia Series 40) over GPRS - i.e. effectively to run an SMS gateway, without a PC?
I am aware that:
this is not possible through just MIDP, since MIDlets cannot access the SMS inbox directly.
Gammu is a possibility, and in fact I currently use it. However, this permits connection to a computer via Bluetooth or data cable, but not via an internet or GPRS interface (naturally, since AT commands presumably cannot be sent that way). Hence, to get to a server on the Internet, you need a PC.
SMS gateways exist for Android and Blackberry but not for these "featurephones."
From my research it appears that this task is not possible. However, I just want to check if I'm missing something.
It's been a while I programmed midp devices, but have you seen Nokia SMS Api?
http://developer.nokia.com/Develop/Java/Documentation/Java_API_specifications.xhtml#sms
I think it should be possible to read SMS in midlet, but permissions apply, and depending on the phone and/or midlet signature the resulting application would ask each time the sms is to be read (as far as I remember). Therefore you wouldn't get automatic relay as Gammu.
Edit: Have you seen this:
Receive text message using J2ME
I would like to manage a connection between 2 applications, they will run on diffrent phones.
The purpose doesn't really matters let's say that it would be some kind of a chat.
How can I create this connection between the applications? I know how to do it on pc java programs using the socket and the serverSocket classes but I guess it's diffrent in here since the phone might change his ip when he moves between networks.
So how would you do that? how would you create a connection between 2 applications/phones
Given the scenario you described in your comment, using Push Notification i.e Google Cloud Messaging (GCM) might be sufficient.
So, when program B wants update from program A, it will ask the server to push a notification (via GCM) to program A. Note that program A will not connect to the server every x time to check for updates.
Another out-of-the-box solution is to use SMS if the communication is not so frequent and messages are short. Here I mean SMS that will be processed directly by your app (given it has certain attention word) and will not go to the inbox i.e. no SMS notification on the phone
Since the two phones will, as you note, have changing IP addresses, you'll probably need to use an intermediary.
The general design pattern here would be to have a server with a fixed IP or DNS address that relays messages between your two mobile devices. The simplest implementation would be a webserver, to which each phone would connect via HTTP(S) to transmit data or poll for updates.
There are a number of backend-as-a-service platforms that provide this type of functionality pre-built, and would likely suffice for something like a chat system. Check out Cloudmine and Parse.
If you need a low-latency or near-realtime connection, you could also consider implementing your own server that uses the Android C2DM (Cloud to Device Messaging) service.
See Android's Sample Bluetooth Chat App, It will give you an idea for how it can be achieved.
I am writing an Android application that needs to communicate via sms. So for example application will send a message "Hi" to number 123, when number 123 receives the message it will be parsed on their phone by my application and acted on if it was determined to have been sent by my app.
Now I have the sending and receiving/parsing of messages working perfectly but I need a way to identify that the message was sent by my app. I could easily semd the message as "appName:hi" and check to see if the body contains 'appName' but the problem is if the user who receives my message doesn't have my app I would prefer if they just saw "Hi". So I was wondering if theres a way for example to send invisible characters or set some other identifying information either in the sms body or as part of the sms itself ie header. I would like to avoid data sms if possible and my app is intended to be offline.
Any ideas how I could accomplish this?
You can specify port when sending SMS. I do not know how to do this with Android API but since this feature has being supported for years by J2ME Android must support it too.
Your application should listen to this port and send to the same port. So, if user already has your application I think he even will not see the message in his inbox. At least this was the behavior in J2ME. If however he does not have the application yet he will either see it in inbox or will not see it at all. Check this with android. As far as I remember in J2ME it depends on the phone model.
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.