Android

Release of prefser v. 2.1.0 with RxJava2 support

2017-06-19 Android, Java, Open source, RxJava 2 comments

I’ve recently released new version of prefser library for Android. In case you don’t know, it’s a wrapper for Android SharedPreferences with object serialization and RxJava Observables. This version has the new artifact, which has codebase migrated to RxJava2.x. As usual, I kept backward compatibility with RxJava1.x.

You can find more details about the project at https://github.com/pwittchen/prefser.

If you want to use it in your mobile project, you need the following dependencies in the build.gradle file:

dependencies {
  compile 'com.github.pwittchen:prefser-rx2:2.1.0'
  compile 'io.reactivex:rxandroid:2.0.1'
}

Short release notes can be found at https://github.com/pwittchen/prefser/releases.

This update was requested by at least two developers on GitHub and it’s my second most popular project, so I hope you’ll find it useful if you’re in the process of migrating from RxJava1.x to RxJava2.x. I still have 4 remaining RxJava1.x libraries waiting for the upgrade. If you want to perform any updates via Pull Requests, you’re more than welcome.

Releasing Prefser v. 2.0.7

2017-05-28 Android, DSP2017, Java, Open source No comments

I’ve recently released new version of Prefser. It’s a wrapper for Android SharedPreferences with object serialization and RxJava Observables.
The new version number is 2.0.7.

In this release, I performed mostly internal work not related to the external library API. Nevertheless, it’s important for the library development in the future.

The following things were done:

  • updated dependencies
  • updated Gradle configuration
  • migrated unit tests to Robolectric
  • started executing unit tests on Travis CI
  • added integration with codecov.io and coverage report
  • extracted code related to accessors from the Prefser class (refactoring library internals)

Organizational work is done and now I’m ready for migration to RxJava2 in this project on a separate branch. I want to keep backward compatibility with RxJava1 as in my other projects. This update is planned for version 2.1.0.

Stay tuned!

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.

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.

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.

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.

ReactiveNetwork – release v. 0.5.0

2016-07-24 Android, Java, Open source No comments

I have never thought that seemingly tiny thing like monitoring network connectivity on a mobile device can be subject to development for at least about one year!

I’ve recently released a new version of my project – ReactiveNetwork library – v. 0.5.0.

Highlights of this release are as follows:

  • added support for the new network monitoring strategy with NetworkCallback available since Android Lollipop (API 21)
  • kept backward compatibility of network monitoring with pre-Lollipop devices
  • added possibility to implement custom network monitoring strategy
  • made methods responsible for creating Observables static like in original RxJava project
  • added Preconditions class verifying correctness of the input parameters
  • changed API of Observable responsible for monitoring network from Observable<ConnectivityStatus> observeNetworkConnectivity(context) to Observable<Connectivity> observeNetworkConnectivity(context)
  • replaced ConnectivityStatus enum with Connectivity class containing info about network state, type and name
  • added more unit tests

You can read detailed release notes on GitHub.

I hope, this project will make your apps more robust and you won’t be surprised by incorrect network monitoring when your users will upgrade their devices to Android N. The newest Android version is not officially released to all Android devices yet, but it’s already supported by ReactiveNetwork library.

Setting up Android Studio on OS X

2016-07-05 Android, Apple, macOS, OS X No comments

Setting up Android Studio on OS X can be tricky. I had a strange problem with tools.jar file and I am not the only one.

After installation of Android Studio, when I started it up, I got an error, which looked like that:

'tools.jar' seems to be not in Android Studio classpath.  
Please ensure JAVA_HOME points to JDK rather than JRE.

jdk_required_screenshot

Luckilly, I fixed this problem and set up Android studio in the following way in my .zshrc file.

If you are not using ZSH, you should set it up in your .bashrc or .bash_profile file.

  # android
  export STUDIO_JDK=/Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk
  export ANDROID_HOME=$HOME/Library/Android/sdk
  export PATH=$ANDROID_HOME:$PATH
  export PATH=$ANDROID_HOME/tools:$PATH
  export PATH=$ANDROID_HOME/platform-tools:$PATH
  alias runAndroidStudio="/Applications/Android\ Studio.app/Contents/MacOS/studio"

Please, remember to set your version of JDK. If you have a different version than me, you need to change STUDIO_JDK variable respectively.

Complete source of my .zshrc file can be found here: https://github.com/pwittchen/dotfiles/blob/master/.zshrc

Then, I need to start Android Studio with the following command from terminal:

$ runAndroidStudio

Unfortunately, opening it via Spotlight or from Applications menu doesn’t work properly in my case. If you know, how to fix it, leave a comment below this article!

That’s it! With that setup, I can finally use Android Studio on Mac OS X.

ReactiveNetwork – new releases & roadmap

2016-06-10 Android, Java, Open source, RxJava No comments

Recent updates

I’ve recently released version 0.3.0 of ReactiveNetwork library for Android. As you can see in the release notes, it contains a lot of updates.
Highlights:

  • Deprecated methods related to monitoring WiFi Access Points and WiFi Singal level in favor of ReactiveWiFi project, which has this functionality extracted from ReactiveNetwork
  • Deprecated methods and enums related to monitoring connectivity with The Internet
  • Added Observables, which allows monitoring Internet connectivity basing on socket connection with a remote host (we can also monitor specific host with given parameters)

Roadmap for the future versions

Updates planned for 0.4.0:

  • Removing deprecated methods
  • Removing unused permissions from AndroidManifest.xml

Track progress of releasing 0.4.0 on GitHub

Updates planned for 0.5.0:

  • Updating library code with respect to the updates in Android 5 and 6 (especially ConnectivityManager) related to monitoring network connectivity mentioned in issue #62 on GitHub
  • Creating strategy interface to keep backward compatibility with Pre-Lollipop devices, so we’ll be able to monitor network in a different way depending on the given Android version

Track progress of releasing 0.5.0 on GitHub

Another future updates (not related to any version):
These updates are also important, but they’re not related to library API

  • Adding example of library usage with Retrofit (without breaking reactive stream chain)

Track progress of resolving this issue on GitHub

Final thoughts

Currently, it’s my most popular open-source project and people rely on it in production apps, so I’m trying to keep it as simple and as good as I can with respect to the recent updates of Android SDK. I’m getting really good feedback from people on GitHub and seriously considering it during the development process. If something bothers you in that project, don’t hesitate to create an Issue or new Pull Request on GitHub.