Did someone say Navigation to the rescue: Android Jetpack

If you been around the block a few times with Android development you probably already know that there is an issue with Navigation. If you don’t trust me you will soon find out but don’t worry I am going to let you in on a little hint to overcome many of the challenges that arise doing the development process. Note unless the app you are developing isn’t complex avoid this altogether but let get serious if you are developing for the public it is sure to become more convoluted as you go. Complexity can range from any of the following: Fragment transactions, deep linking to different parts within the app, passing values/arguments securely and safely, and much more. This is where our friend JetPack’s nav component steps in because its purpose brings solutions to the above complexity. From this article, you can expect how to solve those issues.

Terms and Definition to keep 

  • NavHost
    • a container that has any or all the information it may need to handle the navigation actions
  • NavController
    • This component performs the navigation between destinations,
  • NavigationalUI
    • This component simply connects the navigation with some material component (for example the BottomNavigationView and DrawerLayout)

Fragment Transactions

With the nav component, there’s no need to manually handle fragment transactions (praise him), and it takes care of everything internally. To successfully go from  FragmentA to FragmentB and now all you need to do is call the corresponding navigation action at runtime.

navController.navigate(R.id.actionId)
//or something like this
navController.navigate(R.id.destinationId)

The Back & Up Navigation

With the nav component and using the single activity model, the Activity’s role becomes more of an entry point to the app that delegates the handling of its content rather than being its owner. A NavHost, it is hooked up to the navigation graph which represents the single source of truth, and this where all the destinations, actions, arguments and deep links are defined

When using fragments as destinations, you can use the NavHostFragment class as a  NavHost. Let’s take a look at how the activity layout may look like it

<FrameLayout>
    <fragment
         android:id="@+id/mainNavHostFragment"
         android:name="androidx.navigation.fragment.NavHostFragment"
         android:layout_width="match_parent"
         android:layout_height="match_parent"
         app:defaultNavHost="true"
         app:navGraph="@navigation/main_navigation_grah"/>
</FrameLayout

Since the navigation graph is the single source of truth for all navigation within the app, the navigation component does the right thing when the user navigates back or up. Not only does it handles this, but it correctly takes care of things such as the back stack, transactions, pop behavior, and transaction animations.

Passing Data Securely & Safely

If you have ever pass data between  Fragments can be tedious as well as error-prone and this is not including the things that can go wrong or at least get confusing while refactoring the code. Ideally, we like to pass and retrieve arguments in an easy manner without having to worry about their keys, and read them safely.

The navigation component brings a solution to this using the Gradle plugin [androidx.navigation.safeargs]. It basically generates some boilerplate code to make any developer’s life easier. As you will see with the example below when a user navigates from FragmentA to FragmentB while passing a mandatory argument and an optional argument. What classes are generated:

  •  FragmentADirections.ActionFragmentAToFragmentB 
    • Inner class with a constructor that takes in the mandatory arguments and setters for the optional arguments
  •  FragmentADirections 
    • Has a method [actionFragmentAToFragmentB] that takes in the mandatory arguments and returns an instance of FragmentADirections.ActionFragmentAToFragmentB
  •  FragmentBArgs 
    • Has getters for the different arguments

So to begin, within the navigation graph, the destinations are defined along with the action (this transition is from FragmentA to FragmentB) and the arguments

<fragment
	android:id="@+id/fragmentA"
	android:name="com.test.FragmentA"
	android:label="Fragment A">
	<action
		android:id="@+id/action_FragmentA_to_FragmentB"
		app:destination="@+id/fragmentB"/>

</fragment>

<fragment
	android:id="@+id/fragmentB"
	android:name="com.test.FragmentB"
	android:label="Fragment B">
	
	<!--Mandatory Argument-->
	<argument
		android:name="id"
		app:argType="integer" <!--Argument Type-->
		/>

	<!--Optional Argument-->
	<argument
		android:name="data"
		android:defaultValue=""
		app:argType="string" <!--Argument Type-->
		/>
</fragment>

In addition, within FragmentA, performs the navigation while passing the arguments.

//creating  a NavDirection instance for the mandatory argument
val directions = FragmentADirections.actionFragmentAToFragementB(10)

// if there is n optional argument you can pass it
directions.setData("")

//Navigate to the new FragmentB
navController.navigate(directions)

Now reading

val id: Int = FragmentBArgs.fromBundle(arguments).id
val data: String = FragmentBArgs.fromBundle(arguments).data

 

Deep Links

Deep linking inside any application can get complicated as the app get more complex. Issues such as how to structure these deep links, how to pass the required information, and how to build the right back stack arise. In the nav component, deep linking is a first-class citizen, and both types are supported: Explicit () and Implicit ().

  • Explicit

    • Used for notifications, app widgets, actions, and slices. Consider these used for pending intent based.

 

//prepare the arguments to pass to any notification expectation
val arg = Bundle().apply {
    putString("StringKey", "a string value")
    putInt("IntKey", 0)
}

//preparing intent, while selecting the graph & destination
val pendingIndent = NavDeepLinkBuilder(context)
    .setGraph(R.navigation.main_navigation_graph)
    .setDestination(R.id.destinationFragment)
    .setArguments(arg)
    .createPendingIntent()

//prepaing notification
val notification = NotificationCompat.Builder(context, NavigationApplication.NOTIFICATION_CHANNEL_ID)
    .setSmallIcon(R.drawable.notification_icon)
    .setContentTitle("Explicit Deep Link")
    .setContentText("Click on the following notification")
    .setContentIntent(pendingIndent)
    .setAutoCancel(true)
    .build()

//Display notification
NotificationManagerCompat.from(context).notify(10, notification)

 

  • Implicit

    • Used for handling web URLs and custom scheme URIs.

 

<fragment
    android:id="@+id/destinationFragment"
    android:name="com.example.destinationFragment"
    android:label="@string/title_destination_fragment">
    <action ... />
    <deepLink
        android:id="@+id/custom_scheme_uri_deeplink"
        app:uri="android-app://path/subpath/{data}" />
    <deepLink
        android:id="@+id/web_url_deeplink"
        app:uri="www.husaynhakeem.com/path/subpath" />
</fragment>

Now we need to review the manifest and tweak it a bit. Within the activity tag of the Activity that contains the above destination fragment, the line below needs to be added.

<activity android:name="com.example.Activity">
    <nav-graph android:value="@navigation/main_navigation_graph" />
</activity>

Testing Navigation

The navigation component comes with a dependency just for testing android.arch.navigation:navigation-testing:$nav_version. But unfortunately, there seems to be very little (to say the least) documentation around it online, I wasn’t personally able to find any projects (not even the google sample apps) that use it, and a GoogleIO talk from earlier this year briefly brings up the topic but doesn’t go into any of its details. But the promise is that testing will be developed further in future releases, allowing developers to test their app’s destinations in isolation without worrying about potential issues such as fragment transactions.

All in All

Read more
No Comments

Using let or var within Swift

I know I know I know before you say anything I understand this statement is probably ridiculous. However, this topic could aid someone or more likely open the floor to discuss concepts in general so without hesitation, we will dive into it.

let and var so what are they and their differences

 As you probably already know both let and var are for creating variables within Swift. Now with let it helps create an immutable variable(s) so consider it a constant but var is used for creating a mutable variable(s). Nonetheless, a variable created by either of them holds a reference or a value. 

The difference between the two is that when a developer creates a constant with let the value must be assigned before you can use it. While when you declare a variable with var it can be used before or after an assignment or never use it as well as reassigning it on the fly.

Mutate function parms

function parameters are constants by default. Trying to change their value within the function body results in a compile-time error.

func pokedex(for name: String) { 
   name = "charmander" 
} 

pokedex(for: "mex")

//Line 2 cannot assign to value is let constant

Test: Build & Compile

struct Pokemon { 
   var name: String 
   let weakness: String 
} 

let trainerAPokemon = Pokemon(name: "Charmander", weakness: "water") 
trainerAPokemon .name = "Bulbasaur" 
trainerAPokemon .weakness = "fire" 

var trainerBPokemon = Pokemon(name: "Pikachu", weakness: "rock") 
trainerBPokemon.name = "Squirtle" 
trainerBPokemon.weakness = "electricity"

In the example above we are using a struct. Whenever you try to muate them they get copied with mutation applied to them and reassigned back.

Now let’s review everything within the block. The let variable within the struct cant is mutated as it would mean you are mutating the value of an immutable variable. However, our friend the var variable within the struct can be mutated. 

  • Line 7
    • cannot assign to the property trainerAPokemon because it is a let constant
  • Line 8 & 12
    • cannot assign to the property weakness because it is a let constant

Test: Build & Compile

class Pokedex {
   var name: Int
   let num: String

   init(name: String, num: Int) {
      self.name = name
      self.num = num
   }
}

let trainerA = Pokedex(name: "Lucario", num: 448)
trainerA.name = "Squirtle"
trainerA.num = 7

var trainerB = Pokedex(name: "Bulbasaur", num: 1)
trainerB.name = "Gengar"
trainerB.num = 94

In the example above we are now using a classes. When attempting to mutate them, the object stored elsewhere in memory gets mutated while the reference to it remains the same.

You can modify a class’s members whether or not the variable referencing it is mutable

  • Line 13 & 17
    • cannot assign to property num because it is a let constant

 

 

 

Read more
No Comments