Android then and now

Android Then and Now: Callbacks

Welcome to the second instalment in this series of byte-sized blog posts, where we look at Android Then and Now. We’ll go through bits and pieces of Android development that have changed, and look at why and how they are what they are today in less than five minutes of reading. We’ll cover things like layouts, dependency management, background work, camera usage, navigation and much more!

Today we’re changing tack, and looking at a style of programming which is slowly becoming less prevalent in Android development: Callbacks.

Callbacks are cool

Callbacks are all over the place in Android Development. That’s simply because they do a job, and they do it well! By definition:

A callback is a function passed into another function as an argument, which is then invoked inside the outer function to complete some kind of routine or action.

Wikipedia states a couple of key benefits for callbacks: They can be called multiple times, and they can capture information the outer function doesn’t need to worry about. Handling view clicks in Android is a great example of this.

Here, we pass an OnClickListener to the setOnClickListener function. Kotlin flattens this into a lambda which takes the view clicked as a parameter. Both of these benefits of callbacks become immediately obvious:

• You could click a button more than once, so we need to be able to call back more than one.
• All the implementation of setOnClickListener needs to know is that we need a reference to the view clicked. We keep details of what to do when the button is clicked to ourselves.

All in all, callbacks are cool. They’re an elegant solution to a communication problem which is actually quite tricky, and our programming language of choice makes them simple to implement with lambdas.

Sometimes, callbacks could be cooler

Callbacks are a very general, and very useful programming style. They can be used to solve any number of problems — however in some cases, thanks to improvements to technology, callback might not be the best approach. One such case are callbacks which are called no more than once. How about an example!

Let’s think about a common problem, asynchronous REST API calls. We want to hit some network endpoint, download some information, then continue our program. We don’t want to do work on the main thread, as we’d block the app from running, making it unresponsive to user input. To address this, we move the work of doing a network call to a different thread. We can then talk back to the main thread by posting messages, telling us to resume what we were doing now that the other thread has finished its work.

In practice, writing the code to post these messages back to the main thread is at the very least error prone, and becomes a pain to maintain. Instead we could delegate the threading work to a library, and wait for a result to be delivered to a callback function! This is one of the ways in which we can use the ever-popular Retrofit library:

This greatly simplifies how we make network calls, allowing us to avoid the cursed AsyncTask . However, with Kotlin introducing coroutines, we can now do one better.

Suspend funs beat one-shot callbacks

If you think about it, Kotlin coroutines solves the exact same problem Retrofit was solving with enqueue . We’re calling a function, waiting for a result which might have come from a different thread, and continuing. There are a couple of key differences, which describes why I think suspend funs are the obvious winner:

• It limits misdirection, the program reads like any other sequential code.
• It simplifies the problem of thread isolation even further, while also being more obvious, as suspend funs have to be called from a suspendible context.

Let’s look at the same example, but now with coroutines:

What was two callbacks is now either a result, or an exception. We’ve gone from implementing our own functions to drive control from callbacks to code, to a simple try-catch. Not only is this easier to write, it’s far easier to read too! On top of this there’s the added benefit of built in lifecycle management using coroutine scopes and contexts, which makes cancelling things at the right time almost automatic.

Converting callbacks to suspend funs is easy, and Roman Elizarov does a great job at explaining how. He even goes further, to show how you can replace multi-shot callbacks with other coroutines primitives!

I hope you enjoyed the second instalment of Android Then and Now! Next week: Navigation. If you want to see more, follow me on Medium. Alternatively, I’ll be cross posting to my own personal blog and announcing each instalment on Twitter

Источник

Android Then and Now: Intro, @IntDef & Enums

Earlier this week I mentioned to a colleague that for the longest time enum s were discouraged in Android Development. To developers new to Android this fact is apparently pretty mind-boggling — just look at the code we write today with Kotlin! Android development has changed a lot over the years, and looking back at things like enums shows just how far Modern Android Development has come.

Join me in this series of byte-sized blog posts where we look at Android Then and Now. We’ll go through bits and pieces of Android development that have changed, and look at why and how they are what they are today in less than five minutes of reading. We’ll cover things like layouts, dependency management, background work, camera usage, navigation and much more!

Let’s start the series off with a bang by looking at enum s, and why they were so highly discouraged back in the day.

Back then, memory was tight

The title of this section really sums up why enums were frowned upon. We’re skipping quite a few beats here though — let me explain.

In the early days, mobile devices were constrained hardware-wise. Most people kept hold of a phone for a year or two, meaning in 2015 one of the most popular devices in New Zealand was the Samsung Galaxy S3. This device was really one of the big drivers of Android in the early days, delivering incredible performance on Android 4.X with… 1GB of RAM. As it turns out, 1GB of RAM doesn’t leave much free when considering the overhead of running an OS, as well as multiple apps.

Memory was a sought after resource. We all wanted to be good mobile citizens, and to be the app that people kill last. One focus therefore had to be on app size and memory consumption.

Enums are classes, and classes consume memory

The main issue with enums is that they’re classes under the hood, and classes have overhead. If you’ve got 5 minutes to spare and want to know exactly how bad this can be, I’d recommend looking back at The Price of Enums from back in 2015. TL;DW: enums consume about 13x more dex (Dalvik Executable) memory space than standard integer constants, with additional runtime allocation overhead from an array maintained under the hood to keep track of values.

For example, this definition sets you back just over 1.6KB in dex space:

When instead making use of static integer constants, we’re down to just 125B:

As you can imagine, apps which make extensive use of enums could quite easily blow up in memory usage. This puts pressure on the system, causing the system to kill apps and tanking device performance.

Introducing @IntDef, turning enums into ints

So we’ve seen enums are bad, and ints are good. The Android team ran with this, and implemented tooling to help developers make use of int s over enum . This took the form of the @IntDef annotation and accompanying lint rules. Using these we’ll extend our integer example from above like so, giving us (mostly) the same build time constant-group benefits without the memory overhead!

Oh and in some circumstances R8 does this for you! If you’re not accessing the enum values array and you haven’t implemented any methods on the enum, it can be flattened into a set of int constants.

Android Now: Just use enums already

There have been quite a number of improvements to Android ecosystem over the past 5 years. ART (the Android Run Time) has improved, allowing dex space usage to shrink considerably. The average amount of RAM available on devices has shot up considerably as device manufacturers move to cater for more performance-hungry apps. Some devices are now firmly in laptop territory, with recent devices packing up to 16GB of RAM.

The official guidance stating not to use enums no longer exists. Use enums whenever you want! They’re a much nicer abstraction than @IntDef allows and devices now have silly amounts of memory, so they don’t mind. If you want to know more about how ART has helped things further, Chet Haase has a great segment in this talk from Google I/O 2018 talking about runtime improvements.

All in all, memory usage is something most apps no longer have to pay too much attention to. Apps which allocate bitmaps still do, and as do apps which might load ML models into memory, but the majority of apps get off fairly lightly. The official guidance nowadays is at a much higher level: Use abstractions as you see fit. However, they can be expensive, so avoid them if you’re not seeing significant benefit.

I hope you enjoyed the first instalment of Android Then and Now! I’ve got a backlog of topics, and I’ll be sticking to a cadence of roughly once a week.

Next week, we’ll be taking a look at callbacks. If you want to see more, follow me on Medium. Alternatively, I’ll be cross posting to my own personal blog and announcing each post on Twitter.

Источник

Pagination in Android with Paging 3, Retrofit and kotlin Flow

Haven’t you asked how does Facebook, Instagram, Twitter, Forbes, etc… let you “scroll infinitely” without reach a “end” of information in their apps? Wouldn’t you like to implement something like that?

This “endless scrolling” feature is commonly called “Pagination” and it’s nothing new. In a brief resume, pagination help you to load chunks of data associated with a “page” index.

Let’s assume you have 200 items to display in your RecyclerView. What you would do normally is just execute your request, get the response items and submit your list to your adapter. We already know that RecyclerView by it’s own is optimized for “recycle our views”. But do we really need to get those 200 items immediately? What if our user never reach the top 100, or top 50? The rest of the non displayed items are still keep on memory.

What pagination does (in conjunction with our API) is that it let us establish a page number, and how many items per page can we load. In that way, we can request for the next page of items only when we reach the bottom of our RecyclerView.

Non library approach

Before paging 3, you could have implemented Pagination by adding some listeners to your RecyclerView and those listeners would be triggered when you reach the bottom of your list. There are some good samples about it, here is a video with a vey detailed explanation (it’s on Indi, but it is understandable anyways).

A real PRODUCTION ready example is on the Plaid app. Look at their InfinteScrollListener class.

Android Jetpack Paging 3 and Flow

Today you gonna learn how to implement Pagination by using paging 3 from the android jetpack libraries. For my surprise the codelab of Paging 3 was one of the most easiest I have ever done. Florina Muntenescu did a great job with each step of the codelab, go check it out and give it a try. If you want to go straight to the sample code, check this pull request and see step by step how I implement paging 3 to this project.

Источник

Now in Android #13

Android 11 developer preview, Android Studio 3.6 stable and 4.0 beta, background location guide, easier testing for dynamic feature modules, material motion guide and library, articles, videos, and AndroidX releases

Welcome to Now in Android, your ongoing guide to what’s new and notable in the world of Android development.

Hotels and 13th floors. But maybe you like to avoid the number 13 in your life (the 13th floor, the last donut in a baker’s dozen, counting by ones after you reach 12 and before you reach 14). If so, just imagine that this is called #14 instead. And then next time, when I post #14, tell yourself that since it’s about software, it must be an off-by-one error.

In the meantime, there were many things that hit in the last couple of weeks, so let’s get going.

NiA13 in Video and Podcast Form

This Now in Android is also offered in video and podcast form. It’s the same content, but with less reading required. The article version (keep reading!) is still the place to come for links to all of the content that’s covered.

Video

Podcast

Click on the link below, or just subscribe to the podcast in your favorite client app.

Now in Android: 13 — Android 11 preview, Android Studio 3.6 stable & 4.0 beta, material motion…

Welcome to Now in Android, your ongoing guide to what’s new and notable in the world of Android development. In this…

Android 11: Developer Preview 1

The big Android developer news for the past couple of weeks is that the first developer preview for Android 11 is now available. You can not only install the system image and play with it on one of your developer devices (Pixel 2, 3, or 4), you can (and should!) also test out your app to see how it looks on the new release (using one of those test devices or the emulator). While you’re there, check out some of the new features and APIs that you might want to use.

Here’s a small sample of the features you’ll see in this first preview:

• Support for 5G, with new APIs to check unmetered status and bandwidth capabilities
• Bubbles, a system-wide UI for seeing ongoing conversations. Bubbles were introduced in Android 10, but hidden behind Developer Options; now they are enabled in the platform and the API is available for use.
• One-time permission: The tri-state location permission introduced in Android 10 (allowing access to location while apps were in the foreground only) was popular with users, so we are expanding that concept to make the permission available only while the app is in the foreground during this session. Also, we’re adding the microphone and camera to the list of permissions with this additional layer of user control.
• Scoped-storage protections which began in Android 10 are being expanded. Some new capabilities to make access to scoped storage easier include batched edits and access to raw files and paths.
• BiometricPrompt APIs which handle a wider variety of device capabilities have been introduced in Android 11, and are also available in the biometric AndroidX library for compatibility.
• Data blobs (which stands for “binary large object”, but I prefer the term “blob”) may now be shared between apps through the BlobStoreManager API. This could be useful for a large download, like an ML model, which an app wants to make available to other, related apps that also need that data.

For more info on Android 11, check out the article on the Android Developers Blog, and head over to the preview site to read about the specific changes and to download the system image.

Android Studio

Our IDE had a couple of important releases recently.

3.6: Stable

The 3.6 release of Android Studio recently went stable. I’ve talked about 3.6 in a previous edition of Now in Android, and maybe you’re already using it. But in case you were waiting for it to be complete before updating, that time is now.

Hop on over to the Studio download page to get your very own copy. Here are some of the things you’ll find in this version:

• Improved and easier leak detection
• Split-view for code and design resource file editing
• View binding (see Sean’s article about this, referenced below)
• Emulator improvements for working with location and multi-display situations.

4.0: Beta

I’ve also talked about 4.0 recently. But if you were waiting for it to get out of that alpha stage, now’s your chance. Some of the fun features you’ll find in 4.0 Beta include:

• MotionEditor, the visual editing tool for the new MotionLayout API that enables richer animations
• Live LayoutInspector

For more about the 4.0 design tool changes in particular, check out Nicolas Roard’s Twitter thread:

4.1: Canary

Just to round out the offerings, you can also live on the wild side and download the newest version of Android Studio, 4.1, which is now available in the canary channel.

The main reason I’m calling it out here is that the Jetpack Compose compiler has been removed from the 4.0 release. So if you want to play with the pre-alpha Compose UI toolkit APIs, you’ll need to use version 4.1.

Background Location Guide

Q: What are the three most important things about user privacy?
A: Location, location, location.

One of the larger areas of privacy changes in recent releases has been around location. It’s critical that applications accessing user location have permission to do so, and that that access is transparent to and controllable by the user. But this behavior can require effort from application developers to get it right.

To help, we’ve created a new guide to help you understand how you might be accessing location while in the background, and to give you tips on how to update your app to provide alternatives to such access.

Dynamic Feature Module Testing

Local development and testing with FakeSplitInstallManager

New releases of Bundletool and the Play Core library made local iteration faster and testing possible with on-demand…

Dynamic feature modules are a powerful way of improving download and install experiences for users, by moving elements of your app that aren’t required on first launch into optional modules that can be installed later.

But testing dynamic feature modules proved difficult, since it required installing the bundle on the Play Store.

Wojtek Kaliciński has been working to make this easier, through enhancements in the Play Core library, along with documentation and samples. Now, you can use version 1.6.5 of the library and test the functionality locally.

Material Motion

Animation is a powerful way to make application UIs easier to understand and to interact with. But… animation can be difficult to implement, especially for rich motion involving transitions between elements and activities.

The Material Design team recently posted a comprehensive guide for handling UI Transitions in your application. Even better: version 1.2.0-alpha05 of the Material Design Components library provides transitions implementing this guidance that are ready for use in your app.

Check out the excellent documentation and the article for more on how to integrate these new transitions into your app.

Articles

Nick Butcher added two new articles to his ongoing Android Styling series, both around theme attributes:

Источник