Open GoogleCodeExporter opened 8 years ago
Also see
http://stackoverflow.com/questions/16947528/how-to-find-out-if-a-user-actually-h
as-glass/16948197#16948197 which had a similar question, and a proposed answer
to do double opt-in as a way to mitigate the resource issue for now.
Original comment by Prison4...@gmail.com
on 13 Jun 2013 at 2:26
A workaround if I may:
Your post oauth flow shouldn't immediately post a welcome card, this causes the
issue as explained. Rather, it may be good DX to send user to a settings page
where your verification logic can exist and then they enable additional
settings specific to your glassware. A POST then fires of welcome card by "send
to glass".
An example implementation with the CNN glassware could be adding second opt a
"Send to Glass" submit on the http://cnn.currentnewsnotify.com page
Downsides? Too many steps..
Original comment by noble.ackerson
on 13 Jun 2013 at 4:29
All users have a timeline. By requesting those scopes, you're asking for access
to that abstract data.
If that activates a Glass device, their timeline is synchronized to that device.
If there was a way to detect if a timeline card had been observed, per issue
#61 - https://code.google.com/p/google-glass-api/issues/detail?id=61, would
that satisfy your need?
Original comment by mimm...@google.com
on 23 Jul 2013 at 12:12
I think it would go a long way, and would lead towards the best practice of the
double-opt-in method (where the second opt-in would be simply viewing the
card). I can see edge cases where the person might never see the card (Glass
gets the card later, by which time it is buried in other cards they might not
go through), so it breaks the "timely" guideline, and dealing with that well is
extra work on the Glassware side, but I think it is a reasonable trade-off.
Original comment by Prison4...@gmail.com
on 23 Jul 2013 at 12:18
Original issue reported on code.google.com by
azugal...@gmail.com
on 13 Jun 2013 at 3:21