Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Retex DroidCon UK 2017

Alain Muller
November 08, 2017

Retex DroidCon UK 2017

Carole Thébaud & I did a quick presentation about the takeaways and talks we assisted during the DroidCon UK in London 26-27th oct 2017.

Every talk is available on skillsmatter's website and we provided links to the videos/sample/blog post when available.

https://skillsmatter.com/conferences/8265-droidcon-london-2017#skillscasts

Pictures are from skillsmatter's flickr : https://flic.kr/s/aHsm7JNde1

Alain Muller

November 08, 2017
Tweet

More Decks by Alain Muller

Other Decks in Programming

Transcript

  1. Android: A Retrospective Chet Haase & Romain Guy • Comedy

    talk • Android history through all releases • Links : Talk
  2. About Memory Management in Fully Reactive Apps Paco Estevez •

    Most common memory leaks • Bad lifecycle handling
  3. About Memory Management in Fully Reactive Apps Paco Estevez •

    Most common memory leaks • Bad lifecycle handling • Keeping references (inner/anonymous classes)
  4. About Memory Management in Fully Reactive Apps Paco Estevez •

    Best practices : • .takeUntil operator
  5. About Memory Management in Fully Reactive Apps Paco Estevez •

    Best practices : • .takeUntil operator • Architecture components
  6. About Memory Management in Fully Reactive Apps Paco Estevez •

    Best practices : • .takeUntil operator • Architecture components • Links : Talk, slides shorter / longer
  7. Profile, debug, analyze Wojtek Kaliciński • Best practices • AS

    tooling (APK Analyzer, profiler (CPU, GPU, mem, Network), view hierarchy, systrace, proguard)
  8. Profile, debug, analyze Wojtek Kaliciński • Best practices • AS

    tooling (APK Analyzer, profiler (CPU, GPU, mem, Network), view hierarchy, systrace, proguard) • Links : Talk
  9. How to Keep Your API Keys Safe Richard Taylor •

    2 weak points for hacking : app / communication
  10. How to Keep Your API Keys Safe Richard Taylor •

    2 weak points for hacking : app / communication • App :
  11. How to Keep Your API Keys Safe Richard Taylor •

    2 weak points for hacking : app / communication • App : • DO NOT store anything in manifest (unzip apk -> everything is visible)
  12. How to Keep Your API Keys Safe Richard Taylor •

    2 weak points for hacking : app / communication • App : • DO NOT store anything in manifest (unzip apk -> everything is visible) • DO NOT hardcode keys in a class or strings.xml (easy to reverse-engineer)
  13. How to Keep Your API Keys Safe Richard Taylor •

    Communication : • Man In The Middle technique : show requests (w/ content)
  14. How to Keep Your API Keys Safe Richard Taylor •

    Communication : • Man In The Middle technique : show requests (w/ content) • Use an obfuscation for external calls (hash / salt / HMAC)
  15. How to Keep Your API Keys Safe Richard Taylor •

    Communication : • Man In The Middle technique : show requests (w/ content) • Use an obfuscation for external calls (hash / salt / HMAC) • Use an external server to authenticate app
  16. How to Keep Your API Keys Safe Richard Taylor •

    Communication : • Man In The Middle technique : show requests (w/ content) • Use an obfuscation for external calls (hash / salt / HMAC) • Use an external server to authenticate app • Links : Talk
  17. From View to Pixel Britt Barak • Smooth user experience

    • Measure > layout > draw • invalidate() -> re-draw
  18. From View to Pixel Britt Barak • Smooth user experience

    • Measure > layout > draw • invalidate() -> re-draw • requestLayout() -> re-measure
  19. From View to Pixel Britt Barak • Flatten view hierarchy

    • Remove unneeded views • Merge on include
  20. From View to Pixel Britt Barak • Flatten view hierarchy

    • Remove unneeded views • Merge on include • Flatter layouts
  21. From View to Pixel Britt Barak • Flatten view hierarchy

    • Remove unneeded views • Merge on include • Flatter layouts • Minimize requestLayout()
  22. From View to Pixel Britt Barak • Flatten view hierarchy

    • Remove unneeded views • Merge on include • Flatter layouts • Minimize requestLayout() • Links : Talk
  23. Vector Workflows Nick Butcher • Definition of SVG / Vector

    Drawables • Optimisations VS classic PNGs (size, precision)
  24. Vector Workflows Nick Butcher • Definition of SVG / Vector

    Drawables • Optimisations VS classic PNGs (size, precision) • Clipping is bad
  25. Vector Workflows Nick Butcher • Definition of SVG / Vector

    Drawables • Optimisations VS classic PNGs (size, precision) • Clipping is bad • New API (gradient...)
  26. Vector Workflows Nick Butcher • Definition of SVG / Vector

    Drawables • Optimisations VS classic PNGs (size, precision) • Clipping is bad • New API (gradient...) • How to import SVG into a VD
  27. Vector Workflows Nick Butcher • Definition of SVG / Vector

    Drawables • Optimisations VS classic PNGs (size, precision) • Clipping is bad • New API (gradient...) • How to import SVG into a VD • Tools & plugins (sketch export plugin, shapeshifter…)
  28. Vector Workflows Nick Butcher • Definition of SVG / Vector

    Drawables • Optimisations VS classic PNGs (size, precision) • Clipping is bad • New API (gradient...) • How to import SVG into a VD • Tools & plugins (sketch export plugin, shapeshifter…) • Links : Talk
  29. The Baddest Android Advice in All The Land Bad Android

    Advice • use FAB • put logic in XML
  30. The Baddest Android Advice in All The Land Bad Android

    Advice • use FAB • put logic in XML • no time for tests
  31. The Baddest Android Advice in All The Land Bad Android

    Advice • use FAB • put logic in XML • no time for tests • motion doesn't always have to be meaningful
  32. The Baddest Android Advice in All The Land Bad Android

    Advice • use FAB • put logic in XML • no time for tests • motion doesn't always have to be meaningful • turn off lint checks
  33. The Baddest Android Advice in All The Land Bad Android

    Advice • use FAB • put logic in XML • no time for tests • motion doesn't always have to be meaningful • turn off lint checks • don't learn design guidelines, invent your own
  34. The Baddest Android Advice in All The Land Bad Android

    Advice • use/hack private APIs • only use your fancy phone and data plan / wifi for development
  35. The Baddest Android Advice in All The Land Bad Android

    Advice • use/hack private APIs • only use your fancy phone and data plan / wifi for development • store your sign-in/credential in your repo w/your code
  36. The Baddest Android Advice in All The Land Bad Android

    Advice • use/hack private APIs • only use your fancy phone and data plan / wifi for development • store your sign-in/credential in your repo w/your code • save all data in sharedPrefs
  37. The Baddest Android Advice in All The Land Bad Android

    Advice • use/hack private APIs • only use your fancy phone and data plan / wifi for development • store your sign-in/credential in your repo w/your code • save all data in sharedPrefs • select all files > convert to Kotlin > rest
  38. The Baddest Android Advice in All The Land Bad Android

    Advice • use/hack private APIs • only use your fancy phone and data plan / wifi for development • store your sign-in/credential in your repo w/your code • save all data in sharedPrefs • select all files > convert to Kotlin > rest • put plus sign in your dependencies version
  39. The Baddest Android Advice in All The Land Bad Android

    Advice • use/hack private APIs • only use your fancy phone and data plan / wifi for development • store your sign-in/credential in your repo w/your code • save all data in sharedPrefs • select all files > convert to Kotlin > rest • put plus sign in your dependencies version • Links : Talk
  40. Why do we need Clean Architecture Igor Wojda • isolated

    layers = less merge conflicts but you need to implement mappers
  41. Why do we need Clean Architecture Igor Wojda • isolated

    layers = less merge conflicts but you need to implement mappers • IoC / DI to link all together
  42. Why do we need Clean Architecture Igor Wojda • isolated

    layers = less merge conflicts but you need to implement mappers • IoC / DI to link all together • easily testable at every level
  43. Why do we need Clean Architecture Igor Wojda • isolated

    layers = less merge conflicts but you need to implement mappers • IoC / DI to link all together • easily testable at every level • YOU SHOULD DO IT
  44. Why do we need Clean Architecture Igor Wojda • isolated

    layers = less merge conflicts but you need to implement mappers • IoC / DI to link all together • easily testable at every level • YOU SHOULD DO IT • Links : Talk / slides
  45. CYA : Cover Your App Jorge Ortiz Fuentes • Selfish

    Unit Tests • Do not rely on code coverage (not a viable KPI for your business logic)
  46. CYA : Cover Your App Jorge Ortiz Fuentes • Selfish

    Unit Tests • Do not rely on code coverage (not a viable KPI for your business logic) • Live coding with Rx / Dagger and Instrumented Tests
  47. CYA : Cover Your App Jorge Ortiz Fuentes • Selfish

    Unit Tests • Do not rely on code coverage (not a viable KPI for your business logic) • Live coding with Rx / Dagger and Instrumented Tests • Links : Talk
  48. CYA : Cover Your App Jorge Ortiz Fuentes • Selfish

    Unit Tests • Do not rely on code coverage (not a viable KPI for your business logic) • Live coding with Rx / Dagger and Instrumented Tests • Links : Talk
  49. CYA : Cover Your App Jorge Ortiz Fuentes • Selfish

    Unit Tests • Do not rely on code coverage (not a viable KPI for your business logic) • Live coding with Rx / Dagger and Instrumented Tests • Links : Talk
  50. Lint for Life: Your Customizable Guard At Compile Time Snow

    Zhao • AST and UAST • Lint vs other static code analysis tools (PMD, findbugs, ...)
  51. Lint for Life: Your Customizable Guard At Compile Time Snow

    Zhao • AST and UAST • Lint vs other static code analysis tools (PMD, findbugs, ...) • Custom Lint Rules
  52. Lint for Life: Your Customizable Guard At Compile Time Snow

    Zhao • AST and UAST • Lint vs other static code analysis tools (PMD, findbugs, ...) • Custom Lint Rules
  53. Lint for Life: Your Customizable Guard At Compile Time Snow

    Zhao • AST and UAST • Lint vs other static code analysis tools (PMD, findbugs, ...) • Custom Lint Rules • Links : Talk (not yet available)
  54. Data Persistence In Android: There’s Room For Improvement Florina Muntenescu

    • Based on SQLite • Solves these common problems/mistakes :
  55. Data Persistence In Android: There’s Room For Improvement Florina Muntenescu

    • Based on SQLite • Solves these common problems/mistakes : • Boilerplate code
  56. Data Persistence In Android: There’s Room For Improvement Florina Muntenescu

    • Based on SQLite • Solves these common problems/mistakes : • Boilerplate code • Difficult migration
  57. Data Persistence In Android: There’s Room For Improvement Florina Muntenescu

    • Based on SQLite • Solves these common problems/mistakes : • Boilerplate code • Difficult migration • Difficult test
  58. Data Persistence In Android: There’s Room For Improvement Florina Muntenescu

    • Based on SQLite • Solves these common problems/mistakes : • Boilerplate code • Difficult migration • Difficult test • Database operations on main thread
  59. Data Persistence In Android: There’s Room For Improvement Florina Muntenescu

    • Based on SQLite • Solves these common problems/mistakes : • Boilerplate code • Difficult migration • Difficult test • Database operations on main thread • Links : Talk
  60. Three key lessons when migrating to ConstraintLayout Connie Reinholdsson •

    Converted different layouts to see what was the result
  61. Three key lessons when migrating to ConstraintLayout Connie Reinholdsson •

    Converted different layouts to see what was the result • Don't do this at home kids
  62. Three key lessons when migrating to ConstraintLayout Connie Reinholdsson •

    Converted different layouts to see what was the result • Don't do this at home kids • @see Nicolas Roard’s talk (slides/video on ConstraintLayout during DevFest Nantes)
  63. Three key lessons when migrating to ConstraintLayout Connie Reinholdsson •

    Converted different layouts to see what was the result • Don't do this at home kids • @see Nicolas Roard’s talk (slides/video on ConstraintLayout during DevFest Nantes)
  64. Three key lessons when migrating to ConstraintLayout Connie Reinholdsson •

    Converted different layouts to see what was the result • Don't do this at home kids • @see Nicolas Roard’s talk (slides/video on ConstraintLayout during DevFest Nantes) • Links : Talk / blog post
  65. Keynote: Tips for Library Development from a Startup Developer Lisa

    Wray • You’re not Google / Facebook / Square
  66. Keynote: Tips for Library Development from a Startup Developer Lisa

    Wray • You’re not Google / Facebook / Square • If you needed it, it might be useful to others
  67. Keynote: Tips for Library Development from a Startup Developer Lisa

    Wray • You’re not Google / Facebook / Square • If you needed it, it might be useful to others • K.I.S.S.
  68. Keynote: Tips for Library Development from a Startup Developer Lisa

    Wray • You’re not Google / Facebook / Square • If you needed it, it might be useful to others • K.I.S.S. • Links : Talk
  69. Keynote: Developers Are Users Too Florina Muntenescu • We as

    developers are users of our own APIs and are end users too
  70. Keynote: Developers Are Users Too Florina Muntenescu • We as

    developers are users of our own APIs and are end users too • Take care of APIs public methods as much as our design
  71. Keynote: Developers Are Users Too Florina Muntenescu • We as

    developers are users of our own APIs and are end users too • Take care of APIs public methods as much as our design • 10 Usability heuristics for API design
  72. Keynote: Developers Are Users Too Florina Muntenescu • We as

    developers are users of our own APIs and are end users too • Take care of APIs public methods as much as our design • 10 Usability heuristics for API design • Links : Talk
  73. Keynote: Developers Are Users Too Florina Muntenescu • We as

    developers are users of our own APIs and are end users too • Take care of APIs public methods as much as our design • 10 Usability heuristics for API design • Links : Talk
  74. Testing Android apps based on Dagger and RxJava Fabio Collini

    • Dagger • Dagger • Dagger... • Unit Tests / Instrumented Tests
  75. Testing Android apps based on Dagger and RxJava Fabio Collini

    • Dagger • Dagger • Dagger... • Unit Tests / Instrumented Tests • How to test void / asynchronous / synchronous observables methods (see photos)
  76. Testing Android apps based on Dagger and RxJava Fabio Collini

    • Dagger • Dagger • Dagger... • Unit Tests / Instrumented Tests • How to test void / asynchronous / synchronous observables methods (see photos) • Links : Talk
  77. Testing Android apps based on Dagger and RxJava Fabio Collini

    • Dagger • Dagger • Dagger... • Unit Tests / Instrumented Tests • How to test void / asynchronous / synchronous observables methods (see photos) • Links : Talk
  78. Becoming a Master Window Fitter Chris Banes • How to

    use fitsSystemWindow • Do not use android.R.dimen.status_bar_height
  79. Becoming a Master Window Fitter Chris Banes • How to

    use fitsSystemWindow • Do not use android.R.dimen.status_bar_height • Do not use 24dp margin on post-lollipop (21+)
  80. Becoming a Master Window Fitter Chris Banes • How to

    use fitsSystemWindow • Do not use android.R.dimen.status_bar_height • Do not use 24dp margin on post-lollipop (21+) • use appropriate listener (onApplyWindowsInsetsListener)
  81. Becoming a Master Window Fitter Chris Banes • How to

    use fitsSystemWindow • Do not use android.R.dimen.status_bar_height • Do not use 24dp margin on post-lollipop (21+) • use appropriate listener (onApplyWindowsInsetsListener) • Links : Talk
  82. Pragmatic Kotlin on Android Josh Skeen • Const VS val

    (not really immutable) • Converting = booooh (errors, not optimized, leads to mistakes)
  83. Pragmatic Kotlin on Android Josh Skeen • Const VS val

    (not really immutable) • Converting = booooh (errors, not optimized, leads to mistakes) • use .let, .apply (null check -> if a == null blah() becomes a ?: blah())
  84. Pragmatic Kotlin on Android Josh Skeen • Const VS val

    (not really immutable) • Converting = booooh (errors, not optimized, leads to mistakes) • use .let, .apply (null check -> if a == null blah() becomes a ?: blah()) • extensions function
  85. Pragmatic Kotlin on Android Josh Skeen • Const VS val

    (not really immutable) • Converting = booooh (errors, not optimized, leads to mistakes) • use .let, .apply (null check -> if a == null blah() becomes a ?: blah()) • extensions function • Links : Talk
  86. Kotlin Coroutines and Android sitting in a tree Kai Koenig

    • Complex but efficient • Cheaper / Faster / lightweight than Threads
  87. Kotlin Coroutines and Android sitting in a tree Kai Koenig

    • Complex but efficient • Cheaper / Faster / lightweight than Threads • Run in //
  88. Kotlin Coroutines and Android sitting in a tree Kai Koenig

    • Complex but efficient • Cheaper / Faster / lightweight than Threads • Run in // • Still experimental (lib kotlinx.Coroutines)
  89. Kotlin Coroutines and Android sitting in a tree Kai Koenig

    • Complex but efficient • Cheaper / Faster / lightweight than Threads • Run in // • Still experimental (lib kotlinx.Coroutines) • Links : Talk
  90. Android Instant Apps Benjamin Weiss • modularize your app (base.apk

    feature1.apk feature2.apk) • bundled app <= 4mb (base.apk + featureX.apk)
  91. Android Instant Apps Benjamin Weiss • modularize your app (base.apk

    feature1.apk feature2.apk) • bundled app <= 4mb (base.apk + featureX.apk) • tools to optimize size (APK analyser...) + best practices (one APK by "flavor")
  92. Android Instant Apps Benjamin Weiss • modularize your app (base.apk

    feature1.apk feature2.apk) • bundled app <= 4mb (base.apk + featureX.apk) • tools to optimize size (APK analyser...) + best practices (one APK by "flavor") • Links : Talk / sample
  93. Towards a better language Chet Haase & Romain Guy •

    Comedy talk • F.A.R.T & P.O.O.P
  94. Towards a better language Chet Haase & Romain Guy •

    Comedy talk • F.A.R.T & P.O.O.P • Dependency rejection…
  95. Towards a better language Chet Haase & Romain Guy •

    Comedy talk • F.A.R.T & P.O.O.P • Dependency rejection… • Links : Talk
  96. Hacking Android, a Hacker's narrative Chris Le Roy • History

    / Examples of Hacks • Live hacking • Follow OWASP guides
  97. Hacking Android, a Hacker's narrative Chris Le Roy • History

    / Examples of Hacks • Live hacking • Follow OWASP guides • Prevent Temper / Debug / Instrumented
  98. Hacking Android, a Hacker's narrative Chris Le Roy • History

    / Examples of Hacks • Live hacking • Follow OWASP guides • Prevent Temper / Debug / Instrumented • SafetyNet API to prevent running your app on rooted (xposed) devices
  99. Hacking Android, a Hacker's narrative Chris Le Roy • History

    / Examples of Hacks • Live hacking • Follow OWASP guides • Prevent Temper / Debug / Instrumented • SafetyNet API to prevent running your app on rooted (xposed) devices • Links : Talk
  100. Litho Animations and Internals Marco Cova & Andy Street •

    Facebook's anim lib • limit view hierarchy on draw
  101. Litho Animations and Internals Marco Cova & Andy Street •

    Facebook's anim lib • limit view hierarchy on draw • measure / layout step done by the lib -> only draw
  102. Litho Animations and Internals Marco Cova & Andy Street •

    Facebook's anim lib • limit view hierarchy on draw • measure / layout step done by the lib -> only draw • leads to really fluids animation
  103. Litho Animations and Internals Marco Cova & Andy Street •

    Facebook's anim lib • limit view hierarchy on draw • measure / layout step done by the lib -> only draw • leads to really fluids animation • Links : Talk
  104. Building a Minimum Viable Product (MVP) with Face recognition and

    AR in Android Raul Hernandez • How to build an MVP (choices, optimisations, be fast)
  105. Building a Minimum Viable Product (MVP) with Face recognition and

    AR in Android Raul Hernandez • How to build an MVP (choices, optimisations, be fast) • How to implement Face Recognition using AI / Machine Learning
  106. Building a Minimum Viable Product (MVP) with Face recognition and

    AR in Android Raul Hernandez • How to build an MVP (choices, optimisations, be fast) • How to implement Face Recognition using AI / Machine Learning • Some code samples (Cloud A dialogflow,…)
  107. Building a Minimum Viable Product (MVP) with Face recognition and

    AR in Android Raul Hernandez • How to build an MVP (choices, optimisations, be fast) • How to implement Face Recognition using AI / Machine Learning • Some code samples (Cloud A dialogflow,…) • AR to display items on the matched face with code samples...
  108. Building a Minimum Viable Product (MVP) with Face recognition and

    AR in Android Raul Hernandez • How to build an MVP (choices, optimisations, be fast) • How to implement Face Recognition using AI / Machine Learning • Some code samples (Cloud A dialogflow,…) • AR to display items on the matched face with code samples... • Links : Talk / sample
  109. Sinking Your Teeth Into Bytecode Jake Wharton • Command lines

    to generate bytecode and analyze it • Various samples end checks on different implementations
  110. Sinking Your Teeth Into Bytecode Jake Wharton • Command lines

    to generate bytecode and analyze it • Various samples end checks on different implementations • Kotlin / retrolambda / D8
  111. Sinking Your Teeth Into Bytecode Jake Wharton • Command lines

    to generate bytecode and analyze it • Various samples end checks on different implementations • Kotlin / retrolambda / D8 • AS Tools (marvellous Kotlin bytecode analyser)
  112. Sinking Your Teeth Into Bytecode Jake Wharton • Command lines

    to generate bytecode and analyze it • Various samples end checks on different implementations • Kotlin / retrolambda / D8 • AS Tools (marvellous Kotlin bytecode analyser) • Links : Talk