Notes - Modern Android Development: Android Jetpack, Kotlin, and More (Google I/O 2018)

In this Notes article, I roughly jotted down notes in English from the content of the English session video/podcast. This article is intended to be read as a reference while watching the video. I hope this article helps you even a little when you watch the actual video. (Please feel free to contact me if there are any errors or typos! m(__)m)

This article is based on Modern Android Development: Android Jetpack, Kotlin, and More (Google I/O 2018).

Android History

#

• 2008 - Android 1.0
• 2013 - Android Studio
• 2014 - ART, RecyclerView
• 2017 - ConstraintLayout, Kotlin, AAC, Studio Profilers
• 2018 - ktx, Paging

Tools

#

• Layout Inspector
• Trace View -> Systrace
• New Profiler Tab in Android Studio
• Memory Tracking
• Layout Design
  • ConstraintLayout

Runtime and Language

#

Dalvik

#

• Optimized for Space
• JIT optimizations not as powerful
• Slow Allocation/collection
• Heap fragmentation

So

#

• Avoid allocations (e.g., Don’t use Enums!)
• Primitive types are cool

ART

#

• Optimized for performance
• JIT + AOT
• Faster allocation/collection
• Heap defragmentation
• Large object heap

So

#

• Allocate as necessary (Yes, even enums)
• Use appropriate types

But

#

• Phones are still resource-constrained
• Battery is important

Java

#

• Started with Java 1.5
• Extremely popular
• Great tools available
• Slow adoption of newer versions

Kotlin

#

• Official support in 2017
• Close collaboration with JetBrains
• Many great features that make code more enjoyable to write & read
• Android projects can contain both Kotlin & Java
• Lint checks in Android Studio
• Java -> Kotlin conversion
• Android Kotlin Extension
• Kotlin Style Guide
• Kotlin Interop Guide

Benefits of Kotlin

#

• Extensions
• Inline functions
• Operators
• Destructuring assignments
• Data classes
• Lambdas

Starting with Android P, new Java APIs in the platform will follow the Kotlin convention where a SAM interface parameter goes at the end of the parameter list.

View APIs

#

• AbsoluteLayout => Deprecated
• LinearLayout => Okay for simple cases
• FrameLayout => Okay
• GridLayout => Don’t use
• RelativeLayout => Don’t use
• ConstraintLayout => Use it. 2.0 Soon!
• AdapterViews

Fragments

#

• Complicated
• Core platform bugs + fixes => Core Platform API @deprecated
• Use Support Library Fragments
  • Improvements ongoing, plans for more
  • New Navigation component simplifies fragment transactions

Activities

#

• Android apps consist of many activities
• Navigating launches an activity
• Use single activities when possible
  • One per entry point
• Richer, more continuous user experience
• Fragments are not necessary, but can help
  • Navigation component, too

Architecture

#

• No recommendation for architecture before
• Handling Android Lifecycle

Lifecycle

#

• AAC: Lifecycle
  • Fragment implements LifecycleOwner
  • AppCompatActivity implements LifecycleOwner
  • Activity and Lifecycle-dependent components are now separated

Views and Data

#

• Activity had too much stuff
  • Views
  • Data for Views
  • Lifecycle tracking
  • Data change tracking

LiveData and ViewModel

#

• Activity now only contains Views and a reference to the ViewModel
• Activity observes LiveData

Data

#

• Do it your own! => Room

Room

#

• Local data persistence via SQLite
• Compile-time validation
• LiveData integration

Idea from Repository Pattern

#

Activity/Fragment
↓
ViewModel (contains LiveData)
↓
Repository
-> Model (Room) -> SQLite
-> Remote Data (Retrofit) -> WebService

Data Paging

#

• Paging Library 1.0
  • Works with RecyclerView
  • Fine-grained item changes, bindings
  • Uses background threads
  • Flexible data fetching options
  • Integration with Room
  • Boring name

Graphics

#

• OpenGL ES 1.0 => OpenGL ES 3.1/3.2, Vulkan
• Software rendering => Hardware-accelerated rendering
• Nine-patches => Vector Drawables
• TextureView vs. SurfaceView => Use SurfaceView, not TextureView
• Managing bitmaps by hand => Recommended Libraries: Glide, Picasso, Lottie

Final Thoughts

#

• Profile your code => Profile your code
• Avoid work when possible
• Minimize memory consumption
• Devices are still resource-constrained
• Battery life is critical
• Bandwidth is precious
• User experience matters

Impressions / Summary / Key Takeaways

#

• It’s significant that the official policy now explicitly states to use a single Activity as much as possible.
• Designing Java APIs with Kotlin in mind sounds excellent!
• Navigation Component and AAC Lifecycle have made Fragments much easier to handle, which feels like a strong endorsement of Fragments.
• The attitude of using good third-party libraries (Retrofit, Glide, Picasso appear in this video) all eventually connects to providing a better UX. It’s persuasive and makes sense, as it allows developers to build better apps with less stress.

That’s all!