How we expanded the MyŠkoda app to include Wear OS support

The idea of supporting Wear OS

The MyŠkoda mobile app, the main B2C channel for communication with owners of Škoda brand vehicles, is being developed as part of a collaboration between Green:Code and Škoda Auto. It has become a standard part of all vehicles sold. A few years back it was fully rewritten into current technologies like Kotlin, Jetpack Compose, Koin or the Škoda Flow design system. The objective was to ensure the highest quality when complying with clean architecture principles and advanced modernisation. When Škoda later came up with the idea to support integration with watches with Wear OS, we decided, instead of creating a completely new project, to expand our current implementation.

Design testing (proof of concept)

In order to validate the feasibility of the idea, we first put together a Proof of Concept that was meant to confirm the whole idea was viable. In this we focused on the following: 

• Exploring Wear OS integration with parts of the current architecture
• Exploring data synchronisation between Wear OS and the mobile app
• Exploring remote launch  of the mobile app from Wear OS
• Performance testing (the application uses DB with encryption, networking and MQTT communication and other more demanding operations)
• Exploring  of testing and debugging  for the Wear OS application

In addition to the above, we identified several adjustments that we needed to include in future phases of app development: 

• Extract part of the logic for the application skeleton (framework) into libraries (logic for navigation between screens, architecture tests and more)
• Decide whether to extend the current functionality to include Wear OS support or if we would write fully new and separate functions
• Edit part of the shared code so that it would be even more independent (general)

What you need to bear in mind when designing a Wear OS app

VDeveloping an app for Wear OS brings specific challenges that differ significantly from traditional development and design work for mobile devices. It is necessary to take into account the watches’performance limitations. These devices often have less computing power, smaller memory and more limited battery capacity. From a user interface (UI) perspective, it is important to design simple, clear and readable screens adapted to small round or square displays. The user experience (UX) should reflect the fact that interactions on the watch are short and often happen on the move. In addition, one also has to take into consideration compatibility with different types of devices, including different versions of Wear OS and different manufacturers.

What the new Wear OS app can do

The new MyŠkoda for Wear OS is designed such that it enables users to have the most important  information and news about the vehicle’s functioning always on hand. At the same time, the functions must be readily available and easy-to-understand on a small watch display. The current version includes the following: 

• An easy-to-read dashboard with basic information (e.g., the battery level or vehicle range)
• Function for remote lock and unlock of the vehicle
• Function for remote start and stop (turn on/turn off) of the charger

We are currently actively working on other functions.

Architecture

Original architecture

The MyŠkoda application’s Android project uses the principles of clear architecture with a large number of encapsulated Gradle modules. Currently there are more than 180 of them. A few of them perform a support function during development, but most of them cover the logic of the entire complex application. These modules are categorized into folders according to their type.

Prior to expanding the code to include Wear OS support, it included modules of the following types: 

• library : Code that can be used in other types of modules. A typical example is a module containing a networking layer. However, this also includes shared code that uses, for example, multiple modules of the feature or section type. An example might be a generic map to which a pin or route can be added.
• feature : Individual application functions. Modules of this type cannot use code contained in other modules of this type. This guarantees their independence and the ability to add or remove individual functions without affecting others.
• section : Modules of this type serve to unify multiple functions. An example is a dashboard that displays a function for controlling the air conditioning and a function for charging control. As with feature modules, these modules cannot depend on other modules of this type.
• app: Top-level executable Android app. It contains the basic skeleton of the app and integrates other necessary modules. A typical example is a production-type mobile app. However, this type of module also covers a possible demo app or an app for another type of device.
  

Expanding the architecture to include Wear OS

When designing the architecture for Wear OS features, we considered two options - to expand existing features or to implement Wear OS features separately. The first option offers a simpler encapsulation of the individual functions, as the common logic for both mobile and Wear OS functions is provided within a single Gradle module. The second, on the other hand, affords better separation of logic and less complexity, as the Wear OS functionality may have a radically different behaviour. The disadvantage is the need to extract some common logic from the feature module into the library module to make it available for the feature-wear module. After discussion with Android developers in a Community of Practice meeting and weighing the options, we leaned towards decoupling the logic. We now have two new module types.

• feature-wear : Individual functions of the Wear OS app. They have the same rules as the feature modules.
• section-wear : Includes section modules dedicated for the Wear OS app.

‍

By choosing this architecture, we got a large amount of logic for the Wear OS app (part of the library modules) almost for free. The code was already developed for the mobile app. 

This saved us time/costs in terms of larger units of months of development compared to greenfield development. At the same time, the Wear OS app uses identical code in the background: code that has been continuously developed and debugged for several years.

‍

Synchronisation of data between the watches and mobile devices

The Mobile and Wear OS apps operate almost independent of each other, sharing only code and processes during development. The Wear OS app only needs the mobile one for the initial user log in; it then continues to communicate with the remote backend API directly. Despite this, it is desirable from a user perspective to synchronise some states between the two apps. For this we use the Data Layer API.

Data Layer API

We use the Data Layer API for efficient data transfer between devices. This API is part of Google Play services and provides a robust, optimised solution for communication between smartwatches and paired mobile devices. Developers have several transfer methods at their disposal:

• DataItems for synchronising state (status) data,
• Assets for larger binary files like images,
• Messages for one-off events in real time,
• Capability API for determining options for device synchronisation.

Thanks to these tools it is possible to create smooth, responsive interaction between the mobile and the wearable parts of the application.

‍

S využitím Data Layer API aktuálně probíhá synchronizace přihlášení a vybraného automobilu.

Log in synchronisation

We use a log in from a mobile device to log the user into the Wear OS app. This is for a number of reasons: 

• Watches generally have a small display that is harder to enter log in information on.
• Syncing logins from the mobile app is one of the recommended approaches according to Android documentation.
• Some functions in the watch are tied to functions in the mobile app.

‍

Notification synchronisation

By default, Android synchronises notifications received on your mobile phone to your watch. In our case, however, the MyŠkoda Wear OS app can receive and display notifications on its own. Since this would cause duplications, it was necessary to modify the configuration:

• To ban automatic synchronisation of notices between devices

• Configure the same unique ID for the same notification for synchronisation of removal of notification (when removing a notification on one device it will also disappear on the other)

‍

UI development

The MyŠkoda app for Wear OS uses the Jetpack Compose for Wear OS library which complements the Jetpack Compose implementation in the Škoda Flow Design system. The Jetpack Compose for Wear OS library simplifies development and ensures consistent behaviour across devices. The Škoda Flow Design system ensures and delivers the same design language in terms of colour, fonts, components and icons.

The Horologist libraries helped us a lot during development. One of its most used functions is Compose modifier fillMaxRectangle(), which configures the size of UI components into the maximum possible visible block(s). Thanks to this, we have a guarantee that all components defined in the UI will show properly regardless of the shape of the watch display (round vs. square).

Testing and troubleshooting the Wear OS app

Testing the Wear OS app takes place as a rule via Android Studio and ADB (Android Debug Bridge), which support connections via Wi-Fi, USB cable or Bluetooth.

As soon as connection is made the app can be tested and tuned as on any standard Android device – you can follow reports using adb logcat, install builds via adb install, carry out debugging in Android Studio or make use of adb shell for access to a lower level. 

When connecting via Wi-Fi, you need to turn on Developer options on the watch, allow forWireless debugging and then pair the device with the developer computer. This is done using the ADB command:

After successful pairing, the device is connected using the typical command:

It sometimes happens that watches connected via Wi-Fi disconnect on their own and then cannot be reconnected. That is why in the majority of cases, when testing on a physical device, we used a USB cable connection. We recommend that you use emulators during regular development activities.

Available in Google Play Beta

The Wear OS app for MyŠkoda is already available on the Google Play Beta channel. We will be glad to have you test it and share your thoughts on what we can improve.

‍