In a previous post, I alluded to a larger project I was working on in the physical/electronics/maker world, and now after much development, I'm pleased to present iZac, the Android Bartender!
A while ago I was inspired by Drink Making Unit 2.0 by Evil Mad Scientist Labs, and decided I wanted to build my own barbot. In this post I'll go over the high level details of what I did and why I did it.
One problem with any drink-dispensing machine is the difficulty of sourcing parts for interacting with food liquids. Pumps are expensive or impractical, valves are likewise problematic and difficult to obtain. My original intention was to use syringe pumps - effectively a DC motor hooked up to a threaded rod that pushes a syringe plunger in and out - and that was the reason behind my making the motor driver shield I wrote about previously. Unfortunately, syringe pumps turned out to be too fiddly and unreliable to use for the barbot, so I had to look for an alternate solution.
I ended up using a similar approach to that used by the DMU2.0, employing a battery powered aquarium pump to pressurize the ...
As I mentioned in my earlier post about the keynote, one of the exciting new releases at I/O is the new Push messaging API for Android. With it, you can push notifications from any webapp to an Android device in real-time - no polling, no messy hacks.
Push messaging is particularly valuable on the Android, because of battery life concerns. Even a single app polling every 5 minutes can cause a substantial drain on the battery - mostly wasted on checking for changes that don't exist. Several Android APIs already use push for sync - including Contacts, CAlendar, and the GMail app. Implementing it yourself, and getting it right, is tough, though - and that's where the new API comes in.
Under the hood, this is implemented as a background service. It starts whenever the network is available, and maintains a connection with the server for new messages. In order to prevent NATs and other network hardware from destroying the connection, and to detect that if it happens, it uses heartbeat messages - but it's been extensively tested and optimized to minimise the frequency of these as much as possible.
To use it, an app on the Android device registers with ...
It's day 2 at I/O!
The keynote was packed with Android stuff today - see the official blog post for the awesome details.
One in particular stands out for App Engine users: the new Cloud to Device messaging service. This makes it possible for an app in the cloud to send an Intent directly to an Android device, asynchronously. That means that you can send a notification to an android device, and have the device receive it immediately: no polling, no hacks.
Obviously, App Engine is a shoo-in for the cloud portion of this. Previously, I blogged about authenticating against App Engine from your Android app - look out for a blog post soon on how to do the reverse, and send notifications from your App Engine app back to your Android device.
The keynote's over, but there's still plenty of new App Engine content to come in the talks today. I'll be writing up short posts on the new APIs and features during the day.
I won't get to everything - I can only be in one talk at a time, and I have Office Hours to staff as well - but I'll attempt to cover ...
Many an Android app requires a server backend of some sort, and what better choice than App Engine? It's free, reliable, and does everything you're likely to need in a backend. It has one other major advantage, too: It supports Google Account authentication, and nearly all Android users will already have a Google Account.
So given that we want a backend for our app, and given that we want to have user authentication, how do we go about this? We could prompt the user for their credentials, but that seems less than ideal: the Android device already has their credentials, and users may not trust us with them. Is there a way we can leverage an Android API to take care of authentication? It turns out there is.
Authentication with App Engine, regardless of where you're doing it, is a three-stage process:
- Obtain an authentication token. This can be done with ClientLogin for installed apps, for example, or with AuthSub for a webapp. When logging in directly to an application, this is the part of the login process where your user sees a Google signin screen.
- Take that authentication token, and use it to obtain an authentication ...