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
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.
In my company, there’s a concept of so-called “innovation day”. I have the possibility to “use” 1 innovation day per 2 development sprints. Last year, I used only 1 day due to the tight release schedule and a lot of work. Now, we are right after release, so I had time to take innovation day once again. I’ve decided to create YaaS Java SDK. If you don’t know what the YaaS is, check out my previous article about Basic usage of YaaS proxy for the microservice. In a few words, it’s a proxy for the microservices with authorization & monitoring capabilities, which allows using other services available on the YaaS market. SDK created by me is really simple, was created in a short period of time and does not cover all features of the YaaS. This SDK allows performing authorized requests to the microservices hidden behind YaaS proxy.
Tech stack used for this project is as follows:
For unit testing I used:
I wanted to make this SDK as simple as possible so the user can add YaaS integration to the Java application within just a few lines of code.
YaaSProject project = new YaaSProject.Builder()
Client client = new YaaS(project);
.subscribe(response -> System.out.println(response.body().string()));
As you can see, it looks really simple and straightforward. In the code snippet above, we’ve done the following thigs:
- Defined YaaS Project with YaaS service
- Created YaaS Client
- Performed HTTP GET request to the endpoint of the microservice asynchronously
- Received and printed body of the HTTP response from the microservice on the current thread as a String
All of that was done with
Single type from RxJava2, which wraps
Response type from OkHttp. We have a reactive stream of HTTP response here and we can do with it whatever RxJava2 offers us. Like filtering, mapping, throttling, combining it with other stream and so on.
For more information, visit repository of the project at: https://github.com/pwittchen/yaas-java-sdk.
I have the following plans related to this project, which may be realized when I’ll have time:
- Add more unit tests (I didn’t have enough time to cover all cases)
- Add continuous integration
- Integrate YaaS with SAP Hybris Backoffice or SAP Hybris Core Platform through this SDK (PoC)
- YaaS Android SDK (copy YaaS Java SDK, downgrade it to Java 7 & optionally migrate to Kotlin and create sample mobile app)
- Optionally, add more features to YaaS Java SDK
- Optionally, deploy an artifact to Maven Central repository
- Optionally, create SDKs for different programming languages (especially those I don’t know well or I don’t know at all – just to learn them)
Interesting links related to this article:
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.
As few people might notice, I’m developing a few open-source projects right now. It’s not so easy to manage this stuff when you’re working in a full-time job, doing different not only IT-related things and don’t want to sit in front of the computer all the time. Nevertheless, doing this stuff really helps me to develop my programming & communicating skills and be up to date with various technologies. Instead of searching for excuses, I have the following plans related to releasing updates for my projects in the nearest future:
- Review reported issues
- Verify if reported bugs are real bugs
- Adjust code to recent RxJava2 features if necessary
- Handle Walled Garden issue OOTB
- Add more useful code samples
- Update existing code samples
- Release decent updates related to project configuration and updating dependencies
- Migrate project to RxJava2 as a separate artifact
- Keep backward compatibility with RxJava1 as in ReactiveNetwork project
- Review projects and their issues
- Perform new releases in the project with unreleased, but commited changes
- Handle users’ requests when possible
- Migrate all RxJava-based projects to RxJava2 while keeping backward compatibility
- Start new projects (which are currently drafts in my head/notepad/electronic notes/empty private git repos/etc.)
Moreover, I also have plans to learn a few new things not related to my ongoing projects, so that may slow down their development. In addition, I’m going to the conference this week and probably won’t be updating anything at this time. If anyone of you is interested in developing any of my projects, feel free to do it, go ahead and create your PRs! For sure, it will speed up the updates if you’re waiting for any of these.
While developing open-source projects it’s important to monitor usage of them. Having that information we know on which projects we should concentrate the most and which are becoming more popular. In this short article, I’ll present you two tools, which can help you with that.
On GitHub, each project has “Traffic” tab. After clicking on it, we can see how many visitors and unique visitors we have, we can also check how many project clones and unique clones were performed (including CI servers). Moreover, we can see referring sites for our projects. It’s useful information because we can check how people gather information about our project.
GitHub stats can be used for any type of project for any language. When we’re developing Java or JVM library and we publish it on SonaType, we can also use oss.sonatype.org website for monitoring usage of our libraries. It provides us quite interesting information, which actually tells us if anyone is using our library.
In the “Central Statistics” section, we can select
GroupId and also
ArtifactId. We can see accumulated information about downloads of all our projects in time and check, which project is the most popular. We can also view downloads from unique IPs. What I found interesting here is the fact that one of my projects called prefser is quite popular and people really started using it in their projects! Approximately 47% of downloads of all my projects are downloads of that single library. Nevertheless, the last release of this library (v. 2.0.6) was almost one year ago. It encouraged me to put more effort into this project and make it better. I actually started working on it again and planned new releases. Trust of many people is a huge motivation factor & honor for me.
Do you know any more methods of measuring usage of your projects? Maybe for different technologies than Java?
Share your experiences in 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
If you still want or need to use RxJava1.x, use the following dependency:
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.
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
- kept library compatible with RxJava1.x on a RxJava1.x branch and released it as
- 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
For RxJava1.x you can use old artifact id:
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.
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 :).
Recently, I created a tiny script called spotify-cli, which allows you to control Spotify on Linux from terminal. It’s inspired by shpotify, which is a shell script doing similar things, but on macOS. My script is written in Python and uses dbus under the hood, which allows to communicate with bus daemon to pass messages between applications. I used pactl for controlling the system sound.
You can install spotify-cli as follows via wget:
sh -c "$(wget https://raw.githubusercontent.com/pwittchen/spotify-cli-linux/master/install.sh -O -)"
or via curl:
sh -c "$(curl -fsSL https://raw.githubusercontent.com/pwittchen/spotify-cli-linux/master/install.sh)"
After that, you can just type
spotify-cli in your terminal.
You can use
spotify-cli with the following parameters:
--help, -h shows help
--status shows status (currently played song name and artist)
--play plays the song
--pause pauses the song
--playpause plays or pauses the song (toggles a state)
--next plays the next song
--previous, --prev plays the previous song
--volumeup increases sound volume
--volumedown decreases sound volume
That’s it! Happy listening!
Source code of the project can be found at https://github.com/pwittchen/spotify-cli-linux.
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
Preconditions class verifying correctness of the input parameters
- changed API of Observable responsible for monitoring network from
Observable<ConnectivityStatus> observeNetworkConnectivity(context) to
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.