I am trying to write a program for Windows Phone 7.5/8. My concept is, The appa should automatically read the incoming SMS, extract the data and notify of important things to the user. Is it possible? Like, it should read the message containing the total balance from you bank and notify you when the total amount goes below certain limit. Is it feasible or possible in Windows Phone?
No. It is not currently possible to intercept an incoming SMS or read past messages in the public Windows Phone SDK.
Related
I created a module which imports daily usage of SMS csv files to laravel and analyzes it to track all the failed SMS recipient's phone number and then blacklists the phone number so as not to send SMS to the same number again. I checked this against success message like:
if($status != "Message accepted by phone carrier"){
//do blacklist and stuff
}
But I soon found out that one of the numbers that I frequently used for testing (and which is valid) also got blacklisted. The status was The recipient is currently unavailable something like this. There are other status messages such as Blocked as spam by phone carrier. It must mean that sometimes if a phone is switched off or out of network range for some time, AWS will mark it as failed. But I don't know what these status messages mean to make a concrete decision whether to blacklist the numbers or not.
Does anyone know all the (or at least important) status messages and what they mean? I searched the AWS forums but found nothing there.
I have a main application and 4 client applications, I communicate back to the main application using SendMessage.
I can use any three of the client apps without any problems but as soon as I add a forth I get access violations and stackoverflow errors.
My question: is there a maximum for the number of apps that can send using SendMessage to a single application?
I am using Delphi XE2 and Windows 8
My question is, is there a maximum for the number of apps that can send using SendMessage to a single application?
No there is not. Your problem is not related to the number of processes sending messages.
One likely explanation for an access violation when processing messages is that your message contains a pointer to memory that is only valid in the address space of the sending process. But that's a wild guess since we have no code.
I have a client company with a simple web app that users can interact with via a desktop/mobile website. Recently they asked to implement a notification functionality. The users, if they wish to, can sign up to real time notifications from the web app.
The really interesting requirements though is that the notificaitons should:
Be delivered in real time (60+ seconds delay is a failure);
Have guaranteed delivery, i.e. my client wants to be sure that each user gets all his/her notifications.
Be able to somehow notify the user from background, i.e. a typical user would not wait for a notification with a browser window open on his/her Android, for example. The preferred way is to make the phone ring and/or vibrate and put some messages into the notification area so that a user can notice a notification even if the phone lies in her pocket or a bag.
Notes:
a typical notification message is rather short, here is an example: "Hello! You have a meeting with $John today at $5pm";
all the users have smartphones (iPhone/Android) with 3G connection enabled.
Since the requirement 3 can not be met with the current state of modern mobile browsers, the only two ways to fully achieve the spec is to:
A. Make an app for iOS/Android and use the native APIs to make the
phone ring and vibrate upon notification receipt;
B. Use an IVR like
Asterisk to call the user via SIP, play a sound with notification and
ask him/her to press 1 to confirm the receipt of the notification
(the sound can be something like "You have a meeting with John today
at 5pm. Please press 1 to confirm").
But when I started to test those A and B options, I found that (1) and (2) can not be satisfied via a regular 3G connection (the company is in Europe and the connection is quite okay). For example, a Jabber client on an Android device can get some messages with a long delay (a few minutes) and even loose some messages.
So, the only option left to meet the requirements 1, 2 and 3 is to use B (automated IVR - Asterisk).
Is my reasoning correct? Are any other mechanisms to deliver short notifications to smartphone-enabled users in real time, with 100% guarantee and make the smartphones ring and/or vibrate upon notification? Should I try to use anything else instead of the automated IVR calls?
P.S. I do not consider the SMS technology in my research, since to my knowledge there is no guaranteed delivery of messages.
If all your users have smartphones, your choices are IVR, SMS, or push notifications. If the mobile phone network is unavailable, all bets are off for IVR and SMS, but iOS and Android users may receive push notifications over wifi. If the phone network is present but weak (as in, no 3G or LTE), IVR and SMS are about just as good - SMS may be slightly better, because a bad phone connection can turn your message into "Hello, you have an appointment with KRRRZZZZT today at [call drops]".
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
We run a remote system and would like the servers to be able to alert us to their status via SMS. Is it possible to setup our own SMS gateway (or our own GSM network) so we DO NOT have to pay for an SMS provider?
Is this possible? if so, please let us know what are the required hardwares and how we get started..
I'm sure this is possible, because when the operator A want to send an SMS to the operator B, it do not pay any cent to the operator B. also, there are ton of online services like: Atompark.com, clickatell, ...etc
please Note: we know how to build an sms gateway using Linux system, a Modem GSM and a valid SIM, but we are looking a way that we do not have to pay any cent for sending sms messages...
Here's How It Works
You >>> Forwarding Aggregator >>> SMS Aggregator >>> Mobile Operator >>> Mobile Company >>> Your Customer
3 Major Parties Are Involved in the Whole Process:
1. Mobile Operators: They Manage SMSC (Short Message Service Centers). AT&T, Sprint/NEXTEL, T-Mobile USA, U.S.Cellular and Verizon Wireless are few of the major mobile operators in the whole world. They have deep connections with all major mobile phone companies. Most of them have 800 to 950 telecommunication/mobile companies in their pannel. All of your messages came to them via SMS Aggregators and they forward them to reciever's Mobile Company which send it to receiver in the end.
Cost of becoming a Mobile Operator: Billion Dollar Business if not Trillion.
2. SMS Aggregators: mBlox, air2web and motricity are few of them. They have deep connections with Mobile operators.
Cost of becoming SMS Aggregator: in Millions
3. Forwarding Aggregators/SMS Gateways: Clickatell, Twilio and esendex and few others are providing SMS Gateway APIs and most of the developers are using Clickatell to integrate its SMS API with their app. They charge different rates for different countries (NO FIXED RATE FOR ALL COUNTRIES). It would cost you rougly around $600-$700 for 100,000 messages (internationally).
Cost of becoming Forwarding Aggregator: May be in Millions
Bottom Line:
I'm working on a FREE solution but till today there are no FREE reliable solution in the whole world to send Bulk Messages for FREE internationally. So stop wasting your time on searching for a FREE solution. You have to come up with a new technology in order to achive this.
Though there are many options to send Bulk messages within your country for FREE or by spending little money but you simply can't achieve this if you're planning to send messages internationally.
Aside from any operator provided email-to-sms system there is no "free" way to do this.
A want to send an SMS to the operator B, it do not pay any cent to the
operator B
This is balanced by the fact that B will not pay A for messages going in the other direction. Internationally they often do pay SMS interconnect fees.
... setup our own SMS gateway
Yes, but you need access to an SMSC on a GSM network to send the messages either directly or via a device with a SIM, thats what you pay for.
or our own GSM network
Not practically, no.
You can use a raspberry pi or Orange pi with a Dongle.Then we can use AT commands.
We can connect the dongle and check whether It is connecting as a right mode using this command.
sudo lsusb
Then we can use python code execute AT commands..
sending sms we can use this code
def sendsms(number,text):
ser.flushInput()
ser.flushOutput()
ser.write('AT+CMGF=1\r\n')
sleep(1)
ser.write(f'AT+CMGS="{number}"\r\n')
sleep(1)
ser.write(f'{text}')
sleep(1)
ser.write(ascii.ctrl('z'))
sleep(1)
ser.flushInput()
ser.flushOutput()
print f"Text: {text} \nhas been sent to: {number}"
read unread sms
def read_unread_sms():
ser.write('AT+CMGF=1\r\n')
sleep(2)
ser.write('AT+CMGL="ALL"\r\n')
sleep(5)
a = ser.readlines()
z=[]
y=[]
for x in a:
if x.startswith('+CMGL:'):
r=a.index(x)
t=r+1
z.append(r)
z.append(t)
for x in z:
y.append(a[x])
##Following line changed modem back to PDU mode
ser.write('AT+CMGF=0\r\n')
return y
we can use "logger" for if you want create a logger file for the sms gateway.If you want to send the unread message to api, we can use "request" module for that.
While there are no free ways to send proper text messages, you might be better off buying an GSM module for a server (usb in racks would not be ideal, but there should be proper hw expansion buses). You would query the module itself rather then relying on a 3rd party middle server to send those messages, saving a notable portion of money.
Though I have not realized this per se, I created this plan for sending text messages for a service of mine. It was by far the cheapest option.
I'm working on an application that sends and receives SMS messages to and from its users. (Don't worry - it's not spam - every user of the app expects to send and receive these messages).
One key aspect of the app... If a user sends a message to the app, the app then sends that message out to every person on that user's "team". So, the app will be sending a receiving a pretty significant number of messages (I'm hoping for a few thousand users, and 5,000-10,000 SMS messages per day).
I've been experimenting with a number of options:
SMS to email
Connecting a mobile phone to my server
Contracting an SMS gateway
Option 1 is great, since it's free, but it's unreliable (apparently mobile providers queue these messages after SMS messages they can charge for, so they're frequently received late or lost)
Option 2 is also cheap, but the mobile phone can't keep up with the number of messages I'll be sending. Also, the mobile phone provider will consider this volume of messages excessive.
Option 3 is perfect, except that SMS gateway providers charge PER MESSAGE (usually $0.02-$0.06 per), which creates an impossible scaling problem. (Reminds me of the old business adage... "Sure we're losing money on every transaction, but we'll make it up in volume...")
So, long story short - how on EARTH did Twitter pull this off? They've been doing a similar thing (allowing users to exchange SMS messages with the app) since the beginning. Even if they negotiated an INCREDIBLE discount (say, $0.001 per message), they'd be paying an ENORMOUS cost to send the hundreds of millions of messages they handle.
Does anyone have any idea how they did this?
After a bit of Googling, it looks like Twitter has simply been signing deals with cell phone companies in various countries. For example (Twitter blog post link spam incoming):
Australia: http://blog.twitter.com/2009/12/sms-tweets-for-telstra-australia.html
Indonesia: http://blog.twitter.com/2009/11/sms-for-axis-indonesia.html
New Zealand: http://blog.twitter.com/2009/05/hello-new-zealand.html
UK: http://blog.twitter.com/2009/03/full-sms-service-for-vodafone-uk.html
Some more details about SMS in general here.