Hi everyone! About six months ago we launched one of Badoo’s most exciting features: Live Streaming. One of its main functionalities is that viewers can send gifts to their favourite streamers to express their appreciation. We wanted to make the gifts as fancy and as engaging as possible, so it was decided to make some of them really lively, and by this I mean animated. And to engage people even more, we, the Badoo team, planned to update those gifts and animations every few weeks.

As an iOS engineer, you might have already guessed the challenge we faced here: the need to add new animations and remove the old ones was going to require a fair amount of work from the client side. We’d need both the Android and the iOS development teams for every release — which, when combined with the amount of time App Store reviews and approval often take, would mean it might be days before each update could go live. But we solved the problem, and I’m going to explain to you how.

Solution overview

By this stage, we already knew how to export Adobe After Effects (AAE) animations into the format readable by our iOS app using the Lottie library. This time though, we went a bit further: we decided to create a kind of animation storage service, available via the internet. In other words, we would store all the actual animations on the server and deliver them to the client apps on demand:

Here is what the final solution looks like in the iOS simulator on the developer’s machine:

However, in this post, the example I’m going to use is a very simple animation that I created myself. It’s not as fancy as Badoo’s one, but it’s good enough to demonstrate the potential of the described approach.

Exporting animations

The Adobe After Effects (AAE) project of animations I’m using here can be found along with other source files on github. So, after opening the AAE animation project located in _raw/animations/Fancy/Fancy.aep, you should see a window like this:

At this point, I’m not going to go into how animations are being created in AEE, but what I’m going to explain is how to import already existing animations from AAE into an iOS app-readable format using the Bodymovin plugin.

Having made sure the plugin is installed, open it by selecting the Window/Extensions/Bodymovin option in the menu:

Now you should see the Bodymovin window where you can select the animation you wish to export, specify the output file path and then open export settings:

Having selected and opened animation settings, we can now ask Bodymovin to embed the assets into the resulting JSON file by checking the Assets / Include in json option:

Finally, the selected animation composition is exported and saved to the specified file by clicking the Render button.

Storing animations on the server

Let’s assume we have moved our rendered animations JSON files onto our preferred web server via the Internet. In our case, for simplicity’s sake, I’ve uploaded them into this project’s github repository. The animations are available here:

• Clouds animation
• Firework animation

Base URL:

• https://raw.githubusercontent.com/chupakabr/server-provided-animations/master/_raw/rendered-animations/

Animation-specific IDs:

• clouds.json
• fireworks.json

Note: Looking for an animations provider web server written in Swift? Find the solution here on github and a detailed explanation in this article.

At this point, we have a fully-functional animations-provider server, so it’s time to move onto the most exciting part: presenting the animations to our users.

Fetching and presenting animations

At this point I strongly recommend opening our example iOS app project located at Client/ServerProvidedAnimation.xcworkspace as it already has all the necessary boilerplate code and configurations.

Loading animations data

Given that the REST API endpoints for obtaining animation data are now up and running, it’s time to introduce the data provider protocol and add its server implementation:

This data provider class allows us to load animations from the server in JSON format on demand and hold them in memory for rendering on the UI. Assuming we are following the MVVM pattern, it can easily be used in the ViewModel entity in the following way:

The ViewModel updates the selected animation data property when it receives a valid HTTP response from the server with a non-empty JSON object inside. This data is used by the presentation layer to schedule the animation rendering.

Presentation layer

Now we can use our ViewModel to access the animation data and present it via the UI in the “on tap” action handler attached to the button:

Basically, what we have here is a button handler which triggers an update of the LOTAnimationView instance with the most recent animation data coming from the ViewModel.

Here’s what the final result looks like:

That’s pretty much it. Animations are now being loaded from the prepared REST API endpoint and rendered on the client on demand.

Tips & Limitations

Tips and tricks:

• AAE allows the use of most asset types including raster and vector graphics;
• Bodymovin makes it possible to embed all assets into an output JSON animation file (using base64 encoding) — this means we can avoid separate assets loading on the client side;
• For the animations, you have the choice between drawing straight into the vector in AAE, or simply importing Adobe Illustrator vector graphics.

Unfortunately, it’s not yet possible to import SVG vector graphics into AAE (I’ve tried!).

More tricks and potential problems are described in this amazing article written by my colleague Radoslaw Cieciwa.

Conclusions

So, what does using server-provided animations give us? The most obvious benefit of this approach is the ability to decouple all stakeholders of the animations update flow. In other words, to release a fancy new animation, all designers have to do is to provide the animation’s JSON representation to the server team. And to remove one, the server team just has to remove that particular animation from the discovery service. No time wasted!

Another cool thing is that the same functionality can be implemented on all supported client platforms (iOS, Android, Web,..) without having to adjust the existing server functionality or raw animations.

That’s it for today! Thanks for reading 🙂

Resources

• “Behind the scenes with importing Adobe After Effects animation into Badoo iOS app” by Radoslaw Cieciwa;
• Bodymovin plugin for AAE by AirbnbEng;
• Full project is available here on github;
• Installing bodymovin plugin for AAE by AirbnbEng;
• Lottie iOS library by AirbnbEng;
• “REST API with Swift on Vapor” by Valerii Chevtaev;
• ZXP plugin installer for AAE.

Server-provided animations in iOS apps was originally published in Bumble Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Good day everyone!

Recently I was in need to have a server-side storage with some kind of a discovery service for my JSON data files. So I was tearing myself apart:

• One part of me, as a server-side engineer, was pushing towards having the files stored on Amazon S3 with one more JSON file as a discovery information for the available data;
• Another part of me, as a client-side engineer on iOS, was craving to find some web server framework in Swift and play with it.

After a bit of fighting with myself, I decided to come up with this post due to the following facts:

1. Lately I’m mostly busy developing iOS apps in Swift;
2. I’m actually very keen to see how different is Swift on the server in comparison to more traditional server technologies like Java, JavaScript, etc.

In this post I’m going to implement a simple REST API web server which is able to provide JSON data identified by unique ID, in our case a piece of data will be represented as an animation exported from Adobe After Effects (AAE) as JSON (read as “some JSON object”).

So let’s begin!..

Preparation

After having a quick read of this quite interesting article about most popular Swift based web frameworks such as Kitura, Perfect and Vapor, I decided to go with the latter one due to its rapid development nature aka Ruby on Rails and active community around it. Mind though — I don’t say it’s the best choice.

So let’s create an empty Vapor project. First we need to install Vapor framework and its command line tools following this guidelines.

After we have Vapor installed, creating new project is simple as running the following command in Terminal:

$ vapor new AnimationsProviderServer

It’s also useful to generate Xcode project for easier development of our server:

$ vapor xcode

At this point we should have Xcode project ready to be opened and even ran!

The server will be available on default 8080 port, so you can open “http://localhost:8080” URL in your browser and check if it works.

Short remark: Vapor doesn’t support “hot reload” feature out of the box at the moment of writing this article, but it’s possible to set this up via gulp-vapor package available here on NPMJS.

Voila, now let’s code a little bit!

Data model

Now it’s time to add some logic to the server. Let’s create a model entity to hold information about our animations, for now everything we need to represent an animation is to have its identificator and JSON data exported from Adobe After Effects (AAE). So the animation model may look like this:

Next we need to import animations into the project, to do so simply drag and drop JSON files exported from AAE into Resources folder of the server Xcode project, the project hierarchy should look like this:

Note: Make sure the imported JSON files are added to the “App” target.

Data storage

Somehow we need to access imported animations resources, to achieve that we may want to implement some kind of a storage entity, let’s call it AnimationsStorage:

In order to make AnimationsStorage service available in Vapor controllers, we should register it in configure.swift file:

Basically, treat configure.swift file as source of information about all available global services, utilities, etc.

REST API

Next let’s create a simple controller which returns requested animation by ID as JSON via HTTP GET:

The last step for the server project is to add required routing rules, so the animations are accessible via HTTP. Vapor framework has a separate file for specifying routing tables called routes.swift, in our project it should look similar to this:

Now we have fully working animations provider server, which could be requested by URL via HTTP GET, for instance:

• Fireworks: http://localhost:8080/animation/fireworks
• Clouds: http://localhost:8080/animation/clouds

Requesting unavailable animation will result in 404 HTTP code with an empty body.

Note: at this point you may want to restart the web server to make all the changes we’ve made to the code available via REST API.

Conclusions

So we made it to the end! We’ve gone through the process of creating Vapor project from scratch, adding some business functions to the server, deploying and making it available via HTTP.

I wouldn’t say that Swift on Vapor sold me the idea of using it for implementing server solutions after I got to know with such server oriented technologies like Java and Go. But Swift is evolving, and evolving fast, so I’m very curious to see how it will pass the test of time, and what business applications Swift will have apart of client-side development for Apple platforms.

Meanwhile to me it looks like Swift on Vapor is a great starting point for those iOS/macOS engineers who want to become more familiar with server development concepts using the language they are already familiar with.

Thanks for your attention :)

Resources

• “Hot reload” with gulp-vapor.
• Server source code is available here on github;
• Server-side Swift Frameworks Comparison by Robert Abramczyk;
• Vapor documentation;
• Vapor framework.

Hey there!

About 3 years ago from now, at my previous job, I had an opportunity to solve very interesting and to some extent complex problem: implement a solution for processing and analysing Big amounts of Data on daily basis, providing all the needed information to our higher management on demand. Here by “Big amounts of Data” I mean the average value of 1 TB of raw data per day.

First solution

At first, we implemented non real time solution utilising the power of Hadoop and Hive (HiveQL) via Amazon Web Services (AWS). By that time we already had most of our services deployed on AWS, so we decided to go with Amazon this time again.

The main idea was to feed raw data stored on S3 into HDFS (Hadoop), then run HiveQL queries on that data to generate required data reports and then wipe the whole thing out as the maintenance costs of running Hadoop cluster was quite high and there is no need to keep it alive anyway.

The solution was solving the business problem we had initially, but in the end we had to play around the running costs of EMR and EC2, as Hadoop was quite pricey at that time for us. We even ended up reducing more than 70% of costs by using Spot instances (basically, marketplace of EC2 instances with huge discounts).

New solution

Half a year passed and we’ve encountered a problem that the approach we have is not sufficient anymore and the price tag of generating daily reports was too high, so we started to investigate other options.

We ended up implementing the new solution using a mix of production ready (like Redshift) and green technologies (like Kinesis) hosted on AWS. This time the main idea was the following: continuously feed raw data into Amazon Kinesis streams which were able to convert that raw data into the meaningful format and pass it into Redshift via Kinesis Firehose component, so then we can run SQL queries in real-time directly on Redshift (which AFAIK is PostgreSQL database optimised for large amounts of data).

During implementation, we even had a chance to contribute to Open Source community by implementing Logstash output plugin for Amazon Kinesis Firehose as well as to research some other interesting Big Data Warehouse technologies like Snowflake.

The first version of the new solution and its first customer integration took us less than 3 months overall. The price in comparison to the first solution was more or less on the same level, but the benefits we’ve got in terms of usability, availability and maintenance did overweight the initial implementation significantly.

Why?

No doubt many things has changed since then, but nevertheless it was real fun and great experience for me.

I think that one of the most exciting parts of being a software engineer is that you are not limited to any particular tech stack and can always solve the same problem in many different ways using completely unrelated technologies, either open source or proprietary.

I believe that the essential thing in software engineering is to have the desire to explore and don’t be afraid of the domain not yet discovered by you.

Cheers!

Hi there! I’m Valera, iOS Padawan at Badoo. Here in our company we are crazy about UI and spend plenty of time designing, polishing and improving the user interface to make our users happy, not only about the services we provide, but also about the look and feel of the app in general. At the end of the day, you don’t go to your first date or an interview in your pyjamas, but instead you would make sure that you wear a suit, or at least something smart/casual and presentable.

First, I want to mention that in Badoo we prefer to build UI in the code. This approach has its own pros and cons, but it’s not the topic of this post. Today I want to talk about building custom UI components, which is tightly coupled with the opposite approach of building UI — via Interface Builder (IB). Depending on your project, you may want to have some custom reusable UI components to be available for you in IB, to play with your UI component parameters without compiling the project and so on. And here I’m going to show you how to achieve that.

You can check out the full source code of the example project here, or just create an empty project of your own to follow up with the steps below. However, I will be skipping the code snippets for views creation and constraints, so the full source code is worth checking.

The idea

Let’s create a simple UI component for our example app to present some information text. The component should reveal a link when a user taps on it. It should have some basic IB configurable properties like border style, texts, colours, and so on.

Designable class

It’s very simple. To create a custom component you just need to create a new class, extend it from UIControl (in our example I extended from UIView for simplicity) and add @IBDesignable annotation:

Then add your inspectable properties [a property which a user of your component can change in IB]:

Using your component in IB

Now, it’s time to test this new UI component in IB. To do so, just drag&drop a “view” from the IB Object library to the main view and then add minimal constraints such as position, width, height:

Then set the UIView’s custom type to the one we created before, i.e. MyDesignableComponent:

And voilà! Now we can see borderWidth property within our view’s properties in the Attributes Inspector:

You probably noticed that if you change a value of borderWidth in IB it won’t do anything, and that’s because we didn’t bind any logic to it, so let’s fix that and update borderWidth property implementation in the code to the following:

Now compile the project, open IB and try to change the borderWidth property to some positive number — there you go! Now the border is visible:

In similar way we can add more properties like border colour:

We also can add some text properties with a default values like this:

Simple, isn’t? And that’s pretty much it!

Now, after just a few more minutes of work we have a component like this:

And here’s what this component configuration looks in IB:

Some tips

Sometimes you may need to have an inspectable property for UI designing only, for example you want to see what the “expanded state” of your control will look like in IB. In order to achieve that, you need to wrap the block of code in the preprocessor macro #if TARGET_INTERFACE_BUILDER .. #endif

As an option, it’s also possible to prepare your custom UI control specifically for IB by overriding the prepareForInterfaceBuilder method in your class.

And never forget to update the related view’s state upon @IBInspectable property change to see the result in IB right away, like we did in the borderWidth and borderColor didSet implementations.

Limitations

Designable components have some limitations. For example, you can only mark a limited set of types as @IBInspectable, which means you cannot have an inspectable enum or array of Strings property.

Another potential downside of @IBDesignable components is that in order to reflect the latest changes in a designable component’s implementation, a project rebuild is required (Xcode does this automatically in the background). So, this could be a decisive factor for big projects. A fair solution for this issue might be a separate project for UI components.

Designable components are not limited by UIView, and again, you can extend from UIControl and take full control of your component’s rendering and laying out.

Conclusions

In general, I think UIKit gives developers a lot of flexibility in implementing UI. For instance, @IBDesignable components could simplify UI development as they give a developer the ability to set up UI in Storyboard, playing with various parameters without recompiling a project.

So, depending on your workflow and needs, I think, this approach might be useful for you, but if not — no problem, at least you know your options!

Thanks for reading!

Cheers.

Resources

The full project is available here: https://github.com/chupakabr/DesignableComponentExample

Detailed reference by Apple: https://developer.apple.com/library/content/referencelibrary/GettingStarted/DevelopiOSAppsSwift/ImplementingACustomControl.html

Preparation of UI for IB: https://developer.apple.com/documentation/objectivec/nsobject/1402908-prepareforinterfacebuilder

What’s new in Xcode 6: https://developer.apple.com/videos/play/wwdc2014/401/

Making custom designable UI components was originally published in Bumble Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hey! Being a developer in Badoo is not only interesting and fun, but also challenging — you have to produce highly maintainable code in a short period of time. Due to the amount of new features coming to our team on a weekly basis, we have to think of the architecture in the first place, otherwise it will be impossible to add new functionality to the app without breaking existing features later. Obviously this also applies to UI implementation whether it’s done via code, xib or using a mixed approach. In this post I’m going to describe some of the UI implementation techniques we use here in Badoo, which make UI development easier, more extensible and testable for our team.

Before we start…

As a starting point for this article I’ll be using a sample app written in Swift to demonstrate UI implementation techniques. The app shows a list of friends upon a button click. It also consists of the following three domains:

1. Components — custom UI components, which means UI related code only;
2. Demo app — demo view models and other entities which have only UI-related dependencies;
3. Real app — view models and other entities which also may contain domain specific logic and dependencies.

Why such separation, you may ask? I’ll give you the answer in just a few moments. For now, take a quick look at the UI of the sample app:

This is a popup view with content on top of the full-screen view. Simple as it is.
The full source code of the example project is worth checking and is available on github.

Value observing utility

Before we dig deeper into the UI code, I want to present one utility class which I’m using in the sample app — Observable and its interface looks like this:

What it does, is simply notify all previously subscribed observers about the changes in the stored value, so it’s kind of an alternative to KVO observing or Reactive observables if you wish. Here is a usage example:

This code subscribes to the changes in self.viewModel.items property and when there’s a change, the observer closure executes some business logic like updating the view’s state and reloading collection view data with new items.

You will see more usages of this utility class later in this post, but now you are prepared!

Here we go: the techniques

So the fun starts here, in this section I’ll present four UI development techniques we use here in Badoo which are:

1. Implement UI in the code;
2. Use layout anchors for simplicity;
3. Divide and conquer with components;
4. UI and logic separation.

I have to say that the second one is not crucial, but it’s still good to know about the existence of this technique. So let’s dig in…

#1: Implement UI in the code

Here in Badoo, we implement most of the UI in the code. You may ask why we don’t use XIBs or Storyboards, and it’s a fair question. In short, the reasoning for this approach is the maintainability of the code in a medium-large team, and this includes:

• Clear changes in the code, and so clearer code reviews, which means there is no need to parse the XML of a Storyboard / XIB file looking for the changes made by your team mate;
• It’s much easier for Version Control Systems like GIT to work with the code instead of heavyweight XML files, especially during merge conflicts, also considering that XIB / Storyboard file content is being changed on every file save, even when the UI wasn’t changed at all (I heard this should have been fixed in Xcode 9, but I still get this problem from time to time);
• It could be hard to change and maintain some properties in Interface Builder (IB), like layer properties upon subview layout for example, and this may lead to a multiple sources of truth of a view’s state;
• Interface Bulider is not the fastest tool really, and sometimes it’s much faster to navigate through the code instead. Or maybe it’s just me? 🙂

Take a look at the following view controller (FriendsListViewController):

In this example you can see that it’s only possible to instantiate this view controller by providing its view model and view config entities. If you want to know more about view models, i.e. MVVM design pattern, you can read about it here on medium. While a view’s config is a simple struct entity which defines a view’s layout and style, like inset, sizes, colors, fonts, etc. I think it’s also a good practice to provide some default view configuration similar to this:

All view initialization is done in the setupContainerView method which is called only once upon view creation, basically just adding all needed subviews to the view’s hierarchy here and then applying their layouts and styles.

Now check out that view controller’s presentation entity:

You can see responsibility separation clearly here, and it’s not any more complicated than triggering a segue from a storyboard really.

The creation of the view controller is pretty straightforward given you have its view model set up and are just using the default view configuration:

Now let’s have a closer look at the magic happening in the layout code..

#2: Use layout anchors for simplicity

Here is the view’s layout code:

Simply what this code does is lay out infoView inside its superview at (0;0) origin nesting a superview’s size.

So why are we using layout anchors? It’s just short and simple. Obviously you can use frame-based layout and calculate all the positions and sizes on the fly, but that just can get quite messy sometimes. You can also use in-code text layout constraints as described here, but it’s impossible to use a safe-area layout guide, because this is also an error prone approach and you have to remember the text format as well:

It’s quite easy to make a mistake or have a typo in the text string defining the layout in the example above, isn’t it?

#3: Divide and conquer with components

As you can see, the UI of the sample project is split into components, each of which does one particular function and no more. Take a look at the following view from the sample project:

1. FriendsListHeaderView — a view which displays some information about friends and a close button;
2. FriendsListContentView — a view that displays a friends list with clickable cells, more content is dynamically loaded upon reaching the end of the list;
3. FriendsListView — a container view for the header and the content views, which lays out the latter two on the screen.

I personally love this single responsibility approach, as you always know which exact entity is responsible for each particular function. It helps a lot, not only during bug fixing times (which you probably not a big fan of), but even when you develop a new feature, as this approach also significantly increases the reusability level of the code.

#4: UI and logic separation

And last but not least, my favourite high level technique, which saved a lot of time and nerves for our team, is UI and logic separation. Literally, what we have in place is a separate project for all UI components, and another project for business logic and the glue parts of UI and logic components.

Let’s take a look at the sample project. As you will remember, we have our presenter implementation looking like this:

As you can see, you need to provide only a header and a content view models. The rest is hidden inside the UI components’ implementation that I described above. A header view model protocol in the sample project looks like this:

Now imagine you are going to add some Visual Tests for your UI, and I can tell you — it’s as simple as passing stub view models for your UI components:

Looks pretty straightforward and simple, doesn’t it? Now, we want to add some real business logic for our component in our app, which may require some data providers, raw data models and so on:

It couldn’t be easier: just implement the data provider and you are good to go!

This looks a bit more complicated with a content view model, but still responsibility separation makes the life so much easier. And that’s how to instantiate and present the friends list screen in the app upon a button click:

This technique helps to isolate the UI from its business, and even easily cover the whole UI with visual tests by feeding fake data to the components! So in my opinion, the separation of UI and related business logic is crucial for the success of a rapidly developing big project, whether it’s a startup or an already established product.

Conclusions

Obviously, this is just a set of some techniques we use in Badoo and I’m not saying it’s a silver bullet for all possible cases, so evaluate and use them if they fit your team and projects. Of course there are other techniques such as Designable UI Components alongside Interface Builder that I explained in my other article, which we try to avoid using at Badoo for maintainability reasons. Remember, everyone has their own opinion and a view of the big picture, so I believe in order to be successful you have to reach a consensus in your team and stick to a selected approach for most cases.

Thanks for your time and may the Swift be with you!

Resources

• Full project is available on github;
• Making custom designable UI components by myself;
• iOS Architecture Patterns by Bohdan Orlov, former Badoo developer;
• Modelling state in Swift by John Sundell;
• SOLID Principles in Swift by Vinodh Swamy;
• NSLayoutAnchor by Apple;
• Programmatically Creating Constraints by Apple.

iOS UI development in Badoo was originally published in Bumble Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.