Navigating in Compose: Criteria

Navigating in Compose: Requirements

Navigating in between screens is a widespread act in an Android app… although, as
Zach Klippenstein pointed out,
“screen” is a considerably amorphous time period. In a natural way, we want to be equipped to navigate
to different “screens” when those people screens are applied as composables.

How we do this is a extremely contentious subject matter.

Around speaking, there appears to be to be 4 important types of methods:

  • Use the formal Jetpack Navigation for Compose

  • Use some sort of wrapper or helper all-around Navigation for Compose —
    Rafael Costa’s compose-locations library
    is an instance

  • Use Jetpack Navigation, but use the “classic” implementation alternatively of Navigation
    for Compose, using fragments to wrap your monitor-stage composables

  • Use some individual navigation implementation, this sort of as Adriel Café’s Voyager library

I simply cannot inform you what to use. I can inform you that you need to appear up with a established
of criteria for judging numerous navigation alternatives. Dependent on a study of a bunch
of navigation answers, in this article are some criteria that you might want to consider.

Table Stakes

If your navigation answer does not guidance ahead navigation to N destinations,
or if it does not guidance again stacks (e.g., a goBack() functionality to pop a vacation spot
off the stack and return to the place you experienced been ahead of), use a little something else.

Compile-Time Form Protection

A person important issue of using Kotlin, and Java right before it, is variety basic safety. The more type
safety we get, the much more probably it is that we will uncover issues at compile-time,
somewhat than only by using tests or by the application going 💥 for your buyers.

…For Routes/Locations

When you tell the navigation alternative in which to navigate to in ahead navigation,
you may possibly want to want methods where by the identifier is anything that is kind safe.
Some remedies use strings or integers to identify routes or locations. That helps make
it really simple to do some definitely terrifying items, like compute a desired destination working with math.
Frequently, primitives-as-identifiers supply minor compile-time safety. You may possibly choose
options that use enums, sealed course, marker interfaces, or other matters that
determine what are and are not legitimate options.

(and if you are inquiring oneself “what about deeplinks?”, that is coated a little bit later)

…For Arguments

Usually, our screens need details, no matter if an identifier (e.g., most important important) or
the precise information alone. So, we want to be in a position to move that info from preceding
screens. All else staying equal, you could want to want solutions that supply compile-time
style protection, so you do not wind up in situations in which you supply a string and the receiver
is expecting an Int rather.

A similar criteria is “content safety”. You might want to want alternatives exactly where your
code can just go the info, with out getting to fret about no matter if it complies with
any alternative-specific restrictions. For instance, if the solution necessitates you to URL-encode
strings to be equipped to move them securely, that is not excellent, as you will neglect to do this from
time to time. Preferably, the option handles those people kinds of items for you.

…For Return Values

At the very least for modal locations, such as dialogs, we frequently need to have to go back some
form of “result”. For illustration, we exhibit a dialog to allow the consumer to select something,
and we want the previous display to obtain out what the consumer picked. Sometimes, there
are strategies of accomplishing this outdoors of a navigation resolution, these types of as the dialog
updating some shared facts illustration (e.g., shared Jetpack ViewModel) exactly where
the former display screen finds out about benefits reactively. But, if the navigation solution
you are considering presents return values, and you intend to use them, you could possibly want
to favor ones exactly where people return values are also style-risk-free and content-risk-free.

IOW, forward-navigation arguments really should not get all the basic safety adore.

Assistance for Configuration Change and Course of action Loss of life

Like it or not, configuration alterations are authentic. Birds, most likely not.

One way or yet another, your app requires to be equipped to cope with configuration alterations,
and your navigation resolution really should be equipped cope as perfectly, to assistance your application.
This incorporates both of those retaining the navigation details alone throughout configuration modifications
and, ideally, obtaining a sample for application data for your screens to survive as effectively
(e.g., Navigation for Compose’s for each-route ViewModel assist).

Associated is approach death:

  • The consumer utilizes your app for a although

  • The user receives distracted by some not-a-hen for a though, and your app’s UI moves to the track record

  • When in the qualifications, Android terminates your method to free up process RAM

  • The person returns to your app just after your process dies, but in a acceptable time period of time
    (last I understood, the restrict was 30 minutes, however that value may perhaps have altered about the years)

Android is likely to want to not only convey up your application, but pretend that your course of action
experienced been all over all that time. That is the place “saved instance state” comes into play,
and ideally your navigation answer advertises assistance for this, so your again-stack
and so on get restored alongside with your UI.

Hooks For Stuff You May Use

Only you know what your app is going to want to do in conditions of its UI. Or probably
your designers know, or your item professionals. Or, hey, it’s possible you are just spraying
pixels about like Jackson Pollock sprayed paint.
Who am I to decide?

Irrespective, there may perhaps be some issues that you want in your app’s UI or flow that
tie into what you will have to have out of your navigation option.

Lots of apps use these kinds of UI constructs. It could not be necessary that they be taken care of
by way of a navigation solution — you may be in a position to product them as becoming “internal implementation”
of a screen, for case in point. But, it would be superior to get a perception of what styles
are established, if any, for a distinct navigation option to tie into these
types of UI constructs. For case in point, if you want to able to not only navigate to a screen, but
to a specific tab or web page inside that screen, it would be good if the navigation
solution supported that. Possibly not crucial, but awesome.

And, for some of these UI constructs, you could be seeking to have many again stacks. For instance,
you may possibly want to have it so that back again navigation inside a tab normally takes you to preceding articles
within just that tab, instead than likely back again to other tabs that the user earlier visited.
Assistance for many back stacks appears to be to be a little bit of an superior aspect, so if this
is crucial to you, see what candidate navigation answers provide.

Deeplinks are well-known. Right here, by “deeplink”, I not only necessarily mean situations wherever a spot
is activated from exterior of the app, this sort of as from a hyperlink on a Website web page. I also imply
situations where by a place is determined at runtime primarily based on facts from an outside the house
supply, such as a server-driven “tip of the day” card that steers consumers to certain
screens within the app.

If you believe that you will need to have these items, it will be useful if your navigation
resolution supports them immediately. That support may not be required — just as your
other app code can navigate to places, your “oh, hey, I acquired a deeplink” code
can navigate to places. Even so, a navigation answer could simplify that,
especially for conditions where the deeplink is from outdoors of the app and you want
to make a decision what to do with the presently-running app and its current again stack.

When assessing deeplink support, one particular requirements that I will strongly recommend is:
deeplinks should be choose-in. Not just about every monitor in your application ought to be instantly
reachable by some exterior get together just by being tied into some navigation procedure
— that can guide to some protection difficulties.

Also, consider how details in the deeplink will get mapped to your arguments (at the very least
for routes that get arguments). Some navigation options will try out to tackle
that instantly for you, but be wary of methods that use deeplinks as an excuse
to be weak on type basic safety. Preferably, there must be an unambiguous way to change pieces
of a deeplink (e.g., route segments, question parameters) to navigation arguments, but
in a way that limits any “stringly typed” logic to deeplinks by themselves and does not
crack kind protection in other places.

Transitions

Your designers may well connect with for a particular way to transition from monitor X to monitor
Y, this kind of as a slide, a fade, a slide-and-fade, a fireworks-model explosion destroying
X with Y showing guiding it, and many others. Ideally, the navigation remedy would take care of
those people sorts of transitions, particularly if you need to control the again-navigation
transition as nicely (e.g., the exploded fireworks by some means reassembling by themselves into a display,
mainly because that seems like enjoyment).

Improvement Criteria

Does the library have very clear documentation? Does it seem to be to be managed? Does it
have a crystal clear way of finding guidance? Does it have a license that is compatible with
your job? These are all typical conditions for any library, and navigation solutions
are no exception.

Beyond that, navigation solutions have a couple unique things that you may want to
think about, this kind of as:

  • How conveniently can you assistance navigation where the destinations could reside in different
    modules? Especially for assignments that go with a “feature module” progress product,
    it is likely that you require a display in module A to be in a position to navigate to a display in
    module B.

  • Are there crystal clear patterns for making use of @Preview? In basic principle, a navigation answer
    need to not get in the way of using @Preview for display-amount composables, but it would
    be agonizing if it did.

  • Does the answer perform for improvement targets over and above Android? Possibly you are not
    organizing on Compose for Desktop or Compose for World wide web or
    Compose for iOS or
    Compose for Consoles. If you are, you
    are likely to want to consider if and how navigation ties into your Kotlin/Multiplatform
    ambitions.


This is not a finish checklist — if there are factors that you assume are quite popular
that I missed, reach out!