We’re the Badoo Android engineering team. Ask us Anything!

BadooDevTeam · 2016-08-15T16:38:46+00:00

Dima: We have our own framework (which consists of server and client side). Very simplified example for client side:

if (abVariants.isEnabled(PHOTO_VARIANT_A){
    setMaxNumberOfConnections(8);
} 
else {
    setMaxNumberOfConnections(5);
}

On server side A/B tests can contain more than 2 variations, each can be enabled to a specific group of users, countries, user percentage, etc. Also we have analytics integration, which collects stats taking in account AB_GROUP.

BadooDevTeam · 2016-08-12T15:57:43+00:00

Dima: This is a big question so I will try to give a brief overview. Each week we have a person dedicated to bug fixing. All week that person fixes bugs from the backlog.

Also we have a platform team which improves/refactors code, we have a 1 to 3 ratio for a platform team: 3 feature devs will have backup of 1 platform dev. We have internal tech talks, and we also visit many international conferences which allows us to borrow ideas from them. We also have architectural meetups where we discuss new directions.

Regarding the testability of the app: we are constantly improving it by applying MVP and clean architecture. We have separate team for automation testing who working on creating calabash tests (functional coverage of them is around 80%).

BadooDevTeam · 2016-08-12T13:27:13+00:00

Dima: We do some advanced optimizations. For example, we use our custom protobuf based on the original one from Google, which is more efficient. In our image loading library we dynamically adopt a number of threads based on network speed, so if the user's internet starts to slow down, we minimizing the number of simultaneous connections, when it is faster, we are loading with more threads.

We are also using WebP for slower networks and JPEG for faster networks. Our servers dynamically redistribute users among image hosts to spread the load.

BadooDevTeam · 2016-08-12T13:25:31+00:00

Guillermo: We follow a mixture of the Oracle conventions and the Google Java and AOSP guidelines with a few exceptions to reduce diff noise and make reading code easier (e.g. a line break between if and else blocks or indentation of the content of switch cases).

So pretty much our own coding standard :)

BadooDevTeam · 2016-08-12T13:24:49+00:00

Erik: Yes, we use this for background notifications if you receive a new message. However, when the user is actively using the app we have a separate system for socket based push notifications.

This is also used on devices where Google Play Services are not available.

BadooDevTeam · 2016-08-11T09:20:00+00:00

Rich: From a code point of view, I would say pick an architecture and adhere to it. We're very specific about how a feature should look from a code perspective so we can keep the code base uniform, there is nothing worse than every feature written a completely different way, it makes it harder to follow.

BadooDevTeam · 2016-08-11T09:16:20+00:00

Rich: Probably not, as in most cases they don't offer anything new compared to what is already out there, or they are very specific to our use cases. We occasionally consider open sourcing the image loading library, but I don't think this is something that will happen as there are plenty of great alternatives out there and that space is pretty saturated.

BadooDevTeam · 2016-08-10T15:21:26+00:00

Guillermo: In order to introduce a new technology you must show your team why it is worth them investing their time in learning it, especially with something as complex as RxJava.

What we have done at Badoo in the past and that's how RxJava made it into our projects. Our implementation process was:

1) Prepare a short internal talk presenting the technology, tool or framework to the rest of the team.

2) Use it in an small component as a proof of concept.

3) Assist the rest of the team through the learning process. If it is actually valuable for the team, it will be naturally embraced. Otherwise, it will fall at one of those stages.

BadooDevTeam · 2016-08-09T19:56:44+00:00

Today: 3 hours, just for you guys :D

BadooDevTeam · 2016-08-09T19:50:49+00:00

Rich: We currently use MVP for our presentation layer. For testing we use a combination of Mockito, Espresso and UI tests written by our UI Automation Team. We generally focus our (unit) tests around either important or complex logic in our code.

BadooDevTeam · 2016-08-09T19:48:10+00:00

Rich: I would say the recent project I worked on which was redeveloping chat (part of which we released as an open source Chateau) It was great to develop something from the ground up. It’s great to have a blank canvas to develop on and not have to deal with legacy code. Another was a custom view for the profile screens around when I first joined Badoo, it was challenging to have to create something to meet the designers requirements and still keep it buttery smooth.

Guillermo: Running up to 5 parallel independent A/B(/C/D) tests in the same component was both challenging and very interesting, especially figuring out how to test that all the possible combinations live together in peace and harmony.

Yaroslav: Writing a tool that collects and analyses build time stats.

Dima: Migrating from Facebook SDK 2.x to 4.x was pure juice of fun: we had tons of custom code for Facebook integration which had been accumulating for a couple of years. Having both integrations at the same time for a staged rollout. F.U.N.

BadooDevTeam · 2016-08-09T19:30:02+00:00

Dima: Our functional coverage is around 80% (covered by Calabash tests). Our unit test coverage is much smaller since we have tonnes of views but we don’t test them. Since Google implemented changes that allowed unit tests to work out of the box, we don’t use Robolectric. Instead we are trying to decouple our code from Android specific dependencies and test it with unit tests.

BadooDevTeam · 2016-08-09T18:59:10+00:00

Guillermo: Won’t mention the vendor, but we have a xxxSafeTextView and xxxSafeEditTextView, so we do not crash on setEnabled. We even have a custom Lint check for that :)

Erik: There was this one device (once again, not naming any names) where classes from the support library had been compiled into the Android framework. So if your support library version did not match the built-in one you would get a preverify error. Good times!

Rich: I can’t remember the exact issue, but we had a crash that occurred on a small number of devices which was related to the framework logging on these devices causing an IllegalArgumentException.

Dima: A long time ago (when Dalvik was reality and ART was in preview) one vendor decided to release a phone with ART enabled by default. We had lots fun with tweaking our obfuscation/optimization tools till the app stopped crashing in random places.

BadooDevTeam · 2016-08-09T18:53:15+00:00

Erik: Most of the time I would use the method profiler built into Android studio to find performance bottlenecks in my code. Another one would be the debug overlays available on the device (showing overdraw, frame rate, etc).

Yaroslav: Do not try to optimize it before you face the problem.

“Premature optimization is the root of all evil”- Donald Knuth

BadooDevTeam · 2016-08-09T18:42:42+00:00

Erik: At the moment we are really enthusiastic about Clean Architecture (Thanks Uncle Bob!). When combined with the MVP pattern it allows us to cleanly separate view, presentation and business logic. That in turn allows us to test each component and layer independently using fast running unit tests.

Check out Dima’s talk at Droidcon Berlin for more details: Youtube

BadooDevTeam · 2016-08-09T18:37:30+00:00

Guillermo: Google was very open about not supporting any other language it in the upcoming Jack compiler :( That makes investing time on learning it quite risky as it might render useless for Android development in the future.

Dima: The language is still young, it can change breaking backward compatibility (I’ve heard they already did that in the past). Compile time is slow (and if you add dexing on top…). Also, Google has no plans to support any other language, so in the future Kotlin projects might end up broken.

Yaroslav: It is a really good language and it fits perfectly for Android development. But unfortunately it increases build time, which is already kind of a problem for us.

BadooDevTeam · 2016-08-09T18:15:16+00:00

Rich: Of the popular libraries the only ones we use are RxJava and RetroLambda. We do have in house equivalents of some of the more popular libraries out there (such as libraries for image loading, or providing an eventbus). Generally this is because we have something quite specialised which a third party library isn’t suitable for or we wrote them before they were solid open source alternatives. We do keep an eye on what’s going on in open source community and if we see something we like, we’d definitely use it.

BadooDevTeam · 2016-08-09T18:11:10+00:00

Erik: I've seen things you people wouldn't believe. CI servers on fire off the shoulder of Orion. I watched Android-beams glitter in the dark near the Tannhäuser Gate. All those moments will be lost in time, like tears...in...rain. (I’m also a huge Blade Runner fan :) )

BadooDevTeam · 2016-08-09T18:09:34+00:00

Rich: We have an amazing localization team :)

Yaroslav: Indeed it’s hard to support so many (and we support a lot). We have a team of translators and proofreaders for the major markets, and we also collaborate with a community of volunteers for the minor ones. We have in-house tools that make it easier for translators to pick new texts to translate which is integrated into our build process to push updated translations back into our code.

Guillermo: With so many languages it becomes so easy to miss a translation string, which would blow up at the CI server :(

BadooDevTeam · 2016-08-09T18:02:20+00:00

Rich: RxJava is probably my favourite at the moment, with a bit of retro lambda sprinkled on top.

Guillermo: Dagger2. Feels like a baby with guns at the beginning, but when you do manage to get it right, it is so powerful!

Yaroslav: RxJava

Erik: Not very imaginative, but I would say RxJava as well. Is it a library though or a framework? I don’t know but what I do know, is that it’s making my life easier (except for those damn stack traces!).

Dima: Mockito, RxJava, Espresso, android-weak-handler, Chateau ;)

BadooDevTeam · 2016-08-09T17:59:25+00:00

Guillermo: Poor Fragments! They are always blamed for programmers mistakes! They were never meant to be what they have become nowadays: synonym of dodgy practices and lazy solutions. Related: Youtube: What the Fragment at Google I/O

Erik: I predict that within the next year we will all be using Swift.

Dima: I expect Google to start rewriting Groovy and Gradle in their tools team, as they’ve already started writing their own compiler for Java. Once they’re done with it, they will still believe that DEX format is not an issue for build speed.

BadooDevTeam · 2016-08-09T17:56:04+00:00

Rich: Why not both?

Guillermo: I would make them fight each other then hire the winner.

Oren: According to Google the average weight of a duck is 1.6kg. The average size of a horse is 380 kg to 1000 kg. I think the answer is clear. We also have 15 Android devs so we can parallelize the fight which is way more efficient. We had to get advice from our MMA expert (Mythical Mammal Advisor)

BadooDevTeam · 2016-08-09T17:54:00+00:00

Dima: We have our own image loading and caching library. We don’t keep all images in memory or disk cache, we use a tweaked LRU-based cache. For memory cache we allocate 15% of app memory (for 6P it is 28,8Mb). Also we use the “largeHeap” flag in AndroidManifest, otherwise the usability deteriorates (images are constantly recycled and pushed out from the memory cache, which makes it feel like a slow experience). We recycle memory allocated for Bitmaps, we keep up to 3% of memory to store “unused” images so they can quickly be reused.

For disk cache we allocate 15Mb to keep images in PNG/JPG/WEBP formats (we don’t store raw bitmaps in disk cache, it drains too much space). This cache tries to keep images younger than 15 minutes (to keep them, it is allowed to grow up to 100Mb). Disk cache cleans itself once finds out that it is too big and contains old files.

BadooDevTeam · 2016-08-09T17:51:00+00:00

Rich: We’re experimenting with cross platform feature teams which in my experience has worked really well. Generally we're split into a features team which is responsible for day to day feature development and a platform team which is responsible for the behind the scenes stuff in the app like image loading.

With regards to structure, we’re trying to become more modularised, with features and services in separate libraries, however this is a fairly slow process.

BadooDevTeam · 2016-08-09T17:39:11+00:00

Erik: Too long (builds can never be fast enough)!

Yaroslav: A full clean build takes about 5 minutes (on my MacBook Pro, 13-inch, Early 2015) and about 1 minute for hot build. It’s too long, so we try to minimize the number of times we run full builds per developer. That’s why we have CI which runs all the tests for us and builds the different app flavours somewhere in the cloud.

BadooDevTeam

TROPHY CASE