Category: Development Tips

Setting up Travis CI in Android

Setting up Travis CI in Android

If you are developing using TDD you should run your tests to be sure that you don’t break something in every TDD phase. But we are not perfect and we can commit changes that break our system and we should have something that can alert us if we are doing something wrong asap. This is going to be a short guide on getting set and ready with Travis CI in Android. Before we continue, you need to have an Android Studio project already set up. Now let’s get down to business.


  • Create a github repo for your project
  • Head over to the root of your project and create a .travis.yml (More on this later)
  • Still at the root of your project, create a folder/directory called licenses; this directory will help in exporting your license agreements such as sdk license agreement from your local machine to the build environment.
  • Now head over to your sdk location and locate a folder/directory called licenses, copy its contents then go ahead and paste them inside the licenses folder/directory you created previously at your project root.
  • You’re now set up, just do a git init, add all your files to git then push your code to Github.

Setting up Travis CI

Here is where Continous Integration comes into play. Every time that you push changes into a branch in your system you can check if everything is ok before you merge this branch into Master (assuming you are using git). What to check? Well, this is up to you and your team members to decide.

I keep my promises! , lets now talk about .travis.yml mentioned earlier. So this is just a file that tells your build machine how it should be configured and also provides the necessary tools and information to get your build system up and running.

So how does this file look like? Here’s the code, you can copy paste it but ensure you go through it to have a grasp of what’s going on.

You can decide to paste it directly to your code then commit and push the changes or paste it in your Github Repo then pull the changes, either of these two will work fine.

Travis provides the service for free but your repo in Github must be public and the free URL is different from the premium URL.

After visiting Travis, sign in with Github. Search for your Github repo then add it. Travis will go to your repo, locate the .travis.yml file and do the rest. Hopefully, if you followed every step correctly, your build should be successful and the repo should turn green with the badge at the top indicating build passing.


It’s awesome looking at that badge from your repo. So to add it to your repo, go ahead and click on it. A pop up will show with the url of the badge. Copy the url then paste it in your README file. Here’s an example of how the file should look like inside your README file.

Hooray! Your CI should now be up and running. Thanks for your time.

Happy Coding!

How To Debug Your Android App over WiFi

How To Debug Your Android App over WiFi

Hello guys, its been a while since I wrote an article about code here. I have been pre – occupied at my new workplace, but still, there are more things to come. Keep subscribing 🙂

Now, I wanted to write about wireless debugging in Android. Its a little trick I discovered a while ago and it was immensely helpful. So far, whenever I was working on my Android apps, I had to connect it to my laptop with a USB cable. The USB cable is annoying and limits my movements. Then after some digging, I found out this easy work around.

All you need is a USB cable (for the initial setup) and have both devices in the same network. The screenshots in the following section are from my MacBook Pro, but it works on any operating system.


You need to connect your device to your computer via USB cable. Make sure USB debugging is working. You can check if it shows up when running adb devices.

Run adb tcpip 5555

Disconnect your device (remove the USB cable).

Go to the Settings -> About phone -> Status to view the IP address of your phone.

Run adb connect <IP address of your device>:5555

If you run adb devices again, you should see your device.

Now you can execute adb commands or use your favorite IDE (Android Studio) for android development – wireless!

Now you might ask, what do I have to do when I move into a different work space and change WiFi networks? You do not have to repeat steps 1 to 3 (these set your phone into WiFi-debug mode). You do have to connect to your phone again by executing steps 4 to 6.

Unfortunately, the android phones lose the WiFi-debug mode when restarting. Thus, if your battery died, you have to start over. Otherwise, if you keep an eye on your battery and do not restart your phone, you can live without a cable for weeks!

Happy Wireless Coding!

My First Year of Blogging

My First Year of Blogging

Hurray! Around this time last year, I launched this blog. I hope I helped someone here in one way or another and here’s a story of why I’m doing it and how it all started 🙂 I want to share some parts of my story along the way.

How I Started

So before I had any Android development job I was working on some apps, which were available on PlayStore (Unpublished later, haha). Because I knew it would be very hard to get a job, since I didn’t have a computer science degree, nor any experience of working for companies. This app was a proof of me knowing my shit! I had already been doing Android for close to two years, but for fun and did not have a good portfolio to showcase my skills yet.

Around that time I saw an Internship Position at Muva Technologies, which I quickly applied for. I actually wanted to get a job with them, but they gave me an Internship position instead which I gratefully accepted. Three months down the line, my Internship period was over, and they offered me a Consultant Position as an Android Developer, best moment of my time last year (January 2017).

Since it was not a full time job, I had a lot of time which I spent learning Android from my colleagues and decided to write few posts. But the question was where? So some idea just came up about starting a blog. In the next few minutes, I was busy thinking of good domain names on Godaddy, and then came up, and to my surprise it was available for purchase. I then acquired the domain and hosting, and with the help of my colleague Henry Mbugua, we set up wordpress and he taught me how to use it. Thanks for the support, I still appreciate it.

Now I know – it doesn’t matter how much you know, once you learned something – you already know more than somebody.

Blogging Reasons

So when I first started blogging I had like a great unknown in front of me, tons of topics, very exciting. Topics I knew nothing about. Blogging was my primary source of growth as an Android Developer

And I can tell you, after just three months of blogging basically, most topics were completely new to me. I was literally learning stuff hours before I was writing about them, I leaned like hell. In those 3 months of blogging, I was learning a lot of new stuff.

So if you want to become an Android Developer, start blogging. I mean right after around 2 weeks of learning start blogging. Pick a new topic every time, start from basics. And trust me, in fear of making yourself a complete fool by writing worst blog posts ever  you will learn stuff so quickly, to make better posts. This does not mean starting your own blog, you can even write me an email on the Contact Me Page and I can set up an Author account for you, and you can write your own articles on this blog. You may impact the next learners in a big way, who knows 🙂

I have continuously gained knowledge over the years, and started an Open Source Organisation on Github, to develop Android and Golang libraries primarily. Just get in touch if you want to join/contribute to it. We could be starting the next big Android Open Source Community 🙂

After working with Muva Technologies for one year, I am now moving on to Twiga Foods, where I will be joining as an Android Engineer. I hope to learn a lot of new and cool Android Development stuff and share with you here. You must be already excited as I am 🙂 I am also part of the ALC 2.0 Program sponsored by Google and Andela, to teach and create Android Development Awareness in the Sub Sahara, and I have come to meet very amazing programmers and share ideas with them. Thanks to Andela Kenya 🙂

This blog is still growing and gaining popularity in the Android Community, and I recently made it open to anyone who feels they need to share anything. You can share something about anything you learnt and you could be a lifesaver to someone else. If you feel challenged enough, please drop me a message, and I will set up an account for you 🙂

Alright, I hope you find my story somewhat interesting. If you’re living in the middle of nowhere and there’s no Android or any kind of programmers around it’s kind of hard to be motivated and grow.

Blogging is the biggest growth booster I’ve ever known.

Also, I want to hear your stories. Are you a beginner/not? Do you feel like you have learned all you need to know about Android development/how much more time do you think it will take you to become a “pro”? Share your views and comments down below.

Happy Coding!

Continuous Integration with Github, Android and CircleCI

Continuous Integration with Github, Android and CircleCI

Hello guys, today I will be writing about something new that I am learning. Lets look at CI. But before we look at it, I would like to express how excited I am to finally join Twiga Foods as an Android Engineer,  thanks to their wonderful C.T.O Mr Caine and their entire Development Team.

Continuous Integration (CI) plays an important role in the development process for almost every development team. Knowing the effects of your changes is extremely useful to see how the tasks are coming together with other members. It’s also just a good approach to take in general if you’re developing something personally and want to track the progress and stability of your project.

There’s a lot of CI tools available to anyone who needs it,  with Jenkins or TravisCI being the most recognized tools out there. CircleCI is a fresh take on CI that provides a very clean UI and powerful flexibility to users. Let’s take a look at setting up a basic CircleCI build task for an Android application.


  • A Github account (CircleCI also has BitBucket login option)
  • Android Studio – I’m using the 3.1 Canary  8 preview version.

Dipping your toes

I’m going to assume you already have an Android app up and running in Android Studio so I’ll skip that part. If you don’t have your application code in Github or another type of Version Control system, I would recommend you do that now. It can be a life-saver if things go bad and you can work on your code from anywhere.

The first thing we need is to create your CircleCI account. CircleCI is free to sign up to and use up to a certain limit (approx 1500 build minutes p/month) so it’s great for individuals. We’ll also be using a technique to speed up build times on CircleCI to reduce build times. When you sign in with your Github account, you’ll be able to choose which projects you’ll want to track / build. Select the project you want to follow and an initial build should trigger. CircleCI’s default configuration triggers a build to occur on any commit to any branch on the repository, but this can be customised later on. CircleCI fires up a container to host your app while it’s building.

Lets use this Repo from my Andela ALC Challenge, which you can folk and make contributions to 🙂


Follow the Next Steps section you see in your CircleCI, as shown in the screenshot above. After that, just push the changes to Github.

It’s probably best to switch to Project perspective in Android Studio for this part, as the file is hidden in the Android perspective.

After you are done pushing it, just hit the Start Building button on step 5. This triggers CircleCI as shown below:

As shown above, CircleCI is performing a build on the Master Branch.

After performing the first build, I got an error 🙂

So I googled my way around Stackoverflow and found this solution. Move the config.yml from the .circleci folder. I tried to rebuild again and got this build error.

The issue here is that we have not granted the correct permissions to the ./gradlew command on the container that CircleCI has created.

This configuration file informs CircleCI that when the dependencies section is reached, gradlew must be given execution permissions (chmod +x) This will allow ./gradlew to run, but it will fail for a different reason. To use the Android SDK and build tools, you must accept the licence agreements.

Passing the Test

The most important part of the above config file is ./gradlew assemble. This is what actually builds your project. Once you have this file in your project, your CircleCI build should be ready. My builds usually take about 4 minutes to complete, but it is somewhat dependent on how much you pay! Settings on CircleCI can be accessed which change when a build is triggered, such as only on pull requests. CircleCI also has email notifications, along with integrations for Slack channels so it’s a very modern and useful tool for Android development.

I am still learning a lot in CircleCI, so free free to shoot suggestions, tips and even questions down below. Remember to subscribe, follow me on Twitter and Facebook to get updates from me.

Happy Coding!

UI Testing with Espresso

UI Testing with Espresso


It is normal for developers not to be concerned about testing at the beginning when still learning how to program, but as they get involved in larger projects and critical software, getting involved in testing will be inevitable. According to the documentation, Espresso is targeted at developers, who believe that automated testing is an integral part of the development lifecycle.

Software testing is the last thing on the mind of someone who just wants to code and get it going, as long as there are no bugs it is good to go. But that can be costly if done in companies where a minute of failure will cost a lot of money. I was at a GDG (Google developer group) event where a speaker who works at a well known international company said that the company had lost millions at a point, and it was due to the fact that a developer had forgotten to test the UI which was to book international flights for  customers. It was charging the customer’s account but displayed that the transaction was unsuccessful so the customers kept booking assuming that it was because of poor network, imagine how much was lost with that kind of error. Well, testing might not be top priority if I am making a quick to-do list app 🙂 , but it is good practice to properly test your code.

Espresso is a testing framework that includes a set of APIs that simulates and schedules user interactions to help test the user interface and with these tools you can automate the process of testing. So instead of punching, slapping, poking or pressing your phone screen to test if your app works fine as expected, Espresso can do this for you while you relax 🙂 .

Normally if you were to manually test your Android app, you will start the appfind the view you want to test, and verify that the expected output or behavior was what occurred. If you understand these steps then testing should’t be a problem.

According to the documentation, to create an Espresso test, create a Java class that follows this programming model:

  1. Find the UI component you want to test in an Activity  by calling the onView() method, or the onData()method for AdapterView controls.
  2. Simulate a specific user interaction to perform on that UI component, by calling the ViewInteraction.perform() or DataInteraction.perform()method and passing in the user action (for example, click on the pay button). To sequence multiple actions on the same UI component, chain them using a comma-separated list in your method argument.
  3. Repeat the steps above as necessary, to simulate a user flow across multiple activities in the target app.
  4. Use the ViewAssertions methods to check that the UI reflects the expected state or behavior, after these user interactions are performed.

Code time!

Lets take a look at a code snippet below

The first thing done is the search for the view, the withId() is a view matcher, while the check() is the view assertion. So when the code runs it checks if the textView with Id is displayed and if it finds the view the test will pass, otherwise the test will fail.

To properly demonstrate, let us test a simple app that copies a text from an EditText to another EditText view.

Below is the UI.


Below is the XML and code to see what’s under the hood:



The EditText with Id textA is the first view at the top, while textB is the second view below textA but above the button (copyBtn).

To test this app let us create a new instrumented unit test:

I can name mine MainActivityTest:

Start testing!

So this is how my MainActivityTest class looks initially:

You will normally start the class with @RunWith(AndroidJUnit4.classwhich helps control launching the app and running UI tests on it. ActivityTestRule is a rule that provides functional testing for a specific single activity. All these annotations indicate to Android that specific parts of the test code need special processing. @Test indicates where we are testing what we are interested in.

The @Test method can have any name, but for readability be careful to give it a name that indicates the purpose of the test.  I will just quickly name mine TestEditTextA.

So the above test is just a simple test that writes some text on the first EditText view and verifies if what was written on that same EditText (textA) is what appears.  To run the test you right-click on the Java file and select ‘run’, in this case ‘RunMainActivityTest’.

If it is successful you will see a green bar as shown below, also stating how many tests were carried:


If it failed for some reason, the bar will be red and you will see the log output for example:


Full Code!

The test source code shown above isn’t the main test since it does not test the button click and the copying, below is the full code for the test:

So as shown, the text “123456” is written onto the first EditText (textA) then the button (copyBtn) is clicked and then the second EditText (textB) is checked if the text was truly copied, if so then the test passes and the app works as expected. You can get the full source code at EspressoTutorial.

Read More Read More