Is there any kind of standard/widely used SMS format for Android/IPhone/Windows mobile/Symbian that enables to send/recieve GPS coordinates ('geo tagged SMS')?
E.g. Garmin has peer point SMS format, that enables to send/recieve POIs or just simple points. Garmin mobiles are able parse this format and geographic part of the SMS behaves as a link, so by clicking it it can be shown on map or save to user's POIs etc.
I tried to find a similar SMS format for other mobile operating systems (or a general one...), but I have not found yet. Do you have any suggestions?
If so, is there any library that can be used to construct this kind of SMSs in .net environment?
I am developing a GIS app under .net that can be connected to a GSM modem. My plan is to implement a feature to send POI points to mobiles from my app.
Nope I'm afraid not.
An SMS is just that, a simple message, unlike MMS or voice it carries no state information, no meta data the most it has is a user defined header (For binary messages) and various protocol data unit elements that describe things like the address of the SMS central receiving server and the message length, type and char set.
If you want to do location aware stuff using SMS, then you'll
a) need to have software running on the target device, that can interrogate a built in GPS or other location aware device.
b) can respond to an inbound SMS asking it to send an SMS back with said location information in.
unless you have a web based SMS service then this is going to get very expensive very fast as most operators will charge you (at least here in the UK anyway) 0.14p per single SMS text off a standard consumer sim card, where as many bulk operators (I use Cardboard fish) will only charge you around 0.05p per SMS.
To give you an idea of the difference that's 7 SMS messages in every UK £1 on a consumer account and 20 in every UK £1 on a bulk account.
Related
This seems like a topic that would be widely covered in the mobile digital age, but I haven't found much of anything.
What information comes with an SMS? Obviously the message text itself, and the number from which it was sent. Is there anything else included - GPS (long/lat) data perhaps? Device type? Carrier info? Does it vary by device and carrier?
I'm coming at this from the perspective of a web developer, where I can see calls to and responses from the server, which often include rich header data. I'm just curious what all could theoretically be similarly gleamed from an SMS.
This question was originally about SMS and MMS, but the two appear to be significantly different in operation
I'm just reading up on iBeacon, and I might want to use it for a project I'm currently involved in. What I currently understand from it is this:
Simply put, an iBeacon device broadcasts a message to whomever is
within range. This message includes the sender its mac-address, and
from the intensity of its signal, the receiver can calculate the
distance. iBeacon devices can either be senders, receivers, or both.
1) First of all; is this correct?
Secondly, on the wikipedia page I read that it could enable payments at the point of sale (POS). Because I understand that it is basically a very local broadcast service I'm just trying to understand how something like that would work.
2) So would in case of a payment, the store or the customer initiate the payment?
3) And how would you prevent that other nearby devices pick up the payment messages?
4) Lastly; is it possible to send an iBeacon message to only one iBeacon device identified by its mac address?
Any tips and insights are very welcome!
Enabling mobile payments is an example of something you could build on top of iBeacon technology. But iBeacons themselves are very simple building blocks that would only be a small piece of a solution. It is a common misconception to confuse what iBeacons do themselves with what can be done with iBeacons.
In the payment use case, the only function the iBeacon would perform would be to wake up the payment app and tell it the phone is near the point of sale. (With a specific numeric identifier for the point of sale.) That's it! That is all the iBeacon does. Everything else necessary would be built with other software.
There are lots of possible answers to your other questions about payment processing, but they are not specifically related to iBeacons. Typically, a mobile payment system will require entry of a PIN to confirm payment. So an app using iBeacons could simply display an option to pay to any device with the payment app that is a few feet of the point of sale.
In the simplest implementation, the phone would query the payment server with a message like "I am near POS terminal with iBeacon identifier #12345. How much is the payment?" And the server might respond with a message like "$23.95", which would be displayed on the screen of the phone. In this implementation, the user would verify the amount on the screen and enter a PIN to confirm. This confirmation would be the security mechanism ensuring that the wrong device does not pay for the wrong order. Other more sophisticated implementations are possible, but again they are not strictly related to iBeacons.
Two other clarifications:
While an iBeacon does transmit its Bluetooth Mac address, this is typically ignored. In fact, iOS blocks reading this Mac address, so it is useless on that platform. Instead, applications rely on a three part identifier specific to iBeacons: ProximityUUID, Major, Minor.
There is no way to make only a single device see an iBeacon. It is an open radio transmission visible by everything in its approx. 150 ft. range.
I'm trying to figure out if this is even possible:
I'm interested in writing a simple game that could be played in a peer-to-peer setup, rather than having to go through some intermediary server. I was thinking of using something similar to how SMS works, but I don't know if those routines are accessible.
From what I understand, SMS is just a data packet with a specific structure, and on a certain port, that gets sent to a phone number as the unique identifier, rather than an IP Address. If that is the case, is it possible to use similar routines to what SMS uses in order to send messages to another phone, but in such a way that SMS will not pick it up, and if the app that would understand that packet is not running, then the data would just get ignored?
You can write Apps that send SMS and receive SMS. Some things to keep in mind:
SMS tend to be expensive, especially when compared to IP traffic.
The user must grant the permission to send and read SMS to the app. He probably won't do, beacuse he knows it's expensive.
Even if the users contract offers a SMS flat rate, providers may limit the actual number of SMS being sent or forbid automated, high-traffic usage.
SMS might be much slower than IP packets.
If a user tries to play with someone who hasn't installed the App, that poor person will have his SMS inbox flooded with those SMS.
So it's mostly a bad idea to use SMS for that purpose. Some alternatives if the users are close enouth to each other:
Use bluetooth.
Use Wifi (Most android phones won't allow ad-hoc connections, but some phones can act as acces points so that others can connect to it).
Maybe: Use NFC (only some of the newest phones have this, and I don't know if you can use NFC that way).
Use P2P over internet (which requires at least one provider to allow incoming connections on their network with a public IP, e.g. no internal NAT).
Use a server that handles the traffic between phones.
I am new to android and I want to implement finding the location of another phone and displaying their location on my device using Google Maps while I am talking with that person.
Considering the fact that currently I'm not aware of a phone carrier company providing an API over the cellular network or a server to access other phones' locations, you'll have to implement the infrastructure yourself.
By that, I mean both the on-phone applications designed to transmit and receive location data and the means to communicate this data between phones, when a call is placed.
It would be easier at this point if you could programmatically embed metadata in the caller id information of calls you place from an Android phone, but unfortunately I don't think that such an API exists at the moment.
This leaves you with only two other options: have the application on the caller phone send the location data either through a server that you control, or through an SMS message to the number it's calling.
Using a server only works if both phones are connected to the Internet, so you must rely on data traffic to work for the location data to be transmitted.
Sending location data by SMS incurs some kind of cost for your user, as it either subtracts from the available number of SMS messages included in their carrier plan, or simply charges them extra if this plan is already over capacity.
You may offer a clear alternative, that the user should be informed about, to use one way or the other; depending on the application's scope and purpose, each of these alternatives may be suitable (I'm thinking of this feature only activating for some specific phone numbers, in case you'd use this app inside a company that deals in on-site interventions to some kind of emergencies, that require automatic location reportning at the time of certain calls from the field).
You have two options - both of them probably not so feasible:
1. Having an application running on the other phone which is designed to transmit the location to wherever needed.
2. Having the phone carrier company(s) providing you either an API over the cellular network or via their server an access to the other phone's location.
Good Luck
I am working on an application and one feature that would make it really useful is the ability to share some information, but the other device may not be expecting the data to be sent.
For example, if I am reading a really good book, and I realize that a friend may like it, I could use an application to send the data to him, so he could order the book from Amazon.
But, since he isn't expecting the data, I would hate for the application to be polling a server every so often, as that will be needlessly draining the battery.
Ideally it would be great if there was a way to make a phone call to the target device, send a data packet and end the call.
If it could be done and prevent the phone from ringing, then it would be very useful to me.
I am curious if there is some way to send data between devices without polling.
You can send them a message via facebook or email (e.g. here), or broadcast it with twitter.
These approaches - using an existing infrastructure for messaging - provide mechanisms for discovering your user's contacts / 'friends' and so on too.
Your can send and read SMS on phones if you have the correct permissions.
You could talk to Mashmobile who have a bigger platform that can do peer-to-peer between phones. You could imagine a hybrid that did both Mashmobile for Windows/Android/Symbian and Apple's push for iPhone users of your app.
On future phones, you could use C2DM (which is a application-specific messaging system overlay on gmail - the Android phone user has to have a Google account etc)