BrewBit app

[emdubeu]

App in the Google play store. Nuf' said.

[ecotony]

I'm going to add, iOS too...

[bsvaniwarden]

What is the timeline for the iOS app?

[emdubeu]

Right after they create an android app.

[hebnern]

Yeah this is definitely on our to do list, but we don't have any timelines right now. Getting the rest of the Model-T's out and stabilizing the device and website are our main priority for now. If anyone has app develoent experience, we would love the help!

[SLOBrewer]

I have iOS app development experience. I haven't looked yet but what's the authorization mechanism for the online API? What are you using for the API itself? REST?

[hebnern]

The API authentication portion doesn't exist currently, so we are open to recommendations. The API itself will be REST.

[SLOBrewer]

Oh, is this all baked into the back end of the website so the ability to control the BrewBit isn't really exposed right now? Is the BrewBit hitting an API that just allows it to activate and then just pull data? What stops my BrewBit (or another piece of software) from posting bogus data to my fermentation session?

[hebnern]

Well no, there is authentication for the device, but I don't think we would use the same mechanism for authenticating an app. Device authentication works as follows:

• The device must have an 'authentication token' in order to perform any privileged operations like sending data or changing settings.
• When the device connects, it sends the device id and auth token
• The server will check these and return a response to the device.
• If authentication fails or the device doesn't have an auth token, it will start the activation process by requesting an activation token from the server.
• The user enters the activation token on the website.
• The website looks up the device for that activation token, and if it is not already associated with another account, it associates it with the current user's account, and sends an auth token to the device.

This allows us to make sure that we are talking to the right device, but I think we would want a different mechanism for app auth. We probably want to have the user log in with username/password and then use a session id to authenticate subsequent requests to the API.

[SLOBrewer]

Ah, that makes sense. I was confused by the phrasing of authentication token and thought you meant the authentication ID but now understand what you mean.

Why not follow that exact same model for authentication of apps? For example, I have a Smart TV and went to associate it with my Hulu account. The Hulu app on the smart TV contacted Hulu and got a authentication code. The app then told me to log in to www.hulu.com/activate and enter the code. That presumably tied the app on my smart TV to my account and Hulu provided an authentication token to the app.

That's almost exactly what you're doing as well for the device and so could do the same for any app. It would be pretty easy to implement and you could take all of the log in functionality out of the app and leave it in the website. Session state management is a mess and ends up with lots of edge cases to manage. It's also harder for you to scale in the long run.

[hebnern]

That's a great point. I guess I was just thinking it was different because that's how lots of apps seem to be implemented. I suppose the same model does work well for apps. Cool, one less thing to implement, haha!

[jhines18]

Hi, I don't know if I'm missing something, but I can't find the app in the google play store

[SLOBrewer]

You're not missing anything. It doesn't exist. This thread is talking about adding apps in the future. For now there's just the UI on the BrewBit and the dashboard on the website.

[jhines18]

Oh cool. Thanks. Well it's a great idea. Thanks

[dan_maslowski]

PM me. I have a number of connections in this arena and could help you get an app out in weeks.

[pdomenig]

I would really like to see an android app too.

Would be nice if this app could alarm me if a tempereature is too far off the setpoint.