Build It Bigger Project

This project required building an app that diversifies through multiple flavors (paid and free)  and connects to multiple libraries and endpoints:

• A Java library that provides jokes
• A Google Cloud Endpoints (GCE) project that serves those jokes
• An Android Library containing an activity for displaying jokes

The app should fetch a joke from the GCE module and pass it on to the Android Library to display it on screen and in the end be subjected to a few Instrumentation tests.

A question that immediately sprung to mind, was why do we have to go through the extra intermediate step of the GCE and not just have our Android library call into our Java joke providing library?.I raised  this question in the forums and here follows the dialogue I had with the forum's mentors:

Forum mentor
it’s just a design choice, and it aims at verifying if the student grokked everything on how to implement an Android Library, a Java Library and how to link them in a project where a GCE is needed.

Nikos
So if I could draw a diagram of the flow, would it be:

App(click button)–>GCE–>Java joke library–>GCE–>Android library

Forum mentor
Yes, exaclty.I’d change the last link between GCE and Android Library with:

GCE -> App -> Android Library

because I’d open the Activity implemented in the Android Library only after receiving the joke from the GCE.

Nikos
And how does the local GCE server have access to or calls into my local joke library?

Forum mentor
The GCE backend module will include the Java library in its build, so it will be able to create an instance of your class and pull the jokes from it.

Nikos
OK, this makes sense. And what about the last step of:

GCE -> App -> Android Library

how does the GCE call into my App? Or is it just my App calling the GCE endpoint and retrieving the response (the joke) of the GCE ?

Forum mentor
The GCE backend is simply a server, it serves up jokes.We talk to the server from our app, and it returns a response to us. We do this via AsyncTask. We deploy it and then it’s just like connecting to any other API.

When we receive the result in our AsyncTask we then launch the Activity from our Android library. Does that make sense?

Nikos
It does. So we are talking about two distinct components here. A, the App; and B, the GCE Server which also includes the Java library. The GCE server could very well be remote and that’s why we can’t hold any internal references from component A to B and back, adhering to a modular design. Is that the notion?

forum mentor
That is exactly correct. The server is remote, even if we run it on our local machine; instead of deploying it we still have to dial into it and connect with an AsyncTask. It is a completely self-contained module and does not require the Android framework to run. We connect to that backend server from our app and get a response from it. A better diagram might be like this:

GCE Backend Server <--AsyncTask--> App

There is two-way communication happening here.

This cleared up the requirements and once more highlighted the reliance one can have on the Udacity forums. Unlike StackOverflow, you always get an answer and that answer always makes sense.

So the project structure I've followed was:

• 'app'          the main/launcher/container app
• 'backend'  the GCE implementation
• 'jokelib'     the joke generator Java library
• 'showlib    the Android library the shows the generated joke

Locating the missing dependency

The first incident involving Gradle was Android Studio complaining for the missing dependency on class AndroidHTTP when about to add support for the GCE backend.

Putting on the detective's hat, this was the procedure I've followed:

First tried looking it up on the Google Developers web site:

Following the link brought up the Class's screen:

but since interested only in the package containing the class, I followed 'Package'

which brought up the Overview of the package list in "Google HTTP Client Library for Java"