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.

Explore the creative journey of designing swag and cultivating a remarkable culture at Showmax Engineering. Discover how we've built a unique workplace identity that fosters innovation and teamwork

Designing Swag and Culture: Unveiling the Remarkable | Showmax Engineering Blog

As a marketer, it's always a great feeling to see people happy with a product you've helped promote or enjoying the cool stuff you've made to create a buzz around a brand. When it comes to employer branding, it's pretty much the same story. Everything we create is meant for people to enjoy and share. In this look-back post, I'd like to tell you the story of the Showmax Engineering brand and how much we loved working on all the branded stuff that we now see our colleagues wearing or using in the office, at our events, and during their free time.

For five years, Showmax Engineering didn't have a dedicated employer branding manager or a designer to handle the designs needed for online promotions and events. We pretty much dealt with things as they came up. One story I heard was about a hiring event where the team ordered light yellow t-shirts simply because they wanted to stand out. Nobody really cared about the brand colors, which were primarily black with pink and grey accents. 

Showmax team at the COFIT conference back in 2018.

This approach resulted in having several versions of the logo or logo splash, which led to my first mistake when I tried to upload the same logo icon to all our social media accounts. Unfortunately, I ended up replacing the new one on one social network with the old one, which dominated the rest of the networks. We needed to bring some order to the chaos and create a brand guide. It took us a good six months to get there.

The team used two versions of the logo icon and different versions of the logo and the logo icon in the static logo version and its animated splash.

We knew we were building a brand that would hopefully last for years. So, we reached out to Daniel Valčík, our Product Design Solution Lead, to do some research, provide recommendations, and create an inspiration board. Since we were proposing a brand and logo derived from the main Showmax brand but creating a new sub-entity, we needed to sell both the idea and the proposed solution. Fortunately, we made the right choice in picking Daniel to help us, as his recommendation paved the way for success with the central team. So, starting in 2021, we had just one logo. Alongside Michaela Mašková (Míša), our contracted designer, we put together the brand guide. Then, we embarked on the fun part – working on our swag.

Looking back, I can see that the time when we were laying the foundation – the brand, logo, and logo style guide – was a fantastic "incubation" period for Míša and me to get to know the team, its spirit, and its approach to self-promotion (basically, they despise it). The folks at Showmax are genuinely nice, open, and caring about the impact they have on people around them and on the world in general, and they have a fantastic sense of humor. They also, for the most part, love their sports. Knowing this mindset, we approached the swag with a focus on making it practical (no more wasteful items), ensuring high quality, and making sure everything matched well to create a cohesive look.

This is our very own and favorite, soft and warm hoodie.

The new logo allowed us to create a series for various occasions. This one is for alumni, while another one was designed for Showmax teachers.

The reusable party and event cups have two design types.

Weekend or business travel backpack and the cap that comes in handy at the summer offsites.

What we're most proud of, and what kept Míša burning the midnight oil, is the sports set. We designed a softshell jacket, sports t-shirt, headband, and cycling dress, all produced in collaboration with the Lavi sportswear brand. Since everyone's opinion matters at Showmax, we took a vote to pick the best design. Below, you'll find the shortlist of the designs.

And here is the one that emerged as the winner. We call it the Chip design.

The pattern combines a microchip subtly connecting engineering with a runner on the "chip track." Most people ordered the black version, which made us happy since it matched the brand colors perfectly.

The cycling set: headband and the t-shirt (left) and  the runners t-shirt (right).

As the chip design was the most elegant, clean, relevant, and the universal symbol of the engineering team it represented, we used it on plastic cups and all the invites to the sports events, not just on the sports apparel.

Eventually, we also applied the design to the name cards used for reserving a table after implementing a flexible desk policy.

In 2021, our team leaders launched a fantastic initiative: defining the team values that we were already living by but hadn't put down in writing yet. The goal was to keep these values intact, even as the team was rapidly growing and working in a hybrid mode. Through various workshops and discussions with team members, we came up with a set of ten values. Our job was to introduce these values to the team and help everyone (especially newcomers) embrace them. 

First, we took on the challenge of sharing our company's values in a fun way. Since there was a ton of paper used for boring presentations and guides about our values, we decided to save time, energy, and paper by putting our values on stickers. We got inspiration from comics, movies, and the IT world. You can see what we came up with below.

We placed one of the stickers on kids' T-shirts distributed during the Kids' Day at the office.

Next, we thought about how to get folks excited about living these values. We heard some team members talking about fun company pins, so we combined these ideas and created a system to recognize and reward people who embody these values with a pin. It was a more significant task than just creating another branded item, but working with Zita Pivcová (Head of HR) and Anička Hlaváčková (formerly from HR at Showmax) went as smoothly as always. Together, we defined the system, its levels, and how people would collect simple badges and quickly designed the pins to earn a metal pin. You can check out the pin designs below. 

Anyone who collects three of the same basic badges earns a metal pin.

The first pin comes for free when you join Showmax.

Last year brought two new items that we've been thoroughly enjoying. First, we have a sofa adorned with the same patterns you've seen on the pins. We bring it with us to events where we chat with people about Showmax and how we operate. The idea for the sofa came up after a conversation with Daniel, who presented the concept of Showmax as a cinema in our customers' pockets — a cinematic experience accessible from the comfort of a living room sofa. The second exciting addition is our sweatpants, designed after the last wave of COVID-19 and enjoyed during our last offsite in Znojmo.

Designing Swag and Culture: Unveiling the Remarkable Spirit of Showmax Engineering

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

Explore how user clustering through k-means algorithm, graph algorithms, and content embedding models enhances content recommendations. Learn about the fusion of classic methods and modern technologies to understand user preferences better.

User Clustering for Improved Content Recommendations: A Fusion of Classic and Modern Techniques

Recently, our Content Discovery team, stationed at the intersection of our vast video content library and the users choosing what to watch on our streaming platform, embarked on an essential mission: clustering users based on their similar viewing behaviors to refine our video content recommendations. We explored various modern algorithms, but interestingly, it was the classic k-means algorithm that proved to be the most effective. Let's dive into our journey and see how we tackled the challenge of user clustering.

In the world of personalized experiences and custom offerings, our way of creating group-based content recommendations offers a really interesting option. While acknowledging its drawback, we must also recognize a notable advantage – this approach requires significantly fewer computational resources. And on top of that, it opens up a whole new space for diverse analyses and A/B testing within these newly defined user cohorts. Some things work better for certain groups of users, and we really wanted a good way to see that. And now, we have achieved it.

We kicked off with a straightforward approach: constructing a matrix where each user corresponds to a row and each movie or TV series is represented by a column. The matrix elements were binary, taking the value of 0 or 1 based on whether the user had viewed a particular title. With the groundwork laid, we proceeded to implement a clustering algorithm of our choosing and eagerly anticipated the outcomes. 

However, as we delved into the results, we discovered significant drawbacks inherent in this approach. Firstly, we realized that the distance between user vectors remained constant whether they both watched a particular title or neither did. Imagine a scenario where there are 10,000 titles available, and two users have each watched 5 titles. Among these, only 3 titles are common to both users. Strikingly, this results in a situation where they share 9,996 assets, whether watched or not, while the actual shared viewing experience comprises just 3 titles. Our intention was to give more weight to the positive data in order to emphasize shared content rather than the absence of it. Regrettably, our results didn't align with this desired emphasis.

Furthermore, another issue emerged: The similarity measure treated users who watched similar titles identically to users who had vastly different viewing preferences. For instance, consider Alice, who watched "Top Gun," and Bob, who saw "Top Gun: Maverick." But their dissimilarity is exactly the same as Xavier and Yasmine, who respectively viewed "Paw Patrol" and "Big Brother" – two very different titles. We realized we needed to address these challenges for a more effective user clustering solution.

To address these challenges head-on, we pivoted toward the realm of graph algorithms. We opted to represent our users as individual nodes within a graph, with edges signifying instances where two users shared a common content-viewing experience. These edges carried weights, indicating the number of titles shared in common – a vital shift that allowed us to focus on the positive data, accentuating the shared preferences rather than disparities. Additionally, this approach unveiled an intriguing aspect: when two users had similar viewing histories, it often meant numerous other users had also watched the same titles, leading to an abundance of shared neighbors within the graph. It seemed like the path forward.

However, it's important to note that this graph-based solution came with a significant memory overhead, unlike the initial matrix approach. In big O notation, the memory requirement was proportional to the square of the number of users, while the matrix approach was simply a product of the number of users and the number of titles (considering Showmax has several orders of magnitude more users than titles). To mitigate this, we explored various divide-and-conquer techniques, which indeed yielded meaningful results and stunning visualizations (as depicted in the figure below). 

Visualization of clustered users using a graph-tool library. Each user is represented by a node on the exterior circle and edges signify commonly watched titles.

Despite these successes, we encountered a roadblock: the graph-based approach consumed excessive CPU resources, leading us to make the decision to close this particular avenue of research. Still, we kept some of the charts as stunning and CDR-relevant office decorations.

After our experiment with graph algorithms yielded unsatisfactory results, we circled back to the original matrix approach and sought to refine the user vectors for a more accurate depiction of user preferences. Let me discuss some of the approaches we considered but ultimately did not implement for production.

One straightforward method involves the use of dimensionality reduction algorithms, such as PCA (Principal Component Analysis), t-SNE (t-Distributed Stochastic Neighbor Embedding), or UMAP (Uniform Manifold Approximation and Projection). The underlying concept here is that when two titles are watched by the same users, the corresponding columns in the matrix should exhibit a strong correlation, and the resulting lower-dimensional representation should have a composite column that captures the essence of both titles. In such cases, the specific title a user watches becomes less significant – the resulting vectors should be remarkably similar.

Another related technique is the use of autoencoders. These are neural networks with identical data on both the input and output layers, with a relatively compact hidden layer positioned in the middle. Essentially, the network attempts to squeeze as much information as possible through these artificially created bottlenecks. We're particularly interested in the vector at the narrowest point, which holds valuable compressed information. Autoencoders find extensive application in recommender systems due to the nature of the network, which aims to predict the content a user might watch based on their past viewing history, albeit with the distinction that the input is precisely what is being predicted.

However, we had another tool at our disposal – a content embedding model. This model allowed us to measure the similarity between two titles using cosine similarity. We integrated this into the refinement of our original matrix structure. When a user had watched a particular title, we assigned a value of 1 to that matrix position. When a title wasn't watched, we searched for the most similar content they had viewed and plugged the similarity score into our matrix. As a result, our matrix columns became strikingly correlated for similar titles. This transformation enabled us to choose a subset of reference titles, setting the stage for a relatively simple clustering algorithm, k-means, in our case.

This approach also had an interesting side benefit - it made the process more explainable. The user features were designed based on "how similar the content is to the title the user watched," and the k-means clustering provided cluster centers that held valuable insights. This allowed us to describe the clusters in terms of their similarities to the reference titles. For example, we could say that a cluster was most akin to titles of a certain genre while having little similarity to another genre. Alternatively, we could explore which groups of users resembled a specific set of titles the most. This unexpected advantage brought a layer of clarity and understanding to our clustering results, enhancing the overall value of our approach.

In conclusion, our journey through user clustering led us to explore graph algorithms and content embedding models, blending classic and modern techniques, and arriving at an innovative solution. We discovered that, when it comes to understanding preferences and improving group recommendations, the pursuit of explainability and efficiency is the most effective. Our adaptation of the k-means algorithm empowered us to create user cohorts that provided not just valuable analytical insights, but also a clear, interpretable perspective on the preferences of various user groups. Our approach demonstrates how the fusion of classic methods and modern technologies can progress the understanding of user behavior in the ever-evolving digital landscape.

Clustering Users for Better Content Recommendations

Learn how to systematically test all endpoints in Django using powerful testing tools like the Django test framework and pytest. Ensure a seamless user experience and robust security by identifying and fixing broken links and maintaining all endpoints. Dive into this step-by-step overview of the testing process.

Comprehensive Guide to Testing All Endpoints in Django

Testing is a crucial aspect of software development, particularly in web development. Even a single broken link or endpoint can result in a poor user experience or security vulnerabilities. Luckily, Django offers powerful testing tools, including the Django test framework, which can be enhanced with third-party packages like pytest to tackle these challenges.

When dealing with large, long-standing systems, it's common to have numerous endpoints. Many of these endpoints may be infrequently used but still necessary. Unfortunately, they can easily slip from our minds when implementing changes, leading to unforeseen impacts on users that go undetected.

In this developer blog post, we'll dive into an approach for testing all the endpoints of a Django server. We'll utilize the "show_urls" command from django-extensions and the "get" method of pytest's django_app_factory plugin. Together, these tools will enable us to systematically test each endpoint. Join us as we walk through the entire process, providing a detailed explanation of how it all works.

The show_urls command is a useful tool provided by django-extensions that offers a list of all endpoints in JSON format. Each entry returned has four fields: url, module, name, and decorators. By iterating over the returned list, we can test each endpoint with a GET request to identify broken links and ensure that all endpoints are functioning properly.

To implement this test, we can start by using Django's call_command method to run the show_urls command and get a list of all endpoints.

The first step after acquiring all endpoints is to sort them based on whether they are maintained or not. This can be achieved by checking the module field that contains “path” for the endpoint, because the first part of the path is the app name. 

Having the app name, we can now easily check if the app is maintained or not, and skip the ones that are not.

Next, let's focus on constructing the URL for our GET request. To ensure we have all the necessary data, we'll need to consider adding query parameters and keyword arguments to the URL field. In Django, we can achieve this using the url field and leverage the Django syntax.

For keyword arguments, there are many that are generated by django as a model. These models follow a pattern that we can easily use and replace for its intended value. But there are some that don’t follow this pattern which are mostly custom endpoints that need to be checked individually to add their value.

Unfortunately, there is no easy way to check query parameters as there is no denotation for them on the url, so they need to be checked individually by looking into the code, usually after a request fails.

In this step we need to create a high amount of pytest fixtures too as most of the values needed are model identifiers or are related to them.

Once we have built the URL and necessary data, we can perform the GET request using pytest's django_app_factory plugin's get() method. In this step, more fixtures may be required and there's also a possibility of internal errors occurring. I had some occurrences of implementation errors from old endpoints in production showing some good results from these tests already.

There is not much that can be done here other than waiting for a response and following to the next step or handling the errors that happen from time to time.

Finally, we need to check the status code returned by the GET request. If the code is outside the 2xx range and is not 405, indicating that the endpoint does not allow GET requests, the test will fail unless this endpoint is explicitly listed as expecting another code. The request follows redirects, so we should not receive any 3xx code either.

In conclusion, thoroughly testing all the endpoints of a Django server is a crucial step in guaranteeing the smooth functioning of a web application and delivering a positive user experience. Fortunately, with the powerful Django test framework and the aid of valuable third-party packages such as django-extensions and pytest, developers can effortlessly create comprehensive tests. By leveraging these tools, broken links and endpoints can be identified, and potential errors can be caught before they have a chance to impact users.

Testing All Endpoints in Django: An Overview

Read an insightful interview with Tomáš Zeman, the Team Leader of the Showmax Smart TV and Web Team. Discover the challenges and unique aspects of developing Smart TV apps, the importance of bug reporting, technology advancements, debugging nightmares, and the team's approach to software development. Gain insights into the transition to remote work and the team's collaborative spirit. Don't miss the opportunity to meet Tomáš and Michal Topinka at the upcoming WeStream meetup. Register now!

"Interview with Tomáš Zeman, Team Leader of Showmax Smart TV and Web Team"

At our Prague Sky | Showmax engineering office, we have a place where you feel like you are in a newsroom – you’re surrounded by the tens of televisions which our developers work on when testing the smart tv app. For three years, Tomáš Zeman has been leading the Showmax smart tv team. He kept everything working even after the Covid outbreak when we all worked from home and his team had to test the app on TVs remotely. Tomáš was among the first people who recently transitioned to the Sky teams, making this the perfect moment to speak about what makes his work special.

Your office corner is full of various televisions. How many have you had there? Are you counting the total number?

I stopped counting a while ago. But I guess we have around 25 or 30 TVs there currently and that’s the maximum we’ve had so far. We also have more models, which our customers don’t use that much, in storage, because we don’t have space to hang them all on the walls. 

As the time goes, it’s much harder to hang the same number of models on the wall, the screens grow in size. Back in 2017, we were able to find TVs with 32” screen easily, now it’s almost impossible – the cheapest models are usually over 40”, and such large screens fill up our precious space pretty quickly.

Why isn't it sufficient to have, for example, 5 pieces? Do they vary so much from each other?

Unfortunately, yes. Every year new models appear and usually come with new operating systems which bring us new challenges and bugs. 

But it doesn’t stop there. Even models released within a single year can behave differently. One firmware could be completely broken (memory leaks, bad garbage collections, etc.) whereas another one works just fine. 

The world of TVs is different from what we know on mobile phones or computers. Keeping the software in shape is harder. Not all vendors provide regular updates, major OS updates are even less likely. On top of that, users themselves are less used to updating their TVs – even if they are lucky enough to get an update to install they can ignore it.

Your team was the only one responsible for web and Smart TV apps at Showmax. Have you established a cooperation with any devs or testing team in Africa?

Actually, we have been in contact with (DStv*) front-end developers in Africa for years. They had a similar roadmap and usually faced similar issues while implementing new features like live streaming, 4K support and such. So, we often shared the knowledge.

Also, we have been working together on a new JavaScript player (we call it Connected Video Player) that has so far been shared between us and supports our complete set of devices. Other teams also considered or still consider using it.

Getting back to testing, are all the TVs available and common in Africa also available here? 

I think it varies from brand to brand. Some vendors sell very similar TVs in both markets but there are others who, in Africa, sell very different models, different mainly in the behavior.

In the past, our African customers or colleagues shipped us several models – those we had major issues with – so that we could test the app on them. It’s not easy to get the stuff to Europe but sometimes it's the only way.

What do you do with TVs you no longer need?

I think each TV we have ever had still has value to us. Obviously, our TV lab in the office is not infinite so we sometimes have to take some TVs off the wall to make space for new ones. But we keep them in our storage and don’t have any plans to get rid of them as long as they are still officially supported. Old TVs are a treasure you can’t buy again and we never know what weird model-specific bug lurks behind a corner.

How long have you been leading the Showmax web and Smart TV team?

What has changed during those years in terms of technology and your approach to development of the app?

The world of Smart TV doesn’t evolve that quickly so we were not forced to completely rewrite our application using new technologies or change our approaches.

I think the only major change that we made was the transition from JavaScript (with Flow) to TypeScript. Other things like React hooks have been changing gradually.

Was there a truly challenging moment, a real debugging nightmare? 

Certainly! There were many moments. The world of Smart TVs is full of landmines 🙂

I will mention maybe the two weirdest ones.

We had customers on specific LG models often complaining about their apps randomly crashing. Our investigation showed that those models were crashing while trying to translate labels. We were not able to exactly determine the root cause on our TVs in the office so we only mitigated the impact, caught those exceptions and just left part of the app untranslated. 

But then, stranger things started happening. The app sometimes went from fully translated to partially translated state and back while you were using it. 

To continue with the investigation, we had to have the TV encountering these issues shipped from Africa to us. 

So, we then dug deeper and revealed a truly horrifying truth. There was a variable declared outside of a ”for loop” and used (read-only) inside of the loop. The code was really nothing special. Then when the exception happened, the variable was suddenly undefined, or with completely random value and such. It turned out that the garbage collector just collected the variable in use and the memory was allocated for something else causing it to crash. 

The for loop was part of an i18n external library so in order to fix this, we had to ditch the library and write our own implementation avoiding that particular issue.

So without having the TV shipped to the Czech republic you wouldn’t have been able to solve it. Terrible! And the second story?

The second moment was related to “stuck” promises in, again, LG TVs. 

We sometimes reload our app internally to make sure people have the up-to-date version. And during one of those reloads, the app stayed stuck and didn’t load. But, when you performed any user action, pressed any button on your remote, the TV loaded and everything was just fine.

It took a while to investigate this. Eventually, it turned out that the TV is another one-of-a-kind piece – one of the promises in bootchain remained pending forever due to some internal bug either in the promise implementation or in the TV SDK and the user action got it settled.

We basically called setTimeout with zero timeout and with a no-op function. A terrible hack to unblock the stuck promises, right? But yeah, it worked.

The world of old TVs is really full of surprises…

Tomáš at the WeStream meetup #2 in April

You have recently moved to Sky teams, to work again on the web app and you are already growing the team here in Prague. What do you expect from an ideal candidate for a job in your team? 

We develop in Javascript/Typescript and React but there are many libraries out there apart from React so we don’t really focus on knowledge of a certain framework. It may sound like a cliche but we look for smart and enthusiastic people who have strong core Javascript knowledge and are able to solve problems. 

And we can teach everything else that is specific to our team and not knowing it in advance is not really an issue.

Boosting App Performance with Baseline Profiles: A Comprehensive Guide for Android Developers

Integration Tests

Designing Swag and Culture: Unveiling the Remarkable Spirit of Showmax Engineering

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

Exploring Kotlin Multiplatform Mobile: A Comprehensive Overview

Clustering Users for Better Content Recommendations

Testing All Endpoints in Django: An Overview

“Spotted a Bug on Your Smart TV? Send It to Us!” Says Tomáš Zeman, Team Leader of the Showmax Smart TV and Web Team

Handling Feedback Loops in your RxSwift Code

Boosting App Performance with Baseline Profiles: A Comprehensive Guide for Android Developers

How We Migrated the Whole Content Delivery and Encoding Infrastructure from Debian to Ubuntu

Critical Success: Unleashing the Power of Teamwork Through DnD

4K UHD Experience During FIFA World Cup

JSON Python libraries overview

Women at Showmax: Eva Podbrdská

DjangoCon 2022 in Porto: Insights from the World’s Biggest Django Conference

Using view_component for Design System Implementation in Rails Projects

VMAF - Performance vs. Accuracy

WE ARE MIGRATING THE WEBSITE

Why Did Our Brazilian Colleagues Relocate to the Czech Republic?

Backend Developer’s Guide to Monorepos

Showmax Design System: The Precious

Continuous Research: When Non-Researchers Take the Lead

Cross-Functionality in One of our Backend Teams

Project Management Office at Showmax

From iOS Tester to Junior iOS Developer in 2 Years

Air-Pocalypse, and a DATA2022 Conference Amidst Wildfires

Adding Vite to a Sprockets-Based Rails Application

How We Updated the Thumbnail Generator

The Tale of Two Internets and IPv6 @ AWS Lab

IPv6 at Showmax

By Showmaxers, for Showmaxers: Is '{JSONB}' a Silver Bullet?

Our experience with SwiftUI on tvOS