DEV Community: Victor Brandalise

From Nothing to Material Transitions

Victor Brandalise — Thu, 24 Jun 2021 00:20:06 +0000

Animations rarely change the core functionally of an app but you can’t deny that they make a big difference for the user. When an app has great animations everything looks more fluid, it’s easier to understand how things fit together.

Transitions are used when you’re moving from one screen to another and you want to apply animations to one or multiple elements. In this article I’ll show you how to implement them in your app.

We’ll start with an app that has no animations and add the needed ones to improve it.

Without transitions / With transitions

Preparation

Before we start, make sure you’re not using the wrong library version.

If you’re using androidx.appcompat:appcompat:1.3.0 you’ll have to manually specify androidx.fragment:fragment-ktx:1.3.5 because appcompat:1.3.0 depends on fragment:1.3.4 that introduced a bug related to fragment transitions.

See the “Bug Fixes” section

I was getting an IndexOutOfBoundsException exception when messing around with shared transitions and I took me a while to discover that the fragment library was the problem.

 java.lang.IndexOutOfBoundsException: Index: 5, Size: 5
        at java.util.ArrayList.get(ArrayList.java:437)
        at androidx.fragment.app.FragmentTransitionImpl.setNameOverridesReordered(FragmentTransitionImpl.java:183)
        at androidx.fragment.app.DefaultSpecialEffectsController.startTransitions(DefaultSpecialEffectsController.java:665)

Now let’s get started

Basic Knowledge

If no return transition is set, the transition system will automatically reverse the enter transition when navigating back.

By default, transitions run on all child views within their scene root hierarchy. For example, if you have a RecyclerView, the animation will be applied to it and to its children. If that’s not the behavior you expect, set android:transitionGroup="true" on the view group to disable that. You can also apply it to the out most view in your layout to make the fragment animate as a whole.

If you have views that are populated after the fragment is created (a RecyclerView for example) you need to tell the transition system to wait before starting the transitions. To do that you need to call postponeEnterTransition to postpone the transitions and call startPostponedEnterTransition when you’ve populated your views.

Fade Through

We’ll start with one of the simplest transitions, MaterialFadeThrough. The fade through pattern is used for transitions between UI elements that do not have a strong relationship to each other.

FadeThrough

The transition here consists of going from the items fragment to the cart fragment. On the first fragment we define exitTransition and reenterTransition to MaterialFadeThrough.

On the destination fragment we define the same transition but on enterTransition and returnTransition.

If you’re using a RecyclerView you might need to postpone the enter transition on the destination fragment. To learn how to do that, take a look at the Basic Knowledge section.

This transition is a good option for navigating between fragments when you have a bottom navigation bar. The fade is subtle but adds a nice touch to the navigation.

In a fade through transition, outgoing elements first fade out. Next, incoming elements fade in while scaling in overall size from 92% to 100%. The element scaling starts at 92%, rather than 0%, to avoid drawing excessive attention to the transition. The scale animation is applied only to incoming elements in order to emphasize new content over the old.

The motion system

Fade

The fade transition is usually used with dialogs, menus, or things that fit within the bounds of the existing screen.

MaterialFade

Implementing the MaterialFade transition is basically the same as implementing the MaterialFadeThrough transition, the only difference is the transition name.

When entering, elements use a fade and scale in overall size from 80% to 100%. The scale animation starts at 80%, rather than 0%, to avoid drawing excessive attention to the transition. When exiting, elements simply fade out. The scale animation is only applied to entering elements. This places emphasis on new content (entering elements) over old content (exiting elements).

The motion system

What’s the difference between Fade and Fade Through?

They look very similar but by looking at the specification we can see one main difference.

Fade – Scales from 80% to 100%

FadeThrough – Scales from 92% to 100%

Shared Axis

The MaterialSharedAxis transition is well suited for cases when you want to represent some kind of spatial relationship. Opening a search page would be good example, when the user searches something, the content below is expected to change.

MaterialSharedAxis

For this transition to look good you need a pair of fragments to animate simultaneously. Their transitions will run together to create a directional animation.

You can control the transition direction by specifying the forward property on MaterialSharedAxis. In the forward direction, targets of the transition will scale out.

On this example we’re using the Z axis but you should give the X and Y axis a try to see what they look like.

For the transition to look great you need to specify the same forward value for exitTransition = enterTransition and reenterTransition = returnTransition.

Container Transformation

This is the transition I love the most, MaterialContainerTransform is used as a shared element transition, that means it’s used to transition the view’s size, position, etc from the start state to the end state.

The Container Transformation is used a lot when you have a RecyclerView that’s already displaying some portion of the content that’ll be available at another screen. By using this transition you can animate the change from one place to another.

MaterialContainerTransform

First we need to specify a transitionName on the view we wish to transition. Transition names have to be unique, that’s why I’m adding layoutPosition to the end of the transition name. If you’re using a RecyclerView, you should do this when binding your ViewHolder.

Now on the end layout file, add a transitionName to the view the animation will end on.

We want the transition to start when the item is clicked, on the item clicked handler we have to tell the transition system the views from the start state that will map to the end state. For example the icon that was clicked on the RecyclerView will transition to the view on the end layout that has R.string.item_detail_icon_transition_name as transitionName. The transitionName you specified on the ViewHolder is just used by android to keep track of things, you won’t use it anywhere else.

Finally we specify the MaterialContainerTransform on the destination fragment. drawingViewId is the view that’ll be used as a plane for the animation, if you’re using Navigation specify your NavController view.

If you want your animation to follow an arced path, you also need to specify the path motion.

There are many ways to customize your transitions, you can learn more about them here.

As I’ve said before, if you don’t specify a return transition, Android will automatically use the enter transition reversed.

Take a look at the last GIF again, the MaterialContainerTransform looks good but everything else uses a rough transition. Let’s learn how we can use many transitions together to achieve a better end result.

Debug mode

In some cases you might need some help to understand what’s happening behind the transition and there’s a simple thing that can help you with that. MaterialContainerTransform has a isDrawDebugEnabled property that adds visual information to the transition.

MaterialContainerTransform

Mixing transitions

We’ve learn learned about the 4 transitions provided by Material individually, now let me show you how I used 3 of them together to create an animation that is pleasing to the eyes.

First I started by using the MaterialSharedAxis transition on the list fragment, it works well because the views reduce size from 100% to 92%, that helps to focus on the icon animation.

Then I added the MaterialFadeThrough transition to the destination fragment but I excluded the icon from that animation because it’s already being animated by MaterialContainerTransform.

By doing just that the end result is much better

Mixing transitions

If you have any doubts you can find the source code here or contact me.

The best way to learn is by doing, go and apply the knowledge you’ve acquired here to a concrete example. I’d enjoy seeing what you can accomplish. I hope this article was helpful for you.

Resources

Photo by Julian Hochgesang on Unsplash

The post From Nothing to Material Transitions first appeared on Victor Brandalise.

How to Show an Activity on Lock Screen instead of a Notification

Victor Brandalise — Thu, 10 Jun 2021 23:10:25 +0000

Today we’re gonna learn how to show a full screen activity instead of a notification when the device is locked.

By default Android will show the same notification it shows when the device is unlocked but in some cases, such as a phone call, you might want to display a full screen activity.

You can find the source code here.

Creating The Notification

Let’s start by creating a simple notification that’ll be used later to show an Activity on the look screen.

The first thing we need to do before creating the notification is creating the channel to display it.

First we retrieve the NotificationManager from NotificationManagerCompat. That’s the interface used for dealing with notifications on Android. Then we create a NotificationChannel that takes the channel’s id, name and importance as arguments. It’s advised to use NotificationManager.IMPORTANCE_HIGH for increasing the chances of the notification appearing as a heads up notification. We also change the lockscreenVisibility to Notification.VISIBILITY_PUBLIC to tell Android that the notification can be shown on the lock screen. Finally we call notificationManager.createNotificationChannel to register the channel.

Up until Android Nought (25), there’s no need to create notification channels, that’s why there’s a guard cause at the beginning of the method.

When Should I Create the Channel?

There’s no problem in calling createNotificationChannel multiple times with the same channel, Android will ignore it if there’s an existing channel with the same id.

You should register your channels as early as possible, preferably when Application.onCreate is called.

Channels are immutable , if you need to change some channel configuration you’ll either have to delete the app or change the channel’s id.

Creating a Simple Notification

Now that we have created a channel, we can proceed to creating the notification.

First we start by creating a PendingIntent, that’s the intent that will be called when the notification is clicked, here we’ll simply start an activity. Then we call NotificationCompat.Builder to define how the notification will look like. The CHANNEL_ID parameter has to have the same id we used earlier to create the channel. If you want to learn how to customize you notification you can take a look at the Android Documentation.

The next step is simply calling notificationManager to show the notification. The notification id can be any number, it’s used only if you need to interact with the notification later.

That’s what you should see when your notification is displayed.

Heads Up Notification

Creating the Lock Screen Activity

Now we’ll create the Activity that’ll be displayed on the lock screen. That activity is very similar to a normal activity but there are 2 things you need to change for it to appear on the lock screen.

The first thing is calling showWhenLockedAndTurnScreenOn after onCreate to define that the activity can appear on the lock screen and that the screen should be turned on when it appears. I added the method to the activity but you can easily add that as an extension to Activity in case you use it in other places.

The second thing is changing the manifest definition by adding launchMode and showOnLockScreen.

That’s it, you’ve created a activity that can appear on the lock screen. The last thing we need to do is to tell Android that we want that activity to appear on the lock screen instead of the notification.

Adding the Activity to Notification

We’ll have to modify the createNotification method we defined earlier. We need to create another PendingIntent that’ll start the activity that’ll be shown on the lock screen. We then pass that intent to setFullScreenIntent. It’s also important to add a category such as ALARM or CALL for increasing the chances of it appearing on the lock screen.

Here’s the end result

Full Screen Activity on Lock Screen

It’s not Working !!!

For some of you the activity might not appear on the lock screen and that’s because of your phone, not all phones allow full screen intents by default. I have a Xiaomi and it’s not enabled by default.

To enable it you have to go to the app configuration -> Other permissions -> Show On Lock screen.

Enable App to Appear on Lock Screen

The notification will also not appear if you have an existing notification with the same id that has not been dismissed. Ideally you should cancel the notification by calling notificationManager.cancel(id) when the lock screen activity is destroyed.

Conclusion

Android notifications are a great way to notify your users they need to do something but they might not be work well when the phone is locked. Full screen activities come to solve that problem, allowing you to show the activity even if the phone is locked.

The source code can be found here.

Resources

How to manage incoming video call for every Android OS version with FCM notifications

Show an urgent message

Photo by Rami Al-zayat on Unsplash

The post How to Show an Activity on Lock Screen instead of a Notification first appeared on Victor Brandalise.

In-depth look at gRPC for Android

Victor Brandalise — Tue, 01 Jun 2021 01:05:00 +0000

This article walks you through the most important concepts you need to know to understand gRPC. The concepts range from understanding how an HTTP/2 connection works to learning how to model Protocol Buffers correctly.

By the end of this article you’ll have learned most of what you need to know to use gRPC effectively in Android.

I’ll be using the following libraries:

build.gradle

com.google.protobuf:protobuf-gradle-plugin:0.8.14

_ app/build.grdle _

api 'io.grpc:grpc-kotlin-stub:1.1.0'
api 'io.grpc:grpc-protobuf-lite:1.38.0'
implementation 'io.grpc:grpc-android:1.38.0'
implementation 'io.grpc:grpc-okhttp:1.38.0'

You can find the source code here.

Everything I say here refers to how the Kotlin library implements the gPRC protocol and it might be different from how other libraries implement it. The content of this article was curated from the resources listed at the end of the page.

HTTP/2

HTTP/2 was introduced to fix many problems HTTP/1 has. The main ones are:

HTTP/1.x clients need to use multiple connections to achieve concurrency and reduce latency;
HTTP/1.x does not compress request and response headers, causing unnecessary network traffic;
HTTP/1.x does not allow effective resource prioritization, resulting in poor use of the underlying TCP connection;

In contrast:

HTTP/2 reduces latency by enabling full request and response multiplexing,
HTTP/2 minimizes protocol overhead via efficient compression of HTTP header fields,
HTTP/2 adds support for request prioritization and server push.

Binary framing layer

HTTP/1 transits its information encoded in US-ASCII. HTTP/2 on the other hand encodes its information in binary. This single change has a big impact on the message size. The HTTP semantics, such as verbs, methods, and headers, are unaffected, but the way they are encoded while in transit is different, this is achieved by adding the binary framing layer.

Both client and server must use the new binary encoding mechanism to understand each other: an HTTP/1.x client won’t understand an HTTP/2 only server, and vice versa.

HTTP/2 also splits its messages into smaller parts called frames, each of which is encoded in binary format.

Streams, messages, and frames

_ Stream _: A bidirectional flow of bytes within an established connection, which may carry one or more messages. Each stream ** has a unique identifier. A single HTTP/2 connection has one or more **streams.

Message : A complete sequence of frames that map to a logical request or response message.

_ Frame _: The smallest unit of communication in HTTP/2, each containing a frame header, which at a minimum identifies the stream to which the frame belongs. The most common headers are HEADERS and DATA.

That’s just a simple explanation of what HTTP/2 is like but it’s enough for understanding the next concept. Now we’re gonna take a look at how gRPC’s channels leverage HTTP/2.

Channel

A channel is basically an interface for sending messages to one or more servers. Channels represent virtual connections to an endpoint, which in reality may be backed by many HTTP/2 connections.

Channels do much more than just sending messages, they do name resolution, establish a TCP connection (with retries and backoff) and TLS handshakes. Channels can also handle errors on connections and reconnect. We’ll see how that happens at the Retry section.

To create a channel you just need the server’s host and port. The context is optional but it helps to manage the channel state.

To create a simple abstraction for users, the gRPC API exposes information about the channel by defining 5 possible states:

CONNECTING

The channel is trying to establish a connection, the steps involved are:

Name resolution – retrieving the IP address from the hostname;
TCP connection establishment – establishing a connection using the three-way handshake process;
TLS handshake if you’re using a secure connection – establishing a secure connection by negotiating what version of SSL/TLS will be used in the session, which cipher suite will encrypt communication, etc.

If any of these steps fail, the channel transitions to TRANSIENT_FAILURE state.

TRANSIENT_FAILURE

Something didn’t go as expected. There has been some failure (such as a TCP 3-way handshake timing out or a socket error).

Channels in this state will eventually switch to the CONNECTING state and try to establish a connection again. You can define a custom retry policy to determine how the retry works.

The amount of time the channel spends on this state increases overtime because retries have exponential backoff.

READY

If the channel has successfully established a connection it transitions from CONNECTING to READY state.

This is the state the channel has to be for it to be used to make RPC calls. In an ideal world this would be the state channels would always stay, but the world is not perfect. If some failure happens the channel will transition to TRANSIENT_FAILURE state.

Even if everything is okay the channel might change its state to IDLE , let’s see why.

IDLE

This is the initial state for channels as defined by ConnectivityStateManager.

It’s a waste of resources for the client and for the server to keep a connection open if no data is being transmitted.

The channel transitions to this state because there has been no activity in the channel for a specified IDLE_TIMEOUT. The default value for IDLE_TIMEOUT is 30 minutes. The minimum value is 1 minute.

The activity can either be a new RPC call or an existing call that has not finished yet. Only channels that are READY or CONNECTING can switch to IDLE.

Any attempt to make a RPC on the channel will push the channel out of this state to CONNECTING.

Channels may receive a GOAWAY from the server to indicate the channel should transition to IDLE to reduce resource waste.

SHUTDOWN

Channels may enter this state either because the application explicitly requested a shutdown or if a non-recoverable error has happened during attempts to connect communicate. Channels that enter this state never leave it.

Any new RPCs should fail immediately. Pending RPCs may continue running till the application cancels them.

Channel’s States

You can call Channel#getState() to retrieve the channel state.

That’s a good overview of Channels, you know how to create a simple channel and how it behaves in its lifecycle. Now we’re going to see how to configure the channel to change its behavior.

Retry

Unexpected things happen. The connection might be lost, the server may close the connection abruptly, etc. Channels attempt to hide these situations from the user by recovering automatically. I say attempt because some situations are not recoverable and there’s nothing the channel can do about that.

A temporary connectivity loss can be recovered from but if you permanently lose the connection or if the server shuts down, there’s no way to recover.

When retrying, the channel switches from the CONNECTING state to the TRANSIENT_FAILURE state back and forth until the connection is recovered or the retry expires. By default retries are done with exponential backoff.

Some libraries allow you to define a custom retry policy. The Kotlin library allows you to define the max numbers of retries the channel is allowed to do.

By default the channel retries 5 times. If you want to change that you can call AndroidChannelBuilder#maxRetryAttempts(attempts)

If you want to customize other parameters you’ll need to create a custom service configuration. The specification can be found at service_config.proto.

The proto has to be converted to a map style on the Kotlin library. You can learn how to do that here.

Keep Alive

You’ve established a connection to the server. You’ve sent some messages and everything is working fine. Suddenly you try to send another message and it fails, there’re was a problem communicating to the server. If you have retry enabled, the channel will do its job to try to reconnect again but that’s not the best way to handle that.

What if there was an way to discover a problem will happen the next time you send a message? Well that’s not 100% possible but there’s something very close to that in gRPC.

Keep Alive is the feature that allows you to achieve that. Keep Alive sends periodic pings to check if a channel is currently working, that’s done using HTTP/2 PINGs. If the ping is not acknowledged by the peer within a certain timeout period, the channel knows there’s a problem.

Keep Alive is not enabled by default, you can enable it by specifying the keep alive interval on the channel builder.

The above code causes the channel to send a ping to the server every 20 seconds and wait another 5 seconds for a response. If the server doesn’t acknowledge the ping, the channel considers the connection failed, closes the connection, and begins reconnecting.

You might need to call AndroidChannelBuilder#keepAliveWithoutCalls(true) if you’re not actively using the channel but would like it to keep pinging the server.

Subchannel

You’ll not likely work directly with Subchannels but it’s interesting to know why they exist. The Subchannel is used mainly for load balancing. For example, you want to send requests to google.com. The resolver resolves google.com to multiple backend addresses that serve google.com.

For example, let’s suppose there’re 3 servers that serve google.com. The parent Channel will create 3 Subchannels, 1 for each logical connection. You can use the parent channel only and it’ll handle all the load balancing logic.

Now that we’ve learned how channels work and that they’re used to transport messages, let’s see how we can send messages.

Protocol Buffers

By default, gRPC uses protocol buffers as the Interface Definition Language (IDL) for describing both the service and messages. It is possible to use other alternatives if desired.

Protocol Buffers are not like JSON where you have data and structure together. It’s closer to Kotlin Interfaces, where you define a protocol specifying methods and fields. The only thing you care about is the protocol, how the protocol will be implemented doesn’t matter to you.

In the example below, I created a protocol to define a book. It has an id to identify each book and its title.

message Book {
  int32 id = 1;
  string title = 2;
}

The protocol buffer defines an interface, for you to interact with the interface, you need an implemented version in your target language.

If you’re using the protobuf-gradle-plugin, when you build your project, the protobuf plugin will get called and generate the implementation for each proto in Java.

By default the plugin will look for files under app/src/main/proto. The generated files can be found at app/build/generated/source/proto/buildType.

There’s much more to Protocol Buffer than we can cover here, if you want to learn more I recommend Protocol Buffer Basics: Kotlin and Language Guide (proto3).

Service

Services are where you define the methods you want to call with their parameters and return types. You can define the API of your service using Protocol Buffers.

You should use CamelCase for both the service name and any RPC method names.

In the example below, I defined an interface that allows me to create books (CreateBook) and list books (ListBooks).

The great thing about the Kotlin library for gRPC is that the generated classes support _ coroutines. _

The above code creates a connection to a server at 127.0.0.1 on port 9000, the connection is then used by a channel that’s passed as argument to create the service. When createBook is called the service dispatches the message to the channel that sends it the to server.

We’ll not look into the server side because this article is focused on Android, but I recommend you looking into that.

Photo by Marc-Olivier Jodoin on Unsplash

RPC

We’ve seen what a service is, now let’s go back and understand it a little bit further. RPCs are in practice plain HTTP/2 streams.

To define a method in Kotlin we use the fun keyword. To define a method in gRPC we use the rpc keyword. The method signature is as follows:

rpc MethodName(Request) returns (Response) {}

There’re 2 kinds of methods in gPRC. Unary and Streaming.

Unary

The client sends a single request to the server and gets a single response back, just like a normal function call. This is what you’ll likely be using the most. It maps closely to a REST request/response.

Streaming

There’re 3 kinds of streaming

Server streaming RPCs where the client sends a request to the server and gets a stream to read a sequence of messages back.
Client streaming RPCs where the client writes a sequence of messages and sends them to the server. Once the client has finished writing the messages, it waits for the server to read them and return its response.
Bidirectional streaming RPCs where both sides send a sequence of messages using a read-write stream. The two streams operate independently, so clients and servers can read and write in whatever order they like.

gRPC guarantees message ordering within an individual RPC call. For example, if the server sends messages 1,2,3 and 4, gRPC guarantees the client will receive them in the same order but doesn’t guarantee the client will actually receive them, the client may actually only receive 1,2 and 3.

Streaming RPCs that return multiple messages from the server won’t retry after the first message has been received. Streaming RPCs that send multiple messages to the server won’t retry if the outgoing messages have exceeded the client’s maximum buffer size.

Unary x Streaming

For lower concurrent requests, both have comparable latencies. However, for higher loads, unary calls are much more performant.

There is no apparent reason we should prefer streams over unary, given using streams comes with problems like complex implementation at the application level and poor load balancing as the client will connect with one server and ignore any new servers and lower resilience to network interruptions.

Success for both parties?

In gRPC, both the client and server make their own independent and local determination about whether the remote procedure call (RPC) was successful. This means their conclusions may not match! An RPC that finished successfully on the server side can fail on the client side.

For example, the server can send the response, but the reply can arrive at the client after their deadline has expired. The client will already have terminated with the status error DEADLINE_EXCEEDED. This should be checked for and managed at the application level.

Best Practices For Protocol Buffers

Most languages have a set of best practices that are followed by developers to improve the code quality. The same happens for Protocol Buffers. Here’re some that I’ve found:

Do not use google.protobuf.Empty as a request or response type. If you use Empty, then adding fields to your request/response will be a breaking API change for all clients and servers.

For custom methods, they should have their own XxxResponse messages even if they are empty, because it is very likely their functionality will grow over time and need to return additional data.

Each enum value should end with a semicolon, not a comma. The zero value enum should be the name of the enum itself followed by the suffix UNSPECIFIED.

enum State {
    UNKNOWN = 0;
    STARTED = 1;
    RUNNING = 1;
  }

This is my first “big” article. It was really fun writing it, I learned a lot about gRPC. If you have any questions or suggestions, you can contact me on Twitter. I’m open to new ideas, if you want somebody to chat about programming, architecture, or different approaches in general, I’d be happy to chat with you. Thank you for reading this article.

Resources

Transient fault handling with gRPC retries | Microsoft Docs

gRPC and Deadlines | gRPC

Effective gRPC

Common Design Patterns | Cloud APIs | Google Cloud

Style Guide | Protocol Buffers | Google Developers

gRPC: Top 6 Things that Bite Newbies | by Charles Thayer | Medium

gRPC On HTTP/2: Engineering a robust, high performance protocol | Cloud Native Computing Foundation

HTTP/2: Smarter at scale | Cloud Native Computing Foundation

Introduction to HTTP/2 | Web Fundamentals | Google Developers

High Performance Browser Networking | O’Reilly

The SSL/TLS Handshake: an Overview

Protocol Buffer Basics: Kotlin

Cover Photo by Taylor Vick on Unsplash

The post In-depth look at gRPC for Android first appeared on Victor Brandalise.

Useful Kotlin Extensions for Android

Victor Brandalise — Thu, 13 May 2021 11:30:38 +0000

Kotlin has many amazing features but one that stands out is extensions. Extensions are used to add functionality to existing classes.

They are extremely useful at helping to reduce boiler plate code. The good thing is that you can add them to any class, including the ones from third-party libraries that you can’t modify.

Most of the time we see Extension functions but Kotlin also supports Extension properties.

Useful Extension Functions

Lets start with some extensions that make the code easier to read, the ones that improve the code quality over time by reducing boiler plate code.

Context

The Android API changes over time and something as simple as getting the color for a given ID can become not so simple. The extensions below helps reduce the boiler plate code associated with retrieving resources for a given ID.

Usage

We all know how repeating it’s to check whether the user has granted the permissions the app requires. The extension below can help with that. It doesn’t solve the whole problem but helps reduce the code size.

Usage

Copying some text or URL to the clipboard should be something very simple. It only works with plain text but that’s what we use most of the time, if you need to support other formats you can change it.

Is there an URL in your app that the user needs to open the browser to view? Are you handling the case where the browser or equivalent app might be missing? The next extension abstracts most of what’s needed. You just need to give it the Uri and do something such as showing an error if there’s no app to resolve the intent.

Usage

Date

This extension is very useful if you need to log a date object over and over or send it via an API call. Something to notice here is that the ISO format is universal, it doesn’t change from country to country, I’ll show why that’s important later.

Usage

Some other extensions that might be useful

Photo by Artur Tumasjan on Unsplash

All that glitters is not gold

Many things including extensions can be abused. Some of them look good, but are actually disguised code smells.

Let’s start with an useless extension. I was reading an article about extensions the other day and found this one.

There’s no code reduction by using the extension.
By using the extension the compiler will consider it a normal function call and refrain from optimizing the null case if possible.
That’s bad use of OOP, we add methods to objects to “ask” them about something, null by definition is the absence of an something. An object is never null, what’s is null is the reference to an object.

Be careful with localization

The extension below may look reasonable to most of us. It formats a Double to its decimal format.

The dangerous thing about this code is that money is not formatted equally worldwide. In some countries you’ll see 1,200.00 (comma first, dot after), in others 1.200,00 (dot first, comma after). This is only a problem if the app is/will be used in many countries.

My solution would be to add the formatting pattern to strings.xml and create an extension on Context to handle that. That way you can define the monetary format for each language and still use the same function.

Extension Properties

Kotlin also allows us to add properties as extensions. I’ve not found an use case for them yet but it’s useful to know that it’s possible to use them.

Thank you for reading. If there’s anything you disagree with, please leave a comment below so we can discuss it and arrive at a better solution.

Android Lifecycle Scenarios – Single and Multi Activities

Victor Brandalise — Thu, 29 Apr 2021 01:04:20 +0000

These are my personal notes on the topic. Most of the content here is not mine. All sources can be found at the end of the article.

Activities are a main part of Android. Lifecycle methods is the way Android notifies state changes to the Activity. To provide a great user experience, you should know how to manage them.

If you haven’t read my article about Activity Lifecycles, you can read it here.

Lets take a look at some common scenarios using a single Activity

1. App is finished or restarted

This scenario happens when there’s only one activity in the back stack and:

The user presses the Back button
The Activity.finish() method is called

onSaveInstanceState is not called.

onCreate doesn’t have a Bundle when the app is reopened.

If there’s only one activity in the back stack, the app will be finished. To avoid that you can override onBackPressed(), that way onDestroy() won’t get called.

@Override
public void onBackPressed() {
   moveTaskToBack(true);
}

2. Configuration changes

This scenario happens when there’s only one activity in the back stack and:

The configuration changes, like a rotation
User resizes the window in multi-window mode (available in android 7.0)

The activity is completely destroyed, but the state is saved and restored for the new instance.

The Bundle in onCreate() and onRestoreInstanceState() is the same.

Why is the Bundle sent to two methods?

onRestoreInstanceState() is called only when recreating activity after it was killed by Android. It is possible to restore the state in onRestoreInstanceState(), but not very common. onRestoreInstanceState() is called after onStart().

Usually you restore your state in onCreate(). onCreate() is called before onStart().

3. User navigates away

This scenario happens when there’s only one activity in the back stack and:

The user presses the Home button
The user switches to another app

For example, you’re browsing Twitter and you click on a notification that takes you to another app. When you switch back to Twitter the activity’s onRestart() will called.

onSaveInstanceState() is used to save the app state in case the system kills the app’s process later on.

This scenario is very similar to navigating from Activity A to Activity B, the only difference is that onSaveInstanceState() is not called when navigating between activities.

4. App is paused by the system

Enabling Multi-window mode (API 24+) and losing the focus
Another app partially covers the running app (a purchase dialog, a runtime permission dialog, a third-party login dialog…)
An intent chooser appears, such as a share dialog

Doesn’t apply to:

Dialogs in the same app. Showing an AlertDialog or a DialogFragment won’t pause the underlying activity.
Notifications. User receiving a new notification or pulling down the notification bar won’t pause the underlying activity.

Now lets take a look at some common scenarios using multiple Activities

1. Navigate from Activity A to Activity B

When activity A is created, onCreate() is called. Then onStart() is called. Once the user is able to interact with the app, onResume() is called. Now the user opens Activity B.

onPause() of activity A will get called. Then activity B’s onCreate() ** ** followed by onStart() and onResume(). Finally activity A’s onStop() is triggered.

Here is the callbacks order

Activity A -> onCreate() , onStart(), onResume(), , onPause()

Activity B -> onCreate(), onStart(), onResume()

Activity A -> onStop(), onSaveInstanceState()

2. Navigate from Activity B back to Activity A

When the back button is pressed, Activity B’s onPause() is triggered. Then activity A’s onRestart() is called followed by onStart() and onResume(). After that activity B’s onStop() gets called followed by onDestroy().

Here is the callbacks order

Activity B -> , onPause()

Activity A -> onRestart(), onStart(), onResume()

Activity B -> onStop(), onDestroy()

Thank you for reading.

Sources

Cover Photo by Laura Ockel on Unsplash

The post Android Lifecycle Scenarios – Single and Multi Activities first appeared on Victor Brandalise.

Android Lifecycle Revised

Victor Brandalise — Sat, 24 Apr 2021 01:34:54 +0000

The Activity class is an essential part of every Android app. Unlike traditional programming paradigms, the Android framework starts code in an Activity instance by invoking callback methods that correspond to specific stages of its lifecycle.

The activity state changes when the user rotates the phone, responds to a notification, or switches to another app. When these state changes happen, Android uses lifecycle callback methods to notify the activity about them.

A simplified illustration of the activity lifecycle

onCreate()

This is the first callback called by the system. The activity is now on CREATED state.

You should perform basic application startup logic that should happen only once for the entire life of the activity, for example, associating the activity to a viewModel.

If you initialize something after onCreate() is called, release or terminate it when onDestroy() is called.

onStart()

This is the second callback called by the system. The activity is now on STARTED state. The activity is visible to the user but not yet interactive.

You should execute code that maintains the UI.

onResume()

This is the third callback called by the system. The activity is now on RESUMED state. The user can now interact with the app. The app stays in this state until something happens to take focus away from the app. Such an event might be, for instance, receiving a phone call, the user’s navigating to another activity, or the device screen’s turning off.

You should implement onResume() to initialize components that you release during onPause()

These 3 commands are called on all activities you instantiate, they’re used to setup and make the activity available to the user. First the method is called, then the state changes. onCreate() is called and after that the activity is on CREATED state. The next 3 methods do that in the reverse order. The state changes to PAUSED and after that onPause() is called.

The state changes

After	Before
onCreate	onDestroy
onStart	onStop
onResume	onPause

onPause()

This is the first callback called to indicate the user is leaving the activity. The activity is now on PAUSED state. It is no longer in the foreground.

onPause() execution is brief and should not be used to perform heavy operations. Don’t use onPause() to save data, make network calls or execute database transactions. These operations should be executed when onStop() is called.

The user might decide to come back to the activity and onResume() will be called. If that doesn’t happen, onStop() is the next method.

onStop()

This is the second callback called to indicate activity might be finishing. The activity is now on STOPPED state. It is no longer visible. This happens every time you open a new activity that covers the whole screen.

You should release almost all resources that aren’t needed while the user is not using it. If needed you should also make network calls or save data to the database.

In some rare cases, the system might kill your process without calling onDestroy(), so it’s important that you use onStop() to release resources that might cause memory leak.

onDestroy()

This is the third and last callback called to indicate activity is finishing. The activity is now on DESTROYED state. This method is called by the system when finish() is called, when the user dismisses the activity or because the configuration changed, for example, the user rotated the device.

What happens when you start another activity? Source

The order of lifecycle callbacks is always the same. Here’s the order of operations that occur when Activity A starts Activity B:

Activity A’s onPause() method executes.
Activity B’s onCreate(), onStart(), and onResume() methods execute in sequence. (Activity B now has user focus.)
Then, if Activity A is no longer visible on screen, its onStop() method executes.

The sequence is always the same, making it easier for developers to manage transitions between them.

When to call the super class?

When overriding any of the methods, you may need to call the super class implementation. The rule of thumb¹² is that

During initialization, you should always call the super class first

During de-initialization, you should do the work first before calling the super class

The post Android Lifecycle Revised first appeared on Victor Brandalise.

DEV Community: Victor Brandalise

From Nothing to Material Transitions

Preparation

Basic Knowledge

Fade Through

Fade

What’s the difference between Fade and Fade Through?

Shared Axis

Container Transformation

Debug mode

Mixing transitions

Resources

How to Show an Activity on Lock Screen instead of a Notification

Creating The Notification

When Should I Create the Channel?

Creating a Simple Notification

Creating the Lock Screen Activity

Adding the Activity to Notification

It’s not Working !!!

Conclusion

Resources

In-depth look at gRPC for Android

HTTP/2

Binary framing layer

Streams, messages, and frames

Channel

CONNECTING

TRANSIENT_FAILURE

READY

IDLE

SHUTDOWN

Retry

Keep Alive

Subchannel

Protocol Buffers

Service

RPC

Unary

Streaming

Unary x Streaming

Success for both parties?

Best Practices For Protocol Buffers

Other articles

Resources

Useful Kotlin Extensions for Android

Useful Extension Functions

Context

Usage

Usage

Usage

Date

Usage

All that glitters is not gold

Be careful with localization

Extension Properties

Other articles

Android Lifecycle Scenarios – Single and Multi Activities

1. App is finished or restarted

2. Configuration changes

3. User navigates away

4. App is paused by the system

1. Navigate from Activity A to Activity B

2. Navigate from Activity B back to Activity A

Sources

Android Lifecycle Revised

onCreate()

onStart()

onResume()

onPause()

onStop()

onDestroy()

What happens when you start another activity? Source

When to call the super class?