- Real-life developer’s horror stories about apps that break on production out of sudden - How do we rollout apps? - How do we monitor their health? - How do we rollout features?
- Real-life developer’s horror stories about apps that break on production out of sudden - How do we rollout apps? - How do we monitor their health? - How do we rollout features? - Takeaways
they’re stored in the database - Once something is stored in the database, SyncAdapter is triggered and stuff is synced to the server - Server syncs some other stuff back - i.e. changes made by other people, or by you on a different platform
they’re stored in the database - Once something is stored in the database, SyncAdapter is triggered and stuff is synced to the server - Server syncs some other stuff back - i.e. changes made by other people, or by you on a different platform - KEY: changes in DB synced by the server don’t trigger sync
they’re stored in the database - Once something is stored in the database, SyncAdapter is triggered and stuff is synced to the server - Server syncs some other stuff back - i.e. changes made by other people, or by you on a different platform - KEY: changes in DB synced by the server don’t trigger sync - OOOOPS.
that the bug is there and what is the root cause - If it’s critical, BEFORE you even ship a fixed build to the Google Play, speak to your backend collegues: can we actually apply a workaround on a backend?
that the bug is there and what is the root cause - If it’s critical, BEFORE you even ship a fixed build to the Google Play, speak to your backend collegues: can we actually apply a workaround on a backend? - Then fix the mobile app, in most of the cases regardless if you have a workaround on a different layer or not.
that the bug is there and what is the root cause - If it’s critical, BEFORE you even ship a fixed build to the Google Play, speak to your backend collegues: can we actually apply a workaround on a backend? - Then fix the mobile app, in most of the cases regardless if you have a workaround on a different layer or not. - Months after: deprecate the workaround when virtually nobody’s using that build anymore.
Android. That’s a lot of money. - Huge brand risk if things break - 20K transactions done every minute - … so yeah, maybe we’re not Facebook or Twitter, but...
Firebase Test Lab - For every Pull Request before we merge it - On 3 different physical devices - With 3 different Android versions - QA are responsible for them
Firebase Test Lab - For every Pull Request before we merge it - On 3 different physical devices - With 3 different Android versions - QA are responsible for them - 93 automated acceptance scenarios, covering the most important features
may hit real backend environment, thus make tests flaky - … and slow. - And sometimes it’s extremely hard to replicate some server edge-cases (What about some UI tests for server-connectivity errors?)
may hit real backend environment, thus make tests flaky - … and slow. - And sometimes it’s extremely hard to replicate some server edge-cases (What about some UI tests for server-connectivity errors?) That’s why we introduced Mock Enviornment.
may hit real backend environment, thus make tests flaky - … and slow. - And sometimes it’s extremely hard to replicate some server edge-cases (What about some UI tests for server-connectivity errors?) That’s why we introduced Mock Enviornment. Small framework over MockWebServer and Espresso to make it easy to mock stuff.
they offer a plugin for Gradle - Automaticaly instruments your OkHttp / Apache HTTP client / HttpUrlConnection code to track request’s metadata. (sensitive information, like auth tokens is not included by default)
they offer a plugin for Gradle - Automaticaly instruments your OkHttp / Apache HTTP client / HttpUrlConnection code to track request’s metadata. (sensitive information, like auth tokens is not included by default) - Also - crash rate calculation and bunch of other, standard analytics tools.
time. - Long running feature branches. - Development feature flags disabling the feature on production builds + mergin all stuff to master all the time.
be compile-time constant - Best: multiple build flavors so unfinished feature isn’t even included in the bundle. - Usually checked in 1 place - check whether to show an icon in the menu, Toolbar, etc.
works technically, on every phone in every country - Making sure it works business-wise - Product Owner to decide when “it’s ready”. - You can turn stuff off is something gets in fire
works technically, on every phone in every country - Making sure it works business-wise - Product Owner to decide when “it’s ready”. - You can turn stuff off is something gets in fire
Prioritize your automation by amount of time you need to spend to test it manually - Make your remote feature flags be checked in real-time - don’t require app’s process to be killed in order to apply a new setting
Prioritize your automation by amount of time you need to spend to test it manually - Make your remote feature flags be checked in real-time - don’t require app’s process to be killed in order to apply a new setting - Don’t treat crashes as the only measurement of app’s stability.
Prioritize your automation by amount of time you need to spend to test it manually - Make your remote feature flags be checked in real-time - don’t require app’s process to be killed in order to apply a new setting - Don’t treat crashes as the only measurement of app’s stability. - Make sure your tooling lets you spot issues before your customers report them.
gdglviv
nulabinc
colopl
meow_noisy
taro_masuda
aiqlab
konifar
danielbryantuk
bkuhlmann
kmatsui
harishpillay
pingcap0315
bobtani
paigeccino
andyhume
shpigford
cherdarchuk
tammielis
samlambert
sstephenson
jonyablonski
robhawkes
mojombo
trishagee
eileencodes
