I am using Java Communications API. Want to know that is it compulsory to set CSCA (Service Center Address) using the AT command: AT+CSCA= for sending sms through java application? Or we can just skip that part and send the AT Command AT+CMGS= to send the message? Any help would be appreciated. Thanks!
Presumably your sending via a hardware device with a SIM card; that card will most likely come configured with a profile that specifies the home networks service centre number - after all you don't have to enter one yourself when you acquire a SIM for your own phone.
You can test for one with +CSCA?.
It’s been a while since I messed around with GSM but I think you only need to configure the service center if you intend to send messages in text format. When using binary PDUs the SMSC number needs to be specified for each SMS you send.
I've written an example for sending sms with AT commands some time ago on my blog. It's in C# but the AT commands should stay the same, have a look at http://www.softwarepassion.com/your-personal-sms-gateway-with-c/
Related
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 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.
I’ve built an app for a client that basically sends a standard pre written SMS to the client of my client’s phone asking for them to get in contact. Now the client would like to be able to send a pre recorded voice message to an answering service with the touch of a button, can this be done, firstly from an Android phone.
I’m guessing it can be done because when I search for an answer all I can find are apps that someone else has written that do just that.
Sometimes development tutorials can be hard to find when it comes to apps as you just get a long list of people trying to sell their apps…lol.
Does anyone know of such a tutorial?r
This is not an answer but maybe could help
I once wrote an application like that for a particular answering service for a particular provider in my country. To leave a message on their device I was basically required to compose an e-mail with a message recorded as an mp3 file and included as an attachment to the mail. I then send such mail to a specific mail address of their answering service. I had to supply credentials for the mail to be accepted. Such credentials (login/password) I obtained first by sending a specific port SMS to their service.
For composing mails with attachment I used an opensource IMAP client for Android (as a jar library added to my project). Don't rememeber which client it was but can find out.
I guess there's no common standard for that but basically all the answering services should do something similar.
Sorry if this info is too vague, I was just given the protocol of how that particular answering service was working and implemented accordingly.
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.