Fragmented | AI Developer Podcast - Episodes

310 - Mitchell Hashimoto on Ghostty & His Agentic Coding Workflow

Tue, 14 Apr 2026 04:00:00 UTC

Mitchell Hashimoto co-founded HashiCorp, built some of the most impressive DevOps tools like Vagrant and Terraform, sold the company to IBM — and then built a terminal. Ghostty is now where a huge chunk of agentic coding actually happens. Mitchell was an AI skeptic. We walk through his six-step adoption framework and the workflows he uses day to day — warm-start research, Hail Mary prompts across twenty GitHub issues, and knowing when to let the agent slam dunk it.

Show Notes #

Ghostty #

Ghostty - Mitchell’s fast, native terminal built for platform integration across Mac and Linux
Terminal shells
SSH - secure shell
PTY - pseudoterminals
Terminal Multiplexers
- tmux - most popular open source one
XTGETTCAP by xterm
libghostty - the cross-platform terminal emulation library that powers Ghostty’s core
xterm-js - powers terminal for apps like VSCode and the cloud
Jedi Term - Intellij’s embedded terminal
Ghostty is now a non-profit
cmux - native macOS terminal multiplexer built on libghostty — a fork Mitchell champions
Free Software Definition - the 4 essential freedoms
1. The freedom to run the program as you wish, for any purpose.
2. The freedom to study how the program works, and change it to make it do what you wish.
3. The freedom to redistribute copies so you can help others.
4. The freedom to distribute copies of your modified versions to others.
Mitchell’s tweet on unsolicited PRs and transfer of ownership

The AI Adoption Journey #

My AI Adoption Journey - Mitchell’s blog post outlining his five-step framework
Step 1: Drop the Chatbot
- Episode 301 - AI Coding ladder - Different stages of AI adoption
Step 2: Reproduce Your Own Work
Step 3: End-of-Day Agents
- OpenAI Deep Research - kick off research tasks for a “warm start” the next morning
- Spine AI research - deep research tool for longer, hour-long analysis tasks
Step 4: Outsource the Slam Dunks
- Claude status hooks - warcraft peons
- Conductor
Step 5: Engineer the Harness
- Episode 307 - Harness Engineering - Fragmented’s deep dive on harness engineering, heavily inspired by Mitchell’s post
Step 6: Always have an Agent running
Peter Steinberger
Codex plugin for Claude Code

Get in touch #

We’d love to hear from you. Email is the best way to reach us or you can check our contact page for other ways.

We want to hear all the feedback: what’s working, what’s not, topics you’d like to hear more on.

Co-hosts: #

We transitioned from Android development to AI starting with

Ep. #300. Listen to that episode for the full story behind our new direction.

309 - Background Agents

Wed, 01 Apr 2026 04:00:00 UTC

Andrej Karpathy says the goal is to maximize how long an agent runs without your intervention. But there’s a false summit most teams hit first: individual speed goes up while system speed stalls, laptops roar under four parallel Gradle builds, and review queues keep growing. Kaushik and Iury trace the full arc — from local multitasking to cloud-hosted async work to fully autonomous agents that fire on repo events and send you PRs to approve.

Full shownotes at fragmentedpodcast.com.

Show Notes #

Andrej Karpathy on agents and token throughput - NoPriors podcast — maximize agent runtime, not token burn
Cursor Agent Mode - Multiagent interface - introduced the multi-agent board as a new paradigm for local parallel agents
Google Antigravity - Agent Manager interface
Claude Code Agent Teams - spawn sub-agents from a main orchestrator, with tmux pane integration
Git worktrees - /reddit

Remote Background Agents in the cloud #

Google Jules - hosted GitHub-connected agent, proposes a plan, edits code, runs tests, opens a PR
Cursor Cloud Agents - remote agents that clone your repo in the cloud and work in parallel
OpenAI Codex - cloud software engineering agent for parallel tasks
Claude Code on the web - cloud-hosted Claude Code sessions decoupled from your local machine

Building trust #

Episode 307 - Harness Engineering - the earlier episode on shaping agent environments — and why this ceiling exists

Get in touch #

We’d love to hear from you. Email is the best way to reach us or you can check our contact page for other ways.

We want to hear all the feedback: what’s working, what’s not, topics you’d like to hear more on.

Co-hosts: #

We transitioned from Android development to AI starting with

Ep. #300. Listen to that episode for the full story behind our new direction.

308 - How Image Diffusion Models Work - the 20 minute explainer

Tue, 24 Mar 2026 04:00:00 UTC

You already know how LLMs work — text into tokens, tokens into math, predict the next one. Image generation uses the same broad ideas but flips the training game: instead of predicting the next token, the model learns to predict and remove noise. Starting from pure static, it chips away — step by step — until a coherent image emerges. What does Michelangelo have to do with any of this? More than you’d think. This is how image diffusion models work, in 20 minutes.

Full shownotes at fragmentedpodcast.com.

Show Notes #

Episode 303 - How LLMs work in 20 minutes - text generation
VAE - Variational Autoencoder
RGB Color model - wikipedia
Word2Vec technique - wikipedia
- Efficient Estimation of Word Representation - original Word2Vec paper by Mikolov et al.
High-Resolution Image Synthesis with Latent Diffusion Models - Rombach et al. (2022) — the paper behind Stable Diffusion
Image Training data
- LAION-5B - 5 billion image-text pairs scraped from the web, used to train many image generation models
- WebLI - Google’s internal image-text dataset
Michelangelo

Get in touch #

We’d love to hear from you. Email is the best way to reach us or you can check our contact page for other ways.

We want to hear all the feedback: what’s working, what’s not, topics you’d like to hear more on.

Co-hosts: #

We transitioned from Android development to AI starting with

Ep. #300. Listen to that episode for the full story behind our new direction.

307 - Harness Engineering - the hard part of AI coding

Tue, 17 Mar 2026 04:00:00 UTC

The hard part of AI coding isn’t generating code — it’s controlling quality, safety, and drift. Drawing from OpenAI’s Codex case study, Mitchell Hashimoto’s post on AI workflows, Stripe’s Minions project, and real-world experience, Kaushik and Iury break down harness engineering: the five pillars for shaping an agent’s environment, and what it looks like when teams build custom harnesses from scratch.

Full shownotes at fragmentedpodcast.com.

Show Notes #

Why it matters #

Mitchell Hashmito first coined this term in his post My AI Adoption Journey
Harness Engineering - OpenAI’s post on building their Codex codebase (~1M lines of code, 1,500 PRs merged, zero manually written)

Shaping the harness #

The Feed’s Lost and Found - Iury’s newsletter consolidating harness engineering themes

Agent legibility
Closed feedback loops
Persistent memory
Entropy control
Blast radius controls

Building the harness #

Minions: Stripe’s one-shot, end-to-end coding agents - Stripe forked Goose to build custom agents for their codebase
Goose - open-source coding agent from Block
Superpowers by Jesse Vincent - skills that enforce a proper software engineering process
Open Code - open-source coding agent you can fork and customize

Other resources #

Agent Harness Glossary - Latent Patterns
Towards self-driving codebases - Cursor
Agentic Workflows - GitHub Next
Future of Software Development - ThoughtWorks

Get in touch #

We’d love to hear from you. Email is the best way to reach us or you can check our contact page for other ways.

We want to hear all the feedback: what’s working, what’s not, topics you’d like to hear more on.

Co-hosts: #

We transitioned from Android development to AI starting with

Ep. #300. Listen to that episode for the full story behind our new direction.

306 - Keeping your agent instructions in sync and effective

Mon, 09 Mar 2026 04:00:00 UTC

AGENTS.md is becoming the common language for AI coding tools, but keeping repo rules, personal rules, and tool-specific files in sync is still messy. In this episode, Kaushik and Iury break down the sync problem, compare their own setups, and unpack what the latest AGENTS.md research actually says.

Full shownotes at fragmentedpodcast.com.

Show Notes #

The sync problem #

AGENTS.md - Official spec
Custom instructions with AGENTS.md - Open AI
Keep your AGENTS.md in sync - Kaushik’s post
Rulesync - What Iury uses
Tweet by Ryan Carson and Claude frustrations

Get in touch #

We’d love to hear from you. Email is the best way to reach us or you can check our contact page for other ways.

We want to hear all the feedback: what’s working, what’s not, topics you’d like to hear more on.

Co-hosts: #

We transitioned from Android development to AI starting with

Ep. #300. Listen to that episode for the full story behind our new direction.

305 - Subagents explained: What they are, when (not) to spawn them

Mon, 16 Feb 2026 04:00:00 UTC

Download directly

Subagents are becoming a core primitive for serious AI-assisted development. In this episode, Kaushik and Iury disambiguate “agent” terminology, unpack plan mode vs subagents, and explain how parallel, scoped workers improve research quality without polluting the main thread.

Full shownotes at fragmentedpodcast.com.

Show Notes #

Resources & Documentation #

Official Documentation #

Agents, Modes, Subagents: official harness docs

Research Papers & Articles #

Introducing Claude Opus 4.5
Deep-Research Agents Paper
Post: GPT-5 System Card by Alex Xu
Self-Driving Codebases Blog - multi-agent systems making 1,000 commits/hour

Get in touch #

We’d love to hear from you. Email is the best way to reach us or you can check our contact page for other ways.

We want to hear all the feedback: what’s working, what’s not, topics you’d like to hear more on.

Co-hosts: #

We transitioned from Android development to AI starting with

Ep. #300. Listen to that episode for the full story behind our new direction.

304 - Agent Skills - when to use them and why they matter

Mon, 09 Feb 2026 05:00:00 UTC

Download directly

Agent Skills look simple, but they are one of the most powerful building blocks in modern AI coding workflows. In this episode, Kaushik and Iury break down when to use skills, how progressive disclosure works, and how skills compare with commands, instructions, and MCPs.

Full shownotes at fragmentedpodcast.com.

Show Notes #

Main References #

Progressive Disclosure - how skills are loaded into context
Agent Skills Open Specification
AAIF (Agentic AI Foundation) - Linux Foundation initiative for AI interoperability
Needle in a Haystack Problem - original “Lost in the Middle” paper
Agent-Invokable vs User-Invokable - merging skills and commands in Claude Code

Creating Skills #

Skill Creator - Anthropic’s skill for creating new agent skills
Claude Code frontmatter reference
- see model: * & context: fork

Using other Skills #

Anthropic Skills GitHub Repository - official collection of Claude skills and examples
Clawdhub - Clawdbot’s skill hub. All versions are archived here
SKILLS.sh - Vercel’s skills hub

Warnings before installing random skills #

Don’t install from hubs blindly.

Inspect the repo code before adding anything to your agent.

Prompt Injection Attacks - OWASP guide to LLM prompt injection vulnerabilities
OpenClaw <- MoltBot <- Clawdbot
OpenClaw Security Analysis - analysis of prompt injection risks in open agent frameworks
Malware found in a top-downloaded Clawhub skill - incident report thread

Additional resources #

Few-Shot Prompting - improving outputs with examples
.agents/skills - proposal to standardize the skills folder path
Vercel: AGENTS.md vs Skills - comparison of agent instruction methods

Get in touch #

We’d love to hear from you. Email is the best way to reach us or you can check our contact page for other ways.

We want to hear all the feedback: what’s working, what’s not, topics you’d like to hear more on.

Co-hosts: #

We transitioned from Android development to AI starting with

Ep. #300. Listen to that episode for the full story behind our new direction.

303 - How LLMs Work - the 20 minute explainer

Mon, 02 Feb 2026 08:00:00 UTC

Download directly

Ever get asked “how do LLMs work?” at a party and freeze? We walk through the full pipeline: tokenization, embeddings, inference — so you understand it well enough to explain it. Walk away with a mental model that you can use for your next dinner party.

Full shownotes at fragmentedpodcast.com.

Show Notes #

Words -> Tokens: #

OpenAI Tokenizer visualizer - Visualize how text becomes tokens

Tokens -> Embeddings: #

RGB Color model - wikipedia
Word2Vec technique - wikipedia
- Efficient Estimation of Word Representation - original Word2Vec paper by Mikolov et al.

Embeddings -> Inference: #

Get in touch #

We’d love to hear from you. Email is the best way to reach us or you can check our contact page for other ways.

We want to hear all the feedback: what’s working, what’s not, topics you’d like to hear more on. We want to make the show better for you so let us know!

Co-hosts: #

We transitioned from Android development to AI starting with

Ep. #300. Listen to that episode for the full story behind our new direction.

302 - MCPs Explained - what they are and when to use them

Mon, 26 Jan 2026 00:00:00 UTC

Download directly

MCPs are everywhere, but are they worth the token cost? We break down what Model Context Protocol actually is, how it differs from just using CLIs, the tradeoffs you should know about, and when MCPs actually make sense for your workflow.

Full shownotes at fragmentedpodcast.com.

Show Notes #

MCP - Model Context Protocol
Remote MCP server example - Glean
AAIF - Agentic AI Foundation setup by Linux foundation
Github MCP
Github gh CLI
Playwright MCP
Context7 MCP
Anthropic’s announcement on Advanced Tool Use

Tips #

Iury: use ast-grep to structurally search code faster
KG: use agent-browser by Vercel to give browsing power to your agent

Get in touch #

We’d love to hear from you. Email is the best way to reach us or you can check our contact page for other ways.

We want to hear all the feedback: what’s working, what’s not, topics you’d like to hear more on. We want to make the show better for you so let us know!

Co-hosts: #

We transitioned from Android development to AI starting with

Ep. #300. Listen to that episode for the full story behind our new direction.

301 - The AI coding ladder

Mon, 19 Jan 2026 09:00:00 UTC

Download directly

Most folks reference “AI coding” like it’s one thing. It’s really not. In this foundational episode Kaushik & Iury walk through (at least) four paradigms — from super autocomplete to agent orchestration — each with different workflows, expectations, and mental models.

What do most developers follow today? Where is the frontier? What’s coming in the future?

Listen to the episode and find out!

Full shownotes at fragmentedpodcast.com.

Show Notes #

Gen 1: Super autocomplete #

Gen 2: Chat Oriented Programming #

Gen 3: Agent #

Gen 4: Agent Orchestration #

Git worktrees

Tips #

Iury: Transfer between agents using your own compact command
KG: Ask the agent to clarify your prompt

cclarify

Confirm if my requirements are clear. If you have follow up questions, ask me first and clarify before executing anything.

Contact us #

Co-hosts: #

We transitioned from Android development to AI starting with

Ep. #300. Listen to that episode for the full story behind our new direction.

300 - From Vibe coding to Software engineering

Mon, 12 Jan 2026 09:00:00 UTC

Download directly

Fragmented is changing. New direction, new cohost. Kaushik explains the pivot from Android to AI development and introduces Iury Souza.

From vibe coding to software engineering — one episode at a time.

Full shownotes at fragmentedpodcast.com.

Contact us #

Co-hosts: #

257 - Future of AndroidDev in an AI world with Vinay Gaba

Tue, 04 Mar 2025 06:00:00 UTC

Download directly

Join us as we talk with Vinay Gaba, Android GDE and leading voice in Android development, about the future of the field. Vinay shares insights from interviews with top Android devs on their three-year predictions, and offers his own perspective. We cover AI’s impact, evolving development roles, and crucial future skills.

You can find the full shownotes over at fragmentedpodcast.com.

Show Notes #

Pessimists avoid risk, Optimists change the world.

Contact us #

Kaushik: #

kau.sh (links to everything)
Threads
Bluesky
Youtube
@kaushikgopal

Discuss on Bluesky, Reddit, Youtube

256 - Rapid prototyping with Kotlin

Mon, 24 Feb 2025 20:03:49 -0800

Download directly

In this episode, we dive into the power of rapid prototyping for Android developers using Kotlin. We explore how this crucial skill can impress stakeholders, accelerate your workflow, and help you stay ahead in today’s fast-paced tech landscape. We’ll cover use cases across scripting, web development (with Ktor & HTMX), mobile apps (Jetpack Compose), and even touch upon how AI is changing the game!

You can find the full shownotes over at fragmentedpodcast.com.

Show Notes #

Simple scripting
- State of Kotlin Scripting 2024 - Jetbrains blog
- Kotlin mini-app repo playground-kt
- Advent of Code
Web sites
- Hugo static site generator
- Cloudflare Pages
- Slashdot effect
- Fragmented Podcast Website powered by Henry (Kaushik’s custom theme)
Web apps
Mobile apps
- Episode 252 talking about playground-android
- Flutter
- Kotlin Multiplatform KMP
- React Native
LLM Based apps
Vibe coding an AirBnb clone

Contact us #

Kaushik: #

kau.sh (links to everything)
Threads
Bluesky
Youtube
@kaushikgopal

Discuss on Bluesky, Reddit, Youtube.

255 - Data Oriented Programming

Tue, 18 Feb 2025 05:36:00 UTC

Download directly

In this episode, we dive into the programming paradigm — Data Oriented Programming (DOP) and why making data the star can simplify your code. Learn how well-modeled data reduces defensive logic, prevents invalid states, and keeps your apps stable. We’ll also contrast DOP with Object Oriented Programming (OOP) and Functional Programming (FP), sharing practical examples, tips, and resource links to deepen your understanding.

The full shownotes with illustrations are on fragmentedpodcast.com.

Show Notes #

[announcement] Fragmented has an email newsletter.
Programming Paradigms
- Object Oriented Programming
- Functional Programming

Data Oriented Programming (DOP) #

Bank Transaction - OOP style

Bank Transaction - DOP style

UUID
- RFC 4122
- Kotlin now includes UUID in the standard lib even for kotlin multiplatform.

Network Result api

Search or find api

Resources #

Brian Goetz’s seminal article on DOP
Ties Van de Ven Advanced Kotlin Dev Day in 2022
Data Oriented Programming in Java by Chris Kiehl (by Manning Publications)
Devoxx talk by Nicolai Parlog on youtube

Contact us #

Kaushik: #

kau.sh (links to everything)
Threads
Bluesky
Youtube
@kaushikgopal

254 - 8× faster 5× memory savings with Dan Rusu’s Immutable Arrays

Tue, 24 Dec 2024 09:00:00 UTC

Download directly

In this episode, discover how Dan Rusu’s pods4k Immutable Arrays library can deliver 2–8× speed boosts and 5× lower memory usage in Kotlin/Android apps. We first revisit the fundamentals of autoboxing/unboxing and immutability to understand their impact on performance. Then we hear from Dan himself on his library, motiviations for building it, how the benchmarks were calculated and much much more. Our grand finale episode for 2024. Hope you enjoy it!

Full Shownotes at https://fragmentedpodcast.com/episodes/254.

Show Notes #

Immutable Arrays on github
Immutability episode #66 on Immutability with Ryan Harter
JMH - Java Microbenchmark Harness
Immutable Arrays Benchmarks page for Immutable Arrays (pods4k)
Dan’s post - Kotlin avoids entire categories of Java defects
K2 compiler
Dan Rusu
- Website
- pods4k github discussions

Contact us #

Kaushik: #

kau.sh (links to everything)
Threads
Bluesky
Youtube
@kaushikgopal

Discuss on Bluesky, Reddit r/androiddev r/kotlin, Youtube.

Disclaimer: Links shared might be affiliate links. They help support the production of Fragmented. Thank you for your support.

253 - logcat - a new look at logging with Piwai from Square

Tue, 10 Dec 2024 09:00:00 UTC

Download directly

Kaushik looks at a new logging library from Square called logcat. He starts by seeing how the popular Timber library does it along with the benefits. He then interviews Pierre-Yves Ricau (Piwai) of Square, the creator of logcat, to explore its origins and advantages.

You can find the full shownotes over at fragmentedpodcast.com.

Show Notes #

Contact #

You can find us on a few places:

Kaushik: #

kau.sh (links to everything)
Threads
Bluesky
Youtube
@kaushikgopal

Discuss on Bluesky, Reddit or Youtube

Disclaimer: Links shared might be affiliate links. They help support the production of Fragmented. Thank you for your support.

252 - Everyone needs a starter template

Tue, 26 Nov 2024 09:00:00 UTC

Download directly

In this episode of Fragmented, Kaushik dives into the importance of creating your own starter template to streamline app development and minimize decision fatigue. He shares insights from his own starter template - Playground Android.

Looking to the future, JetBrains has an exciting tool called Amper that might make all of this much easier. Kaushik chats with JetBrains’ Márton Braun about Amper, an exciting new tool that could revolutionize Kotlin & Android project setups.

Tune in to learn how to go from idea to code with less friction!

You can find the full shownotes over at fragmentedpodcast.com.

Show Notes #

Playground Android
The Architecture Templates (blog post)
Inspiration (Other starter templates):
- Bloco’s starter template what i referenced a lot
- Donn’s project - Jumpstart Android if you care about quickly getting a Rails app integrated with Android in a hybrid experience
- Now in Android too much functionality for my taste
- Jake’s u2020 for some good times nostalgia
Playground Android
- gradle version catalog - BOM & Bundles (one source of truth)
- sharing build logic with gradle convention plugin
- Makefile with common cli commands
- Custom lint-rules
- Multi module setup
- dependency injection with kotlin-inject-anvil
  - Episode 251 - There’s a new king in DI town
- function-injection demo in @Composable
Amper
- logcat lib and injecting multiple loggers
- basic networking with ktor #10
- compose-navigation between feature modules
Iury’s post on Kotlin Devex
Amper
- blog posts on Amper
Feedback on Amper - kotlinlang slack
Contact Márton Braun

Contact #

You can find us on a few places:

Kaushik: #

kau.sh (links to everything)
Bluesky
@kaushikgopal
Threads
Youtube

Disclaimer: Links shared might be affiliate links. They help support the production of Fragmented. Thank you for your support.

251 - There's a new king in DI town

Tue, 12 Nov 2024 09:00:00 UTC

Download directly

In this episode, Kaushik explores the evolution of dependency injection (DI) in Android development. Dagger has been the de-facto solution for DI in Android but there might be a new king in DI-town. He also chats with friend of the show and dependency injection expert Ralf Wondratschek for a final gut check.

Listen to find out more.

Show Notes #

Dagger 1 > Dagger 2 > dagger.android > Koin > Hilt > Anvil > Manual DI > kotlin-inject > kotlin-inject-anvil

kotlin-inject on github
- kotlin-inject-anvil on github
  - Kimchi similar alternative to Anvil-izing kotlin-inject
- Using kotlin-inject in Android
- Kaushik’s kotlin-inject-anvil playground app
Contact Ralf Wondratschek

Contact us #

Kaushik: #

kau.sh (links to everything)
Bluesky
@kaushikgopal
Threads
Youtube

Discuss on Reddit, Youtube

Disclaimer: Links shared might be affiliate links. They help support the production of Fragmented. Thank you for your support.

250 - Bittersweet beginnings

Tue, 29 Oct 2024 09:00:00 UTC

Download directly

We’re back from the hiatus with our SemiQuicentennial episode! With the momentous 250 comes some big announcements and a shift in the way we do things.

Listen to find out the details!

Show Notes #

Contact #

You can find us on a few places:

Donn #

Kaushik: #

kau.sh (links to everything)
Threads
Bluesky
Youtube
@kaushikgopal

Disclaimer: Links shared might be affiliate links. They help support the production of Fragmented. Thank you for your support.

249 – Java and the JDK: Powering the Android Landscape with Michael Bailey

Mon, 10 Jul 2023 10:45:00 UTC

Download directly

In this episode of our podcast, we explore the diverse landscape of Java versions within the Android ecosystem. Our guest is Michael Bailey, a seasoned Java expert who has been a frequent presence on our show since the early days of our podcast. We kick off with a solid foundation, discussing the differences between JDK and JRE, as well as the distinctions between the available Java JDKs. We also guide listeners through Android Studio settings, exploring how to select a suitable JDK, its utilization, and how it relates to JAVA_VERSION on one’s home path/terminal.

As we dig deeper, we start to unpack some of the crucial Android app settings. From compileOptions to sourceCompatibility/targetCompatibility, we shed light on why these versions are important. We also demystify the compileSdk vs minSdk vs targetSdk, and how they interconnect. Drawing from Kaushiks’s recent experience in building a new app, we provide real-life examples that can better clarify these topics for our listeners.

We conclude the episode by providing some valuable resources for further understanding and exploration. This episode is designed to be a comprehensive guide to understanding and navigating the intricacies of Java versions in Android development.

Links #

Find Michael Online

@yogurtearl on Twitter

Donn’s Git Course #

Need to learn Git? Donn has the course for you. In this FREE course you’ll learn everything you need to know in order to start working with Git everyday. Watch it here.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO 🎉
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast on Twitter or our YouTube channel

Donn

Kaushik

kau.sh (has links to all my networks)
twitter.kau.sh
mastodon.kau.sh
youtube.kau.sh (on YouTube)

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

248 – Feature Flags & A/B Testing: A Deep Dive with Ishan Khanna

Mon, 26 Jun 2023 05:00:00 UTC

Download directly

In this edition of Fragmented, we’re thrilled to host Ishan Khanna, a software engineer at Tinder who possesses great enthusiasm for feature flags and A/B testing. Donn discusses why he invited Ishan on the show, highlighting Ishan’s passion for feature flagging and A/B testing. The conversation kicks off with an insightful story from Ishan about feature flagging at Booking.com, leading to a discussion on the difference between A/B Testing and Feature Flags, when and why to introduce feature flagging, and how to measure its effectiveness. The show also focuses on the benefits and risks of feature flagging, along with ways to manage potential complexities in the codebase.

We then delve deeper into the topic of feature flagging, covering how to get started, what to look for in a tool, and the role of testing. Discussion points include the best practices for rollout percentages, considerations for multi-platform implementation, and the specifics of targeting in feature flagging. The conversation wraps up with an exploration of available tools for those looking to introduce feature flagging or A/B testing frameworks into their operations, examining when it might be necessary to build a bespoke solution.

The episode offers a wealth of resources for listeners, including links to an array of feature flagging and A/B testing tools, such as Firebase Remote Config, Optimizely, and LaunchDarkly. For more insight into the topics discussed, Ishan recommends his Droidcon Berlin talk on ‘Customer Driven Development’ and Stuart Frisby’s talk on A/B Testing. To reach out to Ishan, listeners can contact him via Twitter, LinkedIn, or his website.

Links #

Here are the links mentioned in the document, in markdown format:

Contact Ishan #

Donn’s Git Course #

Need to learn Git? Donn has the course for you. In this FREE course you’ll learn everything you need to know in order to start working with Git everyday. Watch it here.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO 🎉
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast on Twitter or our YouTube channel

Donn

Kaushik

kau.sh (has links to all my networks)
twitter.kau.sh
mastodon.kau.sh
youtube.kau.sh (on YouTube)

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

247: The Art of App Modularization with Siggi Jonsson

Mon, 12 Jun 2023 05:00:00 UTC

Download directly

In this episode, we talk to, Siggi Jonsson. Siggi helps guide us through the complex and often confusing world of Android app modularization. Our conversation will begin by shedding light on the importance of modularization, what triggers the need for breaking projects into multiple modules, and how modularization relates to team size, feature teams, and code ownership. This discussion is aimed at demystifying how and why developers often choose to modularize their applications.

As we move forward, we’ll dive into more advanced aspects of modularization, such as the challenges of scaling and the potential missteps in over-modularization. Drawing on real-world experiences, we’ll examine the red flags that signal a need for revising your modularization strategy. This part of our discussion will also highlight some specific tools and techniques that can help manage and visualize your project’s modularization, and Siggi will share his own experiences and insights into how these tools have assisted in his modularization strategy.

In the final part of the episode, we’ll touch on the benefits and strategies of proper modularization. Siggi will share practical advice on how to tackle big projects, fix issues with modularization, and make a smooth transition from monolithic to modular structures. We’ll also talk about some tools that can be handy in this process. Before closing, Siggi will offer his top tips for developers embarking on their modularization journey and share some valuable resources to help them. Siggi will also provide updates on his latest work and how listeners can reach out to him.

Links #

Sure, here are the links provided in the text, formatted in Markdown:

Find Siggi online here:

Donn’s Git Course #

Need to learn Git? Donn has the course for you. In this FREE course, you’ll learn everything you need to know to start working with Git daily. Watch it here.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO 🎉
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast on Twitter or our YouTube channel

Donn

Kaushik

kau.sh (has links to all my networks)
twitter.kau.sh
mastodon.kau.sh
youtube.kau.sh (on YouTube)

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

246 – Dependency Injection: Kotlin Inject with Fred Porciúncula

Mon, 29 May 2023 05:00:00 UTC

Download directly

In this podcast episode, we have the pleasure to host Fred Porciúncula, a Google Developer Expert (GDE) known for his work with Kotlin Inject and his invaluable contributions to the Android development community. Fred offers his expertise on Dependency Injection (DI), Kotlin Multiplatform (KMP), and how they intersect.

We kick off the conversation by discussing Dependency Injection (DI), its importance, and the options available to developers, including Dagger, Hilt, Anvil, Koin, and Kotlin-Inject. Fred explains the use and impact of DI in the Kotlin Multiplatform (KMP) world, considering Dagger’s current lack of KMP support and debating whether one should use separate DI tools for Android apps and KMP components.

Delving further into Kotlin-Inject, we explore its features, usage, and how it differentiates itself from other DI solutions. Topics discussed include its unique handling of Scopes, its support of constructor injection, and its utility in building dependency graphs. Furthermore, we examine the timeless debate of Dependency Injection versus Service Locator.

Toward the end of the episode, Fred presents his thoughts on the advantages and disadvantages of exclusively using Kotlin-Inject throughout an application. We also tackle the concept of “Vanilla Injection” – refraining from using DI libraries at all.

For further learning, we recommend resources like Fred’s insightful article on transitioning from Dagger/Hilt to Kotlin-Inject, a Dagger issue discussing KSP support, and a Kotlin-Inject discussion on Anvil-like features. Links to these resources, among others, are provided below. Don’t miss out on this engaging and informative episode with Fred Porciúncula!

Links #

Find Fred Online Here

Donn’s Git Course #

Need to learn Git? Donn has the course for you. In this FREE course you’ll learn everything you need to know in order to start working with Git everyday. Watch it here.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO 🎉
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast on Twitter or our YouTube channel

Donn

Kaushik

kau.sh (has links to all my networks)
twitter.kau.sh
mastodon.kau.sh
youtube.kau.sh (on YouTube)

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

245: Treehouse, Redwood and Zipline with Colin White

Mon, 15 May 2023 05:00:00 UTC

Download directly

In this episode, Donn and Kaushik talk to an old friend of the show, Colin White, about Treehouse, a combination of the Redwood and Zipline libraries.

Colin is a Staff Engineer at Cash App (Block).

Redwood is a multiplatform Compose library that allows you to target multiple UI toolkits on various native platforms. Ultimately this allows you to share presentation logic.

Zipline is a multiplatform JavaScript engine for Android, iOS, and the JVM, which uses Kotlin for calls in/out of the JavaScript land. This allows you to update the application logic of your apps without the traditional song and dance of the app store approval and release process.

Treehouse is the combination of both libraries, Redwood and Zipline. Listen in to learn more …

Links #

Find Colin Online here #

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO!
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Contact #

@fragmentedcast on Twitter or our Youtube channel

Donn

Kaushik

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

244: Reviving Our Passion for Android Development

Wed, 10 May 2023 18:36:09 UTC

Download directly

In this episode, Donn and Kaushik announce that they are steering the podcast back into Android waters. In other words, the Fragmented Podcast is returning to its roots … we’re back to being a 100% Android Development focused show.

We’re glad to have you as a listener, here’s to the future of Android Development. 🚀

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO 🎉
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
[kaushikgopal] (on YouTube) or kau.sh/blog or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

243: Mastering the Art of Switching Careers in Tech with Dan Lew

Mon, 10 Apr 2023 01:00:00 UTC

Download directly

In this episode, Donn and Kaushik talk to long-time friend Dan Lew about his recent career switch from Android developer to TypeScript/Node.js/Progressive Web App Developer (and more).

It’s an interesting discussion that covers …

Why Dan decided to leave the Android world
The challenges he faced when he moved from one tech stack to another
How to prepare for a big change like this (mentally, financially, etc.)
How to create the life you want live vi by identifying what’s important to you
and much more …

Shownotes #

Links #

Rheaply

Donn’s Git Course #

Need to learn Git? Donn has the course for you. In this FREE course, you’ll learn everything you need to know to start working with Git everyday. Watch it here.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs every week as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or kau.sh/blog or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

242 – Kotlin Code Formatting with ktfmt and spotless

Mon, 20 Mar 2023 01:00:00 UTC

Download directly

In this episode, Donn and Kaushik talk about one of the age old bike shedding topics – code formatting, and how you can solve it with automation and tools.

Code formatting can turn into an endless debate amongst peers and teams, and what Kaushik and Donn have found is that this can be delegated to a tool and automated. Freeing you and your team of having to worry about proper indentation, bracket placement, etc. By relying on a well defined tool and some automation you can clean your code up, make it much more uniform and easier maintain.

We talk about ktfmt, a Kotlin code formatter that was released by Facebook. We dive into ktlint, detekt and more. We also dive into spotless which can help you by integrating ktfmt into your gradle build pipeline.

Links #

ktfmt – website, github
spotless – github
detekt – website
ktlint – website

Donn’s Git Course #

Need to learn Git? Donn has the course for you. In this FREE course you’ll learn everything you need to know in order to start working with Git everyday. Watch it here.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or kau.sh/blog or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

241: The Pressure to Ship. Fear, Uncertainty and Doubt

Tue, 10 Jan 2023 08:30:00 UTC

Download directly

In this episode, Donn and Kaushik talk about the fear of shipping, some impostor syndrome and how it contributes to uncertainty and doubt in your capabilities as a software developer.

Recently Donn embarked on a mission to come up with an idea and ship it within 24 hours (which he did do). The end result was a net benefit of confidence, speed and skill acquisition. This helped reduce any doubt, uncertainty and ultimately fear of shipping a product faster.

That’s what this conversation is about … how to doing a project like the 24 hour MVP can remove fear, uncertainty and doubt and help you ship your side project/products faster.

Links #

Donn’s Git Course #

Need to learn Git? Donn has the course for you. In this FREE course you’ll learn everything you need to know in order to start working with Git everyday. Watch it here.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or kau.sh/blog or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

240: Important Kotlin Constructs

Thu, 15 Dec 2022 00:00:00 UTC

Download directly

In this episode, Donn and Kaushik talk about 5 new-ish Kotlin constructs that you might not be aware of.

The constructs that they talk about are:

fun interface (SAM – Single Abstract Method), and they juxtapose them vs function types
type alias
import alias
value class
data object

You’ll learn what they are, how you can use them and when or when you might not want to use them, and more. We hope you enjoy.

Links #

Enjoy!

Donn’s Git Course #

Need to learn Git? Donn has the course for you. In this FREE course you’ll learn everything you need to know in order to start working with Git everyday. Watch it here.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or jkl.gg/b or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

239: Require PR Reviews with CODEOWNERS

Mon, 28 Nov 2022 11:00:00 UTC

Download directly

In this short episode, Donn talks about the CODEOWNERS file and how it can help you ensure teams review the code that they are responsible for before merging.

The CODEOWNERS file is a file that you drop into the root of your project (or into the /docs or .github/ directory) that tells GitHub (or whatever git host you’re using) to require a review for any code changes that match the patterns as defined in the CODEOWNERS file. You’ll specify a matching pattern and users, or teams that own that pattern of files and they will be required to review the PR before it can be merged. This helps prevent unwanted changes to files that may or may not be owned by one team or another. This is useful as teams grow larger and need more control over the changes in their application codebase.

Links #

Donn’s Git Course #

Need to learn Git? Donn has the course for you. In this FREE course you’ll learn everything you need to know in order to start working with Git everyday. Watch it here.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or jkl.gg/b or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

238: How to Land a Job (if you got laid off or if you’re just starting out)

Mon, 21 Nov 2022 00:00:00 UTC

Download directly

In this episode, Donn talks about the tips and tricks he’s used over the last 20 years of consulting, freelancing and working full time to find jobs and new opporftunities. We’re hoping some of these tips help those affected by the recent tech layoffs.

These are tips that Donn still uses to this day. They work wonders to help you land a job quickly when you do them.

The tips:

Update your LinkedIn Profile and Build a Resume with the LinkedIn Resume Builder
Set your LinkedIn status to “Open to Work” via the “Open to Work” feature on LinkedIn
Directly Reach out to Recruiters you know or have interacted with
Manual Discovery: Visit various companies career pages and job board and apply directly

Ancillary Tips to Boost Your Chances of Landing a Job:

Blog about the technology you’re looking to get a job in
Create a demo app or an app you can use to showcase your talents and put it on GitHub
Record a How To Video and post it to YouTube showing how to do something, such as a tutorial
Record/Start a podcast or reach out to hosts of other podcasts and offer to share some deep knowledge you have, or even talk about soft skills, etc
Speak at local user groups or conferences (where you don’t need to worry about travel and costs, just show up and speak)

Links #

Donn’s Git Course #

Need to learn Git? Donn has the course for you. In this FREE course you’ll learn everything you need to know in order to start working with Git everyday. Watch it here.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or jkl.gg/b or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

237: Compose vs XML – Which one should you learn as an Android Dev?

Mon, 14 Nov 2022 12:00:00 UTC

Download directly

In this episode, Donn and Kaushik talk about their thoughts on Jetpack Compose and XML for Android layouts and which one you should learn first.

As with every conversation in tech … it depends on what you’re trying to do, where you are at in your career, what the company is doing and more. Donn and Kaushik go into both of their thought processes around Compose and XML and when you should learn one or the other, or even both and whether Jetpack is the future … or is XML here to stay?

Links #

Donn’s Git Course #

Need to learn Git? Donn has the course for you. In this FREE course you’ll learn everything you need to know in order to start working with Git everyday. Watch it here.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO. Post your Android Job and get it in front of thousands of Android pros.
Are you an Android Dev? Sign up to get notified of new jobs on a weekly basis.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or jkl.gg/b or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

236: A Terminal for Android?

Tue, 25 Oct 2022 09:00:00 UTC

Download directly

In this episode, Donn and Kaushik talk about the thought of having a terminal for Android.

Have you ever wished you could whip up a quick script to get the current location of a device, add it to cron and do some automated tasks on your phone? Wouldn’t it be nice to have low level access to your system like you do on your desktop?

In this episode, Donn and Kaushik dive into the details of what that might look like and why they find it intriguing.

Donn’s Git Course #

Need to learn Git? Donn has the course for you. In this FREE course you’ll learn everything you need to know in order to start working with Git everyday. Watch it here.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or jkl.gg/b or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

235: Pair programming with Ben Orenstein & Tuple

Tue, 20 Sep 2022 20:00:00 UTC

Download directly

In this episode, Kaushik goes solo and interviews Ben Orenstein. Ben is a prolific Ruby developer, an amazing conference speaker, an ardent vim-ster, and now the CEO of Tuple.

Kaushik has been a big fan of Ben’s work and was super stoked to talk to Ben and pick his brains on a host of topics: starting the company Tuple, pair programming in general, learning different programming languages and technology, giving better conference talks and more!

This episode is chock full of wisdom from Ben. Enjoy!

Links #

Contact #

Ben is @r00k listen to his podcast – The Art of Product

Follow @fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

kau.sh’s blog or @kaushikgopal (on Twitter)

234: More Product. Less Architecture?

Mon, 08 Aug 2022 01:00:00 UTC

Download directly

In this episode, Donn and Kaushik talk about how many Android applications seem to suffer from the disease of over-architecture while neglecting the product (UI/UX) itself. They discuss why this is deterimental to the user experience in the Android platform and how they’ve seen it evolve over the years. They attempt to provide some thoughful ideas on how this can be rectified in the future and more.

We’re looking for your feedback on this show. What are your favorite product apps that are just a joy to use on Android? Let us know on Twitter at @donnfelker and @kaushikgopal and @fragmentedcast

Donn’s Git Course #

Need to learn Git? Donn has the course for you. In this FREE course you’ll learn everything you need to know in order to start working with Git everyday. Watch it here.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or jkl.gg/b or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

233: UI Screenshot Testing with Paparazzi and John Rodriguez

Wed, 29 Jun 2022 08:00:00 UTC

Download directly

In this episode, Donn and Kaushik talk to John Rodriguez (jrod) about the Paparazzi library which allows you to perform UI screenshot testing on Android without emulators or physical devices.

They talk to John about what screenshot testing is, why it’s important, advantages and it’s disadvantages as well. You’ll learn how to use Paparazzi and how it can test various different screen configurations without having to run an emulator. You read that correct … without an emulator.

If you’re looking to incorporate screenshot testing into your app, this is the episode for you.

Links #

Donn’s Git Course #

Need to learn Git? Donn has the course for you. In this FREE course you’ll learn everything you need to know in order to start working with Git everyday. Watch it here.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or jkl.gg/b or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

232: Frustration, Flow State and “The Madness”

Mon, 13 Jun 2022 01:00:00 UTC

Download directly

In this episode Donn and Kaushik talk about frustration, finding “flow state” and how it’s known as “the madness” and how to deal with it.

We originally were going to talk about an other topic, but during the off air banter Donn brought up how he was frustrated with losing/burning so much time on a task that he had for his side project. He only meant to spend a little bit of time on it and then spent WAY more time than he meant to. He got to the point where he had to stop working on the project, yell at himself for not time boxing it and then he had to refocus. This piqued Kaushik’s interest and they decided to hit record to talk about this topic as its something they both deal with and have also hear many other developers deal with too.

The “Madness” is when you get consumed by your work and you’re so passionate that you lose track of time, eating and more. You’ve become consumed … you have “The Madness”. This happens to all developers, and Donn and Kaushik talk about how to not let this derail your day when you have other responsibilities as well as life and work. We hope you enjoy today’s off the cuff developer discussion.

Donn’s Git Course #

Need to learn Git? Donn has the course for you. In this FREE course you’ll learn everything you need to know in order to start working with Git everyday. Watch it here.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or jkl.gg/b or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

231: Learning Jetpack Compose with Vinay Gaba

Mon, 06 Jun 2022 01:00:00 UTC

Download directly

In this episode, Donn and Kaushik talk to Android GDE Vinay Gaba about learning Jetpack Compose.

They talk about how to learn how to use Jetpack Compose by example (and Vinay’s excellent talk by the same name). How to use Jetpackcompose.app to help you find the right Jetpack Compose component and how to use ShowKase to organize discover and visualize your Jetpack Compose Elements.

We then dive into why someone might want to learn Jetpack Compose and how to start learning it. They touch briefly on the parts of Compose, such as the compiler, runtime, UI, foundation, and more. They wrap up by talking about Unidirectional State flow and by answering the hot question … “Is Jetpack Compose ready for production?”

If you’re looking to learn more about Jetpack Compose, this is an episode for you.

Links #

Donn’s Git Course #

Need to learn Git? Donn has the course for you. In this FREE course you’ll learn everything you need to know in order to start working with Git everyday. Watch it here.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or jkl.gg/b or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

230: Feeling Like an Idiot

Mon, 30 May 2022 01:00:00 UTC

Download directly

In this episode Donn talks about that pit of the stomach feeling we all get when we feel like we should know something but we don’t. It’s that voice in our head as developers that makes you feel like an idiot even when you’re not.

Donn gives examples of how even senior engineers are subject to this feeling and how they are often the ones to not speak up about it simply because of their experience level and seniority.

This episode talks about why we get this feeling and how to combat it going forward.

Donn’s Git Course #

Need to learn Git? Donn has the course for you. In this FREE course you’ll learn everything you need to know in order to start working with Git everyday. Watch it here.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or jkl.gg/b or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

229: Native Where You Need It with Turbo (Launch Your Side Projects Faster)

Mon, 23 May 2022 08:15:00 UTC

Download directly

In this episode, Kaushik peppers Donn with questions about his foray into Android Turbo, Hotwire, and the concept of “Native Where You Need It”.

Donn recently launched Android Jumpstart, the Android client for the Jumpstart Rails trifecta. Jumpstart Rails allow you to launch your SaaS business much faster than if you were to do it from the ground up.

The Android client for Jumpstart Rails builds on top of Turbo and Hotwire, two technologies that help power the Hey email client and Basecamp (the project management app). By using Turbo and Hotwire you’re able to get very fast response times and speed with “HTML Over the Wire” (aka Hotwire) with Websockets and much more. This allows your web app to be super fast and when packaged with Android Turbo, allows your web app to live within a native shell. HOWEVER, this doesn’t mean its simply a web wrapper. With Android Turbo you can specify which URL routes you’d like to be as native and which ones you’d like to remain web-based. This means you can choose to use Native when you need it, and delegate back to the web for everything else.

This is the solo founder, indie-hacker, and startup SaaS dream come true. You can come to market faster, iterate with a smaller team and get native benefits when and where you need it, all while also allowing your application to be flexible in a web manner.

If you’re thinking about building a SaaS app that needs a web presence, Android and iOS presence but want fully native experiences in certain areas then this will be the episode for you.

Links #

Donn’s Git Course #

Need to learn Git? Donn has the course for you. In this FREE course you’ll learn everything you need to know in order to start working with Git everyday. Watch it here.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or jkl.gg/b or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

228: Expo Development with Konstantin Liakhovskii

Mon, 18 Apr 2022 01:00:00 UTC

Download directly

In this episode Donn and Kaushik talk to Konstantin Liakhovskii about Expo development and how it takes cross platform development and its productivity to the next level.

Konstantin dives deep into the usages and reasons why Expo (and React Native) are still very good options for companies that are looking to adopt a cross-platform application.

Links from the show #

Stoa #

Stoa is a community platform for creators and anyone who wants to monetize their community. Sign up at getstoa.com and get 3 months free when we launch. Early access coming soon.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or jkl.gg/b or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

227: Exotic Car Salesman to Mobile Developer with Ephraim Schmitt

Mon, 11 Apr 2022 01:00:00 UTC

Download directly

In this episode Donn sits down and talks to Ephraim Schmitt about how he changed careers from being an exotic car salesman to a mobile software developer. It’s a fascinating and inspiring story for anyone looking to get into software development.

We talk about the mental and financial struggles, how he learned to start coding, how you can find opportunities everywhere, how to interview better, where to look for positions when you’re just starting out, why volunteering/doing something for free early on is fast way to open doors and build your network and so much more.

If you or anyone you know is looking to break into the software industry, this is the podcast for you. You’ll leave with a couple pages of notes, tips and the inspiration you need to jump into the world of software development.

Links from the show #

1st Phorm (Ephraim’s current employer)

#

Stoa #

Stoa is a community platform for creators and anyone who wants to monetize their community. Sign up at getstoa.com and get 3 months free when we launch. Early access coming soon.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or jkl.gg/b or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

226: The Reunion – Themes, VS Code and More

Mon, 04 Apr 2022 01:00:00 UTC

Download directly

In this episode Donn and Kaushik are back together on the mic. After an extended break, they both returned renewed and ready to dive into all things software, starting off with IDE themes, plugins and what they’ve been up to since they were last on the show together.

Links from the show #

Monokai Pro Theme
- VS Code & Atom
- IntelliJ/Android Studio/WebStorm/etc
VS Code Plugins
- Beautify
- Change Color Format
- Fish VS Code
- Python
- Pylance
- Shell Format
- Git Lens
- ES Lint
- Prettier
- Rainbow CSV
- TailwindCSS Intellisense
- Ruby
- TypeScript
Caper.AI
Stoa – Community Platform for Creators
Freelance Faction – Donn’s Freelance Community

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or jkl.gg/b or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

225: Don’t Give Up – Persevere

Mon, 28 Mar 2022 01:00:00 UTC

Download directly

In this episode Donn talks about something not giving up and persevering when the going gets tough in software, your career and more. It’s easy to give up, but the real reward is when you persevere.

Links from the show #

Growth Mindset Book

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Software Freelancing #

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or jkl.gg/b or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

224: Our Latest Book Recommendations

Mon, 22 Nov 2021 00:00:00 UTC

Download directly

In this episode, Donn and Kaushik talk about some of the books that they’re reading and thoughts and recommendations on each.

Links from the show #

Donn’s Books #

Kaushik’s Books #

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Donn’s Book on Freelancing Tactics #

Freelance Tactics

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

223: Productivity with TODO Apps and Personal Knowledge Management Systems

Mon, 11 Oct 2021 01:00:00 UTC

Download directly

In this episode, Donn and Kaushik reunite for an episode on how they use productivity tools like various todo apps as well as how the organize information for storage and easy retrieval in their day to day lives.

Shownotes #

Links from the show #

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well. m* AndroidJobs.IO

Donn’s Free E-Book on Freelancing/Consulting Rates #

Free E-Book on Freelancing Rates

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

222: Managing Android devices (EMM) with Prabhjot

Mon, 27 Sep 2021 01:00:00 UTC

Download directly

In this episode, Kaushik talks to his good friend Prabhjot and learns about “Android Enterprise“. This is the official way for companies or organizations to enable the use of Android devices and apps in the workplace.

Prabhjot talks about how he setup the infrastructure to provision devices and the different capabilities the solution allows.

If you ever wondered what kind of control is possible, listen to this episode and get a nice scary reality check. After listening to this episode, you’ll think twice before accepting free devices from companies or letting policy apps be installed on your phone.

Links from the show #

Android Enterprise
- Terminology
- Feature List
Oracle Cloud Free (not a referral link)
- 10 TB of outbound data transfer free (vs 1GB from competitors)

Contact #

@fragmentedcast or our Youtube channel
Prabhjot on Twitter
Donn
- @donnfelker and donnfelker (on Instagram)
- Freelancing for Mobile Developers (Donn’s YouTube)
Kaushik
- @kaushikgopal and kaushikgopal (on Instagram)
- kaushikgopal (on YouTube) or Kaushik’s Blog

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Donn’s Free E-Book on Freelancing/Consulting Rates #

Free E-Book on Freelancing Rates

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

221: How to Introduce Seams into Legacy Code

Sun, 08 Aug 2021 01:00:00 UTC

Download directly

In this episode, Donn continues to dive into his favorite software book: Working Effectively with Legacy Code. He talks about one of the fundamental tactics of the book: Introducing seams

You’ll learn what a seam is according to the book, as well as how Donn interprets it so that you can get the same benefit he has gotten from it. You’ll learn how to introduce seams into your codebase through method injection, interfaces, abstract classes, and the static gateway pattern (aka: wrapper pattern).

Links from the show #

Working Effectively with Legacy Code

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Donn’s Free E-Book on Freelancing/Consulting Rates #

Free E-Book on Freelancing Rates

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

220: Turbo Native for Android and Hotwire with Jay Ohms

Mon, 02 Aug 2021 01:00:00 UTC

Download directly

In this episode, Donn talks to Jay Ohms about Turbo Native for Android, Hotwire, and how to build apps faster with Hotwire, Turbo, Stimulus, and Strata. Jay is an Android developer at Basecamp.com and Hey.com and has been building Hey with Android Turbo since it has been released (he’s one of the developers of it).

You’ll learn what Hotwire is, how to use it with Android Turbo (and Stimulus and Strata) and how you can create apps faster and more maintainable by marrying the concepts of the web with native code. It’s a fascinating technology, and one that Donn will be using very shortly for a SaaS product he’s working on.

Links from the show #

Hotwire.dev
Turbo Native for Android
Turbo Native for iOS
Stimulus
Hey
Basecamp
Basecamp is Hiring an Android Dev – email jay @ basecamp dot com

Get Ahold of Jays Contact #

Jay’s Twitter
Email: jay @ basecamp dot com

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Donn’s Free E-Book on Freelancing/Consulting Rates #

Free E-Book on Freelancing Rates

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

219: The Legacy Code Change Algorithm

Mon, 19 Jul 2021 01:00:00 UTC

Download directly

In this episode, Donn talks dives into his favorite software book: Working Effectively with Legacy Code. He talks about one of the introduction level topics: The Legacy Code Change Algorithm

You’ll learn what it is and how you can use it as the basis for this new series that will be focused on the book, Working Effectively with Legacy Code.

Links from the show #

Working Effectively with Legacy Code

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Donn’s Free E-Book on Freelancing/Consulting Rates #

Free E-Book on Freelancing Rates

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
Freelancing for Mobile Developers (Donn’s YouTube)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal
Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

218: Growth Mindset with Software Developer Alan Hill

Mon, 05 Jul 2021 01:00:00 UTC

Download directly

In this episode, Donn talks to software developer Alan Hill about the Growth Mindset and how it applies to software development and life in general.

They chat about pull request feedback lifecycle, learning new tech, and how applying a growth mindset can advance you in your career further than you could have imagined. They wrap up by going through Fixed Mindset vs Growth Mindset “back and forth” to discuss the differences.

Alans Link #

Alan Hill Social and Web Links

Links from the show #

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Donn’s Free E-Book on Freelancing/Consulting Rates #

Free E-Book on Freelancing Rates

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
Freelancing for Mobile Developers (Donn’s YouTube)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal
Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

217: Working at a Big Tech Company vs Freelancing

Wed, 30 Jun 2021 03:00:00 UTC

Download directly

In this episode, Donn talks about the difference between working at a big tech company vs freelancing.

There are many pro’s and con’s for each. What is best for you? Listen to the episode and find out.

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Donn’s Free E-Book on Freelancing/Consulting Rates #

Free E-Book on Freelancing Rates

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
Freelancing for Mobile Developers (Donn’s YouTube)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal
Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

216: Code Conventions – Why It’s Important to Follow Them

Wed, 23 Jun 2021 13:51:29 UTC

Download directly

In this episode, Donn talks about the importance of following code conventions and coding styles in codebases.

You’ll run into various different coding conventions throughout your career. Sometimes it’s as an employee, sometimes it’s as a freelancer or consultant or just a small side project. The number of coding “styles” that you’ll see will blow your mind as you work through your career. The big question is … should you adhere to the current coding convention that is used in the app/file/etc or should you use your own favorite or an industry standard?

In this episode, I’ll help explain the differences so you can make an informed decision going forward.

Links from the show #

Martin Fowlers Blog

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Donn’s Free E-Book on Freelancing/Consulting Rates #

Free E-Book on Freelancing Rates

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
Freelancing for Mobile Developers (Donn’s YouTube)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal
Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

215: From Side Project to Full Time via Watch Faces with David Whittaker and Ross Manges

Mon, 14 Jun 2021 01:00:00 UTC

Download directly

In this episode, Donn talks to David and Ross from Squeaky Dog Studios about building a business out of a side project.

David and Ross are long-time serial side project developers with experience that dates back to the Palm era. They’ve built games, apps, and now Watch Faces.

We dive deep into how they went from building their watch faces for Android as a side project and how they turned it into a full-time business in which one of the co-founders works full-time. We talk about building the app, pricing, support, which features to build, paid vs free, trial conversions, supporting your app and much much more.

If you’ve ever wanted to build a side project into a business, and it’s app-based… this one is for you.

Links from the show #

David and Ross’s Links #

Android Apps by Squeaky Dog Studios on Google Play

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
AndroidJobs.IO

Donn’s Free E-Book on Freelancing/Consulting Rates #

Free E-Book on Freelancing Rates

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
Freelancing for Mobile Developers (Donn’s YouTube)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal
Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

214: 3 Things Every Developer Needs To Know How To Do

Mon, 07 Jun 2021 01:00:00 UTC

Download directly

In this episode, Donn talks about the three things that every developer needs to know how to do.

These three things include:

How to identify and stop premature optimization
How to write tests and know the difference between unit, integration and end-to-end tests.
How to set up a continuous integration server

While there are vast arrays of other things all developers need to know how to do, and we will cover them in future episodes, this small list will help you vastly in your career. It has helped mine (Donn) a ton.

Links from the show #

Continuous Integration Server Platforms #

Managed Services
1. Github
2. GitLab
3. Bitbucket
4. Azure Devops
5. CircleCI
6. Bitrise
7. Codemagic
Self hosted
1. Jenkins
2. TeamCity

Book #

Working Effectively with Legacy Code by Michael Feathers

AndroidJobs.IO #

Job postigns are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notififed of new jobs on a weekly basis as well.
AndroidJobs.IO

Donn’s Free E-Book on Freelancing Rates #

Free E-Book on Freelancing Rates

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
Freelancing for Mobile Developers (Donn’s YouTube)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal
Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

213: How to Pick What Technology to Learn Next

Mon, 31 May 2021 01:00:00 UTC

Download directly

In this episode, Donn answers a listener’s question. The listener wanted to know how to choose what to learn next in Tech.

Donn provides 6 tips (actually 7 if you count a hidden one) on how to pick what technology to learn next. He provides a simple framework that will help you check whether you should pursue a particular technology or not.

Links from the show #

AndroidJobs.IO #

Job postings are FREE on AndroidJobs.IO during the early release phase (at the time of this recording).
Sign up to get notified of new jobs on a weekly basis as well.
Post jobs and sign up here: AndroidJobs.IO

Donn’s Free E-Book on Freelancing/Consulting Rates #

Free E-Book on Freelancing Rates

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Freelancing for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

212: Growing an Online Presence in the Software Industry with Philipp Lackner

Mon, 24 May 2021 01:00:00 UTC

Download directly

In this episode, Donn talks with Philipp Lackner about growing an online presence within the Software Industry with Instagram and YouTube.

Shownotes #

You’ll learn how Philipp went from 0 to over 80,000 followers on Instagram. This was done all organically by posting valuable content every single day to his feed.

You’ll also learn how he uses YouTube (as well as Instagram) as a marketing channel for his own course products that he sells via his site.

We wrap up by talking about content strategy, what tools are used, captions and hashtags. This episode is chock full of great info if you’re learning how to grow your following online.

Tools that Philipp Mentioned #

Find Philipp Lackner online here #

Donn’s Free E-Book on Freelancing/Consulting Rates #

Free E-Book on Freelancing Rates

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
Freelancing for Mobile Developers (Donn’s YouTube)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal
Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

211: Why Learning React is Good For You as a Developer

Tue, 18 May 2021 01:00:00 UTC

Download directly

In this episode Donn talks about why you need to learn React (or Flutter) – so you can truly understand the Unidirectional data flow pattern in a framework that was built for that purpose alone.

Working with other frameworks which bolt on a custom unidirectional data flow is often hard to understand. When you work with React and learn how it works, the concept of Unidirectional data flow starts to make much more sense as that is the default way to implement UI’s in technologies like React (and Flutter).

This exposes you to the pattern and helps you understand it. In turn, this will help you become a better developer.

Show Notes #

Unidirectional Data flow Image

How to learn React:

How to Learn Flutter

Donn’s Free E-Book on Freelancing Rates #

Free E-Book on Freelancing Rates

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
Freelancing for Mobile Developers (Donn’s YouTube)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

210: Kotlin Multiplatform Mobile (KMM) with Mitch Tabian

Mon, 10 May 2021 01:00:00 UTC

Download directly

In this episode, Donn talks with Mitch Tabian about Kotlin Multiplatform Mobile, also known as KMM.

Mitch explains what KMM is, why he decided to use it, and how it works from a developer’s perspective. The goal was to build an app and develop both the iOS and Android versions. Mitch talks about his experience in building a KMM app. We cover the pros and cons, what worked vs what did not, and his advice on using KMM going forward. Mitch also shares content about how to build native components in Jetpack Compose and SwiftUI as well as architectures used in his KMM project.

Links from the show #

Find Mitch online here: #

Donn’s Free E-Book on Freelancing Rates #

Free E-Book on Freelancing Rates

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
Freelancing for Mobile Developers (Donn’s YouTube)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

209: Secure Development Lifecycle with Glenn Leifheit

Mon, 03 May 2021 01:00:00 UTC

Download directly

In this episode, Donn talks with Glenn Leifheit from Microsoft about a concept known as “Secure Development Lifecycle”. Glenn is a Senior Security Program Manager at Microsoft.

Glenn explains to you what the secure development lifecycle is, how it works and how you can implement something like this in your company. He also shares the top tips you can implement in order to get the quickest benefit of the Secure Development Lifecycle

Links from the show #

Application Inspector: GitHub
DevSkim: GitHub
Attack Surface Analyzer: GitHub
OSS Gadget: GitHub
Recursive Extractor: GitHub
Microsoft SDL: Microsoft Security Development Lifecycle
CodeQL: CodeQL for research | GitHub Security Lab
OWASP: OWASP Foundation | Open Source Foundation for Application Security
OWASP Top 10: OWASP Top Ten Web Application Security Risks | OWASP
OWASP Web Security Testing Guide: OWASP Web Security Testing Guide
Python basic code analysis: Pylint – code analysis for Python | www.pylint.org
TypeScript basic code analysis: GitHub – typescript-eslint/typescript-eslint: Monorepo for all the tooling which enables ESLint to support TypeScript

Find Glenn online here #

Donn’s Free E-Book on Freelancing #

Free E-Book on Freelancing Rates

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
Freelancing for Mobile Developers (Donn’s YouTube)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

208: Developing Software at Startups with Jason Roberts

Mon, 26 Apr 2021 01:00:00 UTC

Download directly

This is the original story of how Uber was built … this is a fascinating story. You don’t want to miss this. Donn talks to Jason Roberts. Jason was chosen to be Uber’s CTO when the company was in its infancy (but didn’t accept the offer). Jason shares the story of developing the code that eventually ran Uber from a couple of cars to a highly distributed system with an impressive amount of rides.

We talk about building what is needed when it’s needed, the tools that he chose to build Uber’s platform on. Early startup learnings, and how Uber originally ran on PHP before he chose to move it to Node.js.

Jason shares his story of how he met Travis (Uber’s CEO who took it from a small company to a huge international corporation), how they built the systems, and team and much more. You’ll learn how networking, working on interesting things, and seizing the moment and luck played into him landing his role at Uber.

Finally, we wrap up by chatting a bit about how being a generalist in an early-stage startup is beneficial (vs being a specialist).

Find Jason online here #

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Consulting for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

Disclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

207: How to Optimize Your Home Office

Tue, 20 Apr 2021 09:30:00 UTC

Download directly

In this episode, Donn outlines how you can optimize your home office so that you look, sound, and perform the best that you can. From audio to video, to your body, and everything beyond, it’s covered here.

Shownotes #

Donn talks about everything you can do to improve your home office. From microphones, lighting, and webcams for your video calls to chairs, standing desks, and more. This episode has all the links below for all the products discussed.

Take even 20% of the recommendations and apply them to your home office and you’ll see a drastic difference in your productivity and happiness in your home office.

Links to Items Discussed #

Microphones

Boom arms for Mics

Webcams

Docking Hub

Lighting

Headphones

JVC Xtreme-Xplosivs Wired Earbuds – Donn’s Go to

Sony MDR-7506 Professional Headphone

Audio Technical M20x

No, I don’t use Bluetooth headsets at work, though many do. If they work for you, you might want to check out the Audio Technica ATHM50XBT’s or the Bose Quiet Comfort 35’s

Chairs

Standing Desk

Anti-Fatigue Mats

Monitor and Monitor Arms

Keyboard

Mouse

Air Quality

Focus Music

Mobility, Desk Ergo, and Back Pain Resources

Contact #

@fragmentedcast or our Youtube channel

@donnfelker and donnfelker (on Instagram)

Consulting for Mobile Developers (Donn’s YouTube)

kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

Disclaimer: Many of the links are affiliate links. They help suppor the production of Fragmented. Thank you for your support.

206: DevOps for Developers with Will Button

Mon, 12 Apr 2021 01:00:00 UTC

Download directly

In this episode, Donn talks with DevOps expert, Will Button about everything DevOps-related. If you’re ever wondered how and what DevOps is, then listen in.

Shownotes #

Will walks you through the definition of DevOps and how it’s used in a company. You’ll learn the 20% of DevOps you should know that will get you 80% of the benefit. You’ll also learn about a bunch of automation technology that will help you and your team level up your environments so that you can become super efficient in your day-to-day engineering activities. In this episode, Donn talks about the best way to learn a new technology from the ground up. Want to learn something new? This episode is for you.

You’ll learn Donn’s proven 5-step methodology for learning new technology. This is the same method Donn has used for over 2 decades of learning new technology. We hope it helps you.

Find Will Online #

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
Consulting for Mobile Developers (Donn’s YouTube)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

205: How to Learn New Technologies

Thu, 08 Apr 2021 01:00:00 UTC

Download directly

In this episode, Donn talks about the best way to learn a new technology from the ground up. Want to learn something new? This episode is for you.

You’ll learn Donn’s proven 5-step methodology for learning new technology. This is the same method Donn has used for over 2 decades of learning new technology. We hope it helps you.

Shownotes #

The 5 Steps:

Choose a Simple Problem Domain (Note Taking app or Calorie/Protein Tracker)
Do not worry about best practices
Start Small, then go smaller: Super tiny nibbles of work
Build Something Ugly and just “Get it working”
Don’t Conflate Technologies if you don’t have to. Keep it simple.

Donn’s Free 9+ Hour Kotlin Course #

Watch the entire course here, for free

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
Consulting for Mobile Developers (Donn’s YouTube)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

204: Quality over Quantity

Mon, 29 Mar 2021 01:00:00 UTC

Download directly

In this episode, Donn returns for a solo episode to talk about his thoughts on Quality over Quantity and why it’s important to software development and productivity in general.

Shownotes #

What is being “in Flow”? – Learn more

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
Consulting for Mobile Developers (Donn’s YouTube)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

203: Jetbrains Projector with Joaquim

Sun, 07 Mar 2021 19:00:00 UTC

Download directly

In this episode, we talk to acclaimed Android developer Joaquim Verges. He recently embarked on a journey of making is laptop not burn like a furnace when using Android Studio. He landed up on this unknown effort by Jetbrains called Projector and seems to have found programmer Nirvana.

Listen to his adventures.

Shownotes #

How to Run Android Studio on ANY Device With JetBrains Projector
Mirakle Gradle plugin
Jetbrains M1 Macbook updates:
- Jetbrains JBR-2526
- IntelliJ IDEA 2020.3.1 Is out with Apple Silicon Support

Jetbrains Projector #

Contact #

@joenrv
@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

202: Dagger on the Anvil with Ralf Wondratschek

Mon, 01 Feb 2021 07:56:21 UTC

Download directly

Anvil is a Kotlin compiler plugin that makes your life a tad bit easier when using Dagger 2. In this episode we talk to Ralf Wondratschek from Square who created the library and open sourced it for all of us.

After touching on some of the basics, Ralf dives into the thinking behind Anvil and how it evolved into the tool it is today. It’s filled with nuggets of wisdom especially if your app uses Dagger for Dependency Injection.

Enjoy!

Shownotes #

Anvil for Dagger
Ralf’s talk at Droidcon: Android at Scale @Square
Slides for above talk

Contact #

@vRallev
@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

201: State of the Testing Union with Valera Zakharov

Mon, 02 Nov 2020 05:00:00 UTC

Download directly

In episode 1 of Fragmented we talked about Testing. 200 episodes in, we decided it’s a good time to do a state of the union for mobile testing. We talk with Valera Zakharov who’s a Staff Engineer at Slack and considered one of the experts in the field of mobile testing. Hope you enjoy this one!

Shownotes #

Contact #

@valera_zakharov
@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

200: Serverless Programming

Mon, 05 Oct 2020 06:07:27 UTC

Download directly

In our 200th episode, we talk about Serverless Programming.

What is it? What’s an example of a service I could build with Serverless Programming? What are the advantages or disadvantages? We talk about it all in this episode.

Also, 🙏 for being listeners. We’ve stuck together for 200 of these. Kaushik & Donn are incredibly grateful to have you folks as listeners.

Shownotes #

Heroku
Platform as a Service
Donn’s gif service gifstagram.com
Flippa : Buy and Sell services online
Founder’s Chats: Ep 41
Options for different services:
- AWS Lambda Function
- Azure Functions
Postman : The Collaboration Platform for API Development
Vercel

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

199: iOSDev vs AndroidDev.lazy().not()

Mon, 21 Sep 2020 06:37:53 UTC

Download directly

A tweet from a famous tech journalist about Android vs iOS spurs a storm. In this episode, Donn and Kaushik given their honest thoughts on iOS vs Android; and being developers for the platform.

Shownotes #

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

198: Fragmented.reset( Mode.Indie )

Mon, 14 Sep 2020 09:00:19 UTC

Download directly

We’re back and Fragmented is going Indie again. A quick episode on the future of Fragmented.

New Artwork! Story on how Swapnil helped with our new artwork

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

✊🏽✊🏾✊🏿

Mon, 08 Jun 2020 05:55:05 UTC

Download directly

We interrupt our regular programming for this extremely important message.

We stand with our black sisters and brothers against the evil that is racism. The recent events of police brutality and oppression against black people have been truly horrifying.

Please take the time to listen to the audio snippet on the #BlackLivesMatter movement from today’s episode. It is a TedX talk by the far more eloquent Kennedy Cook who’s voice and words are more powerful than ours.

We’ve never been very vocal about political issues on Fragmented. But that doesn’t mean we don’t care about these issues. On the contrary! We do our best to have our actions speak louder than our words and let others with first-hand experience speak out. Then importantly we aim to listen.

But these aren’t regular times are they? The horrifying brutality we’re seeing against people of color is nauseating. The Covid-19 outbreak has made action particularly difficult so for today we will start with these words.

More Resources on how we can help: #

197: .git internals with Gordon 🔧

Mon, 04 May 2020 05:00:00 UTC

Download directly

OK, If you really want to know how git works, this is the episode for you. KG talks with his longtime colleague and mentor Gordon McCreight. Gordon is a wiz in general but his knowledge of git goes deep. So in this episode, KG goes solo and really dives in-depth about how git works.

Buckle up and listen on; you’ll come out on the outer side with a much sounder understanding of git.

Shownotes #

Objects which are no longer referenced can be evicted with git prune; though this is a low-level operation which is often called from git gc. By default it will not remove commits newer than 2 weeks old, and of course the commits that are reachable from that; so provided the branch (or tag) deleted has recent commits, it will stay around in the git repository for up two a fortnight afterwards.

Git internals by John Britton of GitHub – CS50 Tech Talk

Sponsors 🙏 #

Educative.io #

Learn and practice Android development from inside your browser. Visit Educative.io/Fragmented to get 10% off.

Contact #

@gmccreight
@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

196: Composing with Leland 👨‍🎨

Mon, 27 Apr 2020 05:00:00 UTC

Download directly

In this episode, we chat with friend of the show Leland Richardson. Leland is a main contributor to Jetpack Compose. But in this episode, we pepper him with questions on how he came to the position he’s in viz. a reputed Software Engineer contributing to probably the most cutting edge library in development for Android.

This was a treat and inspiring episode! Listen on:

Shownotes #

Sponsors 🙏 #

Educative.io #

Learn and practice Android development from inside your browser. Visit Educative.io/Fragmented to get 10% off.

Contact #

@intelligibabble
@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

195: Going on-call 🚨

Mon, 20 Apr 2020 05:00:00 UTC

Download directly

Have you ever gone on on-call rotations for your company? What is on-call? How to operate a successful on-call strategy? What does on-call for mobile mean? What are some tools and resources to help with on-call rotations?

In this episode Donn and Kaushik dive into these topics.

Shownotes #

Good resources #

Steps to handle on-call #

Triage
Coordinate
Mitigate
Resolve
Follow up (Root Cause Analysis or Post Mortem)

Sponsors 🙏 #

Educative.io #

Learn and practice Android development from inside your browser. Visit Educative.io/Fragmented to get 10% off.

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

194: Polyglot programmers 🐙

Mon, 13 Apr 2020 05:00:00 UTC

Download directly

What are Polyglot programmers, should you be one? Listen to this episode and find out!

Shownotes #

KG’s youtube screencast
awk programming language
Smart and Gettings Things Done : Joel Sposky
Ep #119: Flutter with GDE Eugenio Marletti
Learning Ruby: Why’s poignant GUIDE to Ruby

Sponsors 🙏 #

Educative.io #

Learn and practice Android development from inside your browser. Visit Educative.io/Fragmented to get 10% off.

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
kaushikgopal (on YouTube) or b.jkl.gg or @kaushikgopal

193: Working from Home – Pandemic on hard mode 🏡

Mon, 06 Apr 2020 05:55:00 UTC

Download directly

Well, the world took a crazy turn and everyone’s working from home now. How do you work from home? An experienced developer who’s done this before talks to a newbie and discuss their thoughts.

Shownotes #

Maker’s schedule vs Manager’s schedule
git commit --allow-empty -m "todo: listen to fragmented" -m "send KG & DF<br /> tweet"
git squash & merge
Instacart.com
Autonomous AI Smart desk
Android from the trenches
Jarvis Bamboo Standing desk
Ergo driven TOPO footmat

Sponsors 🙏 #

Educative.io #

Learn and practice Android development from inside your browser. Visit Educative.io/Fragmented to get 10% off.

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

192: What is your backup strategy? 📼

Tue, 17 Mar 2020 04:36:00 UTC

Download directly

In this episode, we talk about what a good backup strategy looks like and the different kinds of data you should be backing up.

Stay safe and think about your backup strategies.

Shownotes #

3-2-1 Backup Rule #

Backup Software #

KG’s primary Mac:
- SuperDuper! by Shirt Pocket for bootable backups
- Arq Backup for versioned backups -> Backblaze B2 Cloud Storage
rsync script that KG uses:

This mirrors both drives defensively (-n is dry run)

 rsync --partial --progress --archive --update \
--verbose\
--human-readable\
--exclude='$RECYCLE.BIN' --exclude='$Recycle.Bin' --exclude='.AppleDB' \
--exclude='.AppleDesktop' --exclude='.AppleDouble' --exclude='.com.apple.timemachine.supported'\
--exclude='.dbfseventsd' --exclude='.DocumentRevisions-V100*' --exclude='.DS_Store'\
--exclude='.fseventsd' --exclude='.PKInstallSandboxManager' --exclude='.Spotlight*'\
--exclude='.SymAV*' --exclude='.symSchedScanLockxz' --exclude='.TemporaryItems'\
--exclude='.Trash*' --exclude='.vol' --exclude='.VolumeIcon.icns' --exclude='Desktop DB'\
--exclude='Desktop DF' --exclude='hiberfil.sys' --exclude='lost+found'\
--exclude='Network Trash Folder' --exclude='pagefile.sys' --exclude='Recycled'\
--exclude='RECYCLER' --exclude='System Volume Information' --exclude='Temporary Items' --exclude='Thumbs.db'\
-n\
/Volumes/xhd_strg/ /Volumes/xhd_strg_bkp

Misc #

Wirecutter recommends SeaGate drives instead of the Western Digital Kaushik uses 🤷‍♀️

Sponsors 🙏 #

Square #

Check out the new Square YouTube channel for developers. Square has SDKs and APIs to make payments and run a business.

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopal

191: Logging 🌲

Mon, 09 Mar 2020 14:56:00 UTC

Download directly

Today we talk about logging. When to log, how to log, what to log – our thoughts on the subject.

Shownotes #

GDPR
Android Logging priorities
LogDna
Loggly
Datadog
Papertrail
Android logging: Timber by Jake
JS Logging: Winston
Google – libphonenumber
Fragmented Podcast Episode #145: Tracking Network Requests With x-Request-ID

Sponsors 🙏 #

Square #

Check out the new Square YouTube channel for developers. Square has SDKs and APIs to make payments and run a business.

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and blog.kaush.co

190: The Privacy of ***********

Mon, 24 Feb 2020 05:00:00 UTC

Download directly

In this episode, Donn and KG talk about the post Tim Bray recently wrote – Why Google did Android. They then touch on Chrome becoming a monopoly and tips on what folks can do to be a little more privacy conscious on the web.

Shownotes #

Google Chromium and Ad-blocking #

Misc #

New Microsoft Edge is based on Chromium
Download Firefox
Firefox Multi-Account Containers add-on + Temporary Containers for the privacy conscious.

Follow up from a previous episode: #

Svelte : framework that spawned from New York Times. Thanks Midhun.

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal or blog.kaush.co

189: The 2038 Problem

Mon, 17 Feb 2020 05:00:00 UTC

Download directly

We’ve all heard of the Y2K problem, but there’s also a similar coming up this 2038 for us programmers. In this episode we dive into the 2038 problem (… after of course talking about our opinions on new year resolutions).

Get 1% better every day folks… Listen here:

Shownotes #

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal or blog.kaush.co

188: Containerized applications with Docker

Mon, 03 Feb 2020 05:03:00 UTC

Download directly

In this episode KG and Donn talk about KG’s recent jaunt with Docker. In the attempt to setup continuous deployment for his blog, KG explains his simple requirement and how it lands up requiring some basic Docker. Donn then closes it out with some interesting in-depth knowledge on how to use Docker

Personal website hosting #

Domain checking services #

Docker #

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

187: Coroutines with Manuel Vivo & Sean McQuillan

Tue, 21 Jan 2020 05:00:00 UTC

Download directly

It finally happens! KG and Donn talk about Coroutines with two experts at Google Manuel & Sean. We’ve waited quite sometime on Fragmented to discuss this topic. We wanted to make sure Coroutines was mature enough to be compared with the contenders. Listen to find out more!

Resources #

Contact #

Sean McQuillan @objcode
Manuel Vivo @objcode
Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

186: Announcement 2020

Mon, 06 Jan 2020 05:01:00 UTC

Download directly

An important announcement.

185: Year End Decompress

Mon, 16 Dec 2019 05:00:00 UTC

Download directly

In this decompress episode, Donn and KG talk about how their 2019 went. It goes from Dagger talk to Kotlin talk to Kotlin Conf talk. Give it a listen and enjoy!

Sponsors 🙏 #

Square #

Square has SDKs and APIs to make payments and run a business. Even better, Square has a new YouTube channel for developers! Check out Square’s new YouTube Channel for Developers at youtube.com/squaredev and let them know you heard about it from us.

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

184: Should I use a BaseActivity in my Android apps?

Mon, 02 Dec 2019 05:00:00 UTC

Download directly

In this episode, Kaushik tries to talk through this question.

Thanks to friends of the show Jeroen, Yigit and a bunch of others who ran through some ideas on this one.

Sponsors 🙏 #

Square #

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

183: The Testing Paradox

Mon, 25 Nov 2019 05:00:00 UTC

Download directly

How do you know what to test when you don’t even know how to write the code that you need to test? This is a paradox that many developers find themselves in daily.

In this episode Donn talks about his strategy for dealing with unknowns in programming, namely around testing and how to figure out how to write tests for new code that might be difficult, unfamiliar or even legacy code.

Links #

Sponsors 🙏 #

Square #

Flatiron School #

Learn UX/UI design flatironschool.com/fragmented in 24 weeks and discover our global community on campus or online and go back to school with Flatiron School! flatironschool.com/fragmented!

Change careers with confidence with 1:1 support from our dedicated Career Coaches and a money-back guarantee. Complete details at flatironschool.com/terms.

See you in class!

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

182: Where do I put DB objects in a modularized Android app?

Mon, 18 Nov 2019 05:00:00 UTC

Download directly

App Modularization has plenty of benefits and a lot of Android devs today are starting to modularize their android app.

A common problem though that most folks will start to run into is – how do you manage your database objects in these modules? do you create a single module with all your database dependencies (modularize by layer), do you do the right thing and modularize by feature so each module has it’s own database file etc.?

In this episode Kaushik grapples with that question and tries to come up with an answer.

Shownotes #

Modularization (KG’s favorite resources) #

Google IO 19 : Build a modular Android app architecture
Jeroen Mols’s posts : Modularization – Why you should care
Joe Birch’s posts : Modularizing Android Appications
Ep 117 : Multi Module Builds in Gradle
Karan Trehan’s post : Writing a modular project on Android

Sponsors 🙏 #

Vettery #

Vettery is an online hiring marketplace that is changing the way people hire and get hired. Make a free profile, name your salary, and connect with hiring managers from top employers today.

Listeners of Fragmented get a $300 bonus if you accept a job through Vettery! Sign up at vettery.com/fragmented

—

Flatiron School #

Learn UX/UI design flatironschool.com/fragmented in 24 weeks and discover our global community on campus or online and go back to school with Flatiron School! flatironschool.com/fragmented!

Change careers with confidence with 1:1 support from our dedicated Career Coaches and a money-back guarantee. Complete details at flatironschool.com/terms.

See you in class!

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

181: In Functional Programming how to do IO and database operations

Wed, 13 Nov 2019 05:00:00 UTC

Download directly

In the world of Functional programming where pure functions don’t encourage side-effects, how does on actually do any IO?

So in this brave new world where everyone is adopting more FP principles, do we just stop doing database operations? Listen to this episode to find out.

Functional Programming basics #

Ep 83 : Learning the basics of functional programing with Anup Cowkur
Ep 120 : Functional Programming with Kotlin Arrow team
Ep 121 : Functional Programming with Kotlin Arrow team (Part 2)

Unidirectional State Flow #

Ep 148 and Ep 151
KG’s speakerdeck slide
KG’s Movie search apps Android app + iOS app

Resources for FP/IO contention #

Sponsors 🙏 #

Flatiron School #

Learn UX/UI design flatironschool.com/fragmented in 24 weeks and discover our global community on campus or online and go back to school with Flatiron School! flatironschool.com/fragmented!

Change careers with confidence with 1:1 support from our dedicated Career Coaches and a money-back guarantee. Complete details at flatironschool.com/terms.

See you in class!

–

Vettery #

Vettery is an online hiring marketplace that is changing the way people hire and get hired. Make a free profile, name your salary, and connect with hiring managers from top employers today.

Listeners of Fragmented get a $300 bonus if you accept a job through Vettery! Sign up at vettery.com/fragmented

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

180: Code Comments

Mon, 04 Nov 2019 05:00:00 UTC

Download directly

In this episode of Fragmented, Donn talks about when it’s appropriate to comment your code.

Donn then dives into the types of code comments, when you might want to comment vs when you might not want to (depending upon your consumer) and then gets into how he decides to comment his code with a simple two-step process.

Enjoy!

Things Mentioned #

Commenting Code Post

Sponsors #

Bitrise #

Build amazing apps in Java, Kotlin or whatever tech you prefer and use Bitrise to automate your Android integration, build, test and deploy process quickly and easily.

Flatiron School #

Learn UX/UI design flatironschool.com/fragmented in 24 weeks and discover our global community on campus or online and go back to school with Flatiron School! flatironschool.com/fragmented!

Change careers with confidence with 1:1 support from our dedicated Career Coaches and a money-back guarantee. Complete details at flatironschool.com/terms.

See you in class!

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

179: Kaushiks Top Tips For Giving A Technical Talk

Mon, 28 Oct 2019 05:00:00 UTC

Download directly

In this episode of Fragmented, Kaush breaks down how he begins creating and writing technical talks, using a talk he’s about to give at the Mobilization Conference.

Enjoy!

Things Mentioned #

Mobilization conference – KG is about to give a talk at
Post it notes pic1 pic 2 *
My Speakerdeck
San Jose Theme
Nick Butcher – speakerdeck
Cyril Motier – speakerdeck

Sponsors #

Vettery #

Vettery is an online hiring marketplace that is changing the way people hire and get hired. Make a free profile, name your salary, and connect with hiring managers from top employers today.

Listeners of Fragmented get a $300 bonus if you accept a job through Vettery! Sign up at vettery.com/fragmented

Bitrise #

Build amazing apps in Java, Kotlin or whatever tech you prefer and use Bitrise to automate your Android integration, build, test and deploy process quickly and easily.

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

178: Learning New Languages

Mon, 14 Oct 2019 05:00:00 UTC

Download directly

As Android developers we know Java and now Kotlin. But to become even more seasoned developers, learning newer languages can be a level booster.

The list can go on and on, especially if you’ve been in the industry awhile. So, when does it make sense for you to learn a new language?

When should you learn a new language? When does it make sense? How do you do it?

In this episode KG and Donn discuss the merits of learning new languages, what new languages they’ve picked up and how they feel its important for them and their careers as developers.

Build amazing apps in Java, Kotlin or whatever tech you prefer and use Bitrise to automate your Android integration, build, test and deploy process quickly and easily.

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

177: Over-Engineered Code

Mon, 07 Oct 2019 05:00:00 UTC

Download directly

How do you know if some code is over-engineered?

What does that even look like?

How do you know if you’re over-engineering the code that you’re writing?

What if you recently started at a new company, how do you know if the code you’re working with is over-engineered?

In this episode, Kaushik and Donn go back and forth on this topic …

This episode is sponsored by Instabug –

Understand How Your App is Doing with Real-Time Contextual Insights From Your Users

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

176: Kotlin’s !! Operator is a Code Smell

Mon, 30 Sep 2019 05:00:00 UTC

Download directly

Kotlin isn’t a magic bullet that prevents NullPointerExceptions.

Not at all.

What Kotlin does do is force you to think about how you want to handle your nulls. through Kotlin forcing you to think this through, the hope is that you’ll avoid NullPointerExceptions. The only problem is, Kotlin has the !! operator, also known as the “Not Null Assertion Operator”. This operator basically says “Hey Kotlin, trust me, I’m a pro, I know what I’m doing … I KNOW THIS WON’T BE NULL”.

This… is a code smell.

In this episode, Donn walks through why Kotlin’s Not Null Assertion Operator (!!) is a code smell and what you can do to alleviate it.

This episode is sponsored by Bitrise

Build and operate better apps, faster with Bitrise.

Learn more about Bitrise

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

175: Kotlin or Java – Which one should you learn?

Mon, 23 Sep 2019 05:00:00 UTC

Download directly

One question that Kaushik and I get all the time is this …

I’m starting to learn how to build Android apps, which language should I learn? Kotlin or Java?

In this episode Donn answers this question and gives valid points on why both languages are valid options and why you might want to consider one over the other.

He provides caveats to why you might want to use one language over another and some of the trade offs of Java and Kotlin and how they operate together.

If you’re wrestling with this question, this is the show for you …

Build amazing apps in Java, Kotlin or whatever tech you prefer and use Bitrise to automate your Android integration, build, test and deploy process quickly and easily. Sign up for an exquisite pair of Bitrise Branded Socks, here! https://go.bitrise.io/fragmented

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

174: Testing RxJava, Debugging and More

Mon, 02 Sep 2019 05:00:00 UTC

Download directly

Kaushik is back in this weeks podcast. 🎉

Donn and Kaushik talk about testing RxJava streams with a Kotlin extension method and how and when to test various scenarios. Donn talks about his thoughts on the Testing Pyramid and why he thinks it’s incorrect and how you can help shift your thinking in regards to it. They then talk about IDE themes and how the theme can help you with your day to day development and more.

They wrap up with some talk about developing on Macs vs Windows and Linux.

We hope you enjoy …

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

173: What Pattern Should I Use – MVP, MVVM, MVI …?

Mon, 26 Aug 2019 05:00:00 UTC

Download directly

This week Donn talks about what pattern you should use when developing your application. Is it MVP? MVVM? Mabye MVI? Perhaps it’s something else. Find out in this episode.

We hope you enjoy …

Shownotes #

Patters #

Mocking Out the API in Espresso #

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

172: Coil Image Loading Library with Colin White

Mon, 12 Aug 2019 05:00:00 UTC

Download directly

In this episode Donn and Kaushik sit down with Instacart Engineer Colin White to discuss a new image library he has created called Coil.

Coil is a Kotlin-first image library that focuses on ease of use, simplicity and extensibility. In this episode we ask him the question you’re probably wondering … “Why create an image library, isn’t this a solved problem already?” and then move onto the details of how the library works, and what it offers developers.

From Donn’s perspective – It’s an interesting library and gives you what you need with minimal footprint but offers you the extensibility that you’d want in the future. Its a good balance of “just enough” and “I might need this”.

Enjoy

Show Notes #

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

171: Jetpack Compose with Leland Richardson

Mon, 29 Jul 2019 05:00:00 UTC

Download directly

This week Donn and Kaushik talk to Leland Richardson from the Android team at Google about Jetpack Compose.

Jetpack Compose is declarative component-based UI runtime for Android. With compose you can build your UI with functions in Kotlin to easily “compose” what your UI would look like.

We dive deep in this episode. We talk about the background and influence React had on the project, we dive deep into some of the decisions made regarding the library and much much more…

We hope you enjoy …

Shownotes #

Leland’s Contact info: #

Fragmented Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

170: Developer Growth – Public Speaking

Tue, 23 Jul 2019 05:00:00 UTC

Download directly

In this episode, Donn talks about public speaking and how it can help you grow your career.

He dives in by telling a story of his first speaking engagement and how he was riddled with fear, insecurity, doubt and anxiety. He then talks about why speaking can help you grow your career and life leaps and bounds. He wraps up with possible things you can speak about when starting out as well as where you can get your break into the speaking circuit.

Shownotes #

This episode is sponsored by Instabug. Squash bugs 🐞 in less than a minute with Instabug!

Special offer for all listeners, go to instabug.com/fragmented Signup for free, install the SDK, and you will get Instabug’s brand new t-shirt!

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

169: Testing and JUnit 5 with Marcel Schnelle

Mon, 15 Jul 2019 05:00:00 UTC

Download directly

Marcel Schnelle joins Donn in this episode to talk about how to get your application under test and some steps to go from scared to confident in your testing process. The second half of the show they dive in deep to JUnit 5 and its new features.

JUnit 5 is backwards compatible with JUnit 4 and offers a slew of new features and extensibility points which make the framework much more appealing going forward. We’re convinced you’ll enjoy this episode and leave wanting to get your app under test – even more than it already is.

Enjoy.

Shownotes #

Get ahold of Marcel:

Sponsors 🙏 #

sentry.io – Your code is broken. Let’s fix it together – https://sentry.io/for/android/

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

168: Learning Kotlin: Lambda Expressions Part 2

Mon, 08 Jul 2019 05:00:00 UTC

Download directly

In this episode, Donn continues his talks about Kotlin Lambda Expressions. He explains how you can use lambda expressions as function parameters and as return types for functions.

This is a very dense episode – if you get lost look at the code snippets below or view on them on fragmentedpodcast.com

class LogReader {
 fun processFile(file: File, processLine: (String) -&gt; Unit = {}) {
 file.forEachLine {
 println("Number of Chars: ${it.length}")
 processLine(it)
 println("Line Done Processing")
 }
 }

 fun processFileWithHandlers(file: File, logHandler: LogHandler) {
 file.forEachLine {
 println("Start of Processing")
 logHandler.handleLine().forEach { handler -&gt; handler(it) }
 println("Line Done Processing")
 }
 }
}

interface LogHandler {
 fun handleLine(): List&lt;(String) -&gt; Unit&gt;
}


val reader = LogReader()
val textFile = File("/Users/donnfelker/scratch/lorem.txt")

// Process with single lambda
reader.processFile(textFile, { println("First 10 Chars: ${it.substring(0..9)}") })

val logHandler = object : LogHandler {
 override fun handleLine(): List&lt;(String) -&gt; Unit&gt; {
 return listOf&lt;(String) -&gt; Unit&gt;(
 { line -&gt; println("${line.substring(0, 1)}") },
 { line -&gt; println("${line.substring(2, 4)}") },
 { line -&gt; println("${line.substring(5, 10)}") }
 )
 }
}

// Process with multipe handlers via the logHandler
reader.processFileWithHandlers(textFile, logHandler)

Sponsors 🙏 #

sentry.io – Your code is broken. Let’s fix it together – https://sentry.io/for/android/

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

167: Clean Architecture with Joe Birch

Mon, 01 Jul 2019 05:00:00 UTC

Download directly

Donn sits down with Buffer Android Lead, Joe Birch. Joe is a GDE for Android, Google Actions, Flutter and Google Pay. In this episode Donn and Joe talk about Clean Architecture, what it is, and why you might want to use it.

They break down the concept of what Clean Architecture is in a manner that is easy for even a beginner to understand.

Enjoy.

Shownotes #

Caster.IO Course
[Uncle Bob Clean Arch]https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
Buffer Clean Architecture BoilerPlate
Chord Assist Guitar

Get ahold of Joe:

Sponsors 🙏 #

sentry.io – Your code is broken. Let’s fix it together – https://sentry.io/for/android/

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

166: Cross platform development talk with Jesse Wilson

Mon, 24 Jun 2019 05:00:00 UTC

Download directly

Kaushik decides to hit record on a skype call he has with friend of the show Jesse Wilson. They start off by discussing building features across different platforms today. Jesse talks about a clever mechanism of using javascript to change logic on the fly across the Square cash app, that’s worked out pretty well. They then go on to discussing how one can try and converge across platforms in terms of business logic, architecture, naming etc. They then wind it down by discussing the state of Flutter, Kotlin multiplatform and reaching the promised land.

Enjoy.

Shownotes #

Sponsors 🙏 #

Instabug – Instabug is an SDK that completely takes care of your beta testing and user feedback process so you can debug, fix, and improve your app quality faster.

Go to instabug.com/fragmented, signup, install the SDK, and you will get their brand new t-shirt and a 14-day free trial.

Contact #

@jessewilson
@chrismlacy
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

165: Learning Kotlin: Lambda Expressions Part 1

Mon, 17 Jun 2019 05:00:00 UTC

Download directly

In this episode, Donn talks about Kotlin Lambda Expressions. He explains the syntax and how to build a couple of simple lambda expressions with and without type inference and declaration. We wrap up with a small example of passing a small lambda with multiple values to a function. See the show notes below for more info. This is part 1 of a multi-part series on Lambda Expressions in Kotlin.

The basic syntax of a lambda expression:

val myLambda : Type = { argumentList -> codeBody }

The codeBody is the only section that is not optional.

Double lambda expression (doubles an integer) with type inference


val double = { number: Int -> number * 2 }
val result = double(4)
// result = 8 now

Double string multi-line lambda with type inference.


val doubleString = { number: Int ->
 // codebody
 val doubleResult = number * 2
 doubleResult.toString()
 // Kotlin knows this will return a string
}

Type declaration in a lambda


val myLambda: (String, Int) -> String = { str, int ->
 "$str - ${int.toString()}" // "Donn - 32"
}
val result = myLambda("Donn", 32)
// result = "Donn - 32"

Preview of next week … passing a lambda to a function:

fun doWork(name: String, favoriteNumber: Int, someLambda: (String, Int) -> String) { // Do some processing, this is a contrived example
 val repeatedString = "$name$name"
 val result = someLambda(repeatedString, favoriteNumber)
 println(result)
}

// Usage
doWork("Donn", 32) { str, int ->
 val someNewValue = "$str is my parameter and so is $int"
 someNewValue.length.toString() // this is returned
}

// &#8217;37&#8217; is printed via println

// Or use it like this, the lambda code body is what can change, this is where the power is at
doWork("Donn", 32) { name, count ->
 var result = ""
 for (i in 1..count) {
 result += "$name"
 }
 result // this is returned
}

// loops over and concatinates "Donn" until
// the favorite number (aka count) is met.
//
// Output looks like: "DonnDonnDonnDonnDonnDonn..."
// and so on...

164: Learning Kotlin: Sealed Classes

Mon, 10 Jun 2019 05:00:00 UTC

Download directly

In this episode, you’ll learn all about Kotlin Sealed classes. Donn walks you through what they are, how to create them, how to use data classes, objects and regular classes to create a restricted type hierarchy.

Kotlin Sealed Classes

Sponsors 🙏 #

sentry.io – Your code is broken. Let’s fix it together – https://sentry.io/for/android/

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

163: Parallelize Your Espresso Tests with Flank w/ Matt Runo

Mon, 03 Jun 2019 05:00:00 UTC

Download directly

In this episode, Donn talks to Matt Runo about the Flank project. Using Flank you can run your Espresso test suite in parallel on Firebase Test Lab (FTL). This allows you to lower your feedback loop time and increase developer productivity and throughput. You’ll learn all about Flank, how it works and how to get started in this episode.

Sponsors 🙏 #

sentry.io – Your code is broken. Let’s fix it together – https://sentry.io/for/android/

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

162: Catching up on Google IO 2019

Mon, 27 May 2019 05:00:00 UTC

Download directly

What happened at Google IO 2019?

Shownotes #

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

Sponsors 🙏 #

Instabug – Instabug is an SDK that completely takes care of your beta testing and user feedback process so you can debug, fix, and improve your app quality faster. Go to instabug.com/fragmented, signup, install the SDK, and you will get their brand new t-shirt and a 14-day free trial.

161: Machine Learning on Android with ML Kit and TensorFlow with Dan Jarvis

Mon, 20 May 2019 05:00:00 UTC

Download directly

In this show, Donn talks with Dan Jarvis about Machine Learning on Android with ML Kit and Tensor flow.

They dive deep into what ML (Machine Learning) is, what you need to know as a developer and how to apply those things to build ML applications on Android.

They tal about what you can do on Android in regards to ML, model training and running the models on the device. You may be wondering if you should include the model in your app or if it should live on a server, that’s discused as well and the reasons for it.

They wrap up the show with some examples of what you could build and some great resources to get you started.

Enjoy

Shownotes #

Sponsors 🙏 #

sentry.io – Your code is broken. Let’s fix it together – https://sentry.io/for/android/

Contact #

Contact Dan Jarvis on LinkedIn, Medium or GitHub
Donn Felker – @donnfelker (Twitter) and donnfelker (Instagram)
Kaushik Gopal – @kaushikgopal (Twitter) and kaushikgopal (Instagram)
Fragmented on Twitter: @fragmentedcast
Our YouTube channel
Join thousands of other developers on our free chat server. Ask questions, answer questions, be part of the community at our The Fragmented Discord chat

160: Increase App Engagement with Android Q

Mon, 13 May 2019 05:00:00 UTC

Download directly

With the release of Android Q we now have the settings panel and all its glory. This panel, while most likely overlooked as a minor feature, is actually a diamond in the rough.

Why?

Simply because it’s going to lower the abandonment rate of your app and increase the engagement of your app at the same time. Donn talks about this in depth in this episode.

Enjoy.

Shownotes #

Android Q Features

Sponsors 🙏 #

sentry.io – Your code is broken. Let’s fix it together – https://sentry.io/for/android/

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

159: Improve Your App with the Android Material Components (feat. Cameron Ketcham & Connie Shi)

Mon, 06 May 2019 05:00:00 UTC

Download directly

In this show, Donn and Kaushik talk to Cameron Ketcham and Connie Shi from the Android Material Components team at Google.

The Android Material Components are material designed components that you can easily drop into your application with just a few small tweaks. You get a bunch of fully built out material components, from the Android Material team at Google. From Chips, to Cards, to Buttons and much much more … the goal is to enable you to build your application faster when using these components.

Donn and Kaushik talk to Cameraon and Connie about the components and how to use them in this episode.

Enjoy

Shownotes #

Sponsors 🙏 #

sentry.io – Your code is broken. Let’s fix it together – https://sentry.io/for/android/

Contact #

Contact Cameron and Connit at – GitHub Issues, StackOverflow
Donn Felker – @donnfelker (Twitter) and donnfelker (Instagram)
Kaushik Gopal – @kaushikgopal (Twitter) and kaushikgopal (Instagram)
Fragmented on Twitter: @fragmentedcast
Our YouTube channel
Join thousands of other developers on our free chat server. Ask questions, answer questions, be part of the community at our The Fragmented Discord chat

158: Building High Performance Audio on Android

Mon, 29 Apr 2019 05:00:00 UTC

Download directly

In this show, Donn and Kaushik talk to Don Turner about how to build high-performance audio apps on Android.

We dive deep into history of audio on Android, some of the problems that the platform faced. Then look into the tools that we now have to solve those problems so that developers like you can build killer audio apps.

Enjoy.

Shownotes #

Sponsors 🙏 #

sentry.io

Contact #

Don Turner – @donturner
Donn Felker – @donnfelker (Twitter) and donnfelker (Instagram)
Kaushik Gopal – @kaushikgopal (Twitter) and kaushikgopal (Instagram)
Fragmented on Twitter: @fragmentedcast
Our YouTube channel
Join thousands of other developers on our free chat server. Ask questions, answer questions, be part of the community at our The Fragmented Discord chat

157: Effective Java Item# 20 – Prefer interfaces to abstract classes

Mon, 01 Apr 2019 05:00:00 UTC

Download directly

In this episode, Donn talks about Item #20 in the Effective Java book (third series) by Joshua Bloch. He discusses why you should think about using interfaces over abstract classes, how they can add mixin like behavior to retrofit existing classes with new behavior, default methods, skeleton implementations and more.

Enjoy.

Sponsors 🙏 #

sentry.io – Your code is broken. Let’s fix it together – https://sentry.io/for/android/

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

Fragmented Podcast Update – TSHIRTS 🐤

Mon, 25 Mar 2019 12:20:58 UTC

We’re extremely excited to announce a brand new T-shirt sale from Fragmented.

Our last run with the Spacedroid was so successful with listeners that we decided to work again with our good friend Taylor Ling for this brand new design.

Taylor’s DroidTee designs have gained legendary fame amongst Android devs and this time he’s made something extra special just for us:

The pragmatic programmers will astutely observe why this design is so close to our hearts. We’re big fans of the Rubber duck approach to debugging and we hope you’ll proudly wear these as you champion on with your development.

The campaign closes April 7th, so please place your order before then. We hope you love the t-shirt as much as we do.

Purchase the t-shirt here!

156: Increase App Engagement with Android Q

Mon, 18 Mar 2019 05:00:00 UTC

Download directly

With the release of Android Q we now have the settings panel and all its glory. This panel, while most likely overlooked as a minor feature, is actually a diamond in the rough.

Why?

Simply because it’s going to lower the abandonment rate of your app and increase the engagement of your app at the same time. Donn talks about this in depth in this episode.

Enjoy.

Shownotes #

Android Q Features

Sponsors 🙏 #

sentry.io – Your code is broken. Let’s fix it together – https://sentry.io/for/android/

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

155: Naming conventions for RxJava Observables

Mon, 11 Mar 2019 05:00:00 UTC

Download directly

The Android community has come to use Rx pretty heavily but surprisingly there hasn’t been any one convention that’s won, when it comes to how we name our functions that return Observables. getUser(), user(), userUpdates() ? In this mini-episode dutifully does the yak-shaving for you and discusses what some options are and what the community has been gravitating towards.

Enjoy.

Shownotes #

yak-shaving

Upday’s convention: #

Options #

 // option 1
 fun getUser(): Single<User>
 // yuck

 // option 2
 fun user(): Observable<User>
 // but what does this mean?

 // option 3
 fun user(): Single<User>
 fun userUpdates(): Observable<User>
 // or
 fun userStream(): Observable<User>
 // this is looking good

 // option 4 (upday style)
 fun userOnce(): Single<User>
 fun userStream(): Observable<User>
 fun userOnceAndStream(): Observable<User>

Stay tuned for a future episode, where we discuss more details and more complicated cases to handle (like emitting a list of user, policies for fetching the first user as quickly as possible etc.).

Also #FinishNotation.

Sponsors 🙏 #

sentry.io – Your code is broken. Let’s fix it together – https://sentry.io/for/android/

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

154: Developer Growth: Start Writing

Tue, 05 Mar 2019 05:00:00 UTC

Download directly

Growing as a developer is important for you, your career and your future. One of the best ways to grow your career is to start writing.

Donn recommends starting a blog or contributing to a blog. The process of writing will expose your weak points in your comprehension of a topic. Refining your communication skills through writing and putting thoughts out into the universe via a blog will broaden your skills as a developer.

Ultimately, writing is about communication and communication is the cornerstone of success in much of anything. In this episode, Donn walks you through why you should start writing to help you grow as a developer.

Enjoy.

Sponsors 🙏 #

sentry.io – Your code is broken. Let’s fix it together – https://sentry.io/for/android/
Instabug -They’re giving a special offer for all listeners, go to instabug.com/fragmented, signup, install the SDK, and you will get a free Instabug t-shirt and a 14-day free trial.

Contact #

Discord chat or @fragmentedcast or [our Youtube channel][10]
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

153: How to be an indie Android developer with Chris Lacy

Tue, 19 Feb 2019 05:00:00 UTC

Download directly

Listen to all star Indie developer and friend of the show Chris Lacy. Chris Lacy created the beloved Action Launcher – arguably one of the best Launcher apps on Android. In this epiisode, he talks to us about what it’s like being an indie developer, starting on Action Launcher and of course his newest creation – ActionDash.

Enjoy.

Shownotes #

ActionDash #

Sponsors 🙏 #

Contact #

@chrismlacy or work with him or leave a 5 star reviews on ActionDash :)
Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

152: Should I Rewrite My App? with Jeroen Mols

Mon, 11 Feb 2019 05:00:00 UTC

Download directly

After you’ve been working on an app for sometime, the most common quandry one runs into is the need to rewrite the app. We’ve all been there, there’s technical debt, we’ve improved our understanding, the tools have become better, we’ve become better. So should you go back and just rewrite the whole app? Jeroen walks us through his thinking.

Shownotes #

The big Rewrite – Jeroen’s talk
- Droidcon Italy
- Slides for the talk with notes
Philips Hue
Philips Hue API

Resources #

Sponsors 🙏 #

sentry.io

Contact #

@molsjeroen or his blog or his speakerdeck
Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

151: Evolving Android architectures (Part 2)

Mon, 04 Feb 2019 05:00:48 UTC

Download directly

In this episode, we continue our discussion from episode 148 on evolving android architectures. We collected some of the questions from the community and try to answer them.

Shownotes #

Sponsors 🙏 #

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

150: Learning Kotlin – Returns, Jumps & Labels

Mon, 21 Jan 2019 14:50:27 UTC

Download directly

Another Learning Kotlin episode. We talk about Returns, Jumps & Labels!

Shownotes #

Kotlin Returns and Jumps Documentation

Code #

data class Customer(val isPlatinum: Boolean)

fun main() {

 val customer = Customer(false)

 println("Number of points customer has: ${calculatePoints(customer)}")

 // Break out of the loop once we're over 25
 for (i in 1..100) {
 if (i > 25) {
 break
 } else {
 println(i)
 }
 }


 // Skip all even numbers
 for (i in 1..100) {
 if (i % 2 == 0) {
 continue
 } else {
 println(i)
 }
 }


 // Break out of the outer loop (which breaks out of the inner too) using a label
 donn@ for (i in 1..100) {
 for (j in 100..200) {
 if (j > 150) break@donn // This will break out of the inner loop and outer loop
 else println("i: $i, j: $j")
 }
 }

 // Continue processing the next outer loop value when a condition is met.
 donn@ for (i in 1..100) {
 for (j in 100..200) {
 if (j > 150) continue@donn // This will break out of the inner loop and outer loop
 else println("i: $i, j: $j")
 }
 }

 // returns with label
 example1()
 example2()

 println("I'm done processing!")
}

fun calculatePoints(customer: Customer): Int {
 if (customer.isPlatinum) {
 return 100000
 } else {
 return 10
 }
}


fun example1() {
 listOf(1, 2, 3, 4, 5, 6, 7, 8, 9).forEach {
 if (it > 7) {
 return
 } else {
 println(it)
 }
 }
 println("This wont print :( because return exited the bar() function")
}

fun example2() {
 listOf(1, 2, 3, 4, 5, 6, 7, 8, 9).forEach bin@ {
 if (it > 7) {
 return@bin
 } else {
 println(it)
 }
 }
 println("This will print! :) return exited the forEach!")
}

Sponsors 🙏 #

Nevercode
- Nevercode is taking Flutter revolution extremely serious and is prepared to offer kick-ass CI/CD for Flutter projects with codemagic.io. Check it out and get started at https://codemagic.io/
Sentry.io
- Sentry tells you about errors in your code before your customers have a chance to encounter them. Check them out at: https://sentry.io/for/android/

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

149: Learning Kotlin: inline classes and Type driven design

Tue, 15 Jan 2019 18:57:06 UTC

Download directly

In this quick fragment, Kaushik talks about the new Kotlin 1.3 experimental feature “inline classes” and how it helps with Type driven design.

Shownotes #

Type driven design resources #

Kotlin KEEP #

vs typealias #

Sponsors 🙏 #

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

148: Evolving Android architectures (Part 1)

Mon, 07 Jan 2019 16:28:33 UTC

Download directly

In this episode, Donn and Kaushik talk about the state of android architectures and how they’ve stared to evolve. Kaushik recently worked on a project of coming up with an evolved version of an MVVM architecture, very similar to what the Android community now calls MVI.

Special request: if you have follow up questions or clarifications or things you’d like to see specifically with respect to this dicussion, hit us up on the Discord #fragmented-podcast channel with your thoughts and we’ll make sure to address them in future parts!

Shownotes #

Salient features of the pattern: #

I. Screens are driven by a single ViewModel

II. Screens listen to a single Observable exposed from the ViewModel

III. Events are sent into the VM through a single function processInputs

IV. Break(ing) the Chain VI. Testing strategy

Inspiration #

Sponsors 🙏 #

Contact #

Discord chat or @fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

147: Disposing RxJava 2 Streams with AutoDispose

Mon, 31 Dec 2018 11:06:46 UTC

Download directly

In this short fragment episode, Donn explains how you can clean up your RxJava 2 streams and ensure no memory leaks are occurring by using the AutoDispose library from Uber.

Shownotes #

Code Samples #

Java

myObservable
.map(...)
.as(AutoDispose.<SomeType>autoDisposable(AndroidLifecycleScopeProvider.from(this)))
.subscribe(...)

Kotlin

myObservable
.map(...)
.autoDisposable(AndroidLifcycleScopeProvider.from(this))
.subscribe(...)

With Scope Event Provided

myObservable
.map(...)
.autoDisposable(AndroidLifcycleScopeProvider.from(this, Lifecycle.Event.ON_DESTROY))
.subscribe(...)

Testing

// File: CustomerService.kt
class CustomerService @Inject constructor(...) {
lateinit var scopeProvider: ScopeProvider
}
// Usage in Fragment/Activity/etc
val service = CustomerService(...).apply {
scopeProvider = AndroidLifecycleScopeProvider.from(this)
}
// Usage in Test
val service = CustomerService(...).apply {
scopeProvider = TestScopeProvider.create()
}

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)
Fragmented Chat

146: 3 Things Every Android Developer Needs to Know

Mon, 24 Dec 2018 16:08:21 UTC

Download directly

In this episode of Fragmented, Donn digs into three things that every Android developer needs to know.

Dependency Injection
```
1. Constructor\_setter\_method injection
2. Service Locators or other DI frameworks
3. Common Frameworks
1. [Dagger](https://google.github.io/dagger/android.html)
2. [Koin](https://github.com/InsertKoinIO/koin)
3. [Kodein](https://github.com/Kodein-Framework/Kodein-DI)
4. [ToothPick](https://github.com/stephanenicolas/toothpick)
```
- How to test
  1. Functional / System
  2. Integration
  3. Unit
  4. Tools:
    1. jUnit
    2. Espresso
    3. Spek
- Keep it simple simple
  1. KISS principle KISS principle – Wikipedia
  2. Examples
    1. Code Duplication
      1. “Extract this into a method”
    2. Lets create a framework for this
    3. Kaushik’s – 3x rule
      - if something is duplicated 3 or more times, think about extracting it
    4. 3/6 Rule – In 6 months, will I be able to understand this in under 3 minutes?

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

145: Tracking Network Requests With x-Request-ID

Tue, 18 Dec 2018 18:07:18 UTC

Download directly

In this short fragment, Kaushik explains how you can trace network requests from your app by adding a special header. Easily trace an HTTP request all the way from a client to your backend web process.

Shownotes #

Sponsors 🙏 #

codemagic.io by NeverCode
- Join their Flutter Community here

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

144: Developer Productivity Tools

Mon, 10 Dec 2018 05:00:25 UTC

Download directly

In this episode, Donn and Kaushik talk about productivity tools for developers. As developers, what are some additional tools and utilities that really up your game. If you wanted to see how they tweak their development environments and workstations in general, this is a good episode to listen. Also introducing a Fragmented Discord Chat server!

Shownotes #

Fragmented Discord Chat Server

Productivity tools #

Keyboard Maestro #

Keyboard Maestro – Mac (Referral code with 20% discount)
Sample macros:
- Demo: Better auto pairing with BBEdit and Keyboard Maestro
- Demo: Autocopy text from one program to another
AutoHotkey – Windows (Windows equivalent of sorts)
DuckDuckGo
- Bang Syntax
Muzzle App
Window management tools:
- Divvy
- Spectacle
- Magnet
- Moom
- Phoenix
VSCode
- Night owl theme
OhMyZsh
- Spaceship prompt
- Auto Suggestions
Fish Shell
Kap – Screen recording tools
Sip – Color Management

Sponsors 🙏 #

codemagic.io by NeverCode
- Join their Flutter Community here

Contact #

@fragmentedcast or our Youtube channel
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

Fragmented Discord Chat Server

Wed, 05 Dec 2018 11:18:21 UTC

Kaushik and I are excited to announce that we’ve created a public Discord server that you can join, for free to chat with other folks in the community.

We wanted to create a place where listeners could get together, ask questions, communicate and help each other. The goal of our podcast has always been to share knowledge and we feel that this is only a natural extension of our original vision.

Join Here #

You can join the discord group by installing the Discord app and joining the server via the link below.

Install App: Mac, Windows, Linux, Android, iOS
Invite link: https://discord.gg/zBSfhwk

Why didn’t you use Slack? #

This is a great question, and one that we grappled with for a bit. Ultimately it came down to the fact that Slack has a 10,000 message limit on the free plan. This severely limits the usefulness of Slack (in our opinions). Without message history its a limited chat. With history, it provides a rich history of searchable content for the community.

Therefore we decided to go with Discord. It is free to use and has unlimited message history that can be searched.

Why didn’t you use Telegram? Discord is mainly for gamers … #

Discord allows us to have various channels/rooms where discussions can be broken out into. We have rooms for design, testing, architecture, etc. Using Telegram, this would not be possible.

While Discord is very popular for gamers, it is used widely in various other industries as well.

Code of Conduct #

We do our best to model ourselves as responsible stewards of the community and in doing such we have established a code of conduct that all members of the discord server must abide by. Read it here.

As always, please let us know if you have any comments, questions, etc.

-✌️ Donn & Kaushik

143: Real world testing thoughts

Mon, 03 Dec 2018 15:51:58 UTC

Download directly

In this mini fragment, Donn and Kaushik share some thoughts on real world testing with Android development – a favorite topic of theirs.

Kaushik recently ran into a case where an espresso test fails because the UI stops performing. It’s an interesting discussion on figuring out what matters when you write your tests. They dive into strategies and techniques around testing. What makes a good test, what should you be testing?

They then talk about why Hermetic testing is pretty hard on mobile and ideas around a simple solution that could be provided out of the box. They then round it up talking about TDD and it’s role in today’s world.

Hope you enjoy this one!

Shownotes #

Sponsors 🙏 #

American Express Jobs – American Express is hiring Android developers!
NeverCode
- Blog post on developing apps 20% faster

Contact #

@fragmentedcast or our Youtube channel
@jebstuart
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

142: Indie development on Android and iOS with Matt Logan

Mon, 19 Nov 2018 07:00:52 UTC

Download directly

In this episode, we talk to our friend Matt Logan. Matt took some time off and worked on an indie app called Sessions. He built this for both Android and iOS. In this episode we talk to him about his experience building apps on both platforms, techniques, advice and other good stuff.

Shownotes #

Sponsors #

Contact #

@fragmentedcast
@_mattlogan
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

141: Impostor Syndrome

Mon, 12 Nov 2018 07:00:43 UTC

Download directly

In this mini fragment, Donn and KG talk about Impostor syndrome. Most of us developers are plagued by this. Does this feeling ever go away? How do we deal with this? Listen to this short episode to find out more.

Shownotes #

Sponsors #

Contact #

@fragmentedcast
@preusslerberlin
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

140: ProGuard with Jeb Ware

Mon, 05 Nov 2018 07:00:32 UTC

Download directly

We all know of ProGuard, we want to use it and like it. But let’s face it proGuard ain’t pretty. In this episode we have Jeb walk us through the magic of ProGuard.

We talk to Jeb Ware of American Express. Jeb works as an Android developer and has given some great talks on ProGuard. He walks us through what ProGuard is, how it works, advancements with R8 and more.

By the end of this episode, you should have a new found appreciation for proGuard and bravely approach adding proGuard to your projects.

Shownotes #

Contact #

@fragmentedcast or our Youtube channel
@jebstuart
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

139: Static code analysis with Manu Sridharan

Thu, 25 Oct 2018 02:56:32 UTC

Download directly

In this episode, Donn and Kaushik talk to Uber’s Manu Sridharan on static code analysis. Manu’s a badass who did his PhD on the subject! He explains how static code analysis works, how Uber leverages these tools in their app development pipeline and how we can use such tools to build high quality Android apps.

Shownotes #

Note from Manu: #

I found the story I was thinking about: Reed Hastings founded the company that built the Purify tool for debugging memory errors in C programs before founding Netflix. But, that’s actually not a static analysis tool; it does dynamic analysis by adding extra metadata at runtime.

As far as the history of lint goes, from Wikipedia looks like Kaushik’s guess was exactly right as to why it’s called lint. Looks like the name goes back to the late 1970s.

Misc #

Contact #

@fragmentedcast (on Twitter) or our Youtube channel
@rakingleaves
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

138: Decompress – kotlin scripting

Mon, 15 Oct 2018 05:00:12 UTC

Download directly

In this mini fragment, Donn asks KG about a recent hackathon side project that he worked on with Kotlin scripting.

We go into kotlin scripting (using kscript), pros cons, setting it up and more. We’ve added links some interesting resources, so you want to make sure you check out the shownotes for this one, so you too can explore kotlin scripting and see if it’s a fit for you.

Shownotes #

Existing solutions for poll/vote tabulation #

Misc #

kscript by holgerbrandl
blog post on the hackathon vote tabulation script
what the csv output from google forms looks like

github repo for script – with installation instructions

Highly recommended – Talking kotlin episode on kscript

// slick kotlin usage

override fun onCreate(savedInstanceState: Bundle?) = super.onCreate(savedInstanceState).also {
setContentView(R.layout.activity_something)
// ...
}

Sponsors #

American Express Jobs – American Express is hiring Android developers!

Contact #

137: Decompress KISS DRY Testing

Wed, 10 Oct 2018 19:56:36 UTC

Download directly

In this episode, DF and KG decompress. They start off talking about ideas around KISS vs DRY in software engineering. They move on then to talk about a dear topic – functional vs unit testing and then dive into some of the woes of having a testing infrastructure spun up. Also announcing our youtube channel!

Fragmented’s Youtube channel

Sponsors #

American Express Jobs – American Express is hiring Android developers!

Contact #

136: Kotlin Extension Functions

Tue, 25 Sep 2018 22:47:47 UTC

Download directly

In this fragment episode, Donn talks about Kotlin extension functions. He discusses what they are, how to build them, why they’re useful, how to organize them, visibility and how to call them Java and much more.

Show Notes #

import android.view.View

fun View.gone() {
 this.visibility = View.GONE
}

fun View.visible() {
 this.visibility = View.VISIBLE
}

 view.gone()
 view.visible()

Contact #

135: You can’t learn everything

Mon, 17 Sep 2018 05:26:50 UTC

Download directly

Donn’s on a roll again this week and talks to us about his experience having developed Android for a while. In the early days of Android development, as app developers we felt like we had a decent grasp of everything you needed to know to pump out decent apps.

But with the time, and the latest updates, that has become a tricky thing. This is a good problem to have for the ecosystem but it can make it seem very daunting for developers, both new and old.

Donn gives his 2 cents on this subject.

Contact #

134: Get Effective Help with an SSCCE

Mon, 06 Aug 2018 13:14:53 UTC

Download directly

In this episode, Donn talks about how you can get effective help with your coding problems with an SSCCE – a Simple, Self-Contained, Correct (Compilable), Example.

Using an SSCCE provides others with a quick, concise way to examine the problem without extraneous libraries, UI toolkits and various other parts of your application that do not matter to the problem at hand.

Donn breaks down each component of the SSCCE so you can wrap your head around what you need to get help quickly.

Links #

SSCCE.org

Sponsors #

Instabug – Instabug is the simplest yet most comprehensive bug reporting and In-app feedback SDK.

Contact #

133: Dependency Injection and Service Locators in a Kotlin world with Danny Preussler

Mon, 23 Jul 2018 07:20:22 UTC

Download directly

A hotly debated topic at the moment is the use of a library like Dagger for dependency injection in the world of Kotlin. In this episode, we talk to Danny Preussler. Danny’s a pro who’s been around from the Java 1.0 days! He helps trace the history of dependency injection in Java all the way to today, in a Kotlin world where there exists alternatives like Koin and Kodine.

We dive into how some of these use a Service Loader/Locator pattern and the subtle differences with dependency injection. Listen on for an action packed episode.

Show Notes #

Service Locators vs Dependency Injection #

Your application is aware it’s using a Service Locator, but your application should be totally un-aware that it’s using a Dependency Injection Container.

Sponsors #

Bitrise – Bitrise is your mobile continuous integration and delivery for your whole team, with dozens of integrations for your favorite services.

Contact #

@fragmentedcast
@preusslerberlin
@donnfelker and donnfelker (on Instagram)
@kaushikgopal and kaushikgopal (on Instagram)

132: Dealing with Money in programming

Wed, 18 Jul 2018 09:07:37 UTC

Download directly

In this mini fragment Kaushik talks about dealing with the Money object. With money we need decimals, but the obvious solution of using a float or double may not work as advertised. Listen to this episode to find out why and how you can go about dealing with this.

Show Notes #

Problematic snippet 1:

println(1.03-0.42) # prints 0.6100000000000001

Problematic snippet 2:

var x = 0F
(1..100).forEach { i ->
x += 0.01F
}
println(x) # 0.99999934 vs 1

Sponsors #

Bitrise – Bitrise is your mobile continuous integration and delivery for your whole team, with dozens of integrations for your favorite services.

Contact #

131: ARCore with Yulia Kaleda

Mon, 09 Jul 2018 15:21:52 UTC

Download directly

We live in a time of booming AR (and VR). We wanted to talk to someone who’s worked with it and would know a thing or two about the subject. Then we found Yuliya – also known as the walking wizard of ARCore. In this episode, she teaches Kaush and Donn about ARCore, the differences between AR/VR, the fundamental building blocks of ARCore, some of the newer concepts introduced like Sceneform. An action packed episode to say the least. Listen on !

Show Notes #

Resources #

Sponsors #

Bitrise – Bitrise is your mobile continuous integration and delivery for your whole team, with dozens of integrations for your favorite services.

Contact #

130: Sunsetting ReactNative at Airbnb with Gabriel Peal – Part 2

Wed, 04 Jul 2018 05:40:23 UTC

Download directly

In this episode, we resume our conversation with Airbnb’s Gabriel Peal. If you haven’t listened to part 1, you really really should go back and do that. In that episode, we kicked it off by first trying to understand the goals and the story behind why React Native was chosen as the code sharing technology/tool.

After two years, 220 screens, and 120,000 lines of javascript, Gabriel tells us why they’re moving away from React Native.

Show Notes #

Contact #

129: Sunsetting ReactNative at Airbnb with Gabriel Peal – Part 1

Mon, 02 Jul 2018 05:00:27 UTC

Download directly

If you haven’t heard, Airbnb has decided to move away from React Native. Friend of the show Gabriel Peal wrote an in-depth series of blog posts about this. We had so many questions around this that we asked him to come on the show and he graciously accepted to answer some of our questions.

It’s always a pleasure listening to his insights and this episode is no exception!

Listen on:

Show Notes #

Sponsors #

Bitrise – Bitrise is your mobile continuous integration and delivery for your whole team, with dozens of integrations for your favorite services.

Contact #

128: gRPC on Android with Sam Bobra

Mon, 25 Jun 2018 14:18:27 UTC

Download directly

In today’s episode, we are joined by Sam Bobra – engineering manager @VSCO, android fangirl and gRPC magician (some would even say evangelist !) to talk about gRPC on Android. Super informative episode!

Show Notes #

Implementation #

Misc #

codegen grpc-Java
codegen grpc-Lite
codegen Wire
Curling: grpcurl
envoy

Sponsors #

Contact #

127: Audio playback on Android with Caren Chang

Wed, 13 Jun 2018 14:56:35 UTC

Download directly

In today’s episode, we sit down with Caren Chang from June to talk about audio engineering for Android. Audio APIs can be tricky so Caren walks us through how she maneuvered around them to get the notifications and audio feedback for June’s ovens.

Show Notes #

Apis #

Resources #

Sponsors #

Microsoft AppCenter – Sign up now on appcenter.ms and spend less time managing your app lifecycle and more time coding.

Contact #

126: GraphQL and Apollo with GDE Mike Nakhimovich (Part 2)

Mon, 04 Jun 2018 05:58:29 UTC

Download directly

In this episode, we continue with Part 2 of this GraphQL series. If you haven’t listed to episode 125 already, it might make sense to first listen to that one cause we go into the basics of GraphQL.

In this episode, we dive into the specifics of Apollo and how Mike went about creating a GraphQL client for Android. Let’s get on with Part 2.

Show Notes #

Apollo #

Apollo Android – GraphQL Client for Android

Resources #

droidcon NYC 2017 – GraphQL on Android is here!

Sponsors #

Microsoft AppCenter – Sign up now on appcenter.ms and spend less time managing your app lifecycle and more time coding.

Contact #

125: GraphQL and Apollo with GDE Mike Nakhimovich (Part 1)

Mon, 28 May 2018 05:00:51 UTC

Download directly

In this episode, we talk about GraphQL. Friend and GDE Mike Nakhimovich helped create the library Apollo for Android, which is the defacto official GraphQL client for Android.

In this first part of two, we take a step back and first try to understand what GraphQL is, why one would use it, how Mike set out to create and contribute Apollo for Android and his journey and satisfaction with open sourcing it when he worked at the New York Times.

If you’ve ever been interested in GraphQL, this is a good show to get you up to speed.

Show notes #

GraphQL

Sample GraphQL servers #

Resources #

Sponsors #

Microsoft AppCenter – Sign up now on appcenter.ms and spend less time managing your app lifecycle and more time coding.

Contact #

124: IO 2018 first impressions with Android Dialogs & Pocket Casts team

Mon, 14 May 2018 05:00:28 UTC

Download directly

In this episode of Fragmented, Kaushik talks to Chiuki & Huyen from Android Dialogs and Russell & Philip from Pocket Casts. Fresh after IO we huddled in a room to talk about our first impressions and what we thought were some of the highlights for us Android developers. Hope you enjoy the show! (if you want to see a behind the scenes crossover special, make sure to subscribe to Android Dialogs!)

Show Notes #

Android Dialogs #

Pocket Casts #

Russell Ivanovic @rustyshelf
Phil of PocketCasts @geekygecko
Pocket Casts
Wall Street Journal – Public Radio organizations buy Pocket Casts

io2018 stuff #

Sponsors #

Microsoft AppCenter – Sign up now on appcenter.ms and spend less time managing your app lifecycle and more time coding.

Contact #

123: Android Micro Frustrations

Mon, 07 May 2018 05:00:29 UTC

Download directly

With good –most of the time– also comes the bad. In this episode, Kaushik and Donn chat about the small annoying things about being an Android developer, or more aptly – “Micro Frustrations”.

We usually cover the new, latest, greatest and awesome developments. But it helps to step back and also point out the things that are broken and the 1000 cuts so to speak.

Sit back and enjoy this hearty rant!

Shownotes #

F**k you Android

layout complaints #

Kotlin Android Extensions
Anko layouts (slightly different from Kotlin Android extensions)
Android Studio 3.1 Stable – Build successful but can’t resolve error

How do I ge the height and width of the android navigation bar

If you’re looking for a solution to just hide system bar (and not the navigation bar), here’s what Kaushik landed up using (you’re welcome):

fun Window.makeStatusBarTransparent(activity: Activity) {
 sdkUpto(20) {
 setWindowFlag(activity, WindowManager.LayoutParams.FLAG_TRANSLUCENT_STATUS, true)
 }
 decorView.systemUiVisibility = View.SYSTEM_UI_FLAG_LAYOUT_STABLE or View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN
 sdk(21) {
 setWindowFlag(activity, WindowManager.LayoutParams.FLAG_TRANSLUCENT_STATUS, false)
 setTranslucentStatusBarLollipop()
 }
}

private fun setWindowFlag(activity: Activity, bits: Int, on: Boolean) {
 val win = activity.window
 val winParams = win.attributes
 if (on) {
 winParams.flags = winParams.flags or bits
 } else {
 winParams.flags = winParams.flags and bits.inv()
 }
 win.attributes = winParams
}

@TargetApi(Build.VERSION_CODES.LOLLIPOP)
private fun Window.setTranslucentStatusBarLollipop() {
 statusBarColor = Color.TRANSPARENT
}

Sponsors #

Microsoft AppCenter – Sign up now on appcenter.ms and spend less time managing your app lifecycle and more time coding.

Contact #

122: Learning Kotlin – typealias

Mon, 23 Apr 2018 05:00:42 UTC

Download directly

In this episode of learning kotlin, we look at the typealias keyword. The typealias keyword allows you to provide alternate names for existing types and and function types. Learn how, why and when you can use it in this episode

Show Notes #

Kotlin Inline functions

Sponsors #

Microsoft AppCenter – Sign up now on appcenter.ms and spend less time managing your app lifecycle and more time coding.

Contact #

121: Functional Programming with Kotlin Arrow team – II

Mon, 16 Apr 2018 05:00:28 UTC

Download directly

In this episode of Fragmented, we wrap up another 2 part series. We dive into the details of the Arrow library with this one. Arrow is a library in Kotlin that helps bring many of the functional paradigms of programming to your daily development. We talk to the team about how it all started, the history of the library, why we even need arrow, how Arrow is structured, some of the pitfalls, and in the end some resources on getting us started with Arrow.

Show Notes #

Arrow library #

Misc #

Get help on Arrrow #

Sponsors #

Microsoft AppCenter – Sign up now on appcenter.ms and spend less time managing your app lifecycle and more time coding.

Contact #

120: Functional Programming with Kotlin Arrow team

Mon, 09 Apr 2018 05:00:59 UTC

Download directly

In this episode of Fragmented, we kick off another 2 part series. This time it’s with the Kotlin Arrow team! In the first part, we talk to Jorge, Raul and Paco about Functional programming in general, some core FP concepts, do we already use functional programming today, what are pure functions, do I need to know complicated math to do FP, Immutability, Referential transparency and so much more. These are all pretty daunting words, but the Arrow team break it down and make it really simple for us to understand.

Listen on to the show.

Show Notes #

Kotlin Arrow team #

Misc #

Sponsors #

Microsoft AppCenter – Sign up now on appcenter.ms and spend less time managing your app lifecycle and more time coding.

Contact #

119: Flutter with GDE Eugenio Marletti – Part 2

Mon, 02 Apr 2018 06:47:58 UTC

Download directly

In part 2 of this series,

To help us understand Flutter in-depth we talk to Flutter’s GDE Eugenio Marletti. In Part 1 of this 2 part series, Eugenio helps us understand what flutter is, why it was created, how it works, some really cool features with Flutter and why an AndroidDev today should really give Flutter a good look.

We got so carried away in conversation, that we were forced to break this episode into two parts. If you missed part 1 but want to go back and listen you’ll find it here: 118: Flutter and cross-platform development with GDE Eugenio Marletti – Part 1)

Show Notes #

Sponsors #

Microsoft AppCenter – Sign up now on appcenter.ms and spend less time managing your app lifecycle and more time coding.

Contact #

118: Flutter and cross platform development with GDE Eugenio Marletti – Part 1

Mon, 19 Mar 2018 07:00:50 UTC

Download directly

In this episode, we dive into one of our most requested topics and highly anticipated ones – Flutter.

To help us understand Flutter in-depth, we talk to Flutter’s GDE Eugenio Marletti. In Part 1 of this 2 part series, Eugenio helps us understand what flutter is, why it was created, how it works, some really cool features with Flutter and why an AndroidDev today should really give Flutter a good look.

We got so carried away in conversation, that we were forced to break this episode into two parts. Stay tuned for Part 2.

Show Notes #

Sponsors #

Microsoft AppCenter – Sign up now on appcenter.ms and spend less time managing your app lifecycle and more time coding.

Contact #

117: Multi-Module Builds in Gradle

Mon, 12 Mar 2018 05:00:57 UTC

Download directly

In this episode, Donn and Kaushik sit down to talk about multi-module builds with Gradle. They talk about how you can separate your build into multiple different modules and how you might go about implementing it. They discuss build performance with incremental compilation, isolation of features, code ownership and how to handle cross-cutting concerns like persistence and networking.

Show Notes #

Sponsors #

Microsoft AppCenter – Sign up now on appcenter.ms and spend less time managing your app lifecycle and more time coding.

Contact #

116: Learning Kotlin – inline, noinline and crossinline

Mon, 05 Mar 2018 08:18:22 UTC

Download directly

In this episode of learning kotlin, we look at 3 important keywords – inline, noinline and crossinline. The inline keyword is super common and you’ve probably run across this one at some point. What does it mean and when is it useful? We also look at the related but seldom used variants noinline and crossinline.

Show Notes #

Kotlin Inline functions

Code Snippets: #

Simple inlined function: #

 fun main(args: Array<String>) {
 functionA()
 }

 inline fun functionA() {
 println("awesomeness !")
 }

Warning: Expected performance impact of inlining ‘public inline fun functionA() can be insignificant. Inlining works best for functions with lambda parameters

What the code looks like in Java:

 public static final void main(String[] args) {
 String var1 = "awesomeness !";
 System.out.println(var1);
 }

Function with lambda parameter: #

 fun main(args: Array<String>) {
 functionA({
 println("double awesomeness")
 })
 }

 inline fun functionA(lambda: () -> Unit) {
 println("awesomeness !")
 lambda.invoke()
 }

What the code looks like in Java (without inline):

 public static final void main(String[] args) {
 functionA(new Function() {
 println("double awesomeness")
 });
 }

 public static final void functionA(Function0 lambda) {
 String var1 = "awesomeness !";
 System.out.println(var1);
 lambda.invoke();
 }

What the code looks like in Java (with inline):

 public static final void main(String[] args) {
 String var1 = "awesomeness !";
 System.out.println(var1);
 String var2 = "double awesomeness";
 System.out.println(var2);
 }

Function0:

 public interface Function0<out R> : Function<R> {
 /** Invokes the function. */
 public operator fun invoke(): R
 }

Misc: #

Sponsors #

Microsoft AppCenter – Sign up now on appcenter.ms and spend less time managing your app lifecycle and more time coding.

Contact #

115: Architecture Components with Akshay Chordiya

Mon, 26 Feb 2018 07:00:18 UTC

Download directly

In this episode, we talk about the different parts of Android architecture components. We’ve had episodes on Room and the paging library, so in this one, we thought we’ll touch a little on Lifecycle Owners & Observers, ViewModels, and LiveData. Akshay Chordiya helps break it down. Listen on!

Show Notes #

Android Architecture Components

Lifecycle #

ViewModels #

Code snippet for a ViewModelFactory:

class UserVMFactory(
val user: MyUser
) : ViewModelProvider.Factory {
override fun <T : ViewModel?> create(modelClass: Class<T>): T {
return when {
modelClass.isAssignableFrom(UserVM::class.java) ->
UserVM(user) as T
else -> throw IllegalArgumentException("Unknown ViewModel class")
}
}
}

LiveData #

Misc #

Sponsors #

Microsoft AppCenter – Sign up now on appcenter.ms and spend less time managing your app lifecycle and more time coding.

Contact #

114 : All About CI & CD on App Center w/ Patrick Nikoletich

Mon, 19 Feb 2018 05:00:35 UTC

Download directly

In this episode, we talk to Patrick Nikoletich from Microsofts App Center team. We explore the intricacies of the Continuous Integration server system on the App Center platform. From what App Center is, all the way down into the weeds to how to get your app building on App Center in a few short steps. We also get into the nitty-gritty details around how you can customize your build with build hooks, install utilities and binaries, work with a command line interface, shell scripts, the App Center API much much more. This episode shows a new side of Microsoft that we have not seen in a long time and it’s a breath of fresh air.

Show Notes #

VSTS: https://www.visualstudio.com/team-services/
Microsoft on GitHub: https://github.com/Microsoft
The App Center CLI: https://github.com/Microsoft/appcenter-cli
Azure function that automatically creates branch configurations for PR’s and communicates status back to Github.: https://github.com/pniko/function-appcenter-build-
App Center API: https://docs.microsoft.com/en-us/appcenter/api-docs/ & https://openapi.appcenter.ms/
Detox fo React Native Native: https://github.com/wix/detox
Azure Server Functions: https://azure.microsoft.com/en-us/services/functions/

Sponsors #

Mapbox – Android developers don’t have to settle for a default same-map-no-matter-what option in their Android app. Mapbox offers complete map design control, allowing you to create beautiful custom maps to meet the needs of your Android users.

Contact #

113: Chatting with Pinterest’s Christina Lee

Mon, 12 Feb 2018 15:45:54 UTC

Download directly

In this episode we catch up with a highly energetic but sick Christina Lee about the delightful details in the Pinterest app, delving with the dark side (Swift), giving live coding presentation talks and touching on some Kotlin details like covariance and contravariance. Listen on for a power-packed 40 minutes.

Show Notes #

Google IO episode (#84) for Christina’s running story
Pinterest app
Calligraphy by Chris Jenkins
Android 8.0 Custom fonts
Material design guidelines
Brio design system by Pinterest’s Lin Wang and Thorben Primke
Pinterest stars you should follow on Twitter -> Mallika & Alice
Christina’s code from Kotlintown talk
Christina & Huyen presentation from KotlinConf

Sponsors #

Mapbox – Android developers don’t have to settle for a default same-map-no-matter-what option in their Android app. Mapbox offers complete map design control, allowing you to create beautiful custom maps to meet the needs of your Android users.

Show Notes #

Google IO episode (#84) for Christina’s running story
Pinterest app
Calligraphy by Chris Jenkins
Android 8.0 Custom fonts
Material design guidelines
Brio design system by Pinterest’s Lin Wang and Thorben Primke
Pinterest stars you should follow on Twitter -> Mallika & Alice
Christina’s code from Kotlintown talk
Christina & Huyen presentation from KotlinConf

Sponsors #

Mapbox – Android developers don’t have to settle for a default same-map-no-matter-what option in their Android app. Mapbox offers complete map design control, allowing you to create beautiful custom maps to meet the needs of your Android users.

Contact #

112: Effective Java v3 – Item #9 – Prefer try with resources to try finally

Thu, 08 Feb 2018 05:30:11 UTC

Download directly

In this mini-fragment episode, Donn talks about Item #9 of the Effective Java (Third Edition) book – Prefer try with resources to try finally.

Please note, this episode references the third edition of the Effective Java book that recently came out. Previously we were doing the entire series on version 2, but we are now upgrading to version 3 of the book. We will not be re-doing any of the existing lessons, but if one was inserted in the mix, then we will do that lesson.

Listen on:

Links #

Effective Java (3rd Edition) Book

Sponsors #

Mapbox – Android developers don’t have to settle for a default same-map-no-matter-what option in their Android app. Mapbox offers complete map design control, allowing you to create beautiful custom maps to meet the needs of your Android users.

Check them out today at mapbox.com/android

Contact #

111: Effective Java v3 – Item #5 – Prefer Dependency Injection to Hardwiring Resources

Mon, 29 Jan 2018 05:00:45 UTC

Download directly

In this mini-fragment episode, Donn talks about Item #5 of the Effective Java (Third Edition) book – Prefer Dependency Injection to Hardwiring Resources.

This is the case with Item #5. We did Item #5 previously for v2 of the book, but v3 introduced a new Item 5 (and bumped the previous Item 5 up to 6).

TLDR; Item #5 is new in the third edition of the Effective Java book. So listen closely. :)

Listen on:

Links #

Effective Java (3rd Edition) Book

Sponsors #

Mapbox – Android developers don’t have to settle for a default same-map-no-matter-what option in their Android app. Mapbox offers complete map design control, allowing you to create beautiful custom maps to meet the needs of your Android users.

Check them out today at mapbox.com/android

Contact #

110: BuddyBuild and CI/CD services

Mon, 22 Jan 2018 16:08:38 UTC

Download directly

In this episode of Fragmented, we talk about CI, CD and CD services. That’s Continuous Integration, Continuous Delivery, and Continuous Deployment. BuddyBuild a beloved 3rd party service of ours (and previous sponsor) is sunsetting their Android service, so Donn and KG discuss alternatives and the options they’ve been keeping an eye on.

Listen on:

Show Notes #

Differences between CI/CDs services #

Options for CI Services #

Sponsors #

Mapbox

Contact #

109: Learning Kotlin – Sequences the new Iterables

Tue, 16 Jan 2018 05:00:45 UTC

Download directly

In this episode of Fragmented, we go back to learning some Kotlin and look at the Iterable like data structure introduced called “Sequences”. What is a sequence? How is it different from Iterable? When should I use it?

Show Notes #

Eager/Lazy #

Eager evaluation:

 val lst = listOf(1, 2)
 val lstMapped: List<Int> = lst.map { print("$it "); it * it }
 print("before sum ")
 val sum = lstMapped.sum()

 // prints "1 2 before sum"

Lazy evaluation:

 val seq = sequenceOf(1, 2)
 val seqMapped: Sequence<Int> = seq.map { print("$it "); it * it }
 print("before sum ")
 val sum = seqMapped.sum()

 // prints "before sum 1 2"

Source stackoverflow.com answer

Intermediate and terminal operations #

Notice that at each chain operation, a new temporary list is created:

 data class Person(val name: String, val age: Int)

 fun main(args: Array<String>) {
 val people =
 listOf(Person("Chris Martin", 31),
 Person("Will Champion", 32),
 Person("Jonny Buckland", 33),
 Person("Guy Berryman", 34),
 Person("Mhris Cartin", 30))

 println(people
 .filter { it.age > 30 } // new temp. list
 .map {
 it.name.split(" ").map {it[0]}.joinToString("")
 } // new temp. list
 .map { it.toUpperCase() }) // new temp. list
 }

Using a sequence:

 println(people
 .asSequence() // convert to sequence
 .filter { it.age > 30 } // lazy eval (intermediate op)
 .map {
 it.name.split(" ").map {it[0]}.joinToString("")
 } // lazy eval (intermediate op)
 .map { it.toUpperCase() } // lazy eval (intermediate op)
 .toList() // terminal operation
 )

Without a terminal operation, Sequences won’t print anything:

 val seq = sequenceOf(1, 2, 3)
 println(seq) // prints address
 println(seq.toList()) // [1, 2, 3]

You can’t pick an index from a sequence:

 println(seq[0]) // throws ERROR "No get method providing array access"
 println(seq.toList()[0]) // 1

Sponsors #

Mapbox

Contact #

108: State of React Native for Android with Ryan Salva

Mon, 08 Jan 2018 15:09:01 UTC

Download directly

In this episode Donn talks to React Native magician Ryan Salva. React native and cross-platform development is typically one of our most requested topics so we kick the new year off with React Native. Ryan and Donn dive into the state of React Native today for mobile development, how it’s matured since inception, what kinds of apps are suited to be built with React Native, what kinds aren’t, what are the benefits to using React Native, some tips like pushing updates without having to upload to the play store every time and so much more.

Listen on!

Download directly

Show Notes #

Misc #

Noteworthy quotes from this episode: #

As developers, we are empowered to break things; it’s our god given right!

Javascript is a beautiful disaster

Sponsors #

Mapbox

Contact #

107: Shape shifting SVGs with Alex Lockwood

Mon, 18 Dec 2017 14:00:51 UTC

Download directly

In this episode, we talk to Alex Lockwood who created shapeshifter.design, while at Google. Shape Shifter is an amazing tool that can help developers create Animated Vector Drawables without losing all their hair. Think of shapeshifter as a developer-friendly, open source, After Effects alternative for Android developers.

Alex talks to us about how and why he created Shape Shifter, the different tools that have evolved out of its creation and just getting a good grasp of its working.

Show Notes #

Abt Alex Lockwood #

Shape Shifter #

SVGO #

Shape Shifting & Icon animations #

Sponsors #

Thanks to Buddybuild for sponsoring this episode of Fragmented! Ship apps faster with BuddyBuild 🚀 Give them a try for free at fragmentedpodcast.com/buddybuild.

Contact #

106: The Reactive Workflow Pattern with Ray Ryan

Wed, 13 Dec 2017 21:56:46 UTC

Download directly

In this episode, we sit down and talk to Ray Ryan from Square about the Reactive Workflow pattern that he recently gave a talk on. This pattern goes deep into RootViews, containers, ViewFactories and much much more.

Show Notes #

Ray’s “The Rx Workflow Pattern” talk at Droidcon NYC: droidcon NYC 2017 – The Rx Workflow Pattern – YouTube
Flow Navigation –GitHub – square/flow: Name UI states, navigate between them, remember where you’ve been.
Square Coordinator Library – GitHub – square/coordinators: Simple MVWhatever for Android
Composable State Machine Pattern – A composable pattern for pure state machines with effects (draft v3) · GitHub

Sponsors #

Rollbar – special offer: Bootstrap plan free for 90 days

Contact #

105: Jake Wharton on the Android Kotlin Guides

Mon, 04 Dec 2017 05:00:50 UTC

Download directly

In this episode, we talk to Jake Wharton of Google on a recent Kotlin coding style guide that they released: the Android Kotlin Guides. In this episode, we pick his brains and ask him how he structured the guide, how he partitioned it to fit some of the idiosyncrasies of Kotlin, what some of the challenges were, when coming up with the guide and much more.

Jake’s one of the best out there and it’s always such a pleasure to have him on the show.

Show Notes #

The style guides #

Android Kotlin Guides
official github repo for Android Kotlin guides
Google Java Style Guide
Jetbrains Coding conventions
Jetbrains collection of Kotlin idioms (also very useful)

Building the style guide #

Android Kotlin Guides #

Sponsors #

Rollbar – special offer: Bootstrap plan free for 90 days

Contact #

104: Conversations with GNOME/Mono/Xamarin creator Miguel and VS App Center PM Simina

Mon, 27 Nov 2017 05:00:29 UTC

Download directly

In this episode of Fragmented, Donn makes the pilgrimage to Microsoft Connect 2017. Connect is Microsoft’s annual developer conference where they announce a bunch of new products and services.

Donn got to interview a bunch of folks, and in this episode, we talk to two of them: Miguel De Icaza (leading open source proponent who also helped create Gnome, Mono, Xamarin etc.) and Simina Pasat (Program manager for Microsoft’s very new CI like service AppLink). Both of them were terrific guests and had quite a few gems to share, for us Android devs!

Show notes #

Microsoft Connect

Miguel #

Cross platform development #

Misc #

Simina Pasat #

Contact #

103: MVI pattern with Hannes Mosby Dorfmann

Mon, 13 Nov 2017 05:00:24 UTC

Download directly

In this episode of Fragmented, we talk to Hannes Dorfmann about using the Model View Intent (MVI) pattern for Android. The MVI pattern was sparked through cycle.js (for javascript). Hannes took this pattern and tried to adapt it to Android. This pattern has gained a lot of traction and interest in the Android community.

In this episode, he breaks down the pattern for us. He tells us how to implement it, how it helps with testing, the benefits of the pattern and some of the pitfalls. Recording this episode was riveting for us and we dive into some juicy technical details. Listen on!

Show Notes #

About Hannes #

MV* patterns #

MVI like patterns #

Hannes series on MVI for Android (must read!) :

Misc #

Sponsors #

Contact #

102: All Things Kotlin and notes from KotinConf

Mon, 06 Nov 2017 05:00:36 UTC

Download directly

In this episode of Fragmented, Donn and I decompress. I had the pleasure of attending KotlinConf 2017 – Jetbrain’s very first conference dealing completely just on Kotlin. I have a quick chat after Day 1 with Donn, giving him the juicy updates.

We talk about how the conference was organized, some of the technical talks I attended (our thoughts on these…) and some of the folks I had the opportunity to meet.

Overall it was an amazing time at KotlinConf and if you want to vicariously enjoy it, listen on to the show.

Show Notes #

Pixel 2 #

KotlinConf #

Meeting folks #

Talks at KotlinConf #

Coroutine introduction #

Other interesting stuff #

Kotlin Style Guide – courtesy Jake Wharton
Google Java Style Guide
google-java-format
now for google-kotlin-format
github isse (+1 this :D)
@JvmOverloads overloads generation

Sponsors #

Thanks to Buddybuild for sponsoring this episode of Fragmented! Ship apps faster with BuddyBuild 🚀 Give them a try for free at fragmentedpodcast.com/buddybuild.

Contact #

101: Learning Kotlin – visibility modifiers, internal modifier, modules

Mon, 30 Oct 2017 05:00:34 UTC

Download directly

Another day, another opportunity to learn more Kotlin. In this episode, Kaushik walks through the concept of visibility modifiers. How do the modifiers in Kotlin differ from the ones in Java? What is this new internal modifier? When should I use each of the operators?

Listen on to find out!

Shownotes: #

Excellent resource explaining visibility modifiers in Kotlin

open class Outer {
private val a = 1
protected open val b = 2
internal val c = 3
val d = 4 // public by default
protected class Nested {
public val e: Int = 5
}
}
class Subclass : Outer() {
// a is not visible
// b, c and d are visible
// Nested and e are visible
override val b = 5 // 'b' is protected
}
class Unrelated(o: Outer) {
// o.a, o.b are not visible
// o.c and o.d are visible (same module)
// Outer.Nested is not visible, and Nested::e is not visible either
}

100: Episode 100 Listener questions

Mon, 23 Oct 2017 05:00:35 UTC

Download directly

This is the 100th episode of Fragmented. We do things a little differently for our 100th episode and field a bunch of listener questions that came in. We’re going a little meta and talking about our experience starting Fragmented, our process, how we pick guests and topics, our setups, our favorite Android libraries and classes (?!).

Thank you so much for being a listener. We cannot express how grateful we are to have you.

Shownotes #

Setup #

KG #

Shure Beta 87A
USB Pre 2
LG 34UC87C 34 ultra wide display
Headphones (KG has too many – ping em if you’re curious)

Donn #

Android Resources #

.. and many many more

Favorite class and libs #

Misc #

Sponsors #

Contact #

099: Effective Java – Item #17: Design and Document for Inheritance or Else Prohibit It

Mon, 09 Oct 2017 05:00:03 UTC

Download directly

In this episode, Donn talks about Item #17 from the Effective Java book: Design and Document for inheritance or else prohibit it. Learn how you should be documenting your code that is built for inheritance when you should not call overridable methods and much more.

Show Links #

Fragmented – Effective Java Fragments

Contact #

098 : Droidcon NYC 2017 – Kotlin, React Native, Android Security, Design Patterns and Doppl

Mon, 02 Oct 2017 05:00:27 UTC

Download directly

In this episode, Donn is at Droidcon NYC 2017. He sits down to chat with Dan Kim about Kotlin, Gabriel Peal about React Native, Scott Alexander-Bown about Android Security, Jose Alcérreca about the Android Architecture Blueprints and Kevin Galligan about the history of Droidcon NYC and his new library – Doppl.

2:07 – Dan Kim (Kotlin)
- 10:07 – Gabriel Peal (React Native)
- 23:43 – Scott Alexander-Bown (Android Security)
- 33:32 – Jose Alcérreca (Android Architecture Blueprints)
- 43:09 – Kevin Galligan (Droidcon & Doppl)

Show Links #

Sponsors #

BuddyBuild – fragmentedpodcast.com/buddybuild

Contact #

097 : Android Architecture Paging Library with Florina Muntenescu

Mon, 18 Sep 2017 05:00:34 UTC

Download directly

In this episode, Florina returns to talk to us about Google’s recently announced paging library!

The paging library is a powerful take on implementing paging functionality in general, not necessarily linked to a particular technology or library. Florina breaks down the different components and explains what specific function each of them play.

We start off with DataSources, talk about when one would want to use “Tiled” or “Keyed” data sources, and then talk about making them work with RecyclerViews (which is really what 99% of us eventually want). Florina also explains the role of PagedLists, PagedListAdapters and so much more.

If you ever wanted to get an overarching view of Google’s first take on implementing the paging library, this is a great starting point. Listen on so you can understand, try it out and then give feedback to Google, to participate in the making of this new library.

Show Notes #

Sponsors #

Kobiton – 15-day Free trial with no credit card required 🙌

Contact #

096 : Romain Guy on Displays, CPU’s, GPU’s and Color

Mon, 11 Sep 2017 05:00:50 UTC

Download directly

In this episode, Romain Guy from Google gives us the lowdown on a bunch of Hardware related stuff.

He starts off by explaining how the refresh rates on screens matter, what it would mean to have something like a 120Hz display for Android screens, how things like V-Sync and double buffering work, using different screen technologies, how much work is done by the CPU and GPU and so much more.

This was one of those episodes where we tried so hard to hold back for fear of recording for another 2 more hours. Romain is clearly one of the most knowledgable and interesting engineers to talk to today in the hardware land of Android. What a blast!

Show Notes #

Photography #

Screens, refreshing/rednering Color #

Fragmented 91 – Reddit AMA
Romain on Reddit being spoiled by 120Hz
What is V-Sync (pcworld.com) and Screen tearing (Wikipedia)
Three-two pull down technique (filmaking) (wikipedia)
OLED vs AMOLED (quora.com)
OLED vs LCD (quora.com)
Romain Guy’s 2017 IO Talk on Colors fundamentals YOU OWE IT TO YOURSELF TO WATCH THIS!!

Sponsors #

Kobiton – 15-day Free trial with no credit card required 🙌

Contact #

095 : Room Databases with Florina Muntenescu

Tue, 05 Sep 2017 05:00:49 UTC

Download directly

In this episode, we talk to Florina from Google about the recently released Database library Room. Room was introduced as part of the Android Architecture components and has been picking up a lot of steam in the community.

Room focuses on being a beautiful api layer to Sqlite. Florina explains to us how we can use Room to create a database, creating entities and how they map to tables using DAOs to access data and even “observe” them. Listen on for more of the details!

Show Notes #

Official docs #

Florina’s posts #

Florina’s Medium blog posts

360|AnDev talks #

Micellaneous questions about Room (that we chopped off for lack of time) #

Q: Does Room use reflection? #

A: There’s only 1 reflection call (at the time of finding the database implementation, when you call Room.builder). Most of the other stuff is generated code (with compile time verification!).

Q: Does Room provide compile-time SQL checks #

A: Yes, Room was designed to provide compile-time checks.

Q: Does Room handle SQL injection attacks (security) #

Yes … for all practical purposes. See this post for times when it doesn’t.

Q: Do we have tools to access the sqlite database file directly? #

Nope, at the moment, adb is your friend. Use that to download the file manually from your device.

Sponsors #

Rollbar – special offer: Bootstrap plan free for 90 days

Contact #

094: Design Patternitis – 5 Tips to Help You

Mon, 28 Aug 2017 20:07:45 UTC

Download directly

In this episode of Fragmented, Donn talks about a common problem almost all software engineers face in their career – Design Patternitis.

So, you’ve read the books on design patterns and now you’re applying them everywhere. Just because some code can be put into a pattern doesn’t mean you should. Or should you? How can you apply them when needed? Donn shares 5 tips with you that you can use to help combat Design Patternitis.

Show Notes #

Sponsors #

This episode is made possible by Kobiton – Fragmented.

They’re giving listeners a 15-day FREE trial with no credit card required! 🙌 Give them a try at Kobiton.com/fragmented and let them know we sent you.

Contact #

093 : RxJava intervention with Dan Lew

Mon, 14 Aug 2017 05:00:02 UTC

Download directly

In this episode of Fragmented, our friend and RxJava paragon of the Android – Dan Lew, returns for a record 3 and 1/2 time.

We’ve been using RxJava over the years now and have even talked to Dan about it in previous episodes.

How has our understanding of Rx use in Android changed over the years? We know some of the super standard usecases for RxJava in AndroidDev. But the important question to be asking is: when are the times we “shouldn’t” be using RxJava? Are we over-complicating our code by shoe-horning it in different places. Concepts like functional programming and reactive state management have picked up steam again, how has this influenced our RxJava use?

Show Notes #

Sponsors #

Kobiton – Fragmented

Contact #

092: Learning Kotlin – dealing with static-ness and (companion) objects costs

Mon, 07 Aug 2017 05:00:18 UTC

Download directly

In this second episode of our learning Kotlin series, we talk about Kotlin’s support for static members or … lack thereof. Kotlin as a language was designed so that there’s no such thing as a “static member” in a class but there are times when having static members can be useful.

So what do we do in those cases? do we just avoid static members? are there better alternatives? what are the costs with some of these approaches?

Listen on to find out more!

Show Notes #

Static alternatives #

Cost of approaches #

Look at the end of these notes for code snippets

Misc: #

Sponsors #

Rollbar – special offer: Bootstrap plan free for 90 days

Contact #

Code snippets #

Cost effectiveness #

// ----------------------------------------
// THIS IS BAD
class Foo {
companion object {
val myVar = "testing"
}
}
// calling from Kotlin
Foo.myVar
// calling from Java
Foo.Companion.getMyVar(); // yuck
// ----------------------------------------
// THIS IS OK
// notice the Jvm annotation
class Foo {
companion object {
@JvmField val myVar = "testing"
}
}
// calling from Kotlin
Foo.myVar
// calling from Java
Foo.myVar;
// ----------------------------------------
// THIS IS AWESOME
// notice the const keyword
class Foo {
companion object {
const val myVar = "testing"
}
}
// calling from Kotlin
Foo.myVar
// calling from Java
Foo.myVar;
// compiler additionally inlines this
// myVar is not a primitive or String?
// use @JvmField or @JvmStatic for methods

Package level options #

// inside BottomSheetView.Kt
class BottomSheetView {
companion object {
const val BOTTOM_SHEET_ANIMATION_TIMING = 500L
}
// ...
}
// accessed as:
animation.setTiming(BottomSheetView.BOTTOM_SHEET_ANIMATION_TIMING)
// ----------------------------------------
// INSTEAD DO THIS
// inside BottomSheetView.Kt
const val BOTTOM_SHEET_ANIMATION_TIMING = 500L
class BottomSheetView {
// ...
}
// accessed as:
animation.setTiming(BottomSheetViewKt.BOTTOM_SHEET_ANIMATION_TIMING)

091 : Decompress – Reddit AMA highlights, package by feature not layer and testing!

Mon, 24 Jul 2017 05:00:55 UTC

Download directly

In this decompress episode, DF and KG kick it off with a brief discussion of the highlights from the recent reddit AMA that the Android Engineering folk conducted. What were the interesting things they learnt or were surprised by etc.? They then go on to briefly discuss two topics they’ve always chatted about (off-air) packaging by feature (not layer) and most recent thoughts on testing. Listen on to find out more:

Show Notes #

360 | AnDev #

AMA Reddit #

Package by feature not layer #

Sponsors #

Kobiton – start your 15 day free trial

Contact #

090: Make your apps instant with Zarah Dominguez

Mon, 17 Jul 2017 05:00:38 UTC

Download directly

At I/O ’16 Google announced the super cool new feature Instant Apps. At IO’17 we started to see real world examples and third parties pull off this feature. In this episode, we talk to GDE Zarah Dominguez who’s company “Domain” was one of the partners for this program.

What is the Instant Apps feature? What are some usecases where this comes in handy? How does it actually work internally? What does it take for a developer to implement this feature in their own app? Listen on to find out!

Show Notes #

Sponsors #

Rollbar – special offer: Bootstrap plan free for 90 days

Contact #

089: Learning Kotlin – Properties a first class language feature

Mon, 10 Jul 2017 05:00:36 UTC

Download directly

In this mini Fragment, KG talks about his journey learning Kotlin as a newb. Given that Kotlin is most likely going to be the de-facto language for most developers, it makes sense to deepen our understanding of the language (as we have strived with Java over the years).

“Properties” in Kotlin are a first class language feature. But what does that actually mean? What are the nifty features we get with properties? How are these resolved from a Java class when there’s potential a name clash? What are some other gotchas and learnings from using properties? Listen on to find out:

Shownotes: #

Contact #

088: Offensive programming with Piwai from Square

Mon, 03 Jul 2017 05:00:50 UTC

Download directly

In this episode of Fragmented we talk to our friend Piwai from Square.

Piwai’s a pro at testing and breaking apps (he built LeakCanary – so not terribly unexpected). He teaches us some strategies on debugging app crashes and briefs us on this concept he calls “offensive programming” which has helped him a lot with his Android development.

It’s good stuff and we hope you enjoy the show.

Show Notes #

Defensive programming

Py’s libraries: #

Misc resources: #

Pending touches and UI event: #

Contact #

087: Effective Java – Item #16: Favor Composition over Inheritance

Mon, 19 Jun 2017 13:19:55 UTC

Download directly

In this mini-Fragment episode, Donn talks about Item #16 of the Effective Java series – Favor Composition over Inheritance. You’ll learn why using inheritance is not always a great idea and how you can use composition in place of it to make your code more anti-fragile, resilient and clean.

Show Notes #

Effective Java Book

Contact #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

086: Working Effectively with Legacy Code

Mon, 12 Jun 2017 15:28:49 UTC

Download directly

In this mini-Fragment episode, Donn talks about Working Effectively with Legacy Code. He doesn’t just talk about the book itself, but he talks about how to approach a legacy code base and start delivering value as soon as possible, yet with confidence. If you’ve recently started a new job, moved to a new team, started working on an existing code base, then this episode is bound to help you.

Show Notes #

Working Effectively with Legacy Code Book

Rollbar

Contact #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

085: Casual Kotlin conversation with Dan Kim

Mon, 05 Jun 2017 07:00:05 UTC

Download directly

In this episode, we talk to Dan Kim about Kotlin. Dan is an Android developer at the company Basecamp and has some great Kotlin posts on the company’s famous blog Signal Vs Noise. He was pretty early, on the Kotlin train and has been working with the new language for quite sometime now.

Instead of trying to go into every single detail about Kotlin, the nuances of the language, it’s syntax etc. we take a more general approach and talk about starting out on Kotlin, how does on go about migrating an Android codebase to Kotlin, what are things we should watch out for when using the language. This and a whole lot more!

Show Notes #

Kotlin view (binding) libs #

Resources #

Jake’s youtube video
Dan’s blog posts:
- How we made Basecamp 3’s Android app 100% Kotlin
- Some of my favorite Kotlin features
Android development with Kotlin – Jake Wharton (video)
Introduction to Kotlin – Google I/O 17 (video)

Contact #

084: Kaush and Donn go to Google IO 2017

Mon, 22 May 2017 05:00:17 UTC

Download directly

This was truly one of the most memorable IOs Google has ever conducted. In keeping with tradition, Donn and Kaushik talk with a bunch of awesome #AndroidDev and get their opinions/thoughts on IO and Android in general. As always, these are super fun episodes.

Show Notes #

Dan Kim (Basecamp)
Patryk Poborca (Kozio Digital)
- @patrykpoborca
- Trello app
Jerrell Mardis (Salesforce)
Annyce Davis (Offgrid Electric)
Zac Sweers (Uber)
Matt Kranzler (Salesforce)
- @mattkranzler
- Flamingo app
Roberto Orgiu (Caster)
- @_tiwiz
Christina Lee (Pinterest)
Hugo Visser (Little Robots)
- @botteaap or +HugoVisser
- Android APT
Raveesh Bhalla
- @raveeshbhalla
- Enki app
Etienne Caron (Shopify)
- @kanawish
- Safari Queue app
Chris Jenkins (Owlr)
Brenda Cook (Seesaw)
Joaquim (Twitch)

Previous Google IO Episodes #

Sponsors #

Rollbar – special offer: Bootstrap plan free for 90 days

Contact #

Living Dangerously

What a baller

geared up and ready to 🎤

Find the KG (hint: his Pixel is more prominent in this picture than his face)

How so many Android ❤️s were won

Troll masters as they revel the name of Android O to us

Many stickers were collected

083: Learning the basics of functional programing with Anup Cowkur

Mon, 15 May 2017 01:00:23 UTC

Download directly

RxJava is considered a functional reactive programming library. But the paradigms of functional programming have existed for a very long time. In this episode we talk to Android GDE Anup Cowkur, about his experience experimenting with “pure” functional languages. He breaks down some of the basic concepts, explaining the different terms along the way.

Show Notes #

Functional languages: #

Resources #

Sponsors #

Rollbar – special offer: Bootstrap plan free for 90 days

Contact #

082: Airbnb’s Gabriel tells us how to animate with Lottie

Mon, 08 May 2017 04:30:35 UTC

Download directly

It’s pretty awesome, when you use a third party library, love using it and finally get to talk to the person who actually helped build it. In this episode, we talk to Gabriel Peal. Besides having quite the illustrious career in Android development, Gabriel now works at Airbnb and helped build Lottie – an animation library.

What is Lottie, how do you use Lottie? why is so Lottie so cool? how does it actually work under the hood? Listen to this episode and find out.

Show Notes #

Sponsors #

Rollbar – special offer: Bootstrap plan free for 90 days

Contact #

081: Talking Android Things with Rebecca Franks

Mon, 01 May 2017 07:00:26 UTC

Download directly

It is the world of the Internet of Things (IoT) and Google’s answer to that is the Android Things. In this episode, we talk to the amazing Rebecca Franks. She explains how Android things works and talks of some of the adventures and examples she’s embarked on with Android Things. If you’ve had that hobby Raspberry Pi or Arduino board lying around and not sure how to put it to use, this episode’s for you.

Show Notes #

Sponsors #

Kobiton

Contact #

080: 10 Books Android developers should read

Mon, 17 Apr 2017 05:00:35 UTC

Download directly

In this episode Donn and Kaushik recommend 10 books on Software programming that they think every Android developer would greatly benefit from reading. These are books that helped them become better programmers and have had the most impact in their daily lives as Android developers.

Show Notes #

Honorable mentions #

Contact #

079: How do i get started with VR apps? Etienne Caron explains

Mon, 10 Apr 2017 05:05:29 UTC

Download directly

Have you ever thought about building VR (Virtual Reality) apps? Where do you start? How difficult is it? How similar is to Android development? Do you still code in Java? In this episode, Etienne Caron AndroidDev extraordinaire and expert VR hobbyist gets us up to speed on what you need to know, to start creating VR apps.

Show Notes #

Contact #

078: Ten Testing Strategies with Michael Bailey

Mon, 03 Apr 2017 05:05:14 UTC

Download directly

In this episode, Donn sits down with fellow Android GDE, Michael Bailey to cover 10 testing strategies to help you get your application under test and to make sure your testing environment is top notch. They start off with the basics and then progress further down the testing rabbit hole eventually covering topics like cloud-based testing labs, hermetic testing and much much more. This episode will help provide you with a blueprint of how to get your Android app under test and get you to a level where you can develop your app with confidence.

The Ten Tips #

Use Espresso for functional/integration testing
Mock data and API endpoints to keep tests hermetic
Utilize JUnit JVM Tests and patterns for a fast dev cycle
Utilize a git branching strategy and utilize pull requests (PR’s) for code reviews
Use CI to run the tests and provide constant feedback
Speed up testing and ease of testing with shell helpers and helper classes for testing
Cloud Testing Services
Mutation Testing
Thoughts on code coverage & value based testing
Don’t let flaky tests linger

Show Notes #

Contact #

077: Chatting ADB with Genymotion’s Eyal Lezmy

Mon, 20 Mar 2017 07:00:51 UTC

Download directly

Today on Fragmented, we talk to Eyal Lezmy. Eyal works as an Android developer for Genymotion. While working for Genymotion he had to deal with the Android Debug Bridge a whole bunch, so in this episode we dive into the details of ADB, some super slick commands and in general just get a better understanding of this tool we use every single day.

Show Notes #

Helpful commands #

# input some text from your keyboard
adb shell input text "keyboard text"
# download database file
# see http://stackoverflow.com/questions/18471780/android-adb-retrieve-database-using-run-as
adb exec-out run-as package.name cat databases/file > file
# run-as mentioned in episode
adb shell "run-as package.name chmod 666 /data/data/package.name/databases/file"

Sponsors #

Rollbar – special offer: Bootstrap plan free for 90 days

Contact #

076: Taming the activity lifecycle with Kristin Marsicano

Mon, 13 Mar 2017 09:00:48 UTC

Download directly

In this episode Kaushik talks to Kristin of the Big Nerd Ranch. You would think that the Android lifecycle is pretty standard and basic stuff, but as Kristin begins to unpack the nuances of the Android lifecycle, we learn there’s a world of details that’s easy to miss. Listen on, to get an ironclad grip on the Activity lifecycle.

Show Notes #

Sponsors #

Rollbar – special offer: Bootstrap plan free for 90 days

Contact #

075: Effective Java for Android Developers – Item #15: Minimize Mutability

Mon, 06 Mar 2017 15:39:43 UTC

Download directly

In this mini-Fragment episode, Donn talks about Item #15 of the Effective Java series – Minimize Mutability. You’ll learn what mutable and immutable objects are, how and why immutability is a good thing and how you can implement it.

Show Notes #

Rollbar

Contact #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

074: Ben Oberkfell talks Fingerprint API

Mon, 20 Feb 2017 05:42:17 UTC

Download directly

It’s almost a given these days that most phones will have Fingerprint APIs. But how does the hardware actually work? How does the Software work? How does an Android developer make use of these APIs? Ben Oberkfell breaks it down for us in great detail. Listen on!

Show Notes #

Sponsors #

Rollbar – special offer: Bootstrap plan free for 90 days

Contact #

Transcript #

Donn Felker: Kaushik, I forget: do you have a Nexus 6P or a Pixel?

Kaushik Gopal: I have a Pixel.

DF: Really? Do you like it?

KG: Oh, I love it.

DF: Where’s the fingerprint scanner on that? Is it on the back or the front?

KG: It’s on the back, exactly like the 6P’s.

DF: Do you use it for anything, like unlocking?

KG: I use it for everything. I absolutely love it. It’s one of those technologies where, once you start using it, you can’t live without it. I obviously use it for unlocking my phone. I also use an application called 1Password, which stores all my passwords. Thankfully, after much online harassment, they have implemented fingerprint authentication as well. I even use it at Starbucks through Android Pay. I use it all over the place.

DF: It’s absolutely fantastic. I have a 6P, and it was the same way for me. Now that I’ve started using it, I can’t give it up. I will never again buy a phone that doesn’t have fingerprint support.

That brings up a good point: we have a guest today who should help us dive deeply into this topic.

KG: Absolutely. I think it was at DroidCon NYC where this gentleman gave a talk about Fingerprint ID. We’ve been excited about this interview for a long time, because we’ve been wanting to talk about this. Without further ado, we welcome Ben onto the show.

Ben Oberkfell: Hi! I’m really glad to be here. Thanks for having me on.

DF: Ben, for any folks who aren’t familiar with you (even though you’re pretty active in the community), can you give us a bit of background about yourself and tell us about where you work and how you got into Android?

BO: I live in St. Louis. Until recently, I worked for American Express, where I helped build fingerprint login into their app. Now I work for the New York Times, where I’m building the Android version of the crossword app. In other words, I get paid to do the crosswords, which is really fun!

I got on this journey back in 2010, when the Nexus One came out, and I started goofing around with it. Then this conference called “Google I/O” surfaced on my feed. The registration window was open for 90 days, so I had plenty of time to decide whether I wanted to go or not. It wasn’t a complete free-for-all back then (like it later became). I fell in love with developing on Android through that. I did some side projects here and there while I was working on cancer research, and then wound up going into this full time about four years ago.

DF: That’s cool! Don’t you also work with the Google Developers Group in St. Louis?

BO: Yeah, I’m one of the two co-organizers of the St. Louis GDG.

KG: Is the New York Times crossword app an independent application, or is it part of the New York Times app itself?

BO: It’s a separate app, with a separate subscription—although if you subscribe to the digital news, you’ll get a $20 discount on that. Also, if you want to buy one-off puzzle packs, we have in-app purchases for those. So, if you don’t want to commit to a year, you can buy a set of puzzles to play on the train.

KG: That’s very cool. We’ll add a link to that in the show notes, because I’m a big fan of the New York Times. It’s one of the few newspapers that I try to read regularly.

Ben, Donn and I want to talk about the fingerprint API, because that’s the thing that really excites us, but we want to step back a little. As developers, it makes a lot more sense to us if we understand the hardware as well. Do you think we can start off there? Could you talk about how this whole fingerprint authentication mechanism works at a hardware level, just so we can get a brief understanding before we dive into the actual software, which is typically where we try to do all the magic?

DF: How does the fingerprint hardware on the back of the Nexus 6P, the Pixel, and a bunch of other devices actually work? Do you know?

BO: Some of the scanners that were on some of the older Samsung phones were optical sensors, but today’s sensors are actually capacitative. It’s similar to the sensor your screen uses, but at a much higher resolution. There’s a grid of capacitors, and the grooves, the valleys, and everything else in your fingerprint will affect the current that’s passed through. Reading off that grid basically forms an image—a grid of pixels. That’s how a sensor resolves a fingerprint image without having to use a camera.

KG: I didn’t know that, but it makes so much sense when you describe it that way. I thought it was just a low-end camera that took an image, since I heard that if you scratch it (or simply use your phone for some time, so that it wears out) then it wouldn’t work because the image would not have a high enough resolution to resolve your fingerprint. Obviously, I imagine it still wouldn’t work, but I understand why it happens now. That’s amazing.

BO: Qualcomm has a new sensor that can scan through glass and some metals, and can handle things like wet fingers, so you don’t actually need that big round circle on the back of your phone anymore. There aren’t many devices that have that right now, though. I think it’s just a few from Xiaomi and Le Eco.

KG: That’s interesting. Funnily enough, I bought my dad a Pixel phone recently, because he was due for an upgrade. He mentioned that he had gone to the pool or something, and after he came back, he tried to unlock his phone. It didn’t work. It makes sense now, because I imagine those ridges and valleys took a completely contorted shape as they shriveled up.

BO: The other thing that I’ve found is that if your fingers are wet (or even a little bit damp) that can affect the conductivity that it ends up measuring. If I’ve just washed my hands, even if I’ve dried them off, that can sometimes affect the sensor. Most phones have their issues with that from time to time.

DF: I think I remember hearing something related to fingerprint recognition on Episode 38 of the Android Developers Backstage podcast. They mentioned the Chicken Wing test: they wanted to make sure that Android fingerprint authentication worked so well that if you happened to be eating chicken wings, and you wiped your finger on a napkin quickly and put it on the fingerprint sensor, it would still be able to read it.

BO: I’m imagining them sending test devices out to a Super Bowl party to see if it worked…

DF: Anyway, I’ve heard that the fingerprint reader is tied to something on the actual chip itself. Do you know anything about how that works?

BO: Yes, it’s called a Trusted Execution Environment, and it’s either part of the CPU itself or on a separate chip called a secure element. But ARM CPUs have something called a trust zone, which is almost like a secure system within a system. Code running on Android can’t actually get at the memory used by what’s in the trust zone. If there’s rogue software running on your phone—maybe you have a virus, or maybe you’re rooted and you’re intentionally trying to pick at it—it still can’t exfiltrate what’s going on inside that trust zone.

KG: So you are saying this is almost like a physical hardware component on your phone? Typically, secure phones don’t allow API level access, or even much lower-level access, to any of that information. There’s no reading, just writing. Is that right?

BO: There are channels in and out, but yes: the Android OS kernel can’t actually see what’s going on in there or read that memory. There have been researchers who have tried to break the trust zone barrier, but it’s theoretically a firewall between the potentially insecure Android world and the world of cryptography and fingerprint scanning and matching.

KG: Got it. So there’s something called a trust zone, which I imagine is a marketing thing from the folks at ARM. And the Trusted Execution Environment is basically the genetic term for where the secure information is held. So, all Android phones have a Trusted Execution Environment?

BO: Not every one. This is something that a lot of older Android phones either did not have or make use of.

That’s one thing that you’ll find in the Android Compatibility Definition Document, which is a great piece of bedtime reading.

DF: A cure for insomnia?

BO: Print it out and keep it on the nightstand. Anyway, it’s basically the Bible of what you have to comply with to ship a version of Android that contains the Google Play Store and all of the Google accoutrements that come with an Android phone. One of the things that it specifies is how you should build your hardware if you’re have a fingerprint reader. For instance, fingerprint matching has to happen in trusted hardware, and the fingerprint reader has to have a secure channel straight to that. It can’t go to the user space on the Android side. Also, cryptography (which we’ll get to later today, I imagine) has to happen in that trusted zone as well.

DF: That kind of bridges the gap into the software component, because the hardware and the software have to talk together. This reminds me of when the Nexus 5X and 6P came out. They used what was called “Nexus Imprint”, which was the software/hardware combination that allowed Nexus phones to support fingerprint authentication. Do you know if this something that all devices have to implement? Or is this specific to Nexus devices? I know there are some Samsung devices, like a friend of mine has, that use fingerprint authentication, but is that the same thing?

KG: Donn, anyone who uses a Samsung phone is not your friend.

Just kidding….

DF: No, you’re not. You’re not kidding, and that’s the truth! [laughs] We’ll get into that in a minute, don’t worry.

BO: The Nexus Imprint, as far as I can tell, is really just a brand name for the fingerprint framework that arrived in Android 6. The underlying implementation of that fingerprint experience is what you’ll find in any device that has a fingerprint reader and runs Android 6 or better. Anything that meets these criteria under the CDD (i.e. it gets a fingerprint reader and all of that other good stuff that we talked about) is going to use the Android SDK. It’s effectively the same thing without the fancy branding.

KG: Basically, if I understand this right, the CDD is global to all Android phones, and anyone who implements the CDD allows the fingerprint feature on a phone. And Nexus Imprint is essentially a Google implementation of the CDD, but on the Nexus and Pixel phones, so it’s more like a marketing term.

BO: You got it. There is one wrinkle, though, since we mentioned Samsung. They started using fingerprint readers back with the Note 4 and the Galaxy S5, and their fingerprint API doesn’t do any of the really cool cryptography stuff that the Android API (since Marshmallow) lets you do. It doesn’t actually meet the CDD. If you try to use the fingerprint API on one of these devices (now that they run Marshmallow), Android will report that they don’t actually have fingerprint hardware.

You’ll probably get some 1-star reviews for this. I know I’ve seen them on apps that I’ve used (like 1Password, for instance), and the authors have to go chime in on their support forums, saying, “We’re really sorry, but while these two phones have fingerprint readers, they don’t meet the standards that Google set for this SDK. We can’t use them.” That’s one thing that you’ll have to fight against. Their SDK is simply a call-back of, “Hey, did you get a successful scan or not?” It doesn’t have any of the really fun cryptography stuff that we’ll see in the Android 6 API.

KG: So you’re basically saying that Samsung phones have weak security in their Fingerprint ID, and nobody should ever use Samsung phones ever in their life? And if they get new phones for different people, they should not be buying Samsung phones? That’s basically what you just said, right?

BO: I can’t fully agree with that, but I can say that if you’re going home for the holidays and your family asks, send them in the direction of a Pixel.

KG: Okay, I’m clearly a little biased here.

Anyway, I’m tracking with you so far. All of this makes sense. So, let’s dive into what actually happens once this fingerprint data gets encrypted. I’m curious about how the encryption model works, because (in all seriousness) this is very important. If you’re saying that this is a biometric way of unlocking your phones, and it’s secure, we need to understand how secure it really is, as developers. You also mentioned cryptography. Can you dive a little into that?

BO: One of the things that also comes in the Android CDD (with Android 6 and the fingerprint reader) is what’s called a “hardware keystore”. That’s really just an abstraction around a place where encryption keys can be placed, and where they can’t be exfiltrated out of the system by a rogue app, the government, rooting, or whatever else.

KG: Sorry, can we step back a little? What exactly is a keystore (for those of us who are wondering)?

BO: In Android, when you create an encryption key—either a symmetric key (which can be used to encrypt and decrypt a piece of data), or asymmetric keys (where you retain a private key and give your friends the public key, and vice versa)—it’s saved in what’s called the keystore, which is essentially an abstraction of the place where keys wind up being saved. Some of the older Android devices, way back in the Jelly Bean and Gingerbread dark days, actually didn’t have a place in the hardware where the key material was saved. If you were rooted, all bets were off.

Now, what actually happens is that all of the key manipulation and and actual cryptography happens inside the Trusted Execution Environment.

KG: That’s something we should really hit home. Essentially, you’re saying that after Android M, they began enforcing that encryption should happen only inside this Trusted Execution Environment, so even if you have root access to a phone that runs this operating system that is M and above, then you’re safe, but if you did it before M, then you’re probably not.

BO: So if you have an Android phone that runs M, the private key or symmetric key for any encryption operation will be safely locked up in that vault. It’s never going to be able to leave the friendly confines of the Trusted Execution Environment and get out into the world.

Where that plays in though, is when you create encryption keys on your device. You can actually set a property on those keys that says that authentication via the fingerprint reader is required before anyone can use them. That’s how you can actually use the fingerprint reader to sign data (if you’re using a public/private key pair) or encrypt and decrypt data you have on disk. In either case, you have some assurance that the only way you’re ever going to actually use those keys is if you put your finger to that reader.

DF: This actually could be very useful in situations where you need to provide some type of encryption mechanism for HIPAA compliance, or you need to encrypt a local database. For example, Realm has AES-256 encryption out of the box, but you have provide it a key. You could base it off of a fingerprint, so that if someone wants to have access to your app, and you need to make sure that it’s secure to that particular user, they have to authenticate with a fingerprint to unlock the database.

BO: Since there’s an OS handle for each key, you can just pass that off to whatever API needs the key to do its work.

KG: I have one quick follow-up question. You mentioned that you can set a property on the key that you are encrypting that basically says “user fingerprint required.” The question is: if you don’t have a user fingerprint—say, you only have a pattern or a PIN code—can you only unlock this with a fingerprint?

BO: I haven’t played with it, but as far as I remember, there’s also a way to unlock that key using the passcode, or (effectively) anything else that can open a lockscreen.

KG: Okay. I imagine they’re grouped as a specific sort of thing, because I remember that there was this talk about how Smart Lock is a trust agent thing, but isn’t necessarily as secure. I imagine that there are groups of authentication methods, like “this is super secure” and “this is a convenience kind of security.”

DF: So we talked a little bit about the hardware and some of the higher level software stuff—about how it works and what we can use it for. But if I’m a developer listening to this podcast, and I think, “This is cool. I really have a use for it. I have the HIPAA use case, or maybe I have a financial app that I need to unlock, or something else with security stuff,” what are some of the things that I need to do to implement fingerprint support? Is there a particular library that I need to use?

BO: The first thing that you need to do is make sure that you’re targeting Android 6.0 or better in your app. Once you’ve done that, you should go look in the Android SDK documentation for FingerprintManager. That lits all of the lovely methods that you’re going to use to check if fingerprint hardware exists and whether or not your device has fingerprints added to it, and for performing the authentication itself.

Handily, the support library gives us a class called FingerprintManagerCompat, which wraps a lot of this in SDK-level-safe versions. You don’t need a lot of version checks peppered throughout your code to do FingerprintManager calls. On older versions of Android, this will be a no-op, but on versions that actually support fingerprint, this will call into the FingerprintManager and do the real work.

The first thing you want to do in your UI is query, “Hey, does this phone have the hardware?” Then you could go and present a message to the user: either “You have fingerprints enrolled. Great,” or “I see you have a fingerprint reader. If you go and enroll fingerprints, then you can enable fingerprint authentication in our app.”

KG: Are these standard UI dialogs that come with the support library, or is this something you have to implement?

BO: You’d think that you’d get this for free in the support library, but not so. It’s never this easy with Android. However, if you go to the Google’s Material Design guidelines page, they have a really great page about Fingerprint which gives you some helpful guidelines on how to design your layouts for standard look and feel. They have a standard icon which they’d like you to use across all the apps, so that when you enroll a fingerprint, Android can say, “Hey, look for this icon. When you see it, you can use your fingerprint to unlock this app, or anything else that requires a fingerprint operation.” It also has some really good recaps of what fingerprint flows your user might run into as they’re interacting with the app and the fingerprint reader.

DF: Let me make sure I’m hearing this correctly: there is no built-in dialog, so I have to build my own dialog that looks like Material Design. I have to do all that work if I want to implement this.

BO: Unfortunately, yes. If you go to the Google samples, they have a sample fingerprint app with some layout files that you could pilfer, so that’s always a good start.

One great example that I’ve seen is the Target app. They’ve added fingerprint authentication, but they’ve done a bit of a spin on the dialog. They use more of a flat look, and instead of the white on green Android color, they use white on red. It’s very Target branded, but the Material guidelines do say that you can use your brand colors, as long as you keep that icon somewhere, so people know what to look for across all their interactions with their phone.

DF: Let me take a step back. We’ve talked about FingerprintManager and FingerprintManagerCompat. You can check to see if the hardware is detected, if it has enrolled fingerprints, and all of that good stuff. You can perform different actions given those scenarios, but to take it back to the fantastic Samsung devices that we all love, what happens to some of those older devices with these methods? If there’s a fingerprint reader, is it detected, and are there any weird things that we should expect when working with Samsung fingerprint readers?

BO: The older Samsung phones (like the Galaxy S5 and the Note 4) are going to give you back FALSE if you query for whether fingerprint hardware exists. One thing that I have found in crash logs on those Samsung phones (those are always fun) is that a smattering of devices (and I don’t think I was ever able to resolve what specific type it was) would throw a security exception if there weren’t any fingerprints actually enrolled in the phone.

DF: Thanks, Samsung.

BO: A word of caution from those who have been there before is to definitely wrap stuff like that in handlers, because you never know what Samsung or some other vendor is going to throw at you in this kind of stuff that has deeper hardware interactions.

DF: That’s an excellent bit of advice there. So, if we have the FingerprintManager at this point in time, and we’re ready to implement this, how do we go about generating the keys that we talked about? Myself and a bunch of other folks consider ourselves security dolts, so maybe you could walk us through what that would look like and how to get it set up?

BO: Android has a couple classes that help you create and save keys straight to the keystore. There’s a KeyGenerator, which is what you use for symmetric cryptography (i.e. the same key will encrypt and decrypt a piece of data). Then there’s also a KeyPairGenerator, which lets you generate public/private key pairs for public/private cryptography. The flavor of which classes you’re going to use depends upon what method of cryptography you’re using and what your use case is. For instance, if I’m just going to sign data (rather than encrypt it), I still need to use a key pair generator, because that will allow me to sign data with my private key, and ensure that the only way I can ever sign it is if I put my finger to that reader.

The way we do that is by passing in an instance of a class called a KeyGenParameterSpec. That basically encapsulates all the parameters necessary for creating a key. It comes with a builder, and the builder methods contain things like the algorithm you’re using—you know, like AES and Elliptic Curve—how many bits in the key, etc.

Also, one of those builder methods (after you’ve decided on your algorithm and key complexity) is going to be setUserAuthenticationRequired. This is what puts that key in the vault, so to speak, that’s guarded by the fingerprint reader.

KG: Got it. That’s step one, I suppose: generating the key. You’ve managed to take this key and store it inside the Trusted Execution Environment, but through the API, so you don’t necessarily have to do it yourself.

BO: Yeah. Now, you have to figure out what you want to do with this key. One thing that’s really handy is fingerprint authentication to a remote backend. You can actually sign a piece of data with your private key that authenticates you. Since the only way that I’m able to use that key is by using the fingerprint reader, if I want to prove to a backend server that I put my fingerprint on there, I can sign a piece of data with that private key and the back-end can register it.

For instance, maybe I’m adding fingerprint authentication to an app that has not had it before. In the past, you would sign in with a username and password and get back a session token. Well, you sign a request with your session token and your public key wrapped in that, and send that up to the backend to register your public key as part of the data that’s maintained for you. The next time around, if you send a login request, you don’t send in a username and password. Instead, you send a blob of data that’s signed with that private key, saying, “I want to log in as Donn and I’m signing this with my private key.” Then you can validate that signature on the backend and say, “This passes the signature check by verifying with the public key. I know that he actually has access to that private key, so I can go ahead and log in using that request instead of a username and password.”

What’s really handy is that if I request to enroll my device in this new backend feature, I can give back a device ID that I saved locally. Now, on the backend side, I have the ability to revoke an individual device login. Since I’m not sending a live username and password over the wire anymore, I can remotely disable that device’s ability to login with fingerprint. That gives a little bit more security for your users if they lose their phone, and someone else might have access to the fingerprint.

A really good analogy is if you’ve ever used SSH to login to a server and enrolled your public key on the server side. After that, you basically turbo login. That’s the pretty much exact same thing we’re doing here.

KG: Exactly. That actually brings up two quick follow-up points. First, you mentioned symmetric and asymmetric cryptography off-hand. Just to give folks a quick understanding, symmetric and asymmetric encryption use two different mechanisms. The difference is that symmetric uses the same key to unlock and lock, but asymmetric uses two separate keys to unlock and lock.

BO: Right. With an asymmetric key, you have a private key and a public key. You guard the private key with your life. It’s yours, and yours alone. But you can go and send out your public key anywhere. You could post it on Twitter, or mail it to everyone in the world. In fact, they actually need that key to be able to encrypt data that’s destined for you. So I can go and encrypt data using your public key, and that data is now for your eyes only. Only you can use your private key to unlock it.

What’s also handy is that you can basically use your private key as a digital notary stamp. I can sign a piece of data with my private key, and then (if you have my public key) you can come back and validate that it was really me who signed it.

DF: If folks are really trying hard to wrap their heads around how public/private key encryption works, and if they’ve never really dived into it, it can be a really confusing beast. I’m going to put a link in the show notes to a blog post where the author explains very easily, and through a great analogy, how public/private key encryption works.

KG: My last follow-up question was: you mention sending stuff to your backend. That brings up a question: does fingerprint authentication only work when you’re online? What if I’m offline? Does it not work then? If I’m using an application, and I’m in a tunnel, riding in a bus, does that mean that I can’t use the Touch ID?

BO: Well, if you don’t actually care about having this implemented in your backend side, you can encrypt with a symmetric key to save data offline, and also use that. For instance, maybe I have a diary app. I can use a symmetric key to encrypt every piece of every single journal entry. Maybe I’m using Realm to back this up, as Donn suggested earlier. I could use that locally-saved symmetric key to encrypt some local data and pull it back up later on when I’m offline, or if I don’t want to have any kind of server interaction at all.

KG: Just to wrap this up, we’ve signed the requests with a private key. What happens after that? I have this key, so what do I do now? I imagine I have to use one of the APIs that’s provided to me by Android, and that this is the final step. So what happens? At what point do I get a boolean saying “Yes, you are authenticated,” or “No, you are not authenticated”?

BO: Once you’ve generated this key, you can call authenticate on an instance of the FingerprintManager. You pass in what’s called a CryptoObject, which is really just a generic box to hold a handle to the key. That just tracks whether you’re going to use a key pair or a symmetric key. What that will do is activate the fingerprint reader. When you call this, you also pass in a callback, and you implement a listener. Depending on how that scan went, you’re going to get some calls into this. There’s a success callback that gives you your cryptography object back, blessed by the fingerprint reader. You can pluck your key handle out and go use it to sign or encrypt some data.

Then there are a couple different flavors of error conditions which are handled by two different callbacks that you’ll need to implement. One is for a hard error, where you scan the wrong finger five times and it locks you out. Try it the next time you try to log in to your bank or unlock your lock screen. After five bad tries, it locks you out of the hardware.

The other is a soft error, and there’s a handler for that. Maybe you moved your finger too quickly on the sensor, so it asks you to try again. We’ve all seen that one. There is another one in there that goes back to the hot wing example here: the “The finger is too dirty” error condition that asks someone to use a different finger, go wash their hands, or something.

DF: Take a bath!

BO: What’s really handy about these soft and hard errors is that you don’t actually have to worry too much about disambiguating what the error is. Android is nice enough to pass in a string with these callbacks that has localized error text which you can show in your UI. This might also be because some vendors and OEMs have their own failure cases for why their sensor didn’t work, so they can handle that and you don’t have to worry about it. Or, you won’t have the messages localized to each language, so you don’t need to enumerate localized translations for all of these different error conditions. One thing that you will find in the Material guidelines is that when the framework gives you back those callbacks, don’t try to dream up your own error messages.

KG: That makes sense. Just to wrap up what you just said, you have a cryptography object, which you pass to the FingerprintManager. At that point, the device starts reading your fingerprint. Once the person puts his finger on the sensor, the data comes in, and the callback that you passed in initially when constructing this comes back with a success or failure. Then you can perform accordingly to what you need to do. Is that the high-level overview?

BO: Yep, you’ve got it. If you get a success, you can go and use that key to encrypt or decrypt some data or sign something. At that point, the key is yours to use.

DF: There is a ton of stuff out there about fingerprints. There is the Android documentation and so forth, but I wanted to highlight some of the things that we’ve noticed that you’ve done, Ben. One is that you have an actual Android Fingerprint demo up on Github, correct?

BO: Yeah, I put this together for my talk at DroidCon NYC last fall. What you’ll find in there is a super simple implementation of an app that does fingerprint. I did Uber for baked potatoes, and called it Tuber. You’ll also find a sample backend that handles public key verification. If you want to use a signature based request pattern, you’ll find a starting point in there, so you can pretty easily spin up that backend.

It’s all lovingly done in Kotlin, which you can run locally in the emulator as well, side-by-side. There are some instructions on how to make sure that your emulator can talk to that sample backend, and you can play with Fingerprint there.

DF: Ben, I’m really excited to check out that Github link. I didn’t know there was a server component to it as well, so I’m going to check that out—and fork it, and probably create an Uber for Chipotle, because I need some burritos.

BO: Burrito bowls on the go.

DF: Here’s my money. Take it.

KG: Ben, thank you so much. This has been really exciting. It opens up a whole bunch of possibilities. I’m sure that many folks are curious to see what’s involved in implementing fingerprint authentication, so this is extremely useful stuff. Thank you so much for coming on the show and helping us understand this.

BO: Thank you very much for having me on. I hope this is a good starting point for a lot of people.

KG: Absolutely. If folks want to reach out to you and want to find out more about fingerprints, what’s a good way to do that?

BO: Definitely check out the Github repo in the show notes. If you still have any questions, you can hit me up on Twitter. My handle is @benlikestocode. I’ll be happy to field questions there, for sure.

KG: I know Donn likes to code as well. Where do folks hit you up?

DF: Just like Ben, I’m on Twitter. You can hit me up at @donnfelker. What about you, Kaushik? Where can folks find the illustrious Kaushik Gopal?

KG: Well, I have a very creative Twitter username: @kaushikgopal. You can hit me up there if you have any questions. Thank you all so much for listening, and thanks again, Ben, for coming on this show.

073: Effective Java for Android Developers – Item #14: In public classes, use accessor methods, not public fields

Mon, 13 Feb 2017 05:00:23 UTC

Download directly

In this mini-Fragment episode, Donn talks about Item #14 of the Effective Java series – In public classes, use accessor methods, not public fields. You’ll learn why it’s important to use accessors in your public classes and some caveats to this rule.

For example, you may decide that the class is a private inner class or package private. Donn digs into the details in this week’s episode. This is a glimpse of what’s to come in Item #15, which is coming soon…

Show Notes #

Rollbar

Contact #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

Transcript #

Donn Felker: Today, I’m going to talk about Item 14 in Effective Java, by Joshua Bloch.

For those of you who are just joining us, we do a small “mini-Fragment” episode every once in a while. Some of these episodes are based around Effective Java, a book that’s packed full of great information for every single Java developer. It gives a bunch of patterns and practices that you should implement in order to be a good Java developer. Our goal here is to relate them to Android development, and to talk about each of the items as we come across them.

Today, I’m talking about Item 14, which states: “In public classes, use accessor methods, not public fields.” I think the key phrase here is “In public classes…” Keep that in mind: Joshua is not talking about private or package-private classes, but about public classes only.

Some folks are tempted to create data objects that, instead of having accessors and mutators (getters and setters, respectively), just make their fields public. They’ll make a public value, and they’ll just access it that way. One of the reasons that this is looked upon badly by some of the hard-line, object-oriented programmers is because it doesn’t offer the benefits of encapsulation:

You can’t change the representation without changing the API, you can’t enforce invariants, and you can’t take auxiliary action when a field is accessed. Effective Java, page 71

There are a bunch of problems which you can encounter when you expose these values as public fields.

On a personal note, I agree with him that when it comes to public classes, which are accessible outside of their package, you should provide some type of getter or accessor method. This allows you to preserve some flexibility around that class’s internal representation.

If (for some reason) your class does expose a public field, all hope of ever changing its representation is basically lost. That public class—again, a public field or method—is a part of the API that you’re giving. If you build a library and make something public, it’s going to be used by people who are using your library. You need to think hard and long about whether something should be public. If it’s a field, you’re kind of tied to it. If you realize later (for some reason), “Ooh, I need to change that because of these problems,” there will be all sorts of folks who are using that public field.

Instead, you should probably think about encapsulating the field in some type of accessor (i.e. a getter method), and that’s exactly what item 14 is saying.

Effective Java then dives in, saying that the main reason for this item (again) is to preserve the class’s internal representation of the data and give you some flexibility in how it works (if you need to change it).

Now, there is a flip side to this coin (which everyone probably has on the tip of their tongue): if the class is package-private or within a private nested class, there’s nothing inherently wrong about exposing its data fields, assuming that they do a good job of describing any type of data or abstraction provided by said class. The reason for this is that it generates less visual clutter (i.e. you have less code lying around) than the typical accessor method approach. I’m sure you’ve seen this: if you have ten fields in your class, and then (for some reason) you generate getters and setters using Android Studio or IntelliJ, your class suddenly explodes from 15 lines of code to 30-50 lines of code, and you have a larger set of code to maintain. So, if the class is private or package-private, you can go ahead and set your fields to public.

One of the reasons why it’s okay to do this in a private or package-private class is because the client code (your library, or whatever) is tied to the class’s internal representation and the package containing that class. If changing something in the class is desirable, you can make that change without having to worry about what it will do to the public API. You aren’t changing a method name, its signature, or anything like that which could be a breaking change.

However, you still have to be careful about what you’re doing to the data, since you could be changing what’s happening (against the users expectations). If (for some reason) you’re changing a value when another method is called, you need to (of course) notate that in your release notes.

Please note that you’ve probably seen different classes in Java itself that completely violate this advice—for instance, the Point class and the Dimension class. Apparently, according to the book, some internals of the Dimension class which are exposed create a serious performance problem that’s still in Java today. I haven’t dug into this exact issue, so this is just from Effective Java, but Joshua is explaining, “Look, Java has actually suffered from this, and they’re realizing it too.” He’s giving the advice to provide a public accessor method, which helps you fix or alleviate some of the problems that existing Java classes have run into.

There’s also another caveat to this (which a lot of the folks out who are really into immutable data types are probably screaming at me right now): while it’s never a good idea for a public class to expose fields directly, it’s usually less harmful if those fields are immutable. You can’t change the representation of that data because it’s immutable.

Suppose I have a class called Time with two variables: Hour and Minute. We could set those as public final int Hour and public final int Minute. We could then pass those values in when we create an instance of the Time class. So you would say new Time, pass in the hour and the minute, and those public fields would then be instantiated. There are no setter methods. These are public final fields, so you cannot change them. In that case, the class guarantees that each instance represents a valid time, and something will not be changed.

In summary, item 14 states that public classes should never expose mutable fields. Of course, there are some caveats to that, such as inner private and package-private classes, and also if those fields are not going to be mutable.

I really hope that this helps you. Please pay attention to the next item (item 15), where we’re going to be talking about minimizing mutability. This is a huge topic in Android right now, and we’ll talk about these in the next Fragment.

072: App Shortcuts with Andrew Orobator

Mon, 06 Feb 2017 05:00:31 UTC

Download directly

In this episode, we talk to Android developer Andrew Orobator. He gives us the lowdown on the new feature App Shortcuts that was introduced in Android. We talk about static and dynamic shortcuts, use cases for other shortcuts and how to implement them for your app. We also cover what the feature lacks and things to watch out for, while implementing them. Listen on!

Fragmented also has spanking new music from the super talented Blueprint: you can find out more at info@printmatic.net.

Show Notes #

Andrew’s Medium posts #

Introducing Auracle: A queue based music player: Andrew’s new music player
Implementing Android App shortcuts
Andrew’s medium posts
Best productivity tools for Android developers (another article Andrew wrote)

Misc #

App shortcuts design guidelines
Konstellation (Kotlin demo app using App Shortcuts)

Sponsors #

Rollbar – special offer: Bootstrap plan free

Contact #

Transcript #

Donn Felker: Kaushik, it’s been a while, but we’re finally back.

Kaushik Gopal: Yes we are. How has your 2017 been so far?

DF: Well, it’s a new year, so I think it’s only right to talk about something new which neither you or I have done. I work with an individual named Andrew, and we’ve invited him on the show to talk with us about application shortcuts, a newly released Android feature. Without further ado, welcome to the show, Andrew.

Andrew Orobator: Thank you.

DF: For folks who aren’t familiar with you and haven’t read any of your really good blog posts, can you tell us a little bit about your background—how you got started in Android development, where you work, and so forth?

AO: Sure thing. In the summer of 2013, I had just finished up a class on Java. I had a new HTC One (M7) that I wanted to put some music on, instead of carrying around my old iPod Classic. I tried out several music players, but none of them really worked the way I wanted them to. So I set out to make my own—which I actually just released to beta in the first week of January. It’s called Auracle Music Player.

I currently work as a Android engineer for American Express (which is how I met Donn), although I’ll be joining the team at 7Park Data in a few weeks.

DF: What does 7Park do?

AO: 7Park Data generates analytics for millions of users of popular apps. Then they take all of that data and apply machine learning algorithms to it, and they essentially provide consumer insights.

KG: Very cool! That sounds exciting. Are you excited about it?

AO: Yeah, I’m super excited. I did a couple of machine learning classes in college (just the basics, but enough to get by), so it’s going to be really exciting to work closely on the Android side with machine learning.

KG: Will you be building the client-facing consumption point for that data?

AO: That’s correct. I’ll be working on the app that’s accumulating data and sending it to their backends.

KG: We’ll stay tuned and have you back on the show sometime so we can learn more. Look at us, already pushing the next episode!

DF: Andrew, when I was visiting New York, you showed me a blog post you had written about implementing app shortcuts, so we thought it would be perfect to have you on the show to talk about that. Have you written just the one blog post, or have you written or talked more about it?

AO: So there was a blog post, a talk I gave about it at AmEx, and an open-source repository on GitHub to go along with all of this.

KG: Fantastic.

To kick this off, what exactly are app shortcuts? I know that Google has recently released a whole bunch of new features in Android 7. I know that app links, instant apps, and app shortcuts exist, but I know nothing about app shortcuts. Could you tell me what app shortcuts are, and why they’re interesting as Android developers?

AO: App shortcuts are primary actions or deep links into your app that can be accessed via a long press on the app icon. You can pin these shortcuts to your home screen by long pressing and dragging them from the menu that appears. For all of you iOS folks, this is pretty similar to a Force Touch, although app shortcuts are implemented in software, not hardware.

KG: Got it. So in iOS, there’s some pressure-sensitive aspect in the hardware that triggers an app shortcut, but in Android, it’s just a long press.

DF: Where exactly are these app shortcuts available? Can I only do them on my home screen, or can I do it the app launcher? What about custom launchers?

AO: It really depends on the launcher’s implementation, since they’re the apps that actually choose how to display these shortcuts. You implement app shortcuts by providing data that says, “Hey, this is what I want to display,” and then the launcher figures out how and when to display it. In both Nova Launcher and the Google Now Launcher, you can access shortcuts on the home screen, but you can also access app shortcuts in the app drawer using the Google Now Launcher.

KG: Interesting. So, even if you did have it technically implemented in your application, it would only be seen in the specific launchers that are capable of launching it, right?

AO: That’s correct.

KG: How else can you use this? Donn and I have been wondering if you actually use these from the home screen. For example, I have a to-do application, and there’s one task that I keep doing, to the point where I’m thinking, “You know what? This should just be the default.” Is there a way to pin that specific action to my home screen, in my list of app shortcuts?

AO: Absolutely. Individual shortcuts can be pinned to the home screen, but (again) this is up to the launcher app that the user uses—although I haven’t seen any that diverge from that.

DF: Let’s reel back for a second. You’re an application developer. When you developed Auracle, why did you decide to implement app shortcuts? How do they benefit the user?

AO: Personally, I’m a big fan of playlists. I love making custom playlists, and I mostly listen to playlists when I’m listening to music. Sometimes I know the exact playlist I want to listen to. Auracle provides shortcuts to my most listened to playlists, and I can just pin my favorites on my home screen. Instead of opening the app and navigating to the playlist, I can just click on the playlist right from the home screen.

DF: I used to work at MyFitnessPal, which had a calorie tracking app. If they wanted to allow folks to go straight to the food diary, they could implement a custom shortcut to do that, correct?

AO: Yeah, that sounds about right.

KG: Since we are talking about example applications, it’s easier to sell app shortcuts as a feature when people can see examples of applications that do this. You said that your music player has a playlist menu. I could have sworn that Pocket Casts (a podcast player that many of us use) also has something along those lines. Are there any other apps that jump out to you as doing this pretty well?

AO: Yeah. Google Maps has really good app shortcuts. When you press on the Maps icon, two shortcuts appear: “Home” and “Work”. When you click on “Home,” it’s opens up directions to your home.

KG: Why have I not done this? Immediately, I’m understanding why you use this.

DF: Okay, end the podcast. Thanks, we’re good to go!

No, I’m literally on my phone right now, playing with this. I’m long pressing random icons. Pocket Casts has a bunch of options. Google Play Music has everything. It’s almost as if, if you have analytics on your application and you’re able to tell what users do the most, it would be a good thing to implement that as an app shortcut.

AO: That’s actually a really solid idea.

DF: Yeah, I’m looking at Play Music now. Every time I open it, I always seem to go to “My Library”, because I create playlists (just like you, Andrew). I have a productivity playlist (music with no lyrics) and another playlist for working out. I always open the app, and I’m buried in some search that I was doing. Then I have to navigate back to the home screen, go to “My Library”, and then to “My Playlists”.

But with this app shortcut that they have, I can go straight to “My Library” or my recent activity. I skipped all of these steps. Just like you said for Maps, it’s just a huge timesaver—I mean, let’s be honest: every time you open Maps you’re either going somewhere from home, or you’re going home. You’re probably going home 50% of the time, so that’s a humongous time savings.

KG: Donn, you know that I have problems with to-do applications. I go a little bonkers about a whole bunch of them: Trello, Asana, Todoist, etcetera (yes, I’ve used all of them—and actually still do!). One thing that I find super helpful about the app shortcuts is the ability to hold and press the icon and quickly add tasks to specific projects. You can also do searches faster, which makes sense. This is pretty slick. I’m really liking this, especially for applications that primarily use one action really quickly. I imagine that an app shortcut is a great thing there.

It’s funny though. I was looking at Uber and Lyft and thinking about the Maps thing. Being developers, we’re kind of lazy that way. I was thinking, “Maybe Uber and Lyft should have a ‘Get me a ride home’ button.” I’m sure that’s coming down the line, though.

AO: That would actually be awesome.

KG: That would be pretty slick. It would be a huge time saver.

Alright, so we’ve been talking about all the advantages this has, but are there any limitations to this? For example, are these only available on an API level? Because if you’re a developer, you’re thinking, “Oh my God, this is amazing,” but then you use API 14 or 15 and no one sees it. Can you tell us a little more about some of those limitations?

AO: Sure. App shortcuts were introduced in Android 7.1, so they can only be used on API level 25 or above. When you’re actually writing code, you have to check against Build.VERSION_CODES.N_MR1.

DF: That’s the hidden beast in Android sometimes. You’ve got a new cool feature that comes out in the new APIs, but you can’t use it until everyone is using it.

Thankfully, I have it, though!

KG: And that’s all that matters!

One quick follow-up question to that: there are actually two limitations here, right? One is the API level, which (you rightly mentioned) is API 25. Then there’s also the fact that only certain launchers allow this. Developers have to keep that in mind, because we can’t just say, “Okay, set the minimum API to 25.” If you can…oh man, you’re living the life. But it’s not just about setting your SDK to 25. It’s also about the fact that it’s only currently available in certain launchers.

AO: Right. When you’re testing, it makes a lot of sense to test your implementation on different launchers, like Nova Launcher, Action Launcher, and the Google Now Launcher.

DF: What are some of the challenges that you’ve encountered while implementing app shortcuts on your personal projects?

AO: For starters, you can’t have an unlimited number of app shortcuts. In theory, you’re allowed a maximum of 5, which are any mix of static and dynamic shortcuts. Your app will actually crash if you provide more.

KG: Oh, that’s aggressive. I like it!

AO: They’re hard and fast with their limitations. In practice, you only see four app shortcuts, anyway. You can provide five, but I’ve never actually gotten that to show up. It’s kind of weird like that.

Another gotcha when you’re making app shortcuts comes when you want to disable shortcuts if the actions they represent become unavailable in your app. In Auracle, I include the most listened to playlists as shortcuts. But if they’ve pinned that shortcuts to their home screen, and then they delete the playlist, it’s a dead link. If they try to open a deleted playlist, the app could potentially crash. So every time a user deletes a playlist, I disable the shortcut for the playlist as well. When they try to click on the deleted playlist, the launcher will display a “shortcut disabled” message instead of potentially crashing your app.

KG: Those are considerations that you have to make, but in the larger scheme of things, this is pretty amazing! You know what? You’ve sold me. I want to implement this right away, because it sounds really interesting to me. How do I go about implementing app shortcuts? Where do I start? I mean, I have no clue. So, as a developer, what’s step 1?

AO: The first thing you should know is that there are two different types of app shortcuts: dynamic and static.

DF: What’s the difference between the two? When would you use a static one, and when would you use a dynamic one?

AO: A static shortcut is defined in the XML that’s bundled in your APK. That means that you can only update them when you update your app in the Play Store. Dynamic shortcuts, on the other hand, can be updated at runtime.

You’d use a static shortcut to represent core action for your app. For example, Google Maps has two shortcuts that offer directions to your home and your work. While I don’t have the source for the Maps application, I would have made those static shortcuts, because they’re core actions. They don’t just disappear at the whim of the user. On the other hand, if your app shortcuts represent actions performed on user-generated content, you should consider using dynamic app shortcuts. For example, a messaging app could provide shortcuts to a user’s most recent conversations or favorite contacts.

KG: Let’s keep step one simple. I know that are some cool things I’m already thinking of that can be done with dynamic shortcuts, but suppose I just want to make a basic application to help me get a feel of how this thing works. Let’s talk about just static shortcuts. How do I go ahead and implement one?

AO: When you’re implementing a static shortcut, it’s all in the XML, so the first thing you’re going to do is edit your Android Manifest. You’ll need to add a metadata tag to your launcher activity. You can actually drop this tag onto any launcher activity, so if you have multiple activities showing up in the launcher, each one can be assigned separate app shortcuts. So you add a metadata tag to your launcher activity, with the name android.app.shortcuts and the resource @xml/shortcuts.

The next step is to actually create the shortcuts.xml file in the xml-v25 folder. Note the resource qualifier saying that it’s only for version 25 and above. Technically, Android won’t crash without it, but Android Studio gives you a warning about it, so it’s best practices to just use the qualifier.

DF: You said that you were going to create an @xml/shortcuts resource. What’s contained inside of that XML metadata?

AO: There are a bunch of attributes which you can specify for static app shortcuts. The major ones are the shortcut labels (the text that you see associated with your shortcut), the icon (which you usually see to the left of the text), and the intent(s) used to launch the user into your app. You can actually specify multiple intents as you’re defining these in XML, if you would like to create a back stack when the user taps on your shortcut.

KG: Interesting. Actually, that makes sense now, assuming (like you said) that you have an action which takes you into an activity, and you want to back out into another activity—for example, if Twitter had a new tweet shortcut, and after backing out of that, they wanted to take you back into the timeline—you can do that. The framework allows that.

AO: That’s exactly right.

KG: Is there any possibility of shortcuts being enabled and disabled? How does that work? For example, maybe I don’t want a certain shortcut (taking the example of Twitter again, a new tweet) to happen, if they aren’t logged in. You cannot enter a new tweet unless you’re signed in, or something along those lines. Is there any way to handling that?

AO: You can mark your shortcut as disabled in code. Just as a note: you cannot modify static shortcuts at runtime. You will get an exception, and your app will crash. You can only disable dynamic shortcuts.

KG: Oh, that’s good to know.

AO: If you want to disable a static shortcut, you’ll have to do it in XML on the next APK update from the Play Store. But when you disable a shortcut, the launcher (at least, Google Now Launcher) turns the shortcut icon into grayscale. Then, even if it was pinned on the home screen, it’s not going to appear in the shortcuts menu at all either. If you click on the grayed out icon, a short toast will pop up containing the shortcut disabled message. The default is literally “Shortcut disabled,” but you can override that to provide more information to your user.

DF: Now you have these various different static and dynamic shortcuts. But from what I’ve been able to read, it seems that you can provide an icon to go with that. Does that icon have to be your app icon, or can it be a custom icon?

AO: It’s really a mix of both custom and app icons. So the app shortcut’s main icon will be the one you provide. That’s the big icon that you’ll see—the main icon. It’s going to appear as a small badge on top of the app shortcut icon.

DF: Okay. Are there any icon design guidelines we should follow as we develop these app shortcut icons?

AO: Absolutely. Google actually released design guidelines for app shortcuts. The basic gist of it is that you have a 48 dp square icon, which should feature a Material Gray 100 circle with a diameter of 44 dp. In the middle of that circle, you have a 24 dp square icon specifying the action.

KG: Wow. I guess that’s to bring some consistency to it, especially since it’s so visible to users.

AO: Exactly.

KG: Interesting. A quick follow-up question to that: you can’t use vectors there, I imagine—or can you?

AO: Vectors were introduced in API 21, and you’re on version 25 when you do app shortcuts, so you can definitely use vectors.

KG: Along the same lines of controlling what the user sees, what options do I have?

AO: You can control the label that the user sees in a couple of ways. There’s a short label and a long label. It’s recommended that the short label be less than or equal to 10 characters, and the long label be less than or equal to 25 characters. Android picks the appropriate one to display based on the space available, but I’ve noticed that the short label is usually used when something is placed on the home screen, and the long label is usually used whenever there is space in the app shortcut menu.

KG: Interesting. So that’s just a general guideline so far.

AO: Right, but if any of these labels are too long, they’ll just be truncated with ellipses.

DF: So how do we control what a shortcut does? Do they use the intent system? Do we have to create an intent? How does that work?

AO: It’s just a regular intent, but it has some requirements. It has to have an action specified, and you’ll crash if you don’t have one. If having an action doesn’t really make sense for your application, you still need to put something. I’d recommend using the value android.intent.action.VIEW, although the string you use doesn’t really matter. It could be an empty string if you wanted it to be. You’ll also need to specify the target class (the activity you want to launch) and the target package (your package name). Then, if you want to create a back stack (like we talked about earlier), you can define multiple intents in a list, and the last one in the list will be what the user sees when they click on your app shortcut.

KG: That makes sense. I’m sufficiently intrigued by static shortcuts, so I want to up my game and do dynamic shortcuts. Can you walk us through how dynamic shortcuts actually work, so that I can get a better understanding of how I’d go about implementing them?

AO: Dynamic app shortcuts have all the same attributes as static app shortcuts, but they can be updated, modified, created, or destroyed at runtime. That’s the main difference.

KG: What’s the reason why I’d want to use one of these, again (just so we refresh our understanding of this)?

AO: I would recommend using dynamic shortcuts if you’re going to deep-link to user generated content. In Auracle, I have dynamic shortcuts to the user’s most listened to playlists. Or, a messaging app could provide shortcuts for the most recent or most active conversations.

DF: You said before that there’s a limitation to the number of shortcuts you can have, but when I think of something dynamic, I think of something that can be updated at runtime. If I can’t have more than five shortcuts, would I be correct in assuming that I could technically update one particular shortcut with an infinite number of options?

AO: That totally makes sense. It’s a dynamic shortcut, so you can continuously update it, and it will continuously change. You could even change what actions it represents in code.

KG: Interesting. So, in that case, can even the short and long labels that you talked change, or would those have to be generic?

AO: When you’re creating a shortcut, you pass in a ShortcutInfo. That contains all of the attributes of the shortcut, including the long label and the short label. As long as you pass in the ID of the shortcut, it’ll update everything that’s in there with the current values from the ShortcutInfo.

KG: How do I go about creating, destroying, or even updating these shortcuts?

AO: You have to go through the ShortcutManager. The ShortcutManager is the class that you interact with whenever you’re dealing with app shortcuts.

DF: So if I’m going to work with the ShortcutManager, how do I get an instance of it? Where does it come from?

AO: You can get an instance using context: getSystemService(ShortcutManager.class). Make sure to only do that on API 25 and above, since ShortcutManager doesn’t exist on previous versions of Android. If you try to do this on API 24, you’re going to get a “class not found” exception.

KG: Does Lint warn us of that? I know there’s the Lint max API option, and there’s a Lint error that specifies when something is available only beyond your max API, but do you know (off the top of your head) if Lint warns you of this?

AO: I’ve got Android Studio open. I can check.

KG: Nice! That’s how we do it here!

AO: Let’s see. Android Studio doesn’t currently provide a Lint warning. My min SDK version is 19, and there’s no warning. Maybe I can file a bug for that.

KG: I was going to say that. You should hit those folks up, because they’re very open to suggestions.

DF: If we update shortcuts, what’s the procedure by which we need to go about it? Is there anything special we need to do?

AO: Whenever you’re interacting with the ShortcutManager, you’re usually interacting with batches of shortcuts, not just a single one. If you wanted to update some shortcuts, you would have a list of ShortcutInfos. Make sure that they all have the appropriate IDs and all of the up-to-date information, and then pass that list of ShortcutInfos to ShortcutManager.updateShortcuts.

KG: What are the steps again to create a dynamic shortcut?

AO: The first thing that you’re going to do is create a ShortcutInfo object. This details the attributes of the app shortcut, like the ID, the icon, the label, etc. There’s a really nice builder that you can use to get this done that helps you out with everything. You have to do this for every dynamic shortcut you make.

Then you pass the list of these shortcut info objects to ShortcutManager.setDynamicShortcuts.

DF: How do we get a reference to a particular shortcut? Say we wanted to remove one of those dynamic shortcuts—how would we go about that?

AO: If you know the ID of the shortcut, you could pass in a list of string IDs, because the IDs are strings. You call ShortcutManager.removeDynamicShortcuts and pass in that list.

DF: And then it just goes ahead and removes all of those.

It sounds like dynamic shortcuts are more work, but it seems that they do give you more flexibility. Would that be an accurate assessment?

AO: Yeah, that’s spot on. They’re super flexible.

In Auracle, the playlist icons for each app shortcut come from an icon font and color that’s customizable by the user. This means that there’s a ton of icon color combinations needed for the app shortcut icons. Instead of having my designer make assets for each and every different combination of icon color (bloating the APK), I have a custom view that draws the app shortcut icon to a bitmap. Then I use Icon.createWithBitmap, and pass the resulting icon to the ShortcutManager when I’m creating the shortcut.

KG: That’s pretty slick! You could play around with these things in so many ways.

So, is there some sort of heuristic that I can use when I’m starting out with a new application? Is there an easy way to say, “Okay, this is when you use a static shortcut, and this is when you use a dynamic shortcut”? This is just for people who want to try this out.

AO: In general, you should use a static shortcut for actions that your user can perform in your app that remain constant. For example, Evernote has an app shortcut that creates a note.

You should use dynamic shortcuts if you want to link to user-generated content, like conversations or playlists—things that are going to change over time.

DF: While we were having this conversation, I unlocked my device and went to Pandora. They actually have app shortcuts, and they’re great. It actually lists the top three stations that I play, which is a fantastic use of dynamic shortcuts.

Are there any best practices that you would recommend for app shortcuts in general?

AO: Every time a user navigates to a part of your app that’s accessible via shortcut, whether they got there using the shortcut or by navigating through the app, you should call ShortcutManager.reportShortcutUsed. That gives launcher apps the information they need to build a prediction model and promote the shortcuts that are likely to be used at any given moment.

KG: As you were mentioning this, I was playing around, and I opened up developer options and noticed something curious: there’s an option to “Reset ShortcutManager rate-limiting”. What’s up with that? I don’t even understand this concept. What does resetting the rate-limit mean?

AO: When you’re actively developing, you’re probably going to be using the updateShortcuts, setDynamicShortcuts, and addDynamicShortcuts methods pretty frequently. It’s important to know that Android limits how often these methods can be called if your app is in the background. If your app is backgrounded, Android just won’t let it update your shortcuts that often. It’s probably best for the user, actually.

In a production environment, this limit can be reset by bringing your app to the foreground. But in a development environment, you can go to developer options and hit “Reset ShortcutManager rate-limiting” to get rid of this limit.

KG: That makes sense. It’s nice to have the option there, so that you don’t have to manually figure out a way to trigger that.

DF: Can the same thing be done through ADB, if I wanted to automate this?

AO: There is an ADB shell command called reset-throttling.

DF: That makes it easier, especially in a test environment. That could be very useful.

Let’s bring this full circle. For me, one of the best ways I’ve found to learn things is by looking at sample apps and just reading and interacting with the code. Do you know of any sample apps that someone could inspect or download to see how to use static or dynamic shortcuts?

AO: I actually made a sample app called “Konstellations”. It simply has a list of constellations, and information about each one. Then I track the usage of each shortcut, so that on the home screen, it always provides app shortcuts for the most visited constellations. There’s also a static shortcut in there that will take you to a random constellation.

DF: Sweet. Where is this available at?

AO: On Github. Another thing to note about this project is that you can also toggle whether a shortcut is enabled or disabled via the app, so you get that behavior as well.

KG: Wait a minute…I just opened it up, and is this written in Kotlin?

AO: It’s 100% Kotlin. There’s a little bit of Java in there from the generated tests, but the entire project is written in Kotlin.

KG: People, if you also want to get a little dose of Kotlin, then this project is right up your alley as well.

App shortcuts seem to have been implemented pretty well. It doesn’t necessarily seem very daunting as a developer. I’m super curious about this, and I definitely want to try them out. Listeners, especially if you’re building apps, it’s easy enough to give this functionality to your users. I would encourage you to do it.

Thank you so much for letting us know about this, Andrew. It’s been an absolute pleasure.

AO: Thanks for having me on the show.

KG: If folks want to reach out to you with questions on some the nitty-gritty, interesting aspects of app shortcuts, is there a way they can do that?

AO: The best way to reach me online is via Twitter (@aorobator).

KG: I will say that you probably have one of the coolest last names of any guest we’ve ever had. It’s pretty badass.

AO: It’s Nigerian.

KG: Thank you so much again for coming on the show, Andrew.

DF: Thank you, Andrew.

071: UI UX development with GDE Raveesh

Mon, 23 Jan 2017 05:00:09 UTC

Download directly

In this episode we change the tune and talk with Raveesh Bhalla; Raveesh is a GDE for design specialized in UI/UX.

He starts off by helping us get a good understanding of what UI/UX involves. He then shares his experiences and learnings from having conducted extensive research specifically for Android. What are some good patterns today, what are anti-patterns, what should we watch out for. Listen on to find out more!

Show Notes #

Apps with interesting designs #

Misc #

BuddyBuild is a continuous integration and continuous deployment system built specifically for mobile developers. Thousands of development teams love BuddyBuild because it’s the fastest way to build, distribute and gather feedback for their apps. Give it a try for FREE at buddybuild.com

Contact #

Transcript #

Donn Felker: Let’s hop right into it, folks. Today, we’re going to be talking about some fun stuff related to UX and UI. We have a special guest here with us. Please welcome Raveesh Bhalla, a GDE. Welcome to the show, Raveesh!

Raveesh Bhalla: Hey, guys. Thanks for having me.

DF: For the folks who aren’t familiar with you (particularly with your background in Android), can you give us the Reader’s Digest version of how you got into Android and what you’re currently doing with it?

RB: I got into Android (on the development side of things) back in 2009 or 2010. Smartphones were just starting to take off over here in India, and I wanted to start writing code for mobile applications. I started out with Nokia, and then realized that it was a big mistake. That was a big thing in India for a long time, though.

But after building a few applications, I noticed that I was spending a lot more of my time with the design elements of things, particularly the UX. Slowly, as a result of that, I moved into a design role. I still write some Android code on the side—in fact, I just released an application last month that aids my design work—but that’s only a hobby now.

I just joined an Indian design and development agency called Uncommon, and I’m advising a few more startups on the side.

DF: So you’re like a wild unicorn—someone who can both develop and design.

RB: I actually don’t think it’s that rare. I really think that developers have a huge role to play in design, and they’re already doing that. I think that there are at least a few developers out there who are actually already pretty good at design.

KG: My friend, you overestimate the capabilities of developers. To be fair, there are actually a bunch of developers who have pretty good design tastes.

RB: It’s not just their design tastes, but also the roles that they play. There are other sides of the table that they need to take care of besides just visual elements.

KG: That’s actually a great segue. Before we get into that, though, I had a quick follow-up question. When you started off with Nokia, did you actually have to write apps for the Symbian OS?

RB: Yeah, they used Symbian C++ and the QT IDE. That thing took forever to get the hang of, and I eventually gave up and thought, “You know what? I think I’m just going to write for Android, because that’s in Java.”

KG: What does it say if you actually pick Java as a language over something else? “This is too annoying. I’m just going to go with Java.” That speaks volumes about what it was like.

RB: It was awful.

KG: You mentioned that UX isn’t just about visual design, and I find that fascinating, because a bunch of my friends who are designers also mention that. Obviously, there’s that famous Steve Jobs quote:

Most people make the mistake of thinking design is what it looks like. People think it’s this veneer – that the designers are handed this box and told, “Make it look good!” That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works. – Steve Jobs on design

Could you talk a little about that topic? To you, what is design? What does it mean to you, especially as someone who’s worked as a developer before? You have the unique advantage of translating this mystical world for us.

RB: A lot of people confuse design with art. They think that since they can’t draw or aren’t good with colors, they don’t have a role to play in design. But visuals are just a part of design itself. I look at design as the strategy that you’re using to solve certain challenges that come your way. I almost consider it a science, personally. I believe that good design can be measured, and that you can quantify what is and isn’t working. It takes a lot of logic, which is why I believe developers can actually make pretty good designers.

KG: Usually, I try to think of it as the difference between UI (the art, the illustration, and the other visuals that you see) and UX (the overall experience). Does the science aspect that you mentioned play more heavily into UX, or is there a conjunction there? Is it something that you can even demarcate?

RB: I think it plays slightly more into the UX side of things, but it does play into UI as well. The point is that you’re essentially measuring a certain design change (for instance), quantifying whether a user is able to do what you wanted them to do. That doesn’t necessarily mean that you should do the old Google A/B tests with 50 different colors of blue for links, or something like that. I think that’s a little overblown.

KG: Are there are any other misconceptions regarding design that you think are important to iron out at this point?

RB: Design needs to be thought of as strategy itself. It needs to be at the core of a product team. For example, most of the startups I advise have a product team that decides on what needs to be solved and how to solve it. Then they go to their designers and tell them, “Okay, we want you to design the UI for this.” But I think that designers need to have a seat at the table on the strategy side of things.

KG: In other words, right where you’re building this product to begin with—at the stage where product managers are doing their whole business evaluation of the application’s objectives?

RB: Exactly.

DF: I completely agree with that statement. It seems like at every company I’ve consulted with, an idea comes down from the higher levels to designers too late in the product life cycle. Then they feel like they’re just applying a coat of paint on top of something, solely to make it look better.

But if design was brought in earlier, management might actually see, “Hey, we can do this thing a little bit differently, and it’ll make more sense to users than the wizard flow that we’re building.” I think that’s a great idea, and I completely agree that we should be bringing designers into the fold a lot earlier in these conversations.

Now, how can you tell by looking at an app if it has a good user experience?

RB: I won’t necessarily be able tell immediately. I mean, I can probably point out a few things that are done wrong if they just stick out, but I think that good UX is something that you realize over a period of time. Quite often, you don’t even notice it because it feels so natural, and you aren’t paying too much attention to it.

For example, a lot of applications will do a lot of animations (and things like that) just to wow you. Over a period of time, though, you’ll probably get tired of them, or maybe they don’t have as much impact as you might think.

KG: Do you think that some folks have gone overboard in the Android world today? I don’t want this to be a leading question, but do you think that folks have gone overboard with Material Design, or do you think it’s not being used enough? That’s one interesting conversation that I’ve had with quite a few folks. Now, they’ve always said, “Material Design is great,” and I feel that way too. I don’t see it as being overboard—but then again, I am an Android user, so maybe I’m being biased. What are your thoughts, as someone who works in design? I imagine you have a slightly more objective outlook on that.

RB: I think that a lot of people get the original goals of Material Design wrong. If you talk to a lot of people, most of them think, “If we do Material Design, we need to have a floating action button, a toolbar, and stuff like that.” I don’t think that’s how you need to think of it. Go back to what Material was originally supposed to stand for: trying to bridge the divide between digital interfaces and physical products; taking some of the affordances that we have in physical products and applying them to digital products. Essentially, they wanted to add shadows and make the way things move feel very natural.

Because of that, I do think many people get it wrong, in the sense that they’ll put a floating action button in a place it probably doesn’t need to be in. I think that Google also missed a big beat over here. The original Material Design guidelines talked about a floating action button as a promoted action, and I felt that that wording was imperfect.

I also think a lot of designers feel very constrained by Material Design. As a result of that, we’re seeing very homogeneous designs. I think that good designers try to step away from that, understanding that (while there are guidelines) it absolutely makes sense to deviate from the guidelines every now and then.

KG: One of the easiest ways to help someone understand good design is to point them to applications that do it really well. Can you point out four or five applications have good design in general (not necessarily just Material Design)?

RB: I think that one which a lot of people have probably used is Todoist. It’s a todo application which I absolutely love (and I’ve tried out a bunch). It feels like a very standard Material Design application, but one of the things that I really like about it is a little feature called “karma points”. It essentially promotes being a little more active in terms of keeping track of your tasks and marking them off. They use this small indicator, which points up or down in terms of your trend, gamifying getting your tasks done.

Another app I really like is Foursquare Swarm. There’s a little known feature in Swarm that indicates when you’re on a streak. I saw someone who did a 52 week streak of checking in at a gym, and I tried to do that this year as much as possible. I got up to about 44 weeks, but couldn’t go further with that, but I still got 44 consecutive weeks of going to the gym!

KG: That’s pretty good. Donn has a three year record.

DF: Not lately.

RB: Another one that I just came across is this little app called Enki. It’s actually meant to help improve your programming capabilities. They also have a small little gamification thing which lets you know how many days in the past week you’ve spent five minutes in the app, going through one of the workflows. Also, they position that by telling you that all you have to do is spend five minutes in the app. That convinces you to take that much time out of every day.

One that I came across recently, while doing some research here in India, was called Fastfilmz. I love this because it’s completely different from what you’d expect from a Material application. Fastfilmz is a startup based out of South India which does movie streaming in three of the languages spoken here.

They have a completely different UI. One of the things that I’ve noticed during my research on Indian users is that nobody here really uses search. So, their entire navigation is actually based on movie stars, because one of the major reasons that people watch movies is to keep track of their favorite stars.

During the stream itself, they have a couple of buttons on the screen that you can tap. One of them essentially mimics a whistle for you, and the other displays firecrackers all over the screen. If you’ve ever been to a South Indian movie screening in a theater, you know exactly what I’m talking about. People over there go nuts at times with firecrackers and other stuff inside. No one cares about fire codes at all. Fastfilmz just replicates that behavior for people on the phone itself.

KG: I’m chuckling because I know exactly what you’re talking about. Are you used to whistling in movies, Donn?

DF: I mean, it’s going to get a little rowdy in certain theaters in New York City, but throughout the majority of the US, if you go to a movie theater, people may clap when certain things happen in a Star Wars movie, but they generally just sit there and watch them. You don’t hear a single thing. Apparently, that’s different in India. What’s it like over there?

RB: It’s very dependent on the region and the stars themselves. Bollywood films get it for Samachar, for example, but most of the other movies don’t have it. I’ve never particularly experienced this, but I’ve heard of a lot of people who have.

KG: Back when I was in India, there was an extremely famous movie star named Rajinikanth. He was from South India, and he was basically our equivalent of Chuck Norris. Some of his movies are outright crazy. He’ll catch bullets and shove them back at people! But people have a devotion towards him because he’s also a good person in real life. Even though people know that what they’re seeing is completely bizarre, they’ll go to his movies just for the experience of enjoying it with other folks and reveling in the ridiculousness of it all.

RB: It kind of signifies how big their user base is overall. You could never expect NetFlix (for example) to do something like this.

KG: It makes sense that NetFlix doesn’t do it, but Fastfilmz does. It’s all about that target demographic.

That brings up another point, then: if you’re in a startup that’s doing well, and you’re expanding to different countries, should you localize your app specifically to every single country that you go to? I don’t mean the technical localization that most of us developers are used to. I mean, do you tailor your app to the specific countries that you’re moving toward? For example, does the Uber app need to be completely different when used in India, China, or the US? What are your thoughts?

RB: I think it makes sense to make that investment once you know that a market is becoming important for you. For example, I know that a bunch of companies are starting to do a lot of research in India to understand the market better, now that they’ve determined that that’s where they’re going to see their next big growth. Facebook wrote a great post recently with their best suggestions for international research. It doesn’t need to be a completely different app, but I wouldn’t be surprised if there are a few things here and there that need to be changed.

DF: So, as we move forward, if I want to mimic some of these applications that have good UIs, UX, and so forth, do I need to worry about building a particular team in a certain way to accomplish that? If I do, should I just start with engineers, or should I try to get a designer first? Is there any particular way that you advise companies to structure their teams in order to make sure that they nail their design and UX?

RB: One of the benefits of the last few years has been that a lot of startups tend to have a design founder right from the get-go. That means that design has a significant voice at the strategic level itself. But if you don’t have that, I do think it makes sense to hire a designer, if you can. If you can’t afford it, I’m not going to stop you.

Having said that, the biggest investment you can make early on is in research. You don’t necessarily have to hire someone else to do it. You probably can pick it up yourself, at least to a degree. There’s a book by Steve Krug called Rocket Surgery Made Easy about doing user research yourself. I haven’t actually gone through it yet, but some people whom I respect recommend it a lot.

One of the strategies that I recommend early on is to understand your target users, see what kinds of applications they’re using, and keep your design as similar to those applications as possible. For example, I worked with a startup recently that’s designing a chat app for customer care. What I essentially did (in the early versions of the application) was copy WhatsApp’s design and behavior, except for adding a little few things here and there which I felt polished it a little bit more (like typography).

KG: You said that user research is pretty helpful early on. How should I go about this specifically, as an engineer? Since most of our listeners (in the end) are engineers/developers, I imagine they’re interested in knowing how.

DF: Just to add on to that really quickly: in other platforms (like the web), there are things that can kickstart you into getting a decent design and UX (like Bootstrap, Foundation, and so forth). Do you know of anything similar in the Android world that developers can rely on?

RB: I think you can rely on the Material Design guidelines themselves right now. They give you at least the basics. After that, it’s going to be largely a case of going through the guidelines and being aware of them.

More to Kaushik’s point about what he should do, what I’m actually going to say is: don’t get into a rush with code. I would highly recommend taking a step back and ensuring that you spend time on your designs while they’re in sketch. Create some prototypes for them and test them out in InVision. That’s how you should probably go about it. There’s a little quote from IBM’s research wing which talks about how every dollar spent on design and research can save you about ten dollars in development costs and a hundred dollars in post-release maintenance. I highly recommend remembering that.

The process that I would recommend is something called a design sprint. Google talks about it quite a bit. It essentially gets you to really understand your users, do a lot of prototyping really quickly, and test it out with them—all inside a week—so you’ll know whether your design is actually working.

KG: So can you talk a little about design sprints? For example, if Donn and I were to sit down and say, “Let’s build this thing together with a design sprint integrated into our workflow,” what would that look like?

RB: The first day should be spent doing interviews. Ideally, I’m talking about interviews within your team, but if it’s just the two of you, you’ll have to figure out who else you can do this with. In these interviews, you’re trying to create a user journey map, where you put the user on the left side of it and the goal that they’re trying to reach on the right. Then you kind of draw a map of how they’re getting to this goal currently—through an existing product, through a bunch of products, or whatever. In this map, you essentially need to find where the pain points are for the user. The suggestion is simply to fix those pain points. So day one just shows you the opportunity.

After that, you try to go as wide as possible. You sketch out a bunch of different ways that you could potentially solve the problem. You’re just doing very rough designs yourself, using pen and paper—not even touching your laptop yet. Then you share these between the two of you or the rest of your team, and you talk through each thing, determining what seems to be a positive idea and what seems less strong. Then, on day three, you essentially create a storyboard, where you agree upon how you’re going to solve this problem. Once you have the storyboard, it becomes a lot easier to create your designs and make a prototype, since you now know exactly what designs you need to create. That’s the remainder of days three and four.

Day five involves finding five people whom you can test these prototypes out on. Take them through it, and see whether or not it’s working for them. Try to ask them questions which aren’t very leading. Don’t ask them, “Is this the best design you’ve ever seen?”

KG: “Is your mind blown by this design? Is this the best thing you’ve ever seen in your entire life?” Those are probably not great questions.

RB: One of the most common mistakes that people make in user research is asking people whether they would use something that does this. Particularly if the feature is free, users will almost always say yes. It doesn’t matter whether they would actually use it or not. What you need to do is glance at their behavior, and then understand from that whether it’s a good fit for them or not.

KG: That makes sense. The user journey maps you mentioned are actually pretty fascinating. Even as you were saying it, it made sense to me. If folks are interested in coming up with an application design or something, I imagine that that could be pretty useful.

You said that you studied about different patterns. Can you talk about that process? What were your findings, specifically on Android? Did you discover any patterns of usage when you conducted these studies on Android users?

RB: In the second half of 2016, I did a lot of research in India, a part of a demographic called “the next billion users”. It’s not really a marketing term, though it comes across like that. Cisco has data pointing to an increase of about a billion internet users between 2014-2019. As you’d imagine, a lot of these users are in India itself, where internet penetration is pretty low (but it’s picking up a lot).

Companies like Google and Facebook, for example, are promoting this a lot, but they focus on the technical side. One of the things that I realized was that these users have never used a computer in their lives. The first computing device that they’ve used is probably the smartphone that they picked up. So far, they’ve only used a feature phone. So, one goal of mine was to test out a few very different, but common patterns (or gestures) that we have—things like search, buttons, and swipes.

I gave these people very easy goals to test out with prototypes, whether or not it works for them. That’s when I realized, for example, that search is something they’ve never used. They have no idea, because (since they’ve only been on feature phones) they’ve never really performed a search. How I recognized that was by giving them a fairly standard dialer application and asking them to dial the number of a contact starting with the letter R. Every user would scroll down to get that, instead of tapping on the search icon right there in front of them. Then, when you talk to them about it, you realize that they’ve never been taught the concept.

Another thing that they’ve never really done is horizontal swipes. Again, that’s something that (on Android in particular) we take for granted with the top tabs themselves. When the argument of top nav versus bottom nav comes up, we say, “Hey, you just have to swipe to get to the next one.” But these people aren’t used to it. Even when they figure out that this is a tab interface, they tap on the ones on top instead of swiping through it.

The buttons are especially tricky, because we take it for granted that people will understand the icons that they have in front of them. But the thing is that icons are sometimes not really clear to the person. We sometimes joke about how millennials have no clue what the save icon is, since they’ve never seen a floppy disc. But these people have never seen a mouse in their lives. Communicating these things to them becomes even more challenging at that point.

Simultaneously, a lot of these people are illiterate, which means that they can’t even read their own regional language, and certainly not English. So buttons in particular get very challenging for these people.

KG: And these folks are still using smartphones today, even if they can’t read the language?

RB: The people whom I researched about were specifically people who had never used a smartphone. They were just about to, though, because they had signed up to drive for Uber. I had the opportunity to go there and interview them before they got their smartphones. A lot of Uber drivers in India are new to smartphone itself, and you can see how they’re struggling with much of the interface. For example, I saw one driver on his first day who had actually missed out on cash from his previous ride because he canceled the ride by mistake instead of ending it. He kind of held onto me and said, “Please, end this ride for me.” They have a button to end the ride that you have to swipe across, so he swiped across it. Then every next button that came up after that, he tried to swipe across. When it asked him to rate me, he tried to swipe across to give me five stars instead of just tapping on the fifth one. When it came time to submit, he again tried to swipe across the button instead of simply tapping on it.

KG: Wow, that’s fascinating. He’s straining his model in real-time to understand how this interface works.

RB: The thing that I noticed is that these people need very clear cut affordances to make them understand what they need to do. The swipe button at the beginning had a color gradient that comes across the rectangular button, and he didn’t quite get that. It’s very possible that in the bright sunlight, he didn’t even notice that glare going across. Then he was trained to swipe across, so he just kept swiping across every button he sees.

KG: I didn’t even think about that.

Following up quickly on something you mentioned (I’m pretty sure everyone is interested in this): you know how Google has finally added bottom navigational tabs officially to Material Design as well. So (you know where I’m going with this) what are your thoughts about adding bottom tabs, because this is something that comes up all the time?

RB: It’s one of those things where I’ve come to accept it recently. It makes sense if you have a hamburger menu with options hidden in there. Ultimately, the entire reason for the bottom nav is that the devices are getting bigger. We’re at a point where the average device is about five inches, and it starts getting really difficult for users to reach the top. In that sense, I’m okay with it. I do think that you shouldn’t just say, “I have to add a bottom nav because it’s the flavor of the season.”

KG: So are there any interesting quirks or differences in behavior that you’ve noticed when you’re designing for the next billion? I know that you brought that up in your presentation at DroidCon NYC. You also mentioned the studies you did on folks who were signing up to be an Uber driver. Is there anything we take for granted as Android developers that probably should be highlighted?

RB: As an Android developer, the biggest thing to keep in mind is that a lot of these users don’t download your apps from Google Play. I don’t necessarily mean that they pirate your stuff. The tend to get even free applications through Bluetooth from their friends. There are a few applications which are really popular over here called Xender and SHAREit. They essentially allow you to rip out the APK of your current application and share it over Bluetooth or local WiFi with somebody else.

KG: That disturbs me on so many levels.

RB: I came across this with the messaging application that I’ve worked at. One of the users was complaining about how he was unable to receive the messages, and I asked him what device he was on. He was on a Nokia X—and I was thinking, “How did you get the app?!” They only put the app on Google Play, and it requires Play Services. That’s when I came across these.

DF: How does this work? How are they getting these apps?

RB: Xender and SHAREit essentially allow you to rip out the APK of an app that you have installed, and you can just keep sharing it.

DF: So I just walk up to you, and it helps us share the app via NFC, Bluetooth, or whatever?

RB: I think it establishes a connection over Bluetooth or local WiFi.

DF: And that’s a completely normal thing in that region?

RB: Exactly. It’s a complicated market. I don’t have the data to back this up, but a few people have pointed out to me that Chrome only has a 50% market share of mobile browsers in India, despite the fact that Android itself has a 90-95% market share.

DF: Wow. What other browsers are these folks using?

RB: There’s a browser called UC Browser that’s very popular over here. It’s primary goal is to boost data saving, because a lot of people are on 2G (or even 3G) connections with very small packs of data—maybe 300 MB per month.

KG: I remember that Opera had an app called Opera Turbo which tried to minimize data usage.

RB: I used to use Opera Mini back in my Nokia days. I think it’s still around, but UC Browser is really big in the market right now.

KG: The other thing you mentioned scares me, though. Sharing of APKs… I imagine that it somehow figures out the architecture? What if it’s an ARM architecture that’s completely different? What if it was built specifically for one architecture? That boggles my mind. I imagine that the app accounts for that. Play Services are a problem. The other thing is that I imagine these are rooted phones? Otherwise, how do they pull the APKs, since this is an external APK, not their own application? My mind is already hurting from thinking about this.

RB: I’m just going to make it worse for you: users in India do not tend to update their apps as quickly as you would expect. Once you put an app out there, it’s going to stay around for a very long time, installed on these people’s devices.

KG: And shared across multiple devices, so it compounds.

RB: Be very careful of what you push out.

KG: Folks, no bugs. Ever.

DF: There are so many folks out there included the next billion, so I’m just going to stick to the region of India, which is where you have the most experience. What kind of devices do they mainly have? If you had to guess (I’m not looking for exact data here), how many folks are currently using a smartphone, versus a regular old feature phone?

RB: If I remember correctly, the number is around 300 million smartphone users. The Internet Association over here points to about 400 million Indian internet users. A lot of us don’t believe that to be true. Facebook shared some data recently about it’s 170 million users in India, so I think the number is probably going to be closer to 250 million or so. What could be happening is simply that these people are internet users, just very, very infrequently.

DF: If I’m designing an application, taking into consideration these next billion users and all of the things that you’ve talked about—from folks swiping buttons because they’re still learning, to people being introduced to mobile phones in general—what’s the lowest common denominator that I should be designing for? Are there any tips and tricks you can provide to developers so that they can give their app the best chance of being user-friendly to that next billion?

RB: I think a lot of us take pride in not having tutorials in our application. We don’t want any coach marks or stuff like that. You need to realize that these people are trying to pick up the design of your application itself. Especially if you’re using gestures, something that might seem easy to you is probably not the so easy for other people, even those who have regularly used smartphones previously. Providing menus, suggestions, and stuff like that helps.

Of course, that also means that you don’t just do one tutorial. What I’ve found from my limited tests so far is that it really helps when tutorials are done in context. What you want to do is design your application in a way that promotes performing a certain action on the first try.

For example, there’s an application in India called PhonePe. It’s a new application for transferring money from your bank account to another person’s bank account using a pretty popular framework over here called UPI. They’re trying to promote people at least making their first transaction, because getting them to use their phones for banking is pretty new here. So they’re saying, “Even if you just transfer 1 rupee, we’ll give you 50 rupees back.” A lot of people are doing that just to get the cash back, but the huge power of it is that it gets them to realize how simple it actually is to do this. Once someone experiences your application this way, it gives you a better chance to bring them in the next time.

KG: They’re betting on convenience being the thing that wins them over eventually.

RB: Exactly. The other side of it, of course, is the fact that it’s essentially going through the old Dropbox referral system. They’re not spending money on user acquisition through Facebook ads or something else. They’re just giving it to the users themselves.

KG: A quick follow up question to that: you mentioned that, in order to maintain that high level of quality, you sometimes need to do in-app tutorials and a wizard-like interface. Are there any examples you’ve seen of applications that do that pretty well?

RB: The problem is that I can only point out the ones that do this really badly—the ones that give you all of the tutorials right at the beginning, and you’re just blindly skipping through them.

KG: That’s a great point. When I think of the simplest implementation of what most folks call the “new user experience”, usually it just stores in your shared preferences, “If it hasn’t been activated before, load this new user experience.” What’s going to happen if it’s a new device? Essentially, you’re just going to have four of these new user experiences popping up, one after the other. A good way to handle that would be to actually provide it with context. When folks use that feature, that’s when you pop it up for the first time.

RB: One thing I can think is called “activation”, where you’re trying to get your user to harness the real power of the app. Twitter does this really well when they’re trying to get new users to follow a lot of accounts at the beginning. They’ve determined that when people follow a lot of users, they stay engaged for longer. Previously, they would just push up certain accounts, but now they make you point out what your interests are and try to make you follow accounts based on that. It’s not really coaching, but it gets a user to invest in your application early on.

KG: Actually, that’s a better definition of what a new user experience would be: “How you get a new user to ‘get’ your product.”

Stepping back from a little from user experience, since we have an opportunity to actually talk to someone who understands both engineering and design, what are some common design trends that you think work well? Or even if there are some design trends which you don’t think work well, maybe you can let us know. Many times, we’ve noticed that a lot of the Android design aesthetic is suggested by the developers themselves, because designers tend to be iOS-focused. That’s just the nature of how things started. Many a time, I’ve found that the suggestions for Android applications come from the engineers themselves. So what are some design trends that you think work well, and some things that we should be aware of?

RB: On Android in particular, a good Material Design app is a given at this point. Users now expect it, so you have to meet those guidelines to have an application which does even half-decently.

A new trend that’s taken over this year is something called “complexion reduction”. The focus of this is to remove as much complexity from an interface as possible. That means a lot more white spaces and a lot less color, and tends to mean a lot more line icons and things like that. The point of it is to get straight to the content itself. It’s used by applications like Instagram, Medium, and Uber, and it works really well. What happens is that point where you really want users to focus is where most of the color and other stuff lies, so it points their attention over there. Human beings have a desire to just reduce the complexity of anything that they see to its bare minimum, and this fits in right there.

KG: Interesting. Would you say this is similar to iOS 7’s flat design, where everything was just a line or a box? I assume this is a little different from that.

RB: Flat UI essentially means that you don’t have a z index. You might have fake depth in the sense that users may perceive a background and a foreground, but you’re essentially completely flat. Complexion reduction doesn’t worry about that. You can still have the drop shadows, but you’re going to use them a lot more carefully. For example, you would probably not want a Card UI with shadows in a simple list view. That just adds color on your screen when it doesn’t need to be.

KG: As Android developers, we don’t necessarily get the time to think about these things in such detail, so this was super helpful. Thank you so much, Raveesh.

RB: You’re welcome.

KG: If folks want to reach out to you and throw in some more Android developer questions, what’s the best way to do that?

RB: You can reach me at Twitter. I’m @raveeshbhalla.

KG: Excellent. If folks want to draw out on your startup experience and all of the wicked designs you’ve been working on, Donn, how do they do that?

DF: You can reach me at @donnfelker, which would be the best way. But Kaushik, how do folks get ahold of you and your wicked design skills?

KG: I don’t know about wicked design skills, but if you want to reach out to me, @kaushikgopal is usually the best way. Thank you folks for listening, and thank you so much for joining us, Raveesh.

070: An honest discussion about Realm

Mon, 16 Jan 2017 07:56:12 UTC

Download directly

In this episode Donn and Kaushik have an honest discussion about Realm (a client side database). Donn has worked pretty extensively with Realm and even consulted for their Android platform previously. But Kaushik has only recently tried it out on a production app.

In this episode they have an honest and frank discussion about using Realm, the advantages, the disadvantages, the gotchas and if it makes sense to use a database like Realm as an Android developer today.

Show Notes #

Misc #

Sync stuff #

Github issues tracked on Realm #

Resources #

Contact #

Transcript #

Donn Felker: So, Kaushik, we don’t have anyone on the show this week.

Kaushik Gopal: No, we don’t, so we thought we’d catch up on these chats we have all the time. We keep telling folks, “Donn and I talk about this all the time, and one day, we’ll do an episode about it.” This is one of those days. We’ve decided to capture one of our chats and push it out as an episode.

DF: Yeah, for folks who don’t know, we usually have chats after we hop off the call for our recordings. We’ll intend to chat for about five to six minutes, full of catching up, saying “Hey, I’ll do this and you do this,” and other follow-up stuff—but then it turns into an hour-long chat about technology, and we think, “Well, that would’ve been great to record.”

KG: That has happened way more often than you’d think.

DF: Exactly, so we’re hoping to capture more of that today. One topic that’s come up a few times in those chats is Realm.

KG: Yeah. Some time back, we had Christian Melchior on the show, and we talked about Realm in great detail.

Recently, my team at Instacart started to experiment with Realm for one of the apps that we make. I know that you have a lot of knowledge about Realm and have worked very closely with that time, and I had a lot of questions, so I pinged you a bunch of times. I also pinged the Realm team a lot. Several extremely interesting things came up, so I thought, “Hey, why not just hop on a call with Donn and see where it goes from here.”

DF: Definitely. I’ve been using Realm for a while. In fact, we first talked about it back in one of our first few episodes. We mentioned it in the “Awesome Picks” section we used to have. Ever since then, I’ve been highly interested in it, because I come from with Rails (and a few other programming languages that have some kind of active record system built-in), and I’ve always wanted that functionality with Android. I’ve tried other ORMs, but none of them ever felt like they were “it”, even though they did a good job. I never felt like, “This is awesome!”

But right out of the gate, I was attracted to Realm. Like you said, I started working with it for a while, building it into various apps. I recently released another app that’s gaining a lot of traction, and it’s all Realm-based.

For me, it makes sense to use it because I like it and I’m very familiar with it, but what got you thinking, “You know what? It’s time to start evaluating other data persistence mechanisms”?

KG: At least in the app that I experimented with, we started out with a flat JSON structure. Any persistence that we needed was serialized into a JSON file and stored in the external storage area. This was done for many reasons. Historically, when we started out, we decided that we didn’t want to use a full-blown database since only a few models—the user preferences, and maybe one other object—were persisting. In those early days, our app was also heavily driven by a web-based architecture. Essentially, it served as a shell for a glorified web service. It wasn’t a WebView, but it used a lot of APIs. Pretty much everything came down through APIs. Essentially, every screen was an API hit, because the state was managed on the server side.

For the longest time, that structure worked out pretty well for us, but it got to a point where the app was far more sophisticated than that. Also, there’s been a shift recently towards thinking about mobile devices as mini computers, because they’re pretty powerful. You can do some very cool stuff with them. So, to get the best experience, we wanted to move toward doing everything on-device.

The flat JSON structure we used worked pretty well, if you think about it in terms of performance. Realm has amazing performance compared to SQLite and a bunch of other alternatives. That’s one of their tagline features, in fact. They say, “Hey, we’re way more efficient than any alternative you can use.” For the most part, I think that’s completely true. But in terms of performance, I still think that a flat file structure is comparable to (if not better than) Realm. Again, there are many caveats. It depends on how deep your structure goes and how complicated the serialization is, so take that with a grain of salt. But at least in my experience, I’ve found that they were similar in terms of performance.

So what really won us over was when our objects got complicated enough that there were two relationships between them. There were nested objects. To give a simple example, think of a chat conversation, which has chat messages. Those messages might have small sub-objects—say, different kinds of messages. Anyway, it was getting to the point where relationship queries were a little more difficult. When we used a flat JSON file structure, we essentially had to write the entire ORM layer ourselves. We had to write queries, and really dive into serializing those objects, and filtering them with list queries. It was getting a little crazy, and we were thinking, “At this point, we should be exploring a database for our convenience.”

I know you talk about Realm a lot, so I said, “Hey, this is a great opportunity, because we don’t want to lose the advantage we have in terms of performance.” That’s what got me started.

DF: Yeah, I think it’s important to note that there are ways to both use and misuse various tools. You can use Realm incorrectly and make it slow. You can use SQL incorrectly and make it slow. On the flip side, you can optimize the various SQL ORMs to be very fast. In other words, we’re not trying to say, “You have to use Realm!” Use whatever tool is right for the job. If you’re familiar with SQL, and you want to use a SQL RxJava client, do it. If you want to use an ORM, do it. But if our conversation sparks your interest, then give Realm a try.

KG: This is one of the reasons that SQLBrite was created. The developers got comfortable with writing SQL queries, so they added that layer to make it reactive. That’s also gotten a lot of traction.

So, what was your tagline feature? What made you think, “Okay, this is why Realm is really cool”? Let’s talk about what really won us over, in terms of development.

DF: The first thing that really struck a chord with me came a couple of years ago when I looked at the first example: I would be working with straight Java objects. I didn’t have to write in another language. A lot of times people who are familiar with both SQL and Java will think, “They kind of work together.” Not really. There is an adapter built between the two systems, but SQLite runs on its own engine, and then Java code runs your Android application. You still have to write SQL (Structured Query Language) code to talk to the database.

With Realm, I don’t have to do any of that. I just say, “Hey, here’s an object” and use the .save() method—and suddenly, everything is in the database. If I want to get it back out, I say, “Hey Realm, go get all objects from the ‘person’ class, and find the guy whose name starts with ‘Donn’.” Then it gives me that object back, and I can work with it. And I thought, “Well, that’s awesome.” That was the initial spark that got me going.

What really solidified it for me was one of those side projects that we all have. I fired it up and said, “You know what? I’m going to try Realm.” It was a simple to-do list app, so I said “Alright, I need a database,” and I created a couple of objects. Then I needed to save them, and later retrieve them. I thought to myself, “I spent just 15 minutes learning this and setting it up, and I’m already saving data. I don’t have to do anything else.” That’s what blew my mind. It was way more productive than building a SQL table, making sure to hydrate, setting up ContentValues, and deciding whether to use a content provider, a loader, or something else.

So what interested you? I mean, I’d already been in your ear about it before, but other than that, what attracted you?

KG: The simplicity was definitely a big win. Like you mentioned, the fluent interface made it so easy to work with queries.

DF: For folks who’re wondering what he’s talking about, when you query a Realm database, you basically say, “Hey Realm: go look for the people in the person class. I want you to find all the people whose name starts with ‘D’.” You literally just chain these operations together, and you get back a list. And it’s not just a List<T>. No, it’s a RealmList, which is a souped up version of List<T>. It has a bunch of extra features for Realm itself, so you can do updating and so forth. But it just makes it so easy to query.

The other thing that I really loved about Realm when I first started was that everything was done on the main thread. I’m sure villages are burning down right now, as I say that! But it was so fast, and they said, “Look, you can just run this on the main thread, because it’s fast.” We can get into why that is shortly, but I tried it, and it was so fast that I never had any problems. They now have an asynchronous API, which can do things on a different thread and return them to you, and their advice is to use that if you’re concerned with it not being fast enough. But, to make a long story short, I was blown away by how fast it was.

There’s also the Realm Browser. Realm is pretty popular in iOS, so let’s say that you go to a company, and they say, “We have this iOS app, and we need you to create an Android version.” That happens all the time. Well, if they’re using Realm, they can actually open the Realm file inside of the Realm Browser (which only exists on macOS right now), and use the file to create the basic Java classes for the app. The browser will generate all of the classes for you, so that can easily share modeling between the two different apps.

KG: I read about that, but I didn’t realize that that was the benefit. That’s pretty slick.

DF: You’re not really sharing between two different platforms (you’re just sharing the model files), but it helps you get jump-started. Android and iOS developers are probably going to model things a bit differently, but if you’re building an app with a lot of models, that’s still going to help you jump-start your application.

So I saw all of these things, and I thought, “Wow, this is pretty freakin’ cool.” I didn’t even learn about the reactive features that really make Realm shine until I actually started working with their team. We’ll get into those shortly.

KG: That’s definitely something I want to talk about, because it’s essentially what won me over. I basically said, “We’re definitely going to Realm because of the reactive architecture.”

But to step back, you mentioned the fluent interface and queries. Now, some folks might think, “Is it really that tricky in SQL? Is there really any benefit to that?” There was one query that I wrote that made me think, “Wow, this is so much easier.” When you have a list and you want to negate queries, you use not equal to. It’s a very common condition. For instance, “Pick all the messages that aren’t read,” or something along those lines. When you want to run the not query in Realm, it’s done beautifully. I was really surprised, because all you have to do is throw a .not() on any condition inside a .beginGroup().

If I had to implement that back in my file structure days, I’d have take that list and run a filter on it. I’m not saying it’s difficult to do, but Realm makes it ridiculously simple. In the end, that’s what we want. We don’t want to spend our time filtering lists, taking lists, converting between arrays and lists, and making sure something is an array list. We shouldn’t have to deal with such simple things.

DF: Like you said, you can filter your code, but you’d end up checking nulls and doing sorts of other stuff. You actually end up with quite a bit of (very simple) plumbing code to get the data that you need. Like you said, if you’ve set your column width to be wide enough in Lint, you could (quite literally) fit the whole query for Realm into one line of code. You just say, “Realm, get me all of the people whose age is not less than 5.”

KG: Their fluent API works really well.

When you brought up the reactive architecture, you said that RealmLists are just a really souped-up version of list<t>s—as in, they have some crazy features. This is another thing that won me over, so let’s spend some time on it. It’s really cool, though I don’t think it gets much credit in the documentation. When I actually saw it working, I thought, “Whoa, this is mind-blowing.”

DF: I’m not consulting with Realm anymore, but I was at this time last year. And last November or December, I read through the documentation, talked to a few guys on the team, and learned about RealmLists. And I thought, “Whoa! This is actually the really sweet stuff in Realm, and nobody really knows about it.” They call it the “reactive architecture” or the “auto-updating objects”.

I’m going to give an example here. Let’s say that I have a list of ten person objects in a database. Then I make a query that says, “Hey Realm: go get me all the person objects whose age is greater than 18,” and I get back a RealmResult with 5 people in it.

Now, for some reason, let’s say I have an Android IntentService doing something else in a different thread in the background. Maybe it’s doing a pull from my server to check for new items or respond to a push notification. All of a sudden, it says, “I need to update some data in the database,” so it pulls down some stuff from the API and starts updating the Realm database. Suppose it adds another person to the person table (if you want to call it that). That person is age 30, so he or she should be included in that query now.

Behind the scenes, Realm updates the list for you. It’s actually updated on every iteration of the Android run loop, so you can attach a change listener to an object, a RealmResult, or even the whole Realm database itself, and say, “Hey, any time this data is updated, call me back.”

KG: I didn’t really understand this until I saw it happen. Folks, you can attach listeners to your whole database. You can say, “Any time anything in my database is updated, notify me.” That’s crazy! Whether you should really be doing that is another issue, but the fact that it allows that is pretty cool. You can also attach a listener to this object—say, a “persons” table: “Anytime anything changes in the persons table, send me a change notification.” You can even attach one to a query. You can say, “Hey, I’ve executed this really complicated query where I’ve negated all of these conditions and get a list back. If something in that set of elements changes, send it back to me.”

DF: Yeah, it could be an object getting updated, a new object being inserted, or another being deleted. It’ll say, “Hey, something has changed in this query result, so we’re going to call you back, and you can do something with it.” It’s completely reactive. You aren’t pulling the database. Instead, the database itself is actually telling you, “Hey, this changed. Go do something.”

KG: When I heard about this in a casual conversation, it didn’t really hit home. I thought, “Oh well, I get that with RxJava anyway. I mean, I can build that architecture myself, so why is it really that amazing?” It took me some time to understand why it was so cool.

DF: One of the reasons why it was so cool to me was that I could actually create essentially a unidirectional data flow application. For example, let’s say that I’ve made a kiosk application that’s running in the mall, showing data about how many people are currently in the building. As they walk by a sensor, it updates the data in the database, and everything happens in the background. Your application doesn’t need to do anything. It just respond to these notifications. All of a sudden, everything is super reactive.

On top of that, if you’re just using the core Realm concepts and you want to use something like Rx, you can. They actually have Rx bindings. Have you used them at all yet?

KG: Yes, those are basically what I use, because I’m very comfortable with Rx. I try to switch an element morphing to Rx, as a personal preference, because I understand it decently well. I feel very comfortable with it because I understand the things that happen in it.

The interesting thing about this is that you can attach to it as a change listener or to the first-party bindings (as you said), so you can switch directly to Rx and still get all of these benefits. The reason I think that’s interesting is because if I did have to implement this in Rx—which I could totally do—the complexity arrives in two levels.

I’d have to keep executing the query. Otherwise, how else would I know that the database had changed? Alternatively, I could use another option, like SQLBrite or StorIO.
Secondly, I might have to use something like a Subject, which (again) you can do if you understand Rx well enough, but it’s still boilerplate that you have to write manually.

These are both things that you get automatically, for free, by using Realm. The first-party bindings are as simple as adding .asObservable() Boom! It’s converted to Rx. It’s funny that the example you gave was so similar to what I wanted to achieve, which pushed me toward using Realm in the end.

At Instacart, we had this chat conversation model. As our customers are navigating and doing things on their screens, if they let us know about a change that they want made to their order, it’s extremely important for us to get this to the shoppers. So we basically had a shopper/customer model: we want the shoppers to immediately see any customer notifications.

I’m not going to go into the details of the business logic, but it was extremely important that, no matter what activity or screen shoppers were on, that message needed to surface immediately. That was ridiculously simple to implement. All I did was create a RealmObject for the chat conversations, and any time it updated, it would know immediately and pop up the unread indicator. All I did was write one-time logic to query the model, and then I said, “Hey, listen to this model on the screen.” Boom! I got that for free on every screen.

DF: I think you mentioned this already, but I want to make it very apparent: if you’re querying Realm and you want to get an Observable back, you literally just add a method on the result that says .asObservable(). It gives you an Rx observable, and from then on, you’re off to the races with Rx.

KG: That was really compelling to me, because having to implement this by hand is pretty tricky. But there were some other things that I found interesting. This is a little more meta, but the way they do their development really impressed me. Realm is entirely open-source, and they don’t just do that as a way to get brownie points from developers. As I got interested in Realm, I started to poke around in the code and the GitHub issues to see how things were done. There are some things in those issues which are still lacking in Realm, and we’ll get to those shortly. But any time I had a doubt, I would do is hop onto the GitHub database and look around. It’s impressive how responsive the core team is.

In fact, that’s another thing I wanted to talk to you about. What are your thoughts about the core team and how they do their open development? You’ve worked firsthand with them, and I’ve seen a couple of your comments in the database. So, how has that been?

To me, it’s really impressive. They’re very structured, and it seems like a no BS situation. They’re not trying to impress you. They’ll say, “Hey, this is in our road map, so we’re going to do this.” Or, “Okay, these are the different points which we have to think about. We have these other considerations, so how can we attack this?” They’re very, very clear, in terms of their process.

DF: Interestingly, they’re actually quite distributed, geographically. They have offices in San Francisco and Copenhagen, but (as he said in our previous episode) Christian actually lives in a totally different part of Denmark. Long story short, developers all over the world work for Realm, and they do it very effectively. They do all their development right out in public, so if there’s something that needs to be done, like a new feature idea, they’ll throw it right there in the GitHub issues.

In fact, if you ever have a problem, the best place to go is the GitHub issues. Search through those to see if it’s been solved, because someone has mostly likely already asked the question. They have an internal Slack group where they discuss new tickets as they come up—”Alright, how should we handle this one? Okay”—and then boom! one of the team members replies, if someone hasn’t already. It’s very, very interactive, and they take every single thing from the community very seriously.

You’ll see lots of issues linked to other issues: “Hey, we’re covering this over here.” In fact, a lot of times when I have an issue that I can’t figure out, I’ll ping one of the guys on the team and say, “Hey, I’m trying to do this,” and the first thing they’ll do is link me to a GitHub issue which I didn’t find and say, “We’re already handling it right here,” “It’s coming,” or “Yep, we fixed that two weeks ago. It’s in this release.”

They do this with all of the bindings: with Realm Java, Realm Cocoa, Realm Core, etc. They have discussions right there. Sometimes, they’ll do planning right there in the GitHub issues. They’ll say, “Okay, here’s what we’re thinking. This is the current plan.” They’ll even create little example test branches and push them, saying, “Here’s what we’re thinking. Please provide feedback.” Then the community hops in and interacts from that point onward.

Furthermore, they’re also very active in different communities. If you’re in the various Android development Slacks, their folks will sometimes be in there. They’re also very active on Stack Overflow. If you happen to post a question there, some of the team, like Christian and Emanuele Zattin, are answering those questions. So they take everything seriously, and it’s fantastic to be a part of it. If you’re ever interested to see how things are done there, just hop into the Realm issues, and you’ll see a whole bunch of stuff going on.

KG: I think they do a phenomenal job. It must be said that these folks who work at Realm are some extremely smart people. People sometimes ask me, “Hey, why do you always recommend Square libraries? There are other libraries.” I always answer, “There are, and if they’re good, I’ll start recommending them. But I’ve noticed this bizarre correlation that when you have super smart people working on a library, it tends to be pretty good.” I think that holds true here.

Some of my friends have mentioned that Realm also has some open-source libraries for the iOS platform—for example, a Swift linting library that’s apparently pretty well known. They know what they’re doing.

DF: They contribute to the community in many other ways too. Go to their GitHub page. Everything is open: SwiftLint, realm-java, realm-core, realm-dotnet, and all kinds of other things.

Also, a lot of people who are reading this have probably videos on the Realm website. They’re very active in recording lessons and giving content back to the community. That’s been a big help.

But to rewind for a second to your point about intelligent folks, I can’t agree more. I was talking to some of the core guys, learning about some of the internals while I was helping to write the documentation, and some of the things that they explained to me melted my mind: “What did you just say? Whoa, that’s crazy!” They’re very intelligent.

Now, you actually learned a lot by just browsing the repositories, right?

KG: Absolutely. If I wanted to understand how something worked, I would just hop onto certain issues. The other funny thing is how they would cross-link between repositories. Sometimes I would see an issue that said, “Hey, this happens because of x in Realm Core, so we’re waiting on that app.” Then they would link to the other issue, and I would follow the thread.

Just going through the repository is immensely helpful. That’s the advantage of open-source. I mean, many folks in our community can see the open-source code (even if it’s in the AOSP) and understand why a certain thing happens. It works really well: you have the code, and you can just dive in and see what’s happening. That’s the truest form of documentation.

DF: But by the same token, it’s also a huge problem: some things are not as exposed as well as they could be. You can hop into the code and say, “Oh, that’s how it works,” but it could have something that could have easily been exposed through the documentation. That’s one of the downsides of Realm: sometimes, there’s so much going on that you don’t even know something is there. Again, I know from speaking with the team that that’s something they’re working on. But if you do want to understand it, as I said in a recent tweet, go look at the source code.

If you have a problem, they’re also very open to bug reports. Look at the contributor list—it’s massive.

KG: At this point, people might be reading this and thinking, “Hey, these guys are really pushing hard for Realm. What’s the deal with that?” It isn’t all sunshine and roses. Even to this day, there are some problematic areas, and I think we should spend some time on that.

DF: Definitely. What are some of the things that you ran into, and felt like, “Okay, this is still a little painful”?

KG: The first thing I wanted to bring up is actually the primary key situation. Like an database, Realm uses primary keys. The strange thing is that they don’t have compound primary keys. What are compound primary keys? Let’s say you have an object and you select “ID” as your primary key. All is good there. You just slap on the primary key annotation, and you’re ready to go. But if I wanted a combination of two keys—for example, a person’s name and email address—to be primary keys (which is very common), that’s not possible. There is a workaround, but you can’t just apply the primary key on more than one attribute. Realm is not happy with that.

I found that very perplexing. I thought, “I don’t understand the internals, but that isn’t too big of a thing to ask. I want a combination of two fields to be the primary key.” I found that interesting, because my use case involved a model that comes down from a server, so I don’t necessarily dictate what the ID is. The server sends back a JSON response which says, “Hey, the combination of this type and this ID is unique. The ID alone is not unique, so you have to take into consideration the object’s type.” That basically means that I need a compound primary key, but I couldn’t directly achieve that with Realm. What are your thoughts on that?

DF: That’s something I’ve seen a few people complain about as well.

The other thing that really bothered folks for a long time is that you have to extend RealmObjects. A lot of people don’t like being forced to extend anything that they don’t create themselves, but that’s how a lot of the bindings were created. A lot of the stuff was done in an annotation processor, so the code was written for you. That’s where you get all of your helper methods from: “Hey, is this object valid? Can I find this query? Can I delete the object?”

They’ve recently implemented the @RealmClass annotation, so you don’t have to extend RealmObjects. The only difference there is that you have to use other helper methods (the Realm static methods) to actually get things working.

Then there’s the thing that a lot of folks are very heavy on using: value objects, which we recently talked to Ryan Harter about. That’s not implemented yet. There are a bunch of tricky things going on if you want to use immutable value types in Realm. It’s very interesting.

Have you noticed anything else? I remember you talking to me about getters and setters at some point. Did you ever work that out?

KG: It’s kind of funny, actually. This is very, very perplexing when you start up, but they have it in their FAQ, so if you look through their documentation, you’ll reach this at some point. Suppose I’m debugging an application. If I’m in a class, and I want to check what the value of an object is, I’d normally pull the object and add .name(). For instance, if I have a variable called m_person (I’m using Hungarian notation here, just because it makes it easy to explain), I’d say m_person.m_name().

But in Realm, it will return null. In fact, all of the values will be null. And you’ll wonder, “What am I doing wrong? Did I understand Realm incorrectly? What’s happening?” It took me some time, but I eventually realized that it’s a very different model (this is something you should note) where getters and setters are actually pretty important. They’re not just regular, POJO getters and setters. Realm has this thing called a proxy class that works a little differently. Instead of saying m_person.m_name() and accessing the variable directly, if you say m_person.getName() and use the actual accessor method, you’ll find the value.

DF: This actually segues back to the previous topic about how Realm is so fast. I’m gonna give you the 30,000 foot view here. When you’re working with one of those objects and you say, “Hey, get me the name of the object,” it actually reaches directly into the Realm database to give you that value. It’s not querying the database, loading it into memory, putting it into some buffers, copying it over, and finally bringing it to you (and by then the data is out of date). It’s actually reaching directly into the database and saying, “Give me that name.”

If something was to happen in the background, and the name changed from “Donn” to “Kaushik”, and you pulled it both now and two seconds later, when you pulled it again it would say “Kaushik”. You’re not working with a copy, but with the real database. Besides, all of that code is inside the core, which is C++ from the ground up. That’s another why it’s so fast. So it’s literally reaching directly into the database, and the proxy helps get that done. That’s probably one of the reasons you saw that.

KG: That’s so interesting. I didn’t realize that. It’s almost like you get the best of both worlds: it’s lazy loading (in some ways), but it’s actually direct loading. Now that I realize what that is, that’s actually pretty cool. But still, watch out for that.

One quick follow up question: since you typically use Realm, do you use the composition style or the inheritance style? Do you extend RealmObjects, or do you use @RealmClasses?

DF: I’ve been using Realm since before the @RealmClass annotation was around, so I just use inheritance.

KG: That’s another thing. I’ve noticed that some things just inherently work better if you extend RealmObjects. For example, if you don’t want to have getters and setters, and you just want to have basic public fields, I’ve found that it tends to work better with a RealmObject. That might just be a bug or something, and I apologize because I don’t remember the specifics. Also, if you just stick to using getters and setters and use it as advertised, it works without too many issues, but the minute you start to customize the objects, you run into issues.

DF: I stick with inheritance. It works for me. But there are some folks who do prefer the @RealmClass annotation.

KG: I use @RealmClass myself. One of my reasons for that is that I already had a model defined in POJOs in my application which already implemented certain things and extended certain classes. I didn’t want to complicate those things, so I just slapped on the annotation that said “Hey, this is a @RealmClass. Implement the RealmObject.” Basically, that was an easy way for me to not disrupt the existing state of affairs in my application and still get going with Realm, so I stuck to just using that.

DF: That’s a very good point. You don’t have to go all in when you want to try out Realm. One of the best use cases I’ve seen is exactly what you’re talking about. Usually, you have a couple of objects and some type of state persistence—say, a local cache. That’s a perfect time to try out Realm. Just throw it in there and use it for the cache. A cache is also a perfect example, because you need to know when it’s invalidated or updated. You can attach those change listeners, and get that reactive nature from it. If you want to, you can also take your existing objects, throw the @RealmClass annotation on them, and use them to test it out. That’s a great introduction.

KG: Speaking about gotchas, the other thing that got me multiple times was the whole concept of the Realm instance closing. Correct me if I’m wrong, but this is what I’ve noticed in practice: essentially, any time you open up a RealmObject, you also have to close it. That’s a very traditional, database transaction level thing.

Initially, when I started with Realm, I thought there was some magic happening, but it isn’t magic. It’s just basic reference counting, which is actually pretty cool. They don’t have a garbage collector. We actually did an episode on the difference between garbage collection and reference counting a while back, so you can alway give a listen to that. Since Realm is reference counted, though, if you open up an instance, you need to make sure that you close it. If you don’t, you’ll start leaking memory.

DF: Usually, I’ll just wrap it in a try/catch. At a higher level, I’m also using Dagger. Some people may agree or disagree with this, but I actually have one instance just for the main thread. I create that, and then I can inject it anywhere I want as long as I’m on the main thread. I’m careful about staying there, which we’ll talk about in a second. When I’m using it, I make sure I’m on the main thread, and I don’t use it anywhere else. Then, if I need to use anything in a background thread, I’ll make sure to open, close, and so forth from that point.

KG: I really want to ask you some follow-up questions on threading, because I think that’s super interesting. Like I mentioned before, I’m using Realm in conjunction with Rx. It gets really tricky, because when it returns the observable of elements, it’s returning a RealmList or an observable of RealmObjects. That really got me, because I didn’t understand how to close it. The problem is that when you expose an observable, you’re going to use those elements. But if you closed the Realm instance inside the observable, like you’re supposed to, any time you access an element, it throws an exception, saying, “Hey, this Realm instance has already been closed. You can’t take any more actions on top of this.”

So it took me some time. Again, because I’m comfortable with Rx, I know the workaround here. For folks who are curious, you just add an .onTerminate() call. The advantage of observables is that you can say, “Hey, execute this when you are done with the observable,” as long as you make sure that you’re terminating the whole composite subscription correctly. If you do that, you can say “do .onTerminate(),” and close the Realm instance inside that.

DF: We’re really getting into the weeds of RxJava implementation here. If you’re interested in how this works, Christian actually created Realm’s RxJava example. He does a bunch of stuff in that where he’s in the observables, and so forth. You should definitely check that out.

KG: Let’s go ahead and talk about this threading thing. This is another very interesting aspect of Realm. Whenever you create a Realm instance, it’s tightly bound to the thread that it’s created in. You mentioned that you can inject a Realm instance that’s linked to the main thread through Dagger. Can you tell us a little more about this?

The reason for this binding, I believe, is because if you try to access the same RealmObject on a different thread—say you’re between a Rx call, and you hop onto your I/O thread and access that Realm instance—it will blow up on you.

DF: Exactly. Multi-threading has been the elephant in the Realm room for the longest time. As I said before, you can run everything on the main thread, and it’s still fast. But the reason why Realm is basically thread-bound is because multi-threading is hard. There’s a white paper written by Edward Lee (a professor at the University of California at Berkeley) called “The Problem with Threads“. This is a little snippet from it:

Concurrency in software is difficult. […] non-trivial, multi-threaded programs are incomprehensible to humans.

Threads run over a period of time. If you put them on an x/y axis, left to right being time-bound, and if you have multiple different operations happening at different times—well, just try to get three in your head. You can probably manage that okay, but you’ll still get some bugs. When you get over three, the Cartesian product suddenly becomes insane. You’ve got 16 different possible combinations of things that could happen at any given time. Add another one, and it’s even harder. It just gets crazy.

So, how have previous databases solved these problems? Well, they’ve normally just applied locks. Let’s take a typical example: I want to read from a database, but I’m going to make sure that the data is consistent. If someone is writing to the database at the same time, I may get inconsistent data. I might ask for one thing, and something else may come back. How do we solve that? Typically, we throw a lock on it: I can’t write to it until someone else is done reading from it, and vice-versa. So you end up placing locks all over the place.

But locks are essentially slow, and that creates a humongous problem, because we have locks all over the place. If you’re trying to do the same thing in your application, you’re going to eventually create some bugs, because even though you’ll think you’ve got all the cases covered, you’re bound to miss some. Threading is insanely hard. This is a decades-old problem. It’s one of the reasons that JavaScript, for instance, came up with Promises, just to make things easier to read.

And so the big sell for Realm with this threading lock comes from the documentation, actually. This is a quote that I got from Alexander Stigson, one of the co-founders of Realm:

The only limitation [of Realm] is that you cannot randomly pass Realm objects between threads. If you need the same data on another thread you just need to query for that data on the that other thread. Furthermore, you can observe the changes using Realms reactive architecture. Remember – all objects are kept up-to-date between threads – Realm will notify you when the data changes.

It’s basically saying, “Look, we can get rid of all the threading problems that you’ve had. The only limitation is that you need to make sure that you’re using the same Realm instance on every thread.” Each Realm instance is thread-bound, meaning that you can have a Realm instance open on Android’s main thread. But if you’re watching some data to update my activity, or if you have an IntentService updating data, you’re going to have to open a different Realm instance in that thread. You’ll have to call Realm.init(), which will give you a Realm instance. You can work with it, and when it’s closed, Realm will sync up in the background, because it’s a multi-version concurrency control database. In other words, at any given time multiple versions of the database are running, and everything gets squished together and brought up to date on the next run loop.

KG: That’s pretty complex. I remember reading an article or seeing a talk about this, but I just want to highlight a point that you mentioned. You put it beautifully: the locks are a problem, but you don’t want a situation where the data you’re accessing changes underneath you. Realm solves this problem. It’s a trade-off, basically. All you have to do is make sure that the Realm instance you’re accessing belongs to the same thread, and it will handle all the other problems for you, even on other threads. It’s the same concurrency problem that you mentioned. Did you update data on a background thread? Your current thread handles that. You aren’t going to get stale data. You’ll get the most up-to-date data when you access that object again. The only limitation is that you have to stick to the same thread or Realm instance. I just want to call that out, because it’s a really good thing.

DF: One of the drawbacks of Realm is that it takes a complete paradigm shift to work with it, especially if you’re used to working with Rx, where you’re just tossing around threads left and right, and changing them around. You can’t really do that in Realm. You’re have to think, “Okay, I need to stay on this thread if I’m going to work with this data. Then, when I’m done, I can do something else.” If you don’t remember that, you’ll get into those weird instances where you get the error you talked about: “Hey, the Realm instance has already been closed. You can’t do this operation on this object.” But Realm solves all of those huge problems for you: “Hey, don’t worry about the threads. Do it on the same thread, and we’ll take care of everything else for you.”

As developers, it’s hard to let go sometimes. We’re control freaks.

KG: I had to wrestle with that too, but the explanation that you just gave me makes so much more sense. I understand that it’s a trade-off, and I’m willing to make that trade-off.

DF: Yeah, because you otherwise just get locks, and that’s slow.

KG: Let me give you another example where I found this to be tricky. I usually like to model my architecture like the repository pattern that some people follow. Essentially, I have a POJO—a DB service—and all my database operations are relegated towards this service. The reason I do this is to make unit testing easy. In my unit tests, I can mock out this DB service object and swap it out with elements, saying, “Whenever anyone calls you, return this set of elements.” That very typical setup allows me to do proper unit testing.

The thing people have to realize is that Realm works very closely with Android. In fact, you need an Android framework to work with Realm. You can’t spin Realm on a pure Java environment. That can get a little tricky, because what am I going to do in unit tests? I don’t have an Android instance. I’m running this on the JVM.

To give you an example, a typical query that I might like to execute is dbService.getPeople(). The trick here is that it returns a list of RealmObjects. Those are (again) bound to the Realm instance, so even my unit test isn’t going to work. There are multiple problems, and it also points to the closing of the instance: “At what time do you close the instance? If I have the dbService object return the results, and I’m accessing it at multiple points, then how do I know when to close the Realm instance?”

One way I could avoid that is by passing in a Realm instance and saying, “Whenever you query, use this Realm instance.” Then, at the activity layer, I could call onResume(). Many of the examples that I see follow this pattern. Then I’d create the Realm instance in my activity, and pass it down the chain all the way to the DB service object. I’d use that, and then make sure that the object is closed in the end. Personally, I feel like that’s a little clumsy. It feels like I’m adding way more boilerplate than is necessary.

But I did find a workaround eventually. This (again) points back to the documentation not necessarily highlighting things in a way that makes sense. Inside this DB service object, I would open the instance, execute the query, and then close the instance. I would try to contain it entirely within the DB service object, and I would instead return a copy of the object. I wouldn’t return the exact RealmObject, which is being pointed to at the source of the DB, but rather a deep copy.

Let’s say I have this “person” RealmObject. All I want is a similar Java object that’s one-to-one, but not linked to Realm. If I could make a copy of this, that would work, because the responsibility for what goes out is mine. Whatever comes out of the DB service object is just like any random Java object—I can do whatever I please with it.

It took me some time, but I eventually realized (from a GitHub issue where Christian pointed this out) that Realm has a really cool operation called .copyFromRealm(). I believe this feature was requested and added later, so I’ll make sure to add a link to that GitHub issue. When people asked for this, they said, “Hey, all I want is just a Java copy. Sometimes I don’t have access to the RealmObject in a typical use case for unit tests. All I want is a Realm copy, because I’m not necessarily testing my DB service. I’m testing something else that requires the DB service object.” This copy from Realm does just that: it creates a deep copy. It says, “Okay, I’m going to create an exact copy of this object, and then I’ll give it to you and you can do what you please.”

Essentially, that’s what I did. It was really easy, because I’m using an Rx architecture. I just slapped on an operation saying, “map, and .copyFromRealm(),” and boom! I got a copy, and everything is still contained in my DB service object. It took me some time to understand that, but it now works perfectly well. I don’t even have to worry about creating and closing that activity. I just create the Realm as and when I need it.

DF: The only issue that you’re going to have with that is that those are unmanaged deep copies of those objects, meaning that Realm is not watching after them anymore, further meaning that you’re not going to be notified of any updates to those objects, and they’re going to be invalid at that point. It’s just an in-memory copy of those objects. That’s something to be aware of, since you can’t attach listeners or anything like that to those objects.

KG: What I do, essentially, is expose an observable from the DB service object itself. That keeps returning a new copy every time, so I get the advantages of both in some ways. Internally, I’m using a listener and exposing an observable, so that internal DB service object is getting those changes. There’s a very Realm-like behavior to that.

DF: How many objects are you returning on average from that? Do you know? Is it just a couple? A hundred? Five thousand?

KG: It’s just a couple of objects. If I’m was on a Twitter feed stream, returning a billion objects, I would run into memory issues. So far, though, I haven’t run into a need to use that many objects. But yeah, these deep copies are still a copy, which means more memory.

There’s also a helper, which gets really tricky. If you read the GitHub issue, Christian actually talks about that. You can pass in how many levels of nesting you want, because you can have child RealmObjects of the copy from Realm. For example, if I had a chat composition RealmObject which internally had chat messages, those messages might have an image object and a content object, and you’re storing all of these as independent Realm database tables—a typical one-to-many relationship. I could say, “Hey, just get me to one layer. I don’t care about the nested objects.” I think that’s done for performance reasons. I could also say, “Hey, give me everything. I want the truest representation of the object.” Again, this is something that you have to understand is happening.

DF: People are probably wondering, “What if I have a ton of data in my database?” Let’s say I’m using connected, regular RealmObjects. I’m not using .copyFromRealm; I’m just doing regular queries. If I create a list and say, “Find all of the persons in the database,” and that’s 200,000 records, please note that you’re not loading all 200,000 records into the memory. Think of it as a pointer down into the databases. I’m currently on this record, and it’s going to pull more objects out as I iterate over them. It’s not loading everything into memory all at once, so it’s very memory efficient as well.

KG: For sure. If you go the traditional route, this thing is crazy optimized, so you won’t have any issues. It’s good that you brought that up.

DF: You also ran into an issue doing a very similar thing where you were trying to read stuff in from your API. You had some situation with weird API naming conventions, and you wanted to change them over. Do you remember what that situation was?

KG: This is one where I couldn’t find a workaround, but I think there’s an issue tracking it. For example, say my API sends down an object. Since this is a typical back end, it’s a JSON. I’ll use the same person example. Maybe one variable is “first name”. The column name would be first_name—typical snake casing. But that’s very un-Java-like. In my actual RealmObject, I don’t want to change the name of the variable to firstName (in camelCase).

The problem with Realm—and this seems so basic that it’s surprising they don’t have it already—is that you can’t have custom column names in your database. You cannot say, “Hey, in my Java RealmObject, keep it in camelCase, but when you save it in the database, I want it to be named first_name.” I couldn’t find a workaround for this. It’s kind of funny, because we added it to both the iOS and Android applications, and we were thinking, “Hey, we need to keep this consistent”. This is one point we remembered to touch on, because they have their own mobile platforms. One day, everything can just synchronize across platforms, but I didn’t want to change my variable names.

I couldn’t find a workaround for this, so if you open up the Realm database for my Android application, the column name would be firstName, which is kind of iffy. But I think they’re thinking about solving this.

DF: What was the value coming down from the API? Would it be first_name?

KG: If you had a JSON object of “person”, first_name would be the key, and the value would be the string “Donn”. Then last_name would be “Felker”.

DF: How are you storing that in the database now?

KG: I parse the JSON object (and you can use a very typical JSON deserialization library—GSON, Jackson, Mushy, or whatever works for you), and I have to convert that API object to (in this case) a Java RealmObject, which I can then save into my database. The problem is that when I do the deserialization, converting it from the JSON object first_name to a Java object, it goes into camelCase, because it’s a Java object at this point. If I provide a Java object and then say .saveToRealm(), it essentially maps it to the variable name in your Java objects. Essentially, I’ve lost first_name. My Realm database is in camelCase.

DF: I guess the other issue that I’m having is whether you want it to be first_name in your database?

KG: I do, potentially, because that would mean that the iOS folks don’t have to have camelCasing. camelCasing is not common in iOS land, I hear. The other tricky thing is that we have some objects which use Hungarian notation, so it’s like m_firstName.

DF: OK, I finally see what you’re saying. You want to keep the naming convention from the API, so that it says first_name when it gets saved to the database, but in Java, you’d like it to say firstName. I see what you’re saying. I haven’t had to deal with that, because what I’ll typically do when I get some crazy API is to just save everything in the Java format. If I come down, and it’s _ID or something, I’m not saving that. I’ll just use the serialized name property of GSON or whatever library I’m using, and it will just change it so that the field is actually called ID. Then it gets saved in the proper format, and I don’t worry about it from that point forward. But I guess if you’re trying to share these objects across different platforms, that could be an issue.

KG: In all fairness, you’re right. This is a problem that you would see later on, but it’s not something I immediately see. At some point, though, it might get a little tricky.

DF: They are tracking this, again, on the issue tracker, but it’s currently in their backlog.

KG: There was another tricky situation. What was it?

DF: Was it partial updates?

KG: Yes. This is not specific to Realm. In fact, it’s a very common problem. Essentially, I get a new Java object from my API, and I say, “Hey, update the copy of Realm with this.” The tricky thing is that what you’d usually like to happen is for it to only update the non-null values. Usually, your API will only send certain attributes (say, three or four) in order to make sure you don’t have a very big payload. So I’ll use GSON or something to serialize this into a Java object, which works perfectly. Those three fields that I need will get updated as required, so no issues there.

The problem I would run into is that, other than those three values that came down from the API, everything else is null (as it should be in a serialization). In Java, you cannot say, “Don’t have a value”—it’s either null or not null. So, when I say .copyToRealm(), I’m going to run into an issue where it updates all the other values to null. So I’m getting an API that says “Only update these three values,” but when I actually update my RealmObject after having serialized that, it wipes out all the other values and make them null.

DF: That can be tricky at first. You’re like, “What? This is not the expected behavior.”

KG: Right. But this is very common too. Initially, when I did a little research, I thought, “Maybe this is something that’s only typical to Realm,” but that’s actually not the case. Many databases have this problem.

It should be pointed out that there is a solution for this, because Christian actually pointed me to one. Realm also has a feature where you can copy a JSON directly into the database. Instead of going through the serialization, you can say, “Hey, take this JSON and straight up map it into my database.” If you provide a JSON object, Realm understands that the values which have not been provided shouldn’t be updated, so that’s perfect for our use cases.

But again, this is the problem that I was telling you I ran into. If you save from the API and copy to Realm directly, the keys from my API object are going to be in snake_case, which means it won’t find that value when it’s copying into Realm. That’s a problem. So I had to write a minor mapping. I had to construct another JSON object which would map the fields from my RealmObject, and then use that to copy to Realm directly.

DF: Wow. That’s kind of a pain. You should fix your API (just kidding).

KG: Problem solved, right? But like you rightly said, if you don’t care about these things (like in a typical use case), you won’t run into this problem. But if you want to use a combination of two features, where you want to copy only certain attributes to realm, and you don’t want to change your Java class to have the same variable names as my API, then you run into this problem. I had to work around that by writing a custom serialization mechanism, which serializes it into a JSON that maps one-to-one with my Java object, and then save that into Realm.

DF: So do you guys actually share your Realm databases between iOS and Android, or are you just preparing for that?

KG: That is a good question. We’re just preparing for it. You’re right in calling me out.

DF: It’s just preparing for what you don’t know. Then again, you brought up the point of things we’re used to having in other languages, like an active record. If you wanted to change a database, how would you do that? In an active record, you’d use migrations. Well, Realm actually has the same thing. If you needed to change that column name, you could write that migration in. One of my clients uses fifteen or sixteen migrations, where we add a class, add a field to a class, add a couple other classes, etc. That’s another nice thing about Realm: it’s very easy to update the database, so you aren’t stuck with that same scheme that you started with. You can actually add to and modify it as time goes on.

KG: Speaking about migrations, there is one cool thing that I should point out. Realm has a really cool helper which can delete the entire database if you think a migration is needed. So if you don’t want to maintain the local data, and you also don’t want to deal with migrations, you can just slap that on. Any time Realm thinks that your schema has changed, instead of writing custom migrations (which can get very tricky to understand sometimes), you can just say, “Actually, I want to just delete the database, because my API will pull the objects down and I’ll recreate it.”

DF: Yeah, if you have that ability, you can just rehydrate on the next screen load. That’s such a huge time saver, because if you have to manage that data migration process, it’s not perfect. Data migration is always going to be a manual task, where you’re extracting, transforming, and loading into different areas. But if you can, use those little helpers where you can just delete it and restart. It makes it so much easier.

KG: To your point, if it’s a pure offline app, sometimes you don’t get the luxury of just wiping your local data, because you’ll lose everything. In those cases, you have to go through the migration route.

DF: You bring up a good point. There are a lot of situations involving offline apps. You did this at Wedding Party, if I remember correctly. You guys had an offline app, and you needed to write custom server sync logic, correct?

KG: At Wedding Party, we were very proud of the sync mechanism we wrote, because we wrote it all by hand. It seems like a very simple thing, but it’s not simple, folks. Writing a good sync engine can be ridiculously hard. There are so many considerations to make. You’ve got to make sure that you’re not sending the complete data—just incremental data—but you’ve also got to know which data to pull and which not to pull. Wedding Party had a pure offline mode app where each thing would function independently, but we also had a web application that was the master that all the data would be synced up against.

We can point to some links in the show notes where folks have talked about sync engines. They’re very complicated, trust me. I have written one. It worked really well, but if people came and asked me to write one, I’d say, “No, let’s just pick a solution.” The amount of work that goes into writing a sync engine is almost always not worth it, unless you have a team that’s just willing to work ridiculously hard on that.

DF: That segues perfectly into something that Realm recently released, which I unfortunately haven’t had any time to play with yet. It’s known as the Realm Mobile platform. It’s basically a Realm sync engine with an object store that sits in the cloud. It has two-way data sync, with synchronization and conflict resolution built in for you. You don’t have to build any of that stuff that you fought through before.

They also do a bunch of other stuff, like events that trigger server-side notifications when they need data changes on the server. They have their own custom authentication access control, and (of course) it’s encrypted. I believe it uses AES-256. I haven’t had a chance to play with it, but I really want to. I might do it next week on vacation—just poking around to see what it’s like. If this solves what they say it’s going to solve, I can’t imagine how many man-hours are going be saved by doing this.

KG: That’s another thing. It wasn’t just about convincing myself. I had to convince my team too, because adding a database is not something you simply do on a whim. But this was something that we felt was very convincing. Again, we’re starting to move offline. That’s a big project that we’re doing for our shopper app at Instacart. If we get to a point where we need to sync data between multiple platforms, this makes it ridiculously easy. Again, like you rightly said, I haven’t used it either, but the way it’s being pitched is: “Hey, you have this iOS Realm database and this Android database. You don’t have to write the sync logic. All you have to do is use the Realm mobile platform.” If I issue an update—say I correct the name variable in my Android app—the next time it’s pulled from the iOS application, you’ve already got that update. They’re basically saying that you get the sync engine for free.

DF: I think that the developer version is free now, but if you get into the professional version for enterprises, it’s actually one of the things that they charge for (I’m looking at the pricing page right now). I know that if you’re doing the developer version, you can get all the syncing for free, and so forth. But again, if you’re paying for that product, it’s simple.

I’m very against the NIH (Not Invented Here) syndrome. People are like, “We’re going to write our own status page and analytics engine!” Then you start adding it up, and say, “You’re gonna spend $150-200K writing this, and waste six months of time that’s not spent pushing your business forward. Why don’t you just spend a little bit of money on this other product that does it for you, so you can focus on fixing problems for the customers, not fixing technology problems?”

KG: The strongest skill a software engineer can have is to know when to make it someone else’s problem.

DF: That’s the biggest truth, and it can’t be said any better. I have no words other than what you said. So hands down to Kaushik.

If folks wanted to get started with Realm…I already know how to use it, and it’s become second nature to me. It’s still kind of fresh to you, though, so if you were to recommend how to get started with Realm, what would you tell someone to do?

KG: Almost all of the content that I need, I get from two places. One is obviously the documentation. It’s not as detailed, but it’s a very good place to start to get a feel for what things are.

But an even better recommendation (this is my standard go-to now) is your Caster.io course on this. Donn did not prod me to say that, by the way. He just genuinely asked this question, but this is what I really do. When I started out with Realm, I was like, “This Realm thing sounds interesting. I’ve talked to Christian, and I understand the theory. But what does it feel like? I want to get a better understanding of what it is.” So I made myself a hot cup of coffee, opened up Caster.io, and saw that Donn used Realm. So I thought, “I’ll see how things are.” When you see the code, you get a good feeling of how things work. That’s basically what I did, because I didn’t want to invest that much time in it if it wasn’t something that looked appealing to me.

Any video course would work, but Caster.io works pretty well. So, I opened Caster.io, looked at the courses, got an understanding of how it works, and thought, “Okay, this looks like something I can get behind.” Then I went to the documentation. As you implement, you’ll run into these small quirks, like we mentioned over the course of this episode. Usually, you’ll find them either in the documentation or the GitHub issues, so that was my strategy. What are your thoughts?

DF: I agree. I usually tell people to just go to https://realm.io. Here’s the key thing: today, we’re mainly focused on Realm Java, because this is an Android podcast. But they also support Objective-C and Swift. There’s starting to be quite a few folks listening to this show from the React Native crowd, and there’s a React Native binding too. And if you’re on the .NET side of things, doing cross-platform development, they have Xamarin bindings as well. So go the website, choose your platform, read the docs, and start hacking away. That’s usually what I recommend. If you need any help, you can always check out the Caster.io course.

I hope that this conversation has answered a lot of your questions about what we think about Realm in general, without having someone directly on the Realm team here to talk about it. These are our actual real thoughts. I have apps in production with Realm, and have had some for close to year now. It’s been performing well. Kaushik, you’re starting to use it now, and I have a bunch of other friends who already use it.

Hopefully, this answers your questions. If it didn’t, please hit us up on Twitter, and we’ll try to help you out.

KG: If there are things we mentioned offhand that you would like more clarification on, feel free to hit us up on Twitter, and we’ll make sure to give you the details, the context, or the specifics on the stuff that we mentioned.

If folks wanted to reach out to you and find out more about Realm’s specifics, what would be a good way to do that?

DF: They can reach me at @donnfelker on Twitter. What about if they want to ask you about the weird nuances of Realm?

KG: Please do! Do it on Twitter at @kaushikgopal. Seriously, folks, we’re very interested, and this is a big part of the learning process for us, too. If you keep asking quirky questions or the things that come up that seem like a no-go for you, this is how we’re fortunate enough to be able to find answers, so that we can jointly learn in the process.

DF: We’ve had many folks ask us specifically about our thought process on the the MVP pattern (and other MV* patterns), so we have another one of these conversations planned for those type of things. Please ask your questions, and we’ll get them in here!

069: Talking Buck with Uber engineer Gautam Korlam (part 2)

Tue, 10 Jan 2017 13:39:15 UTC

Download directly

We’re back with part 2 of our Buck episode. We continue our chat with Uber Engineer, Gautam. We dive into the details of how buck is used, how you can use it and how it can help you and your team. Learn about how to use it with Gradle and more with OkBuck.

Show Notes #

Build systems #

Misc #

okBuck (adopting Buck easily) [github.com]
Buck – Exopackage
Watchman

Resources #

Buck Slack group
What makes Buck so fast
Gautam’s talk on okBuck at Droidcon NYC [youtube.com] (Slides)

Contact #

Transcript #

This is Part 2 of a two-part interview. Part 1 can be found at http://fragmentedpodcast.com/episodes/68/

Donn Felker: As an Android developer, I’m very familiar with the Gradle build system, so I’m apprehensive about leaving for something brand new—there’s probably a large learning curve, and so on. But I hear that you guys have created a Gradle plugin for Buck called okBuck. Can you tell us a little bit about what okBuck is, and maybe why we would want to use it as compared to regular Buck?

Gautam Korlam: That’s a great question. We were in that same exact boat, because change is hard (especially when you have hundreds of developers working on a codebase). All our developers were familiar with Gradle, so we wondered, “Hey, is there any way that we can use our existing structure along with Buck?” It would have been a nightmare to force a large migration on all our developers, bringing all the cognitive overhead from the tooling changes.

So we started looking at an open-source project called okBuck. It wasn’t originally written by us, but by a guy in Beijing named Piasy Xu. He wrote it as a hobby project, and it was building very basic Android projects by the time we discovered it. At the time, a lot of things in it were not flexible enough to actually be considered production ready, so we went in and almost rewrote it from scratch over three to four months. We brought it to a high-quality state that can be considered production ready.

We use a lot of different tools at Uber. For instance, we pretty much use everything under the sun that Google puts out. All of that needs to work in alternate build systems. Sometimes there are no convenient analogs, so we had to bridge the gap, and that’s where okBuck comes in.

Kaushik Gopal: Let’s just step back a little. Right now, this is a little confusing to me. You’re saying that okBuck is a Gradle plugin—but fundamentally, Gradle and Buck are on opposite sides, so how does that work? Right now, my mind is split into two parts. There’s Gradle, and there’s Buck—but wait, both of these are working together? I don’t understand.

GK: Let’s say that you have a project which is currently being built with Gradle, and you want to try out this new system from curiosity. In other words, you don’t want to spend all the time and effort it takes to migrate over. What will you be looking for? “Is there anything that can make the transition automatic for me?” If you think of a project converter, okBuck is kind of like a build system converter.

The way it’s currently written, it’s very easy to convert a Gradle project into any other build system. If you remember Maven from back in the day, Android Studio used to come with something called a Maven to Gradle converter, which did something similar.

KG: Oh yeah, I remember those days.

GK: It’s similar to that, but there’s actually a huge gap between the concepts of the two build systems. There’s a level of complexity that needs to be bridged so that developers don’t have to spend time wondering “Hey, how does this work, exactly?”

To make that even easier, okBuck sets up something for you called a Buck wrapper. It’s very similar to the Gradle wrapper, so we kind of stole the name.

DF: So it’s essentially buckw.

GK: Exactly. In fact, we called it that. If you want to build an APK, you just say ./buckw build apk. If you want to test something, you say ./buckw test module Or if you lend something, it’s ./buckw lend [whatever]. It bridges the gap, taking the overhead of understanding the system away. That’s why okBuck is a very quick way for you to try Buck and see if it’s right for your project, and what value it can bring to your project or your codebase.

KG: Suppose I want to try Buck. What would my first steps be?

DF: How do we get started?

GK: okBuck has a sample project containing a lot of different examples. It also has a very extensive wiki and migration guide. But 90% of the time, you can just apply the plugin, and it should just work.

Admittedly, there are particular cases—especially in large, enterprise-level builds—where you may want to customize it, or you may have a bunch of legacy Gradle hackiness somewhere in your build that doesn’t work with Buck.

Another company that uses okBuck very extensively right now is AirBnB. Once we open-sourced it, they were pretty interested. They have basically the same problem (along with a lot of other companies that are hitting this issue): they started with Gradle, but they’re reaching this point of scale where it’s just not working out for them and they need alternatives. But they don’t have the bandwidth or time to go research, and that’s where this solution fits in. AirBnB basically did their conversion in three days to a week. Two engineers sat down, understanding what the system looks like, and just tried it out.

KG: So I guess our first step would be to go and look at the examples and instructions in the README, and that would help us understand where to move from there.

GK: I also gave a talk in September at DroidCon NYC which covers what the migration path looks like and the kinds of gotchas that users might encounter.

DF: You said that okBuck is something that you and Airbnb are using. Is it production ready, or are you guys just testing it out still? To me (and from what I can tell, to Kaushik), it’s very interesting, and I kind of want to go play with it. If I’m able to convince clients that, “Hey, this is going to cut down your build time significantly, which is going to increase your developer productivity, which affects your bottom line”—is this something that I can go use today?

GK: We’ve been using it to build the new Uber Android app ever since we started developing it six months ago. At this point, all of Uber uses Buck to build for Android (as well as iOS), and we use okBuck on a daily basis. So it goes through a lot of churn as we make sure to add any new features that people request. For example, we added support for things like SQLite, Square, Lambda, and the Gradle transform plugin. It actually supports a lot of those use cases out of the box.

It’s really a situation where you can try it out, and if something’s broken, it’s easy for us to add that support, because it’s super easy to extend. Also, we get a lot of excellent contributions to okBuck that make it easy for us to make these changes.

DF: There’s a good question. Is okBuck open-source?

GK: Yes, it’s completely open-source. You can check out all the code at https://github.com/uber/okbuck.

DF: It looks like you guys are MIT licensed too, for those who are wondering.

KG: Excellent, that’s a good license to have.

GK: Also, in terms of the quality of the product itself, Airbnb isn’t the only one using it. I think Lyft has been using it for a while, and the guys at Square are currently evaluating it.

Also, Facebook has set up a Buck-focused Slack, where a bunch of companies are usually chatting about different elements of Buck, how it’s being used, and the unique situations that they’re facing. That’s open for people to join, if they’re interested in learning more.

KG: We’re all software engineers, so we understand that not everything in the land of Android development is sunshine and roses. Right now, hearing about Buck’s advantages is pretty much just sunshine and roses, but I think it’s also fair to say that there have to be some disadvantages, right? For example, one thing that I’ve heard is that external dependencies aren’t supported right out of the box. Is that still true? I remember that that was thrown around a lot in the early days of Buck, when people were super frustrated with Gradle.

GK: Those still aren’t supported in the broad sense. With Gradle, you have a lot of finetuning abilities, so you can say, “Hey, I want this dependency, but not the transitive dependencies that it brings in.” Actually, there’s no concept of Maven in Buck yet, but you have to understand that Buck was built for the multi-people situation that Facebook is currently in—one where the whole codebase is filled with all sorts of JARs and external dependencies.

That may not work for everyone, which is why okBuck bridges that gap as well. It uses Gradle’s caching solution. You basically get the exact same dependencies that you would get in Gradle, but it downloads them to a local cache that Buck can actually reuse to build the codebase. If you just use Buck, it still doesn’t do external dependencies. There’s a basic command called buck fetch that can fetch external code, but there’s no dependency management in the Maven sense. So okBuck is definitely useful for people who are coming from the Maven world and want to bridge that gap.

KG: Essentially, I guess that the disadvantage (if you can call it that) is that all those dependencies would be pulled locally, versus having direct references.

GK: Exactly. Having them locally can bloat up your repository if you’re not using things like Intellifast, for example.

Those kinds of things are not documented really well on the Buck website. They just say, “Hey, you can have this checked in, and you can pretty much go with it.” The fact of the matter is that Facebook has tailored their BCS solution to scale really well. They use Material, and they have a lot of custom in-house things that make it very easy to work with large-scale codebases. But that’s not within everyone’s reach.

okBuck basically says, “It may not matter on small-scale projects, but eventually, as your project grows, your build will grow with you and not slow you down.” So a comes from here at Uber. Our codebase has grown from 40 modules at the get go 3 months ago to 170 modules in the released app. That doesn’t even count any of the external libraries that are used for networking and other stuff like that. That’s just the new app. But we haven’t actually changed, in terms of the build speed. It’s exactly the same.

We also have something called a network cache, which I forgot to mention. Buck comes with something called a remote build cache, which means that if you build something on CI (for example), it’s cached on the network cache. Let’s say that CI has the build master, and I come in tomorrow and say, “git rebase. Okay, I have the latest master.” Then I try buck build, and it says, “Build done in 3 seconds.” What just happened there? It downloaded the exact apk for that job from the network cache, and it says, “Okay, you don’t really need to build anything. It’s already been built on a different machine; you can just go ahead and use it.”

DF: That’s magical.

KG: That’s brilliant. So basically, it’s a shared build cache.

GK: We can do that because builds are reproducible. You couldn’t do it if they weren’t equivalent on different machines.

KG: That makes sense. So it’s like coming full circle in terms of reproducibility.

GK: Currently, our build times on a fresh clone from the repo are 12 seconds on Wi-Fi and 3 seconds on Ethernet.

KG: That’s pretty cool.

GK: Uber has also open-sourced our Buck HTTP cache implementation. That’s linked to in the README of okBuck, if you’re interested in trying it out. I think the Airbnb folks already use it for their builds.

DF: Kudos to you folks.

KG: I guess there are two points to be made. First, this is a network cache. Hopefully, you’re in a company and on Ethernet, but it depends on the internet. If your network connection is slow, don’t expect 3 seconds.

GK: It might be 30 seconds then, because you also have a local cache on your machine. There are multiple levels of cache.

KG: You mentioned the documentation, and that’s something that we should let our listeners know about. At this point, the documentation is not necessarily up to snuff.

GK: We found that lot when we were working in Buck, actually. There are lots of things inside the Buck codebase that are not immediately obvious from the public documentation. That’s not problematic, generally, because you can typically look at the source code and get a good understanding of what’s going on once you dig in, but it was definitely a surprise to us when we initially started to start develop with Buck.

DF: Before we hopped on this call for the podcast, I took a look (over the last couple of days) at the Buck website. I started hopping into the docs, thinking, “You know what? I’m going to see if I can try this out.” But what I immediately felt was an apprehension to learn it—not because I didn’t want to learn something new. I love learning. But it seemed like a big thing, like when you first learn Dagger or dependency injections. It’s a very large, steep learning curve that turned me off. Have you seen that with Buck as well? Is there a large or steep learning curve?

GK: For some parts of it, yes. If you’re doing a very basic build, most of the systems have very, very basic examples on their websites. But they won’t list, for example, how to hook up annotation processors, do build flavors, or other instant things like those. It may not be easy to access that information, so while there’s not a steep learning curve, there’s definitely a longer one. It will take you longer to find that information.

But okBuck just says, “Okay, that’s too much information. Let’s try to bring it all together into a nice API interface. Just build that thing, and we’ll get out of the way.” That’s why we really like okBuck.

KG: The other question that I had about Buck is that, while I’m very enthused to try it out, one of the biggest advantages of Gradle is the concepts of product flavors and build variants. Does Buck support the same thing, because that’s actually a pretty useful feature for many folks?

GK: Certainly. Buck has no concept of build variants (as such), but okBuck supports them. We do the translation logic in such a way that it doesn’t really make a big difference. Let’s say that with Gradle, you’d do something like, assembleFlavor1Debug. With Buck, you’d say, buck build Flavor1Debug instead. We did that translation because Buck doesn’t really have a concept of build flavors or variants, but you can map what Gradle does to say, “Hey, when you build Flavor1Debug and Flavor2Debug, you’re pretty much recompiling twice.” All the source code is compiled twice and treated as two separate targets, so we kind of do the mapping that way.

KG: So that’s where okBuck comes into play.

GK: If you did that manually, it can take quite a lot of time. I think some of the largest build files we have are our 5,000-10,000 lines of Buck files for really complex builds.

KG: Even beyond time, I would imagine that complexity is the tricky thing, right? These are things that you want to be careful about, especially if you’re building multiple variants.

GK: In terms of other features, I think that okBuck supports unit tests and espresso tests. Gradle transforms have been added recently.

We’re working on Kotlin support right now because the community is moving towards it very heavily. Kotlin build times are not exactly where they’re supposed to be, as far as the developer feedback I’ve been hearing goes. That’s very important to us. We do have some internal tooling in Kotlin, but we don’t have it in production yet. We basically want to have a way to build it at scale, so we’re definitely looking at that in the next few weeks or so.

DF: You said that it supports testing, like Android tests and unit tests. Do you know if the unit tests are faster? I would have a hard believing that the Android tests would run faster, because you’re waiting on espresso, online resources, and stuff like that. But what about the unit tests themselves?

GK: Unit tests are faster, purely because it can run multiple targets in a very interesting way. It runs multiple threads for different targets. Let’s say I change one single file somewhere in the codebase. Since it knows how that bubbles up, it’ll say, “Only these particular test cases have to be rerun,” and it’ll just run that subset of test targets, which makes it very fast.

KG: I have one question about Kotlin support, because I’m sure our listeners would want to ask this. You mentioned that Kotlin build times are significantly longer than what people want. Would Buck be able to solve that problem in some way, or is it something that’s inherently a problem with generating Java classes from Kotlin?

GK: Sure, I can talk a little bit about that. I forgot to mention one important detail: Buck does something called ABI (application binary interface) checking. Let’s say that you have two classes, A and B, in two different modules. B depends on A. Let’s say you change A. Gradle says, “Hey, A is changed, so B has to rebuild itself.” But if you changed a private method that doesn’t really affect anything in B, Buck won’t rebuild B. It will just rebuild A, and it’ll pack the text files together directly inside the APK.

When you go with Kotlin, the same thing would apply. For every JAR that comes out of a module, it creates this ABI JAR with all of the public APIs. Especially if you’re iterating on something really quick or you’re changing methods, it’s similar to instant turn on the command line, which can skip a significant portion of the build.

KG: How does that play into the Kotlin support? Does it apply the same logic to Kotlin?

GK: Yes, because all of these targets are actually generating JAR files at the end of the day. Buck doesn’t really care how the JAR file is materialized. It could be from Kotlin, Scala, Ruby, or Java. It doesn’t really matter.

KG: So because of the way incremental compilation is approached, you get its benefits across other languages. That’s pretty slick.

Okay, so all of this is amazing, but what’s the future for okBuck? What’s on the road map? You mentioned Kotlin support. That’s pretty cool. Are there any other things that you want to tell us about to get us even more excited?

GK: Well, at this stage, we have so many modules that the slowest part of our build is the time we actually take to run okBuck, because it’s still based in Gradle. So I just made some changes that basically make it run these things in parallel. We’re looking at incremental task execution.

At this point, we’re doing more polishing of our incremental build support. Some of our APIs are still not finalized, so we’re trying to make them stable. Also, we ought to have feature parity (at the end of the day) with whatever the Android Gradle plugin has. At this point, we’re at about 90%, but some features are still not supported. We’re slowly whittling down all the features that people are requesting and trying to make sure that it’s airtight.

At this point, Kotlin is the next big thing for us, along with making okBuck faster and scalable. People might be tempted to switch all the way to Buck, but then you’d lose access to the Gradle plugins that the community puts out. Square might put out a great Gradle plugin tomorrow, and you’d be thinking, “Oh man, I wish I was still using Gradle so I could use that.”

KG: Wow, that’s fantastic. It’s a lot to digest, but I’m super amped up now. For folks who are listening, what are some good resources to look at, and how do I get started?

GK: If you want to just admire how fast it is, there’s a test project that we put up to stress test Android Studio and Gradle. The funny thing is that it’s now used by the tools team and the Gradle guys to ignition test their performance on every release. It’s a very buggy project.

KG: So it’s a legit thing, not some convoluted project that just shows how Buck is doing better?

GK: It’s basically our project, but we removed all the code and obfuscated all the project names. It’s like an Uber project that has no actual information in it, just dependencies. That gives you an idea of how fast it is. There’s also the okBuck Github page, where you have the actual project; the DroidCon NYC talk; and a Buck Slack that Facebook maintains, where that people can hop in and get an understanding of what’s currently going on.

KG: Fantastic.

GK: I want to mention something else really quickly. There’s support for generating Bazel from okBuck now. The Bazel team in New York said, “Hey, this is a great project. Let’s try adding Bazel support”—so they actually did. The next version of okBuck will probably ship with Bazel, so you can compare all three systems side-by-side if you wanted to.

KG: Ooh, that’s very interesting. Gautam, thank you so much. I can’t wait to hop off this call and start exploring okBuck more.

DF: I have shiny object syndrome times 5.

GK: You should definitely try it out. It’s low investment. Just apply the plugin and see if it works out. There is no upfront cost to do the migration.

KG: Thank you so much for spending your time and sharing your wisdom on okBuck. I think this is going to be great. Our listeners will definitely appreciate it.

In fact, if they want to reach out to you, what’s an easy way to do that?

GK: I’m on Twitter (@kageiit). I’m not super active, but I do monitor it from time to time, so that might be a good way to reach out to me.

KG: All right, that makes sense. Donn, if folks want to reach out to you after you’ve tried Buck…

DF: The best way, again, is Twitter (@donnfelker), but the real question is: how do they get ahold of you, Kaushik?

KG: I’m @kaushikgopal on Twitter. If you give me some time, I’ll also try Buck, and that’s a good place for folks to reach out to me.

068: Talking Buck with Uber engineer Gautam Korlam

Mon, 02 Jan 2017 05:00:48 UTC

Download directly

We kick off 2017 talking to Uber Engineer Gautam. In first part of this 2 part series, Gautam talks to us about the Uber Android app, the complexity in the architecture, the scaling challenges, the pain points Android developers faced working on such a massive app.

He then goes on to explain how his team (Android Developer Experience) at Uber have approached these challenges and come up with elegant solutions.

We then dive head deep into Buck – the build system for Android development, it’s advantages and the benefits that the folks at Uber have observed having migrated.

Show Notes #

Build systems #

Misc #

okBuck (adopting Buck easily) [github.com]
Buck – Exopackage
Watchman

Resources #

What makes Buck so fast
Gautam’s talk on okBuck at Droidcon NYC [youtube.com] (Slides)

Contact #

Transcript #

Donn Felker: How are you doing, Kaushik?

Kaushik Gopal: I am doing good. How has your day been?

DF: My day has been fantastic. Just another day in paradise, as they say.

KG: That sounds pretty good! My day has been interesting. I had a pleasant Uber ride, but it took me a quick minute to get here.

Speaking about Uber, I hear we have an excellent engineer from Uber with us today. Can you tell us more?

DF: I’m just going to hop right into it. Without further ado, I’d like to welcome Gautam to the show. Welcome to the Fragmented podcast!

Gautam Korlam: Thanks for having me, guys.

DF: Gautam, I think it would be good for our listeners to become familiar with you, and I think the best way you can do that is by giving us a little background information on yourself: how you got into Android development, where you work at now, and what you’ve been up to.

GK: I’ve been an Android developer for about three years now. On my first job out of college, I joined a company called Lookout Mobile Security. I’m sure you know some people who work there. There was a guy there named Israel Ferrer (he works at Twitter now).

DF: Hey, he was on our show before!

GK: Yeah, I used to work with him. Anyway, when I joined the company, I didn’t know anything about Android. I did a bunch of stuff with Ruby on Rails back in college, and I wasn’t really sure of what mobile did, but I was given the job. I started with Android UI. I think one of my first projects was designing a live wallpaper (those actually used to exist!).

Eventually, while working at that company, I began to develop an interest in Android tooling, especially in continuous integration (CI) and the build system. That was at a time when we didn’t have Gradle or any of the other tools that we have today. It was mostly just Eclipse.

DF: Oh man, that word brings back nightmares for me.

GK: Back in the day, we weren’t even on Maven.

KG: So you had to deal with all that good XML stuff, huh?

GK: Exactly. Those were interesting times.

But at that point in time, Gradle came out. I was pretty interested in the build system and all the new stuff that was coming out. I think they announced it during Google I/O. So I began diving into that stuff, and I migrated the company’s build system over to Gradle. So I grew into more of a tooling background.

When I was starting to look for another job, I landed at Uber. The first thing I said during my interview was that I wanted to make tools for developers—and today, I’m on the Android developer experience team at Uber. We focus a lot on things—the build system, the IDE, and any general productivity tools that developers use in day-to-day jobs. We try to help them do their job better. That’s the gist of my Android experience.

DF: So you help the Android team at Uber do their jobs more effectively? That’s cool. I had no idea there was even a position like that at Uber.

GK: It was a very organic thing. I was on the platform team before, which used to coordinate many of the core libraries, like networking, experimentation, and analytics. Since my main passion was in tooling, I carved this team out over time, so I have a couple of people on it right now.

I think this sort of team becomes very important as you scale a company. Especially with a lot of developers, you get a lot of unique challenges and problems. I think we currently have a couple hundred Android engineers at Uber.

KG: Oh wow! That explains a lot of stuff. That seems like paradise!

GK: Yeah, there are a lot of smart people—and a lot of people committing core changes. People tend to step on each other’s toes, so I want to make sure that they’re doing their job effectively, and (at the same time) that they’re able to commit fast and move quickly. That’s where we come in.

KG: Suddenly, the whole Android developer experience team is like, “Oh my God, we obviously need someone who’ll help with that.”

GK: It wouldn’t be much of an Android developer experience team if we had just two engineers.

DF: Holy cow, that’s amazing.

KG: One of the topics that both Donn and I have been really interested in (we’ve always wanted to talk about this) is the Buck system. I know that Uber now uses Buck, so it looks like you’ve transitioned from Gradle to that. Is that true? Did you ever use Gradle, or did you always use Buck?

GK: To give you a bit of a background about why we did this, when I joined the company, there were a handful of engineers. We had a very small codebase: the rider app, the driver app, and one common library, (which was conveniently called “Android Library”) that contained the shared code between these two apps. There was no versioning for that artifact, so people would just consume it and build off of it, basically. Those were dark times!

When I joined, I wanted to transition us onto a system where we could add more libraries and start taking things apart. We began looking at things like Artifactory, which is a Maven server for artifacts. We already had a very basic setup of Gradle, so we pushed all of our libraries up to the Artifactory server and all the apps consumed them. Organically, over time, we’ve grown to a situation where we have somewhere close to a hundred libraries with a lot of different functions. So things have gotten interesting.

DF: I have a question about that. I have a friend who worked, very early on, at Uber. He told me that everything is based on micro-services there. Does same thing happen in the Android ecosystem too? In other words, does everyone creates these micro-libraries for various different components or what?

GK: When we initially started out, we had a macro situation, where we’d try to dump all of our common utility code (along with anything that could be a secondary) into this library. But we later realized that if you start doing that, there will be a lot of bad coupling, and that can be a very big problem. So we started splitting out into micro-libraries, but not to the extent that there are only two or three classes in a library. That would just get ridiculous to maintain over time.

If you think about it at a high level, you’d probably have a bunch of different components in your app: stuff for networking, threading, UI, analytics, experimentation, and mapping and navigation, for instance. So we started splitting out our libraries based on the core feature specs of the app.

KG: How many submodules does a typical app the size of Uber have?

GK: It’s totally dependent on the particular app. Some apps, when they were being developed, didn’t have any modules in their repository. They had other modules outside the repository that were all built individually and uploaded to this artifact server, and would later consume it in their different ways.

DF: You guys consume a ton of modules and libraries, so (at some point) you have to have run into some kind of scaling issues with Gradle. Actually, I haven’t ever had that many submodules (and most other developers probably haven’t, either), so I guess the big question is: did you run into any scaling issues with Gradle when you reached that level?

KG: I mean, I had a project that I worked on in the early days of Gradle that had three submodules, and it was already a nightmare, so I’m really curious to find out how that’s worked out. I imagine there are more than three in Uber!

GK: Yeah, definitely more than three. To answer the question, when you initially start a new project in Android Studio, the wizard tells you, “Hey, you can make can make an app module”, right? I’m sure that if you started a hobby project or something on the side, you’ll just use one module. But the interesting thing about that module is, as you start adding more code to it, every single change you make needs the to recompile the entire module. As time goes on, you get to a state where small changes take so much time that you can go for a coffee break or do a lap around the office. We actually did that at Uber.

At that point, a lot of the engineers said, “Hey, this is too big. Let’s break it apart.” They started breaking things apart, but then they started seeing something interesting. Their Gradle sync times started getting really slow. Whenever they’d make a change, they’d think, “Oh my God, Gradle is telling me that the project is out of sync. I need to re-sync this,” but then it took a while. That can be a very grating proposition for engineers when they’re working, and they just want to keep working on their codebase.

KG: Like, “Oh my God, do not change your Gradle file—don’t even add a space!—because then it’s going to ask you to sync, and that’s going to take another five minutes.”

GK: Exactly. That’s the situation where we started putting stuff outside, because they had pre-built artifacts, which means that they didn’t need to read their tests or recompile it.

With scale, that came with other problems, though. If you have hundreds of libraries, it’s very hard to make big refactors in a safe, automatic manner. Whenever you want to make a change in the networking library, there could be hundreds of other libraries that depend on it. That could be very problematic, and you can break an API. And, since everything has to be compiled, you won’t even see the problem until it’s a runtime issue.

KG: Yikes. That doesn’t sound too pleasant, especially in terms of discovering the problem.

GK: For a while, I think we were still kind of in a system where we had a lot of different instances. So, to alleviate that, we had a system internally where, whenever some dependency changed, we recompiled and retested all the code for that particular version, to make sure that everything was compatible.

But that’s not really feasible as well, when you have a lot of different instances. At some point, our Gradle build times started getting ridiculous: around 20-40 minutes for a single line change.

DF: No more going to coffee! Go to get lunch.

GK: If you guys think that’s bad, look at Swift build times. I don’t know if you have any iOS friends…

KG: 20 minutes is dysfunctional. Wow! How does anyone get any work done?

GK: I we started seeing this issue back in May.

I don’t know if you guys have used the new Uber app. Have you tried it out yet?

KG: You mean the new redesign that came out? Yeah, it’s pretty slick.

DF: I used it yesterday.

GK: That app actually started out around that time. It was a brand new architecture, where a lot of the principles relied on the code being broken apart into a lot of modules. This was very worrying for me, as an Android developer, because I was thinking, “The platform team wants to bring out this cool new architecture, and they have a lot of modules coming up, but then the build times are going to suck.” I didn’t want to stop them from progressing, but…

DF: So you get to this level, break everything apart, and have all of these modules. Then you have this humongous build time. What did you do at that point to speed everything up?

GK: We didn’t even think about speeding it up at first. We just waited to see if we could make it work. We talked with the Android tools team quite a bit and tried to see if it could scale well at the longest time. But then we realized (at some point) that it didn’t scale, so we started looking at other companies that had scaled, like Google, Facebook, and Twitter. They have a gigantic amount of repos, with a lot of code, but they’re still functional. That got us interested in what they’re using to build their codebases.

At that point, we evaluated some of the automated build systems out there, and there were a couple of different contenders: Buck, from Facebook; Bazel, from Google (which they open-sourced); and Pants, from Twitter.

KG: Just so I understand, and so it’s clear to our listeners, these are all alternatives to Gradle? They’re all completely one-to-one build systems?

GK: They are all independent build systems, so you can build a lot of different Java or mobile codebases. But they’re all built by different companies.

KG: Does Bazel, the one that Google open-sourced, have anything do with Gradle? I know that Gradle is independent (i.e. it’s not part of Google), but that’s a question that could come up with the listeners: “There’s Gradle and there’s Bazel. Does Google internally use Gradle? Do they use Bazel? Do we know?”

GK: Gradle (the build system) and the Android Gradle plugin (a plugin that lets you build Android projects with Gradle) are two separate things. If you treat it separately like that, it starts making sense. Gradle is something that was open-sourced by a company called Gradleware. At that point in time (I believe), it was very easy for small projects get coding started very quickly. So the Android tools team, at that point in time, decided to create a way for extra developers to start using the system, because it was really low-friction.

At that stage, Bazel was not open-sourced yet. Google had something (which they still use internally) called Blaze. In fact, a lot of the systems I just talked about are all designed by engineers who left that team at Google and moved on to different companies. They built a very similar system, based on the ways that Google internally builds most of their codebase.

We wanted to focus more on something that would work really well for mobile, and Android specifically. At that point in time, Buck was the only one which had a lot of the features that we already get in the Android Gradle plugin, so that was something we began to take a closer look at. It had really good features. It promised so many different things, like really fast incremental builds, a lot of customizability, and being built to scale for the codebases the size of Facebook’s.

KG: You’re talking about “fast”. Do you have an approximate idea of how fast? Is it two seconds faster? A minute faster? 2x faster? Do we have any idea?

DF: Take Uber. How long is your build now, compared to how long it was before?

GK: I’ll give you a break down by different phases. When we started looking at Buck, we initially did everything by hand. We wrote all of the different files for Buck, and the build times were maybe 2x-3x faster than what Gradle gave us. That was very early on.

When you do incremental builds especially, there are a lot of operations Buck makes. There’s a thing called exopackage, which is very similar to multi-text. That was way before multi-text existed, which uploads changed class files to the device whenever you try to rebuild the project after you’ve changed some Java files. That cuts down the build time even further, and we started seeing 6x improvements.

KG: 6X?! Holy cow! Okay, just to backtrack a little, is this similar to what happens with Instant Run in that case?

GK: Instant Run is very similar, but it has a bunch of limitations. When it has anything to do with annotation processors, it basically does a full reboot, purely because the processors a lot of the Android community uses these days (like Dagger and ButterKnife) require the entire code. Anytime you change a file, it’s very hard for Instant Run to predict what’s actually supposed to be re-built, so it has to run the annotation processor again and rebuild the code again. If you notice, a lot of the samples you actually see from Instant Run don’t have the annotation processor turned on.

KG: Oh, interesting!

DF: Enlightenment just hit.

KG: So how does Buck handle that, then? I imagine it’s the same thing. Nothing has changed about the annotation processors, right?

GK: Buck actually takes a different approach to this. It knows that incremental builds are very hard to do in general. If you looked at the world of, say, Ant back in the day, you saw that incremental builds would give you correct results 98% of the time, but 2% of the time, you had to do a full build.

KG: That happens even today, and it’s super frustrating.

GK: Buck prefers really small, usable modules, so any individual module can be built or rebuilt really quickly. That means that you have a lot of flexibility with how long and how much you want to scale your build process. Let’s say that you have one giant application module in Gradle. There are some parts of that module that aren’t required to be recompiled every time, so you can start spreading things out. There are parts where you don’t even have to run annotation processors. So, as you start spreading things out, the build time becomes a function of how small you can get the modules and how many of them you actually have to build.

Which brings us into the next point about Buck: it’s very heavily based on inputs and outputs, compared to Gradle, which is task based (similar to how Ant worked). Let’s say that you want to build an Android library. Buck builds by looking at all the different inputs that are required—resources, sources, and other dependencies—and saying, “Hey, are all the dependencies currently ready for me to start building this or not?” If they’re not, it will go down one more level try to build the ones that are further down. It’s a very simple execution model that can catalyze really, really well. That’s what makes it very input/output based. There’s no more task model.

KG: Here’s a quick question then: you said that it encourages the use of smaller submodules, right? Does that mean that when I write a generic application, it would serve me better to force myself to use these submodules, or does that not necessarily matter? The alternative question is: if I don’t have submodules, am I going to see a benefit with Buck?

GK: Submodules definitely help with build times, but they’re not the only way that Buck is faster—for instance, the parallel execution model. The parallel execution model is very, very fine-grained. All it cares about is the input and the output. So, if you had multiple modules, it’s kind of like the Gradle switch that you can turn on called “parallel build”, except that Buck makes really good use of all the cores in your machine. It understands what the best way is to run all of these targets. Even when you have a vanilla Gradle module setup and you haven’t really spent time to speed it up, you typically see gains of 2x-3x for a clean build.

To actually prove that fact, we have a test project on GitHub that shows how the different build systems stack against each other. You can actually build a project with Gradle and build the exact same thing with Buck, and you can see for yourself how it makes a big difference with clean builds.

Since everything is declared beforehand in Buck (both input and output), there is no such thing as the Gradle configuration time. I don’t know if you ever saw this message: “Gradle configuring project x of y.” You wonder what it’s actually doing in the background. It’s actually doing a lot of stuff to configure the tasks, and figuring out what the inputs and outputs are, but all of that stuff is given to Buck, since the build language it uses makes it very easy for it to skip that configuration phase.

KG: That’s interesting. You said it’s highly customizable, and then you mentioned the build language. Gradle is written in Groovy, right? So Groovy is the language that’s used. Does Buck also use a language, or is it more declarative (like Android Maven)?

GK: The Buck build files are actually mostly just Python rules. It’s a macro, if you think of it that way. You can actually write Python in the Buck files.

DF: Do know what the Buck build system is written in? Is it purely Python, or what is it?

GK: The actual build system is written in Java.

KG: I know Java!

DF: No more Groovy! Yes!

GK: Even Gradle is mostly written in Java nowadays. Older versions of Gradle were written in Groovy, but almost 90% of Gradle is currently in Java.

KG: That’s interesting and surprising. I mean, I guess it’s more of a familiarity thing as well, but Groovy is supposed to be a better language. Well, actually, I shouldn’t say that…

DF: Who are you talking to?

KG: I’m probably going to get a lot of hate mail on that.

DF: From what I understand, Buck isn’t just used for building Android projects. It’s a build system, so you can use it to build both Android or other projects, like a Go project. Is that correct?

GK: Yeah, it actually supports quite a few languages, and it’s really easy to add new ones. I think it natively supports Java on Android, and Objective-C on iOS (Swift is in the works right now), along with C++, Go, Rust, Haskell, and what have you.

KG: I imagine Facebook is using this for their iOS applications, but have you seen Buck being used for other iOS applications?

GK: Actually, we have a counterpart at Uber called the iOS Developer Experience team, and they migrated to Buck before we did. So we basically have both iOS and Android builds orchestrated in Buck at Uber.

The other really nice thing about Buck, which I have to quickly mention, is that it’s really good at caching stuff. Since it’s based on the input/output rule, if the inputs haven’t changed, it reads the output as up to date. It’s similar to Gradle, but the checks are a lot faster, since they’re not based on timestamps but on the file content. Let’s say you make a build right now, change a file, and do a build. Then you later change your mind and want to go back to the previous state, and you build again. It basically says that everything is up-to-date, because it has already previously built that state of the codebase.

KG: That’s so cool! How does it do that? Since it doesn’t look at timestamps, does it use a hash or something?

GK: It maintains a hash, and it also does something else very clever. It runs a file watching service in the background (like a daemon). It’s called Watchman, and it watches certain files which are a part of this target chain. It knows before you even pick a build what has changed already, so it can make decisions really, really fast.

KG: Interesting. So this is like an additional thing that you have, beyond just the regular Buck system?

GK: You don’t really need it to build in Buck, but it actually makes it much faster, so it’s nice to have.

KG: Okay, that’s pretty cool. I know that one of the other advantages that has been for Buck is reproducible builds. How does that work? First, what does it mean? Why is reproducibility important? Why do you need it? And how does Buck provide it?

GK: Have you ever had a situation where you or another colleague adds some configuration that depends on things like the version to your build.gradle file? I know that a lot of people want to have the version of the codebase in the build.config, so they typically add it to the build.config fields in Gradle. That means that every time you build, the build.config of the Java changed, so it’ll end up being a full reboot.

Basically, we’re talking about state that’s outside of the build systems that you’re trying to build in. It’s very easy to do in Gradle. Sometimes, if you’re (say) developing annotation processors, and you include the Tool JAR, those JARs are actually different on every different machine and JDK. Your coworker could have a different JDK from you, which means that what you’re building might be slightly different in terms of hardware, which means that the actual APK that you’re building might have some differences from what you’re seeing. That can be very frustrating when you have small changes that are very hard to debug.

It’s really hard to do with Buck, because you have to be very clear to have that happen to you. The way that the build language is defined, you can’t depend on environment variables or have dynamic hardcore strings. You can’t really have dynamic dependencies that change for every invocation, for that matter, the way you can with Gradle. That’s part of the usability, which means that if I check out a particular version of the codebase and run it on any machine at any given point of time, I would always be guaranteed to get the same exact output.

KG: And this is not necessarily something you can guarantee with Gradle at the moment?

GK: You can actually guarantee it, but it’s very easy to mess up. We had an instance where we made this mistake ourselves. When we started migrating it to Buck, we realized, “Hey, why is this target being rebuilt every time?” Then we figured it out: “Oh, it’s because in Gradle, it’s not a problem. We were already used to it being rebuilt every time. But with Buck, it can get pretty annoying, especially when you’re used to really fast build times.” Anything that rebuilds that can be a problem.

DF: So I’m an Android developer. You’re an Android developer. Kaushik is an Android developer. Everyone who listens is usually an Android developer. We spend all of our day inside of Android Studio, so any time I hear about any of these new tools or things I can use, the number one question in my mind is, “Does this work with Android Studio?” Does Buck work with Android Studio?

GK: Android Studio is purely based off the excellent IntelliJ IDE by the JetBeans folks. If you think about it that way, Buck actually does work with Android Studio, but you may not see all the latest features that Studio might push out. For example, constraint layout is a new thing that Google pushed out. It hadn’t been upstreamed to IntellJ for a long time, but the latest version actually has constraint layout. Eventually, these do end up in IntelliJ, but Studio is definitely something people want to use with any build system. It does work with Android Studio in a limited capacity, but typically, we at Uber use IntelliJ instead of Android Studio, because we don’t miss the Gradle sync times. But that’s completely gone out of the picture.

KG: So you use it with IntelliJ, but I imagine you can potentially use it with Android Studio, right?

GK: Yes, you totally can use it with Android Studio.

KG: Okay, so we talked about some of the major pain points in the build system for a company as big as Uber, and we found out some of the cool ways in which Buck can help. In the next episode, we’ll actually dive into more specifics with okBuck, which makes it way easier to add a build system like Buck to your Android project. Stay tuned for part two!

067: Cross platform development with Xamarin cofounder Joseph Hill

Mon, 19 Dec 2016 05:00:29 UTC

Download directly

In this episode, Donn talks with Xamarin cofounder on how one can use Xamarin for Android development.

They start off chatting about using Xamarin just for business logic sharing. This Joseph tells us was the original intention for use. They also touch on Xamarin forms which allows you to additionally build UI elements cross platform.

Even if you don’t use Xamarin or plan to use Xamarin right away, this was a fantastic insight into the platform, from the creators directly. They touch on advantages, how to really leverage the platform and potential downsides.

This is our last episode for 2016 and we’re glad we get to end on an high note. See you in 2017!

Show Notes #

Xamarin
Developer guides (Joseph mentioned they’re particularly proud of this one)
Xamarin University
Download Visual Studio
Xamarin Forms

Notable alternatives: #

Contact #

Transcript #

Donn Felker: I have someone quite special here today. He’s talking about a topic that I’ve been very interested in getting to: cross-platform development. We’ve actually had quite a few people ask us about this. I’d like to welcome Joseph to the show.

Joseph Hill: Thanks for having me.

DF: Joseph, can you give our listeners who aren’t familiar with you some background information—who you are, what you’re working on, what you’ve worked on in the past, and so forth?

JH: I currently work for Microsoft, since they’ve acquired the company I helped co-found (Xamarin). We created Xamarin as a company focused on cross-platform mobile development. The thing that was special for us was understanding that, while people need to create cross-platform apps, they need to create native apps as well. I think that turned out to be the thing that gave the company length.

Of course, my background before that was as a C# developer and a member of the open-source community. Xamarin itself took the open-source model of technology, and then wanted people to write C# applications.

DF: Our audience here at Fragmented is mainly made up of Android engineers. We’re highly focused on that. We get a lot of questions about cross-platform development. There are a bunch of different tools for that nowadays, like Xamarin, React Native, Cordova, and who knows what else. But for folks who aren’t familiar with what Xamarin is: if you were in an elevator together, how would you explain Xamarin to another engineer?

JH: First and foremost, Xamarin has always been focused on letting developers do anything with C# that they could do with Objective-C or Swift on iOS, or Java on Android. The idea is basically a complete mapping of Android APIs to C#, giving the ability to use things like Native Android Layout, XML, Android resources, and even libraries, but with the C# programming language. The benefits to that are obvious if you’re a C# developer already; but even if you aren’t, it’s nice to have a language that’s powerful, and available on Android, iOS, Windows, and web servers, because you don’t have rewrite code. Also, it helps you avoid bugs—you don’t fix a bug on one platform and then find out months later that you still have the same bug in a different code base on another platform.

DF: You said that I can use C# to develop Android apps, but you also mentioned iOS. Does that mean that I just write the code once and compile it, and I get two outputs from the one app, or do I have to code for each individual platform?

JH: You can share code, but at the end of the day, you’re writing a native iOS app and a native Android app. Historically speaking, we started by putting C# on iOS. We wanted to enable the developers (Windows developers, at the time) who were telling us, “Hey, we need to get to iOS. Can you help us do it?” There was a temptation to just give them all the APIs they had on Windows, so that they could make ugly Windows apps running on iOS. But we didn’t want to do that. We wanted them to make great iOS apps.

At first, once we produced the iOS product, people would ask us about Android, and we’d say, “Android uses Java. Java’s enough like C#. Just use it.” But these forward-thinking developers would say, “Well, it’s about the advantages of using a single language. Plus Visual Studio is a great IDE, and I want to be able to leverage all of the benefits of this ecosystem.” So it was from that tipping point at the very beginning that we said, “This actually resonates with developers—not being ‘write once, run anywhere’, but to actually be native first while keeping cross-platform capabilities.”

DF: Let’s dig a little deeper into the weeds here. Say upper management hears about how great cross-platform development is—it’s going to save a lot of money in the future, since developers only have to write apps in one language, and so forth. If I wanted to build both an iOS app and an Android app and share some code between them, what does that look like from a developer perspective? Do I have different projects in GitHub, or do I just have one big project with shared code?

JH: In the Visual Studio build system, we have the concept of solutions, where each solution can have multiple projects in it. Android Studio follows essentially the same model, of course. When you’re working with Xamarin, you would have a head project for each platform that you’re targeting. You might have one project for your Android-specific code, another project for your iOS-specific code, and a shared project, like you said.

You can share libraries. You can either write the libraries or use libraries that other people have written which are cross-platform. You might end up with multiple shared projects within your solution. We also make a library called Xamarin.Forms. It’s an abstraction toolkit that focuses on some kinds of UI sharing, so you could share UI code as well.

But typically, you’re going to have a project with code that’s specific to each platform that you’re targeting.

DF: So I would keep pertinent business logic that applies across all projects in those shared projects. Is that correct?

JH: Right. Let’s say you’re making an app that needs to render some financial calculations, so you write some logic that creates amortization tables. If you did that on the web, you would just do it all on the server. You wouldn’t want to run calculations on the device, because you can’t trust those calculations.

But you’re going to render these tables on the phone, and you want to run the calculations locally on the device so that the user has a responsive experience when they see what the models look like or what the final costs are going to be. But you’re going to run the same logic you ran on the server, since you trust those models.

Then there’s also code sharing for things like authentication. Maybe you have ten apps, but they always run against the same user/password login system—the same authorization-granting API. So you put that logic in a library which ends up getting used across your apps. Or, if you’re in a large organization, other parts of the organization can use those same components in their apps as well.

DF: To bring it full circle (keeping it simple), we have one shared library where we have all of our authentication logic, and where we build those amortization tables and any other financial things we’re going to work on. Then, on top of that, we have Xamarin for Android, Xamarin for iOS, and so forth, which talk to those same shared libraries.

But as a developer, I only have to write that code once. Then I unit test it, or whatever, and it’s good to go. I know that it works, and that it’s going to work the same on both platforms, since both platforms talk to the same shared library.

JH: Right. Importantly, if you find a problem in your model and fix it, you know that you fixed it on both platforms. And if you’re working in a single solution and change an API in your shared code, you get feedback right away from your iOS and Android projects that those guys are still building. You didn’t really break anything that both apps are depending on.

DF: Just to make sure that I’m for with the listeners, all of this is written in C#, right? As in, is Xamarin all C#, top to bottom?

JH: Talking specifically about Android code, we expose all of the Android APIs as C# code. So, when you have an Android specific project in your solution, you write all of that code in C#.

The exception comes when you’re also using Android XML for layout. If you were using other tools for processing Android layouts, you would have access to all of those, but we’re not making you write Java code—although you can bind Java code. On the iOS side, you can bind Objective-C code. You can bind C code. All of that is available to you, but we give you the ability to just write C#.

DF: You bring up a very good point there. In Java (actually, in pretty much all of the languages now), we have a very big open-source community with tons of libraries available. Especially in Android, if you look at your build.gradle file, every project has a ton of dependencies that are pulled in—logging libraries, API libraries, and everything else. If I want to continue using libraries that I’m already kind of familiar with, since they do a great job, can I continue to do so?

JH: Absolutely. Now, they don’t become inherently cross-platform when you do that. It’s not like when you opt into Xamarin, your Android JAR files can be used by your Xamarin iOS app. But by all means, you can continue using any Android libraries you were using before.

Occasionally, if it’s an open-source library, customers will opt to port it from Java to C#, since that’s fairly straightforward. That’s also an option, and that might give you the ability to make the code more portable to iOS, but you don’t have to do that.

In fact, some of our customers who already have an app written in Java will keep a big chunk of that app, compile it as a JAR, and just start building new code in C# tomorrow. They won’t necessarily mess with the working Java code they already have.

DF: That’s important, because a lot of the teams that I work with on a day-to-day basis build a lot of Android custom views that do a specific thing in Android which we don’t really want in iOS (or isn’t even iOS specific)—think floating action buttons and Material Design things that we’ve custom built. It sounds like just I can pull those in and use them in the Android version.

JH: Like I said, there’s a gradient. You can pull those in and make them as Xamarin specific as you want, or just leave them as is.

DF: I think that when a lot of people hear about Xamarin, they’re afraid of leaving everything that they know to hop over to something like this: “I know all of these libraries, but now I’m going to hop over here, and I can’t use them.” I think that knowing you can still use them is a big win.

JH: Historically, in the case of .NET and Java, you can almost always find the same libraries in the other language, or forks and ports of those libraries. At the same time, making it easy to consume libraries as is has always been a top tenet for us. You can start with one approach and switch to the other, so it’s very easy to ease yourself into it.

DF: So you guys basically run C#, and you’re able to talk to all of the Android and iOS API bindings. But let’s say I’m building an Android app. How is the bridge made from writing C# to actually getting a native Android application? What happens and how is that maintained?

JH: At the end of the day, Xamarin uses the Mono runtime (at the core) to compile C# to Intermediate Language (IL)—like how Java compiles to Java bytecode. Then, in the case of Android, that IL is turned into ARM executables.

DF: What is IL, for those who are coming from the Java world?

JH: The Intermediate Language is very much like bytecode, but C# compiles and F# compile to it. Then it’s the job of (on Android) the JIT to just-in-time turn that intermediate representation into an actual native ARM executable.

DF: So it’s truly native? It’s not like running a WebView inside of my app?

JH: Correct. When we talk about these bindings, what we’re really saying is that we’re using JNI with that. It’s a bridge between the .NET code and the Java code. Also, we have cooperative garbage collector that makes sure that when we dispose of an object on the Java side, it goes away on the .NET side (and vice versa).

DF: Are there any performance implications to doing that?

JH: That’s what I was about to say. There’s a performance implication to speaking across the bridge. If you were in a tight loop, creating an Android button, and you made a list in an odd way, you might stack a bunch of buttons up and create all of them. There is an additional cost to doing that.

On the flip side, we have a very high performance JIT. When comparing strict C# (which is not speaking across the bridge) to strict Java, we perform at least as well. I don’t have specific benchmarks in front of me, but there are even places where C# code would actually perform better. Typically, I just wouldn’t really consider that there’s a performance cost to choosing to use C#. It really only comes to light when you’re doing something the wrong way, like I just described—where you’re doing a lot of cross-talking from C# to Java that you probably shouldn’t be. Instead, you would just take a different approach.

DF: Does the same thing happen for iOS?

JH: iOS is not JIT-ted. When we talk about JIT, we’re talking about just-in-time conversion of the intermediate representation to the ARM executable code. On Android, that’s completely allowable. Basically, you generate some code you want to execute, make it executable, and run that code.

But on iOS, that’s not allowed as a security restriction. When you start writing to memory, you’re not able to make that memory executable, which means you can’t have a JIT on the device. You could certainly generate all the code, but iOS will never let you execute that ARM code once you’ve generated it. So, we use ahead-of-time compilation on iOS. Our AOT uses LLVM, which is an optimizing compiler. It’s the same back end used for Objective-C and Swift, so (at the end of the day) you’re generating the same ARM code that you would generate from those languages. But it’s all generated ahead of time on your Mac, before it’s compiled into the app that you ship.

DF: Lt’s go back and really hop into the weeds here. Suppose I’m writing an app, and I need to put a text box into and Android form, and then get a reference from it. In Android, we normally do things like findViewById(). Then we get a reference to that, and we can work with it. If I’m doing this in Xamarin, am I working with a .NET text box or with the Xamarin representation of an Android text box?

JH: You’re speaking directly to the Android text box.

DF: So it would be like a TextView, an EditText, or something like that.

JH: And you could do exactly what you just said. It’s still “find by ID”. It’s the same resources pile, which gives you the same handles (the same IDs). That model should be instantly familiar to any Android developer, because it’s the same.

Going back to what I said earlier with Android XML, layout is also going to be the same.

DF: We still write our layouts in XML, then?

JH: Correct.

DF: From my personal experience as a previous C# developer, I know that making the change from C# to Java (and vice versa) is actually quite easy, because the languages are very similar. Personally, I actually prefer C#, which might come as a shock to a lot of our listeners. I think it’s a beautiful language. I know that my co-host Kaushik also loves C# and feels it’s a very beautiful language. That’s one thing which I definitely miss from working inside of Java for the last eight years, which is having access to the beautiful language that is C#. It seems like Xamarin gives you that ability.

JH: If you look at early versions of C#—which is probably what most Java developers who have been around for a while made their assumptions about what the language from—C# and Java look very similar. But actually, C# has evolved quite a bit. Java has even evolved to pick up some of the C# idioms. C# continues to evolve, bringing in nice features like async.

DF: Yeah, that’s a beautiful one.

JH: I’m biased toward C# (many people are), but at the same time, there is a common heritage. They’re clearly inspired by the same C-type constructs, with semi-colons and curly braces. Typically, people give it an objective look. First off, it’s something you can get comfortable with very quickly, and moving the other direction is fine as well, though you’re going to miss the features that you got used to on the C# side.

DF: Yeah, when I came over to Java, I had an array list of something and I went to go use a lambda expression, but it just wasn’t there. I found myself writing so many verbose for-loops and so forth, so I can definitely relate.

But let’s take this in a slightly different direction here. Android releases new operating systems all the time. They’ve released Marshmallow, N, etc. They just keep coming out (and will hopefully continue coming out). When a new Android version is coming out, either as a developer preview or when it’s being released, how does that get into Xamarin? If I’m using Xamarin, can I actually use those new APIs?

JH: Every time there’s a preview of a new Android release, we have a team of engineers who download it and start creating bindings right away. We have tools for generating those bindings, so it’s typically a process of coming along behind the generated bindings and saying, “This is not quite what you would expect the C# API to look like.” So we go through and refine it, bringing async into APIs that need to be async-ified. Or, if developers would expect a more delicate model for raising events or whatever, we try to bring in the C# behaviors that we think they would expect to see on top of that.

What’s really neat is that Xamarin was (of course) a proprietary solution for the past 5+ years, but after Microsoft’s acquisition of us, they open-sourced everything. So, if you watch it all on GitHub, you can actually see this whole binding process take place publicly. We aren’t just dumping this out there. We encourage the community to come participate.

DF: So if I find a bug in a particular implementation of a UI widget, for instance, can I create a pull request back to the project?

JH: Yes, please do. We would love to have those. Also, it’s nice to be in a situation where we have a community that’s anxious to have this kind of help. If Google drops a new preview of the next version of Android, and there’s an API that you’re really anxious to try, jump in! We’re here to help you take advantage of that API, start binding it, and get involved with the community.

DF: That’s excellent to hear, especially since it’s open-source now. Just to be clear, if a new version of Android comes out and it has a new UI widget, your team of engineers will hop in there and create that binding so that you can expose it inside of Xamarin, correct?

JH: That’s our priority—making sure that it’s not only exposed, but that it’s a beautiful looking API that developers want to use. But you’re absolutely free to go bind it yourself. You don’t have to contribute it back if you think we’re going to do it anyway. If you just want a quick and dirty hack to be able to try something out, you can do that as well.

DF: What’s the average turnaround time that you guys usually have when a new release is pushed out before it is available to the public?

JH: That’s a good question. We have an excellent track record of tracking these things very closely with iOS. Apple gives us a nice, long lead time. You start seeing previews that we can start tracking with our own previews in the summer (at WWDC). By the time they get close to GM, we have everything bound and most of the kinks worked out, and people can start submitting apps to the app store before the release.

On the Android side, we’ve historically lagged more behind. Because of the adoption curve of new versions, it hasn’t been as pressing that we track them closely, and we’ve never gotten publicly dinged for not doing that. But the nice thing is that, as we’ve gotten more developers on board, we’ve begun having more customers that even Google cares about. They have a vested interest in us supporting this new API soon as well, because they want to push adoption of new versions. So I don’t think we’re quite the same day yet, but I think we are in a position to be close.

DF: Would you say it’s within the month? Two months?

JH: I was shying away from that, because I don’t remember what the exact period was on the latest release. I do know that a year ago, we were out within days.

DF: That’s amazing, though. I personally don’t have a problem with that, especially when you’re creating a bridge between two different languages. A couple of days? I can wait. If I’m a C# developer (and I used to be on many C# teams), and I need to support the new version of Android, I can probably wait a couple of days afterward. Again, I know there are people who feel differently, but I don’t see why it’s a humongous problem (although the fact that you guys are trying to push forward is great).

JH: Having a community there and people who care about native development certainly pushes it forward.

DF: You mentioned something called Xamarin.Forms. Yesterday, here at the Microsoft Connect event (right now, we’re in the New York City Microsoft offices), they were saying that they had used both shared libraries (like we were talking about earlier) and Xamarin.Forms to build an application, basically allowing for over 90% code sharing between the platforms. What is Xamarin.Forms, and if I’m a new Xamarin developer, why should I care about it?

JH: From day one, we kept telling developers that they should be creating native experiences. But a lot of times, businesses would be coming back to developers, saying, “We really just want you to write it once.” So Xamarin.Forms is basically a library that we created to fit that need: giving the developers the ability to do write once, run anywhere with Xamarin when they need to, without necessarily giving up completely on the ability to do native things.

Xamarin.Forms is an abstraction toolkit that gives you layouts and controls for writing cross-platform apps. Depending on the kind of app you want, you can share up to 100% of the code.

DF: Between platforms? As in…iOS and Android?

JH: iOS, Android, and Windows UDP. The trade-off is less control over exactly how things get rendered, but since it’s still an abstraction, it’s still using native rendering. When you make a Xamarin.Forms app, you define a layout, and then Xamarin.Forms decides how to use native buttons, native text boxes, etc. So you end up with a native look and feel, even though you may not have quite the complete control to say, “This is the native behavior I expected.”

Xamarin.Forms was designed to keep those native capabilities at arms length. With the first release, we had this idea of custom renderers. As soon as you realize, “I need this screen to be native,” we’ll give you the ability to put a native screen in there. What you saw James demonstrate on stage yesterday was how we’ve made native embedding even easier. Instead of having to figure out what a custom renderer is, or how you should go about writing one (which is probably creating a new class, extending something, or whatever), the native embedding…

Actually, let me take a quick step back. Xamarin.Forms layout is done in XAML (another XML format, separate from iOS storyboards or Android XML). Typically, if you’re making your UI in Xamarin.Forms, you can write it in C#, but you can also write it declaratively in XAML.

Anyway, in his example, James took an iOS segmented control and said, “That’s the control I want. It’s iOS specific, but I want it in the middle of this Xamarin.Forms page.” So, in the XAML, he was able to start a new tag that says, “Give me the iOS segmented control right here.” On Android, that’s nothing. It’s ignored. It doesn’t exist. But on iOS, it’s going to render that control.

DF: Suppose I’ve built a nice little custom UI widget for Android and for iOS that has a certain behavior for my particular business needs. Is there a way to say in XAML, “Hey, if we’re running Android, show this one; but if we’re running iOS, show this one”?

JH: Absolutely. That’s what the custom renderer is. With the custom renderer, you tell Xamarin.Forms at the shared code level, “I’ve written a custom pie chart that renders the way my business wants it. On iOS, it’s rendered one way; on Android, in another. Give me the thing that on this platform is the pie chart.” That’s how Xamarin.Forms itself works under the cover. We give you a lot of renderers packaged in, but the community has created many custom controls of their own. So that’s how you go about doing that.

DF: Okay, let me bring it from top to bottom again for our listeners. If we start at the bottom, we have the shared libraries, which talk to our API and hold our authentication, business logic, and so forth. That’s shared across both iOS and Android. Then, from there, we’ve now introduced this new layer (Xamarin.Forms) which allows us to write our UI once and display it on various different platforms. Then, on top of that, we have our independent platforms (Android and iOS). That stack reduces that layer to a much thinner surface area. Would you agree?

JH: That’s the objective.

DF: Basically, I have very little Android and iOS specific code. The rest of it is shared.

JH: Again, we’re developers. We recognize the productivity benefits that developers want to get from sharing code, and what businesses want to get from sharing code. With Xamarin.Forms, we want to make that possible. At the same time, we recognize that when you put the app into the hands of users, they may say, “This is not the behavior I was expecting. When I’m running my other Android apps, they do the right thing. Why can’t you do that?” We don’t want developers to be stuck with an abstraction. Instead, we want to give them the power to come back and put some native polish on it, like a floating action button.

DF: So that means that if I want to implement the Material Design guidelines on Android (this is a big thing), I can add some custom renderers and have that full, nice, fluid motion; the ripple effects; and all of that stuff. Then for iOS—well, I’m not an iOS developer, so I don’t know the exact terms, but I can implement everything iOS-style there as well.

JH: Correct. That’s the power we want to put in the developer’s hands.

DF: Which brings up a question that Kaushik really wanted me to ask you: “Can you build really complex apps with Xamarin, or are you shoehorned into creating simple applications that are just forms over data?”

JH: I think that’s a leading question for Xamarin.Forms. Sometimes, developers only try the Xamarin.Forms approach since it has the same name as Xamarin. I do think it’s nice to be able to speak specifically to this topic, because that perception might be true with Xamarin.Forms—that it’s good for forms over data apps. It’s powerful for other things (like prototyping) as well, but it’s not the right solution for everything.

With Xamarin itself, the functionality is better than just a toy. We not only want you to be able to build any kind of app you want, but we want your apps to be better. Since you were able to be more productive with C#, Visual Studio, and sharing that code in more places, you can spend more time making new features, rather than implementing the same feature twice.

C# is powerful and performant. It powers a lot of games. It’s big in VR and AR. All of that functionality and power being back in the hands of the developer—that’s much more than just a toy app.

DF: For example, I recently got done with a client project: building a fitness application. Google has released an audio player called ExoPlayer, which is a very configurable audio player for Android. We played audio classes through that, because we needed to control buffering and all of this other stuff. As you said before, I can still use that library for Android with Xamarin. I can still connect to that library, do the audio playback, and everything, correct?

JH: Absolutely. The situation here, then, is finding an equivalent library over on the iOS side (if you want to have that functionality over there).

DF: So I can build those media playback applications, and I’m not limited to the Forms. Even though it’s called “Xamarin.Forms”, I’m not shoehorned into x amount of controls. I have those, and if I want to hop into fine-grained Android, I can go back and do that too.

What apps or companies that we’d be familiar with are currently using Xamarin?

JH: A lot of businesses are going mobile, so many of the stories I keep hearing are from shipping companies and airlines (like Alaska Airlines) putting devices in the hands of field workers and field engineers.

But one of my favorite stories recently has been Outback Steakhouse. They’ve written a five-star app in Xamarin. Almost every restaurant has an app these days. It’s kind of like a web page. They have to put some information on the page so that people know where to call to make reservations, and can get directions and see the menu.

But what Outback asked, “Customers have these devices in their hands. How can we provide a better experience to them when everybody has a mobile app?” The app is reviewed very well not only because it’s native and provides a pleasant experience, but because it lets you do cool things like pay directly from your phone (so you don’t have to wait for the server). That’s transformative to business. Those are the things that make being in this space now a fun place to be.

DF: I’ve worked with a lot of startups, and I get courted by a lot more. They often ask me a question: “Should we use Xamarin, PhoneGap, or React Native?” To be honest, I don’t have any experience with PhoneGap or React Native, other than just perusing the documentation. I’ve actually built apps with Xamarin, though, so I can speak to it. I know that you’re going to be biased toward Xamarin, but what’s your response to that when a company comes to you? Do you have a set of parameters, so you can say, “Well, in this case, you’ll probably want to go with React Native,” or “In this case, you’ll want to go with Xamarin,” or is it always Xamarin?

JH: I’m incredibly biased, but let me at least give you my justifications for being biased. All the other solutions you mentioned (Cordova, PhoneGap, and React Native) fall into a class of APIs that are frankly closer to (at best) the Xamarin.Forms experience.

In the world of React Native, for instance, you’re given a limited set of APIs to build your apps. If you like Javascript…I mean, it’s popular for a reason. It lets you do some cool things, and also makes for great demos. I’m biased toward C# because I think it’s a more powerful language, but at the end of the day, despite the name, React Native is not the 100% mapping of native APIs that Xamarin gives you. With Xamarin, you’re never caught in a place where you need something and can’t get to it.

The other argument people typically use is, “Well, it’s only two platforms. I don’t like writing in two different code bases, but it’s only Objective-C (or Swift) and Java. We’ve decided we need a native experience, but do we even care about sharing code?” A lot of times, people will end up with an iOS-specific app (or a Java specific app) because that was their requirement at the time—you know, “We’re buying iPads, so I know I’m writing an iOS app. I’m just going to use Objective-C or Swift, because it’s just the iPad today.”

But then, six months later, you’re done with the iPad app and everyone is pleased with it—and you have to do a new app on Android. Suddenly, your app is cross-platform, and you wish you could use some of the code that you had before: “Oh, I just wrote authentication for that app on the iPad. Now I’m going to be writing authentication and all of these web service calls again, and offering data synchronization. It’s a totally different app—except it’s not. It’s still the same model, so I’m still using the same business objects that used in the other app.”

So you’re not necessarily a cross-platform developer, because you’re not writing a single app cross-platform; but (over the course of the year) you are a cross-platform developer, because you keep having to write for this platform, then that platform, then bringing it back to the web. It’s when you’re in that mode that you realize that cross-platform is more than just trying to write one app for multiple platforms.

DF: Let’s say that I’m an engineer or an engineering manager. After hearing this interview, I go take a look at Xamarin and say, “This looks like something interesting for me or my team. I want to take us there. But we already have an existing Android application. How do we go from that native Java Android app to Xamarin? Is there any help for that?”

JH: There is help, but there’s also just the fact that Java is pretty approachable. Hopefully by now, you understand that the structure of Xamarin compared to Android with Java has a lot of similarities beyond just the language—for instance, you’re using the same Android XML.

A lot of it depends on the size and complexity of your app, and what your objectives are for getting to the other side. It probably needs to be decided on a case by case basis.

At a minimum, though you should enter this thinking, “Oh, I can file a new app, and copy over my Android XML resources and everything else that’s not the code into my new Xamarin Android project and leverage that. That’s not being rewritten. Then I can take the Java and convert that, though it might be a little tedious. You can probably find tools out there that can convert Java to C#, so that could help.

Lastly, you could get back to that part about bindings, and being able to leverage native libraries. You could just take the Java you’ve already written, keep it compiled as a JAR, and save it for porting later. Make sure you’re committed to moving over, add some Xamarin functionality, and use those two things.

DF: So you could just see if it works—kind of kick the tires a bit. That makes sense. It seems like a very viable approach, especially if I can compile at least the non-Android stuff down into a JAR and reuse it. I think that would ease a lot of pain and apprehension that some folks have about transitioning over a larger existing project.

Here’s the million-dollar question: if I’m developing for Xamarin, it’s in C#. Let’s be honest: when everybody thinks of C#, they think of Windows. Do I have to buy a Windows machine to do this? Where can I develop this? What do I need?

JH: That’s a great question. If you’re going to develop for Android, you can currently do it on Windows or Mac. We’ve now open-sourced the full toolchain, so you could even (with a lot fewer IDE conveniences) do a lot of it on Linux if that’s what you wanted to do. But from our tooling perspective, if you’re on Mac or Windows, it’s not going to be that different. You have Visual Studio on Windows, of course; and yesterday, we announced Visual Studio for Mac. That was previously Xamarin Studio, which was a mobile-specific IDE that’s very Visual Studio-like. We’re beginning to bring Visual Studio functionality into it, so that you aren’t just writing mobile apps, but are able to write your ASP.Net core back inside the IDE and share that code.

DF: That will run on Unix based systems too, with the announcements that were made yesterday that .NET will run on those systems. So it doesn’t matter: you can deploy your back-end to Linux as well.

The last real question that I have here is: are there are any real gotchas about Xamarin? Is there anything we developers should be aware of when looking into Xamarin?

JH: Way to end it on a happy note! I think that the challenges I see people hitting today are very different from what they were a few years ago. We used to get dinged on the size of the runtime, but apps are now so big that when the Mono runtime adds a couple of MB, it can still be smaller than most of your other apps.

DF: That’s a good question. How much size does it add? Just a couple MB?

JH: It starts at about 4 MB. I think we’re actually under that, and we’re constantly trying to trim it down. When you bring in portions of .NET libraries that you’re using, we use a linker to link away the portions that you aren’t, so we give you the minimum amount of Xamarin and Xamarin libraries that are needed to support your app. That does add some size, and I know that people still look at that, so you do have to be aware that that’s coming in there.

DF: Let me interject on your sizing comment there. A lot of folks who listen to this worry about the size of their Android applications and about how many methods they have. It turns into an almost religious war inside of Android itself. Personally, I’m very pragmatic about the situation. If I can gain a ton of productivity by using a different tool—Xamarin or whatever—and it’s going to cost me a few MB, at the end of the day, I don’t care. It’s allowing me to ship my app faster and be much more productive, so a couple of MB are really not that big of a deal. I think that people need to recognize that they are building something, and not focus on these minute details and tear something apart because it adds a couple of MB.

JH: There’s something we refer to as the power of defaults. We give you defaults that make things work, but they can always be tuned later. You can choose what ARM processors and API levels you’re targeting. So I pretty much agree with you: on the runtime side, I don’t think you should sweat it.

And the challenges of large Android apps are something that hit everyone, regardless of whether you are using our framework. We’re all learning together what strategies to use to reduce late loading. We all share in figuring that stuff out together. I would hope that if you’re pragmatic (and you should be), this is not something you’re sweating about.

DF: If folks want to get started with Xamarin, where should they go? How do they learn more about it? Where do they download it? What does that look like?

JH: There is of course, https://www.xamarin.com/download. You can get Visual Studio or our own IDE, Xamarin Studio, directly from there. We have a developer portal, https://developer.xamarin.com/guides/android/, which has tons of great documentation. We’re very proud of the work we put into the that.

We also have Xamarin University. Prior to our acquisition, it was a fairly expensive service that provided a lot of great instruction for learning Xamarin development and mobile development in general. That still exists, and it’s still a great product. One thing that we’ve been doing over the past month is turning some of that content into self-guided learning, so that’s a really great place to start. You can learn a lot about mobile development, development with C#, and just getting started with Xamarin by checking that out.

DF: I think it’s important to note to our listeners: as a very heavily focused Android podcast, we’re all Java developers here. But I’ve been part of a gaming company in Minnesota for years. We recently went through a big rewrite. Everything was all native Objective-C and Android Java, and we rewrote it all in Xamarin. I don’t think you should dismiss this simply because it’s a Microsoft product. It’s a very viable product, which I have used previously, all the way back to when it was just called MonoTouch. It saved me a lot of time in developing applications like that.

You’re going to have some of bugs regardless, but if you’re having problems building applications and doing cross-platform stuff, or running into business logic issues or weird platform bugs, Xamarin and Xamarin.Forms are definitely worth taking a look at. This is from my own personal experience, and it’s been fantastic.

Is there anything you would like to share with the listeners here before we wrap up?

JH: I’d just like to piggyback off of what you said there. We have a great community that’s been very passionate for the years we have been around. It’s large, and it’s been growing at a healthy clip. But when Microsoft acquired us and made everything not only free, but open source, it grew our community by multiples, so it’s a great time to get involved. There are lots of other people learning it at the same time.

People always have had concerns about our company, with a commercial product that we were charging a lot for that could go away: “Do I want to stake my business on this?” Now it’s such a big part of what we are doing with Visual Studio (and of course, on the Microsoft side, with Azure) that it’s really brought down barriers for a lot of people to adopt it. It’s been great for the community.

Like I said, any developers who care about C# being a great language aside, I think we have a good approach for the cross-platform challenges we’re all facing.

DF: If folks want to reach you, what’s the best way to do that? Are you on Twitter?

JH: I am @josephhill on Twitter. You can also email me at jhill@microsoft.com. I love Twitter and have a lot of fun there.

DF: We appreciate you coming on the show. This has been super informative. The topic has been requested quite a few times over the last year. A lot of folks want to hear about cross-platform development, Xamarin, and what we think about it. This has been a phenomenal, really good deep dive into what Xamarin is. I can’t say thanks enough, and I know that Kaushik would say the same thing if he were here. Thank you for coming on the show, Joseph.

JH: I appreciate that. I hope your audience enjoys this—and if they do, we have lots of great people in the community that you should have on your show in the future.

066: Let’s talk Immutability, Value Types and AutoValue with Ryan Harter

Mon, 12 Dec 2016 07:00:55 UTC

Download directly

In this episode, we talk to our good friend and immutability champ Ryan Harter. We start off talking about the benefits and disadvantages of immutability, then we dive into Value types and the subtle difference with Value types. Finally we close out by talking about AutoValue and how you can extend it using the super nifty auto-value extension system for functionality like Parcelability, Json parsing etc.

Show Notes #

About Ryan #

References #

AutoValue #

AutoValue
AutoValue Builders
AutoValue Factory (different from AutoValue Builders)
Difference between Builder and Factory patterns [stackoverflow.com]

AutoValue extensions #

Ryan’s blog post
AutoValue Parcel [github.com/rharter]
AutoValue Cursor [github.com/gabrielittner]
AutoValue Redacted [github.com/square]
AutoValue Moshi [github.com/rharter]
AutoValue Gson [github.com/rharter]
AutoValue Firebase [github.com/mattlogan]

Misc #

Contact #

Transcript #

Donn Felker: Kaushik, we’re back again, my friend.

Kaushik Gopal: Yes, we are. It’s another morning. What’s the time there?

DF: It’s 9:45 in the morning. It’s pretty early for you, right?

KG: Yes, it’s 6:45 here.

DF: Thank you so much for getting up that early. I know it’s difficult, especially when you’re working all hours of the night for a startup.

KG: Well, it’s enjoyable, especially when we have great guests on the show and great topics to talk about. So, who do we have on today?

DF: We have a close friend of the show, who we’ve spoken to before and know through various other channels. Today, this individual is an expert in the area of value objects, and so forth. He’s another Android GDE and an instructor on Castor.io, and is very active in the community. With that said, I’d like to welcome Ryan Harter to the show. Welcome to the show, Ryan!

Ryan Harter: Thank you! It’s great to be here.

DF: For folks who aren’t familiar with who you are, can you give us some information about your background, where you work, and how you got into Android?

RH: Sure. Let me start with how I got into Android. While I was in college, I was a Mac desktop developer. In fact, I managed all the Macs on campus. When I graduated, the iPhone was really big, so I went into mobile development. Android was still in its really early stages then, and the consulting firm I was at just didn’t have anyone who programmed for Android. So, I took up that role and became the Android lead there in 2009 or so.

Since then, I’ve struck out on my own. For the last four years or so, I’ve been a freelancer. I work with a lot of different companies on a lot of really cool projects. It’s been really good. One of my personal projects is working with five other guys in San Diego. We do graphics and entertainment apps, and one that we’re just about to release for the holiday season is called Pigment. It’s an adult coloring book app that we’re really excited about.

DF: I saw that (I think you tweeted about it or something), and it looked super interesting.

RH: It’s really fun. I wasn’t into adult coloring before, but since writing that app, I’ve been spending a lot of my free time coloring in artwork, which is also a lot of fun.

KG: For folks who’ve listened to this show for some time now, you made a guest appearance in our last IO episode. You told us some of the interesting things that you had to say, and you mentioned an app. Was that also Pigment, at the time?

RH: One of the other apps that we do is called Fragment.

DF: That’s a great name!

RH: So I hear! Fragment is sort of for the Instagram crowd. It lets you do artistic edits to your photos. You basically get to put what we call “prismatic shapes” over your photos, and they add some really cool effects and let you do some really artistic stuff.

KG: We definitely will add links in the show notes to both of these apps.

Donn and I have been really excited about this show, specifically because we wanted to talk to you about something we thought was very interesting—a topic that we’ve spent hours and hours talking about: the world of immutability, AutoValue, value types, and value objects. All of these things are super interesting, and we’ve heard that you know a thing or two about them.

RH: That sounds great. I’ve been working really closely with immutability, value types, and all of those things over the last two years or so, so it’s a topic near and dear to my heart.

KG: Let’s start off with the concept of immutability. The graybeards of our industry love this topic. They’re like, “Oh my God, immutability is the best thing. We should try to add it in, because it adds simplicity and purity.” But for those of us who don’t know what immutability is, can you tell us why we should use it?

RH: Absolutely! Simply put, an immutable object is one that can’t be changed once it’s created. It’s a really simple idea, but think about a lot of the code that you normally write. I think when most of us initially write a class, we think of it as “mutable”, or changeable—something we can set properties on. But that adds a lot of complexity that we don’t initially think about, or which may be unintuitive.

By making things immutable, or unchangeable, you need to make an entirely new copy of them if you want to get a slightly different object. There are a lot of benefits. Like I said, simplicity is a huge benefit. The reason that immutable objects are so simple is clear if you think of an object like a credit card transaction. If you can always change all of the properties of a transaction (the transaction time, the customer ID, etc.), it’s really easy for that object to get into an invalid state, because there are so many ways it can change. Immutability offers simplicity, in that you know it’s always valid once you create it. That’s one of the really big benefits of immutability.

The other big benefit (in my mind) is that immutable objects are thread safe by default. If properties can’t change, you never have to worry about another thread changing the properties of a class out from under you.

DF: Let’s take a step back. When we’re talking about how objects can’t be changed, someone who is looking at immutability as a beginner may be thinking: “Well, I can just create an object—but how do I make a particular object immutable, so that it can’t be changed?” What does it look like if I were to build this by hand? How would someone go about making an object immutable?

RH: There’s actually more complexity to this than you might initially think. If you follow the normal, plain old Java object path, you create an object which has private members (that’s important), and then use getters and setters. The most obvious (and simplest) step is to just remove the setters. That’s step 1: remove setters from these classes, because you can’t set values once they’re created.

But then we move into the things that people tend to not think about. First of all, Java classes can be subclassed by default. You need to make the class final, so that it can’t be subclassed. If you don’t, you can end up in a situation where, say, you have this credit card transaction which you thought was immutable, but some malicious programmer or developer who’s not paying attention is going to subclass that and make it mutable. So you want to make the class final.

The final thing to do is to make all the member variables final. That means that once they are created, you can’t change them.

DF: Quick question making member variables final: if the member variable is final, does that mean that I have to provide that value through the constructor?

RH: You have to provide the value at creation time, which means (depending on how closely you follow Effective Java) that it could be in the constructor or in static factory methods.

I may be getting ahead of myself, but speaking of static factory methods, one of the challenges of immutable types is that you sometimes want to slightly modify something. Maybe you want to copy something and change just one property. Static factory methods give you a really easy way to do that. You can either make either static factory methods that make another credit card transaction object (or whatever this object might be), or you can make copy methods that will return a new object, with all of the same properties (or a few changed), without changing the original object. You do have to set all of your member variables at creation time, but using things like static factory methods makes that really flexible.

DF: I’m sure someone who’s listening right now is thinking, “Well, what about reflection? Can I change these value types with reflection?”

RH: That’s one of the questions which we get in the AutoValue community quite a bit, and it’s one of the downsides. As far as I know, there isn’t a way to prevent changing these values via reflection, since you can change the modifiers by using reflection, so you can remove the final modifier.

KG: A quick follow-up question: specifically in the world of Android, immutability was initially seen as a negative thing. Why is that?

RH: One of the challenges of immutability is overhead. Since you can’t change the values of object properties, you need to make a new copy if you want to modify anything. That adds overhead for the garbage collector (and for memory management in general). That’s a challenge.

For instance, on my app Fragment, you can modify all of these settings on photos using your fingers, by brushing rotating, and all of that. Initially, I tried to use an immutable state object to record an Undo stack. That’s a pretty straightforward approach. But when you rotate, there are so many settings that are changing all the time. That adds a lot of overhead—a lot of new objects being created, and a lot of letting the garbage collector collect old objects. So, there are some cases (depending on how frequently your properties need to change) that immutability might not be for you.

KG: Basically, if you have a requirement in your application where you have a ton of objects being generated because of immutability, that may be a case where you have to rethink its applicability. In other words, are you actually getting the benefits of immutability?

Do you think that’s a fair summary?

RH: Absolutely. In the case of Fragment, I made the state objects mutable.

KG: I think I now have a decent understanding of immutability and its benefits and disadvantages.

Earlier, you referenced “AutoValue”. I know that (for all practical purposes) AutoValue is something which helps with the concept of immutability. But what exactly are these things that people also talk about called “value objects” and “value types”?

RH: A value type is an object whose equality (when you’re comparing two of them) is dependent on the values of the properties, not the actual object instance. Going back to credit card transactions, if we were to compare transactions, comparing whether they are the same instance (i.e. in the same memory space in the JVM) is unimportant. Instead, we care about whether they both represent the same transaction. I like to think of a value object as something whose importance is determined by what it represents, not its actual instance.

KG: Recently, I saw a tweet by Martin Fowler. As we all know, he’s one of the graybeards in our industry. Usually, if he publishes something, you should go back and read it, because he has some very interesting and intelligent things to say. He recently updated his article on value objects, and folks who are interested in learning more about value types and value objects, and really want to dive deep into the nitty-gritty details, should take a look at that.

I know that you’ve done some amazing work with AutoValue. So, now that we have an understand of immutability, value types, and value objects, where does AutoValue fit in? Is it basically a library that helps us with immutability? Is that its sole purpose?

RH: AutoValue is an annotation processor that basically helps you generate a lot of the boilerplate which goes into writing immutable value types.

KG: What is the additional boilerplate? If I remember right, you said it’s only setters and getters, but is there anything else that’s involved? I’m trying to understand what the benefit of AutoValue is. Where does it come into that picture?

RH: We talked about how we need to finalize everything and remove our setters for immutable types. For value types, specifically, there’s a little bit more to do. We have to override equals(), toString(), hashCode(), and all of that. We have to make sure that when we do compare objects (since this is a value object), equals() is true if the property values are equal, and that sort of thing. AutoValue will generate all of that really tedious boilerplate for you.

KG: You brought up a great point. It just hit me now. You mentioned the difference between value objects and immutable objects. I think there’s an interesting point to be made there. Immutable objects are purely about the fact that they don’t have direct references, and you cannot change the values in them. But with value objects, there is this concept of overriding equals(), toString(), and that stuff. Why would I need to do that again, just to refresh our memory? Why would I need to override equals()? If I just compare two Java objects, doesn’t that work? Shouldn’t the equals() method work, or is there something else to this?

RH: This touches on the heart of value types. The way that Java compares objects in the default equals() method is by the memory addresses of the objects. A really good way to see this is by looking in the debugger. If you set a break point somewhere in the debugger and look at a variable that you have, you’ll notice that there will be a string attached to it made up of nonsensical numbers and letters.

KG: Like a hash code, right?

RH: Exactly. That’s the memory address. Anyway, the way that Java compares objects is by comparing the memory addresses. If objects 1 and 2 both point to the same object in memory space in the JVM, then they’re considered equal.

But that’s not what a value type is. A value type says that if object 1 represents the user “Kaushik Gopal” and object 2 (a different object in memory space) represents the same user, they’re both equal. What AutoValue does is it makes that comparison by saying, “Does Object 1 match Object 2’s first name, last name, User ID, and whatever else there might be?”

KG: Interesting. So it actually goes through the fields, looks at their “values”, and then establishes that relationship if they’re actually equal, versus just asking if the “x456” reference is equal to “x123”.

RH: One of the things that makes this very important is that if you want to compare objects for both hashCode() and equals(), you want to make sure that two objects representing the same thing are considered equal. equals() is obvious, but a lot of us don’t think about hashCode(). The reason that’s really important is because if you want to use the object in a set, sets can only have one of each object. Equality is really important there and it uses hashCode() to determine that. And if you want to use it as the key in a map…when I update the values of Kaushik’s favorite things, and use “Kaushik Gopal” as the key in that map, it’s going to use the hash code to determine if it’s updating the right objects.

KG: Wow, there are a lot of details that go into these things.

DF: If folks really want to dig into equals() and hashCode() a little bit deeper, that’s in Effective Java, by Joshua Bloch. We’ve also done two episodes on that. Back in episode 31, we talked about overriding equals(); and in episode 34, we talked about overriding hashCode(). We have some content there if folks are interested.

This AutoValue stuff is super interesting, and I want to go use it immediately. How do I get it? How do I use it? How do I install it? Is it a JAR? What does it look like, in practice?

RH: As I mentioned, AutoValue is a compile time annotation processor. That means that it’s distributed as a JAR. You can use Gradle, Maven, or whatever you use to add it. One of the important things to note (especially for Android with Gradle) is that we put usually most of our dependencies in the compile configuration. For instance, you might write:

dependencies {<br /> …<br /> compile "[name of support library package]"<br /> }

You don’t want to do that with AutoValue, because it’s an annotation processor that runs at compile time. It doesn’t actually add its dependencies into your compiled APK. The reason that’s important is that when you go on something like methodscount.com and look at how many methods are in there (since you don’t want to go over the DEX limit), it doesn’t make a difference, because AutoValue doesn’t get included in your final app.

The way to do it in Gradle, then, is to use the annotation processing tool (APT) configuration. That makes sure that the tool is available at compile time for annotation processing, but is not bundled into your final app. AutoValue (which is a Google project on Github, by the way) specifically points out in both the documentation there and the documentation for all of the extensions: “Use the APT or provided scopes for this sort of thing.”

Once you have it added as a dependency, you need to add the AutoValue annotation to an abstract class. The way that AutoValue works is that you write an abstract class as your value object, using abstract methods for the properties, and you simply add the AutoValue annotation. The next time that you compile, AutoValue will generate an implementation of that abstract class for you.

So the reason that it does this is because one of the ideals of AutoValue is that it should be a transparent API. Your users (if you’re writing a library) or other developers on your team should never need to know or care that you used AutoValue to make these value objects. When you create an abstract class, you’re effectively writing the API for your value object, and that’s what users are going to interact with is your class. The fact that it is implemented by AutoValue is unimportant to users.

One of the drawbacks to this is that you can’t use constructors. Because this is an abstract class, we don’t have constructors. But that’s actually a benefit, because it allows us to follow effective Java item #1: “Use static factory methods”. With AutoValue classes, your users will simply call a static factory method to provide whatever properties they want. Then the static factory method is going to internally construct the AutoValue generated object.

KG: So this is a feature, not a bug.

RH: Exactly.

DF: If this gets built at compile time, do I check these files into source code?

RH: No, not the generated files.

DF: I guess those are put in the “Generated” folder in the build output somewhere.

RH: Exactly. Those are going to be inside your build folder. Just like you don’t check in compiled class files, you wouldn’t check in these.

KG: That makes sense.

You mentioned that I have to use abstract classes, which means I can’t use constructors, which means I’d have to build my object. In that case, do I have to use builder methods? Also, since we’re on a roll with reducing boilerplate through AutoValue, is there some alternative that I can use to doing that?

RH: I’ve mentioned static factory methods, which are great if you have value objects that only have a few properties—but, as we all know, that never lasts very long. So, AutoValue also has support for builders. Basically, this ends up being another abstract class which you annotate with AutoValue builder annotation, and it generates a builder class for you. This builder, if you’re unfamiliar with the pattern, basically allows you to set all of the properties via methods, and then (once those are all set) actually build the final object.

There are other languages out there that use named parameters when you call a method. Java isn’t like that, right? You don’t say, “Create User. First name: ‘This’. Second Name: ‘This’.” You just list them in order, which gets really confusing when you require a whole bunch of strings, or something like that. A builder lets you set those properties by name, so it’s really fluent and easy to read.

AutoValue can generate that for you. Just like the AutoValue classes, the fact that you used it to generate the builder is unimportant to your users. It’s another abstract class that you simply write the API for, and AutoValue generates the code backing it.

KG: That’s a very interesting design goal. Technically speaking, because it’s an abstract class, I could come back tomorrow and say, “Actually, I don’t want to use AutoValue”, and swap it out for something else, but my API has not necessarily changed.

RH: Exactly. That’s one of the core tenets (and benefits) of AutoValue. For one of my clients, I wrote an SDK that customers were using. We used AutoValue to create these immutable value types, and our customers never knew or cared. If at some point we needed some functionality—say we needed them to be mutable instead of immutable—and AutoValue no longer fit, they were abstract classes, so we could just create our own implementation and the customer never knew.

KG: That’s pretty slick. One last question I had about the implementation of AutoValue. I haven’t used AutoValue as much as I would like to, but I have noticed that generated classes have this “autoValue_” prefix. What’s the deal with that?

RH: The autoValue_ prefix is for the classes that AutoValue generates behind the scenes. But as we mentioned, given this ideal of a transparent API, your users will never use that; and you, when you use that class elsewhere, won’t use the prefix. You’ll use it internally in your static factory methods; and when you want to construct the actual implementation of your abstract class or builder, you use the autoValue_ prefix. But outside of your implementation and the AutoValue annotated abstract class, you wouldn’t use that.

Actually, you can’t. The classes that AutoValue generates are package private. This is part of their transparent API. If you distribute a library that uses AutoValue to generate its immutable model value types, users are never going to see the implementation because they’re package private.

DF: You talked about a couple of the benefits—mainly about the compile time only dependencies, the invisible API, and that users never know that you’re using AutoValue. What are some other benefits? I’ve been an IntelliJ user for a long time, and I wondered right away: “Why don’t I just use IntelliJ templates? What’s the difference?”

RH: IntelliJ does a really good job of creating templates and generating all of this for you, but here’s the challenge: suppose you’ve made an immutable value type. You used IntelliJ to generate getters, setters, equals(), hashCode(), toString(), constructors, and whatever. Then, six months later, you need to add a property. Now you have to add that member variable into the class, and you need to remember to delete and recreate the existing toString(), hashCode(), equals(), etc. The challenge is that it’s really on the developer to remember that they need to regenerate all that any time they update anything in the class. The AutoValue ideal is that that’s a waste of developer energy. If we can generate all of this stuff, we can do it every time we compile. That way, it’s always up to date. You never have to worry about forgetting to update the equals() method.

DF: Oh man, I can imagine how many times that would come back to bite you.

KG: Yeah, I didn’t think about that, but you’re totally right. If you change that object later on, it’s going to be a pain.

While we are on a roll with these benefits, what are some other benefits? I know we briefly touched on the thread safety thing. Are there any other points you want to add in respect to thread safety?

RH: Just to reiterate, now that multi-threading is so easy, thread safety is a big concern. Suppose you have a value type (say the credit card transaction), and some other thread (say a service thread, or something like that) changes properties on that instance. Then you run into issues. You can never be certain that the value you’re showing in the UI is current. But since AutoValue creates immutable value types, it gives you thread safety for free. You know that if you have an instance of an AutoValue type, it’s always going to be valid. It will never be out of date.

DF: That’s true. It comes back to immutability.

In a blog post last year, you announced AutoValue extensions. What are AutoValue extensions, how do I use them, and why are they useful?

RH: AutoValue by itself is super useful, and I’ve been using it for a long time. But it does one job (which it does it very well): generating immutable value types. As an Android developer, that’s difficult for me, because I want lot of the value types that I’m interested in to be Parcelable, for instance. That was the big driver behind extensions. I can get into some of the details about that a little bit more, but the basic idea is that I wanted more from these implementations. I wanted to be able to customize them to fit my needs.

About two years ago, I went to the AutoValue project, which (as I mentioned before) is a Google project that’s hosted on GitHub. I noticed that there were other people asking for extensions, so that they could extend AutoValue and what it can do. The alternatives of the time were forks of the project—other projects that copied the implementation of AutoValue and extended it to different needs. But the problem is that that’s not mix and match. If I want Gson support and Parcel support, I have to pick one or the other, because these are forks. They don’t work together.

KG: It’s extending vs. implementing.

RH: Exactly. So one summer, I ended up working on AutoValue, writing extension support into it. The idea here is that there are other annotation processors which you can add on to AutoValue. AutoValue does a lot of stuff internally that’s really unimportant if you’re a user. It doesn’t matter what you name the methods, since it figures out if there is a builder present. All of that stuff is done really well internally, so it’s very flexible.

What these extensions do is hook into AutoValue, after it’s already figured out all the details about your annotated classes, and provide added functionality. A good example of this (actually, the first extension that was written) is the AutoValue Parcel extension. What this did, like I said, was add Parcelable support to AutoValue.

One of the things that I wanted to do with this was to make it super easy for developers. If you want Parcelable and Gson in addition to AutoValue, I didn’t want you to have a 180 character long line of annotation that you’re adding. Basically, since this ties directly into AutoValue, all you have to do to make an AutoValue class Parcelable, using the AutoValue Parcel extension, is add “implements Parcelable”. That’s it. The extension is will know when that’s processed that it needs the Parcelable bits generated too, and it’s will do that automatically behind the scenes. You’ve literally added two words to your class, and you get it all for free.

KG: That’s pretty slick.

DF: That’s like magic.

RH: That’s certainly the goal.

DF: I’ve used AutoValue Parcel, so thank you for that. It works fantastically well. What other extensions are available?

RH: When I wrote extension support, it was prompted by Parcelable, but that’s not the only thing it covers. It was meant to be flexible. One of the things I did right off the bat—not only to make it useful for me, but also to demonstrate this flexibility—was to write extensions for Gson and Moshi. If you haven’t used them, they’re two JSON serializers. If you work with any sort of Web API, you’ve likely worked with JSON, and probably even used one of these already. What those extensions do is generate type adapters, so that you have a type-safe way, without reflection, to serialize and de-serialize your value types in Gson or Moshi. That’s a really useful extension.

Another extension is for Firebase Datastore. I’ve been using it on my latest Firebase projects, and it’s really useful. It lets you easily get your value types from and put them into the Firebase Datastore. If you use SQLite instead of Firebase, as many of us do, there’s also AutoValue Cursor. It helps you read value types out of cursors and write them to content values objects, so you can write them into your database.

Lastly, there’s an extension by Square called AutoValue Redacted. Since Square works with finances, if they log or print objects using the toString(), they have a need to exclude certain values, like account numbers and things like that. Redacted adds another annotation (the “Redacted” annotation) that you can put on any property in your AutoValue class, and that property will not be included in the toString().

DF: Do you know how many times I’ve written that myself?!

KG: That’s so cool! I can add Redacted to all my passwords—and maybe my music choices!

DF: I’ve been using AutoValue for a while, but I recently ran into a couple of developers who are using a different library called Project Lombok. From what I can tell, it looks like an annotation processor that does similar things, like reducing boilerplate. How is this different from AutoValue?

RH: Project Lombok does very similar things to what AutoValue does. Its goal is to reduce boilerplate, and it actually does a lot more than just value types. It will generate a lot of what your class needs—constructors, different types, and all sorts of stuff like that. What’s interesting about Project Lombok is that it masquerades as an annotation processor, but it’s not a true annotation processor, in the sense that it doesn’t comply with the annotation processing tool spec. The documentation for Java and Java SE says that an annotation processor can generate new classes, but that’s all it can do. It can’t modify existing sources. That’s the underlying reason why AutoValue uses abstract classes and provides an implementation, as opposed to letting you annotate any class and providing the implementation within that class. That’s forbidden by the spec.

Project Lombok has found a hack for this. They use private APIs in Java SE and the Eclipse Compiler for Java (ECJ) to modify the abstract syntax tree (AST). Basically, an annotation processor is provided an object-based representation of your source code—things like a class object, which has method properties on it that represent all of the methods within your class. An annotation processor has those provided so that it can learn things about your class and source code, and then generate a new class. That’s how AutoValue works.

Lombok uses these private APIs to actually modify the AST. With Lombok, you’re not using abstract classes and getting a different implementation. You actually annotate the class itself, and it modifies that in the compile phase. By the time it’s written to the class file, it actually has the implementation.

That’s actually one of the reasons I don’t use it. There’s some inherent risk there. It’s using these private APIs, and using the annotation processing tool in a way that’s forbidden. If you want to use it (a lot of people do), that’s perfectly fine. You don’t really have to worry about your app breaking at runtime, since this is a compile time thing, but you still risk having to re-implement everything.

KG: So you’ll know beforehand if things go wrong, but if they do, it potentially involves more work. Also, Project Lombok has been around for some time, so it isn’t like, “Oh my God, this is going to break with the new release of Android Studio or something.” Things aren’t going to break. But that’s good to know.

RH: It’s a great project. I know a lot of people who have used it, and I’ve even used it in the past. It’s a personal choice.

KG: You know what I think the true genius behind Project Lombok is? It’s the fact that they have “Project” as a prefix! When you create anything, calling it Project X immediately adds so much legitimacy. I think Project Lombok sounds much better than just Lombok. If you build something called “Project AutoValue”, I’ll that, because it sounds pretty legitimate.

I want to just remind folks that, while we’ve talked about AutoValue a lot, AutoValue is part of a suite of libraries that Google has created. It’s a collection of source code generating tools. So there’s AutoValue, AutoFactory, AutoService, and Common. This is the whole suite that they made—out of which, AutoValue is one that most Android developers have found tremendously useful, especially if it’s in conjunction with an extension like AutoValue Parcel.

RH: Yeah, it’s a great suite of tools. I actually use some of the other tools. All of my extensions use AutoService.

DF: I’ve used that before too, as well as AutoFactory.

KG: Ryan, this was amazing, and I think we could keep going on and on. I have so many interesting questions to ask. But I figure that you’ll have to get to work at some point, so we don’t want to keep you on. Thank you so much for coming on today’s show and helping us understand about AutoValue.

RH: Thank you for having me! It’s been great being here.

KG: If our listeners want to reach out to you with more questions, or want to ask for more ideas and stuff, what’s the best way to do that?

RH: The best way to reach me is on Twitter (@rharter).

KG: Perfect. You also have a blog where you write some amazing posts.

RH: I do. Since I started doing Caster, I haven’t been writing as much, but my blog is at ryanharter.com. In addition to Caster, there’s some really good information about AutoValue and lots of other Android coding topics there.

KG: I hear that if folks actually want to meet you in person, there’s going to be an opportunity soon.

RH: There is! I go to a fair number of conferences, and I have to travel so far to get to them that I thought it was time we had one here in Chicago. I’ve been working with some other great developers and organizers, and we’re going to be hosting Chicago Roboto on April 20-21. It’s going to be the first Android developer conference in Chicago, so that should be a lot of fun. We’ve got great keynote speakers lined up, like Jake Wharton and Jesse Wilson. You can go to chicagoroboto.com to order your tickets, submit a talk, and get more information.

KG: Fantastic. Thank you so much again for coming on today’s show.

RH: Thank you for having me.

KG: Alright, that’s all for the show, folks. We’ll catch you in the next episode.

065: Developer Platform engineering with Ty Smith

Mon, 05 Dec 2016 05:00:17 UTC

Download directly

In this episode we talk to Ty Smith about all things Developer Platform. Currently a tech lead at Uber, Ty has quite the illustrious career having worked on some of the biggest names you’ve heard like Uber, Twitter(Fabric), Evernote, Zagat etc.

Unlike regular client app development, Developer Platform spans a variety of interesting topics like building consumable SDKs, building libraries with good APIs, creating Android integrations and App to app communication via components like Content Providers, AIDL Integrations, Intent APIS and deep links.

We ask Ty how he got started in this field, how one should go about thinking about it and the interesting challenges that one would run across in this intriguing field.

Show Notes #

Ty’s all star Dallas crew #

Chris Banes [@chrisbanes] previously on FriendCaster
Chris Arvin [@ChrisArvinSF] previously on BaconReader
Juan Gomez [@_juandg] on Netflix
Matt Wear [parallelcross.com] prevoiusly on Evernote

Developer Platform #

Tests? Ain’t Nobody Got Time For That! by Ty Smith [youtube.com]
Content providers [developer.android.com]
AIDL (Andorid Interface Definition Language) [developer.android.com]
- TransactionTooLargeException [developer.android.com]

Contact #

Transcript #

Donn Felker: Okay, here we are again. How are you doing, Kaushik?

Kaushik Gopal: I’m doing well. How are you?

DF: I’m doing really well. I’m very excited about today’s topic. It’s something I’ve dabbled in for a couple of clients, but not at the level of the gentleman who we have on today’s show.

KG: Yeah, this gentleman is known for having a sound understanding of the subject.

DF: Definitely. Let’s go ahead and introduce him before we really dive in. Ty Smith, welcome to the show!

Ty Smith: Thank you, guys. How are you doing today?

DF: We’re doing well. Thanks for coming on the show. For folks who haven’t been introduced to you, could you give a little background information about yourself? You know: who you are, where you work, and where you’ve worked before. You have quite an impressive background in Android, and learning a bit about it would be a great help.

TS: Sure. I’m currently a Android engineer at Uber. I’m the tech lead on the mobile platform’s external API, which is our group that focuses on external partners and how they integrate with our platform. I’ve been working for developer platform related companies within the Android space for quite a while, but before that, I was just doing pure product development on Android.

The very first step I took is actually a pretty funny story. I was working at this small consulting company as a Ruby on Rails developer. I was going along my merry way, not worried about the really hard world of mobile. I wasn’t worried about fragmentation or anything else.

KG: No concurrency training. No main threads.

TS: No semi-colons. Ruby was nice! So my boss, the founder of the company, came to me one day and said, “Hey, we’ve got this pretty large client.” You guys may have heard of Zagat. They’re a restaurant review company based in New York. They were purchased by Google years after I worked on the project.

Anyway, he said, “We secured this project. We were subcontracting, working on the Zagat app, and we hired this Android contractor.” This was 2009, so Android was pretty fresh. I think we were working with Android 1.6 on an LG G1. “We hired this contractor, but due to some issues, he’s going to have to step off the project.” This was two or three weeks in. “We have a really tight timeline. How do you feel about learning Android and shipping the first version of this in 3-4 months?” I think I said something to the effect of, “I don’t think you’re really asking my opinion.” He was like, “Well, that’s the state of the world.” So I dove right in and worked on it. I don’t think we made it on time, but it went out and worked fine. It was great.

I stuck around at that job for a little while, working on a few other small app contracts. Then I ended up moving to the company that had contracted to us for Zagat. It was a small company out in Texas, called Handmark at the time. They ended up splitting off into another company called OneLouder, which you guys may have heard of. Chris Banes worked on a Facebook app called Flow that they purchased, which then became FriendCaster. So I worked on Zagat directly there for a little while, and then I worked on an app for Sprint. They were a big partner with Sprint to write their SMS, MMS, and group messaging app.

It was almost amusing, because several names who are pretty well-known in the Android community worked there with me at the time. When Chris Banes’ app was bought, he helped out for a little bit as a contractor. Chris Arvin did BaconReader, which they bought. Then he went to Expedia with Dan Lew. Juan Gomez, who is now at Netflix, came in there to take over the project I was on right as I left. Matt Wear was another guy in this community. He was at Evernote, and is now at HomeAway. So there’s this tiny little Dallas based consulting company who had a few of the Android community folks float through.

KG: Wow, that’s an Android all-star crew there.

TS: Yeah, it was interesting. After a year or so there, I moved out of Texas into the Bay Area. That’s when I got my first taste of Silicon Valley life. I joined Evernote to do Android work. It started with normal product work—doing different features and design-related stuff. I was there when we did the Holo redesign, which was interesting. That was a fun project.

Then I started working a lot on business development and Partner Integrations for different specific partners who we worked with. I started working with the developer relations folks, and developed a passion for interacting with external developers and for these integrations. I began to see how Android could really become a platform there. I thought, “Wow, I really like this developer advocacy and ‘Android engineering as a platform’ perspective.”

After I worked there for a couple of years, I moved to Twitter and worked on Fabric, which I’m sure most of you are familiar with. It was a very small team at the time, right after the acquisition of Crashlytics. I worked pretty heavily, and saw it move from a single SDK to a suite of SDKs. Now, finally, I’m at Uber, working on building a new developer platform. I’m trying to make Uber a platform and build strong use cases that people want to integrate with. It’s pretty interesting.

DF: If you had to explain what a developer platform is to someone who’s just getting into Android development, how would you do it, and why would they want to use it?

TS: I think there are a few different elements to a developer platform. There are all the APIs, docks, and everything else that you expect to be able to interact with. But you have these different companies who view developer platforms in slightly different ways. Some companies build tooling, and that’s their primary value—companies like Optimizely, Leanplum, BuddyBuild, and even Crashlytics (before they were acquired by Twitter). Their primary job is selling an SDK, an API, or some sort of other developer tool to their audience. For those companies, their developer platform and tooling is their lifeblood.

But then you have other companies—like Twitter, Facebook, and Dropbox—who see the developer platform as a way to extend outside of their core competencies and build up power users who have multiple integrations. They try to encourage new apps to build in and create a stronger platform with higher retention.

So you have these two different perspectives. The bigger companies (which I’ve been working with more recently) view it as just one other way to acquire users and then provide value to them. But some of the other companies (which I’ve invested in and give advising to) focus more explicitly on the developer platform as a tool that’s directly served to their customer, which they try to make revenue on.

KG: You summed it up really well. So essentially, there are two aspects to this: there are companies who want to expose a service that they provide (for example, Uber exposing the service of using Uber) as a platform; and there are companies that provide with developer tooling as a product.

So developer platforms actually encompass both business development support and the whole SDK, along with any integration that had to be done on the back end. Essentially, any company that has an API that’s consumable from the outside needs to up their game on the developer platform scene.

TS: It depends on the company. I mean, for a long time, Twitter just had a restful API that people could hit. It wasn’t until after the acquisition of Crashlytics that they started building multiple teams which were focused on how to give a good development experience to mobile developers (as well as, potentially, server developers).

KG: That’s a good distinction.

TS: It definitely went through its ups and downs, but the main third-party library for consuming the API (Twitter4J) was completely community developed. It wasn’t until Fabric that they started bringing some of that in house, saying, “How can we control this piece of the platform?”

DF: A lot of folks who listen to this show are on teams that are either building or wanting to build some type of developer platform—or even just an SDK that they can ship to other users. I know that you’ve worked on these things at the various companies that you’ve worked at. I’d like to start discussing what the best way would be for folks to build consumable SDKs for different developers and teams.

The reason why I want to talk about that right now is that I’ve actually had a small bit of experience doing this for previous clients. We had built some things with AIDL services, content providers, and all kinds of different ways to expose data. But I was wondering if you had thoughts on what you would consider most important when you’re building and shipping these SDKs. Is it stability? Is it a consistent API? Is it package visibility? Is it testing? Is it hosting? Let’s hop into that for a little bit.

TS: I think that stability is probably your number one concern. This is incredibly important for a few reasons. First, when you roll out an SDK, you’re rolling out a binary to a hosted location. Say you’re on Maven Central, and people are consuming it. Maybe you are even just putting out the source code on Github, and you don’t have a binary. But you put this out in a steady state and say, “Okay, I have an SDK that my customers should start using.”

Now if I’m an app developer and push out a crashy update, I can notice that. I can check Crashlytics or Bugsnag. I can see that I have bugs, get user reports, and (potentially) roll out a fix pretty quickly.

But when you roll out an SDK that has issues, the developers that are consuming it aren’t thinking about it past the point where they integrate it. That’s not the business value that they’re providing. They just want to include it so that they can get some analytics, load an image, do some dependency injection, or whatever use case drove them to do that. But once they’ve put it in (with very few exceptions), they’re not actively thinking about it, watching the new releases that you’re putting out, and seeing the communication that you’re trying to drive to your community. If you put out an SDK that crashes—one that’s a horrible experience for the consumers of your customer’s application (your customer being the developer)—this application may be their lifeblood. They may be indie developers who are making their income off of this, and you’re causing a poor experience for their users.

KG: It isn’t just indie developers, though. Even when you work at a medium-size company (like I do), if an SDK or a library that you use crashes, you immediately lose all faith in it. The whole idea is to save our time. We don’t want to actually build this on our own (which most engineers typically love doing). The only reason to use it is so that you don’t have to deal with the problems—and the minute the library starts crashing, it becomes your problem. That’s a big no-no.

DF: It’s like a black box, too.

TS: Absolutely, depending on whether it’s open source or not. But one of the bigger problems with that is that once it’s crashing and you push it out, it may not be a clear crash. What if your SDK needs to talk to a web service, and you’re improperly using the Alarm Manager, the Job Scheduler, or something like that, and you start DDOS-ing your own web service? You have to try to communicate to the different implementers of your SDK that, “Hey, you guys are seeing a lot of users. Because you’re seeing a lot of users, we’re getting a lot of traffic on our SDK. But we had a bug in our SDK, so you need to put out another update.” That’s a terrible relationship to have with your developer.

Even once you put out the update, it may be weeks or months before they see there is one. Then, if they’re not on a regular build train, it may be months more before the update is out in the wild. So if you put out a crashy update, the crash might be out in the wild for months.

KG: Just thinking about that sends shivers up my spine.

TS: What that makes you do is think about strong engineering rigor. Test the quality of your APIs. Dogfood them. Get really strong user feedback. It instills a lot of the other qualities that you have to think about when you’re building SDKs.

KG: I have two quick follow up questions. First, when you’re building an SDK or working on developer platforms, does that mean that you can’t afford to move as fast as startups typically do? For example, if you’re building a front-end consumer product, most startups intend to accelerate at neck-breaking paces. They understand the trade-off: “Sure, if we move fast and release a feature, sometimes there might be crashes. We’re willing to accept the pain that’s associated with users facing that crash.” That isn’t necessarily a luxury you can get as a library or SDK maintainer. Does that mean that you intentionally slow down your pace, or do you try to adjust that by having more tests?

TS: I think it requires a different mentality, honestly. I believe that you can still move quickly while testing. If you’re thorough in your architecture and hire the right quality of engineers, it’s possible to write testable code in a well-architected, separated way, so that you can have confidence in it and sleep at night, even when you’re on call while moving at startup speed.

I gave a satirical talk on this at Square last year called “Tests? Ain’t Nobody Got Time for That!” It was about the other qualities that having to test your code makes you think about. Once you get into the mindset of separated, proper interfaces with modular, more maintainable code, it actually becomes somewhat challenging to go back to thinking about coupled spaghetti code. In my mind, it’s made me a much better engineer to think about systems in this way.

Maybe you can’t move quite as fast as someone who’s constantly pumping out features, but in the end, they’re thinking about different product requirements than you are. They’re retaining users by having new features to compete against their competitors. You’re retaining your developer users by building developer trust, ease of integration, and a developer community.

KG: That makes sense. Second, you mentioned that when your interface crashes, you use something like Crashlytics to see what your crash metrics are. I was curious: if you develop an SDK and discover a crash happening, how do you monitor that on the other side of the equation? For example, if my app is crashing, I use Crashlytics—but can you use Crashlytics inside your SDK?

TS: I think there isn’t one straightforward answer to that question. In general, I think that putting analytics in an open-source SDK would be viewed pretty negatively. One of the conversations that I had at Twitter when we were putting out the Twitter single sign-On SDK, the embedded tweet SDK, and all of that, was, “How do we record impressions on the different things? From a business value, we care about that, but developers may not want this open-source library that they’re including to be sending up analytics events.” I think there is a balance to be had. You have to be clear with your developer community as to what you’re tracking and why you’re tracking it, so that they can trust the transparency that you’re providing.

But when it comes specifically to crashing, that’s difficult as well. When a Java crash happens, the UncaughtExceptionHandler is thrown. It’s a global system that’s going to handle it from that point. So when you use something like Crashlytics, it makes it pretty easy to see, “Hey, we had a crash in our code,” and they can funnel that stack trace down, such that the SDK or the developer app can get information on the crash.

But that’s a unique case, where the platform owner sees that. When you’re developing something like the Evernote SDK or the Uber SDK, it becomes a lot more challenging. You have to rely a lot more on communication from your developers, who see the crashes going on. I can imagine scenarios where you would do things like install your own UncaughtExceptionHandler and then wrap their UncaughtExceptionHandler, but there are a lot of edge cases that could come along with that. You could have conflicts. You could be dual-reporting. You could prevent their crashes from going up. I’m not saying that you shouldn’t, and I’m sure that some companies have figured out how to do that the right way, but I think that relying on communications from your developer community is paramount.

DF: Naming is one of the hardest things in software, it seems. There are a lot of arguments about how you should name things. In your experience, have you come across any tips or tricks about accurately naming something? What are your thoughts on that?

TS: It’s a little more complex when you’re dealing with SDKs or libraries than when you’re just managing your own project. It can be a really big problem when you put out an API in one version, and then say, “Oh, I have a better name for that”, and change it in the next version. Suddenly, you’ve broken the consumer side when they auto-update. Once you put a name out, you’re stuck with it unless you want to deprecate it. I think that having a better name is not a very good reason to deprecate a method! So putting out some guidelines up front on how you want to name your call-backs, how you want to engage with your methods, or how you keep some consistency between multiple platforms (such as iOS and Android) is pretty important, so that you have a general environment that people become familiar with.

There’s a funny saying that I like to throw around. I don’t know where I originally heard it, but it’s that an API is like a baby: they’re fun to make, but you have to support them for 18 years.

KG: That’s so true. Breaking APIs can be a big problem. A simple method change essentially translates into breaking an API, right?

TS: Yeah, adding new parameters, removing them, changing the name…the list goes on. When you put something out there, you’re stuck with that for a while. You don’t always have the best name. Sometimes, you just have to suck it up and move on. But having some guidelines on how you want to build that out, and having consistency between those, is going to give a much better experience than iteratively trying to choose the best possible name.

KG: I imagine things like semantic versioning also help. People understand that if it’s moving from 1.0 to 2.0, something is breaking. The expectation is that some API is broken, so there’s some level of effort involved in adapting your code.

TS: That’s true, but in practice, I find that very idealistic. I stick with semantic versioning (like everyone else), but I see projects all over the place (even very well known projects) that do breaking API updates in minor version updates or patch updates. Also, especially when you have a broad range of users, not all developers understand that a move from 1.0 to 2.0 implies that it’s broken. Even with a broad range of shotgun communication—where you’re updating your changelog, sending out communications to the consumers of your SDK, and talking about it on Twitter (or the other channels that you frequently use for engaging with people)—you’re still going to run into people who have problems with it.

KG: You touched, offhand, on hosting in Maven Central. You said that if something is open-source, it’s probably on GitHub. Could you tell us about some of the options that you have as someone who maintains an SDK? What are your different options to host an SDK; and, in your experience, which options have worked pretty well?

TS: There are a couple different binaries that are pretty prevalent in the Android/Java ecosystem. One is the standard JAR, and the other is the AAR. We also have the APK library, which was an older format from when more people were using Maven. That was kind of community inspired, but it’s not really prominent these days. AAR is going to be more useful if you’re doing any sort of resource or view related work, whereas JAR is probably just fine if you’re doing pure Java. Depending on how you want to set up your Gradle builds to generate your SDK, AAR is probably simpler if you actually want to reference Android classes. Otherwise, you have to try to do source linking and build a Java project if you want to build a JAR that still references context, activities, or stuff like that.

But once you have your binary, there are a few different options (like you said). Maven Central and JCenter are two prevalent ones, but they both require you to have an open-source library. There is no concept of an induced license agreement acceptance or terms of service acceptance. As a consumer, you put in the Gradle dependency, the Maven dependency, or the Ivy dependency, and it’s consumed. There’s an explicit acceptance of the Terms of Service. Therefore, those hosting providers require that anything uploaded to them that’s available in the default repos be open-source. So if you’re open-source, it’s not too bad. You can just put it in Maven Central or JCenter.

I find that JCenter is slightly easier to work with. They have better plug-ins. The Gradle plug-ins are now hosted out of JCenter as well, I believe. It’s kind of a superset of Maven Central and some others. But Maven Central is a little bit more traditional—a little older. There’s still a lot of tooling that references it directly, so you have to add in JCenter manually. I don’t have a strong suggestion towards one or the other.

But if you aren’t hosting an open-source SDK, it becomes more problematic. You have to host your own repo, which would commonly be used by Artifactory. If you want to host it yourself, I’ve seen companies that just throw up an S3 repo with the Maven structure in it, but it becomes more of a headache.

KG: In fact, one of the options that you have (obviously, this wouldn’t really work with large commercial applications) is JitPack, which is something Donn suggested to me sometime back. It works perfectly well. They alleviate a lot of the boilerplate and nasty setup that’s required to host your stuff on Maven Central or JCenter. But obviously, JitPack is not a standard. It’s privately owned. That’s something to weigh in and think about.

TS: I’ve consumed a few things from JitPack, but I’ve never hosted anything on it. But it’s pulling it from GitHub, and I’ve heard stories of GitHub getting onto people who are using it as a hosting repository when higher amounts of traffic start going to it. That may be better for a small open-source library, but my intuition is that if you’re building a company’s developer platform, and you started getting heavy amounts of traffic to it, you might have representatives from GitHub knocking on your door.

KG: I think that they only pull from GitHub when you make a change, and then they cache it, but I could be wrong. I’m not entirely sure of the internals, but it would definitely be something to keep in mind.

TS: If that’s the case, that might alleviate the concern that I had. But one of the negatives for the user is still that they have to explicitly add the repo, which complicates the build sculpt and increases the complexity of the integration. Especially as you’re trying to target a broad range of developers, that’s something that you want to minimize.

DF: Now that we’ve talked a bit about building SDKs, sharing them, and other high level stuff, let’s hop a bit more into the weeds and talk about when we want an app to talk to another app. One of the primary examples of this is an app that has some type of single sign-on. Have you ever built anything that has single sign-on? If so, what were the main benefits of doing so?

TS: Yeah, I’ve worked on the Evernote single sign-on, the Twitter single sign-on, and the Uber single sign-on, so I have quite a bit of experience with that! I’ve also contributed, both through security reviews and pull requests, to Facebook’s and Dropbox’s, along with a few others.

DF: How does that work? If you build one, what does it look like? If I want to implement that in my application for my developer platform, what are the steps, tools, and concepts that I need to be aware of?

TS: The primary benefit to a third-party developer is to allow their users to authenticate against a third-party app with less overhead. Let’s say that you wanted to integrate with the Uber API. You have a couple different options. You can include the Uber Android SDK and hit some wrapped APIs.

But maybe you want to get the status of a trip that’s in progress, so you need to get an authentication token, such that you can check on the status of that trip. With the Uber app installed, you can navigate the user directly over to the Uber app, where they’re already signed in. They can authorize your third-party application, granting the scopes that are required for the information that you’re expecting, and then return the authorization token back to your application. Then you can make the API requests on behalf of the user.

Normally, you would want to some sort of graceful fallback for that, so that if the app was not installed the user would be able to complete the use case as well. For instance, when the app is installed, you take them to the app and have an experience for them to authorize the scopes. But when the app is not installed, you take them to an oAuth WebView where they can enter their credentials, and it will still return the authorization token so you can make the API request.

Let’s say that the second one had more overhead to it. Maybe you were using Chrome tabs, and they would have to sign in there as well. That’s a little extra complexity.

DF: In the first use case, that’s going to be a deep link, correct?

TS: It can be a couple of different things. It can be just a standard URI (a deep link), where you’re either using a universal deep link (with the app overwriting a specific HTTP URL that’s equivalent to the login for your page) or an explicit scheme for your application (say, “uber://”) and some content to get over to that.

However it could always be just a standard intent. The SDK could say, “Let’s construct an intent with this package set.” Maybe it has a specific action that we want to integrate with—say, one called “Authenticate User”, and it’s fired. My app is registered to receive that in the manifest. Or, if I was the developer, I could also use the Android account manager. That would have to have the extra permissions for “Get Account” and “Manage Accounts”, but with that in place, I could use the Account Manager to authenticate an access token as well. There are a several different implementation methods that can get you to the same experience, but in the end, they all drive the same use case.

KG: Along the same theme of sharing data or information across applications, there’s also the concepts of content providers and AIDL integrations. I know that Donn has worked on AIDL integrations, so you two would probably understand this better, but will you explain when I would use a content provider and when I would just use an AIDL? Why not just use one? Why do I need multiple ways of doing the same thing? Obviously, it’s not the same thing, but if you can call out the differences, it’ll be helpful for our listeners.

TS: The content provider is usually styled by a URI. It’s more loosely typed data that you might want to consume with a cursor. There are use cases where that might be valid. Maybe you want to look at specific types of data that are coming back in a list, which you can iterate on a cursor. There are methods in content providers to stream files, so you can use them to specifically access a file.

A great example of a content provider if from when I was working at Evernote. We wanted to implement ACTION_EDIT and ACTION_VIEW(intent) in Android to have an attachment to an Evernote note be utilized by a third-party app which could specifically handle the MIME type of that attachment. Let’s say that you had a note which had an Microsoft Word .doc attached to it. When the user engages with that, we launch the ACTION_EDIT(intent) with that MIME type specified. Now any application on the device can say, “Hey, I’m available to handle that sort of thing.” Then the user picks one, and we construct the intent. We set the data to the URI of that attachment, which will be provided through the content provider. We’re going to be streaming that file, so we need to grant read or write access to it temporarily as well (depending on if they called ACTION_VIEW or ACTION_EDIT, respectively).

Where it can get a little hairy is that there’s a lot of volatility in an integration like that on the Android platform. Third-party apps would say they could handle that MIME type. When you sent the URI over there, sometimes they would edit it directly, call setResult(), and finish(). That’s a straightforward example. You gave them a URI, they edited the URI, and you got an activity result—a RESULT_OK, a RESULT_CANCELED, or whatever the valid response was.

But we started running into other weird use cases as well. Some apps would copy the URI, write it into a different file as the user edited it, and then return the new data URI. Now you have the original data URI that you provided them and the new data URI that you are consuming from them, which is likely being streamed from their content provider. That was a use case where they did call setResult().

But there was another use case where apps would edit the URI and then call finish() without calling setResult(). You wouldn’t get a valid RESULT_OK, but the URI was changed, since the user engaged with it. We had to set up a weird fallback mechanism. When the user specified interest in handling a file, we first copied the file. We then handed out the URI for the temporary copy that was a representation of it. The third-party app then edited the file. When it returned it, we checked first: was the MD5 of the URI that we sent over the same as the one for the URI from the onResume()? If they setResult() and gave us a URI, is it the same URI, or has it changed? If there was no change at all, that’s another use case. We started prompting the user, based on this data set: “Hey, we got a result back from the app. Do you want to save it?”

Different apps behave different ways. Those all consume from streaming a file over the content provider, which is one specific use case. To take that a step outside of the realm of streaming data, files, or big data sets that you may want to iterate on with a cursor for a list, the AIDL is more statically typed. It explicitly binds a service between their app and your app. It requires them to have a generated code set based on a common defined interface. This allows you to transfer objects directly between them. That’s a little more useful for statically typed content, where the content provider has a looser mechanism for defining the data and handling it, based on the URI.

You could manipulate both of them to handle very similar use cases, so it just depends on what you’re thinking about from a maintainability perspective.

KG: The way that I think about content providers is that they are more of a placeholder, whereas AIDL Integration is more of a service which allows you to be a little more flexible in the kinds of things that you can potentially do.

TS: Definitely. You can send any type of parseable object across an AIDL directly, but that requires that both the consumer and the provider have the same method definitions and class definitions. So if you have an app (maybe your app) that provides a service which has updated, but the third-party app consuming the JAR that you provide is not updated, then you could have weird versioning issues in the AIDL. You could run into similar issues with the content provider, but those are more loosely typed, since you’re specifically assembling a URI when you’re parsing that out.

DF: The thing is, if you are using AIDL, there is something to be aware of—a weird gotcha that you’ll never know about until you hit it: the TransactionTooLargeException, meaning that the binder transaction failed because the objects that you’re trying to send across are just too big to handle. The binder transaction buffer has a limited, fixed size of 1 MB. That’s it. It’s in the Android documentation. But that’s one of the ones that I ran into. We were sending a humongous amount of data over an AIDL service—and one day, it suddenly started breaking, because we were sending more data back than the binder could handle.

TS: Absolutely. That’s a great use case for using an AIDL with a content provider and streaming that out directly.

KG: Wow, so my 10 MB JSONs are a no go with AIDL integration.

DF: That’s not going to work.

KG: Dang.

DF: This is good information, but there are more ways that we can share data. You touched on a couple of these. That’s going to be through intents, and I even mentioned deep links. Have you used deep links at all to share data? If so, what did you do? If not, do you use deep links at all?

TS: Actually, in working on the Uber app, I’ve been a little more focused on deep links specifically. The Uber SDK generates a deep link to start the user’s trip, to apply promotions, or for a handful of other use cases that are generated through non-published developer means. For example, suppose a marketing email is sent out to re-engage folks. That will have a deep link that fires back into the app. More often than not, that’s going to be a universal deep link, where it’s potentially just a standard URI with query parameters that you’re parsing out, reading, and trying to do stuff with. You could do intent APIs over Chrome until version 24, which allowed for explicitly defined intent APIs. However, as soon as you’re thinking about cross-platform (iOS and Android), using a standard native scheme in your deep links or using universal deep links will serve you much better, in my opinion.

DF: What is a universal deep link?

TS: A universal deep link is an HTTP URL that has a backing server which understands what type of device is connecting to it. It can redirect appropriately to either the Play Store, the App Store, or the application, such that it can be consumed. You can get into some interesting complexity, like deferred deep linking, where you want to fire over a referrer ID to the Play Store. The Play Store then installs the application on behalf of the user. It then emits that referrer ID (in the install vendor BroadcastReceiver) to your application. You would then catch that, read out that data, see the original deep link that the user was trying to engage with, and just continue the flow for that user.

DF: That’s just a great user experience.

TS:. Absolutely. They click a link, which installs the app, and they’re suddenly on the specific page that they were trying to link into, or it’s starting up a ride for them, or whatever use case they had. That’s a fantastic experience.

KG: I remember that when I worked at Wedding Party, this was exactly the kind of thing we wanted. Essentially, if there was a marketing email that went out, we wanted our users to be able to click a button, go to the Play Store or the App Store, and download the app. After the app was downloaded, since we already had some of that information via the intent, we wanted to be able to repopulate the information. It makes the user experience so much nicer.

The funny thing is that this can actually be done (and there are services that apparently do this) by essentially finger printing that call. It’s actually pretty fuzzy. In some ways, they try to see what the last call that was made was. It has to be made within that time frame, with certain attributes matching up (the same device, model, and version). They actually do a lot of fuzzy logic to come up with that solution.

TS: They definitely do. You can use a service like Tune that does the fuzzy matching, but you can define that pretty easily yourself as well (at least on Android), because if you just had a URL encoded string in the referrer ID, you could pass the specific deep link that you cared about and pull that out yourself, without ever having to have any server integration.

KG: That’s pretty cool! On that happy note, thank you so much, Ty. Some of this information is mindblowing. It’s a completely different side or aspect to what we’re typically used to. This is great information.

DF: Yeah, this has been great.

TS: Of course! It’s a fun field to work in, and it’s a very interesting subset of overall Android development.

KG: If folks want to know more about this and want to reach out to you, what’s the best way to do that?

TS: Follow me on Twitter at @TSmith. I’m pretty active on there, and I’m happy to take messages directly. My website is TySmith.me, where I have some information for further contact. Feel free to reach out to me there. If you want to learn more about developer platform, and potentially work in that space, my team is hiring as well.

KG: Donn, if folks want to reach out to you about your adventures with AIDL Integrations and other stuff, what’s the best way to do that?

DF: Test and fastest way is to hit me on Twitter @donnfelker. What about you, Kaushik? How can folks get ahold of you?

KG: @KaushikGopal on Twitter. Twitter is the way to go these days. It’s definitely the fastest way to reach out to me.

Alright, thanks so much for listening! We’ll catch you in the next episode.

064: Garbage Collection (Android) vs Reference Counting (iOS)

Sun, 20 Nov 2016 21:00:35 UTC

Download directly

In this mini-Fragment episode, Kaushik talks about the process of Garbage collection and how it compares to Reference counting (which is the equivalent process in iOS).

How does each work? What are the differences? Which is better 😁 ? Listen on for all the juicy details…

Show Notes #

Garbage collection (Android) #

Garbage collection [wikipedia.org]
How GC works in Dalvik [medium.com]
How GC works with circular references [stackoverflow.com]

Reference counting (iOS) #

Reference counting [wikipedia.org]
An in-depth look at manual memory management in Objective C [tomdalling.com]
Memory management in Objective C [rypress.com]
Weak, strong, unowned, oh my! (references in Swift) [krakendev.io]

Contact #

Transcript #

Kaushik Gopal: I was talking to one of my colleagues who works on our iOS applications the other day. We started off the conversation talking about advantages and disadvantages of the different local database options—like Realm and SQLite.

Then he mentioned something that blew my mind. A parent-child relationship is a typical use case in any marginally complex system, and we were talking about how to model them in a local database. Then he said, “Yeah, you’ve got to be extra careful with those relationships. You don’t want retain cycles.” This sounded a lot like a memory leak to me, so I probed a bit further, and that led me to the idea behind this mini-Fragment episode: the world of garbage collection and reference counting.

As I chatted more with my colleague and did some research, I began to understand the differences between how garbage collection (GC) is done in Java (specifically, on Android) and how the equivalent concept (reference counting) is done on iOS.

Let’s start off with a little theory. Most of us are already aware of what GC is. In a nutshell, it’s the process by which we free up memory. If you’re done using a whole bunch of variables and objects in your method, class, or activity, those still take up memory in what’s called the “heap”. Since you don’t have infinite memory, that space has to be released at some point, and the process that releases it is called garbage collection.

To be accurate, there are many different algorithms for garbage collection, but the most common one (which Android uses, for the most part) is called “mark and sweep”. The advantage of the “mark and sweep” algorithm is that it’s the first that could actually reclaim cyclic data structures. This is important, especially when you compare it to iOSes’ method of reference counting,—but we’ll get to that in due course.

When using “mark and sweep,” unreferenced objects are not reclaimed immediately. Instead, the garbage is allowed to accumulate until all the available memory has been exhausted. When that happens, the program’s execution is suspended temporarily while the algorithm collects all of the garbage, so to speak.

By the way, when this happens, it actually halts your UI for a brief moment. This is what we usually call “UI stutter” or “jank”. If you run low on memory and this begins to happen a lot, it’s then called “trashing”. Garbage collection trashing happens, unfortunately. But coming back to the topic, once all of the unreferenced objects have been reclaimed, the normal execution of the program just resumes.

An interesting question you may be asking at this point is, “How exactly does the OS detect if an object is unused?” The evaluation for whether something needs to be collected or not starts at a point called a “garbage collection route”. Think of this as a type of link-less structure, where you have a starting node or a tree structure. From that node, you keep trying to track the next reference. If you started with object A, and that references another object, you then jump to that object and see all of its references. Then you continue this process, marking the objects as you go along the way. Then, at the very end, the garbage collection process steps back and says, “Which objects were not marked? If they weren’t marked, then they’re not referenced by anyone. That basically amounts to garbage, so I can release the resources that were used up by those objects.” That’s how the “mark and sweep” algorithm functions, in a very simple and basic way.

Now you should remember that this mechanism also accounts for cyclic references, which is pretty cool. We’ll touch on that again a little later when we try compare and contrast the differences between these methods.

We’ve talked about how GC works at this point, so we have a pretty good understanding of that. Let’s dive into some dark territory and see how iOS does its version of garbage collection: reference counting. Reference counting is similar to GC in that the objective is the same, but the way that it’s achieved is radically different. In the early days of iOS programming (or more accurately, Objective-C programming), programmers had to manually count and release the references that are automatically taken care of for us in GC. So every time you created a variable, you actually had to write code saying, “Hey, retain this,” or “Release that.” Retain and release were real Objective-C matters that you had to write. I know what you’re thinking: “That’s barbaric!” Well, that’s what the process was for the longest time. They called it Manual-Retain-Release (MRR).

But then, in Xcode 4.2, Apple introduced a concept called Automatic Reference Counting (ARC). ARC automatically inserts all of these retain and release matters that we just talked about for you, so that you don’t have to manually write them. As a developer, it’s similar to GC in that you don’t have to take care of it. It just happens on its own. But you still have to remember that the process is the same. It’s very much a reference counting process, which is different from the garbage collection process that we previously discussed.

Reference counting basically works by marking heap objects with the number of parties or variables that refer to them. It actually keeps a running tally of the number of references on the side. Say person #1 needs this resource. It would bump the reference count up to ‘1’. Then person #2 needs the same thing, and it bumps the count up to ‘2’. Then another person needs this, and it bumps the reference count up to ‘3’. Now person #1 says, “Actually, I person no longer need it, so release it.” Then the reference count goes down to ‘2’, and so on. Basically, it keeps a running tally of references throughout the program for an object.

When that number finally drops to zero, it assumes that the object is no longer needed, because it has zero references. That’s how the memory is released.

As you can see, it’s very, very different from garbage collection. While GC waits for some time before kickstarting this side process, reference counting is always happening. It’s constantly checking references and releasing them at every single step. It’s a very different approach. GC clumps the complete process and does it all at once, but reference counting distributes the work. Instead of doing it all in one big chunk, it breaks it into extremely small chunks, and constantly keeps doing that process.

Now that you have an idea about how each of these processes work, let’s enter the holy war territory. Which is better: GC or reference counting? It’s really hard to answer that question, because there are so many variables. In different situations, one approach works better, and in other situations, the other works better. How much total memory do you have? How often do you do object allocations? All of that plays into this decision.

Instead of trying to come up with a single answer, let’s talk about the advantages and disadvantages of each approach in general. That way, we can make an educated guess about situations where one would beat the other. Let’s start off with GC. The biggest ding against garbage collection is that it’s unpredictable. We know it will happen, but we don’t exactly know when. The garbage collector can essentially kick off anytime. The GC will just decide, “You know, I feel like now is a good time to run the process.” This can be a problem, because if you don’t know exactly when this process kicks off, then if you’re running this crazy cool animation in your UI and the GC decides to kick in, it will cause a jank. There’s no guarantee of a consistent delta time between one frame and the next, so some frames will be skipped because your GC process decided to kick in at that point. Then everyone who cares about buttery smooth UI performance will call us out.

Reference counting, though, is super predictable. These retain and release matters are automatically jotted down at compile time. From the ARC mechanism, you know exactly when the references will go down, because that code is right in front of you. It’s all in the variables that you see.

I should say that there isn’t a guarantee that ARC will happen, but it’s what we call “deterministic”. The lifetime of every object is clearly defined, and you know with a great deal of assurance that it’s going to kick in. Also, the actual collection happens in a very incremental fashion, as we discussed. It isn’t in a big chunk, but is distributed in very small chunks, so it’s constantly happening in very small time periods. Because of this, there are no long pauses for collection cycles, so the chances of jank happening are far lower. You can clearly see the state of all of your objects and can decide when it should kick in and when it shouldn’t.

Many folks say that this is the primary reason why Android was considered to be pretty janky in its early days. It never had the buttery smooth experience that our iOS counterparts enjoyed. With recent efforts, like Google’s Project Butter, this has changed significantly, and the arguments don’t necessarily hold. But conceptually, the concepts are still the same. You still have a GC that kicks in, but reference counting still happens incrementally at each point.

Along the same lines, the other disadvantage is RAM usage. With reference counting, objects are released as soon as they can no longer be referenced. The minute an object drops to zero in the side tally, it gets immediately collected. Typically, memory constrained environments like mobile devices, this is great. You don’t want to hold onto a reference any longer than you actually need to, because once the reference goes down, you immediately open up usable memory. Your RAM is reclaimed faster. But in garbage collection, on the other hand, you keep accumulating that garbage for a longer period of time. Until the GC finally decides to kick in, your RAM is basically going to be used up.

This is also why (again, in the early days) Android phone manufacturers used to advertise, “Our phones now have 2 GB or 3 GB of RAM,” but the iPhone (for the longest time) had just 1 GB of RAM. People would go nuts online: “How is it that Apple is so cheap? They don’t want to spend any of their own money, so they put just 1 GB of RAM in their phones—and it still manages to beat the UI from Android phones in terms of performance!”

In the early days of Android, the big reason for this difference was that the garbage collection wasn’t really optimized. Again, I keep saying “the early days”. Now the GC process is tuned to run correctly. Potentially, instead of waiting for the RAM to get full, it kicks in faster, when it isn’t necessarily at a point where it’s going to stall the UI. There are other episodes that we’ve done, and other podcasts that talk in detail about this process. Just keep that in mind.

At this point, you’re probably thinking, “Wait a minute, this whole reference counting thing is probably a better idea than garbage collection.” You’ve already seen its advantages. Well, it’s not all rosy there, either. Let’s talk about some of the disadvantages of ARC and the advantages of garbage collection.

Retain cycles were actually the topic that spawned this all for me. My iOS colleague was saying that retain cycles were a pain in the butt to deal with it. They happen because of circular references. What does that mean? Let me just give an example: say that Object A references Object B, and Object B references Object C, so you have this straight “A depends on B depends on C” structure. But then, Object C goes all the way back and references Object A. You have this circular reference: “A depends on B depends on C, which now comes back and depends on A.

If you think about it, this is actually a big problem for reference counting. Even today, iOS engineers have nightmares about this, because it’s so simple to introduce a circular reference. Think about the reference count tally that’s happening in the background. If A depends on B depends on C, it’s essentially never going to go down, because you have a circular reference in a loop.

This is very easy to introduce. You may think that it’s a contrived example, but it really happens. Take a simple example: say you have this parent object in your application—a father or a mother. That parent has a child, so there’s a strong reference between a parent and his or her child. But if you pull the child object alone, then this son or daughter would have a parent object again, so there would be a strong reference back to the parent. Parent depends on child in a strong reference; child depends on parent in a strong reference. It’s a retain cycle.

I’m being a little dramatic, but the way that you deal with this is to essentially say, “No, no, no. One of these references is a weak reference. If the parent depends on the child, let’s not make that a strong reference, but a weak reference.” This type of weak reference is very similar to weak references in Java, so I’m not going to go into those details.

But this is still a real problem. Even with Swift, Objective-C, and all of the cool new things that they have, they have to worry about retain cycles, because circular references are an inherent problem—one that’s pretty easy to run into. As an iOS developer, you have to remember to not shoot yourself in the foot with these bi-directional references.

If you’re curious, you may ask, “Wait a second? Isn’t that also the case for us as Android developers?” If you think about it, if the references never go, all of those references are still intact. How does the GC figure this out? Doesn’t it also get tricked into always thinking that we need these references? Won’t they live in memory forever and never be released? If you remember what I mentioned earlier about the definition of how GC works, this actually won’t happen. This is pretty cool. Because of the way that GC works, the evaluation starts from the GC root and keeps traversing and marking those objects.

But if it so happens that the chain is not reachable in a spot, which is what would happen here, it’s free to garbage collect all the rest of the objects. From the GC root, you haven’t touched those references. It doesn’t matter if you’re in your happy, private, merry-go-round reference circle. As long as you’re not in the GC root, you will be collected. If you actually learn the computer science concepts, the “mark and sweep” algorithm for garbage collection was a kind of breakthrough, because it was the first that could actually deal with circular references. Even to this day, ARC still cannot deal with circular references.

The final thing is that when you think about these computer science reference concepts that have come along, garbage collection is supposed to be more efficient for larger complicated systems. As our systems become more complex, GC will eventually win. This is because you will tend to have non-trivial object life cycles with large applications. Even now, we already have that. So you wind up spending a lot of your time trying to figure out, “How exactly do those life cycles work? Do I have a reference here? Do I have a reference there? Is there a retain cycle here?” With garbage collection, you get to write your program much faster, and (in the long run) you’ll just be more efficient. Therein lies this huge advantage.

I’ll leave you with some parting thoughts that I found on a Reddit thread. Android was originally designed to be a general purpose computing platform, so there were many complex things like background services and true multitasking that came to us early. A large part of the reason why we were able to get these things early was because we had garbage collection that was built to accommodate these complicated systems. But what that meant was that there were compromises made, and UI fluidity and RAM usage suffered. We bit the bullet there, but we got some of these other features.

By the way, the Android Runtime, which is what we currently use, is super optimized. With initiatives like Project Butter, most of these things are almost indistinguishable. The performance and UI fluidity are almost neck to neck.

iOS, on the other hand, was designed from the ground up to be very smooth and responsive. Low-input latency and smooth redraws were top priorities, which was why early versions of iOS were super smooth compared to early versions of Android. But again, they had to make compromises. Reference counting is much easier to do with simple systems, but it’s very hard to pull of in an efficient way with complicated systems. This, in my opinion, is the main reason why iOS got features like background services and multitasking super late relative to the Android world. Obviously, they’ve caught up with Android and have a lot of similar features these days.

So, in the end, it’s neck to neck. Everyone is pretty much in the same boat. There isn’t necessarily one better way. It’s not easy to say that garbage collection is better than reference counting or vice versa, because each of them has its advantages. Both Google and Apple are obviously coming up with some really cool and innovative ways of circumventing the problems that are inherently present with each of their mechanisms.

I hope you enjoyed this deep dive into a rather pitiful topic. If you have questions, feel free to hit me up on Twitter (@kaushikgopal). I had to do a lot of research, especially in the iOS part of the world, since I don’t really do iOS development. I could have said something that’s not factually accurate about iOS, so I’ll make sure to include all the different links and resources that I used for my research in the show notes. That’s all, folks!

063: Effective Java for Android Developers – Item #13: Minimize the accessibility of classes and members

Mon, 14 Nov 2016 04:11:00 UTC

Download directly

In this mini-Fragment episode, Donn talks about Item #13 of the Effective Java series – Minimize the accessibility of classes and members. You’ll learn why it’s important to limit the access on your public API, how it can help you with development and performance. You’ll also learn how changing a public API can affect the consumers of your API, for good and bad.

Show Notes #

BuddyBuild

Contact #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

Transcript #

Donn Felker: Today, I’m going to talk about Item #13 from Effective Java, by Joshua Bloch. For those of you who are just joining us, Kaushik and I are covering all of the items inside this book in relation to how they apply to Android developers. We’ve already gone through the first 12, so I’ll be talking about #13: Minimize the accessibility of classes and members.

Joshua puts this very well right out of the gate, so I’m going to read this verbatim:

The single most important factor that distinguishes a well-designed module from a poorly designed one is the degree to which the module hides its internal data and other implementation details from other modules. A well-designed module hides all of its implementation details, cleanly separating its API from its implementation. Modules then communicate only through their APIs and are oblivious to each others’ inner workings. This concept, known as information hiding or encapsulation, is one of the fundamental tenets of software design.

To be honest, I spent about ten minutes trying to think of a better way to say that, so that I didn’t have to quote it exactly, but it was too hard. Joshua hit this nail right on the head. The way that he said this was so succinct and perfect that I couldn’t come up with a better way to say it.

Why is it important to hide the implementation details and only expose parts of your API? While there are many reasons, it’s mostly due to how it decouples your modules from how people are consuming them. Furthermore, it allows you to speed up the system development, since the different modules underneath the hood can be developed in parallel.

Suppose you’re building a library or module which has a public API. All of the internals of that could be split apart to multiple different developers, and the work could be done internally. Then the actual API component could be delivered to some other third party, so that they can code against that—basically, an interface. It’s the API which they’re going to be working with.

The great thing about this is that since you’re hiding all of the implementation details, you can actually build those modules internally without worrying about breaking anyone else’s code. As long as you adhere to the public API that you’ve put out, and you’re not exposing the internals of how you’re doing all of the work, then you don’t need to wonder, “Hey, are we breaking anybody else?” You can actually design it, test it, make sure that it works, and move much more efficiently behind a wall. One of the great things about this is that it allows you to essentially ship faster. If you’re able to do all of these things without impacting the consumers of your API, you can deliver the product quicker.

Furthermore, while this does not give immediate performance benefits, it does enable effective performance tuning. Let’s assume that you’ve built your library. You have a public API of 5-10 methods or classes that people are using. Underneath it, you have 50 other files. At some point, you realize: “Wow, this one part of the library is super slow. How can I fix that? Well, I know that it’s in this component down here. Because it’s part of the internals of my library, and I haven’t exposed those internals, I can hop in there and change the way that works.”

Maybe you’re using an improper data structure, or maybe it’s something simple, like a memory leak. You can go in and change the internals of that underlying part of the library, and then ship an update to that library. The interface to it (the public API) doesn’t change, but the internals have now changed. You’re enabled to have some type of effective performance tuning without affecting any consumers of the API.

Okay, that makes sense, but how does Java facilitate any type of information hiding? Well, the access control mechanism that Java uses is something which we use every day: modifiers like public, protected, private, and all of the other types of modifiers that are essential to information hiding. To most of us, they’re second nature. We really don’t think about them at all. But understanding when to use them is key to developing software. The rule of thumb that Joshua clearly gives here is to make each class or member as inaccessible as possible. In other words, use the lowest possible access level that you can while enabling your application or library to do the work that it needs to do.

For top-level classes and interfaces, you’re basically always going to go with public. Some people do go with packaged private, and there are some weird idioms around that which you can follow, but these top-level classes are the things that people will implement. They’re basically not nested. You’re going to make them public. They’re wide-open—things that folks can use.

Here’s the thing, though: if you make something public, you’re obligated to support it forever to maintain compatibility. For those of you who listen to one of our other favorite podcasts—”Android Developers Backstage,” hosted by Chet Haase and Tor Norbye—I’ve heard Chet talk about building an API on various occasions. When you make a decision to implement a particular API, it’s the best decision you can make at that time. The Android developers can make an API public. At that point in time, it’s the right decision, but two months down the road they may have realized (after they shipped that Android OS update) that it was actually a bad decision. That API probably wasn’t the best one. They may have made note of this in the podcast, since hindsight is 20/20, but they still can’t go back and change it.

Why? Let’s assume that Android has shipped a public API. This has happened before. Once it’s released, all kinds of apps suddenly start using it: Facebook, Instagram, Twitter—you name it. Then the Android team determines: “Wow, that was not the best decision. We should not have made that one public.” Or, “We let that slip through a code review by accident.” Any number of things can happen. But now they have to support it anyway.

Suppose they decide to yank it in the next version of Android. What would happen? Let’s assume that a major application like Instagram is using the API. I’m not saying anything negative about Instagram. I’m just using them as an example. This can happen to any application, but I’m using Instagram since it’s a very popular application that would affect millions of people. Anyway, folks decide to update their phones up to the newest version of Android. So they update them, and then open the Instagram app—and the app suddenly crashes. If the Android team removed an API that they’ve already released as a public API, they would not be maintaining backwards compatibility. In other words, as soon as a new version of Android comes out and someone updates to it, the app is going to crash. It’s going to look for that method, but it’s just not there.

What the Android team has done over time is to mark these classes or methods as deprecated and provide alternatives: “Please start using this one.” You’ve probably seen deprecation notices all throughout your applications. AndroidLint does a good job of catching these in the IDE so that you can see them. It puts a little strike-through in the IDE, saying, “That doesn’t look right.” That usually means that you’ll have to take a look at the implementation. You’ll hit Command+B (if you’re on a Mac) and look at the definition of that class. It will actually have some notes in the Javadoc, such as, “This class is now deprecated”, or “This method is deprecated. Go use X, Y, or Z.” Then you can decide which one to use.

To kind of bring this full circle, this is important as an API developer because you have to make the best decisions possible. Realize that when you release something with a public API, you’re stuck with that API. You can’t just pull it, even if you hate it, don’t like it, or it just makes it painful. You have to keep it and work around it.

Of course, there will always be times when people remove them, which can cause pain and so forth. Is that something you would want to do? That’s up to each team to determine. Maybe you’re developing an shared internal library at your company that’s used by just ten other apps. Then you can make a judgment call and say, “Hey, we’re going to yank this API. It was a bad decision. Let all the other developers know so that we can update it within the company.” However, if you’re releasing a public SDK (for instance, the Facebook SDK) and you remove a method, that could become very problematic. All of a sudden, people’s applications break, and they have to fix them. This has happened to all of us before. We’ve used a third-party API, things change when versions change, and stuff suddenly breaks.

This is also why it’s very important to specify exact version numbers in your build.gradle file. Let’s say that the version of the library that you’re depending on is 9.0.1. But in your build.gradle file, you’ve said “9.0.+”, or even “9.+”. What that’s basically telling gradle is, “You know what? So long as it’s version 9 or 9.0, it’s cool. Don’t worry about it. Just pull the new one down.”

Many developers have had weird instances where they build something in the morning, do a bunch of development, rebuild, and it’s broken. Why is that? Perhaps it’s because some other developer has released a new version of that library, upgrading it to 9.0.2. That had a breaking change in it, which removed or changed an API call. Suddenly, an app that worked 10 minutes ago doesn’t work anymore, even though you didn’t change anything. Why is it breaking? Because you didn’t specify your exact version number in your build.gradle file. This is a good reason why you want to use a particular version number in build.gradle. We’ll go into this in detail here on Fragmented at a later time, but this is something that can affect you as an Android developer.

Let’s step back into this effective Java item and talk about how you can lock down access to particular parts of you application or module. Let’s assume that you’re building a module with a bunch of internals. You’ve probably looked at the source of many open source projects and noticed that they have a package called something like “com.example.fu.internal”. It’s a very common pattern for folks to put everything they want internal to the library inside of an internal package. A lot of the time, everything that’s outside of the internal package will be public. This isn’t written in stone. It’s just a common practice that a lot of folks do.

When they put those things in those packages, you’ll notice that they use different Java access modifiers. Let’s talk about this for a second. We have four different access modifiers. The first one is “private”. Private is basically saying that members are only accessible from the top-level class where they’re declared. Say we have a “customer” class with an integer age field called “private.int.age”. That age field is only accessible within that instance of that class. Nobody else can access it. If someone’s trying to call “customer.age”, they cannot get access to it. It’s not allowed.

The second modifier that we have is “package private”. This one says that the member is accessible from any class in the package where it is declared. This is technically known as default access. This is the access level you get if you don’t provide any type of access modifier on a member. Let’s say you create a class called “customer”. That class is now package private. Anything that’s in the same package can access that class. Again, let’s just use that integer age field. But instead of saying “private.int.age”, we just say “int.age”. Any class that’s inside of the same package can access that age, because it’s package private. But only classes within that package can access all of those members.

The third modifier is “protected”. Protected is accessible from subclasses of the class where it’s declared. Again, let’s say that we have a “customer” class and with an “age” field, and we’ve used “protected.int.age”. At this point, we’ve said, “You know what? We need to change our application to support platinum customers and gold customers.” So you inherit from the superclass, which is now customer, and have a sub-class of customer called “platinum customer”. Well, because the customer’s age is marked as protected, the platinum customer can access the age. The “gold customer”, which is also a sub-class of customer, can also access the age. But anything else—perhaps an employee object, which is a completely different class—cannot access the age, because they’re not a sub-class of “customer”.

Finally, we have the very popular “public”. This is a member that’s accessible from anywhere. This is one that we’re very familiar with. When you mark something as public, anyone can access it. If you have that customer class again, and mark that age as public.int.age, anyone can access that age. We can have a whole bunch of problems there, which I’ll talk about in a second, but it’s the most open option. As soon as you mark something public, you basically need to support it from that point forward.

Let’s talk about public classes for a second. If you use a public class, you have a huge increase in accessibility. The access level goes from package private—basically saying that you have to be a part of this package to access it—to protected. A protected member is part of the class’s exported API and must be also supported forever. Let’s say again that we have a library which exposes a customer object that was previously package private. No one could talk to that int unless they were in the same package. But your application, since you’re consuming that third-party library, is not part of the same package. You don’t have access to that integer.

Now let’s say that we changed that from the default access level to protected, for some reason. As soon as we do that, we now open that that as part of the public API. Now I can sub-class the customer object and create my own type of customer. I have access to that age, because it’s now a protected access modifier level. It’s part of the public API, so be very aware of that. As soon as you change something that was package private before to protected, it does become part of your public API. That’s something that you need to think about quite a bit.

There’s one rule that you need to make sure you’re aware when you’re trying to reduce accessibility of methods. If you have a method which overrides a superclass method—maybe it calculates some type of value for your object, and you override that int for me in the subclass—you cannot change the visibility of that, saying, “Hey, this was protected before. Now I want it to be private.” If you do, the compiler is going to complain and not let you do it. You have to keep the same accessibility.

I’ve been on both sides of the field, as an API developer as well as an API consumer. Throughout the years, there have been many times when I wished a particular class or something of that nature was much more accessible. Maybe I wished it was public, so that I could have access to it. The main reason for that was that either I needed to provide some sort of implementation which the class didn’t allow, or I needed to facilitate testing. If you need to facilitate testing, you may be tempted to make everything more protected or more public so that you can have access to it. But realize that that’s not necessary. If you’re building the API yourself, you can provide an interface for folks to use. They can go ahead and mock things out, and with new versions of the mocking tools, you could even mock final classes, which is amazing.

But if you’re worried about testing a library that you’re going to be publishing to external folks, you don’t have to make all of those things public. Your tests are going to be internal to your application anyway, so if you have things that are package private, you can leave them that way. Your tests can still access those, because you’re part of the same package. There’s not really a need to open up your API for testing as much as you think you need to.

Joshua makes a couple of other statements inside of this item which are very important. One of those is that instance fields should never be public. Say it’s that customer’s age again. He’s saying, “Never mark that public, because you give up the ability to take any action when the field is modified. Classes with public, mutable fields are not thread-safe.” That was a big “Aha” moment for a lot of folks—especially me, when I first read this. I wasn’t super aware of that, and never really thought of that in too much detail.”

This also applies to static fields, with one exception: you can expose constants via public static final fields, assuming that the constants are basically primitive values or references to immutable objects themselves. You’ll want to be aware and stick to that rule, except for that one little variation there.

Joshua also makes mention of something that’s very tricky when you think about it: non-zero length arrays are always mutable, so it’s wrong for a class to have a public static final array field or an accessor that returns such a field. What that means is that if you’re returning an array of customer values, that can always be mutated outside of the class. You’ll run into a bunch of problems, crazy bugs, and security holes when you expose a public static final array field or an accessor that returns such a field itself. You want to be careful around that as well.

You may be wondering, “I need to return an array of things. How do I do that?” There are a couple of ways to fix the problem. You can make the public array private and add a public, immutable list; you can use things like collections.unmodifiableList, which will return an unmodifiable list using the collections utilities; or you can make a copy of that private array and return that copy, so that it’s not the same one. That could be confusing to folks, who think, “Hey, I’m getting back an array. I think I can modify it. It should modify my existing array in memory,” which could add some confusion to your application. You may want to be aware of that too.”

In the end, you need to choose between these alternatives if you’re returning an array, and think about what the client is likely to do with the result. Which return type will be more convenient for him, and maybe even what will give him more performance?

That kinda wraps it up for Item #13. It’s all about accessibility and minimizing your API footprint. Remember: if you mark something as public, or it’s available as part of the public API, you’ll have to support it, because people are going to rely on it. You want to hide the internals away. Why is it easy to hide the internals away? It allows us to develop in parallel much quicker. We can iterate and build tests. It also enables effective performance tuning, because if that library we ship doesn’t really function that well, we can hop in there, take a look at the internals, fix it, ship another version, and still not break the public API. I hope that helps. Talk to you next time.

Transcription and editing provided by 10:17 Transcription

062: Effective Java for Android Developers – Item #12: Consider Implementing Comparable

Mon, 07 Nov 2016 04:06:52 UTC

Download directly

In this mini-Fragment episode, Donn talks about Item #12 of the Effective Java series – Consider Implementing Comparable. You’ll learn about how you can use the Comparable interface to give your code the extra sorting boost it needs. Work with Arrays.sort(), Collections utilities and even sorted data structures. Donn breaks down what it takes to implement the compareTo method of the Comparable interface.

Show Notes #

BuddyBuild

Contact #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

061: The state of event bus(es) today

Mon, 24 Oct 2016 05:00:48 UTC

Download directly

The age old question: should I be using an event bus today? What is an event bus? what are still some good use cases for an event bus? Can i replace an event bus with RxJava?

Donn and Kaushik have at it and try to answer this question that gets asked constantly in the AndroidDev circles. Listen on for our take.

Show Notes #

What’s an event bus #

Donn’s blog post on event aggregators (event buses) [donnfelker.com]
KG’s blog post on implementing an event bus with Rx [blog.kaush.co]

Libraries #

Otto – Square’s Event Bus library [github.com]
EventBus – greenrobot [github.com]

Misc #

Handling GCM messages in the foreground and background by Mark Hudnall [markhudnall.comm]
KISS [wikipedia.org]
Ep 53: Jake on RxJava 2 [fragmentedpodcast.com]
RxRelays [github.com/JakeWharton]
Diff change set for converting RxBus to an RxRelay [github.com/kaushikgopal]
Caster.io EventBus course – Annyce Davis [caster.io]

Sponsors #

BuddyBuild

Contact #

060: Smoke and Mirror Android UI tricks with Israel

Mon, 17 Oct 2016 05:00:01 UTC

Download directly

We talk with Android UI magician Israel. In this episode, Israel does what magicians are never supposed to do, reveal those exciting magic tricks. He talks about tricks you can use in your Android apps to create a super slick UI, citing examples from Google Photos, Twitter and other apps.

Dazzle your Android users with these UI tricks.

Show Notes #

Israel’s last appearance on Fragmented (Ep 26) [fragmentedpodcast.com]

Smoke and Mirros #

Israel’s sample app [github.com]
Slides (with animation demos) [photos.google.com]
Google Photos Recycler View pinch to expand/shrink [photos.google.com]
ClipChildren demo [photos.google.com]
Utils method – traverse hierarchy and clip [photos.google.com]
Tap image to show full screen [photos.google.com]

Misc #

Nick Butcher’s Plaid app [github.com]
Android-Job library by Evernote [github.com]

Contact #

059: Chiu-Ki Chan explains Mocking and Stubbing with Mockito

Mon, 10 Oct 2016 05:00:34 UTC

Download directly

We talk with the all-star multi-talented GDE Chiu-Ki Chan about testing. Specifically, we dive into leveraging Mockito for your testing needs. What is Mocking, what is Stubbing, what are the different test doubles, how does mockito help with this? Listen on to find about that and some more interesting stuff on testing!

Show Notes #

Introducing Pixel [blog.google]
Static Gateway Pattern [codebetter.com]

About Chiu-Ki: #

Android Dialogs | youtube [youtube.com]
360|AnDev co-organizer | conference [360andev.com]
Technically Speaking| newsletter [tinyletter.com]

fake SharedPreferences implementations from AOSP #

FakeSharedPreferences | fake in-memory SharedPreferences implementation [github.com]
BridgeSharedPreferences | empty SharedPreferences that does nothing implementation [github.com]
Testing SharedPreferences [gumroad.com]

Different kinds of Test doubles #

Know your test doubles [testing.googleblog.com]
[Test Doubles: Mocks, Stubs, and More](https://www.objc.io/issues/15-testing/mocking-stubbing/ http://www.javaworld.com/article/2074508/core-java/mocks-and-stubs—understanding-test-doubles-with-mockito.html) [objc.io]
Mocks aren’t Stubs [martinfowler.com]

Mockito #

Mockito library [github.com]
Stubbing consecutive calls [mockito.org]
Argument Captor [mockito.org]
PowerMock [github.com]

Resources #

Contact #

058: Effective Java for Android Developers – Item #11: Override clone Judiciously

Mon, 03 Oct 2016 05:00:03 UTC

Download directly

In this mini-Fragment, Donn talks about Item #11 of the Effective Java series – Override clone Judiciously. You’ll learn about the extralinguistic behavior of clone and the Cloneable interface. Clone and Cloneable are very special, and this episode helps explain the nuances.

Show Notes #

Contact #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

057: Data Binding with GDE Lisa Wray

Mon, 19 Sep 2016 05:00:44 UTC

Download directly

In this episode we talk with, Lisa Wray, first of her job title, mother of the Genius app and sorceress of Data Binding.

What is Data Binding? How does it work? What can you do with it? … and what you can really do with it ! Listen on and find out more. Lisa walks us through the basics and then talks to us about how we can really push the envelope with Data Binding and do some really cool things.

Show Notes #

About Lisa Wray #

xwray.com
Genius [genius.com]
Fragmented Ep 042 – Google IO 2016 special [fragmentedpodcast.com]

Data Binding Resources #

Data Binding Library [developer.android.com]
Data Binding – Writing Apps Faster (Android Dev Summit 2015) [youtube.com]
Data Binding Techniques – Jacob Tabak’s Droidcon NYC 2015 talk [youtube.com]
talk:title="@{dataBinding}" – Lisa’s lightning talk at Square Android Spring Cleaning [youtube.com]
Descent into Data Binding – Bill Phillips at Big Nerd Ranch [bignerdranch.com]
Advanced Data Binding – Google I/O 2016 [youtube.com]
ADB Ep 35 – Data Bound [androidbackstage.com]

Hired – special offer: double the signing bonus!

Contact #

056: GDE Philippe Breault on tinkering with Android Studio (Part II)

Tue, 13 Sep 2016 05:00:45 UTC

Download directly

We wind this two part series down with GDE Philippe by chatting about postfix completion, live templates, structural search/replace, integrating with external tools, cool configurations and much more. Prepare to be mind blown.

Show Notes #

Ep 55 – Fragmented: Part 1 of this series
Phil’s talk at 360Andev talk (coming soon): Android Studio like a boss [twitter.com]
Phil’s Android Studio Tip of the day series [plus.google.com]
Timber logging : courtesy JakeWharton [github.com]
ADB Idea plugin by Phil [github.com]
Caster.io AS stuff:

Contact #

055: GDE Philippe Breault discusses Tinkering with Android Studio (Part I)

Mon, 12 Sep 2016 07:37:35 UTC

Download directly

In this 2 part series, we talk to the illustrious Philippe of Android Studio tinkering fame. He starts off by discussing the intermediate basics that everyone should know about using Android Studio: window configuration, keyboard shortcuts, navigating the code smoothly, debugging etc. Gradually he moves into ninja mode and starts blowing DF & KG’s minds with cool tips and configurations.

We refused to let him go early and decided to record a second part as well. Stay tuned for the second part which should come out very shortly.

Show Notes #

JetBrains Toolbox subscription
Phil’s Android Studio Tip of the day series [plus.google.com]
DroidCon Montreal 2015 [droidcon.ca]
No tabs in IntelliJ – Hadi Hariri [hadihariri.com]
Ep 20 – Fragmented : One with Hadi Hariri
Facebook Stetho [github.io]

Hired – special offer: double the signing bonus!

Contact #

054: git development workflow and branch versioning for App devs

Tue, 06 Sep 2016 05:00:36 UTC

Download directly

Donn and Kaushik discuss how they use git for their development workflow. They also touch on semantic versioning and how they rollout new versions of their app in a controlled fashion.

Show Notes #

Follow up #

Misc #

TortoiseSVN
A successful git branching model
DiffMerge by SourceGear
realm-java open source repo (shows branch naming convention)
Semantic versioning spec

Hired – special offer: double the signing bonus!

Contact #

053: Jake Wharton on RxJava (2)

Mon, 22 Aug 2016 05:00:50 UTC

Download directly

We have Jake Wharton and RxJava in one episode ?. In this power-packed episode we talk to Jake about the advances in RxJava 1.x since the last time he was on the show and also looking ahead at the advancements coming down with RxJava 2. If you’re interested in RxJava, this episode will definitely be a treat!

Watch out for a special guest cameo by the adorable Olive.

Show Notes #

Fragmented Episode 6: with Jake [fragmentedpodcast.com]
Fragmented Episode 7: with Jake [fragmentedpodcast.com]
Looking ahead to RxJava 2 [droidcon.nyc] – Jake’s upcoming talk at DroidCon 2016
Retrolambda usage [github.com]
Single
- Documentation [reactivex.io]
- Origin github issue discussion [github.com]
Libraries used:
- RxRelay [github.com/JakeWharton]
- RxReplayingShare [github.com/JakeWharton]
- SqlBrite [github.com]
- RxBindings [github.com]
- Note about the warmth of the share operator [blog.kaush.co]

Looking ahead #

Reactive Streams specification [reactive-streams.org]
Using Observable fromAsync [stackoverflow.com/documentation] (released with 1.1.7)
RxJava2 release schedule [github.com]
Completable
RxJava 2.0 Design: Naming [github.com]
Backpressure types – buffer, latest, drop

Sponsors #

BuddyBuild

Contact #

052: Junit4 tricks with Parameterized Enclosing tests

Mon, 15 Aug 2016 00:00:40 UTC

Download directly

In this mini fragment Kaushik talks about some cool Junit 4 tricks using Parameterize, Enclosing test runners.

Show Notes #

Junit4 introduced with Android Studio 1.1 [tools.android.com]
Junit4 Parameterized tests [github.com]
Calculator example from googlesamples [github.com]
Sample template code for Enclosed.class [gist.github.com]

Sponsors #

BuddyBuild

Contact #

051: Annotation processing Q&A with GDE Mike Evans

Mon, 08 Aug 2016 06:37:32 UTC

Download directly

We’ve always wanted to know more about annotation processing, so in this episode we pick GDE Mike Evans’ brains on the topic and ask him a whole bunch of questions. If you’ve thought about diving into Annotation processing but never quite grappled with what it’s all about, this is a good episode to listen to.

Show Notes #

Mike’s DroidCon NYC 2015 [youtube.com]
AirBnB’s deep link dispatch [github.com]
ButterKnife from Jake Wharton [github.io]
Improving your code with Android Support Annotations [michaelevans.org]
Jake Wharton and Jesse Wilson – Annotation Processing Boilerplate Destruction [youtube.com]
021: Fragmented – Jesse Wilson on Linker [fragmentedpodcast.com]
@Target Element Types [docs.oracle.com]
JavaPoet by Square [github.com]
AutoService library by Google
kapt – Annotation processing for Kotlin [blog.jetbrains.com]
Annotation processing 101 [hannesdorfmann.com]
Aftermath by Michael Evans [github.com]

Sponsors #

BuddyBuild

Contact #

050: GDE gentleman Mark Allison dissects Constraint Layouts

Mon, 01 Aug 2016 05:00:25 UTC

Download directly

Friend of the show -and one of the finest gentlemen we know- Mark Allison chats with us about Constraint Layouts, what they are, why you need them, what to watch out for and how you can start using them in your application.

Show Notes #

Styling Android – Mark’s blog [stylingandroid.com]
Marks’ Constraint Layout Series:
- Part 1 [stylingandroid.com]
- Part 2 [stylingandroid.com]
- Part 3 [stylingandroid.com]
- Part 4 [stylingandroid.com]
- Part 5 [stylingandroid.com]
- Part 6 [stylingandroid.com]
- Part 7 [stylingandroid.com]
- Part 8 [stylingandroid.com]
Introducing Constraint Layout [tools.android.com]
Wolfram’s post: Some thoughts on Android’s new Constraint Layout and Android Studio’s new Design Editor [grokkingandroid.com]
ADB episode-50 [androidbackstage.blogspot.com]

Hired – special offer: double the signing bonus!

Contact #

049: Translating an app for different languages with Dan Lew

Mon, 18 Jul 2016 00:01:36 UTC

Download directly

Friend of the show Dan Lew makes a return! In this show Kaushik talks to Dan about translating an app for other languages.

Show Notes #

Ep 39: Elliot Chenger [fragmentedpodcast.com]
AutoFitting TextViews [github.com]
Transifex – service for helping with translations
Pseudo localization [danlew.net]
Xliff [wikipedia.org]
Phrase lib by Square [github.com]
Ahmed’s Droidcon SF talk: From Right to Left and Back [youtube.com]
Internationalis(z)ing Code – Computerphile [youtube.com]
What your emojis actually look like [youtube.com]

Hired – special offer: double the signing bonus!

Contact #

@fragmentedcast [twitter.com]
@danlew42 [twitter.com] and Dan’s website [danlew.net]
@donnfelker and +DonnFelker
@kaushikgopal and +KaushikGopalIsMe

048: AndroidDev tips and tricks from 2016 (I)

Mon, 11 Jul 2016 00:01:46 UTC

Download directly

2016’s first installment of a grand bonanza of tips and tricks for #AndroidDev! Donn and Kaushik talk about all the tips and tricks they’ve picked up over the first part of this year.

Show Notes #

Orthogonal podcast
GDG – Google Developer Groups [developers.google.com]
Ep 028: Fragmented – tips and tricks from 2015 [fragmentedpodcast.com]
DF: Developer happiness is a real thing; Learn Kotlin.
KG: Prevent logcat clearing on app crash
- link 1 [stackoverflow.com]
- link 2 [stackoverflow.com]
KG: IntelliJ command line launcher:
- git diffing [pontarelli.com]
- regular diffing [jetbrains.com]
- IO 2016 session: Expert guide to Android Studio [youtube.com]
DF:
- KeyPromoter plugin [jetbrains.com]
- Philippe Breault [developerphil.com]
DF: Window management tool
- Divvy [mizage.com]
- Moom [manytricks.com]
- Slant article comparing window management tools (for the Mac) [slant.com]
- Phoenix – lightweight open source js configurable tool [github.com]
Annyce’ caster.io videos [caster.io]
DF:
- Postman chrome extension [chrome.google.com]
- Runscope [blog.runscope.com]
Donn’s git alias (un)watch [gist.github.com]
git config:
- Donn [gist.github.com]
- KG [gist.github.com]
KG: LogExOnlySubscriber.java – log exceptions only subscriber [gist.github.com]
KG: RxSchedulerHook.java – Lazy man’s RxJava Espresso scheduler hooks [gist.github.com]
DF: Shush [mizage.com]
KG: Intellij plugins
- String Manipulation [plugins.jetbrains.com]
- Lines Sorter [plugins.jetbrains.com]
- Open on Github – see last line in blog post [blog.jetbrains.com]
DF:
- 8 steps to a pain free back [amazon.com]
- IKEA – Bekant standup desk [ikea.com]
- Autonomous – SmartDesk [autonomous.ai]

Hired – special offer: double the signing bonus!

Contact #

047: Custom Views & ViewGroups with Huyen Tue Dao

Tue, 05 Jul 2016 00:01:05 UTC

Download directly

In this episode we talk to Trello engineer, GDE, YouTuber, Caster IO instructor and View magician Huyen about all things custom View/ViewGroups.

Show Notes #

Android Dialogs [youtube.com]
Huyen’s Custom Views/View Groups Part 1 [caster.io]
How Android draws views [developer.android.com]

Resources #

Huyen’s caster.io series [caster.io]
New Circle – Enhancing Android UI with Custom Views [youtube.com]
Loving Lean Layouts – DroidCon SF 2016 [youtube.com]
Custom Layouts on Android – Lucas Rocha [lucasr.org]
Taming Android UI’s – Erik Burke – Square [youtube.com]
Android Performance Patterns – Custom Views and Performance [youtube.com]

Contact #

046: okJesse – A deep discussion on okHttp, okio and Retrofit

Mon, 20 Jun 2016 12:39:40 UTC

Download directly

Everyone loves Retrofit & okHttp. But how did they come about? Why ok? What was the need for such libraries? We went knocking on the doors of Square trying to find the answers to these question. We were lucky cause we found probably the nicest most brilliant Android/Java developer of our times – our good friend Jesse Wilson and without surprise, he crushes it!

He gives us the scoop on the origin stories of these amazing libraries and also gives us insight into okio and why it’s such a game changer today.

Direct download

Show Notes #

Guice – DI lib [github.com]
Fragmented 21 : Diving Deep with Dagger (Cameo by Jesse Wilson) [fragmentedpodcast.com]
Android’s HTTP Clients
- Apache Http Client [developer.android.com]
- Http URL Connection [developer.android.com]
- Jesse’s blog post on the subject [android-developers.blogspot.com]

Okio #

Announcing okio [squareup.com]
okio source [okio.com]

Retrofit github throwback #

Retrofit very first commit – crazybob [github.com]
ShakeDetector in Retrofit [github.com]

Moshi #

Moshi – json parsing [github.com]
Gson [github.com]

Sponsors #

Rollbar – special offer: Bootstrap plan free for 90 days

Contact #

045: Bluetooth (LE) with Dave (devunwired) Smith

Mon, 13 Jun 2016 00:30:15 UTC

Download directly

We’ve always been curious about technology and the software surrounding embedded devices and the like. One such technology that’s ubiquitous these days is Bluetooth (LE). In this show we talk with embedded technology expert and all round super smart AndroidDev Dave Smith a.k.a the wonderful devunwired.

We try to get a high level understanding of how Bluetooth works. From a developer’s perspective, how does this tech work? Why should we as AndroidDevs be interested in this technology. What boundaries can we push? How can we effectively use this technology? In this episode we pick Dave’s brain and try to answer some of these questions.

Show Notes #

Dave’s talks on Bluetooth #

Android Lollipop: Bluetooth LE Matures [youtube.com]
Developing Bluetooth Smart Applications for Android Tutorial [youtube.com]
Dave’s talk: Google Beacons – AnDevCon [youtube.com]

Other resources: #

Bluetooth Classic [developer.android.com]
Bluetooth LE [developer.android.com]
Apple docs – Bluetooth for Developers [developer.apple.com]
Bluetooth specification [bluetooth.org]
- check Advertisements: Volume 3, Part C, Section 11
- check GATT: Volume 3, Part G

360|Andev #

Use special code “Fragmented” if you’re registering for the 360|Andev conference to get a 10% discount.

Sponsors #

Rollbar – special offer: Bootstrap plan free for 90 days

Contact #

044 – Effective Java for Android Developers – Item #10

Mon, 06 Jun 2016 11:16:18 UTC

Download directly

In this mini-Fragment, Donn talks about Item #10 of the Effective Java series – Always Override toString. You’ll learn why it’s important for your own sanity, future developers, and overall developer happiness.

This episode is sponsored by Hired.com.

Show Notes #

Hired.com

Contact #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

043: Google IO 2016 (Part 2)

Wed, 01 Jun 2016 01:00:11 UTC

Download directly

In Part 2 of our Google IO special we continue asking some simple questions to the best AndroidDev today. This concludes our IO special for this year. Hope you enjoyed it as much as we did!

By popular demand we added some extra specials at the very end so make sure to listen all the way through :)

Show Notes #

Pierre-Yves Ricau (Square)
Israel @rallat Ferrer Camacho (Square)
Tor Norbye
Kelly Shushter
Eugenio Marletti (Clue)
- @workingkills
- Life without fragments
Sebastiano Poggi (Novoda)
Mike Evans
- @m_evans10
- Robinhood
Zarah Dominguez
- @zarahjutz
- Pocket Casts

Contact us: #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

042: Google IO 2016 (Part 1)

Tue, 31 May 2016 01:00:42 UTC

Download directly

In Part 1 of our Google IO special we talk to a whole bunch of amazing AndroidDev. We go around asking them a few simple questions. Questions, that you probably thought to ask when you saw them in person, but just forgot to.

Oh and you really should listen all the way to the end :)

Show Notes #

Annyce Davis (Offgrid Electric)
Mark Allison (Freelancer currently contracting for AMEX)
- @MarkIAllison
- Styling Android
Wiebe Elsinga
- @welsinga
Jake Wharton (Square)
- @JakeWharton
- Kotlin Night in SF
Ryan Harter
- @rharter
- Pocket Casts
Lisa Wray (Genius)
- @lisawrayz
Rebecca
- @riggaroo
- 22Seven
Erik Hellman
- @ErikHellman
- Fabulous – Motivate Me

Contact us: #

Contact form
@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

Stay tuned for Part 2 where we talk to another list of top notch Android developers and get their answers for these questions.

041: YAGNI

Tue, 24 May 2016 16:15:03 UTC

Download directly

In this mini Fragment, Donn talks about one of his favorite topics, YAGNI. YAGNI is an acronym that stands for “You Aren’t Gonna Need It”. Donn explains what it is, why its useful and shares a personal story of how he was introduced to the YAGNI concept back in 2008.

Direct download

Show Notes #

Caster.IO Use the coupon code “fragmented” to receive 15% off any monthly subscription.

Contact #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

040: Internal Library Dependency Management with Kelly Shuster

Mon, 16 May 2016 01:00:36 UTC

Download directly

In this mini episode, we talk with the lovely Kelly Shushter about Internal Library Dependency Management. Kelly is a GDE, the Director of Women Who Code (Denver chapter), a developer at Thoughtbot, a mind blowingly good AndroidDev and just an all round boss of everything.

She gives us the rundown explaining different strategies for maintaining and managing internal libraries in your organization/company.

Show Notes #

Women Who Code [womenwhocode.com]
Droidcon SF 2015 – Android Internal Library Dependency Management [youtube.com]
Fixing a bug later is costly? [programmers.stackexchange.com]

Solutions #

Git submodules [git-scm.com]
Repo by Google [source.android.com]
Artifactory – Jfrog [jfrog.com]
Jitpack [jitpack.io]
Kelly’s hack to toggle between maven lib dependency and local source [github.com]

Sponsors #

Caster.io [Coupon code: Fragmented]

Contact #

@kellyshuster [twitter.com]
kiodev.com
@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

039: Talking TextView with Elliott Chenger

Mon, 09 May 2016 00:00:59 UTC

Download directly

In this episode we chat with our friend an all round amazing AndroidDev Elliott Chenger. Elliot does Android development for Under Armour and knows a thing or two about TextViews. We talk TextViews, font rendering complications in Android, performance optimizations, localization (vs internationalization), ECDC (it’s a thing!) and wind the discussion off with some design software tools out there.

Show Notes #

Under Armour : Health box [underarmour.com]
Droidcon NYC 2015 – TextView how to turn design into reality for multiple languages [youtube.com]
Android’s Font Renderer : Efficient text rendering with OpenGL ES Romain Guy [medium.com]
DÖnn Fëlker
TextView packages : Slide from Elliott’s talk [speakerdeck.com]
Static Layout [developer.android.com]
Boring Layout [developer.android.com]

Performance #

Traceview in Android Studio [tools.android.com]
Profile GPU rendering
Static Layout : for text that will not be edited after it is laid out
Dynamic Layout : text layout that updates itself as the text is edited
Improving comment rendering on Android [instagram-engineering.tumblr.com]
Sample implementation of technique Instagram describes [stackoverflow.com]
Simple trick explaining TextView wrap_content vs fixed height
Energy glitches with Apple music app
Google Localization Checklist [developer.android.com]

Design tools #

Zeplin
Red Pen
Sketch 3 For Android Developers (Big Android BBQ 2015) [youtube.com]
Sketch app

The Nerdery [nrdryjobs.com/fragmented]

Contact #

@Echenger [twitter.com]
@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

038: What you Need to know about N

Mon, 02 May 2016 00:00:42 UTC

Download directly

In this episode, Donn and Kaushik look at the Android N developer preview. They highlight the biggest changes that you as an Android Developer should keep an eye out for. There are tonne of features in N, so listen to this episode to get the highlights.

Show Notes #

First preview of Android N: Developer API & Tools [android-developers.blogspot.com]
Instruction for setting up your dev environment for the N preview (~=> Lambda support) [developer.android.com]
Java 8 Language features [developer.android.com]
ADB episode : 45 State of the Art
Lambdas do not retain enclosing reference (unless really needed)
- commit note on Jack toolchain [android.googlesource.com]
- JacklrBuilder source createMethodInfoforLambda [android.googlesource.com]
- RxJava Android Samples using lambdas [github.com]
- javap – The Java class file Disassembler [docs.oracle.com]
Issue tracking Annotation processing options in Jack [code.google.com]
Other Java 8 language features for N [developer.android.com]
Android MultiWindow features [developer.android.com]
GCM Network Manager a.k.a Job Scheduler [developers.google.com]
Android Notification styles [developer.android.com]

Resources #

What’s new in Android N: Ian Lake + Joanna smith [youtube.com]
5 tips for preparing for multi window in Android N: Ian Lake [medium.com]
DroidCon SF keynote: Chet and Romain [youtube.com]
Random musing on the N developer preview [commonsware.com]

Hired – special offer: double your accepting bonus $2000

Contact #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

037: Decompress 1 : Xcode, Fonts sizes, Testing and yes Agera!

Mon, 25 Apr 2016 02:00:33 UTC

Download directly

In this very first edition of our Decompress episode we talk about the fonts we love to use, some Xcode hating, Testing woes and the intensely discussed library that Google recently released Agera!

Shownotes: #

Agera

Hired – special offer: double your accepting bonus $2000

036: Working Remotely

Mon, 18 Apr 2016 10:52:59 UTC

Download directly

In this mini Fragment we touch on a highly requested topic – working remotely. Donn talks about how to ease into remote working, tools for working remotely, tips and tricks for staying sane and productive while remote and he wraps it up by discussing the benefits employers have when hiring a remote workforce.

Show Notes #

Remote work is best suited for information workers (programmers, designers, engineers, etc)
Read Remote by DHH and Jason Fried
- Great book that echoes what I feel about working remote.
- Tip: Listen to it on Audible, it’s faster to consume.
How to ease into remote work at your current job
- Convince manager to allow a 1 day trial for one – three months.
- Remote day should be on Friday (fewer critical things happen on Friday, on average)
- After trial, if success, aim for 2-3 days of remote work. (Again, do this at the end of the week. Wed,Thu, Fri)
- Once successful, rally for full week of remote with an occasional in office visit (a day every week work two)

Staying sane while working remote #

Donn’s blog post on this topic
Create a work day schedule (5am-2pm, 8am-5pm, 10am-7pm, etc)
- When you’re done, you’re done. Leave work (your office/etc).
Schedule. Schedule. Schedule. Stick to a schedule.
- Get up at the same time
- Get dressed for work (no PJ’s etc)
- Do your hair.
- Be presentable
- This is all mental
Prepare for the day
- Get coffee/tea/water and snacks
- Try to limit the opportunity of distractions
During the day
- Take a lunch, away from your desk.
- Go out for lunch with someone (significant other, friend, etc) at one to two times a week.
- Work out of the house a couple times a week, this increases our creativity.
Outside of Work
- You need social interaction, Cabin Fever is a real thing.
- Exercise 3-4 times a week if possible.
- Group classes are perfect for this.
  - CrossFit
  - Martial Arts
  - Yoga
  - Pilates
  - etc
Communication When Remote
- Put 3x-4x more effort into communicating than previous. You’re not visible seen so you need to be more vocal.
  - Call
  - SMS
  - Blow up the Slack/Hipchat channel/etc
  - Objective – Clear your own path

Tools #

For remote to work effectively, everything should be considered remote. If one employee is remote, then all meetings should occur as if the team is remote. This ensures that everyone can work effectively without missing anything.
Communication
- Group Chat
  - Slack
  - HipChat
- Video Chat
  - Google Hangouts
  - Skype
  - Join.me
  - Zoom.us
- Task Management
  - Trello
  - Jira
  - Asana
  - GitHub

Remote for Employers #

Benefits from Remote workforce
- Much larger talent pool than the exhausted pool (or non-existent one that local). Higher quality employees/contractors/consultants for the same overhead.
- Remote creates much more loyal employees. You’re giving them their life back and this is reciprocated.
- Your company becomes anti-fragile as you’re able to adapt with the industry faster. You can hire in areas others cannot.
- On average, remote employees work harder and are more productive than their office counterparts.
- Less overhead! No need to pay for additional office space.

Rollbar – special offer: Bootstrap plan free for 90 days

Contact #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

035: All about Vector support on Android

Mon, 11 Apr 2016 08:00:12 UTC

Download directly

In this mini Fragment we touch base on all the things you need to know about Vector drawables for Android development. How one can use it today, the recommended usage for vector drawable and formats, the limitations and everything else you need to know as an Android developer.

Show Notes #

Vector Drawable [developer.android.com]
Trello’s Victor [github.com]
- What’s our Vector Victor [youtube.com]
Android Studio 1.4 release (with Vector Asset Studio announcement) [android-developers.blogspot.com]

Support library announcements #

Android Support Library v23.2 [android-developers.blogspot.com]
- Vector Drawable backported
- Ian Lake also gives us the instructions in this post
9% of AAR saved on AppCompat [chris.banes.me]
Android Support v23.3.1 announced [plus.google.com]
Vector Asset Studio [developer.android.com]

Animated Vector Drawable #

AnimatedVectorDrawable [developer.android.com]
Chiuki on Animated Vector Drawables [sqisland.com]
Road Runner library [github.com]
- see youtube demo [youtube.com]

Problems: #

Dan Lew’s SVG test project [github.com]
bug report on no gradient support for vectors [code.google.com]
Vector format restrictions : Vector Asset Studio [developer.android.com]
Better conversation tool svg2android – Juraj Novák [inloop.github.io]

Other references: #

Mark Allison – Vector Drawable Part 1 [stylingandroid.com]
Mark Allison – Vectors for all (Almost) [stylingandroid.com]
Using Android Vector Drawable [code.tutsplus]

Rollbar – special offer: Bootstrap plan free for 90 days

Contact #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

034: Effective Java for Android Developers – Item #9

Mon, 04 Apr 2016 05:00:24 UTC

Download directly

In this mini Fragment, we introduce Joshua’s ninth Item. After the last somewhat mind boggling item, this is a much welcomed simple, practical yet important one: Always override hashCode when you override equals.

Donn goes into the importance of implementing hashCode and why it’s so important to override it for maintaining harmony with the equals method. Also 42 and the answer to life ? He then goes into some tips on implementing a good hashCode and a standard recipe for the same.

Go forth and override them hashCodes!

This episode is brought to you by Rollbar. Go to rollbar.com/fragmented to get their Bootstrap plan for free for 90 days. Stay tuned for more items from our “Effective Java for Android developers” Fragment series.

Contact #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

033: Talking Gradle with GDE Annyce Davis

Mon, 28 Mar 2016 05:00:27 UTC

Download directly

In this episode we talk Gradle with the amazing and awesome Annyce Davis. We deal with the basics of Android’s build system and dabble with some tips on improving your build times.

Also we released our first ever Fragmented T-shirt in collaboration with another amazing GDE – Taylor Ling of AndroidTee fame.

Show Notes #

Annyce’s talk where she mentions Cyclomatic complexity [youtube.com]
OffGrid Electric
Corey Latislaw on TDD and Testing [fragmentedpodcast.com]
Annyce Davis’ Caster.io videos
DAG: Directed Acyclic Graph [wikipedia.org]
DAG discussion on Fragmented – Seek to 18:35
What commands does Andorid Studio’s gradle aware make perform? [stackoverflow.com]
- MakeBeforeRunTaskProvider source [android.googlesource.com]
Creating a Gradle Plugin
Use apply from in gradle to include external files
Learn Groovy
Gradle dry run flag [docs.gradle.org]
Madis Pink – Optimizing gradle build time : Droidcon Paris [youtube.com]

Annyce’s talks & videos: #

Be a good citizen: Develop Maintainable apps [youtube.com]
Caster.io videos

Fragmented T-shirts #

Purchase here

Contact #

@brwngrldev [twitter.com]
@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

Fragmented Podcast Update – Sol 2 – TSHIRTS!

Sat, 26 Mar 2016 07:30:24 UTC

Everybody loves t-shirts! More than one listener in the past has asked us when Fragmented is going to have a t-shirt – one they can wear at conferences and such.

We thought about it, but never could hone in on a wicked design. The bar is set SUPER high for good t-shirts these days! The design has to be iconic, yet you should be able to comfortably wear it to work and it shouldn’t turn you into a public billboard. Most importantly though – the design should be distinctly Android…

That calls for an extra special t-shirt and we’re stoked to tell you this… we have something extra special for you … check it out …

Announcing the Limited Edition Fragmented T-Shirt:

If the design is familiar, it should be. We worked with Taylor Ling who’s released a bunch of amazing DroidTees in the past. Taylor Ling is a phenomenal designer, who also happens to be a GDE for design and clearly understands Android design intimately.

We asked Taylor if he would do a limited edition special Fragmented t-shirt and he gladly obliged (thanks a ton, Taylor). We are super stoked to be releasing these t-shirts. They’re available in a whole bunch of colors and sizes for a limited time. We would be honored if you got one for yourself!

Purchase the t-shirt here.

032: Making sense of Android Support Library version numbers

Mon, 14 Mar 2016 06:00:56 UTC

Download directly

The Android Support library framework is the biggest boon to Android developers. But how does one makes sense of the different versions and revisions available? In this fragment we try to address that question.

Show Notes #

Introducing AppCompat V21 [android-developers.blogspot.com] [android-developers.blogspot.com]
Prev episode with Mike Wolfson [fragmentedpodcast.com]
Android Support Library – “Revision” changelog [developer.android.com]
Revision vs Version [stackoverflow.com]
Introducing Design Support Library
Command to see dependency graph:

 ./gradlew -q app:dependencies
+--- com.android.support:design:23.1.1
| +--- com.android.support:appcompat-v7:23.1.1 (*)
| +--- com.android.support:recyclerview-v7:23.1.1
| | +--- com.android.support:support-annotations:23.1.1
| | \--- com.android.support:support-v4:23.1.1 (*)
| \--- com.android.support:support-v4:23.1.1 (*)

Seinfeld Auditions

Contact #

Fragmented Spec channel (sign up at the bottom)
@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]
Contact email form

031: Effective Java for Android Developers – Item #8

Mon, 07 Mar 2016 15:32:59 UTC

Download directly

In this mini Fragment, we introduce Joshua’s eighth Item. This one is a doozy, probably one of the longest items in the group of the effective Java series, but most definitely quite important.

This episode is brought to you by Rollbar. Go to rollbar.com/fragmented to get their Bootstrap plan for free for 90 days.

Stay tuned for more items from our “Effective Java for Android developers” Fragment series.

Show Notes #

Effective Java (2nd Edition) – Joshua Bloch

Obey the general contract when overriding equals

When to not override equals: #

Each instance of the class is inherently unique.
You don’t care whether the class provides a “logical equality” test.
A superclass has already overridden equals, and the superclass behavior is appropriate for this class.

The equals method implement an equivalence relation which states it must be: #

Reflexive
Symmetric
Transitive
Consistent
For any non-null reference x, x.equals(null) must return false.

A recipe for a high-quality equals method is as such: #

Use the == operator to check for references to this object.
Use the instanceof operator to check if the argument has the correct type
Cast to the correct type.
Check all field types and corresponding field types.
Finally, when done, ask yourself – is this method symmetric, transitive and consistent?

Caveats #

Always override hashcode when you override equals
Don’t be too clever!
Don’t substitute another type for Object in the equals declaration.

Contact #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

030: Material Design for developers with GDE Mike Wolfson

Mon, 29 Feb 2016 06:00:06 UTC

Download directly

In this episode we talk to Material Design Master and Google Developer Expert Mike Wolfson. What does Material design mean to us developers? How does one use the numerous support libraries to help with this? What widgets should and shouldn’t we be using? Listen to the show and find out.

Show Notes #

Material Design – Official site
Material Design – The Specification
Google Color Palette – list of “approved” colors
Google Color Palette Library – picking colors from an image
Android Support Lib 23.2 video [twitter.com]
Resource for getting better at Material Design:

Sponsors #

Rollbar – special offer: Bootstrap plan free for 90 days [rollbar.com/fragmented]

Contact #

Mike Wolfson: Twitter Google+ mikewolfson.com
@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

029: All about the infamous 65,536 dex method count

Mon, 22 Feb 2016 06:00:14 UTC

Download directly

If you’ve been an Android developer in the last 2 years, you must have seen this dreaded exception: dex: method ID not in [0, 0xffff]: 65536

Quick googling would immediately bring up the phrase “65K method count” and the recommended solution “multi-dexing”. But if you want to really understand this mysterious number and the reason behind its existence, listen on!

Show Notes #

Official Dalvik specification [source.android.com] (look for invoke- prefix methods)
Android and the Dex limit (great post)
ADB Ep 11 : ART, pART 2 (Trash Talk) (discussion on ART)
MultiDexing [developer.android.com] (solution to your 65K method count woes)

Contact #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

Fragmented Podcast Update – Sol 1

Mon, 15 Feb 2016 18:48:25 UTC

Heya Folks,

We wanted to let you know what we’ve been up to with the Fragmented podcast lately. Don’t worry, all things below are good for you as the listener.

You may or may not have noticed that the episode length has been getting gradually shorter. We’re trying to get it under 40 minutes.

Why under 40 minutes?

Well, simply because we’ve heard nothing but good things about all of our shorter episodes. Plus, research shows that the optimal length of a podcast is somewhere in the realm of 22 minutes.

Ha. 22 minutes. That’s funny.

Have you ever tried explaining a complex topic like dependency injection in 22 minutes, with an intro and outro? Yeah, probably not going to happen … and if we did try to do it … well … the show would be as dry as scarfing down an entire bag of saltines without a gulp of water … #knowwhatwemean? For us, we’re finding that an action packed episode comes somewhere between 30-40 minutes (sometimes over – it is what it is).

Secondly, the shorter fragment episodes are coming back. We’ve taken a short break from fragments to re-identify our strategy with them. We’re still going to cover the Effective Java series, but we’re going to sprinkle those in with other Fragments we want to do. We learned that the listeners really loved the super actionable content like we had in episode 12 (Continuous Integration and Collective Code Ownership). Therefore we’re going to do more of those kind of fragment episodes with Effective Java fragments episodes sprinkled in here and there – think of them like cute little surprise Android cupcakes that you occasionally run into <– See what we did there? Cupcake, Android, get it? .. Ok, stop throwing tomatoes – we get it, we admit … it was a bad joke… :)

Lastly, we’ve decided to join the Spec.FM network. This is the same network that is the home to many other great podcasts, such as – Developer Tea, Design Details, Immutable, Does Not Compute and more.

Why are we joining a network? Simply put – they help us get content out faster and handle a bunch of the administrative workload that we have to deal with. With this extra help we can focus more on the show, the content and getting more episodes out to you folks much faster and efficiently.

What does that mean for you as a listener?

More awesome of course! Hopefully, you notice anything but better content and more frequent releases. That said, we’ve already started moving our feeds over to our new podcast media host at Spec.FM. Hopefully, your podcatcher realizes this and does not double up episodes for you. If it does, let us know so we can try to remedy the situation for others.

Joining a network also helps us out on the admin side too, especially in an area we’re not too versed in … let us explain. There’s an old saying that we’re all familiar with – Time is money. This is also the case with the podcast.

We LOVE doing the podcast, so much in fact that we’d probably both do it full time if we could.

Unfortunately, that’s not possible as we don’t make anything off of the show. It’s actually the opposite – it costs us a bit of cash to keep this thing going. Not that we’re going broke, but it definitely does make the “time is money” adage ring true. That said, we have had quite a bit of interest from companies who have offered to sponsored the show. We tried to figure out how that would look and how it would work and how to set that up. Long story short – we’re not good ad salesmen. We’re good developers (we think … err … we hope we are … Kaushik … we’re good dev’s right ?? … man … I hope so … anyway …).

Spec.FM will help us with some advertising spots on the show. Here’s the thing though, we will only be advertising things we feel our listeners can get value out of. Therefore, you won’t see us advertising used cars, enhancement pills or mortgage deals (wow, that combo of keywords should put us on some spam lists….). The only time an ad will be on our show is when we approve it and feel that listeners could possibly benefit from the product in the ad.

We hope these small, incremental changes help improve the podcast in the long run. <– See what we did there again? Small. Incremental. Just like software! Iterative … releases … Ugh… yeah … bad joke again. Hey, we tried. :)

As always, if you have any questions, let us know, we’d love to hear from you.

Hugs and bunnies and robots and stuff, your Android ear-bud buddies (say that 10 times fast) –

Donn & Kaushik

028: Tips and tricks we picked from 2015

Sun, 14 Feb 2016 18:27:05 UTC

Download directly

Feast yourselves to a grand bonanza of tips and tricks with this episode! Donn and Kaushik talk about the tips and tricks they’ve picked up over the course of 2015.

Show Notes #

Android Dev Summit demo – Structural replace [youtube.com]
Software Design patterns [wikipedia.org]
Reformatting code:
- Reformatting Source code [jetbrains.com]
- Reformat dialog [jetbrains.com] (only VCS changed text)
Library dependency management:
- JitPack (publishing jvm and android libraries)
- Internal library dependency managment – Kelly Shushter
Hadi Hariri on Fragmented Ep 20 talking Intellij shortcuts
Using UiAutomatorViewer to help write espresso tests – Ep. 23: Caster.io [caster.io]
git pre-commit hook [gist]
Intellij – work with embedded Terminal [jetbrains.com] (yes, you can customize btw zsh/bash)
KG’s Update script – morning ritual [gist]
Cyril on Grid Spacing on Android [cyrilmottier.com] (showdividers/divider)
Tor’s issue on maven vs jcenter [code.google.com]

Contact #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

027: Talking Realm with Christian Melchior

Fri, 05 Feb 2016 17:56:26 UTC

Download directly

Realm pro and overall genius Christian Melchior joins us in this episode to talk about all things Realm.

Show Notes #

Contact #

@chrmelchior [twitter.com]
@realm [twitter.com]
@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

026: LetMeExplainYou AndroidDev like a pro

Thu, 21 Jan 2016 09:23:22 UTC

Download directly

In this episode Donn and Kaushik chat with the one and only Israel Ferrer Camacho (@rallat). They discuss a talk Israel gave sometime back on “Android development like a pro”, exchanging war stories on patterns like MVP, MVVP clean architecture etc.

Show Notes #

Rallat’s slides [pdf]
Rallat’s sample repo using different patterns [github]
Burrito Design Pattern [twitter.com]
Working Effectively with Legacy Code [amazon.com]
The Clean architecture [blog.8thlight.com]
Uncle Bob’s talk on Vimeo

Awesome Picks: #

Rallat: #

Rallat’s tweet on Dagger 2 & Scope Provider
Music for the week! The Weeknd
Cmd Shift A – one shortcut to rule them all

Donn: #

Philly ETE (April 11/12) (Donn’s giving a talk)
Life is Short [paulgraham.com]
7 videos on UI Testing and TDD with Espresso : Caster.IO

Kaushik: #

Create a pared-down “lite” version of the app
Pancakes library – alternative to Fragment Manager for views

Contact #

@rallat [twitter.com]
@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

025: Effective Java for Android developers : Item 7

Mon, 28 Dec 2015 02:47:04 UTC

Download directly

In this mini Fragment, we introduce Joshua’s seventh Item and a momentous end to the first chapter: Avoid finalizers

Stay tuned for more items from our “Effective Java for Android developers” Fragment series.

Show Notes #

Effective Java (2nd Edition) – Joshua Bloch

Avoid finalizers

If you don’t know what they are, ignorance is bliss. If you know what they are, avoid them!
Finalizers in Java != destructors in C++ (C++ counterparts to constructors).
In C++ destructors
- you reclaim resources here (Java has GC)
- you also reclaim non-memory resources (use the try-finally block in Java)
(unpredicatable amt of time between object becoming unreachable and finalizer being executed) Never do anything time critical in finalizer!
- System.gc + System.runFinalization increase chances – no guarantee
- System.runFinalizersOnExit + Runtime.runFinalizersOnExit are the ones that do – but they are fatally flawed
Java 7 has try with resources, which is also interesting and auto-closeables. [Android] devs can only dream of these.
If an uncaught exception is thrown in a finalizer, it is ignored, and the finalization abruptly terminates.
Severe performance penalty for using finalizers – (one e.g.) time to create and destroy simple object goes from 5.6ns -> 2400ns
Only valid use: as a safety net or to terminate noncritical native resources.
[Android] you’re probably better off using Android’s lifecycle methods.

Contact #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

024: Effective Java for Android developers : Item 6

Tue, 15 Dec 2015 18:48:43 UTC

Download directly

Joshua’s sixth Item: Eliminate obsolete object references, in a distinctively croaky voice.

Stay tuned for more items from our “Effective Java for Android developers” Fragment series.

Show Notes #

Effective Java (2nd Edition) – Joshua Bloch

Eliminate obsolete object references

Supplemental reading (for the diligent ones that follow shownotes) #

Do click listeners leak memory? [stackoverflow.com]
Square’s LeakCanary
How to leak a context – Handlers and inner classes [androiddesignpatterns.com]
Avoiding Memory leaks [android-developers.blogspot.com]

Contact #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

023: Android Dev Summit Recap

Mon, 30 Nov 2015 00:53:50 UTC

Download directly

Donn and Kaushik cover the happenings of Google’s very first Android Developer conference – “Android Dev Summit”. Together, they attended the conference both virtually and physically! Listen on for the highlights.

Android Dev Summit Schedule
- AndroidDev Twitter account

Sessions #

Android Dev Summit 2015 Keynote [youtube]
Android Studio for Experts [youtube]
Android Testing [youtube]
Firechat – Framework team [youtube]
Firechat – Android Tools and Testing team [youtube]

Sample projects #

Contact us: #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

022: Effective Java for Android developers : Item 5

Fri, 20 Nov 2015 06:26:59 UTC

Download directly

In this mini Fragment, we introduce Joshua’s fifth Item: Avoid creating unnecessary objects.

Stay tuned for more items from our “Effective Java for Android developers” Fragment series.

Show Notes #

Effective Java (2nd Edition) – Joshua Bloch

Avoid creating unnecessary objects

Snippet to demonstrate AutoBoxing problems #

// sum of all positive values
Long sum = 0L;
for (long i=0; i< Integer.MAX_VALUE; i++) {
sum+=i;
}

Contact #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

021: Diving Deep with Dagger

Fri, 13 Nov 2015 16:36:35 UTC

Download directly

Show Notes #

In other news #

Dagger #

Topological Sort

Jesse Wilson Cameo #

Other references #

Awesome picks: #

Donn’s picks: #

Dagger 1 [caster.io]
Intro to RxJava for Android Developers [caster.io]
Intro to Realm for Android Developers [caster.io]
Custom Silicone earbuds [howtogeek.com]
DHH – Reconsider [medium.com]

KG’s picks: #

Cold start illusion [github.com]
Song Exploder – House of Cards [songexploder.net]
Song Exploder – Game of Thrones [songexploder.net]

Contact us: #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

020: Talking Kotlin with Hadi Hariri

Mon, 26 Oct 2015 09:35:37 UTC

Download directly

A tonne of folks have been asking for a show on Kotlin. We got the best person in the business to take us through what could possibly be our new hope.

Show Notes #

No tabs in Intellij [hadihariri.com]

Jetbrains products #

Java – IntelliJ
.Net – ReSharper
CI server – TeamCity
Issue tracking – YouTrack

Smaller IDES #

Web/Node.js – WebStorm
Python/Django – PyCharm
Ruby/Rails – RubyMine
C++ – CLion
ObjectiveC – AppCode

Hadi’s 3 tips for Intellij #

Don’t use the Mouse! Mouseless driven development [vimeo.com]
Cmd Shift A – look up other commands
Don’t use the Find box to find things: Prefer shortcuts like Cmd O/Cmd Shift O

Kotlin #

Kotlin – An open source JVM targeted language
Jake’s doc on Using Project Kotlin for Android [docs.google.com]
Execution in the kingdom of nouns [blogspot.com]
Kotlin : a new hope – talk by Michael Pardo [realm.io]
Tony Hoare saying Null is his Billion dollar mistake [wikipedia.org]

Getting started with Kotlin #

Kotlin Tutorials [kotlinlang.org]
Kotlin Koans [kotlinlang.org]
Try Kotlin online : online & interactive [kotlinlang.org]
Kotlin in two minutes [youtube.com]
Kotlin Slack channel [slack.com]
Books:
- Antonio’s book on Kotlin [leanpub.com]
- Kotlin in Action [manning.com]

Kotlin tools #

Anko [github.com]
Kotlin Android extensions [kotlinlang.org]

Sample projects with Kotlin #

Palette Helper [github.com]
Cinesapp Android Kotlin [github.com]
Kotlin demo [github.com]

Misc #

Killing off Wasabi: Part 1 [fogcreek.com]
Killing off Wasabi: Part 2 [fogcreek.com]

Awesome picks: #

Hadi Hariri #

The collapse of the US-EU Safe Harbor: Solving the new privacy Rubik’s Cube [http://blogs.microsoft.com/]
JavaOne Conference [oracle.com]

Kaushik Gopal #

When looking for solutions to a problem, search the source code first before StackOverflow
When working on a feature, change your launcher activity (temporarily) to the one you’re working on

Donn Felker #

git – assume unchanged [stackoverflow.com]
The Martian Audio Book [amazon.com]
Antonio’s book on Kotlin [leanpub.com]
Also check out his blog [antonioleiva.com]

Contact us: #

@hhariri [twitter.com]
@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

019: Effective Java for Android developers : Item 4

Thu, 15 Oct 2015 06:59:37 UTC

Download directly

Singer and Android developer Donn Felker explores Joshua Bloch’s fourth Item: Enforce noninstantiability with a private constructor.

Stay tuned, cause we got more of these quick ones coming.

Show Notes: #

Effective Java (2nd Edition) – Joshua Bloch

Enforce noninstantiability with a private constructor.

Examples where you don’t want class to be instantiated #

class that groups static methods and static fields (Util like classes think java.lang.Math/java.util.Arrays)
class that groups static methods (including factory methods) for objects implementing specific interfaces (think java.util.Collections)
class that group methods on a final class (vs. extending the class)

Considerations #

Makes no sense to instantiate such “Util” classes
Private constructors prevent instantiation
Important side effect: prevents subclassing

Contact us: #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

018: Effective Java for Android developers : Item 3

Thu, 08 Oct 2015 17:50:20 UTC

Download directly

In this mini Fragment, we introduce Joshua’s third Item: Enforce the Singleton property with a private constructor or an enum type.

Stay tuned for more items from our “Effective Java for Android developers” Fragment series.

Show Notes: #

Effective Java (2nd Edition) – Joshua Bloch

Enforce the Singleton property with a private constructor or an enum type

Approaches #

Create a public static final INSTANCE variable and privatize constructor
Same as 1 but privatize variable and expose access with provide factory method getInstance
Single element Enums

Considerations #

First two approaches are open to Serialization attacks (deserializing creates new instance)
To protect from those declare the fields transient + provide readResolve method
Enums are concise, provide free serialization and ironclad Singleton guarantees and are functionally equivalent to first approach

Supplemental reading (for the diligent ones that follow shownotes) #

Contact us: #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

017: Getting Close with Android Nearby

Mon, 21 Sep 2015 16:15:36 UTC

Download directly

In this power-packed episode, Donn returns… If that wasn’t amazing enough, Andrew and Akshay from Google join us to talk about Android Nearby.

Show Notes #

Follow up #

Fragmented is on SoundCloud [soundcloud.com]
ViewPropertyAnimator has better performance [twitter.com]
Droid Inspector [sriramramani.com]
Jake Wharton’s Scalpel [github.com]

Nearby #

100 days of Google Dev, Episode 47/100 – Andrew on Nearby [plus.google.com]
Chromecast Guest mode when Nearby [support.google.com]

Examples/Documentation #

google sample for Nearby [github.com]
Nearby official docs [developers.google.com]

Awesome picks for the week: #

Andrew: #

svg-android [github] and its various forks
inkscape tutorials by Derek Banas [youtube.com]

Akshay #

Xiaomi mi band [engadget.com]

DF: #

Karma Wifi (donnfelker.com)
Working Remote (modess.io)

KG: #

Google Tone – Chrome extension (chrome.google.com)

Contact #

Fragmented #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]
@andrewbunner [twitter.com]
Akshay’s email [@google.com]

016: Effective Java for Android developers : Item 2

Tue, 01 Sep 2015 17:33:32 UTC

Download directly

In our third Fragment installment, we introduce Josh’s second Item: Consider a builder when faced with many constructor parameters.

Stay tuned for more items from our “Effective Java for Android developers” Fragment series.

Show Notes #

Effective Java (2nd Edition) – Joshua Bloch

Consider a builder when faced with many constructor parameters #

Telescoping Constructor Pattern #

Provide constructor with only required parameters, another with a single optional param, a third with 2 optional params… and so on.
- Advantage: Works well for small number of parameters
- Disadvantage: Does NOT scale well

JavaBeans Pattern #

Call parameterless constructor to create the object; then call setter methods to set required parameter and each optional param of interest.
- Advantage: Scales well, easy (but wordy) to read resulting code
- Disadvantage: Allows inconsistency (if all required params not called); impossible to make classes immutable if using this pattern.

Builder pattern #

winner!
- Advantage: Simulates named optional parameters; allows immutable objects to be constructed; flexible
- Disadvantage: more ceremony to actually construct the Builder Class and finally use.

Example usage from Android source: #

AlertDialog Builder [androidxref.com]

Tip: #

Use IntelliJ to generate your Builders easily

Contact us: #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

015: Amanimations – Animations with Amanda

Fri, 21 Aug 2015 07:15:23 UTC

Download directly

In this episode we talk to Amanda about how she got started as an Android developer, working at Venmo, her path to mastering Java and Android, dabbling with the dark side and Animations in Android!

Show Notes #

Learning Java and Android #

Java for Dummies [amazon.com]
Effective Java (2nd Edition) – Joshua Bloch [amazon.com]
Android programming: The Big Nerd Ranch Guide [bignerdranch.com]

Computer Science #

CS50 by Harvard University: David Malan [youtube.com]
CS61B by UCBerkely: Jonathan Shewchuk [youtube.com]
MIT 6.00 by MIT Opencourseware [youtube.com]

Venmo #

Venmo: The Musical 2015 (lip dub)
Hack Week at Venmo [venmo.com]

Swift/iOS and other languages #

Kotlin [kotlinlang.org]

Animations #

Snowdream github repo [github.com]
DevBytes youtube playlist
Chet Haase on Animations in Honeycomb [blogspot.com]
Droid Inspector [sriramramani.com]
Android ObservableScrollView [github.com]

Awesome picks for the week: #

Amanda #

On being a senior engineer [kitchensoap.com]

KG: #

Guillotine animation #

how we developed the guillotine menu animation for Android [yalantis.com]
how we developed the guillotine menu animation for iOS [yalantis.com]

Timely like Animations #

Visualizing the Timely number tweening animation [youtube.com]
Implementing Timely’s tweening animation [sriramramani.wordpress.com]

Contact #

Amanda #

@mandybess [twitter.com]

Fragmented #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

014: Effective Java for Android developers : Item 1

Mon, 10 Aug 2015 08:00:10 UTC

Download directly

We’ve mentioned the book “Effective Java” by Joshua Bloch quite a few times on previous episodes. At this point, everyone knows they should have read this book (quadruple times). But it’s a dense read and everyone could use a reading buddy. Also, what does Effective Java look like through the eyes of an Android developer?

In this second installment of our Fragment (a.k.a mini-episode), we thought we’ll do our listeners a favor and help with that reading. We introduce the very first of these venerable “Items”: Consider providing static factory methods instead of constructors.

Stay tuned for more items from our “Effective Java for Android developers” Fragment series.

Show Notes #

Effective Java (2nd Edition) – Joshua Bloch

Consider providing static factory methods instead of constructors #

static factory method makeText for Toast class [androidxref.com]
ObjectAnimator [androidxref.com]:
- .ofInt [androidxref.com]
- .ofArgb [androidxref.com]
- .ofFloat [androidxref.com]

Advantages: #

You can control the name and thus give it much more meaningful names
You are not required to create a “new” object each time they are invoked
You can even return an object that’s a subtype of the return type (unlike constructors which only return class type)
- e.g. Java Collections framework [grepcode.com]

Disadvantages: #

Classes without public or protected constructors cannot be subclassed
Static factory methods are not readily distinguishable from other static methods

Takeaways #

“Consider” using static factory methods (not always)
Use newInstance when creating Fragments [androiddesignpatterns.com]
Use newIntent static factory method for creating intents inside the target activity.

Contact us: #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

013: Corey Latislaw on TDD and Testing

Mon, 03 Aug 2015 18:05:36 UTC

Download directly

In this episode, we revisit the topic of Testing, looking at it from a TDD perspective. Globetrotter, Kata Queen, TDD practitioner and overall boss of Android development – Corey Latislaw joins us in this episode with thoughts, tips and tricks on pulling off TDD. She also shares some of her wicked sketchnoting tips and made a very special Sketchnote just for this episode! Have a look at the sketchnote here.

Show Notes #

GDG [developers.google.com]
GDE [developers.google.com]
- GDE Android – Ms.Latislaw [developers.google.com]
- GDE Android – Mr.Felker [developers.google.com]

Sketchnoting #

The Sketchnote Handbook – Mike Rohde [amazon.com]
Sketchnoting for Techies [coreylatislaw.com]
Corey’s Google I/O Sketchnotes [coreylatislaw.com]
Corey’s live sketchnoting (with videos) [coreylatislaw.com]
Kids on Computers [kidsoncomputers.org]

Corey’s books #

Android Activity Book [gumroad.com] (coupon “fragmented” for $5 off)
Android Theory Book [gumroad.com] (coupon “fragmented” for $5 off)
Running Code Coverage in Android Studio [stackoverflow.com]

Katas #

Video workshop [gum.co] (coupon “fragmented” for $5 off)
Simple Android app [coreylatistlaw.com]
Robolectric Integration [coreylatistlaw.com]

Awesome picks for the week: #

DF: #

KG: #

ANTI PATTERNS every programmer should be aware of [sahandsaba.com]

Contact #

Corey #

@corey_latislaw [twitter.com]
coreylatislaw.com

Fragmented #

@fragmentedcast [twitter.com]
@donnfelker [twitter.com]
@kaushikgopal [twitter.com]

012: Continous Integration and Collective Code Ownership

Tue, 21 Jul 2015 18:23:23 UTC

Download directly

In this episode we’re trying something new. Everyone has requested more episodes of the podcast. In short, everyone wants a weekly show. So this week, we’re introducing what we call a mini-episode … or as we like to call them a “Fragment”. Fragment episodes will be shorter in length but still packed with goodness. They will range from ~7-25 minutes in length and will showcase either Kaushik, myself (Donn) or both of us.

In the first “Fragment” installment we’re going to talk about Continuous Integration (CI) and Collective Code Ownership (CCO). Donn talks about what CI is, why its important and how it benefits you and your team. He then dives right into CCO and how it can be facilitated through testing.

We hope you enjoy these new mini-episodes … aptly named … Fragments. :)

Show Notes #

Thoughtworks – Continuous Integration [thoughtworks.com]
Working Effectively with Legacy Code – Michael Feathers [amazon.com]

Continuous Integration solutions: #

Jenkins CI [jenkins-ci.org]
- Cloud solution- Cloudbees [cloudbees.com]
TeamCity [jetbrains.com]
CircleCI [circleci.com]
- Setting up CI for Android [caster.io]
Ship.IO [ship.io]
TravisCI
- (open source) Travis CI org [travis-ci.org]
- (commercial) Travis CI com [travis-ci.com]

Continuous Delivery: #

Deploybot (previously) Dploy.io [deploybot.com]
Codeship [codeship.com]

Contact #

Donn Felker #

@donnfelker [twitter.com]
donnfelker.com

Kaushik Gopal #

@kaushikgopal [twitter.com]
kaush.co

011: The Fowler Road to a Clean Architecture

Tue, 14 Jul 2015 18:12:12 UTC

Download directly

In this episode – Donn and Kaushik dive into a topic that is very near and dear their hearts – application architecture. They talk about how Martin Fowler has inspired a lot of their architectural decisions and how they’re moving towards defining what a clean architecture means to them and other developers. They talk about Model View Presenter, Model View Controller and many other topics that surround these two common patterns. Take a listen and go for the ride on architecture train … all aboard!

Show Notes #

Chit-chat: #

Exponential backoff with RxJava [github.com]
RxJs – ReactiveExtensions for Javascript [github.com]

Follow up: #

Moving GC only applicable when app goes into background:
- A closer look at ART in Android L (see last paragraph) [anandtech.com]
- Google I/O 2014: The ART Runtime [youtube.com]

The road to a clean architecture: #

Bad practices:
- Cargo cult programming [wikipedia.org]
- God objects [wikipedia.org]
Martin Fowler’s articles on Patterns of Enterprise Application Architecture:
- Supervising Controller [martinfowler.com]
- Presentation Model [martinfowler.com]
- Passive View [martinfowler.com]
- Martin Fowler’s Book P of EAA [amazon.com]
Decoupling the presenter [mattlogan.me]

Other approaches to clean architectures: #

MVVM on Android – what you need to know [willowtreeapps.com]
Model View ViewModel for iOS [teehanlax.com]
VIPER architecture on iOS [objc.io]
VIPER inspired Clean Android architecture [speakerdeck]
Architecting Android the clean way [fernandocejas.com]
MVP Android [antonioleiva.com]

Awesome picks: #

Donn:

Learning RxJava for Android by example – Kaushik’s talk [youtube.com]
Loading data from multiple source [danlew.net]
StorIO [engineering.pushtoreresh.com]
Mocks aren’t Stubs [martinfowler.com]

Kaushik:

Rebound animation library [facebook.github.io]
- Will Bailey (creator of Rebound):
  - OrigamiActivity.java [gist.github.com]
  - Under the hood [code.facebook.com]
  - Example 1 [youtube.com]
  - Example 2 [youtube.com]
  - Example 3 [youtube.com]
  - Example 4 [youtube.com]
- Springy animations with Rebound [parallelcross.com]

Contact #

Donn Felker #

@donnfelker [twitter.com]
donnfelker.com

Kaushik Gopal #

@kaushikgopal [twitter.com]
kaush.co

010: Boning Up on Core Java

Wed, 24 Jun 2015 02:32:09 UTC

Download directly

In this episode Donn and Kaushik talk to the very talented Michael Bailey about core Java principles and practices. Michael has quite the deep and passionate understanding of Java and we thought it would only be perfect to share this episode with a very passionate Java crowd – Android developers. We talk about IntelliJ, Testing, Inheritance, Static Code analysis, Garbage Collection, Data Structures and much more in this episode. If you’re looking to learn a thing or two about Java, then this is your episode. We hope you enjoy.

Show Notes #

elapsedRealtimeNanos for getting wall time [developer.android.com]
Android Pay announcement [officialandroid.blogpost.co.uk]

Intellij information: #

Curated list of IDE plugings by Jetbrains [blog.jetbrains.com]
Key promoter plugin [plugins.jetbrains.com]
Productivity Guide [jetbrains.com/help]
Extending + Shrinking selection [jetbrains.com/help]

Testing talk: #

Google acquires Appurify [techcrunch.com]
Cloud Test Lab (erstwhile Appurify) [developers.google.com/cloud-test-lab]

Great books on improving your Java skills: #

Gang of Four [amazon.com]
Effective Java (2nd Edition)- Joshua Bloch [amazon.com]

Effective code review technique (WTFs a minute) [cryhavok.org]

On inheritance: #

Item 15 : Design and document for inheritance or else prohibit it
Item 16 : Favor composition over inheritance
Chris Banes on using AppCompatDelegate [twitter.com]

Static code analyzers: #

Checkstyle, PMD, Findbugs [github.com]
Android Lint [developer.android.com]
Findbugs [sourceforge.net]
PMD [sourceforge.net]
blog post setup static code analysis tools [vincentbrison.com]
Infer by Facebook [code.facebook.com]
John Carmack In-Depth: static code analysis [gamasutra.com]

Garbage collection: #

Google IO 2011 talk [youtube.com]
Medium article – Garbage Collection[medium.com]
LeakCanary by Square [github.com]
What is meant by immutable [stackoverflow.com]

Data structures for Android #

ArrayMap (Android alt. to HashMap) [developer.android.com]
SimpleArrayMap [developer.android.com]
SparseArray (Android alt. to mapping int -> Objects) [developer.android.com]

Benchmarking DS: #

Caliper [github.com]
Vogar examples [code.google.com]
ADB Ep. 27 (forEach quirks) (minute 9:07) [androidbackstage.blogpost.com]
Coding for performance blog post [devahead.com]
See Item 21 in Effective Java (Ed. 1) about typesafe enum patterns (this was before enums existed)
Null safety in Kotlin [kotlinlang.org]
Mondegreen [wikipedia.org]
Mad Gab

Awesome picks: #

Michael:

Learn how to file high quality bug report for Android tools [tools.android.com]
List of Android conferences [androidstudygroup.github.io]
GTAC 2015 conference [googletesting.blogpost.com]
Developing for Android – blog post series by Google developers [medium.com]

Kaushik:

library: Android-ReactiveLocation [github.com]
Google App for Donation OneToday [onetoday.google.com]
An article discussing the case between Oracle vs Google [techdirt.com]

Donn:

Vote for my android talks at DroidCon NYC! :)
Anker Charging Station [amazon.com]
22$ Standing Desk [iamnotaprogrammer.com]

Contact #

Michael Bailey #

@yogurtearl [twitter.com]

Donn Felker #

@donnfelker [twitter.com]
donnfelker.com

Kaushik Gopal #

@kaushikgopal [twitter.com]
kaush.co

009: Google IO Special

Wed, 03 Jun 2015 16:52:34 UTC

Download directly

This is the special Google I/O 2015 episode. In this episode – Kaushik makes the trek to Google I/O and chats with various Android developers about their favorite part of Google IO. I was not able to make it but Kaushik was able to interview of top developers in the industry and I’ll tell you what – this is a great episode – I really wish I was there to join him. I know he had a great time chatting and interacting with everyone. We hope you enjoy the show as much as we enjoyed creating it.

Show Notes #

Dan Lew (Trello)
- @danlew42 – twitter.com
- Dan’s Blog – danlew.net
Ty Smith (Twitter)
- @tsmith – twitter
Eric Cochran (IFTTT)
- NightlyNexus – github
- +EricCochranNightlyNexus – plus.google.com
Cyril Mottier (Capitaine Train)
- @cyrilmottier – twitter
- About page – cyrilmottier.com
Shifty Jelly Team
- Pocket Casts – pocketcasts.com
- Philip Simpson
- @geekygecko – twitter.com
- Russell Ivanovic
- @rustyshelf – twitter.com
Amanda Hill (Venmo)
- @mandybess – twitter.com
Dave Smith (New Circle)
- @devunwired – twitter.com
- +DaveSmithDev – plus.google.com
Corey Latislaw (CapitalOne)
- @corey_latislaw – twitter.com
- coreylatislaw.com
Chet Haase
- @chethaase – twitter.com
- Android Backstaage – blogspot.com
Chiu-ki Chan
- @chiuki – twitter.com
Elliott Chenger (Under Armour)
- @echenger – twitter.com
- blog – omitneedlesscode.com
Maria Neumayer (Citymapper)
- @marianeum – twitter.com
Danny Roa (Foursquare)
- @dannyroa – twitter.com
Michael Bailey
- @yogurtearl – twitter.com
Donn Felker
- @donnfelker – twitter.com
- donnfelker.com
Kaushik Gopal
- @kaushikgopal – twitter.com
- kaush.co

008: Pocket Casts Amazingness with Philip Simpson

Tue, 19 May 2015 13:30:43 UTC

Download directly

In this episode, we talk to Philip Simpson, one of the rockstar developers of the amazing Pocket Casts Android Application. We learn about how Philip and his partner, Russell, started Shifty Jelly and how they grew their team from a two-person shop to a small staff all while creating one of top apps on Google Play, Pocket Casts. We also talk about some of the tools, tips and tricks that they’ve used to help them scale, grow and become more effective as indie app developers. We eventually hop into some deep talk about audio software and all kinds of tech in general. If you’ve always wondered what it takes to be an indie app developer then this is the episode for you – Philip does not let us down.

Show Notes/Links #

Pocket Casts
Pocket Weather (for Australia) [play.google.com]
Phil’s stuff
- LG 34” Ultrawide curved monitor (that Phil uses) [amazon.com]
- device test lab [twitter.com]
- Android cheatsheet [gist.github.com]
- Audio effects and features in Pocket Casts [blog.shiftyjelly.com]
Marco Arment
- Accidental Tech Podcast [minute 1:10 he talks of using Go for podcast feed parsing] [atp.fm]
- Build and Analyze podcast (now retired) [5by5.tv]
Pocket Cast Web client [play.pocketcasts.com]
Pocket cast gets sync [lifehacker.com]
Pocket Casts supporting service:
- Pingdom (monitoring uptime)[pingdom.com]
- MySql
- Mongo
- MariaDb
- HockeyApp
Android latency:
- Android latency problem [superpowered.com]
The Tonight show starring Jimmy Fallon (with Billy Joel) [youtube.com]
- Looper app (iOS only :( )
Pocket Casts 3rd party libs
- Butter Knife
- Android Universal Image Loader > Picasso
- Material Dialog library [github.com]
- SnackBar [github.com]
- Mr.Vector (now deprecated) [github.com]
  - Victor by Trello [github.com] (Friend of the show – Dan’s library that we also talked about)
StartUp podcast (by Gimlet media) [gimletmedia.com]
Android Device Dashboard (showing OS breakup)

Awesome picks: #

Philip:

Android tool for mac [github.com]
- Makes it easy to take screenshots, videos, run scripts, bug reports..
37 Signals – Getting Real [37signals.com]
- A book Phil read when we were starting Shifty Jelly

Donn:

Sidekick By HubSpot [getsidekick.com]
- Allows you to see when someone has opened your email etc.
Tim Ferriss Show with Noah Kagan [fourhourworkweek.com]
- Great productivity hacks for everything and overall great show
Grammarly Chrome Extension [chrome.google.com]
- Fix your grammatical errors before the internet fixes them for you.
10 Lessons from 4 Years Working Remotely [whenihavetime.com]

Kaushik:

Custom View Groups– engineer at Facebook [wordpress.com]
LeakCanary by Square

Contact #

Philip Simpson #

Donn Felker #

@donnfelker [twitter.com]
donnfelker.com

Kaushik Gopal #

@kaushikgopal [twitter.com]
kaush.co

007: Jake Wharton on Testing, SqlBrite, NotRxAndroid, RxJava and Much More

Thu, 07 May 2015 03:55:47 UTC

Download directly

In the final part of this two-part segment, we continue our talk with Jake Wharton. We dive right into the topic of testing. Jake then talks about his approach to testing apps in Android and the different languages that he finds interesting. We then move on to RxJava, NotRxAndroid, SqlBrite and many other libraries and topics to round out this great second episode. Again, we’d love to thank Jake for joining us here on the Fragmented Podcast show; it has been an honor. We hope you enjoy it as much as we did.

Show Notes/Links #

u2020 Demo App by Jake [github.com]
- Real Intent Factory [github.com]
- Fake Intent Factory [github.com]
- Slides on Real/Fake Intent Factory [speakerdeck.com – DroidCon Presentation]

Server side frameworks with Java #

Jersey [jersey.java.net]
Jax-rs [jax-rs-spec.java.net]
Go [golang.org]

Other languages #

Jake on using Kotlin for Android [plug.google.com]
Kotlin (by JetBrains) [kotlinlang.org]
Anko [github.com]
Kotlin Android Extensions [kotlinlang.org]
Annotation processing for Groovy code [gradle.org]

Non-Square libraries that Jake uses #

RxJava [github.com]
AutoParcel [github.com]
StickyListHeaders [github.com]
SQLBrite [github.com]
NotRxAndroid [github.com]

Awesome picks: #

Donn:

Android Testing is ten years behind http://philosophicalhacker.com/2015/04/17/why-android-unit-testing-is-so-hard-pt-1/
SquiDB is Yahoo’s new SQLite layer for Android: https://github.com/yahoo/squidb

Jake:

Diversify Your Learning
- Rust – http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html
- Internals of Git – https://codewords.recurse.com/issues/two/git-from-the-inside-out
- GZip Encoding – http://jvns.ca/blog/2015/02/22/how-gzip-uses-huffman-coding/
- Java 10 value objects – http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html

Kaushik:

Contact #

Jake Wharton #

@jakewharton [twitter.com]
jakewharton.com

Donn Felker #

@donnfelker [twitter.com]
donnfelker.com

Kaushik Gopal #

@kaushikgopal [twitter.com]
kaush.co

006: Jake Wharton on Becoming a Better Developer and Creating Successful Open Source Projects (Part 1)

Thu, 30 Apr 2015 04:19:57 UTC

Download directly

In part one of this two-part segment, we talk to the one and only Jake Wharton. He gives us the scoop on how he operates day to day, what he looks for in a good Android developer and how to become a better Android developer. He also touches upon the various sources and non-Java platforms that he draws inspiration from. Finally, he talks about open source and gives tips on leading an open source project.

Show Notes/Links #

Follow up: #

Michel Panzer on UIL [plus.google.com]

Episode topics: #

ActionBar Sherlock [github.com]
Jake’s working environment
- Square Github Styles [github.com]
- No tabs in Intellij [hadihariri.com]
Android source code browsing:
- Android SDK Search by Roman Nurik [chrome.google.com]
- Download the Android AOSP Source [source.android.com]
- AndroidXref [androidxref.com]
- Grepcode Android [grepcode.com]
Device Platform Versions [developer.android.com]
non-Java languages and platforms to draw inspiration from:
- Go [golang.org]
- Rust [rust-lang.org]
- CycleJs [github.com ]
Droidcon Montreal keynote by JW and JW [youtube.com]

Contact #

Jake Wharton #

@jakewharton [twitter.com]
jakewharton.com

Donn Felker #

@donnfelker [twitter.com]
donnfelker.com

Kaushik Gopal #

@kaushikgopal [twitter.com]
kaush.co

005: Image libraries for Android

Fri, 17 Apr 2015 05:51:35 UTC

Download directly

In this episode of Fragmented, Donn and Kaushik start off by discussing the tips and tricks available for efficiently loading images in an Android app. Good image libraries make use of these techniques and perform all the heavy lifting in the background. So they then discuss the different image library options available for Android developers.

Show Notes #

Techniques/tips on effective image rendering in Android: #

Bitmap sizes and allocation: #

Displaying bitmaps efficiently [developer.android.com]
RGB_565, ARGB_888 and other different bitmap configurations [developer.android.com]
Android Camera2 apis [developer.android.com]
Chet Haase DevByte : Bitmap allocation [youtube.com] (bitmaps managed in Dalvik heap post 3.0; so large bitmaps implies large heap implies GC could happen more often)

Reuse bitmaps: #

inBitmap option for Android 3.0 and later [developer.android.com]
before Android 4.4 only equal sized bitmaps with inSampleSize 1 supported [developer.android.com]
Reusing bitmap objects on Android[booking.com]

Downsample bitmaps #

Load a scaled down version into memory [developer.android.com]
- see code for calculateInSampleSize

Caching #

Cache Algorithms – see LruCache [wikipedia.org]
LruCache object in Android [developer.android.com]
JakeWharton DiskLruCache [github.com]
Don’t use Soft or Weak References for your Caches [developer.android.com]
Android Performance Pattern DevByte – why 60fps [youtube.com]

Image libraries for Android: #

Picasso by Square [github.com]
- fetch introduced in V 2.5.0 (Changelog) [github.com]
- Picasso doesn’t do bitmap recycling
- Jake Wharton’s thoughts on Picasso not having a bitmap pool [github.com]
Glide [github.com]
- github issue where author explains tags being used to store metadata [github.com]
- Glide does bitmap recycling
Ion
- DeepZoom with Ion [youtube.com]
- Uses BitmapRegionDecoder to implement DeepZoom [developer.android.com]
Volley
- Ficus Kirkpatrick introduces Volley in Google.IO [youtube.com]
- Doesn’t come with an image caching mechansim out of the box [stackoverflow.com]
Fresco
- Introducing Fresco [code.facebook.com]
- Romain Guy concern over native api call [twitter.com]
Other noteworthies that we did not discuss:
- Universal Image Loader Library comparisons by others:
Picasso vs Glide [inthecheesefactory.com]

Image library comparisons: #

JesseWilson on Picasso vs Fresco :P [twitter.com]
JesseWilson Picasso:Glide :: Coke:Pepsi [twitter.com]
Image comparisons by Koushik Dutta [plus.google.com]
Volley vs Picasso [bignerdranch.com]

Awesome picks: #

Contact #

Donn Felker #

@donnfelker [twitter.com]
donnfelker.com

Kaushik Gopal #

@kaushikgopal [twitter.com]
kaush.co

004: The RxJava show with Dan Lew (Part 2)

Wed, 01 Apr 2015 15:32:23 UTC

Download directly

In this episode of Fragmented, Donn and Kaushik continue their conversation with Dan Lew on RxJava. In the final part of this 2 part series, they talk about many useful RxJava operators and other intricacies of using RxJava in Android.

Show Notes #

RxJava Operators: #

Observable.just [reactivex.io]
Observable.from [reactivex.io]
Observable.defer [reactivex.io]
- Using defer to handle “Old, Slow Code” [blog.danlew.net]
Observable.map [reactivex.io]
Observable.flatmap [reactivex.io]
- map vs flatmap (alchemist and cheese shredding analogy [reddit])
Observable.zip [reactivex.io]
Observable.combineLatest [reactivex.io]
Observable. switchMap [reactivex.io]
Observable.distinctUntilChanged [reactivex.io]
Observable.lift explanation [reactivex.io]
Observable.compose
- Don’t break the chain (using compose) [blog.danlew.net]
Observable.filter [reactivex.io]
Observable.take [reactivex.io]
subscribeOn vs observeOn [stackoverflow.com]
Understanding debounce, buffer, debouncedBuffer [nerds.weddingpartyapp.com]

RxJava Components: #

Subjects: when is it appropriate to use [.net but still applies] [[davesexton.com]19]
Implementing an event bus using RxJava [nerds.weddingpartyapp.com]
RxJava plugins [github.com]
- RxJavaDebug plugin – for hooking to start/end/error [github.com]
.toBlocking() [reactivx.io]
Composite Subscriptions [reactivex.io]

Retrolambda #

Retrolambda library [github.com]
Retrolambda gradle plugin [github.com]
Common Issue with Retrolambda (NoClassDefFoundError) [github.com]

Hot vs Cold observables – From the RxJs wiki [github.com] #

uses js instead of java, but concepts are the same and this is the best explanation I’ve found so far.

RxJava wiki on Backpressure [github.com]: #

Ring buffer size: `System.setProperty(“rx.ring-buffer.size”, “128”);`
Issue with changing buffer ring size [github.com]
It’s 16 on Android, down from 1024 originally. :P So it’s actually 64x smaller.

Awesome picks: #

Dan Lew:

Simple Made Easy (talk by Rich Hickey creator of Clojure) [infohq]
Victor by Trello (SVG assets) [github.com]

Donn:

Realm Object Database [realm.io]

Kaushik:

Therapeutic Refactoring (talk by Katrina Owen) [youtube.com]

Contact #

Dan Lew #

@danlew42 [twitter.com]
Dan Lew’s blog [danlew.net]

Donn Felker #

@donnfelker [twitter.com]
donnfelker.com

Kaushik Gopal #

@kaushikgopal [twitter.com]
kaush.co

003: The RxJava show with Dan Lew (Part 1)

Wed, 18 Mar 2015 20:27:32 UTC

Download directly

In this episode of Fragmented, Donn and Kaushik interview Dan Lew – druid of RxJava & RxAndroid! In part 1 of this 2 part series, we find out more about the one they call Dan Lew. We ask Dan how he started off as a developer, how he stays on top of development, where he draws inspiration from for amazing Android development and much more. We then begin disarming the glorious beast that is RxJava touching upon it’s benefits and begin discussion of some common operators.

Downloads

Dan’s open source contributions: #

Joda-Time Android [github]
- Why developers hate Timezones [youtube]
Gfycat [github]
Victor by Trello [github]

Staying on top of Android Development: #

Android Weekly
Android Dev Digest
Google RSS reader app – gReader
androiddev [reddit]
Best Book on learning Java [Effective Java: Joshua Bloch]

Dan’s favorite apps: #

Android Games that Dan plays #

Working Remotely: #

Getting started with RxJava: #

Dan Lews RxJava Series
Learning RxJava with Android by example [nerds.weddingpartyapp.com]
Android-RxJava [github.com/kaushikgopal]
Intro to Rx you’ve been missing [gist]

Rx #

002: Android Studio

Tue, 03 Mar 2015 19:49:00 UTC

Download directly

In this episode of Fragmented, Donn and Kaushik talk about the official IDE for Android development – “Android Studio”. Why should you care about your IDE? Is Android Studio really open source? What are some of the advantages of using Android Studio? How can you customize and tweak Android Studio so you take your android development game to the next level? Listen to this episode and find out. The awesome picks for this episode are particularly awesome too.

Show Notes/Links #

Android Studio (official IDE): #

Google announces Android Studio [Google I/O 2013]
Developer frontpage – Android Studio is the official editor [developer.android.com]

“Open source-ness” of Android Studio: #

IntelliJ open source platform for building IDEs [jetbrains.org]
Eclipse plugin ADT [developer.android.com]
Build Android Studio from command line [tools.android.com]
Jake Wharton’s u2020 Demo App

Environment customizations: #

Kaushik’s Android studio environment (codestyle, livetemplates, keymap etc) [github.com]
Chris Kempson – original theme [chriskempson.com]

Annotation Magic: #

A look at Android support animations [anupcowkur.com]
Support Annotations [tools.android.com]
Contract Annotations [blog.jetbrains.com]
Tools prefix: Tools of the trade by Sebastiano Poggi

Learning Android Studio resources: #

Donn Felker Android Studio Tips:
- Screencasts on Android Studio
- Android Tools Book – Android Studio Chapter (FREE)
Philippe Breault [developerphil.com]:

The most important things on the internet: #

Awesome picks: #

Stetho
Dan Lew’s RxJava Series
Rounded ImageView:
- Rounded Bitmap drawable usage[gist]
- Evelio blog post on different approaches to creating rounded image views
- Chris Banes For questions, comments or suggestions you can reach us at

@donnfelker and @kaushikgopal

001: Welcome & Testing in Android

Tue, 17 Feb 2015 03:30:24 UTC

Download directly

Welcome to the very first episode of Fragmented. Donn and Kaushik talk about why they started the podcast, the structure of the podcast and a little about who they are. The main topic for this episode is Testing! What are the benefits of testing, in general? Why does testing specifically help Android developers? What is the state of testing in Android and how does one test in Android?

Fragmented | AI Developer Podcast - Episodes

310 - Mitchell Hashimoto on Ghostty & His Agentic Coding Workflow

Show Notes #

Ghostty #

The AI Adoption Journey #

Get in touch #

Co-hosts: #

309 - Background Agents

Show Notes #

Remote Background Agents in the cloud #

Building trust #

Get in touch #

Co-hosts: #

308 - How Image Diffusion Models Work - the 20 minute explainer

Show Notes #

Get in touch #

Co-hosts: #

307 - Harness Engineering - the hard part of AI coding

Show Notes #

Why it matters #

Shaping the harness #

Building the harness #

Other resources #

Get in touch #

Co-hosts: #

306 - Keeping your agent instructions in sync and effective

Show Notes #

The sync problem #

Other links #

Get in touch #

Co-hosts: #

305 - Subagents explained: What they are, when (not) to spawn them

Show Notes #

Resources & Documentation #

Official Documentation #

Research Papers & Articles #

Get in touch #

Co-hosts: #

304 - Agent Skills - when to use them and why they matter

Show Notes #

Main References #

Creating Skills #

Using other Skills #

Warnings before installing random skills #

Additional resources #

Get in touch #

Co-hosts: #

303 - How LLMs Work - the 20 minute explainer

Show Notes #

Words -> Tokens: #

Tokens -> Embeddings: #

Embeddings -> Inference: #

Get in touch #

Co-hosts: #

302 - MCPs Explained - what they are and when to use them

Show Notes #

Tips #

Get in touch #

Co-hosts: #

301 - The AI coding ladder

Show Notes #

Gen 1: Super autocomplete #

Gen 2: Chat Oriented Programming #

Gen 3: Agent #

Gen 4: Agent Orchestration #

Tips #

Contact us #

Co-hosts: #

300 - From Vibe coding to Software engineering

Contact us #

Co-hosts: #

257 - Future of AndroidDev in an AI world with Vinay Gaba

Show Notes #

Contact us #

Kaushik: #

256 - Rapid prototyping with Kotlin

Show Notes #

Contact us #

Kaushik: #

255 - Data Oriented Programming