DEV Community: Vladimir Jovanović

[Boost]

Vladimir Jovanović — Wed, 21 Jan 2026 09:06:28 +0000

I profiled Claude Code so you don't have to, or How I Learned to Stop Worrying and Love the strace

vmitro ・ Jan 20

Firebase Predictions 🔮

Vladimir Jovanović — Fri, 22 May 2020 09:44:00 +0000

Firebase provides a wide variety of tools, something for every developer and something for every problem. But did you know that it has a tool that enables you to see into the future 🔮😮?! Yes, you heard me right, the tool called Firebase Predictions enables you to predict future actions of your users.

A lot of Android developers have never heard of Firebase Predictions or never used it, and this article will serve as a quick introduction. Apart from that, I will also explore some of the retention and monetization strategies that this tool makes possible.

To be able to start using Firebase Predictions you need to have Firebase Analytics integrated into your app. What Firebase Predictions does, is apply machine learning on your analytics data and create user segments depending on how likely those users are to execute a specific action within the next 7 days. In other words, for every analytics event, it can give you a group of users who are most likely and a group of users who are least likely to execute that event.

Now armed with that knowledge, you can react to your users’ anticipated actions and needs using other Firebase tools and always stay one step ahead.

You have the option to use Remote Config and adjust user experience for specific user segments, or to use push notifications and in-app messages to inform those users about new deals tailored just for them.

Retention and Monetization Strategies

The best way to present the power of Firebase Predictions is on an example. Let’s say that we have an app that is selling something. That can be a product, subscription to a pro version of the app, or in-app currency. And let’s say that we are tracking this purchase event in Firebase Analytics.

Using Firebase Predictions we can assign the value to the users on how likely they are to make a purchase in the next 7 days. Knowing this, we can start adjusting the behavior of the app for those users.

If the users are not likely to convert, we can explore other monetization strategies, such as for example ads. So using Remote Config we can show ads to those users. If the users are a bit more likely to convert we can try nudging them by, for example, sending them vouchers using push notifications and in-app messages. And if the users are super likely to convert, we can just leave them alone, and make sure that they are not disturbed by ads and push notifications.

In a similar way, you can also employ a user retention strategy. The only difference is that, in this case, you would run a prediction on the app removal event and adjust the user experience depending on how likely the users are to uninstall your app.

Finally, you can run Firebase Predictions on any event, and since every app is unique make sure to explore different ways to improve your application using Firebase Predictions.

Now you’re probably thinking: “This Firebase Predictions thing sounds amazing. So what’s the catch? How much does it cost?” The best thing about Firebase Predictions is that it’s completely free, and you can start using it today.

If you would like to learn more about Firebase Remote Config check out my Pluralsight course: Firebase on Android: Remote Config and A/B Testing

Thanks for reading! If you enjoyed this story, please share it! Also, feel free to leave a comment 💬 below.

/* intentionally left empty */

Vladimir Jovanović — Wed, 20 Mar 2019 09:44:00 +0000

A long time ago somewhere in India empty spaces were creating a lot of problems. Numbers were being written without zeros, and believe me, it’s hard to write numbers when you replace zero with an empty space. 11 and 1 1 looked almost the same. That’s why zero was created.

In its early beginnings, zero meant “intentionally left empty”.

Let’s now travel back to the present, and see if empty spaces are causing trouble in the life of an average software developer. There are probably places in your code base where it’s not clear if something is a mistake or if it was left intentionally empty. Sometimes we don’t need the implementation of initialize() in every child method, so we would just create an empty implementation instead of an abstract method.

I know that comments are not great, but in this case, I would suggest adding them. With the added comment, there is no confusion whether the empty method is a mistake or not.

Another example when we need an empty method is when we want to omit the behavior of the parent’s implementation. This clearly breaks Liskov substitution principle.

However, sometimes you can’t control all the code that you are using, so you have to make compromises.

Then, there are those notorious listener implementations, with a lot of methods that are usually not needed. Here is one example from the Android world:

Finally, when working on a new feature, you can’t build it all at once. Inevitably, you will have parts of the code that are unfinished. This is not really a problem, it just needs to be clearly marked as unfinished with a simple TODO.

Please don’t leave your methods empty. If the method is intentionally left empty, simply leave a comment for your fellow developers or for your future self.

Thanks for reading! If you enjoyed this story, please click the ❤️ button and share to help others find it! Feel free to leave a comment 💬 below.
Have feedback? Let’s be friends on Twitter.

tools:title=”RemoteSampleData”

Vladimir Jovanović — Sat, 10 Mar 2018 09:44:00 +0000

What I’ve learned from my previous article is that the best way to gain new knowledge about a certain topic is to write about it. When I first wrote the article, I had no idea that you can create custom sampledata for your Android project. (If you don’t have a clue what sampledata is, please read tools:title=”LayoutPreview”) And then someone sent me this.

It sounded like a really cool feature, so I made the list of my favorite characters from Lord of the Rings, used it as sampledata, and got this glorious layout preview.

Later on, I wanted to include it in my other projects, but the only option that I had was to copy/paste the sampledata from one project to another, and that didn’t make any sense. Then I did what every (lazy) developer would do, asked a question on StackOverflow.

After 10 views and no answer in sight, I’ve decided to sacrifice a bit of my reputation and start a bounty. And it worked. I got my answer, which I will share with you.

To use sampledata between multiple projects you first have to host it and then have a Gradle script which will download it into your project’s sampledata folder. This is the code which does that:

The first script will delete sampledata once you do a clean build, and the second one will create sampledata folder in case it doesn’t exist, and then download sample files into it. It works like a charm and from now on you can go crazy with your layout previews. I know that from now on I will never again use @tools:sample/lorem/random.

This code can be found in GitHub repo.

I’ve also added some sample data and will keep adding more. If you notice that something is missing or could be improved, feel free to contribute. This could be a great opportunity for novice developers to make their first contribution 😉.

Thanks for reading! If you enjoyed this story, please click the ❤️ button and share to help others find it! Feel free to leave a comment 💬 below.
Have feedback? Let’s be friends on Twitter.

tools:title=”LayoutPreview”

Vladimir Jovanović — Sun, 18 Feb 2018 09:44:00 +0000

As every Android developer, I also started building my layouts by hard-coding values into them. Later on, I have realized that I should probably extract them into resources. Next step was not to have values in layouts if they are going to be changed from the code (always keep the state of your view in code). But at that point, my layout preview got broken. The layouts were full of TextViews without texts, ImageViews without images, etc. And then I discovered the power of tools:. Fast forward one year and I had layouts full of tools:text="Test text", tools:text="Jake Wharton", tools:src="@drawable/ic_random_res" … you get the point. Is there a better way to do this, you may ask?

Actually, there is. And it’s pretty easy. There are predefined sample resources that you can use to make your layout preview nice and clean. By using these, we can go from this:

to this:

And why is this better? If your TextView is inside a repeatable element like, for example, an item inside RecyclerView, and you set up your preview correctly, then your TextView will have a different text in every item. Speaking of RecyclerView, let’s make a deep dive into making a preview of your RecyclerView as sleek as possible, using this and some other tricks.

It all starts with a normal and rather ugly RecyclerView in your layout XML file. In a preview, it looks like this:

It would look much nicer if we could show the real item used in our RecyclerView, and even more so if that item uses sample texts tools:text=”@tools:sample/lorem” and tools:text=”@tools:sample/lorem/random” for TextViews inside. And as a result, we get the following preview:

It looks much better, almost like a real application. The only problem is that our application in horizontal orientation has GridLayout with two spans. Can we do something in that regard? Of course, we can. By adding tools:layoutManager=”GridLayoutManager” and tools:spanCount=”2", we are getting exactly what we want.

Well, almost. Our Activity has some menu items in the Toolbar, and if we could display these as well, it would be perfect. Accomplishing this isn’t really that difficult. Simply adding tools:menu=”menu_test” to the root element of your layout does the trick. It’s important to know that for this to work you need to have predefined menu item @menu/menu_test.xml, and your Toolbar needs to be defined in a theme and not added in layout’s XML. The final result looks like this:

The final code looks like this (minus some margins, styles etc., that are removed to make it a bit more compact):

As you can see, tools: gives you great power to prototype and experiment with your layout without writing a single line of Java or Kotlin code or adding unnecessary states to your view’s XML. If you start using it now, you will have a much more pleasant time developing UI on your new project, and it will be a breeze to modify it later on.

Documentation for all tools attributes is available here.

The full source code of this and some other examples can be found in the GitHub repository.

Thanks for reading! If you enjoyed this story, please click the ❤️ button and share to help others find it! Feel free to leave a comment 💬 below.
Have feedback? Let’s be friends on Twitter.

PRObably the Language Of God

Vladimir Jovanović — Tue, 24 Oct 2017 09:44:00 +0000

During my university days, when I was studying Mathematics and CS, software development was a refreshment of applied science in a sea of theoretical math. But then in my 4th semester came Prolog. For those who hadn’t heard of Prolog, it’s the most inapplicable programming language in the universe (at least that’s what I thought). Created in the early 1970s, it was one of the first logic programming languages. It’s the most mathematical thing in the world of computer science.

Seven years after my first encounter with Prolog, I found some old .pl files, I opened them and was amazed that at one point in my life I had understood and more surprisingly had written those lines. So I decided to take one week of my life, and check again if Prolog is worth learning in the 21st century. At that point, I created GitHub repository, downloaded Prolog compiler, and started.

The main building blocks of Prolog code are facts and rules. A fact is something like an axiom, a statement that is taken to be true. Meanwhile, a rule is analogous to a theorem, and its truthiness can be derived from facts.

These are the examples of a fact and a rule. The next step would be to load a file containing facts and rules into Prolog and make queries on it. For this case, the examples of queries would be:

?- guitarist("Saul Hudson").
true.
?- musician("Saul Hudson").
true.
?- guitarist(X).
X = "Saul Hudson".

As you can see, guitarist does not behave like a function. That’s because it’s not a function, it’s a relation. Prolog is a relational programming language. To better explain this, let’s take a look at the following example:

factorial defines a relation between some natural numbers. What does that mean? The fact factorial(1,1). means that 1 is in relation factorial with 1. And what about the second line?! Well, it can be read like this: “Numbers N and R are in relation factorial if N>1 and N1 is N-1 and N1 and R1 are in relation factorial and R is N*R1” 😧. Could that be expressed in an understandable way?! In practice, it means that if you query this set of rules, you can calculate factorial.

?- factorial(5,R).
R = 120 .
?- factorial(1,R).
R = 1 .
?- factorial(20,R).
R = 2432902008176640000 .

These are a couple of beginners examples of Prolog code. I hope this is sufficient to show you how Prolog works, and what it has to offer. If you find this interesting, and if you are curious enough to do something on your own, feel free to add it to the repository.

So, should you learn Prolog? Well, it’s the 21st century, and you should be learning whatever you can find on the internet. But seriously, is it worth learning? I think it is. It’s a niche concept that never really took off, but it somehow feels fresh and modern. For you, it will probably be a totally new approach to software development, that will get you out of your comfort zone, and force you to think in a different way while giving you another perspective on how software can be written.

Thanks for reading! If you enjoyed this story, please click the ❤️ button and share to help others find it! Feel free to leave a comment 💬 below.
Have feedback? Let’s be friends on Twitter.

Variable looked at me and said: “Say my name!”

Vladimir Jovanović — Tue, 17 Oct 2017 09:44:00 +0000

While I was learning basics of programming at my high school, I was being taught how to solve problems: sort an array, reverse a String, convert Roman numerals to Arabic, etc. It was never expected from me to write code that would be altered or checked by another person. Usually, it was enough for the code to work, and to return correct output for a given input.

Some years later my university days started. I studied Mathematics and CS, and on my first CS exam I did all tasks, I tested them, and they worked, so I was expecting my first A+. But I got a B. I ran to my Assistant Professor’s office to tell him that he had made a mistake.

I came to him, all confident, and said: “I saw the exam results, and I think you have made a mistake. I am sure that my code works as expected.”
“Yes, it does,” he answered.
“So why did I then get a B?”
“Because it took me 60 minutes to see why it worked.”

And why is that, you may ask?! Well, the longest variable’s name in my code had two characters in it, and its name was s1. At that point, I realised that from that day on, my code would be read by others, so I started commenting it.

As you can see, I learned some things the hard way, but you don’t have to.

Let’s start from the beginning. Why do we need a variable’s name longer than one character? Because, usually, code that you write professionally will be read by someone else, or worse, by you, one year later. Maybe while you are writing it, it’s all clear to you. But that isn’t because your code is clear and easy to understand, that’s because you have just written it.

Whenever you feel the urge to put a comment over your variable declaration, think about giving your variable a more descriptive name. The main problem with the comment that describes your variable is that it will be at one place in your code, and your variable will be at multiple locations. A developer that reads your code at a later point in time will need to constantly convert vn into variableName in his mind while trying to understand the code.

Do not expect that giving your variables longer names will automatically make your code better. Naming is hard, and it will take you much more time to find a decent name for your variable than to write a comment.

“There are only two hard things in Computer Science: cache invalidation and naming things.” — Phil Karlton

Some of the basic principles to follow when naming your variables are:

Use pronounceable names for all variables. dayMonthYear is a much better name than ddmmyyyy.
The name should tell you what the object does, instead of how it does it.
Names should be meaningful within their context. name is a pretty good variable’s name inside class User.
Be consistent. Most words have synonyms. Pick one and use it throughout your project.
Use a name that is as short as possible, but descriptive enough. Use birthday instead of dateOnWhichUserIsBorn.
Don´t use negative logic for your variable’s name. Use isEnabled instead isNotEnabled.
Whenever you have two variables that differ just by number, refactor your code immediately.

In some cases, variables can and should have a short name.

If a variable represents a loop-count, its name should be i, or j for the inner loop.
In a function where arguments traditionally have a one-char-name.
Sometimes it’s really hard to explain a variable’s purpose inside its name, and in that case, you need to write a comment.

While you are writing your code, the most important thing to have in mind is that you are writing your code first and foremost for humans to understand, and secondly for a machine to interpret. Therefore, when your code works and does what it’s meant to do, spend a couple of minutes and make it easier for human beings to understand.

Thanks for reading! If you enjoyed this story, please click the ❤️ button and share to help others find it! Feel free to leave a comment 💬 below.
Have feedback? Let’s be friends on Twitter.

Handling configuration changes using static references

Vladimir Jovanović — Mon, 09 Oct 2017 10:44:00 +0000

When writing about the preservation of data on configuration change, there are two cases to cover. First, if there is a fixed number of small objects that need to survive change, use onSaveInstanceState, and that’s it, end of story, problem solved. However, the real problem comes when you need to preserve big objects whose size is unknown. There are a couple of correct approaches to this problem depending on your requirements. But that isn’t what this text is going to be about. This text is going to be about one pretty popular and rather wrong approach. We all know it is a bad one, but not all know why. The internet is full of questions on this topic, and a couple of days ago I also got asked about it.

What if you hold a static reference to the data in my Activity to preserve them on screen rotation? Why is that bad?

“Don’t do that, it’s bad! Memory leaks! Danger! 🚨” was my first reaction. But then he/she said: “Yeah, yeah … I know, but I will be super careful, and I will hold only data, no Context, or anything that has reference to the Context. Is it still bad?” You can bet it is! But that got me thinking:

“Why is it still bad?”

Why is it bad to have a static reference to some data inside your Activity? I was thinking for some time and then 💡.turnOn(). It’s bad because of 🥁🥁🥁 memory leaks.

However, this is not your classical Java/Android memory leak that Leakcanary will warn you about. This leaked memory can still be accessed, and although it is not needed anymore, the OS can’t do GC on it. The main problem with having a static reference to an object inside an Activity is that it’s really hard to know when to release it.

Think about it. You can’t do that onDestory(), because you need your data to survive a configuration change. Should you do it when the next Activity is opened? Maybe, but probably not, because you will need those objects when you come back to that Activity. So, when should you do it then? Well, you shouldn’t! Android should take care of it, and remove it from memory when there is no free memory left. But it can’t because you have static references to those objects. In the end, the OS will remove it from the memory in the only way it knows how, it will kill your application.

And at some point, on some device, that’s exactly what’s going to happen. You will get OutOfMemoryException, and your application will crash. Just to be clear, next step should not be adding android:largeHeap="true" into your AndroidManifest.xml. It should be fixing your application. You can read more about proper handling of configuration changes here.

To sum up, having static references to objects is really dangerous, and it’s even worst to do it inside the objects which have a lifecycle such as Activities, Fragments, Services etc. Please use your static variables responsibly.

Thanks for reading! If you enjoyed this story, please click the ❤️ button and share to help others find it! Feel free to leave a comment 💬 below.
Have feedback? Let’s be friends on Twitter.

Short methods FTW

Vladimir Jovanović — Mon, 02 Oct 2017 22:44:00 +0000

Some 5 years ago, I got my first intern job in a small startup. We were building a computer vision prototype in Matlab, and my assignment was to write C/C++ code that was supposed to do different types of transformations on video frames. I wrote a 300-lines-long monstrosity of a method that was doing all kinds of transformations and calculations on a matrix. It worked, and I was happy. Then my boss came to me and said:

Every method that you write should be less than 25 lines long.

And I laughed, I laughed hard, right in his face. I was such a plonker!

And let me tell you something, 25 lines make one big, long method. Actually, most should be much shorter, around 10 lines, maybe even less. 25 lines should be the upper limit. And why is that?! Well, here are some of the reasons:

First of all, it fits easily on your screen, so it’s easy to read.
Its purpose can be expressed in one simple sentence, and that makes it (in most cases) easy to understand.
It doesn’t need comments, becauseit does only one thing, and that thing can be described within its name.
It’s easy to test.
And lastly, because Uncle Bob said so.

“The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.” — Robert C. Martin

However, not all short methods are good. For example this one:

Long method bodies are a classical code smell: it’s not in itself a problem, but it’s an indication that there’s probably a problem there. — Joachim Sauer (has nothing to do with this Joachim Sauer, I think 🤔)

One thing that’s mind-boggling is that the vast majority of developers knows that the long methods are bad, but very few actually follow this rule. Quite often, I see good developers writing huge methods because “It’s a UI” or “It’s in a test” or “It’s Java ✋”. And at first glance, it doesn’t look that bad. Code is well organised and each line logically follows the previous one. That’s because the developer who has just written that code has its context and understanding in his head, so he doesn’t need to get it from the code. When another developer tries to change that part of the code one year after it’s been written he/she is …

going to fail. Why?

Because there is no time to invest in proper analysis of that method. (New feature needs to be done by yesterday).
There are no tests to support refactoring. Not because it’s hard to cover a 100-lines-long method with tests (btw. it is hard), but because it’s much easier to split it into 10 methods, and write tests for each of them. Therefore, there is a good chance that that person didn’t even try to test it. And if he/she did, it’s likely that our developer would be making changes on 10 short methods.
Misleading comments are everywhere. First of all, there has to be at least a couple of comments in a long method (it’s really unprofessional to write a long incomprehensible method without comments 😄). And it’s quite probable that code has already been changed, but developers are really scared of changing other people’s comments, so comments will stay the same. They will be sitting there, telling you a story of some other badly written code.

So please, for the love of Uncle Bob, write your methods short. P.S. I promise that I will refactor long methods in my projects on GitHub. 🤞

Thanks for reading! If you enjoyed this story, please click the ❤️ button and share to help others find it! Feel free to leave a comment 💬 below.
Have feedback? Let’s be friends on Twitter.