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
Related
Stack: Nextjs, expressjs, socket.io, WebRTC
I'm trying to build a video chat, at the moment everything works fine only if the second user joins and agrees to use the camera and has one at all.
Otherwise, the connection is established, a chat is available between two users, but user 2 does not receive the video stream of user 1.
I put this code on github for more clarity and a better understanding of what is happening.
Very big cosmic thanks for help!
You are calling createOffer without the "legacy" offerToReceive* constraints. Without these, if the user creating the offer does not have a camera they will only negotiate audio and not attempt to negotiate video.
See https://webrtc.github.io/samples/src/content/peerconnection/pc1/ for a sample using those options.
I'm studying React Native right now, and I'm trying to figure out how to enable the reception of Push Notifications even when the app is closed, just as Facebook does.
I'm a web developer, so I'm not used to mobile apps' "Manifest" logic. Where should I start from?
Thank you!
It seems that since you are a web developer, mobile app is not yet familiar with you. Actually, setting up push notification will require a few more official steps (differently on iOS and Android), and after everything is set, the push notification will happen between Apple server (or Google server) and smartphone's OS (which is iOS or Android), so the push notifications will come to the phone no matter what (without knowing/caring your app is opened or closed ^^)
In the programming code of our app, we can do our logics when the notifications come based on 2 cases: users is using the app or app is not running (not running means users are not using your app, and it is either staying awake in the background or users have exited it completely - e.g. pressing Home button twice on iPhone, and swiping the app away)
Actually, If you want your app to stay awake in the background, you can add some settings to the "manifest"-like files (of course differently on iOS & Android). However, my experiences taught me that keeping the app awake will encourage the users to complain and delete our app (my previous app's user once complained about his iPhone's battery was consumed greatly because of my app ^^)
If you really want to keep your app awake, you can set it in the settings, then in the push notifications' data, you can include extra parameters, and finally in the function of receiving push-notifications in your app, you can do anything with those parameters!
In short, you may just need to config push-notification properly for your app, and Apple/Google will do the rest, either your app is running in background or totally closed, it will receive the notifications. Hope you can find a good solution based on my explanation. If there's still something unclear, feel free to post here some more details on your needs, thanks!
This is the library I'm using with my previous react-native project: (they also have tutorial there ^^)
https://github.com/zo0r/react-native-push-notification
ADDED EXPLANATION: (based on author's needs):
The goal is: the user will register/login in the app, and will subscribe to some future events.
=> whenever users open the app, data will be sent to Apple/Google server to get a token, and you will use this token together with user's subscribe data to send all to your own push-server (you can use PHP or node.js server or whatever)
When an event gets updated a notif. should be sent to all the users who are going to that event. So a notif. aimed to certain users only.
=> like the above answer, data will be sent every time users open app (or change settings, you can do it in your logic of the app, because data will be kept your own push-server, which means on that server, you can even see user list, and can aim to certain users - it depends on what data will be sent to the users from the smartphone, but users may refuse inputting too much information like name, age or email, but it's up to your service's need ^^)
By clicking on it, the app will open and a certain page of the app (pre-existing) will be shown.
=> by default, when an notif. is clicked, the app will be opened for sure, and here once again, you can add extra parameters to the notifications (which is the landing page you need, then in the function of you app, just go there - but it may get extra logics for this. Besides, when to push notification, and which data should be pushed etc. will be controlled by your own server)
It seems like the most complicated part will be the "sending to certain users" one!
=> I explained this already, but you're right, actually it's complicated, because you need to create your own server with lots of API and logics based on your needs, and it need a few more steps (complicated one because you need to register many things with Apple & Google, then adding their Certificates into your own server etc.)
Hopefully you will achieve it, I suggest you play around and truly understand how push-notifications work first (for both sides - your own server and your application) - Good luck, though ^^
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.
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 :)
I'm looking to implement Google Wallet for digital goods' subscription on my website.
I understand how it works with postback on start and cancellation.
I'm worried if cancellation postback fail contacting my server. As I have a rather large amount of subscriptions, checking manually would be bothersome so I was wondering if there is any way to check subscription state contacting google wallet servers (like Paypal API).
How do you manage failed cancelation postback ?
Thanks,
AFAIK, there is no API to "query" - it would be nice to have :) I recall asking a similar question back in one of Google's developer hangouts about "repurposing" some of the now deprecated Google Checkout API which did have "query apis".
I'd suggest you mitigate things by logging all notifications - aka "notification history". If you experience a processing error on your end, you'd still have access to the "raw data".
Of course this assumes 2 things, (1) Google will never fail sending you a postback, and (2) your server/s are always ready (if they're down, then they can't receive).
Unless I'm corrected by a Googler, I don't believe I've seen a "retry policy" - error on either end - e.g. in GCO API postbacks were resent until the merchant successfully "acknowledges" receipt of the postback. Until then, I think you're down to looking at Merchant Center (manual).
Hth...