One player, every target
Android, Linux and desktop share a codebase. A player per platform is a player per bug, and this estate has too many platforms for that.
One buildAndroid, Linux and desktop
Build
Cloud
Digital Signage
The estate is whatever was purchased over the last few years: a retail stick, a Linux terminal, a custom panel. They have to show the same scheduled content, including through a network that drops in the middle of a trading day.
Someone who is not an engineer has to run it. A group with forty sites sees those sites from one login, on hardware nobody is about to replace.
- One player, every target
- Playback that survives the network
- A studio the marketers can use
Playback that survives the network
Content is scheduled centrally and pulled with enough lookahead to keep playing when the link drops. The screen does not go blank because a site lost its connection at noon.
Lookaheadplayback through a dropped link
A studio the marketers can use
Images, video, PDF, a live dashboard, a web page, arranged by drag and drop. If operations has to publish every change, the system gets abandoned.
40sites from one login
The build
The constraint is the device
These screens run for years. Designing for a current flagship and hoping the rest catch up does not match how this hardware is bought. The player has to stay quiet on a low-powered stick and steady on a terminal that is on all day.
Offline is a normal afternoon
A drop during trading hours is Tuesday, not an incident. Lookahead is the difference between a schedule and a stream. The screen keeps what it already has and catches up when the network comes back.
Forty sites, one place to look
The management side is multi-tenant. A group schedules once and does not keep a build per location. That is ordinary cloud work, and it is what makes the player something you can roll out rather than demonstrate.
The publisher is not an engineer
The studio exists so a marketing team can change what is on the wall. Real content is not a folder of videos. A system that only an operations engineer can feed does not stay fed.
How we worked
What a device fleet asks of us
Efficiency as a feature
How little the player needs is not a tuning pass at the end. It is why one codebase can sit on a stick and on a terminal.
One defect, fixed once
Forking the player per platform feels faster until the same bug lands in two forks and not the third.
A portal that finishes the job
If publishing still needs us, the product is not finished. The people who change the screens have to be able to change the screens.
Technology
What it is built on
- C#
- SQL Server
- Flutter
- Java
- Go Lang
- Kotlin
- Angular
- WPF
- Protobuf
More work
More Cloud and Build work
Need something like this built?
Tell us what you are trying to ship and an engineer will reply within one business day.