YoloYolo YoloYolo - 5 months ago 12
Android Question

Android: How do A/B testing platforms modify assets on the fly?

I was trying to figure out how does A/B testing SDK replace assets when sent from the Server by just including one line of Code. I know this can be done by sub classing various UI elements, but that will require a lot of code modification.

Answer

I'm the lead Android engineer at Taplytics. We do exactly what you're talking about!

At the core, its actually pretty straightforward. Obviously I can't go into full details on what magic we're doing, but I can give you a general idea!

First off, if you are the one building these A/B tests, I definitely recommend you subclass your UI elements. Doing this is far faster than other solutions, because it’s your code running when you want it to (I'll explain this later). The easiest way would be to subclass View and work from there.

The tech behind A/B testing is the same as pretty much any information you get from a server and present to a user. There really is no difference.

Now, to address your 'one line of code' comment, well, there's the secret sauce. On iOS, those devs are lucky enough to have method swizzling in which they can literally see when a method is being called and replace it with their own stuff. That makes things relatively easy!

But for Android? Well, no such luck. Take a look at the input params for every single A/B testing / Analytics platform on Android: Foo.start(AppContext, "apiKey");

The magic is in the AppContext. Appcontext is essentially an interface into Android itself. It’s what makes it Android instead of just Java. AppContext has information about everything: What activities are running, when they are running, what intents are being passed around, pretty much everything. With the AppContext in hand, you have a lot of control and information about the Application.

From there, you basically build an AppContext tree. Every little bit of information you need from the app just branches off AppContext. AppContext -> Activities -> Views. AppContext -> Activites -> Views -> Fragments -> Fragment Views. AppContext -> Services -> Push. Mixpanel actually calls this 'ViewCrawling' in their solution, which may give you a better mental visualization of what is going on.

You just create this big winding tree with branches reaching into every little aspect of the app so when you want to make a change to something, you are able to find it in your tree! Once you have what you want, you just grab the info from the server (or a local cache), be it JSON or XML or whatever and make the change you need based on that information.

But like I said previously, use your own UI elements. It's far easier on you to just determine what needs to change before even drawing the element. Especially if you subclass View, you shouldn't need a lot of code at all. The One-line installation is pure convenience and makes everything for me (the SDK dev) a lot harder. But I can't go and ask people to change every single view in their app to be a subclass of my own things, can I?

So there it is. It requires an intense knowledge of Android's SDK to be able to crawl into every aspect of it as necessary. The idea is simple, but deeper executions get incredibly complex.

I'm open to any questions! Thats a real rough overview of it all, and it gets more complex, so ask away.