I recently got the task to implement a change log dialog to inform our users about changes. There are some requirements like showing the beta user more details than the regular user etc. There was a lot of discussions and our project manager loved the change log because he feels it transports important information.
Recently I saw a new post in this rarely updated Android Studio Tips of the Day collection.
While working on cleaning up build scripts and smoothening the complete build process from testing to generating release version, I stumbled upon some libraries we use that are published in a way that makes our life as developers harder than it has to be. I will not name libraries that do that. I don’t play the blame game.
This post will guide you from scratch to a (nearly) full features static code quality analysis using SonarQube, JaCoCo and UnitTests with Junit. As most tutorials out there are quite outdated, this one will give you a basic ground using the latest versions of mentioned tools and plugins.
When making a game or application you may want a fully immersive UI to enhance your user’s experience. The main components that will prevent this are the Status Bar (the strip at the top with notifications and time) and the Navigation Bar (the strip at the bottom with the back, home, and recent apps buttons). Let’s walk through how to manipulate these programatically.
Searching on the internet how to publish a library into jcenter() can put one into trouble. One may even find himself trapped into a spider web of gradle scripts, build configs and ./gradlew commands. fear not, CptEric has a solution to this.
In this post, a simple method to navigate in Google Streetview while using Google Cardboard is presented. It makes use of the automation tool Tasker and the touch input record/replay tool RepetiTouch Pro (requires root) although probably for both apps free alternatives with the required capabilities exist.
Various Preferences available in Android make the maintenance of settings straightforward. Even custom Preferences, e.g., for colors, can be created without much effort. By defining PreferenceScreens via XML, default values for each Preference can be set. However, parsing and type conversions of these default values can lead to unexpected and undesired results.
ESP8266, in it’s default configuration, boots up into the serial modem mode. In this mode you can communicate with it using a set of AT commands. I will present to you a reference of all known AT commands that ESP8266 supports, explain what they do and how to use them.
ESP8266 is a wireless SOC (System On a Chip) manufactured by Espressif Systems. It is extremely integrated and requires few external components to run. If used in any of it’s modularized form, number of external component can go down to zero (that is if you can figure out how to power it from thin air) ;)
One of the articles that I read, while researching how to write good UI tests was this one. And one of the most profound ideas from that article was:
First off, the method described in this post only works on Android versions up to 4.3. The behavior which allowed this was changed in Android 4.4. Still, at time of writing, nearly 50% of all Android devices run Android 4.0-4.3. Thus, especially devices which likely won’t receive a system update can benefit from apps using the method described here.
Note: Espresso has moved to a new website, and thus some of the criticism below is out of date.
Material Design has been around for quite some time now, and many apps are adopting the new design. Not only apps, but many websites are doing that too. But there’s a difference between an app and a website. For example, websites can’t change the color of the Action Bar (of the browser). But now, it turns out that Google Chrome supports this.
Recently I stumbled upon an article that argued against the usage of the “m” prefix. I would like to provide an answer to that argumentation and why we should stick with this prefix.