Found this awesome YouTube Channel: https://www.youtube.com/playlist?list=PL0d1JnOtQbFSDwKdI4EdE81eSaqNkCqhc
All videos have subtitles so you can follow along in your native language!
–jsp
Java
A Strong Cup of Java
Hey everyone!
If you’re interested in the goings-on of the Java language, be sure to check out my new Web Series on IBM Developer called A Strong Cup of Java.
The show will focus on interesting topics in the world of Java.
Episode One is about Jakarta EE, where I talk about what Jakarta EE is, and how it got its name (whatever happened to J2EE?).
Episode Two covers the launch of Jakarta EE 8 (the first release of enterprise Java since Java EE 8 in 2017) that happened on September 10, 2019 in an all-day live stream called JakartaOne.
In the coming weeks, there will be eight more episodes published (I have a 10 episode committment from IBM for the series). With your support there may be more, so please watch!
Click here for the show notes page at IBM Developer.
If you have ideas for topics, please let me know. Thanks for reading!
–jsp
JUnit Jupiter Annotations, Chapter 2
Overview
In part 1 I introduced you to JUnit 5 annotations:
- @DisplayName
- @Test
In this chapter, I’ll show you two more annotations:
- @Disabled
- @Nested
With code examples for both, and a video where I write code using these annotations.
You can download the complete sample application from GitHub if you like.
Let’s get started!
The Class Under Test
Before diving into the meat of this, let me show you the class under test. It’s called Echo, and it’s very simple (so as not to get in the way of the lesson):
public class Echo {
public String echo(String stringToEcho) {
return stringToEcho;
}
public Integer echo(Integer intToEcho) {
return intToEcho;
}
}
The class is pretty simple: its contract stipulates that it echoes whatever is passed, unchanged.
In true Test-Driven Development (TDD) style, you’ll write the implementation after you write the unit tests.
@Disabled
@Test
@Disabled
@DisplayName("A disabled test")
void testNotRun() {
// This method will not run
}
Use this annotation to tell the JUnit platform not to run this test method. Notice that the method is annotated with the @Test annotation. Normally, JUnit would execute this method at the appropriate point in the test lifecycle, but annotating the method with @Disabled tells JUnit not to run it.
Why not just remove the @Test annotation? It might be good for documentation purposes to leave it annotated with @Test so you know it was a test method, or maybe you just want to temporarily disable the method.
@Nested
This is a super cool new feature of JUnit 5 that allows you to create nested (inner) classes that keep groups of tests together in the same main test class, but separate from the other test methods in that class.
In the case of the Echo class, both methods are called echo, so you need some way of distinguishing which echo overload you’re testing. You could do something like this:
@Test
public void testEcho_String() {
.
.
}
@Test
public void testEcho_Integer() {
.
.
}
And that would work just fine. But JUnit 5 and the Jupiter API give you the @Nested annotation. So let’s use it!
@Nested
public class StringEchoTest {
@Test
public void testEcho() {
classUnderTest = new Echo();
String expectedString = "This is a test";
assertAll("String version of echo() method",
// equals() should match,
/// but that is not good enough
() -> assertEquals(expectedString,
classUnderTest.echo(expectedString)),
// hash codes should match,
/// but still not quite good enough
() -> assertEquals(expectedString.hashCode(),
classUnderTest.echo(expectedString).hashCode()),
// This should do the trick
() -> assertEquals(
System.identityHashCode(expectedString),
System.identityHashCode(
classUnderTest.echo(expectedString))));
}
}
@Nested
public class IntegerEchoTest {
@Test
public void testEcho() {
classUnderTest = new Echo();
Integer expectedInteger = Integer.valueOf(238);
assertAll("String version of echo() method",
() -> assertEquals(expectedInteger,
classUnderTest.echo(expectedInteger)),
() -> assertEquals(expectedInteger.hashCode(),
classUnderTest.echo(expectedInteger).hashCode()),
() -> assertEquals(
System.identityHashCode(expectedInteger),
System.identityHashCode(
classUnderTest.echo(expectedInteger))));
}
}
Video
In the video below, I’ll go over these annotations in detail, and you can watch me explain the code as I write it.
Conclusion
In this article, I showed you some of the annotations from the JUnit Jupiter API you’re most likely to use. But there is a LOT more to JUnit than the Annotations.
Be sure to follow along with this series here on my blog, and the accompanying videos on my YouTube channel.
To learn more about the annotations provided by the JUnit Jupiter API visit the JUnit 5 User’s Guide.
Check out my IBM developerWorks JUnit 5 Tutorial Series:
Check out the first post in this series here.
Container Orchestration with Kubernetes, Part 5
Managing Kubernetes
Hey everybody! In this post, I’d like to talk about Container-centric infrastructure with Kubernetes. This is Part 5 of a series of posts on using installing and using Kubernetes.
If you missed Part 4 where I give you Install Kubernetes on your Computer (Minikube), make sure to check that out.
In this post I’ll show you two ways to manage your Kubernetes applications:
kubectl- Kubernetes Web UI Dashboard
The kubectl command
When Kubernetes starts a pod it’s isolated in its own network. So how do we interact with the application?
One way is through a proxy, which you can start in a separate terminal window. Start a new Terminal window and execute the kubectl proxy command.
kubectl proxy
By default the proxy uses port 8001, but you can specify a different port using the --port option.
kubectl proxy --port=8080
This starts the proxy using port 8080. Now you can connect to the cluster through port 8080 on your computer.
I’ve written a script to get the pod name and use it to access the application through the cluster’s REST interface. The script is called test-k8sdemo.sh and takes the port as an argument.
./test-k8sdemo.sh 8080
And there you see the output.
Now that we have an app up and running, let’s talk about how to manage it. You can use the kubectl command to get information about pods, deployments, and so on.
For example, you can show a listing of the deployments:
kubectl get deployments
Or of the pods:
kubectl get pods
You can even get detailed information about the pods:
kubectl describe pods
This produces a lot of output, but it’s valuable (if somewhat verbose) information.
Kubernetes Web UI Dashboard
Now I love the command line as much as anybody, but did you know that Kubernetes has a Web-based UI dashboard?
By default the Dashboard is not deployed. From the documentation, you can copy the command to create the deployment through the kubectl command:
kubectl create -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml
Paste the above command into the console to deploy it.
Make sure the proxy is running (I showed you how to do this in Part 4). Start the proxy in a separate Terminal window:
kubectl proxy --port=8001
Once the Dashboard is deployed you can access it from http://localhost:8001/ui.
You can see the same basic information as from the various kubectl commands, but in a UI. Here’s an example of what I see using Chrome:
Conclusion
Well, that’s it for this series. I hope you enjoyed it, and make sure to check out the video below that walks you through everything I covered in this blog series (it’s true what they say: a video is worth a thousand pictures!).
Want to know more?
If you want to learn more about Kubernetes, check out this post at IBM developerWorks: What is Kubernetes?
Be sure to check out the other posts in this series:
- Part 1: Why Containers?
- Part 2: Kubernetes Overview
- Part 3: Install Kubernetes on your Computer (Minikube)
- Part 4: Work with Kubernetes on your Computer (Minikube)
Check out this video at IBM developerWorks TV, where I show you everything I covered in Parts 1-5 of this series:
Thanks for reading!
–jsp
Container Orchestration with Kubernetes, Part 4
Working with Kubernetes on your Computer (Minikube)
Hey everybody! In this post, I’d like to talk about Container-centric infrastructure with Kubernetes. This is Part 4 of a series of posts on using installing and using Kubernetes.
If you missed Part 3 where I give you Install Kubernetes on your Computer (Minikube), make sure to check that out.
The Application
So now you’re finally ready to start using Kubernetes. The first step in deploying a containerized application is, well, the application. I’ve put together some demo JavaScript code that you’ll run as a Node.js application.
Open a Terminal window or command prompt, navigate to a location on your computer where you want the code to land and clone the code from GitHub.
git clone https://github.com/makotogo/developerWorks
Navigate to the kubernetes directory and take a look at the JavaScript code. This toy application doesn’t do anything serious, just outputs a message to the console. But it’s enough for our purposes here.
Now run the application in Node.
node k8sdemo.js
Open a browser and point it to http://localhost:8080 to see the message.
And there it is. Now that you have an application, it’s time to containerize it.
Containerize the application
Here’s how you use Docker to do that. Take a look at the Dockerfile:
FROM node:6.11.4 EXPOSE 8080 COPY k8sdemo.js . CMD node k8sdemo.js
Use this Docker definition to containerize the application. But before we can do that we need to start minikube, and I’ll show you why in a minute.
Execute the minikube start command:
minikube start
The first time Minikube runs, it has to download the ISO image to run inside of VirtualBox, and may take a minute or two depending on the speed of your internet connection. Once the image has been downloaded, minikube will start.
Minikube runs inside VirtualBox in its own VM. We need to make sure that Docker uses the internal Docker registry on Minikube’s VM by executing this command:
eval $(minikube docker-env)
Otherwise Docker will use the local registry on your machine, which is not accessible from the VM where minikube is running.
Now, from the Terminal window, execute the docker build command:
docker build -t k8sdemo:v1 .
This will create the image with a name of k8sdemo and a tag of v1, and store it in the Docker registry on the minikube host VM. When deploying the image to Minikube, you’ll reference that tag explicitly.
From the Terminal window execute the kubectl run command:
kubectl run k8sdemo --image=k8sdemo:v1 --port=8080
And now the application is up and running in its own Pod.
Conclusion
In this post I showed you how to work with Kubernetes on your computer. You containerized a simple application, then deployed it to your local Kubernetes cluster.
In Part 5, I’ll show you how to manage an application running in a Kubernetes cluster using kubectl and the Kubernetes Web UI Dashboard.
Want to know more?
If you want to learn more about Kubernetes, check out this post at IBM developerWorks: What is Kubernetes?
Be sure to check out the other posts in this series:
- Part 1: Why Containers?
- Part 2: Kubernetes Overview
- Part 3: Install Kubernetes on your Computer (Minikube)
Check out this video at IBM developerWorks TV, where I show you everything I covered in Parts 1-5 of this series:
Thanks for reading!
–jsp
Container Orchestration with Kubernetes, Part 3
Install Kubernetes on your Computer (Minikube)
Hey everybody! In this post, I’d like to talk about Container-centric infrastructure with Kubernetes. This is Part 3 of a series of posts on using installing and using Kubernetes.
If you missed Part 2 where I give you Kubernetes Overview, make sure to check that out.
In this post, I want to walk you through installing the software you need to run Kubernetes on your computer.
Install the software
You’ll need a few pieces of software to run Kubernetes on your computer:
- Docker
- VirtualBox (or some other virtualization software)
- Node.js
- Minikube
Install Docker
First, you need Docker. You can find instructions for your platform by clicking this link. If you already have Docker installed, skip to the next section.
Scroll down until you see your platform, which is MacOS in my case, so I’ll click on Docker for MacOS. I want the distribution from the Stable channel, so I click on the link that says Get Docker for Mac (Stable). Always verify the 256 bit SHA checksum of the downloaded file matches what is published.
Now double-click the DMG file to begin the installation, and follow the instructions.
Install VirtualBox
Minikube requires a virtualization environment in order to run. If you want to use software other than VirtualBox, check out the Getting Started with Minikube page at kubernetes.io. If you already have VirtualBox installed, skip to the next section.
To install VirtualBox, go to the VirtualBox installation page, and click on the link that matches your platform. ALWAYS verify the SHA256 checksum matches the downloaded file.
Now double-click the DMG file to begin the installation, and follow the instructions.
Install Node.js
In order to test the demo application, you’ll need Node.js installed. I already have Node.js installed on my Mac, so I’ll skip that for the video. Make sure to check out the Node.js installation page. If you already have Node.js installed, skip to the next section.
Click on the download link that matches your platform, and follow the instructions.
Install Minikube
Go to the Minikube page at GitHub, and look for Installation.
I like to use Homebrew to install software on my Mac. If you’re using Linux or Windows, the Minikube installation page has instructions for those platforms as well.
Drop out to a Terminal window and execute the brew cask install for Minikube:
brew cask install minikube
Homebrew installs Minikube and now it’s ready to go. Yes, it really is that easy (on MacOS anyway).
Conclusion
Now you have all the software you need to work with Kubernetes on your computer. Stay tuned for Part 4, where I’ll show you how to work with Minikube and define an application, deploy it to your local k8s cluster.
Want to know more?
If you want to learn more about Kubernetes, check out this post at IBM developerWorks: What is Kubernetes?
Be sure to check out other posts in this series:
- Part 1: Why Containers?
- Part 2: Kubernetes Overview
Check out this video at IBM developerWorks TV, where I show you everything I covered in Parts 1-5 of this series:
Thanks for reading!
–jsp
JUnit Jupiter Annotations: Chapter 1
Overview
In order to run JUnit tests, you need to tell the JUnit Platform about your test classes: which methods are test methods, which methods are part of the test method lifecycle, whether to use extensions, and so on.
You do this through annotations, which are metadata about how to run your tests.
You can download the code from GitHub if you like:
https://github.com/makotogo/HelloJUnit5
In this post, I’ll cover the two annotations you’re likely to use with JUnit, along with examples of each.
@Test
@Test
@DisplayName("When numbers are > 0")
public void testAdd() {
// Unit test code here
}
Use this annotation to tell the JUnit platform that the method is a test method. This means it will be invoked at the appropriate point in the lifecycle, complete with all the bells and whistles.
Every method you want to run as a test method needs to be annotated with the @Test annotation.
@DisplayName
@DisplayName("Testing using JUnit 5")
public class JUnit5AppTest {
.
.
@Test
@DisplayName("When numbers are > 0")
public void testAdd() {
// Unit test code here
}
.
.
}
By default, the name displayed for a test class or method is the name of the class or method, respectively. The @DisplayName annotation tells JUnit to use the specified name instead.
Check it out: compare the following examples, first without the annotation, then with it. (Both are from the JUnit View in Eclipse)
Without the @DisplayName annotation:
And with the @DisplayName annotation:
In this simple example, you can see already that the report is cleaner. But when there are several test methods, the value of @DisplayName gets even clearer:
Video
In the video below, I’ll go over the annotations in detail, and you can watch me explain the code as I write it.
Conclusion
In this article, I showed you two of the annotations from the JUnit Jupiter API you’ll definitely want to use. Stay tuned for more in this series, where I’ll show you more annotations from the JUnit Jupiter API.
Be sure to follow along with this series here on my blog, and the accompanying videos on my YouTube channel.
To learn more about the annotations provided by the JUnit Jupiter API visit the JUnit 5 User’s Guide.
Check out my IBM developerWorks JUnit 5 Tutorial Series:
JUnit Jupiter Assertions: Setup
Hey everybody!
The Assertions class of the JUnit Jupiter API is the GO-TO for testing your code. After all, how do you check a condition without an Assertion?
I’m doing a multi-part series on the Assertions API on my YouTube channel (Makoto TV), so make sure and check it out.
In Part 0, I show you how to get the code that accompanies all of the videos, and get your Eclipse workspace setup.
Make sure and check it out.
And thanks for reading!
–jsp
Java News and Code, Episode 14
Welcome
Welcome to Java News and Code, where I tell you about interesting goings-on in the world of IT in general, and Java in particular.
And there’s always code.
On This Episode:
- Oracle wants to open source Java EE
- Android Oreo is here
- Code: A custom Maven archetype for JUnit 5
TLDR;
TODO: VIDEO HERE
Oracle wants to open source Java EE
On August 17th, Oracle Software Evangelist David Delabassee said Oracle wants to open up Java EE.
The announcement on the Oracle Blog says that as the summer ends, releases wrap up, and JavaOne 2017 approaches, this is an “…opportunity to rethink how Java EE is developed in order to make it more agile and responsive to changing industry and technology demands.”
As InfoQ points out, Oracle has been criticized regarding how it’s steered Java EE in the past, which has led to efforts such as the Java EE Guardians, a group “…committed to moving the Java EE platform forward through active community participation and advocacy.”
Java EE Guardians’ members include James Gosling, the Father of Java, and Cameron McKenzie, editor-in-chief of the Server side. It’s not clear what qualifies someone to be a Java EE Guardian, but qualifications span the spectrum from Father of Java, to Java Blogger, to this Java EE Guardian, whose qualifications include Student.
Reaction outside Oracle seems to be positive, with IBM’s Ian Robinson weighing in on the WASDev blog saying, “…we are delighted that Java EE is moving with the times to an open foundation for its ongoing development following the completion of Java EE 8 this year.”
So who will take over Java EE?
Responses to an unofficial Twitter poll by Java EE Guardian Reza Rahman asking that question seem overwhelmingly in favor of handing stewardship of the platform over to Apache.
So what does this mean for Java EE? It depends on whom you ask, but given the popularity and prevalence of the platform, I’m sure it will stay in good hands.
Be sure to check out the show notes page, where you can find more information on this story, and everything I talk about in this episode.
Android Oreo is here
We’ve been following Android O for some time now here at Java News and Code, and at long last, Android O, named Oreo, has been released!
For users, Android Oreo has a bunch of new features, some of which are immediately obvious like picture in picture, and per-app notification options.
Other changes like background limits, are designed to improve device responsiveness and extend battery life.
For developers, things get more complicated. The optimizations and improvements come at a cost, which will be paid on the development side. And rightly so.
What does that mean for developers like me, who have apps in the Play Store?
For now, probably not much. Oreo is not even showing up on the Android Dashboard as of today, but of course, it’s only a matter of time.
Android Marshmallow has the single greatest share of installations, and it was released in October of 2015, coming on two years. So we have time.
But as developers we need to be ready. Fortunately, there is information available already to help us get ahead of this, like this video on the Android Developers YouTube channel.
This release is huge, there’s no denying it. And in my opinion totally worth it. Check out this article at Gizmodo, that lays out 11 cool new features in Oreo.
Be sure to check out the show notes page, where you can find more information on this story, and everything I talk about in this episode.
Code: A custom Maven archetype for JUnit 5
On August 24th, JUnit 5, Release Candidate 3 was released.
This release, which signals the impending General Availability (GA) Release, includes the usual spate of bug fixes, breaking changes, and new features.
The GA release is scheduled for September 6th, according to the milestones page.
A Maven archetype is a special type of Maven project that is used to generate other Maven projects. If you’ve ever used the New Project wizard in Eclipse to create a Maven project, chances are you’ve used the maven-quick-start archetype. Guess what? That’s a Maven archetype!
For this episode’s code talk through, I want to show you how to create a Maven archetype that you can use to create new projects that will come with JUnit 5 dependencies and boilerplate code.
The source code for the archetype is available in GitHub. And in this episode I want to do a quick walk through of the code for a Maven archetype, how it’s structured, and how to use it to generate a new project.
Let’s get started.
First, clone the code from GitHub. Open a Terminal window, navigate to the directory where you want the code to land and execute the git clone command:
git clone https://github.com/makotogo/JUnitJupiterArchetype
Next, import the code into Eclipse.
With the code in Eclipse, let’s take a quick tour. Expand all of the nodes in the source tree. Open the src/main/resources/META-INF/maven/archetype-metadata.xml file, which tells the archetype generator what source files, test source files, resources and so forth you want to be included in new projects generated from the archetype.
A Maven archetype project is itself a Maven project, so there are two POM files to deal with:
The one that controls the archetype project itself, located in the project root:
4.0.0 com.makotojava.learn junit-jupiter-archetype 0.9.1 Archetype - jupiterArchetype http://maven.apache.org jar
And the POM file that will be included in any projects created from the archetype, src/main/resources/archetype-resources/pom.xml.
The archetype project also includes boilerplate code like this:
package $package;
import static org.junit.jupiter.api.Assertions.assertAll;
import static org.junit.jupiter.api.Assertions.assertEquals;
import org.apache.log4j.Logger;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.junit.platform.runner.JUnitPlatform;
import org.junit.runner.RunWith;
/**
* Unit test for simple App.
*/
@RunWith(JUnitPlatform.class)
public class AppTest {
private static final Logger log = Logger.getLogger(AppTest.class);
private App classUnderTest;
@BeforeEach
void setUp() {
classUnderTest = new App();
}
@Test
@DisplayName("assertAll on a bunch of Strings should succeed.")
public void doIt() {
log.info("Testing doIt()...");
assertAll(
() -> assertEquals("String", classUnderTest.doIt("String")),
() -> assertEquals("StringToo", classUnderTest.doIt("StringToo")),
() -> assertEquals("String2", classUnderTest.doIt("String2")),
() -> assertEquals("StringAlso", classUnderTest.doIt("StringAlso")));
}
}
To use the archetype to create new projects, you first have to build the archetype project itself. Like I said, it’s a Maven project, so to build it go to Run As > Maven Project and specify the install and archetype:crawl goals to install it in your local Maven repository, and update your local archetype catalog, respectively.
Next, make sure the archetype is included in your local Maven archetype catalog, which is located in the repository root in a file called archetype-catalog.xml. And there it is.
Now, I can use that to create projects in Eclipse. First, make sure Eclipse recognizes the local maven catalog. Under Preferences > Maven > Archectypes, click on Add Local Catalog. Browse or enter the path to your local archetype-catalog.xml file, give it a description you’ll recognize later, click Ok. Then Click Apply and close.
To create a new project based on the new archetype, go to File > New Project > Maven Project. Click Next. Click Next again. Select the archetype in the list, and complete the wizard.
When the wizard completes, you now have a new project based on your custom archetype!
How cool is that?
For a detailed walkthrough of this, check out this video.
Fini
Well, that’s it for today’s episode. Be sure to check out the show notes page, where you can find more information on this story, and everything I talk about in this episode.
Thanks for watching Java News and Code (and reading this post).
I’ll see you next time.
–jsp
Java News and Code, Episode 13
Welcome
Welcome to Java News and Code, where I tell you about interesting goings-on in the world of IT in general, and Java in particular.
And there’s always code.
On This Episode:
- Java Still on top in the Tiobe Index (but falling)
- Android O Final Preview
- Code Talkthrough: Android and the Cloud
TLDR;
Java Still on Top (but Falling)
According to the Tiobe index for August 2017, Java is at #1 and still has a commanding lead over all other languages. But its percentage score has fallen to about 13%, down from just over 19% a year ago.
And Java is not alone: the top 5 are all in decline from a year ago, with C at 6 1/2%, C++ at 5.6%, C# at 4.2%, and Python at 3.7%.
Scroll down on the page to see just how far ahead of the pack Java is:
From the graph you can see Java had a similar drop back in 2004 from which it rebounded strongly, so maybe this is a temporary trend. Who can say?
If you want to see how the index is put together, you can visit this page.
The Tiobe index is put together during the first week of each month.
Make sure and check out the show notes page, where you can find this story, along with all the links in this episode of Java News and Code.
So be sure to check that out.
Android O Final Preview is Out
On July 24th, Android O Developer Preview 4 was made available.
The announcement on the Android Developer’s Blog, comes one month after the announcement of Developer Preview 3, which I told you about in episode 8 of Java News and Code.
Preview 3 contained some very nice features like simplified settings, battery life optimizations, and per app notifications.
Preview 4 is the final preview before the official O release later this summer:
Preview 4 is a Release Candidate build of the Android O platform, and while it doesn’t have any new features, it contains the final system behaviors, bug fixes, and the final API (level 26).
Coming soon is also a new release of the Android Testing Support Library. The blog post says to stay tuned for more details coming soon.
And if you want to use Developer Preview 4, it’s recommended that you download Android Studio 3 Canary 1 as well, available in the Canary channel.
The show notes page has links to the blog post, download page, and lots more.
So be sure to check that out.
Code Talkthrough: Android and the Cloud
Finally, in today’s code talk through, I’d like to show you a recipe for building a RESTful web service application, deploying it to the Bluemix cloud as a Cloud Foundry application, and building an Android app to communicate with it.
The code I’ll show you is available in GitHub, and is from a recipe I wrote for IBM developerWorks called Android and the Cloud.
To follow along with the video, you will need a Bluemix account, JDK 8, Eclipse, WebSphere Liberty, and Android studio installed on your computer.
You will need three projects from GitHub also:
- oDoTCore – the “guts” of the web services application
- OdotWrapper – the RESTful web services wrapper around oDoTCore
- AndroidCloudRecipe – the Android application code
In today’s show, I’m just going to show you the high level steps. The recipe walks you through it step-by-step if you’re interested in reproducing this yourself, which I hope you are.
Let’s get started.
First, clone the code from GitHub for the two web services projects.
git clone https://github.com/makotogo/oDoTCore
git clone https://github.com/makotogo/OdotWrapper
Now import the code into Eclipse.
With the code in Eclipse, build the oDoTCore JAR file using Maven, specifying the install goal so the JAR file gets installed to your local Maven repository.
Next, build the OdotWrapper WAR file using Maven, specifying the package goal.
Locate the WAR file in the target directory, and copy it to the WebSphere Liberty droppins directory.
Start WebSphere Liberty in Eclipse.
To verify the WebService is working, go to a browser and access this URL
http://localhost:9080/OdotWrapper/ItemRestService/Ping
When you see the JSON message, you know you have everything built and packaged correctly.
Now I’ll bundle the WebSphere Liberty server, including the WAR file, and deploy it to Bluemix.
For this part I need my Bluemix credentials, and the route I want to deploy it to.
I’m going over this fast, I know, but this is just an overview. The recipe has all the details.
Once I’ve deployed the application to Bluemix, I can test it and make sure it’s running. Open a browser, and hit this URL:
https://androidcloudrecipe.mybluemix.net/OdotWrapper/ItemRestService/Ping
Again, when I see the JSON message “Hello from the server side!” I know it’s up and running.
Now to build the code for the Android app, run the app in the Android Emulator, and access the Web Service running in Bluemix.
Don’t worry, we’re almost there!
First, pull the code from GitHub:
git clone https://github.com/makotogo/AndroidCloudRecipe
Now import the code into Android Studio, and run the code in the Android Emulator. Choose the virtual device you setup when you installed and smoke tested Android Studio. It takes a minute or two for the device to start.
When the device starts, it will load the application. If you don’t see the application, click the Run button again in Android Studio.
Verify that the URL is correct (if not, change the code and run it again), and click the Info floating action button to invoke the Ping method. If you get back a Toast message that looks like this, then you’re good to go:
Under the hood, the Android app receives the JSON message we saw earlier in the browser, and is rendering it as a Toast message.
Now click on the Refresh From Server button, and the list should fill with data:
And that’s how you connect an Android app to an application running in the Cloud!
The developerWorks recipe has the steps broken down in much more detail, so be sure to check that out.
That’s all for this episode of Java News and Code.
Make sure to visit the show notes page, click the subscribe button, and you’ll be notified each time a new episode comes out!
–jsp
j steven perry, The Blog 
You must be logged in to post a comment.