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.

You work a lot remotely. How is it possible when you have the Smart TV wall in the office?

It wasn’t common a few years back. We used to be in the office all the time in order to be able to use our TVs for development. This changed instantly with covid pandemic when our offices were closed. We had to find a way to make our development scalable even in such conditions. 

Long story short, we took a CandyBox, a surveillance camera, made a custom VPN routing to allow direct communication with the TVs and the remote development environment was ready. We had a talk about this on the Frontendisti meetup and there’s also a blog post so feel free to check it out. It really gave us the flexibility we needed and opened even more opportunities for hiring.

To learn more about the CandyBox and the solution come chat with Tomáš and Petr Češka from Suitest at the next WeStream meetup on June 29. 

What is the core idea or value that pushes the team forward?

I think the core idea is that we are all responsible for what we do, it is our product, and we work on it together. We really try to help each other every day and in case of issues everybody is willing to step in and help to resolve them. 

And that doesn’t only apply to our team but to everybody around. That’s the spirit we try to embrace here.

The Showmax smart tv & web team that was led by Tomáš is currently in the experienced hands of Michal Topinka. You can meet and chat with both at the upcoming WeStream meetup on June 29 in our offices in Nové Butovice. 

*DStv is a sub-Saharan African video entertainment company owned by MultiChoice. It was launched in 1995 and provides multiple entertainment channels and services to customers across the continent via satellite, online and mobile apps.

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

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.

Testing All Endpoints in Django: An Overview

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

By Showmaxers, for Showmaxers: Linux Containers

Unexpected redrawing in SwiftUI