Discover the importance of integration tests in software development for robust code. Learn how they improve code quality, prevent production surprises, and ensure seamless component integration.

Boosting Code Quality with Integration Tests: Bug-Busting in Software Testing | Showmax Engineering

We all know writing tests can be a bit of a time sink and, well, a tad dull. But, trust us, they're your code's best buds, sniffing out those bugs and keeping your work top-notch. We're here to talk about crafting efficient tests that are quick in bug-busting. Let's get into the nitty-gritty of software testing!

In our CMS team, the most critical parts are API services, especially our lovely Catalogue API, which impacts end users and can easily affect the platform’s usability. Catalogue is the source of nearly all our content, including movies, series, sports events, promoted rows, etc. It supports a wide variety of clients, has a continuously growing number of API versions, and receives a high amount of requests every second. In addition to all of that, Catalogue API uses Elasticsearch indices with a constantly changing mapping as a data source. In other words, it is a perfect environment where bugs can find shelter.

Back in 2021, we had only unit tests for Catalogue. Even though unit tests are great, we realised that unit tests alone are not enough to prevent stressful surprises during production deploys, especially after big cross-service changes. Unit tests typically only work in a limited context on a small section of a program (known as the “unit”). They also heavily rely on mocking things, which consequently brings the extra maintenance costs of keeping the mocks synchronised with the code after every refactor or function rename. 

The main concern is that we can't include all crucial Catalogue parts in the testing loop only by having unit tests. We need something larger or, if you like, higher level. The idea with integration tests is to have the ability to send a request to a Catalogue API, trigger the entire call stack, hit Elasticsearch, and get a response. Another benefit is that integration tests only care a little about the code itself. As a result, we can rename, refactor, and move packages around without the burden of syncing tests. Mocks are not welcome here!

We can configure our CI to spin up Elasticsearch when integration tests require it. We can use pytest to set up a testing application, provide requested fixtures, create Elastic indices, and fill them with data. In turn, falcon's test client can send requests. Sounds straightforward, right? Well, not really. 

We rapidly sketched a testing environment, including the test app setup, Elastic connection and indices creation, various fixtures, and other related tools. The challenge is accurately recreating that constantly changing mapping we have already mentioned. Indices and the mapping are defined by a fabled (and feared) cron job called ES-init, which takes normalized data from our CMS DB, denormalizes it, and indexes it into Elastic. It is a totally different environment.

So how can we get information about the indices? In the first POC, we simply dumped the mapping data into a JSON file and saved it in our integration-test Python package. It worked! We got proof that we could fit all these puzzle pieces together. Now we can write something like this:

#javascript#
@use_data(
    marketing_promos_data=[
        {
            "title": {"eng": "Coming soon Call to action"},
            "promo_type": PROMO_TYPE_SPORT_CALL_TO_ACTION,
        },
        {
            "title": {"eng": "Coming soon Editorial"},
            "promo_type": PROMO_TYPE_EDITORIAL,
        },
    ]
)
def test_no_call_to_action_promos_for_older_clients(
    client_website, main_territories, marketing_promos
):
    # Get all promos. Default API version is 138.
    result = client_website.simulate_get("/catalogue/promos")
    assert len(result.json) == 2
    # Do not return Call-to-Action promos to older clients.
    result = client_website.simulate_get(
        "/catalogue/promos", headers={"Showmax-Int-Api-Major": "130"}
    )
    assert len(result.json) == 1
    assert result.json[0]["title"] == "Coming soon Editorial"


Yes, it's beautiful! It has zero mocks and tests a lot (remember that the request goes through the entire call stack). What is more important is that it's easy to read and write, just look at it.

Let's write some code, and you will see how easily we can request the required data for a test.

#javascript#
def test_something(
    client_android,
    assetflat,
    main_territories
):
    # Some testing is happening here.

The body of this test now can use a ready-to-use Android client, one asset, and all main territories. The asset and main territories documents are indexed in the corresponding indices. All fixtures have reasonable defaults. For example, the assetflat object is a movie with valid license windows for all countries.

Imagine we want to ensure that the /by_id endpoint filters out content which doesn't have a license for a particular country. Easy!

#javascript#
@use_data(
    assetflats_data=[
        {"uuid": "uuid-1"},
        {"uuid": "uuid-2"},
        {"uuid": "uuid-3"},
        {
            "uuid": "uuid-4",
            "license_windows": [
                {
                    "start": choices.DATETIME_PASSED,
                    "end": choices.DATETIME_FUTURE,
                    "countries": ["ZA"],
                    "subscription_statuses": [
                        "sports_full",
                    ],
                    "type": "SVOD",
                    "uuid": "uuid-4-lw_za",
                    "is_downloadable": True,
                }
            ],
        },
    ]
)
def test_filter_by_content_country(
    client_android,
    assetflats,
    main_territories,
    main_languages,
    categories,
    main_ratings,
):
    result = client_android.simulate_get(
        "/catalogue/by_id",
        params={
            "id[]": "uuid-1,uuid-2,uuid-3,uuid-4", 
            "content_country": "KE"
        },
    )
    assert result.status == HTTP_200
    assert result.json["count"] == 3

We can request multiple objects and overwrite only the parts we want. In our case, asset uuid-4 has a valid license window only for South Africa. Other assets have valid license windows for all territories. Similarly, we can overwrite any fixture we want. For example, we've created a helper which allows us to generate hundreds of sports events with any date and time range.

Again, look at the test above – it's self-explanatory.

After we finished writing our first integration test, several developers had already changed an Elasticsearch schema in CMS multiple times. As a result, our Catalogue tests with fixtures based on hardcoded "stale" mappings didn’t make sense anymore. Moreover, such tests would not catch a bug introduced by new mapping changes in CMS. This happened several times during production deployment. Changes in Service A implicitly may affect Service B.

We could ask developers to dump Elasticsearch mapping information and update a JSON file inside the integration-tests package every time it’s changed, but that would require another forgettable and manual step. Is there a way to automate this? 

Yes: having our code in a monorepo gives us this flexibility. We can access files of other services and packages. So we introduced a test for CMS which will fail a CI if mappings are not synced with the integration-tests package. Simple and efficient. You can’t merge your pull request if the integration-tests package has outdated mapping. Period.

Another CMS command, that performs this synchronisation:

What does all this give us? Elasticsearch indices are created and populated with data by the CMS service but are read by the Catalogue API. If even a tiny Elasticsearch mapping change introduced by the CMS service is not fully tested on the Catalogue API, we can end up with a bug in production. Performing these tests manually is nearly impossible since we would have to cover a lot of cases (multiple endpoints, different clients and API versions) and unit tests just aren’t adequate for this. Integration tests solve this problem and work as a glue between different services.

Monorepo not only allows us to access files of other services but also gives us the luxury to install packages from the path. If we change our packages, we don't need to rebuild and push them to PyPI. No need to update poetry.lock files in all dependent services (this topic might be a separate blog post). We simply change the code of the python package, and those changes are reflected in services during the next build. 

During the CI, we know what services or packages were changed, and based on this information, we run tests for those. For example, if a pull request includes changes for CMS service and es-models package (another python package), we run tests respectively for CMS and es-models.

Could we extend this logic so we also run tests for services which depend on changed python packages? Absolutely! All python dependencies are listed in pyproject.toml file. If a changed python package is referenced in service’s pyproject.toml, we add this service to the loop.

How is it related to integration tests? Imagine we want to add one field to the index where all assets are stored. Changes will look something like this:

[CMS service] Elasticsearch mapping change

[integration-tests package] Elasticsearch mapping update

[es-models] Reflecting mapping update in our python wrapper for Elasticsearch

When such a pull request is created, the CI will run the following tests:

Run tests for integration-tests python package
undefined

Run tests for es-models python package
undefined

In this sequence, integration tests ensure that Catalogue, Catalogue-proxy, and Playback will not be broken by changes introduced in CMS.

In conclusion, while unit tests serve as a valuable tool in software development, they are rarely sufficient in ensuring the seamless integration of various components of big projects. This is where it might be beneficial to invest time into creating integration tests that enable us to test the interactions between services and identify potential issues that might arise in more of a “real-world” scenario.

Discover the remarkable evolution of Android TV development, as we share insights into how innovation, adaptability, and user-centric design transformed our app. Dive into a journey that redefines TV streaming.

Elevating Android TV Development: A Journey of Innovation and Transformation

As engineers, developing a video-streaming app that lets people enjoy movies anytime and anywhere means expanding your reach across multiple platforms. With a limited team, it's crucial to ensure consistent support for development, bug fixes, and features. Prioritizing the most widely used platforms makes logical sense. In this context, the African market takes center stage – it's mobile-first, with users watching content on the go, during commutes, and while traveling long distances.

Previously at Showmax, we faced the challenge of catering to diverse platforms with a single mobile team. This team was responsible for developing mobile apps for both Android and iOS, as well as covering Android TV and tvOS. This approach seemed reasonable due to shared programming languages and potential codebase integration. However, the TV experience, known as "leanback" due to users typically leaning back on a sofa while watching on a large TV screen, brought unique design and product considerations. And unfortunately, the platform’s UX was a bit left behind. 

When we set out to develop an Android TV app, we opted for a simple approach that adhered to industry standards. We built our application using the Android Leanback library.

This widely-used library is officially supported by Android, sparing developers from implementing all views, components, and intricate interactions (think of navigation in a 'touchless' environment). It offers solid system support out of the box.

Designing an app for the TV platform is cost-effective due to existing elements and limited design adjustments.

Due to technological advancements, the library has become somewhat dated, impacting the user experience and necessitating significant adjustments for TV app development.

As mentioned earlier, design and product decisions are constrained by the Leanback library's components and layouts.

One colleague, who is an Android TV owner and enthusiast, aptly pointed out the UX during a redesign demo: "Android TV users are simply used to [visually] suffering when using the apps."

The original Showmax Android TV application was constructed several years ago using components from the Leanback Library.

These challenges, combined with a heightened focus on mobile apps (given their prevalence in African markets) and a lack of dedicated design or product management for the Android TV platform, led us to approach the app as an MVP – a minimum viable product. While supporting new features, we prioritized basic functionality over specific or elaborate designs.

With a commitment to allocate 10 percent of our time to innovation and approximately 30 percent to address technical debt and engineering tasks, we aimed for a more balanced approach. This ensured we weren't solely focused on external demands and features from other teams. Thus, we capitalized on this time to enhance our Android TV app.

Our initial step was a common one – identifying pain points collectively. With developers, testers, and app users, we unearthed numerous minor issues ripe for fixing. These low-hanging fruit were prioritized based on technical complexity and potential impact on user experience. We utilized our technical allocation to incorporate these improvements into our plans. This phase primarily involved resolving UI issues and refining navigation between screens. We conducted A/B tests and drew insights from other platform tests and improvements. Additionally, we integrated sought-after features already implemented by other TV teams. Our focus was on tasks demanding minimal Product or Design involvement, requiring limited effort on our part and no backend changes.

The outcome was remarkably positive – we received favorable internal feedback and users' reviews and questionnaires echoed the improvements.

Following the swift fixes, we tackled more substantial challenges that demanded significant time investments across multiple teams. Since our team wasn't overflowing with resources, including Product and Design teams, we needed alignment with other priorities. At this juncture, before delving heavily into the existing app, we proposed a comprehensive platform overhaul. We faced two options: retain native platform support or port our existing JavaScript-based solution for smart TVs to the Android platform.

The smart TV solution was already in use on the web and various TV brands. Adding the native player, which we already possessed, made it the quickest and most cost-effective choice. Unfortunately, the performance of the ported JavaScript application was underwhelming on regular Android TV boxes, and our smart TV team lacked the bandwidth for performance optimization. The alternative was to proceed with the native approach. While promising a superior user experience and performance, this route required significant investment. Thanks to the positive outcomes from initial changes, available team capacity, and the considerable presence of Android TVs in the market, we obtained the green light for this revitalization effort.

To kick start the process, we brought in a dedicated designer fresh from another project within the company. Additionally, we allocated 30% of one of our Product Managers' time to assist with the project. As the team leader, I dedicated half of my time to this endeavor. Furthermore, we appointed a Lead Android TV engineer from our team to closely collaborate with the group, forming a well-rounded product trio.

In conclusion, our journey toward enhancing the Android TV app involved simplifying the technical approach, tackling challenges incrementally, and nurturing innovation within our team. The outcome was a more refined and user-friendly app that aligned with the unique demands of the Android TV platform.

In our pursuit of enhancing the Android TV app, we embarked on an in-depth research journey. Building upon our initial issue triage, we conducted numerous customer interviews and testing sessions, effectively creating an extensive Design sprint.  (The process of rethinking the solution and opportunity mapping was similar to what we have described in the blog post focusing on data driven design process). Through these efforts, we identified major pain points. However, we realized that many of these challenges couldn't be easily resolved within the confines of the existing Leanback library offered by Google. Addressing them would necessitate substantial investments in new development and a comprehensive app rewrite.

We started by a screen-by-screen analysis of the current solution with gathering feedback from all stakeholders to identify all opportunities.

Recognizing the need for analytical insights, we enlisted the aid of one of our Data Analysts. They assisted in the data crunching required to assess the current solution and support the tests and experiments we were eager to undertake. Armed with a solid justification for additional resources, we found ourselves in a position where innovation knew no bounds. Our platform transformed into a dynamic research lab.

Subsequently, Affinity mapping helped us identify the key ideas and assumptions to prioritize.

Taking a bold step, we bid farewell to the outdated Leanback library that had previously constrained us. This opened the door to entirely fresh designs, whether they involved individual elements or entire screens. Our approach now encompassed a spectrum of innovative solutions, often drawing from successful strategies on similar platforms. This approach led us to pioneer novel navigation methods – some of which were eventually embraced by other TV platforms. Additionally, we refined content promotion techniques and introduced a range of feature enhancements. During this phase, we also embraced a new Design system, a tool that greatly expedited the platform revamp process. Interestingly, while our Android team had hesitated to adopt the Design system for their mobile app due to its established functionality, they eagerly embraced it for the TV app, recognizing its potential as we built it from the ground up.

Finally, we prioritized the solutions based on technical feasibility and user impact using a simple prioritization matrix to determine what to address first.

As our journey progressed, it became evident that our esteemed platform demanded full-fledged attention. In response, we took significant steps to reinforce our efforts. We welcomed a dedicated Product Manager exclusively responsible for Android TV. Simultaneously, we selected a developer from our ranks and elevated them to the role of Android TV platform lead, overseeing all matters related to ATV. The addition of the new Product Manager necessitated a reevaluation of our team's capacity allocation. The outcome was a balanced distribution – one-third for mobile, one-third for TV, and one-third for our team's internal technical initiatives.

In closing, our commitment to research and innovation transformed our Android TV app from a mere platform into a dynamic laboratory of ideas. Through tenacity and adaptability, we ushered in a new era of design, functionality, and user experience, propelling our app to the forefront of modern TV streaming platforms.

The reworked application has a modern appearance, employing custom-built elements and layouts derived from our in-house design system.

Our journey to enhance the Android TV app underscored the value of adaptability and innovation in a rapidly evolving landscape. What started as a quest to improve user experience culminated in a transformative process that redefined our platform's capabilities. By challenging convention, embracing research, and fostering a culture of exploration, we unlocked new avenues for design and functionality. The lessons we learned along the way, the hurdles we overcame, and the innovations we championed have paved the path for a future where the Android TV experience continues to elevate and captivate our users. With a dedicated team, a fresh approach, and a willingness to push boundaries, we are excited to embark on this new chapter of Android TV development, armed with the knowledge that every challenge is an opportunity and every innovation propels us toward excellence. Together, we journey onward, crafting a dynamic TV streaming experience that resonates with viewers in every corner of Showmax’s market in Africa.

Earlier this year, Google introduced a new Leanback library based on Jetpack Compose. We were proud early adopters of this library and are pleased that we could contribute to shaping the future of Leanback development through our participation in Google’s Early Access Program. Without our prior internal efforts to rework the TV platform, this would not have been achievable. You can find more information in our recent blog post on Baseline Profiles for Android or explore our talks on the Android TV transformation and adoption of Jetpack Compose for Android TV.

Enhancing Android TV App Development: A Journey of Innovation and Improvement

Discover Kotlin Multiplatform Mobile (KMP) in our latest blog post authored by David Aldorf (iOS) and Tomáš Král (Android). Explore the benefits, challenges, and performance considerations of this powerful framework for multi-platform app development. Uncover the potential of code sharing and seamless UI development with Compose Multiplatform. Whether you're an iOS or Android developer, KMP offers a game-changing approach to mobile app development. Dive in now!

Exploring Kotlin Multiplatform Mobile (KMP): A Comprehensive Overview by David Aldorf and Tomáš Král

Authorship Disclaimer: This blog post was co-authored by David Aldorf and Tomáš Král.

The realm of multi-platform development has received a remarkable addition with JetBrains' new framework known as Kotlin Multiplatform Mobile (KMM), which has evolved to be Kotlin Multiplatform (KMP) since September 2023. The primary objective of KMP is to facilitate code sharing across various platforms, effectively curbing development costs. In this article, we dive into KMP, its unique features, challenges faced during implementation, and its applicability to real-world projects.

So why did we opt for Kotlin Multiplatform? We were driven by the aspiration to maximize code sharing, and with Compose UI now available on iOS, we chose to embark on this path to achieve our goal. This decision promised not only efficient cross-platform development but also the potential to leverage the modern Compose framework seamlessly across iOS and other platforms.

Popular apps using Kotlin Multiplatform (KMP) in 2023

Kotlin Multiplatform (KMP) extends beyond Android to encompass platforms like iOS, web, and desktop. It unifies a shared codebase for internal API access across iOS, Android, web, and desktop, with a standout feature being its native compilation for each target platform. This is made possible by the Kotlin/Native compiler for iOS and desktop and the Kotlin/JVM compiler for Android. Notably, for iOS, the Kotlin/Native compiler translates Kotlin code into LLVM bytecode, seamlessly integrating with Swift runtime components and resulting in iOS app bundles.

The goal is to write to a shared module and especially to commonMain as much code as possible. This part is shared with all platforms. androidMain and iosMain in the shared module are used for platform-specific code. It is written in Kotlin but it can work with platform-specific APIs and libraries. This is pure magic, especially on the iOS side. androidApp and iosApp modules are standard Android/iOS applications using the shared module as a library.

This PoC was written from scratch and it makes sense to us to have just one shared module/library. But in real life, it is possible to make more of them. For example, one for the data layer, one for data storage, etc. Also, a database-shared module can be used the same way on all platforms regardless if it is Room on Android or Realm on iOS. These platform-specific things will be in the Android/iOS part of the shared module. Android and iOS applications will just call a simple facade API.

We use it just for Android and iOS but it can be used for Web and Desktop as well. JetBrains devs are going even further and their idea is to share the same Domain models and services between Backend and Frontend.

Our goal is clear: to create a prototype app that showcases a grid of movies and series. When users tap on an item, they'll see detailed info about it and be able to start watching. To achieve this, we'll download the assets and make sure users can play videos from their source URLs.

Before we start KMP development, we need to set up Environment and Project. Xcode, Android Studio, and the Kotlin Multiplatform Mobile plugin are essential. A helpful tool named Kdoctor aids in setting up and validating the development environment. CocoaPods are optional, even JetBrains says to avoid them if your project is not using CocoaPods dependencies. Because it is a more complicated setup.

Good information on how to start can be found here: 

https://kotlinlang.org/docs/multiplatform-mobile-getting-started.html

https://www.youtube.com/watch?v=CIZU_NNAZsA&list=PLlFc5cFwUnmxSiLW3xyStFSbEslmUSG3p

https://terrakok.github.io/kmp-web-wizard/

Android Studio has a wizard-driven setup, resulting in separate iOS and Android apps that share a common codebase. Although this setup appears unified and it is good for getting familiar with KMP,. Iin reality, Android app, iOS app, and KMP module/library (which is in our case called shared) will be  in separate repositories. 

You can check this wizard if you want some inspiration for the build.gradle setup. It especially helps with setting up gradle for specific platforms and dependencies.

It is awesome how simple it is to run an iOS app from Android Studio. The iOS one is created and configured the same way the Android one is. All devices from Xcode can be selected as an execution target.

Compose Multiplatform: Unifying UI Development

Jetpack Compose has transformed UI development, especially on Android, offering a seamless and robust solution. Compose Multiplatform takes this innovation a step further, extending its benefits without drawbacks. It empowers developers to craft captivating interfaces seamlessly on Android.

For iOS, Compose Multiplatform employs Skiko for a unique Canvas-style interpretation, breathing creativity into UI development. While it differs from the UIKit-based approach, it ensures UI interoperability via iOS widgets/UIKit and SwiftUI. By embedding native UI components in shared UIs through elements like UIKitView and ComposeUIViewController, platforms blend effortlessly.

Notably, Compose Multiplatform doesn't cover tvOS, but Kotlin Multiplatform (KMP) remains reliable here. This demonstrates KMP's flexibility in diverse contexts.

For an in-depth look, explore the Compose Multiplatform GitHub repository, a hub of collaborative innovation driving cross-platform UI development.

There are a lot of multiplatform libraries available these days, so you can easily avoid platform-specific implementation. Still, there is room for improvement. In our case, the library for the video player was missing. Even so, the number of KMP libraries is growing every day.

From an iOS developer's viewpoint, adopting KMP can entail a shift to a new IDE (Android Studio), potentially complicating the entry process. While syntax similarities might ease the transition, debugging in Xcode and adapting to Compose's alpha stage on iOS could present challenges. Business logic and networking layers are prime candidates for code sharing, whereas platform-specific concerns often linger.

Android developers have it way simpler. The only big differences between pure Android and KMP projects are build.gradle and project modules structure. Even Compose UI stays almost untouched.

To call a platform-specific API in the shared module, it is necessary to step out from commonMain to androidMain and/or iosMain. It is possible to do it simply by Interface or the new JetBrains construct expect/actual can be used. Expect/actual will force programmers to implement new features on all platforms. To use it, just annotate the desired value, variable, function, or class in commonMain by expecting the keyword to tell the compiler that the actual implementation will be in the platform-specific part of the shared module. Then annotate the real implementation with ‘actual’ in androidMain and iosMain.

In this case the Android app uses ExoPlayer. We used an Exoplayer with MediaSource and AndroidView to be able to use it in Compose.

Navigating the iOS landscape introduces some complexities, yet KMP comes to the rescue. We tap into iOS internal APIs like Foundation, UIKit, AVFoundation, and SwiftUI, and here, KMP lends a hand by allowing us to utilize these APIs through Kotlin. For instance, we opted for AVPlayer. The process is relatively straightforward: we initialize AVPlayer much like on iOS, with the only distinction being the encapsulation within a UIKitView.

In such cases, the Alpha version of Compose Multiplatform introduces a prototype for seamless UI interoperability. With UIKitView, you can easily integrate advanced platform-specific elements such as maps, web views, media players, and cameras into your shared user interface. Conversely, through ComposeUIViewController, you can smoothly incorporate Compose Multiplatform screens into your SwiftUI-based iOS applications, making the transition to Compose Multiplatform a gradual and convenient process. In this case, you can use Compose Multiplatform alongside your current UI layer. You can read more about it in this article: Compose Multiplatform for iOS Is in Alpha.

While KMP excels in facilitating multi-platform development, it's essential to note that iOS compile times might experience a slight increase during KMP app development within Xcode. Therefore, the run-time seems the same as a native app.

While KMP presents a seamless approach to multi-platform development, it does come with some challenges. Debugging on iOS involves separate debuggers for iosApp and shared components. Setting up Xcode Command line tools and integrating CocoaPods might get complicated. Finding help online (StackOverflow, etc.) can be tough since KMP is relatively new. Finding a solution may require going through public repositories.

Kotlin Multiplatform, now called Kotlin Multiplatform (KMP), offers a revolutionary way to build apps for multiple platforms. It lets you share code and easily connect to internal APIs, making development efficient and cost-effective. However, using it for full multiplatform UI development can be challenging, especially on iOS, where Compose Multiplatform is in its early stages, and tvOS is unsupported. KMP excels at sharing business logic, data layers, and domain models, making testing simpler. We recommend giving it a try and gradually integrating it into your project, starting small, and not needing a major code overhaul. You can begin with one feature or API calls and expand from there to share more code with your fellow developers. The key is that you don't have to rewrite everything at once to benefit from KMP.

Exploring Kotlin Multiplatform Mobile: A Comprehensive Overview

Discover practical strategies for effectively handling feedback loops in your RxSwift code. Learn how to transition from imperative to declarative programming using RxSwift, while avoiding common pitfalls and optimizing code structure. Gain valuable insights and implement best practices for managing state and ensuring smooth functionality. Dive into real-world examples and explore the power of RxFeedback to simplify complex state machines. Improve your RxSwift skills and optimize your app's performance today.

Handling Feedback Loops in RxSwift: A Guide for Effective Code Implementation

It has been several years since we started using RxSwift in our Showmax iOS app. Similar to many other teams, we needed to move away from imperative programming and towards a more declarative approach. Although Rx can be a powerful tool, it's crucial to use it correctly – otherwise, it could do more harm than good. Changing your mindset from an imperative approach to a declarative one is a challenging process and it can take time to truly take root.

The article that follows will outline our progress from initially using RxSwift in an imperative manner to fully embracing a declarative approach. The reader should have a basic understanding of RxSwift.

All of the code discussed in the article is available in this github repository.



The player is the central focus of our app, and therefore, it serves as an ideal example to illustrate our point. The player state is constantly changing based on the video played which makes it a natural fit for reactive programming. Let's consider a basic player with a custom HUD (heads up display) that displays the player's controls as follows:

As any other HUD, it needs to be shown when the screen is tapped. Because we would like to unit test every aspect of the player, we want to have it driven by the view model. This is how we would represent it using RxSwift:

#javascript#
class PlayerViewModel {
    struct State {
        let isPlaying: Bool
        let isHUDVisible: Bool
    }


   // ….


    private lazy var stateDriver: Driver<State> = {
        Observable.combineLatest(
            isPlaying,
            isHUDVisible
        ) {
            State(isPlaying: $0, isHUDVisible: $1)
        }
        .asDriver(onErrorDriveWith: .empty())
    }()
}

The isHUDVisible is an Observable that will be controlling whether HUD is shown on top of the player. So how do we define it?

The first choice of any imperative programmer would be BehaviorSubject, or its equivalent, BehaviorRelay, which avoids error emissions. When didTapHUD is called from the View it will set it to true.

#javascript#
let isHUDVisible = BehaviorRelay(value: false) 

func didTapHUD() {
   isHUDVisible.accept(true)
}


However, this approach has a few problems:

We're now mixing imperative and declarative programming. In reality there will be many more ways to bring up and hide the HUD. E.g. when the movie ends, when a certain gesture is invoked, etc. That will scatter the isHUDVisible.accept(...) calls throughout our code. To get a complete picture of what is driving the hud visibility we need to check all these calls plus we also need to check the reactive code. No bueno.

Let's say we would like to hide the HUD after 3 seconds. However, any interaction with the UI should reset the timer and wait another 3 seconds. An imperative programmer might want to try this approach:

#javascript#
var hideTask: Task<Void, Error>?

private func didInteractWithUI() {
             // cancel previous hide
             self.hideTask?.cancel()

             // hide after 3 seconds
             self.hideTask = Task {
                 try await Task.sleep(for: .seconds(3))
                 self.isHUDVisible.accept(false)
             }
           }

The function didInteractWithUI will be called any time the user interacts with the player. We are again mixing imperative and reactive code and it's getting even harder to understand. Plus we need to bother with cancellation of the previous hide task which adds extra unnecessary complexity.

The code for the implementation is available in  PlayerViewModel_01.swift.

To solve some of the problems mentioned above let's make the code more reactive. First let's define two PublishRelays that will be invoked on hud tap and on interaction with UI. The key distinction between PublishRelay and BehaviorRelay is that PublishRelay does not hold any state but only forwards events (e.g. tap on HUD) to the reactive code.

#javascript#
private let didInteractWithUIRelay = PublishRelay<Void>()
private let didTapHUDRelay = PublishRelay<Void>()

Then we can define isHUDVisible as a single stream.

#javascript#
private var isHUDVisible: Observable<Bool> {
        Observable.merge(
            // When HUD is tapped we want show the HUD
            didTapHUDRelay.map { true },

            // Hide HUD 3 seconds after last interaction
            didInteractWithUIRelay.flatMapLatest {
                Observable.just(false).delay(.seconds(3), scheduler: MainScheduler.instance)
            }
        )
    }

In the above code we merge two streams. The first will set isHUDVisible to true which will make the HUD appear. The second will wait 3 seconds after the user interacts with the UI and hides the HUD by sending the false value. This is a step in the right direction because:

All state related logic is contained in the same place. In fact, the state can't be mutated from anywhere else but here.

The logic for canceling hide upon UI interaction is replaced by a single flatMapLatest operator.

However, you might notice there's one glaring problem with our HUD. When the HUD is visible and the user taps it, we would expect it to hide immediately. But in the current implementation you would always have to wait 3 seconds. To put it simply, we would like to toggle the isHUDVisible value as such:


 #javascript#
didTapHUDRelay.map { !oldIsHUDVisible }.

But how do we do it when we don't have access to the previous value?

Let's refactor our code a little bit. First let's define what actions we can do with our isHUDVisible state.

#javascript#
enum HUDVisibilityEvent {
   case hide
   case toggle
}

Then let's update the isHUDVisible stream a little bit:

#javascript#
private var isHUDVisible: Observable<Bool> {
        Observable<HUDVisibilityAction>.merge(
            // Toggle HUD on tap
            didTapHUDRelay.map { .toggle },

            // Hide HUD 3 seconds after last interaction
            didInteractWithUIRelay.flatMapLatest {
                Observable.just(.hide).delay(.seconds(3), scheduler: MainScheduler.instance)
            }
        )
        .scan(false) { oldState, action in
            switch action {
               case .hide:
                  return false
               case .toggle:
                  // that’s what we are after! 
                  return !oldState
             }
        }
        .startWith(false)
    }

There’s a lot to unpack here. First of all, we keep the same observables in the merge but instead of mapping them into Bool we are mapping them to an HUDVisibilityEvent.

On the next line we use the reactive scan operator. It helps us accumulate value over time and use it in our next calculation. The old state value is passed in the first parameter and the event is passed as second. When the HUD is tapped we can just toggle the previous state value which gives us exactly what we are after. 


For the full context see  PlayerViewModel_02.swift in the GitHub repository.

If you have spent any time researching the functional programming paradigm online, this pattern might seem familiar to you. In fact, it is the very same Reducer pattern that is used in The Composable Architecture (TCA), ReSwift, React and many many others.

This diagram defines the broad idea of Reducer architecture. The view will send actions (in our case they are called events) to reducers which will in turn update the state in store. The view is then updated . We usually see this applied as app-wide architecture but nobody says you can't apply it to distinct sub-problems like this one.

Reducer

The reducer part of the diagram can be defined as follows. It always takes the current state and action as arguments. It should always be a pure function (a function whose output value follows solely from its input values, without any observable side effects).

#javascript#
private static func hudVisibilityReducer(state: Bool, event: HUDVisibilityEvent) -> Bool {
        switch action {
        case .hide:
                  return false
        case .toggle: 
           return !oldState
        }
 }

#javascript#
.scan(false, accumulator: Self.hudVisibilityReducer)

The Action part of the diagram is defined with our HUDVisibilityEvent. It represents “something that happened” and based on which the state should be mutated.

State

State is a simple Bool here but can be much more complicated.

Store
The scan operator essentially provides us with the store functionality. It stores the previous state value and applies the reducer with the new action on it.

This pattern by itself can be a very powerful way to represent the state of your application. The code that handles state mutation is contained within the pure reducer function which can be tested very easily. Chances are you already know and use this pattern within your reactive code. But it has its limitations as I describe in the following example.


For our binge-watching users, the skip intro button has become indispensable. What it does is fairly self-explanatory – when a series intro starts a button will appear which will let users skip it. In fact, after we introduced the button we noticed that most users will choose to skip as soon as it appears. So let’s make it even easier for them and skip the intro automatically if the user doesn’t choose otherwise in the first 10 seconds.


#javascript#
enum SkipIntroState {
        case hidden
        case showing(secondsLeft: Int)
        case skipping
    }

... 

private var hasIntroStarted: Observable<Bool> {
        player.rx.time
            .map { $0 > Constants.introStart }
            .distinctUntilChanged()
    }

...

private lazy var skipIntroState: Observable<SkipIntroState> = {
        hasIntroStarted.flatMapLatest { hasCreditsStarted -> Observable<SkipIntroState> in
            if hasCreditsStarted {
                return Observable.timer(countingDownFrom: 10)
                    .map { secondsLeft in
                        if secondsLeft > 0 {
                            return .showing(secondsLeft: secondsLeft)
                        } else {
                            return .skipping
                        }
                    }
            } else {
                return .just(.hidden)
            }
        }
        .share(replay: 1)
    }()

After the intro starts (based on player time) we will start a timer with a period of one second. On every tick it will update state until we reach 0 where we switch to `skipping` state.

To actually skip the intro we will need to call player.rx.seek(...) which returns Completable (Observable that can only complete). Seeking is an asynchronous operation (due to network latency). We only want to hide the skip intro button after the seek is completed.. But how do we do that?

One way to achieve this would be with a side-effect in a separate subscription on skipIntroState. The subscription would be set-up during view model initialization:

#javascript#
skipIntroState
    .flatMapLatest { [player] state -> Observable<Void> in
        guard case .skipping = state else { return .empty() }
        return player.rx.seek(to: Constants.introEnd).andThen(.just(()))
    }
    .subscribe(
        onNext: { [weak self] _ in
            self?.didSkipIntro.accept(())
        }
    )
.disposed(by: bag)


When the state switches to  “.skipping” we will perform the seek to the intro’s end. When it is concluded we will use the new didSkipIntroRelay to inform the state:

#javascript#
private let didSkipIntroRelay = PublishRelay<Void>()
...
private lazy var skipIntroState: Observable<SkipIntroState> = {
        Observable.merge(
            ...,

            // Change to hidden state when intro was skipped
            didSkipIntro.map { .hidden }
        )
        .share(replay: 1)
}()


As always, you can check the full implementation at PlayerViewModel_03.swift

Here is a diagram illustrating the data flow:

The line that goes from the seek side-effect through the relay back to state shows that we now have a loop in our code. State updates to skipping which will start the seek which then changes the state again. 

The solution works but it hurts readability quite a bit by splitting the code in two parts. And when you have multiple loops affecting one state the code can become very hard to understand.

RxFeedback is a simple framework from the creators of RxSwift. It provides us with the new system operator for Observable. It is basically a super-powered version of scan. It takes an initial state, reducer function, scheduler and an array of feedbacks as parameters. 
Feedback is nothing else but a closure with this signature: (Observable<State>) -> Observable<Event>. In Feedback we are now able to take state Observable, perform a side effect and return an event as result. Here’s the implementation of the system operator:

#javascript#
 public static func system<State, Event>(
        initialState: State,
        reduce: @escaping (State, Event) -> State,
        scheduler: ImmediateSchedulerType,
        feedback: [Feedback<State, Event>]
    ) -> Observable<State> {
        return Observable<State>.deferred {
            // This is roughly equivalent to PublishRelay
            let replaySubject = ReplaySubject<State>.create(bufferSize: 1)

           // Map the array of feedbacks to observables and pass them the state
            let events: Observable<Event> = Observable.merge(
                feedback.map { feedback in
                    return feedback(replaySubject.asObservable())
                }
            )

            ...
            
            // use scan as we did in previous example
            return events.scan(initialState, accumulator: reduce)
                .do(
                    onNext: { output in
                        // when new state is emitted feed it back to the system using the replay subject
                        // this is what creates the feedback loop!
                        replaySubject.onNext(output)
                    }, onSubscribed: {
                        // we need to start the subject with initial state upon subscription
                        replaySubject.onNext(initialState)
                    }
                )
                .startWith(initialState)
        }
    }

From the code we can see that it is very similar to our previous example. Only where we had used didSkipIntro relay to create our feedback loop, RxFeedback feeds the state back to the system using replaySubject and thus creates the feedback loop.

And what would our code look like with RxFeedback?

#javascript#
enum SkipIntroAction {
        case hasIntroStarted(Bool)
        case secondsLeftChanged(Int)
        case didSkipIntro
}

private lazy var skipIntroState: Observable<SkipIntroState> = {
        Observable.system(
            initialState: SkipIntroState.hidden,
            reduce: Self.skipIntroReducer,
            scheduler: MainScheduler.instance,
            feedback: [
                // 1 
                { [hasIntroStarted] _ in
                    hasIntroStarted.map { SkipIntroAction.hasIntroStarted($0) }
                },
                // 2 
                { [player] state -> Observable<SkipIntroAction> in
                    state.flatMapLatest {
                        guard case .showing(let secondsLeft) = $0 else { return .empty() }
                        return Observable.just(.secondsLeftChanged(secondsLeft - 1)).delay(.seconds(1), scheduler: MainScheduler.instance)
                    }
                },
                // 3 
                { [player] state in
                    state.flatMapLatest {
                        guard case .skipping = $0 else { return .empty() }
                        return player.rx.seek(to: Constants.introEnd).andThen(.just(.didSkipIntro))
                    }
                }
            ]
        )
        .share(replay: 1)
}()

private static func skipIntroReducer(state: SkipIntroState, action: SkipIntroAction) -> SkipIntroState {
        switch action {
        case .didSkipIntro:
            return .hidden
        case .hasIntroStarted(let hasIntroStarted):
            return hasIntroStarted ? .showing(secondsLeft: Constants.skipIntroTime) : .hidden
        case .secondsLeftChanged(let secondsLeft):
            return secondsLeft == 0 ? .skipping : .showing(secondsLeft: secondsLeft)
        }
 }

You can also check the full implementation here: PlayerViewModel_04.swift.  Again, here’s a diagram representing the data flow:

In the code above we have created three feedbacks:

The first feedback is where we bind all inputs into the system. Typically it would have Observable.merge with all the inputs but in this case we only have one input. This is actually not a true feedback loop since it doesn’t use the state Observable. But we still represent it as a feedback loop since in RxFeedback every input into the system must be done like this.

The second feedback reacts to the state and will start counting down when the intro is showing

The third feedback reacts to the state and when it switches to skipping it will seek to the end of the intro. Once the seek is done, it emits the didSkipIntro event.

While at first sight it might seem like a lot of added boilerplate, we've found that it really helps us to break down these complex state machines in our code base into something that can be understood more easily. It also makes debugging easier since you can simply make a Higher Order Reducer that will print every state change into the console. 

RxFeedback also comes with a few prepared feedbacks that will save us some boilerplate. For our example, our second and third feedback react to the change of the state. It works because our state is very simple but in real life the state will contain more parts and we could start our feedback multiple times by accident. To fix it, we could add distinctUntilChanged like so:

#javascript#
state
.map {
     guard case .showing(let secondsLeft) = $0 else { return nil }
     return secondsLeft
}
.distinctUntilChanged()
.compactMap { $0 }
.flatMapLatest { secondsLeft in 
   return Observable.just(.secondsLeftChanged(secondsLeft - 1)).delay(.seconds(1), scheduler: MainScheduler.instance)
}

However, we would find ourselves repeating this code all over again. It is better to use the react feedback included in RxFeedback.

#javascript#
react(
    request: {
        // here we define under which conditions we want to start the feedback
        // if we don’t care about this change return nil and it will be ignored 
        // distinctUntilChanged will be applied on the output
        guard case .showing(let secondsLeft) = $0 else { return nil }
        return secondsLeft
    },
    effects: { secondsLeft in
	 // here we start our side-effect
        Observable.just(.secondsLeftChanged(secondsLeft - 1)).delay(.seconds(1), scheduler: MainScheduler.instance)
    }
),

You can see the final implementation in PlayerViewModel_05.swift. 

Once you start using RxFeedback you will see feedback loops everywhere in your code. It will help you formalize them and also provide you with a unified way to handle them across the codebase.

While RxFeedback was meant to replace ViewModels as the new architecture, it lacks some key features like reducer composition that would be required to use it on a larger scale. For that purpose, other architectures like TCA would be better suited.

For apps like Showmax, which is written entirely using MVVM in RxSwift, but which would still like to enjoy the benefits of Reducers to handle state, it can be an ideal choice.

Handling Feedback Loops in your RxSwift Code

Join us and build a streaming platform used by millions. 

We’re excited to witness the recently announced partnership between Showmax, Sky and NBCU coming to life here in Prague. Following the recent announcement of our partnership; that will bring some of the world’s best content and technology to streaming customers across sub-Saharan Africa, Sky are hiring developers to make it happen.

You might know Sky for TV. But we’re more than that. We’re a tech business. We’re broadband and broadcasting, streaming and sports, mobile and magic. And we’re proud to be part of the Comcast NBCUniversal family, creating incredible technology and entertainment that connect millions of people to the moments and experiences that matter most. 

We’ve already rolled out NBCUniversal’s streaming platform Peacock to our European audiences. Now you have the opportunity to work on an exciting new venture powered by Peacock’s leading, globally scaled technology. 

Millions of customers use our apps and we have always been looking to improve by pushing the boundaries in our products and services providing every one of our customers experiences they love.

We are looking for a strong Java Developer who would like to help develop our latest large scale CMS project for Sky OTT International.  Working in an Agile environment, this role will suit an experienced Java Developer who wants to broaden their skill set in an international multilingual CMS application.

Deliver excellent quality software using agile techniques

Assist in developing application deployment, monitoring and automated control artifacts

Strive for continuous improvement – be able to improve existing practices and techniques from within the team with enthusiasm

Assist in the development the CMS application using Java and Spring

Unit, Functional and Performance test code for robustness including edge cases, usability and general reliability. 

Assist in the maintenance and support of the AWS infrastructure, Postgresql Database and Object Caching layers

Actively help the team improve our automated test systems

Extensive experience creating quality Java based applications

Having worked on live high-volume websites

Proficiency in at least one Continuous Integration tool (ideally Jenkins)

Experience in automated testing frameworks

Ability to use a wide variety of open source technologies and cloud services such as AWS

Strong understanding of Spring and Spring Boot

Extensive experience with Agile Principles

Exposure to Content Management and Content Distribution Networks

Knowledge of Unix/Linux and scripting languages (Bash, etc.)

Working in an international environment on an impactful globally scaled technology in cross-functional team with an agile approach 

Open and healthy working culture where we care about people as much as about stability of the code  

Hybrid work, combining working from our office to be closer to the team and working from home 

Work life balance thanks to flexible working hours

Generous free day scheme providing 25 days of holidays + 5 days of on-demand leave (sick days)

Ergonomic office and kitchen full of tasty snacks 

Contribution to Multisport Card or Benefit Card 

Events, meetups, hackathons in the office or elsewhere
 

Our team develops a React application that brings video streaming to a wide range of devices. We run it on desktop and mobile web, Smart TVs (LG, Samsung, Hisense), and our own set-top boxes (Explora Ultra, Streama). 

In order to support so many very different platforms and still have the ability to expand to new ones in the future, we develop our own device SDK and a video player. The React UI then sits on top of it.

We have a very experienced team, consisting of senior developers and QA engineers and we work closely with our product managers and designers. 

The tech stack itself is pretty straightforward. We use React with Redux for state management and everything is written in Typescript. We keep the stack simple with performance in mind because many devices (low-end TVs, set-top boxes) don’t have the high compute power we have all become used to in recent years. 

Sometimes we have to look under the hood of React and Javascript to optimize rendering speed and responsiveness. This makes our work very challenging but also fun and rewarding. We often have to come up with unique solutions to unique problems that could happen only in the world of Smart TVs.

About the team

How we work

Read our blog posts #apps

Integration Tests

Enhancing Android TV App Development: A Journey of Innovation and Improvement

Exploring Kotlin Multiplatform Mobile: A Comprehensive Overview

Handling Feedback Loops in your RxSwift Code

Integration Tests

Enhancing Android TV App Development: A Journey of Innovation and Improvement

Exploring Kotlin Multiplatform Mobile: A Comprehensive Overview

Handling Feedback Loops in your RxSwift Code

Check out our other teams