Google Glass App for Rails

Google Glass is a relatively new technology that, although not many people have used it, has a lot of potential for mass adoption. Designing apps for Glass, known as Glassware, is actually not all that simple, though. For one, you need a pair of Glass, and Google isn’t just handing those out willy-nilly. Let’s assume that you have Glass, though. What does Glassware look like?

Not Your Traditional App

Glassware is not an application in the usual sense of the word, in that it doesn’t actually live on the device. Instead, Glassware is a web application that you authenticate and data is then pushed from the Glassware down to the authenticated pair of Glass. In its current form, Glass does support some data push in the form of subscriptions, but these APIs aren’t as robust as one would think, and the amount and kinds of information Glass can send back to Glassware is still pretty limited.

Additionally, instead of having apps that you launch on Glass, Google introduced the concept of timeline items, which act essentially like a news feed of the activity you’ve elected to receive from Glassware. The New York Times and Path are two major Glassware applications currently supported. Instead of launching one of these apps from a home screen as you would on a mobile device or tablet, these apps insert items into your timeline, which you can scroll through at your leisure. Timeline items can have various menu options, including custom options you can define yourself, but beyond that, there’s not really much to them.

Pick Your Stack

Since Glassware is essentially a glorified web app, you can technically build Glassware on top of any web stack you like. Google has quick start guides written in Go, Java, .NET, PHP, Python, and Ruby, but you’re not really limited to these techs if you don’t want to be. Since I’ve been focusing a fair amount of energy lately on building my Rails chops, I thought I would try to build a Glass app using the Ruby quick start guide. When I loaded it up, I noticed it was actually built on the Sinatra stack, not Rails.

“But I really want to use Rails!”, I thought to myself.

Well, that should be easy enough. Ruby’s ruby, after all! So, I started digging through the source code for the quick start, and soon noticed that Rails does a lot of stuff behind the scenes that doesn’t really translate into other libraries, like Sinatra. For those of you who don’t know, Sinatra is a DSL written in Ruby for creating web applications. Granted, Rails is also used for building web apps, so what’s the difference?

Sinatra vs. Rails

In all honesty, when I first started writing this blog post, I didn’t really know what the differences were. From experience, I was aware of the fact that Sinatra was about as bare bones as you could get in terms of web application frameworks. Rails, on the other hand, is an MVC framework with tons of boilerplate code built in (convention over configuration). So, I did some digging, and came across this great article comparing and contrasting the two, and discussing when one is more appropriate than the other.

TL;DR: Rails is great for larger, more complex web applications, whereas Sinatra is fantastic for smaller web apps or APIs.

Could you use Sinatra for a large web app? Of course! Just be prepared to do more configuration than you would with Rails. Could you use Rails to build a small web app or API? Absolutely (and one notable tech giant started by doing just that)!

And so I, too, chose to build this rather small Glassware application using Ruby on Rails. Thus, I needed to begin working to transition the provided Sinatra-based Google quick start to something that played nicer with Rails. I began as I do with all new Rails apps:

rails new glass-app -T

For those of you who don’t know, ‘-T’ tells Rails to skip Test::Unit files. There are two reasons you may want to do this: If you know you’re going to use a different testing framework than Minitest, or if you don’t plan on writing tests at all. While the Rails community at large would shun you for choosing the second option, that’s the one we’re going with for this post. After all of the setup, I opened the new application in Sublime, started my server in another Terminal tab, and checked out localhost just to be sure everything was set up properly. It was.

Designing the Application

Now, before we get too deep into code, let’s take a step back and figure out exactly what we are trying to do with this Glassware app. We know from Google’s documentation that all Glassware apps and requests to the Mirror API must be authenticated using OAuth 2.0. So, right there we know we’re going to have to handle OAuth. After the user is authenticated, we want to send them some basic text and insert that as an item in their timeline. For giggles, let’s make it so they can also have that timeline item read to them out loud. Finally, they should be able to delete the timeline item when they are done with it. There are two things about this final point I found interesting regarding the Mirror API:

  1. Timeline items are automatically removed from Glass after 7 days and from Google’s servers after 10 days if they are not updated
  2. You have to explicitly add a “Delete” menu items to a timeline item

These two points aside, adding the actual menu item is pretty trivial, so it won’t take long for us to do it. From a front end perspective, there are two aspects to consider. First, we have to consider the front end for our web application, where the user will go to authenticate our Glassware. Second, you can optionally send down HTML in your timeline item, which can effect what is displayed to the end user in their timeline.

Our web app front end will be very simple. We’ll give the user the ability to log in and log out. If the user is logged in, they can send some static text down to their Glass as a timeline item. This is, arguably, a pretty trivial example of how to use Glass, but this post is more about getting Glass up and running quickly with Rails and less about the Glass Mirror API.

Building the Front End

Let’s go ahead and get the easy stuff out of the way. We know we’re going to need a controller and a view to insert the timeline items. The actual insertion logic will be a POST request as a result of hitting a button, but we still need an index action to show the root page with the button if a user is logged in. Fire up Terminal and type

rails generate controller timeline index

This will create a controller named TimelineController with an empty index action. Let’s go ahead and route the index action as root. Open up config/routes.rb and add the following line below ‘get “timeline/index”‘:

root "timeline#index"

Your routes file should now look like this:
Figure 1. routes.rb
Go ahead and restart your Rails server so that the configuration changes get picked up, and then visit localhost:3000 again.

Figure 2. localhost:3000 After Updating routes.rb

Figure 2. localhost:3000 After Updating routes.rb

Alright, so not really the most exciting thing in the world, but we know things work. Better yet, this tells us exactly where to find the view file for the index action so that we can actually put in some of the HTML we need for our view.

We’re also going to use Bootstrap for the front end skinning. Since Rails installs the sass-rails gem by default, we’ll just augment that with a sassy bootstrap gem. Open up your Gemfile and add the following under the sass-rails gem:

gem 'bootstrap-sass'

From the command line, run

bundle install

to install the new gem. Then, open up /app/assets/stylesheets/application.css. Rename this file to application.css.scss so we can hook into all the sassy-ness we want, and add @import “bootstrap” to the bottom of the file. Go ahead and save it. Now we can use bootstrap throughout the entire application.

Let’s start with the navigation bar, which will have a link to the main page (“root_path”), as well as link to Log In and to Log Out, depending on the state of the current user. Add a file called “_navigation.html.erb” under /app/views/layouts, and fill it with the following HTML/Ruby:

</pre>
<header class="navbar"><nav class="navbar-inner">
<ul class="nav pull-left">
	<li><%= link_to 'Home', root_path %></li>
</ul>
<ul class="nav pull-right">
<ul class="nav pull-right"><% if current_user %></ul>
</ul>
<ul class="nav pull-right">
<ul class="nav pull-right">
	<li><%= link_to "Sign Out", signout_path, method: :delete %></li>
</ul>
</ul>
<ul class="nav pull-right">
<ul class="nav pull-right"><% else %></ul>
</ul>
<ul class="nav pull-right">
<ul class="nav pull-right">
	<li><%= link_to "Sign in with Google", "/auth/google_oauth2" %></li>
</ul>
</ul>
<ul class="nav pull-right"><% end %></ul>
</nav></header>
<pre>

Here, we’re using some new HTML5 tags (<header> and <nav>) and augmenting them with bootstrap classes. We’re also using embedded ruby (hence the .erb extension) to add anchor tags for the various links and to conditionally set the right side of the navigation bar depending on whether or not we have a current_user instance variable. Go ahead and restart your Rails server and then refresh the home page. Oh crap.

Figure 3. No variable current_user

Figure 3. No variable current_user

It looks like Rails is upset because it can’t find an instance variable called current_user.

Introducing a User model

We need a user. Think about it: When you authenticate the first time with our Glassware app, you expect to be remembered the next time you come back and request to have a timeline item inserted. If you sign out and sign back in, you don’t want to have to reauthenticate the Glassware app with Google again, either. This means we need some sort of persistence and a model object to persist through. A number of gems exist that handle user log in and OAuth, and we’ll get to those later on in this post, but first we need a model object to represent a user. Head back to Terminal and type:

rails generate model user email:string refresh_token:string

A user.rb file, as well as a create_users.rb migration file, should be created for you. Now we need to apply the migration.

rake db:migrate

Rake is just a build program. db:migrate tells Rake to look for all unapplied migration files and apply them in order. In our case, we only have one migration file, which has come code in it about how to create the Users table, which columns to add to it, and what the value types of those columns should be. Go ahead and open app/models/user.rb. Notice it’s completely empty, aside from the actual class definition. We know that Google OAuth requires an email address for the authentication. We also know (from reading the Google documentation on their authentication process) that a refresh token can be used to request a new access token without having to ask the user to reauthenticate. Currently, access tokens for Glassware are only good for about 2 hours, so it’s important to store the refresh token to enhance the user experience. As such, we should really ensure that a user has both an email address and a refresh token before we save them to the database. ActiveRecord provides a validation method (validates) and a method parameter (presence) to ensure that an attribute has a non-empty value before it gets saved to the database. So, add the code on line 2 to validate the presence of these two fields:

class User < ActiveRecord::Base
validates :email, :refresh_token, presence: true
end

Ahh, Rails makes things like this so simple! And this is great and all, but it doesn’t solve the problem we were seeing before when we tried to load up our home page. We still need to add a current_user instance variable. A popular gem for user authentication is Devise, but that’s overkill for what we need here. Instead, we can use a helper method in application_controller.rb to make an instance variable available to all of our controllers that are subclasses of ApplicationController. Open up app/controllers/application_controller.rb and use the helper_method method to add a current_user method. We’ll define the current_user method as a private method, but create a @current_user instance variable that can be accessed in our other controllers. Your ApplicationController should now look like this:

class ApplicationController < ActionController::Base
# Prevent CSRF attacks by raising an exception.
# For APIs, you may want to use :null_session instead.
protect_from_forgery with: :exception

helper_method :current_user

private
def current_user
@current_user ||= User.find(session[:user_id]) if session[:user_id]
end
end

Simple enough, right? We define a private method called current_user, which uses the conditional assignment operator to either assign or just return the current user by looking up the id of a user in the session hash. The session hash is managed by the Rails and is available for each user of your application. You can read more about the session hash here. Save this file and refresh your browser. BOOM!

Figure 5. Home Screen after adding current_user

Figure 4. Home Screen after adding current_user

Alright, still not incredibly impressive, but at least it works! Let’s add some code to index.html.erb to make it a little bit more interesting:


<% if flash[:notice] %>
 <div class="alert alert-success">
 <button type="button" class="close" data-dismiss="alert">&times;</button>
 <%= flash[:notice] %>
 </div>
<% elsif flash[:alert] %>
 <div class="alert alert-error">
 <button type="button" class="close" data-dismiss="alert">&times;</button>
 <%= flash[:alert] %>
 </div>
<% end %>

<% if current_user %>
 <%= link_to 'Send Offer', insert_offer_path, method: :post, class: "btn btn-primary" %>
<% end %>

Alright, so what did we do here? First, we check to see if their is a notice or alert inside the flash hash and, if so, display it with some bootstrap styling. You can read more about the flash hash here. Next, we check for a current_user and, if we have one, show them a button called “Send Message”, which performs an HTTP POST to this as-of-yet-undefined send_message_path. Now, refresh your browser. Hm; boring. Since we don’t have a current user, or any flash messages, we don’t actually see anything. That’s fine for now.

Go ahead and click on “Sign in with Google”. D’oh! “No route matches [GET] ‘/auth/google_oauth2′”. Well, isn’t that disappointing. Our Rails app is trying to match this route, but it can’t find it anywhere. Where does this route come from? Enter omniauth.

Get Authenticated

In its most simple form, OAuth is “an open protocol to allow secure authorization in a simple and standard method from web, mobile, and desktop applications”. History tells us that storing usernames and passwords isn’t really all that safe. So, an alternative method of authentication was created with the OAuth 1.0 standard. That standard has largely been deprecated in favor of OAuth 2.0, but the principle is the same. A user securely logs in to an OAuth provider with their username and password. In response to a successful log in, the provider passes back to the client an OAuth token, and that token is then used to make authenticated requests on behalf of the user. The user name and password are not stored by the provider, and the OAuth token generally has an expiration date set on it, upon which the client can either use a refresh token to request an updated OAuth token (like we will do), or the user is asked to reauthenticate. Writing your own OAuth implementation is cumbersome and error-prone. Calling OAuth a “standard” might be a stretch, since different people implement it differently. So, if you’re not aware of those differences for the different providers, you’ll spend a lot of time banging your head against a wall. Since I’m in no mood to put you through that (or myself, for that matter), we’re going to use a fantastic gem that handles all of the OAuth for us. Omniauth is a gem that handles multi-provider authentication for web applications. So, if you want to allow your users to authenticate with your app using Facebook, Twitter, Google, or any other OAuth provider, omniauth is a fantastic solution. It knows how to communicate with the various providers, pass along user credentials, parse responses, and return tokens. However, we already know we only need to authenticate with Google for our Glassware app, so we can use a gem that focuses solely on Google: omniauth-google-oauth2. In order to communicate with the Mirror API once we’re authenticated, we can use the google-api-client gem. Let’s go ahead and add both of these to our Gemfile:

# Google
gem 'google-api-client'
gem 'omniauth-google-oauth2', :git => 'https://github.com/zquestz/omniauth-google-oauth2.git'

Again, run ‘bundle install’ to install the gems.

Next, we need to create an API project in the Google API Console.

Awesome. We have a client ID and secret. Where do we store those in our Rails app? Well, there are a few places, but no matter what, you don’t want them committed to source control and publicly available for other people to see. A great option for storing sensitive data like this is a configuration file. We can use the figaro gem to handle most of the setup of this configuration file, and then just add key/value pairs for our ID and secret, which we can then reference throughout our application without directly using the values. Add the figaro gem to your Gemfile. Also, add the rest-client gem, which we’ll be using later on:


gem 'figaro'
gem 'rest-client'

And run ‘bundle install’. Next, run the installation command in Terminal to get figaro all set up:


rails generate figaro:install

You should notice two things. First, a file called application.yml was created in the config directory. Second, your .gitignore file was appended. The .gitignore file pretty much does what the file name says: it tells git which files to ignore and not manage under version control. What got appended to this file? Why, your application.yml file, of course! Open up the application.yml file and add the following two lines:


GLASS_CLIENT_ID: [__YOUR CLIENT ID__]
GLASS_CLIENT_SECRET: [__YOUR CLIENT SECRET__]

The client ID and secret don’t need to be surrounded in quotes — just paste them in as they appear in the Google API Console. Now, anywhere we want to use the client ID, we simply type

ENV[“GLASS_CLIENT_ID”]

And the value for the the key “GLASS_CLIENT_ID” will be inserted. The same holds true for the key “GLASS_CLIENT_SECRET”. Fantastic!

Now we need to setup the configuration file for omniauth. Checking the README for the omniauth-google-oauth2 gem gives us some guidance. Add the omniauth.rb file in config/initializers, and fill it with the code below:

Rails.application.config.middleware.use OmniAuth::Builder do
provider :google_oauth2, ENV["GLASS_CLIENT_ID"], ENV["GLASS_CLIENT_SECRET"], {
 access_type: 'offline',
 prompt: 'consent',
 scope: 'https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/glass.timeline',
 redirect_uri:'http://localhost:3000/auth/google_oauth2/callback'
 }
end

Ok, so let’s break this down a bit. As we learned before,

ENV["GLASS_CLIENT_ID"]

and

ENV["GLASS_CLIENT_SECRET"]

are environment variables. Remember when we added the client ID and client secret to the application.yml file? We can keep our ID and secret safe since the application.yml file doesn’t get checked into source control. Rails will use the figaro gem to look up the values for these two keys and replace them here. Next, we ask for ‘offline’ in the

access_type

so that Google will send us back a refresh token along with the OAuth token. This is going to be useful for refreshing the OAuth token without having to ask the user. Setting

prompt

to ‘consent’ means the user is re-prompted for authentication and/or consent. The

scope

key can be a little tricky. First we ask for

https://www.googleapis.com/auth/userinfo.email

This is mostly for the omniauth gem, but we can also use the response from this to store the user’s email. Next, we include the API endpoint for Glass timelines, so we can read and post to a user’s timeline. The redirect_uri key is the URL you set when you were setting up your Glass App Client ID and Client Secret. You can see a full list of other Glass-related scopes here.

We’re almost there! The last thing we need to do is write the method to perform the actual authentication and log in. For that, it’s best to create a new controller. We’ll call this the SessionsController, since it will be responsible for managing sessions. Back to Terminal!


rails generate controller Sessions create destroy

As before, this will create a new controller called SessionsController and fill it with empty implementations of the ‘create’ and ‘destroy’ actions. First we’ll add the code, then we’ll step through it:


class SessionsController < ApplicationController
 def create
 #What data comes back from OmniAuth?
 @auth = request.env["omniauth.auth"]

# See if we have a user with this email
 @user = User.find_by_email(@auth["info"]["email"])

if @user
 @user.refresh_token = @auth["credentials"]["refresh_token"]

@user.save
 else
 @user = User.create(email: @auth["info"]["email"], oauth_token: @auth["credentials"]["token"], refresh_token: @auth["credentials"]["refresh_token"])
 end

# Store the user in the session
 session[:user_id] = @user.id

redirect_to root_path
 end

def destroy
 session[:user_id] = nil

redirect_to root_url, :notice => "Signed out!"
 end

end

When we make an authentication request to Google, the user is asked to grant access to our application. Assuming they grant said access, omniauth takes care of handling the redirect and parsing the response. The part of the response we’re interested in is contained within the “omniauth.auth” hash, and so we stick that into an instance variable named “@auth”. Next, we try to find a user in our database using the “email” key contained within the “info” hash of the @auth hash (lots of hashes here). Email is an appropriately safe way of looking up a user, since a user’s Glass is tied to their Google account. If we have a user in the database already, we update their refresh token with the value from the @auth hash and save it. Otherwise, we create a new user with the email and refresh token from the hash. The ActiveRecord method “create” will automatically save the new model object as long as it’s valid. It’s a one-line approach to @user = User.new() … @user.save. We then store the user’s ID in the session hash so we can look up that user elsewhere, and simply redirect to the root path, since we don’t really have any other pages to show.

The “destroy” action is pretty self-explanatory. We simply clear out the user_id key from the session hash and then redirect back to the root path with a flash message notifying the user that they’ve been signed out. Nothing too crazy there.

The last piece of the puzzle is to update our routes.rb file. Insert these two lines above “root ‘timeline#index'” and delete the two get routes that Rails automatically created for us:


get "/auth/:provider/callback" => "sessions#create"
delete "/signout" => "sessions#destroy", as: :signout

Your whole routes.rb file should now look like this:


GlassApp::Application.routes.draw do
 get "/auth/:provider/callback" => "sessions#create"
 delete "/signout" => "sessions#destroy", as: :signout

root "timeline#index"

end

There is one more route we need to add: the send_message route. It will look similar to the /signout route we added before. Your routes file should now look like this:


GlassApp::Application.routes.draw do
 get "/auth/:provider/callback" => "sessions#create"
 delete "/signout" => "sessions#destroy", as: :signout
 post "/send_message" => "timeline#send_message", as: :send_message
root "timeline#index"

end

Restart the Rails server, and now try logging in. You should see this:

Figure 5. Google Authentication

Figure 5. Google Authentication

Alright! Go ahead and allow the app, and you should be redirected back to the home page with a fancy blue button on the page. Clicking on this button will obviously do nothing, since we’ve yet to define the send_message action in the TimelineController. Let’s do that now.

Sending Messages to Glass

Sending a message to Glass using the Mirror API is a relatively straight forward process, though I’ve found there’s a fair amount of code to be written in order to do it. The first thing we’ll need is the refresh_token and email from the current user. I decided to create a convenience class method on the User model to return a hash containing the credential information for a given user. Granted, our user only contains attributes for email and refresh_token right now, but it’s perfectly conceivable that you may want to add other attributes to your user model, but still only need these two attributes to insert a timeline item into Glass. Open up user.rb and add the following code under the validates method:


def self.get_credentials(user_id)
 user = User.find(user_id)

if user
 # Get the token and refresh as a hash
 hash = {email: user.email, refresh_token: user.refresh_token}
 end
 end

This method is pretty straight forward. Head back over to timeline_controller.rb and make your send_message action look like this:


def send_message
  credentials = User.get_credentials(session[:user_id])

  data = {
   :client_id => ENV["GLASS_CLIENT_ID"],
   :client_secret => ENV["GLASS_CLIENT_SECRET"],
   :refresh_token => credentials[:refresh_token],
   :grant_type => "refresh_token"
  }

  @response = ActiveSupport::JSON.decode(RestClient.post "https://accounts.google.com/o/oauth2/token", data)
  if @response["access_token"].present?
    credentials[:access_token] = @response["access_token"]

    @client = Google::APIClient.new
    hash = { :access_token => credentials[:access_token], :refresh_token => credentials[:refresh_token] }
    authorization = Signet::OAuth2::Client.new(hash)
    @client.authorization = authorization

    @mirror = @client.discovered_api('mirror', 'v1')

    insert_timeline_item( {
      text: 'Google Glass is awesome!',
      speakableText: "Glass can even read to me. Sweet!",
      notification: { level: 'DEFAULT' },
      menuItems: [
        { action: 'READ_ALOUD' },
        { action: 'DELETE' } ]
      })

    if (@result)
      redirect_to(root_path, :notice => "All Timelines inserted")
    else
      redirect_to(root_path, :alert => "Timelines failed to insert. Please try again.")
    end
  else
    Rails.logger.debug "No access token"
  end
end

Let’s step through this. First, we use the user_id in the sessions hash along with our new get_credentials method to get a credentials hash. We then create a new hash called “data” using the client ID and secret from our configuration file, the refresh token from our credentials hash, and set the grant_type to “refresh_token”. We’re going to use this as the JSON body for a POST request to refresh the user’s OAuth token using the refresh token we stored in our database. You can read more about exchanging the refresh_token for an OAuth token here. We then pass this data hash to RestClient and use ActiveSupport to decode the JSON that is returned into a “@response” instance variable. Next, we check if there is a value present for the “access_token” key and, if so, add it to our credentials hash. Otherwise, we just write out to the Rails logger that we couldn’t find an access token. Assuming we got an access token, we proceed to create a new Google API client and assign it to the @client instance variable. We then create a new hash, cleverly named “hash”, and give it the access token and refresh token from the credentials hash. We create an OAuth 2.0 client variable by passing in our hash. Signet::OAuth2::Client takes an options hash and two of the possible values are :access_token and :refresh_token, so we have passed those in with our hash. This then gets set as the OAuth 2.0 client that our Google API client needs.

Next, we create an “@mirror” instance variable for the Mirror API client. We then use the insert_timeline_item method to perform the actual timeline item insertion. To insert a timeline item, we POST a JSON representation of the item to the appropriate endpoint, which is set inside of the insert_timeline_item method. We pass in a few things via a hash for the actual timeline item.

First is the actual text we want displayed in our item. Second, we pass a different string for text that can be read out loud to the user. We set the notification level to ‘DEFAULT’ (currently the only option) so that the user’s glass will “DING” when a new notification from our app comes through. Finally, we define two menu items, both of which are standard menu items for Glass. Their purposes should be self-explanatory. You can read about other possible values to pass to this JSON representation here.

The return value of this method should be a “@result” instance variable if the insertion is successful. Depending on whether or not the insertion worked, we redirect back to the root path with an appropriate flash message. Next, we’ll define the insert_timeline_item method.

Giving credit where credit is due, the insert_timeline_item method is right out of the mirror-quickstart-ruby’s mirror_client.rb file. We’re not going to cover adding attachments to your timeline items, but this method contains the ability to do so. Your insert_timeline_item method should look like this:


def insert_timeline_item(timeline_item, attachment_path = nil, content_type = nil)
 method = @mirror.timeline.insert

# If a Hash was passed in, create an actual timeline item from it.
 if timeline_item.kind_of?(Hash)
 timeline_item = method.request_schema.new(timeline_item)
 end

if attachment_path && content_type
 media = Google::APIClient::UploadIO.new(attachment_path, content_type)
 parameters = { 'uploadType' => 'multipart' }
 else
 media = nil
 parameters = nil
 end

@result = @client.execute!(
 api_method: method,
 body_object: timeline_item,
 media: media,
 parameters: parameters
 ).data
 end

And that’s it! We’ve put into place all of the pieces we need to send some static text down to our Glass. Refresh your browser, click your button, and you should soon see a new timeline item inserted into your timeline. If you select the item, you should have an option to read the item aloud, or to delete it. And that’s all there is to it.

For your own reference (as well as mine at some point in the future), below are some resources I used scattered across the inter webs when building this app:

Google Glass Reference

Exchanging a refresh token for a new access token

Mirror Quickstart in Ruby

5 thoughts on “Google Glass App for Rails

  1. Thanks so much, very helpful. I had to do a few tweaks:

    1. “Google” was not identified when setting up @client var. I added “require ‘google/api_client'” to omniauth.rb
    2. Migration did not have the “oauth_token” so added that
    3. Was also getting bulk_assignment error for oauth_token, so made it ‘oauth_token” in user.rb
    4. _navigation partial was not included anywhere, included it in the application layout.

    • All great points!! I realized I left out the code for the navigation, but got side tracked with the holidays. I’ll get that in and make a few other updates. Thanks for the comment!

  2. Had all the same errors as Alok. After fixing them….the send_message method blows up with some encoding issue.

    SyntaxError (/app/vendor/bundle/ruby/2.0.0/gems/signet-0.2.4/lib/signet.rb:22: invalid multibyte escape:
    invalid multibyte escape:
    app/controllers/timeline_controller.rb:44:in `new’
    app/controllers/timeline_controller.rb:44:in `send_message’

  3. Can you narrow down a bit where in that method you’re getting that? Make sure you ‘data’ hash is being created properly, and see what the value of @response is after you make the POST call to oauth2/token.

    • It was an error with the google-api GEM. I changed the version and it fixed my issue. Yay! Thanks a lot for this tut. It rocked!!!

      This fixed it for me in the gemfile————–
      require ‘google/api_client’
      gem ‘google-api-client’, “~> 0.6.4”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s