I heard that there are applications that allow people to do transactions by just touching there iPhones to each other. How is that archive via code in Objective C?
I beleive each phone has to detect the "bump" (using UIAccelermeter) and send an immediate notification of the event ot a server (perhaps with a timestamp and some geolocation info too?). Then the server matches up events that occur at the same moment, to determine the two devices involved. Then the server facilitates the transaction by sending each phone's info to the other.
take a look at the Bump API http://bu.mp/api.html as used in the Bump iPhone application. I haven't used it myself so I cannot say how easy it is to integrate but they claim it only requires you to add ten lines of code.
The way I would do it would be to have each device send the other their UID over bluetooth and then have them both send a message containing the other devices UID and their own UID to the server with a timestamp, then have the server handle the transaction.
Related
I am working on a product which requires a real time gps tracking.
I searched on google to collect information, so I got an overview on how does basically GPS work.
Now what else do I need except for a GPS receiver to display on my mobile through an app (designed by us) where a GPS receiver is attached to my product?
I don't want the whole navigation functionality, but just to display where it is located.
I know a GPS receiver continuously sends and receives signals from satellites, but how to display that on my mobile app?
Do we send some info to some kind to a database and then program the app to collect the info from there?
Basically, You need a kind of connection between your receiver and your phone. Since all the phones have their own gps receiver, I assume that you are gonna track the location of a remote device. So the easiest way to do that is creating a basic web service which holds just 2 pages in total.
1 to update data by receiver (I suggest you to use a hash key to prevent bots to piss your database)
1 to get data to mobile app
Depending on your background and project needs you can either use a database to keep location data or you can use just a file (like xml file or something like that)
Also you will need to parse NMEA code to get the actual data. It is easier to do that on web side (like in php). So you can just pass the NMEA code as it is to server, parse it, record it to database/file. Then you can fetch the data from your mobile app by using simple http requests.
If two devices will be close to each other you can easily use bluetooth but I don't know if there is any case that it make sense to place an additional gps receiver just next to a smart phone :)
First of all, you need some kind of communication channel to send location from your product to a server (1) of directly to the phone (2).
Usually GPS tracking devices use GSM modem with GPRS to connection to a remote server. Then your phone app can request location data from server via HTTP API. You can use open source GPS tracking server for your project and use some simple protocol to send location data to it.
Second popular option requires GSM modem again, but in this case device can send SMS messages directly to your phone. In your app you can intercept SMS and retrieve location data.
Is there a way how to get list of all devices connected to the Bluetooth peripheral?
I want to connect to iBeacon and check if another iPhone is connected to it.
No, two reasons why not:
iBeacons are not connected to the iOS device, iBeacons are broadcast only and no back communication exist from the phone to the beacon.
Knowing details of other BT 4.0 Centrals connected to a Peripheral are not in line with the the privacy features of Bluetooth 4.0. iOS and other Centrals are are using resolvable private addresses, in order to avoid situation like you are describing.
#barbazoo is correct that you cannot do exactly what you are asking because iBeacons only transmit data -- they have no idea what devices see them.
You can accomplish something similar, however, if you have an app running on each of the iOS devices you mention, and you have a server where you can build a web service. The web service would expose two methods:
reportIBeaconVisible(iBeaconProximityUUID, iBeaconMajor, iBeaconMinor, myPhoneAdvertisingId)
queryVisiblePhones(iBeaconProximityUUID, iBeaconMajor, iBeaconMinor)
The app would report each iBeacon it sees using the first method, passing the iBeacon's identifiers, along with the phone's advertising identifier to the server.
The app could then use the second method to ask the server what other phones have seen the exact same iBeacon, which would return a list of phone advertising identifiers.
You'd have to have logic on the phone to only report data to the server at a reasonable frequency. You'd also need code on the server to automatically delete phone records in the list if the phones haven't reported seeing a beacon in a certain time interval.
I'm currently in the early stages of designing a cross-platform mobile app (iOS, Android, WP8). At its core, the application will allow proximity based interaction between an unknown number of client devices.
Could someone recommend a framework or technology that would allow me to push server generated location based proximity alerts to the clients that even scales well? Could push notifications (cross platform using PushSharp) be a viable option for this, or will Push notifications always go hand in hand with some kind of toast notification on the device?
Update: 30 seconds or even a minute delay should do.
Push Notifications have way to much latency to give you anything near real-time. Also Push Notifications are not guaranteed to reach a device.
You really need to think about how much time constrained the location updates should be. You should also make some tests with how fast the GPS on various devices updates. I have tested on a Nexus 4 and it is not near real-time either. So throughout your entire application whether it is server side or client side you will have things blowing your real-time wishes.
However IF you can live with a delay of a couple of seconds to maybe 30 seconds or more, Push Notifications my work well for you, they also scales quite nicely.
EDIT:
Push notifications always go hand in hand with some kind of toast
notification on the device?
There is a concept called RAW notifications, which allow you to send arbitrary information with the Notifications. However personally I would just notify the client about updates ready on a server, where it then can get all the information the application needs. This is because as I said Push Notifications are not guaranteed to ever reach the device, but also because you are limited to how much information you can embed in the Notifications.
So my suggestion for a flow would be:
Client A updates its location and sends it to a web service
Web Service receives info from Client A and prepares notifications for all the other Clients, which need information about Client A and pushes information about they need to update their info.
Client B receives a Push Notification telling it to refresh data from the Web Service and does that.
That would work well if the application is in a background state. When showing in the foreground I would simply poll a server every second or so; Still receiving Notifications just forcing the client to update.
For the "scales well" part, you might also want to take a look at Windows Azure Service Bus Notification Hubs. It's currently in preview and supports only Windows 8 Store apps and iOS but support for Android and Windows Phone is on the way.
I am not a professional developer but I want to develop one project that includes sending message through mobile connected through USB port only... And if possible I want to keep it generalized, like no need for handset model and service provider name.
I don't think it's possible to do this. Certainly at the very least it would depend on the model of mobile in use.
However as an alternative approach there are companies that provide a (paid for, but not expensive) SMS service accessible via a web API. This may suit what you are trying to achieve.
I don't think you will find this easy. Messages can be sent in 2 different modes 'text' or PDU. Support for both modes is not universal across all phones. PDU is the most widely available type on modern phones, but is also the most complex. Not all mobile phones expose a modem to the computer eg. Windows mobile 6.*. Many phones use proprietory software that does not support all commands. Different phones will connect to different COM ports so this will need checking every time, and could prove tricky if there is more than one phone/modem connected. However using just one phone and sending messages in text format after configuring the settings manually the first time is very easy.
See an example here http://www.codeproject.com/Articles/34360/vb-net-AT-commands-to-send-SMS
How to get the phone number of the device in Symbian?
According to the GSM specs, only the IMSI is required to be available on the SIM card.
The actual phone number MSISDN is stored on the HLR database in the operator's network and does not need to be available on the SIM card or transmitted to the phone.
So no matter what technology you are using (Symbina, Java ...) you can never count on being able to consistently get your own phone number from the device or SIM. You might be lucky if the operator stores it on the SIM or if the phone provides the user with a possibility to enter it manually, but it does not have to be this way.
As Pat has said, although there are APIs for accessing the "own number" slot on the SIM, rarely in my experience is this slot filled.
The usual strategy for obtaining the phone number for a connected application is to send an SMS as part of a verification process. Either:
Programatically send an SMS from the handset to your server (lots of good SMS gateway interconnect providers out there). The SMS will arrive at your server 'from' the number of the handset (or the SIM to be more correct). Of course the SMS should contain some token so the server can link it with a given session/user.
This has the advantage that you don't need the user to enter their own phone number (which is fraut with subtle difficulties given few folks understand how to format numbers in E.164 format). One disadvantage is that the process can cost your user money (one SMS).
Have the user enter their phone number (web site or on the handset) and connect to your server, passing that phone number. Have the handset then wait for an SMS to arrive that you send from your server. If this SMS does indeed arrive, you have verified the phone number they entered as correct and valid. Obvious disadvantage is that this relies on the user to enter their number correctly - again, given the plethora of ways of writing phone numbers around the world, its not as trivial as it sounds to normalise numbers to E.164....
Alas, neither of these methods are bullet-proof, particularly because SMS is an unconnected transport. Depending on GSM network load, the load of your gateway provider, phase of the moon and direction of window blowing an SMS can take a second to a month to arrive (yes, I do have experience of the latter). The mean delivery time is often in the seconds, but you do have to play with the operation timeout and might have to tweak it on a geographical and GSM network basis.
[And no, don't rely on delivery reports - even more unreliable than SMS delivery]
FYI: Actually i have found this.
http://www3.symbian.com/faq.nsf/AllByDate/100335073FFD8FEF80256E3200571A49?OpenDocument
But the fact is, the phone number is not always stored in SIM. The operator chooses to do it or not!
You can't. Afaik.
Check this discussion:
http://discussion.forum.nokia.com/forum/showthread.php?t=65117
It is not generally possible to get the MSISDN from a Symbian device (or BREW, or any other platform). We've tried.