My Hexaville
Spead the Word

What I’ve Learned From Vue.js As An Android Developer

vue.js android developer

The company I’m working for is using Vue.js as a web frontend framework. I was taking care of implementing few features so I had to learn it. And here’s what I took from it that you can use as an Android developer

Frontend Frameworks

I’m not a web developer, I just took few courses on HTML, CSS, JS on Codecademy few years ago and just built few pages with jQuery. I’d never worked with any frontend frameworks before, so Vue was kind of like my introduction to frontend frameworks

And I know that it took a lot from React and Angular. So this post could’ve been called What I Learned From React or Angular and have same message to it. Simply because I was working with Vue.js

Like Data Binding

Vue.js is very like Android Data Binding, where logic goes into layouts (html/templates). And in some cases it’s even easier than Data Binding, because you don’t need to do any extra work for layouts to listen to data change

So it was very familiar for me to learn it

Object Oriented Design

It’s not something that you’d expect from JavaScript, but there’s those Vue.js components  which are just like Views on Android. Once again this is stuff was introduced in other frameworks before, but it doesn’t matter

Android framework itself is pretty well designed, but what could mess it all up is our code. Some god activities/fragments with 500+ lines of code. If you use Data Binding with layout data variables – then you already making a difference in design. If not – then keep reading, it still will be useful for you

So here’s what I leaned from Vue.js: Views are alive and can do stuff, they not some passive stuff that only takes inputs

What I mean by that? Let’s say there’s some repeating complex computation or even networking associated with some data that’s displayed with TextView. You don’t have to do all the work in activity/fragments. You can extend that View, create custom attribute and leave the work to your View

It takes so much pressure off your shoulders when you know that View knows how to do the work and display the stuff that you need with just some simple input. Especially when it repeats across different screens


Too vague, ain’t it? Let me give you an example with Firebase.  Let’s say we have a user model with fields: id, name, picture, email, age

And those users can comment under posts. So comment model has those fields: fromId, text, timestamp

Where fromId is user id. So let’s say you fetched all the comments for this post and what you want to display is user image, name, text and date

What you could do is just store all the needed user info inside of comment model, so your comment fields look like this: text, userPicture, userName, timestamp. And you don’t need to do extra networking. But it’s not the best way and here’s why: it’s a duplicated data and you should always try to eliminate that and it makes you database heavier

So what you would do is keep models as in images above and first fetch comments and for each comment fetch users. You see, with a real backend you wouldn’t care if data is stored in different tables, in response you’d get joined data, so it looks like one model

But with Firebase you’d get at least nested networking. I said at least – because if you display that in the RecyclerView – you’d ether have to wait for all users to be fetched and only then notify data changed or notify each item change when fetched each user. Or use RxJava

Ether way isn’t that pretty as it would’ve been with a regular backend.


So what you can do is delegate user fetch to that View that displays is. If it’s an ImageView – then all it needs as input is user id. You’d need to create a custom view and custom attribute, let’s say we called it UserImageView

So for your fragment/activity you just fetch comments and tell UserImageView userId and UserImageView takes care of fetching that user picture and displaying it

This way your code looks clean and Firebase networking doesn’t have any nesting

Inside RecyclerView

If your data is just statically displayed – then that solution would work just fine, but with RecyclerView, when ViewHolders data gets changed on scroll this will cause you to do networking each time. Since we didn’t cache fetched data anywhere

So my solution for that is creating static field inside of our custom View

This way you’d cache user images/whatever user data you need and you won’t do extra networking each time you scroll in RecyclerView. Plus this data is available across all UserImageView’s since it’s static

Binding Adapters

If you’re into Data Binding, then you know about binding adapters, with those you can create custom attributes for any view without the need of extending actual Views. So it saves you from creating custom classes in some cases

Expand Your Knowledge

And the last thing is if you’re getting started – then just focus on one platform, super narrow down

But when you have 1+ year of experience, it’s good to learn some different stuff just to have a better perspective on how other people write software and what’s going on in software in general

And it was just a simple example of how to improve your design if you use Firebase, with regular backend you woun’t even bother with that. But you could apply this idea in many more different ways. Let me know what you think of it, the question is – is it better than RxJava?

P.S. You can get source code here


About the Author Ihor Klimov

Formerly an Android developer, lately picked up some Flutter. This blog is everything that I find exciting about Android and Flutter development. Stay tuned and hope to see you again!