PAUL RASHIDI: Hello.
I'm Paul Rashidi, a Developer Programs Engineer
on the Google Cloud Platform.
I'm extremely passionate about Compute Engine and mobile apps.
So not too long ago, I started work
on some applications that use both.
I realize there are probably other developers out there
wanting to do something similar, so I recently open sourced
a sample app.
I'm going to show a demo of the app
and then briefly talk about the process of building it
in Android Studio.
The readme file included with the sample app on GitHub
explains how to deploy the app for yourself
so you can get it running on your own Android device.
First the demo.
The application is a simple one that utilizes the CE API Java
client library to retrieve project resource information.
It pulls information about all active resources
from a developer project you've previously registered.
As you can see, we start with the login page,
where you can choose a Google account.
We're going to select my sample account.
This account listing is pulled from the Google accounts
registered on the Android device,
to avoid requiring the user to re-enter their password.
Now that we've done that, the code asks Android for an OAuth
2.0 token for that account, with OAuth 2.0 scopes for Compute
Engine and Cloud storage.
I will accept this prompt, and now the application
is able to retrieve OAuth 2.0 access tokens.
As a reminder, an OAuth 2.0 access token
is a time-limited authorization string
that provides access to Compute Engine
and cloud storage APIs on behalf of a user.
Next, we type in a project ID for the developer project
that the Google account has access to.
This obviously needs to be a project that is already
using CE or at least has the API enabled.
This value can either be the project name string
or the project number, which we receive from the console.
We'll now click this View Resources button,
and a new activity is invoked.
The app talks with the CE API in the background
and loads the resource information.
We can see that we have a few instances and disks, as well
as the zones that our project has access to.
We can also see that this instance
has a scheduled outage coming up.
This is actually an instance I meant to delete earlier,
so we'll drill into this and delete it.
Again, the app performs a delete asynchronously with the CE API.
Pretty simple app.
For this app, we decided to use the Android master detail
sample.
So if you run the app on a tablet,
you'll notice it nicely combines the first and second activities
together.
This is Android fragments at work, but more about this
later.
Now let's look at the code.
In order to look at the code, we're
going to need to retrieve it.
That's easy enough.
We're going to check out the source code using Git,
and then import the project via the import option
in Android Studio.
We'll select the highest level project,
use the Gradle wrapper option and import.
If you're having trouble here, please see the readme
in the code repo for more comprehensive instructions.
Now that we have the code, the easiest way for us
to understand this project is to look at the code
as it was committed.
You can see the first few commits
are project wizard generated code and are mainly
defining entries in Git ignore.
The structure is a bit different from the Eclipse environment.
As you can see, we're excluding the build directory, as well as
the idea and Gradle hidden directories.
All these files should be inferred from the main
build Gradle file.
So there's no need to check them in.
We're also excluding the lib directory,
since we're pulling in our dependencies via Maven
vis a vis Gradle.
More on Gradle a little later.
For the project wizard commit, I used all the defaults,
except that I chose a minimum SDK of 11
so that I had Android fragments available.
This allowed me to use the master detail
sample as the basis of my app.
You don't have to choose version 11 if you're
creating your own app and don't want fragments.
But I like the simplicity of the tablet
interface we saw earlier.
The next commit is a doozy.
It contains the addition of the API interaction code
to the project.
All of our code that uses the CE API is here,
since we need to keep network calls off the user interface
thread.
You can see we basically instantiate an API stub,
create a command, then execute the command.
In the case of a delete command, we're
going to make an additional status call
and wait for it to complete.
In this commit, I also snuck in the addition
of a login activity.
It's the sample login activity that
can be created with a right click in Android studio,
like this.
Finally, you will notice a critical change
in the build.gradle file in this commit.
If you aren't familiar with Gradle,
then you could probably get away with the fact
that it's the new preferred way to define your builds.
This snippet is specifically pulling
in all of our dependencies by defining them
as Maven dependencies.
All of the Google client library for Android jars,
as well as the surface extension for Compute,
will be added to the project because of these lines.
The snippet does use Maven, but you're still
required to have downloaded some libraries via the SDK manager.
Read through the comments in the snippets
for the specific packages you need to have fully updated.
The next commit has us implementing the login activity
to use the Google account credential.
This is an Android aware credential
that will reuse Google accounts on the device
and allow applications OAuth 2.0 token access.
Finally, the last interesting commit
is the implementation of the resources list
to connect to the async tasks we checked in earlier.
In this commit, we adjusted the XML layout
files to display our resources and updated the list and detail
fragments to display our instances, disks, and zones.
That's about it for the code.
I'm really looking forward to seeing some applications
on mobile devices that use the Compute Engine API.
I appreciate your time and would ask
that you star our project on GitHub and/or
the video to indicate they were useful.
Thank you.