a general question about sending realtime messaging from a cloud server
to users with handsets.
I'm creating new ecommerce: ROSPO - Snap Commerce for Local Trades
( enjoy small video introduction: http://www.rosposhop.com )
Now, my problem is to find the BEST way to deliver Online Orders
(submitted by online buyer) to a seller with a cell phone in his hands.
Order delivery must be in REALTIME and with a "delivery receipt"
confirmation requirement (I need to know for sure if order arrived into
the seller mobile phone, so no beloved e-mails, sorry).
1. Push Notifications
A native app with some sort of push notification protocol for orders
notifications ?
by example using https://developer.android.com/google/gcm/index.html for
Android, something similar fo IoS, something similar for Microsoft Phone
OS, etc.) ?
2. SMS
pros:
- Old plain "delivey receipt" SMS text messages. They always reach
receivers also in area without 3G coverage...
- SMSs do not require any native app. any sort of cellphone is ok.
cons:
sending (and receiving) SMSs is expensive! Let consider text message orders could be many SMS's segments... (an order is usually 160 x N chars), with N = 2-8. And just sending a single SMS, with some gateway providers in Europe cost is between 0.03 to 0.07 EUR.
Any further suggestion ?
BTW, any good experience with SMS gateway providers like: Twillio.com /
Nexmo.com ? I used until now with success Italian Skebby.com, but I
possibly need the CHEAPEST&AFFORDABLE provider that act in worlwide
countries (ROSPO servers will be instantiated in any city all around the
world...)
thanks :-)
giorgio
I don't think any option is really able to provide reliable delivery receipt. SMS is unreliable in various countries, and device Push Notifications can be over-ridden on the local device but still look like they've been sent on your side.
That said SMS is the most general solution to the problem and will cover the most use cases. If you're going to go the Push Notification route though I guess that means you'll have an app on the user's device, in which case the most reliable way would be to have push notifications (or maybe give the user an option to have SMS aswell/instead?) which they then need to acknowledge receipt within the app. That way you're relying on their action to confirm acknowledge it rather than making assumptions based on delivery.
Update: Now there's Catapush: push notifications with sms fallback feature :)
Related
Hi I am currently using channel API for my project. My client is a signage player which receives data from app engine server only when user changes a media content. Appengine sends data to client only ones or twice a day. Do you think channel api is a over kill for this? what are some other alternatives?
Overall, I'd think not. How many clients will be connected?
Per https://cloud.google.com/appengine/docs/quotas?hl=en#Channel the free quota is 200 channel-hours/day, so if you have no more than 8 clients connected you'll be within the free quota -- no "overkill".
Even beyond that, per https://cloud.google.com/appengine/pricing , there's "no additional charge" beyond the computational resources keeping the channel open entails -- I don't have exact numbers but I don't think those resources would be "overkill" compared with alternatives such as reasonably frequent polling by the clients.
According to the Channel API documentation (https://cloud.google.com/appengine/features/#channel), "The Channel API creates a persistent connection between an application and its users, allowing the application to send real time messages without the use of polling.". IMHO, yours might not the best use case for it.
You may want to take a look into the TaskQueue API (https://cloud.google.com/appengine/features/#taskqueue) as an alternative of sending data from AppEngine to the client.
I have questions related pushing messages to a user.
Here is the use-case.
A user is walking inside a wifi enabled warehouse and we would like to use the glasses to send critical information and warnings about the components in that building which required the user to interact with the component(s).
We have used push notifications in android devices with ok results, but with a live hud I would like faster updates.
Basically we will send something like this to the user
{
"html": "<article>\n <section>\n <strong class=\"red\">ALERT </strong>13:10 device ABCD tolerance failure. \n </p>\n </section>\n</article>\n",
"notification": {
"level": "DEFAULT"
}
}
How quickly can we get the information to the device?
What is the update rate? If we see an alert from a machine can, how quickly can we refresh the user of its status.
Is there some type of flood protection that would cause us grief?
I assume native api will have more options, such as polling or some type of custom subscription service which we could use for faster updates than google's service. Is this correct?
Thanks
Nick
This is not something that is expected to be done with the Mirror API. The GDK is where you would want to do this and they are taking feature requests. You might want to add your use case to this thread:
https://code.google.com/p/google-glass-api/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Priority%20Owner%20Component%20Summary&groupby=&sort=&id=75
To answer some of your other questions:
1 - Mirror API card pushes happen within seconds
2 - Seconds
3 - You are currently limited to 1000 card pushes a day per developer account, so that would be shared across all your users
4 - Curently there is no supported way to do that
As a final thought, if you really want to do this without official support, you could watch this video which shows you how to run "normal" android apk's on Glass. It is a presentation from Google I/O 2013:
http://www.youtube.com/watch?v=OPethpwuYEk
I am wanting to setup a service that allows people to send a text to my server and have the server return results of their questions.
Let's say they send a text to my server saying "movies"
and it returns the results
"Boondock Saints"
"Avatar"
"Star Trek - Spock got lost again"
what is this called?
how much would something like this cost?
would you be able to point me to a company that already offers this service?
When you google "inbound sms gateway" or "virtual sms" a large number of companies offering such SMS numbers will show up, all of them quite expensive, about 100 EUR/month.
For example a few random ones:
http://www.mysmsaddress.com/
http://www.mobifi.com/
https://www.2-waysms.com/
http://www.lleida.net/en/
See also Can anyone recommend any good UK based SMS gateways for sending and receiving SMS using C#?
Every example for GAE Chats uses some kind of polling. However, if my GAE app holds a list of clients (in the datastore if necessary), perhaps I could avoid polling by sending a message to all these clients. How can I achieve this?
If you are talking about HTTP, the short answer is that GAE does not currently support it. What I think you are asking about is sometimes called BOSH. Once WebSockets become more widespread, they will be an excellent solution for this problem.
In the mean time you might want to look at XMPP. Using XMPP you can avoid polling. Google has announced a Channel API (yet to be released) which will basically give you the same features as websockets.
You've probably seen some chat room examples...
Since you just want to send a message to users on your datastore (Tip: the IMProperty is great to store such data), it's just a matter of directly sending the message:
from google.appengine.api import xmpp
# `destination` is a list of JIDS
# `message` is a normal unicode string
xmpp.send_message(destination, message)
You can find a great tutorial on using XMPP by Nick Johnson here
Note that you can now use the App Engine Channel API for this: http://code.google.com/appengine/docs/python/channel/
You can create a channel for a given client using:
channel.create_channel(client_id)
Then when you want to update that client, send a message:
channel.send_message(client_id, message)
Basically each client will get a persistent connection that you can push messages over.
I am developing a web app that will be hit frequently by mobile browsers. I am wondering if there is a way to get enough information from the browser request to lookup position data (triangulation or GPS) Not from the request directly, of course. A colleague suggested there some carriers supply a unique identifier in the request header that can be sent to a web service exposed by said provider that will return position data if the customer has enabled that. Can anyone point me in the right direction for this or any other method for gleaning position data, even very approximate. Obviously this is app candy, e.g. if the data is not available the app doesn't really care...
Or perhaps a web service by carrier that will provide triangulated data by IP?
Google has ClientLocation as part of their AJAX APIs. You'll need to load Google's AJAX API (requires an API key) and it'll try to resolve the user's location data for you.
I've got blackberry gps to javascript working OK in a GMaps mashup. Pretty simple, actually. http://www.saefern.org/tickets/test4.php -- help yrself to view source.
(I don't currently have a bb. A user emailed me with "... it seems to be polling every 15 seconds or so, so it keeps adding new locations ... ".)
I'm looking for javascript gps info on an iPhone equivalent. And Nokia, and ... .
Any information appreciated.
I have used this javascript library sucessfully:
http://code.google.com/p/geo-location-javascript/
The examples work great. The user will always be prompted to share their location--don't know a way to avoid that.
Use the source IP address to approximate a network location. No, you won't get latitude and longitude in an HTTP request from an iPhone. Not unless you write a 3rd party app and ask them to run it.
You might be better off just running a poll on your website.
I know that some providers in Japan have a tracking service for location of cellphones.
I also know that the information is not public. I think you need to have a very good reason before the provider gives that information free as it is in my opinion sensitive personal data. Of course they will give the information to police officers but not to the general public.