Git is probably the most popular version control system nowadays. It has a lot of features that makes it suitable for many different workflows, even difficult ones. Maybe one of the most useful feature of Git is the ability to rewrite history, because this makes it possible to fix our mistakes in elegant ways – no need for “revert commits” and other stuff like that.
There are many wide-spread systems for dependency and build management. The officially supported build system for Android development is Gradle for a long time now. The build scripts (build.gradle files) used for assembling the modules are typically stored in version control systems. This post will show how to avoid storing passwords in these version controlled scripts.
UPDATE: I submitted a patch that fixes the issue and it was accepted. The bug should be fixed starting with build tools 26.0.0. This means that the workaround described here is not necessary when using build tools 26.0.0 or later.
This blog post will be short, because this issue does not affect the majority of Android developers, since it is related to Maven.
The title is the name of Item 17 from the second edition of Joshua Bloch’s Effective Java. I did not see the importance of this advice – or should we call it rule – until I ran into an issue during Android development that was caused by violations of this rule in the Android Framework.
This post will be about an interesting observation I made when working on a custom View that did not extend EditText, but contained one.
One of the new features introduced in Java 7 was the possibility to handle multiple exception types in a single catch block.
Starting with March 2014 (added in SDK Tools 22.6), this feature can be used for Android applications too when targeting Android Froyo or later.
However, in Android, there is a special case where multi-catch can bring trouble for the developers.
I knew that I would write a post about this phenomenon as soon as I met it.
Here is the story: during my work, I was assigned to fix a bug. The bug was the following: when navigating to a certain screen, the application crashed with ClassCastException saying that I cannot cast Linearlayout to FrameLayout.
I checked the layout file that was inflated, and the root element was indeed FrameLayout, making the error seem impossible. But then… what was wrong?
This is the second part of the blog post I wrote to help facing the problems that could arise when styling complex, composite Views. Now it is time to go further, and see a working solution!
Android provides two very useful features: styles and themes. Styles save you from repeating yourself in your XML layouts over and over again, while themes make it easy to adjust the look of your application without having to modify a lot of code.
Dear Readers,
First of all, thank You for visiting my blog and reading this introduction.
Let me first introduce myself: my name is Gyula Juhász, and I am a computer engineer. I work as an Android software engineer, and I love it – and computer programming in general.
The main goal of this blog is to share information and experience that may help some other developers and enthusiasts who try to create their own software and are struggling with a concrete problem.
The topic of the posts will certainly be programming and the first posts will probably be Android specific. The platform may change later, but the exact time of later is not defined yet.
Aside from the Readers, I may benefit from this blog too, because I can improve some of my skills by writing the posts. So – as You can see – I’m a little selfish here. 🙂
I plan to be an expert in my chosen areas some day, but I’m not there yet, so there is a possibility for my writings to contain mistakes. If that happens, and someone – maybe You, who are reading this right now – points out my mistake, I will gladly fix the wrong information. However, I hope these cases will be rare.
If You are still reading this, I wish that the title of the blog will be true, and You won’t regret that You ended up here. Welcome on board! 🙂