ReactiveNetwork – release v. 0.9.0 with RxJava2.x support

2017-04-11 Android, DSP2017, Java, Open source, RxJava No comments

This time, I upgraded my another reactive Android open-source project called ReactiveNetwork to RxJava2.x. Many thanks goes to @tushar-acharya who performed initial migration to the newer version of RxJava. During migration, I’ve also created new package rx2 to avoid potential import conflicts during migration inside Android apps. Besides migration, I’ve updated sample apps, documentation & JavaDocs on Github pages. You can still use RxJava1.x version and it’s available on the branch with that name.

To use brand new ReactiveNetwork compatible with RxJava2.x, add the following dependency to your build.gradle file:

dependencies {
  compile 'com.github.pwittchen:reactivenetwork-rx2:0.9.0'
}

If you still want or need to use RxJava1.x, use the following dependency:

dependencies {
  compile 'com.github.pwittchen:reactivenetwork:0.9.0'
}

New updates and bug-fixes are on the way. Right now I have a few issues in the project backlog.

Feel free to contribute to this project and report new issues! Any constructive feedback will be appreciated.

Automate tile layouts creation in tmux with tmux-auto-pane

2017-04-08 Bash, DSP2017, Linux, Tmux No comments

I just released tmux-auto-pane. It’s a tiny shell script for creating pre-defined tile layouts in Tmux on Linux with xdotool.
In our workflow, we often have some pre-defined pane configurations in a terminal. The project called tmux-auto-pane helps to automate that process. It can save us some time and make us a bit more productive.

We can call tmux-auto-pane with one of the following parameters:

--help | -h   showing help
--1l1r        one left, one right
--1l2r        one left, two right
--2l1r        two left, one right
--1u1d        one up, one down
--1u2d        on up, two down
--2u1d        two up, one down
--4tiles      4 tiles, 1 in each corner

for example tmux-auto-pane --4tiles

will generate such layout:

 ____ ____
|    |    |
|____|____|
|    |    |
|____|____|

we can also have the following layouts:

    1l1r         1l2r         2l1r         1u1d        1u2d         2u1d
 ____ ____    ____ ____    ____ ____    _________    _________    ____ ____
|    |    |  |    |    |  |    |    |  |         |  |         |  |    |    |
|    |    |  |    |____|  |____|    |  |_________|  |____ ____|  |____|____|
|    |    |  |    |    |  |    |    |  |         |  |    |    |  |         |
|____|____|  |____|____|  |____|____|  |_________|  |____|____|  |_________|

Script can be installed via wget:

sh -c "$(wget https://raw.githubusercontent.com/pwittchen/tmux-auto-pane/master/install.sh -O -)"

or via curl:

sh -c "$(curl -fsSL https://raw.githubusercontent.com/pwittchen/tmux-auto-pane/master/install.sh)"

Due to the fact, that tmux-auto-pane uses xdotool under the hood, unfortunately it works only with Linux right now.
It can be improved in the future to work with macOS as well.

Source of the project can be found at https://github.com/pwittchen/tmux-auto-pane.
This project could be extended to start specific applications in each pane.
Maybe, I’ll improve it in the future, so users could parametrize their custom applications.

I hope Tmux & Linux users will find it useful :).

ReactiveBeacons – release of v. 0.6.0 with support for RxJava2

2017-04-03 Android, Bluetooth Low Energy, DSP2017, Java, Open source, RxJava No comments

Thanks to @BugsBunnyBR I released new version of ReactiveBeacons library with the RxJava2.x support. It’s an Android library scanning BLE (Bluetooth Low Energy) beacons nearby with RxJava Observables. I also kept backward compatibility with RxJava1.x. Different versions of the libraries are located on the separate git branches. It’s a similar approach to original RxJava project. I have separate builds on Travis CI, separate artifacts and JavaDocs. Such approach generates more overhead, but in such case, RxJava1.x can be kept in a maintenance mode and RxJava2.x can be a subject of the future development.

What has been done in this version?

  • migrated library to RxJava2.x on RxJava2.x branch and released it as reactivebeacons-rx2 artifact
  • kept library compatible with RxJava1.x on a RxJava1.x branch and released it as reactivebeacons artifact
  • removed master branch
  • bumped library dependencies
  • added permission annotations
  • organized Gradle configuration
  • transformed instrumentation unit tests to pure java unit tests
  • started executing unit tests on Travis CI server
  • created separate JavaDoc for RxJava1.x and RxJava2.x

If you want to add RxJava2.x version to your Android project, add the following dependency to build.gradle file:

dependencies {
  compile 'com.github.pwittchen:reactivebeacons-rx2:0.6.0'
}

For RxJava1.x you can use old artifact id:

dependencies {
  compile 'com.github.pwittchen:reactivebeacons:0.6.0'
}

This library was one of the first experiments with my migrations to RxJava2.x. I have plans to migrate rest of my libraries soon.
Thanks to the awesome open-source community on GitHub, this process goes faster and I don’t have to do everything by myself.

Browsing directories with Vim

2017-04-02 DSP2017, Linux, Vim 2 comments

I’m still learning Vim every day. At first, it looks quite hard and most of the people want to learn how to quit it and never use again. Nevertheless, when you learn some basics, you can be really productive. This editor has much more cool functionalities than just :q shortcut ;-).
Recently I discovered, you can use Vim not only for editing files but you can use it for browsing directories as well! Just go to any directory you want in terminal and type:

vi .

Then you have very nice file browser:

You can use most of the regular Vim commands like /yourkeyword for searching.

You can also navigate up and down with j and k as inside the files. To enter directory, just press Enter You also have other features like - key for going up, s for sorting, R for renaming and D for deleting. To quit this browser, just type :q (the same shortcut as in the editor).

I know, this file browsing functionality is not perfect, but it’s much better than regular navigation and directory browsing in the console with cd, ls and searching with grep. In some cases it may be a perfect choice!

How to make open-source projects, which people want to use

2017-04-01 Conferences, DSP2017, Open source No comments

Today at Kariera IT conference in Katowice, Poland, I presented talk explaining how to make open-source projects, which people want to use from my perspective.

Below, you can find slides from my presentation. Thank you all for the attendance, interesting questions and organizers for inviting me. I hope you learned something new.
Of course, any constructive feedback for this talk will be appreciated :).

Links

Handling different Android versions with strategy pattern

2017-03-26 Android, DSP2017, Software Design Patterns No comments

When we’re developing Android apps, we have to remember that different users have different versions of the Android OS. Unfortunately, not all of them has the newest version of the system and some of them have older devices with older systems. Some of these devices may be even unsupported because e.g. Google supports their devices like Nexus and Pixel for only 2 years. When we want to reach as many users as possible and make the app available for almost everyone, we have to handle different Android versions. One of the solutions for that problem is strategy design pattern (it’s also called Policy in Domain-Driven Design).

I’m developing an Android open-source library called ReactiveNetwork, which is used for monitoring connectivity with the network in the system. Network monitoring strategies vary between different versions of Android and I wanted to choose an appropriate strategy for appropriate Android version. To do so, I’ve created NetworkObservingStrategy interface:

This interface can have many implementations like LollipopNetworkObservingStrategy, PreLollipopNetworkObservingStrategy and MarshmallowNetworkObservingStrategy. Morever, more implementations can be added in the future.

After that, we can choose valid strategy for concrete version of the system:

That’s it. Now, we have the separate code working for Android M, L and all devices with system version lower than L.
This approach can also be applied to other areas.

Review your changes in the code before the commit

2017-03-26 DSP2017, Git 2 comments

Most of the people use git as follows.

  1. they create a feature branch
  2. they make some changes
  3. they add all the changes: git add -A
  4. they commit changes: git commit -m "I've done changes"
  5. they push it: git push

There’s a problem with such approach. When we created a lot of changes, it may happen that we forgot to delete something and we pushed some garbage to the remote repository.

It’s better to review our own changes before the commit.

When we’ve done some changes, instead of typing git add -A, we can type git add -p. It will allow us to review our own changes and approve or disapprove them with typing y (yes) or n (no).

After that process, all changes approved by us are “staged”. Changes, which are not approved are not staged. We can discard unstaged (and also unapproved) changes by typing git checkout -- .. After that, our repository is clean – unwanted changes are discarded & changes, which we approved are staged. Next, we can simply commit & push our changes to the remote repository.

This approach is, in my opinion, very useful and helps to avoid pushing unwanted code to the remote repository, what will hopefully make your co-workers happy.

Android design inspirations

2017-03-19 Android, Design, DSP2017 No comments

When we are planning to create our next Android app, besides the codebase, it’s also good to plan its design, UI, and UX. Before doing that, we can take a look at some inspirations and work of other people to gather a few UI design patterns, inspirations, and ideas.
Good resource of such inspirations is Android Niceties website. As the authors write, this website is
a collection of screenshots encompassing some of the most beautiful looking Android apps.

You can also take a look at https://pl.pinterest.com/explore/android-ui/.

Do you know any other similar resources? Share them in comments :-).

Unit test coverage report with Travis CI for Robolectric on Android

2017-03-19 Android, Continuous Integration, DSP2017, Gradle, Unit Tests No comments

Introduction

Some time ago, I’ve written an article about Test coverage report for Android application. It got some interest (many comments below article and many visits according to Google Analytics), so I decided to refresh this topic. Previously, I’ve written instrumentation unit tests, which needed to be executed on a real device or an emulator. It’s a good approach when you want to test functionalities strongly connected with the device. E.g. when you want to test operations on a real SQLite database or something like that. Nevertheless, this approach has huge disadvantages. It’s hard to run tests on the Continous Integration server because we need to have the emulator or device up & connected all the time and also tests need to interact properly with the device to get passed what is not so easy. In most cases, mocking part of the application’s behavior is enough. In that case, we can easily run tests on a CI server and have deterministic test results. In order to do that, we can use Robolectric.

Gradle configuration

First, we have to add appropriate dependency to jacoco-android plugin in our top-level build.gradle file:

buildscript {
  repositories {
    jcenter()
  }
  dependencies {
    classpath 'com.android.tools.build:gradle:2.3.0'
    classpath 'com.dicedmelon.gradle:jacoco-android:0.1.1'
  }
}

Next, we need to add appropriate test dependencies in another build.gradle file for our app or library.

dependencies {
  testCompile 'junit:junit:4.12'
  testCompile 'com.google.truth:truth:0.32'
  testCompile 'org.robolectric:robolectric:3.1.2'
  testCompile 'org.mockito:mockito-core:2.7.17'
}

I’ve added also dependencies to JUnit, Truth and Mockito library, which are used in my tests.

We also need to add appropriate plugins:

apply plugin: 'jacoco'
apply plugin: 'jacoco-android'

To avoid ignoring our tests by the coverage report, we need to configure the following settings:

android {
  testOptions {
    unitTests.all {
      jacoco {
        includeNoLocationClasses = true
      }
    }
  }
}

Next, we need to configure report output:

jacocoAndroidUnitTestReport {
  csv.enabled false
  html.enabled true
  xml.enabled true
}

Travis CI configuration

We are done with Gradle configuration. I’m assuming we have Travis CI build configured. If you don’t know, how to do this, visit travis-ci.org and enable builds for your project. It’ pretty easy. Now, we should visit codecov.io website, register there (e.g. with GitHub account) and add our project. After that, we need to add the following items to our .travis.yml file:

after_success:
  - bash <(curl -s https://codecov.io/bash)

script:
  - ./gradlew clean build test jacocoTestReport check

Here we are performing clean, build an application, running unit tests, generating test coverage report with Jacoco and performing check (Lint, FindBugs, PMD & CheckStyle).

Writing unit tests with Robolectric

Next we can place our tests in src/test/ directory.
Sample unit test can look as follows:

In my case, I also needed to create src/test/resources/robolectric.properties file with the following content:

sdk=23

because Robolectric didn’t work with the Android SDK newer than 23. Moreover, I also needed to use Robolectric v. 3.1.2, because I had problems with running tests and generating coverage report with the latest version of the Robolectric.

Summary

When we have everything configured, we can push our tests to the GitHub repository, Travis CI build will be triggered and we can beautiful test coverage report, which can help to improve our tests.

We can also click on the main package and see detailed coverage information for the several packages.

Moreover, we can analyze coverage change in time.

I’ve applied approach described in this article in ReactiveNetwork open-source library. If want to see the complete solution, take a look at the source code of this project or see its coverage report on-line.

My approach to Git aliases

2017-03-12 DSP2017, Git No comments

While we are working with Version Control Systems like Git, it’s good to adapt them to our needs to perform daily work in a more productive way. People often create so-called Git aliases, which are shortcuts for longer commands. E.g. you can edit your .gitconfig file, which is usually located in your home directory and place a few aliases in the [alias] section. For example:

[alias]
  ls = log --pretty=format:"%C(yellow)%h%Cred%d\\ %Creset%s%Cblue\\ [%cn]" --decorate

Then you can type: git ls in your Git repository to see pretty Git log.

Sometimes people go further and create many more aliases like:

cp = cherry-pick
st = status
cl = clone
ci = commit
co = checkout
br = branch

and so on. I’ve seen configurations containing about 20 aliases or more consisting of shortcuts, which have 2 or 3 letters. Usually, we don’t use 20 commands every day. I can remember e.g. 5 shortcuts, but I don’t want to remember more.

Instead of alias:

lcm = log -1 --pretty=%B

I prefer:

last-commit-msg = log -1 --pretty=%B

When I’m using terminal on Linux or macOS, I have type hinting, so I can type: git la, hit Tab and terminal will autocomplete my command to git last-commit-. Then I can hit Tab again and I can choose one of my aliases and select one by hitting Enter.

git alias hints in unix terminal

Now, I don’t have to remember all of my aliases. I treat my .gitconfig file as a documentation. Whenever I want to browse aliases, I can type git list-aliases (it’s also an alias to !git config -l | grep alias | cut -c 7- | sort) and if I want to find aliases related to diffs, I can type git list-aliases | grep diff. I also have more descriptive aliases like:

undo-last-commit = reset --hard HEAD^

so I know what this command actually does.

Morover, divided my aliases into separate sections and marked these sections with comments. The sections are as follows:

  • showing metadata
  • showing urls
  • showing commits, logs & branches
  • ignoring files
  • adding & reviewing changes
  • resetting and reverting changes
  • merging changes
  • branching
  • showing diffs
  • searching files

It allows me to keep my aliases in more organized way. It’s useful when our .gitconfig file “lives” and we update it during the work day if we need to.

Maybe this approach won’t be the best way of using Git for everyone, but it works for me and allows me to solve my daily tasks easier and faster.

You can find complete source of my .gitconfig file in my dotfiles repository at https://github.com/pwittchen/dotfiles/blob/master/.gitconfig.

Further reading

Happy coding!