In part one we described how running into Android’s method limit may leave you unable to build, and offered strategies you can employ to make your app fit into a single DEX file. In this part we share an alternative option: using multiple DEX files.
Backstage Blog RSS
The new SDK improves stream security and content uploading functionality, and modernizes the technology stack.
ECMAScript 2015 and CommonJS
The original version of the SDK was written in CoffeeScript, which is no longer a core technology at SoundCloud. This update provided us the opportunity to migrate our source code from CoffeeScript to ECMAScript 2015.
Web Audio API
The previous SDK neither provided a way to record sounds from Web Audio applications nor a way to upload Web Audio recordings. It shipped with a Flash component that handled recording and uploading of recordings. There was no way to specify an external file for uploading.
The new SDK ships with a recorder component that uses Web Audio and
The new SDK now includes a new player component. This component improves security for creator content and provides the improved playback stability.
September 21st, 2015 Android Mobile "Congratulations, you have a lot of code!" Remedying Android’s method limit - Part 1 By Matthias Käppler
At SoundCloud we have been building for the Android platform since 2010. Much has changed since then: the team has grown, the list of features has grown, and our audience has grown. Today, eight engineers are working full time on the official SoundCloud app, across various areas, with contributions pouring in from other parts of the organization. Due to the growing complexity and number of contributions, the app’s size has grown substantially. Currently the app consists of approximately 1200 Java source files, not counting tests, containing approximately 86000 lines of code. This doesn’t include native code, such as our playback or recording stacks.
We’re not the first to run into Android’s limits in terms of build tools. An internal limitation of Dalvik’s byte code format (DEX), which I will explain in more detail, can leave you unable to build after your codebase reaches a certain size. If you fail to anticipate this, it might happen during the most inconvenient time, such as when you are preparing for a release. Part of our job in Core Engineering at SoundCloud is to make sure our developers are happy and productive; not being able to build our app anymore makes for neither happy nor productive developers.
While there are a number of posts on this topic, I would like to describe in more detail what we have done to combat Android’s method limit, what things worked well and what didn’t work so well, what it actually means to use the
--multi-dexswitch and what you can do to improve application health with regards to size.
June 16th, 2015 Announcements API Introducing Rate Limits By Dean Hudson
At SoundCloud, we’re building an ecosystem where creativity thrives. Developers are an important part of that ecosystem. We’re continually inspired by how you use the SoundCloud API to support creators and listeners in innovative ways.
Beginning July 1, client applications will be limited to 15,000 play requests per 24 hour period. These limits are applied to developer applications using the SoundCloud API, and have no impact on the SoundCloud embedded player.
Only a small number of developers will be affected by this change, and we’ve contacted them via email to ensure a smooth transition.
What this means for you:
- You should review our developer documentation on rate limiting. Limiting API access is common for API providers. If you’re unfamiliar with rate limits or how they work, we’re here to help.
- You should monitor your play requests.
- Make sure the email account associated with your app is up-to-date, and keep an eye out for communication from our team.
This change does not affect the SoundCloud embedded player, and if you have not heard from us, your app is unaffected.
In the coming months we'll be introducing an application process for developers who'd like additional access.
This change is an opportunity for us to refocus our efforts and renew our commitment to developers. You’re an integral part of the SoundCloud community, and we look forward to seeing what you build next.
June 8th, 2015 Announcements API New playlist representations By Erik Michaels-Ober
Requests for playlists have always included the full track objects contained within. This representation may be convenient for playlists with ten or twenty tracks but can cause problems for playlists that contain hundreds or thousands of tracks. Requesting such large playlists could result in requests that take a long time to respond and that eventually timeout.
Today, we introduce two new representations for the
If you add
representation=compactto a playlist request, the request will return only the playlist itself, without any of the tracks it contains. This representation may be useful if you're purely interested in data about the playlist itself and not the tracks contained within.
Alternatively, if you set the
representation=idparameter, it will return the playlist along with IDs of the tracks contained within, without all the associated track meta data (artist, artwork, duration, etc.) If necessary, you can then individually fetch additional information about each track by filling those IDs into the
/tracksresource. This allows for greater parallelization and can help make your application more responsive when working with large playlists.
By default, requests for playlists will continue to include all the contained tracks. There is no need to update your application but we encourage you to take advantage of these new, more efficient representations of playlists.