This document provides guidance on developing mobile applications. It emphasizes building the right thing based on user research, having short feedback cycles through practices like continuous delivery and testing with real users. Developers are advised to fake implementations when needed and not strive for pixel perfection in tests. It also stresses the importance of getting team buy-in, being transparent in communication, and recognizing that solutions will need to evolve over time.

1. 1
We
lead
what's
next
in
music
We ain’t got
no time
Cutting corners without cutting quality
Danny Preussler, SoundCloud

2. 2
We
lead
what's
next
in
music
2017

3. Why Wear OS?

4. 4
We
lead
what's
next
in
music

6. Toolkit

7. Just start coding,
right?

9. Recruiting users

10. ● Understand users needs
User research

11. meanwhile

12. https://unsplash.com/photos/qFFjBvneV2k
Koin vs
Dagger

14. ● Separate Repository
● Shared Modules
● Flavor
Project setup

15. Jane Snow

16. Now start coding,
right?

17. Continuous delivery

18. Every master built pushed to the
internal PlayStore distribution
Closed and public beta early
CI/CD

21. Test driven

22. Red Green Refactor
•Make it fail
•Make it work
•Make it right
micro-cycle (minutes)

23. Be precise:
•You must not write more of a test than
is sufficient to fail
•Not compiling is failing!
•You must not write more production
code than is sufficient to make the
currently failing test pass
micro-cycle (minutes)

24. Be precise:
•You must not write more of a test than
is sufficient to fail
•Not compiling is failing!
•You must not write more production
code than is sufficient to make the
currently failing test pass.
micro-cycle (minutes)

25. Be precise:
•You must not write more of a test than
is sufficient to fail
•Not compiling is failing!
•You must not write more production
code than is sufficient to make the
currently failing test pass.
micro-cycle (minutes)

26. WTF

27. class LoginViewModel(): ViewModel() {
enum class LoginStatus {
NOT_LOGGED_IN, LOGGED_IN, LOGGING_IN
}
}

28. @Test
fun `initially its not logged in`() {
tested.loginStatus `should be` NOT_LOGGED_IN
}

29. class LoginViewModel() : ViewModel() {
...
var loginStatus: LoginStatus by
mutableStateOf(NOT_LOGGED_IN)
}

30. @Nested
inner class `when logging in` {
@Test
fun `should set loading status`() = runTest {
tested.login(this)
tested.loginStatus `should be` LOGGING_IN
}

31. @Nested
inner class `when logging in successful` {
@Test
fun `should set status to success`{
runTest {
tested.login(this)
}
tested.loginStatus `should be` LOGGED_IN
}

32. fun login(scope: CoroutineScope) {
loginStatus = LOGGING_IN
scope.launch {
loginStatus = LOGGED_IN
}
}

33. @Nested
inner class `when logging in successful` {
init {
runTest { tested.login(this) }
}
@Test
fun `should authenticate`() {
verifyBlocking(authClient) { authenticate(any()) }
}
}

34. fun login(scope: CoroutineScope) {
loginStatus = LOGGING_IN
scope.launch {
authClient.authenticate()
loginStatus = LOGGED_IN
}
}

35. Fake it
(for now)

36. interface PlayQueue {
val currentItem: Flow<MediaItem>
}
object TestPlayQueue : PlayQueue {
override val currentItem: Flow<MediaItem> = flowOf(TestFile())
private object TestFile = MediaMetadata.Builder()
.setTitle("test")
.setDisplayTitle("Test")
.setArtist("Majestro")
.setMediaUri(Uri.parse("https://s3-us-west-2.amazonaws…")
.build()

37. interface PlayQueue {
val currentItem: Flow<MediaItem>
}
object TestPlayQueue : PlayQueue {
override val currentItem: Flow<MediaItem> = flowOf(TestFile())
private object TestFile = MediaMetadata.Builder()
.setTitle("test")
.setDisplayTitle("Test")
.setArtist("Majestro")
.setMediaUri(Uri.parse("https://s3-us-west-2.amazonaws…")
.build()

39. Don’t make it pixel
perfect to test
(for now)

45. Delay
decisions

46. Error handling

47. suspend fun getLikedTracks(): List<Track> =
try {
dataSource.getLikedTracks().map()
} catch (e: Exception) {
// TODO error handling
e.printStackTrace()
emptyList()
}
}

48. suspend fun getLikedTracks(): List<Track> =
try {
dataSource.getLikedTracks().map()
} catch (e: Exception) {
// TODO error handling
e.printStackTrace()
emptyList()
}
}
¯_(ツ)_/¯

49. Be pragmatic

50. The Cache

51. A database, right?

52. class CacheInterceptor: Interceptor {
// ..
private fun Request.cacheOnly(): Request = newBuilder()
.removeHeader(CACHE_HEADER_NAME)
.cacheControl(
CacheControl.Builder()
.onlyIfCached()
.maxStale(CACHE_TIME_MINUTES, TimeUnit.MINUTES)
.build()
).build()

53. class CacheInterceptor: Interceptor {
// ..
private fun Request.cacheOnly(): Request = newBuilder()
.removeHeader(CACHE_HEADER_NAME)
.cacheControl(
CacheControl.Builder()
.onlyIfCached()
.maxStale(CACHE_TIME_MINUTES, TimeUnit.MINUTES)
.build()
).build()
¯_(ツ)_/¯

54. Offline tracking

55. A database, right?

56. class DelayingReportingDataSource(
private val file: File,
private val job: BatchReportingScheduler
) : ReportingDataSource {
override suspend fun report(url: ReportingUrl) {
file.appendText(url.value + "n")
job.schedule()
}
val dequeueJobs: List<ReportingUrl>
get() = file.readLines().map { ReportingUrl(it) }.also {
file.delete()
}
}

57. class DelayingReportingDataSource(
private val file: File,
private val job: BatchReportingScheduler
) : ReportingDataSource {
override suspend fun report(url: ReportingUrl) {
file.appendText(url.value + "n")
job.schedule()
}
val dequeueJobs: List<ReportingUrl>
get() = file.readLines().map { ReportingUrl(it) }.also {
file.delete()
}
}
¯_(ツ)_/¯

58. “the feeling of scrapiness and togetherness
while developing software was noticeable”
SoundCloud product owner
from different project

59. Don’t look for the
ideal solution
or process,
but inventing the way
as you go
to make progress

60. We are in this together!

61. https://dpreussler.medium.com/release-is-coming-a-teams-journey-towards-beautiful-release-6dbc3669e209

62. Testing with real users

63. When to close the
ticket?

64. When to close the
ticket?

66. Real Feedback

67. Communication

68. Transparency
● Bi weekly calls with Google
● Internal Demo early on
● Hinted on talks/tweets
● Google IO announcement

69. Transparency
● Announced delays
● Announced that others might
be delayed as of us

70. Don’t give up on quality
Be pragmatic

71. Summary
● Build the right thing (research)
● Short feedback cycles:
○ Build times
○ CD
○ Fake it
○ Test with real users
● Don’t make it perfect
● Delay Decisions
● Get everyone onboard
● Be transparent

73. Nothing lasts forever

74. 74
We
lead
what's
next
in
music
Thank You
@PreusslerBerlin