Send Identifiable SMS - java

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.

Related

GCM device to device messaging - how is it done?

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.

How to privately send a message that is used by nothing but my app?

I have this app that sends encrypted text messages to the specified phone number. When a message is received, it shows up in my app but also in any other SMS app I have installed. I want to disable the global notification of the received text message.
What I am trying to do is send an encrypted message as a regular text message and send the key to decrypt it as a private message that is not displayed in the chat log. My app should have some kind of notifier to know which incoming message is the key and which is the encrypted text.
I read about using a localbroadcastmanager but I had no luck getting that to work with my code setup. I also was not sure if the manager would be able to send messages to other phone numbers.
I can post code snippest if necessary, but I don't see a reason for that.
Thanks for your time and any help guys.
UPDATE: I have found some posts about using ports so that only my app will listen for messages coming in from the specified port and no other app will see the messages on that port. I have implemented a quick program to send a message to a port I chose, but the message still shows up in all messaging apps. Do ports do what I think they'll do? Am I just doing something wrong?

Check File in the server is change or not

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.

Open my mobile Java program with SMS, no SMS in inbox

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.

sms receive on Port 0 of mobile

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.

Categories

Resources