Modernizing some of SoundCloud’s Android app storage layers, I’ve been especially invested in databases, and have been migrating a lot of the core entities of the app between our in-house ORM and industry-known alternatives, as Room and SQLDelight.
There are many parts to that work, ranging from understanding the current standings of the schemas to coming up with improvements, risk mitigation or reducing overall tech-debt. It has been a great opportunity to learn about the internals of SQLite, the RDBMS that powers most mobile apps, widely popular in Android but that also backs iOS’ CoreData framework.
Today, I want to…
At SoundCloud, we are around 20 Android engineers, working in a multi-module project with more than 10 databases, with multiple tables each. And that’s only the Android app!
As software matures, more functionality is added, code gets moved, re-written or removed. In the same rhythm, team members change and with them historical knowledge might get lost. For that reason, it is important to have a well-organized project, that is inviting for new contributors while still digestible for one-off readers.
Understanding how data is structured can be very helpful as an initial step for diving into the abstract modeling of the…
The story is more common than it seems: a new feature is developed and tested extensively in-house, but only when the client applications are deployed, the engineering team discovers the extra production load and seasonal request rate. A hot-fix is needed! But now it’s too late: we cannot force our users to update their apps or refresh the page on their web browser.
As we’ve discussed in part 1 of this series, clients are in a way bigger number than our servers, and even though we have applied some of the techniques previously described to make our clients smarter, there’s…
When a request to a server fails, it is very tempting to issue another try to the same route, as a way to increase reliability of systems or mask transient problems to the end-users.
How often is this a good idea? Never. Well, more or less.
Today, many RPC libraries provide developers with built-in functionality for retrying requests, making it really easy to hammer servers with more and more load. Thus, retrying requests by default is not a good idea, instead, one must consider the situation and only then decide whether a retry is worth it.
Periodically triggered jobs are very common in modern applications, especially in the client-server model: uploading notes, analytics events or backing up data are good examples of timely operations that a developer might decide to trigger at a specific rate, for example once per hour, or at 3 a.m. when the user isn’t actively interacting with the device.
Now, handling the computational load can get tricky since the number of clients is a magnitude larger than servers.
Starting from Android Lollipop, developers have an API that can be used to capture parts or the entire visualization of a device’s screen: MediaProjection. James O’Brien gave a great description of that usage in this article.
From Android 10, the MediaProjection API was extended to support the audio capture use-case. That is especially interesting if your app does any sort of streaming or Twitch-like broadcasting. In some cases, though, you might want to have finer control over when or what can be captured, either for user-privacy reasons, or content-protection (i.e copyright).
It is a common misconception to think that software development is all about writing code, but in reality, that is not where engineers invest most of their time. Instead, most of the effort is put in designing the application and understanding how it behaves once it is deployed.
As applications grow larger and more complex, it is critical to establish a process around how bug fixing can be organised. For Android apps, there are multiple tools that will support teams to collect and analyse crashes and other debugging information.
When building any software, we want to provide the best possible experience to our users, giving them the feeling of being in full control and taking the most value out of our applications. With audio-related software, that is not different: a very important metric for tracking playback performance is latency: minimizing the time it takes from pressing the ‘play’ button and listening to music is key for providing a seamless impression.
Today we will visit some concepts on digital audio, learn about how part of it is done on Android devices, and understand how buffers play a key-role in providing…
During I/O 2016, Google announced it was developing a new way to bridge the gap between the web and native apps, by making them as easy to access as a simple click in a link: Instant Apps, made of small data-chunks that can be temporarily loaded on the device with no extra going-to-the-Play-Store steps.
Selected developers started adapting their apps to the new format shortly after: the feature rollout will happen in stages, beginning a small set of devices and starting on Android Marshmallow and above.
In this post, I’ll introduce a little of my experience with the Instant Apps…
Apesar de uma prática já bem estabelecida dos círculos de desenvolvimento de software, principalmente do lado back-end, a Entrega Contínua (Continuous Delivery, no inglês) e a Implantação Contínua (Continuous Deployment) ainda dão seus primeiros passos no desenvolvimento mobile.
Neste artigo, vou apresentar a Publishing API (que faz parte da Google Play Developer API), como interagir com seus recursos e eventualmente possibilitar a prática do Continuous Deployment para apps Android. Mas, antes:
Em linhas gerais, o que é a prática do Continuous Deployment, e por que eu devo me importar com isso?
Se o seu time utiliza metodologias ágeis para desenvolvimento…