Studio Knowledge

How to Build Something Your Users Will Share

Vikalp Jain — Wed, 18 Dec 2024 17:25:47 GMT

There’s a myth out there about social sharing from apps.

The common sentiment seems to be: “just slap on a share button” and like magic, your content will start making its way around the wilds of the internet. This is especially true if the target is a younger audience. Unfortunately, there is no “go viral” button.

If you want users to share content around your product, you’re going to need to consider:

What motivates people to share? And;
How to align your feature or content so it speaks directly to #1?

Let’s get into it.

There are innumerable reasons people feel compelled to share (too many to list). We’re not psychologists, but we have developed enough apps to have seen the share-cycle in action, and we’ve distilled the primary motivations for sharing into four categories:

1. The Cocktail Party Effect

Motivation: to be seen as “in the know.” People who share for this reason are often positioning themselves as knowledgeable or cutting edge. They want to be the very first one in their network to share the cool new thing or be able to wax philosophically on a brand-new product over a glass of red.

Reward: praise & validation from their peers.

Notable Cocktail Shares: the latest and greatest article on a cultural topic, newly released features on an existing product or a brand new cutting-edge one (think Google Glass when it first arrived on the scene. RIP.)

2. The Bandwagon Effect

Motivation: to participate in a viral moment. Users who share for this reason are often motivated by FOMO: they don’t want to be the only ones in their circle (either physical or virtual) who haven’t yet joined the movement.

Reward: feeling a part of a larger, like-minded, community

Notable Bandwagon Shares: the ALS ice-bucket challenge was a great example of the bandwagon effect. Being tagged to participate (and share) was a badge of honor. Political movements also capitalize on the bandwagon mentality, getting supporters to forward and share content as a means of participation in a campaign. Often there is some branded element that ties this together - a hashtag, a sticker, etc.

3. The OMG Effect

Motivation: the content has elicited such a strong, organic emotion – joy, sadness, fear, surprise – the user feels compelled to share it. Their motivation is simply that: to spread the feeling, good or bad, to others.

Reward: validation and expansion of their experience

Notable OMG Shares: the early adopters of the “Faceapp” AI aging filter were compelled to spread the word far and wide. This wasn’t just because of the novelty of the tech, but because for young people, seeing themselves in the latter half of their golden years was too delightful, terrifying, and compelling not to share.

4. The Need-to-Know Effect

Motivation: possibly the most difficult to inspire, this kind of sharing is motivated by a genuine desire to inform their network. Either to clue them in to an important cause, tap into collective wisdom, or uplift and elevate their community’s knowledge.

Reward: having an impact on friends, family, and like-minded others.

Notable Need-to-Know Shares: those looking to raise awareness on important issues, seek or offer travel recommendations, or share new results/innovations on a topic close to their heart are all examples of this kind of spontaneous (and hard to capture) sharing.

Instead of making assumptions about shareability, consider the primary motivations for your target audience and focus there. Do they want to be moved? Shocked? Beckoned onto a fast-moving bandwagon? Design your features and content accordingly.

Think about sparking the impulse to share, rather than just declaring something shareable and hoping for the best. After all, sharing isn’t about the button - it’s about giving users something worth pressing for.

Using Screen Navigation with Compose

Vikalp Jain — Wed, 11 Dec 2024 20:52:56 GMT

Moving between screens and views is a crucial aspect of creating robust and user-friendly Android applications. The approach to navigation has been totally transformed with the advent of Jetpack Compose, Google's modern declarative UI toolkit.

Managing navigation effectively can be a daunting task, especially when it involves passing data between screens. So in this guide, we will dive into Compose navigation to help establish efficient navigation flows for your Android apps.

To illustrate this, we’ll construct a basic app with 3 distinct screens. The app will feature a Home Screen with a button to navigate to the Profile Screen. Additionally, the Home Screen will include a list of clickable items that lead to a detail screen. We’ll develop the app using Compose and Koin - straightforward library for injecting dependencies and viewModels.

Getting Started

Now that we’ve set up the foundation, it's time to explore how to manage navigation using Jetpack Compose. To achieve this, we'll utilize the NavHost Component to encapsulate the various destinations within our app:

Building the UI

Home Screen

The home screen is a very simple one that inputs a list of items and functions as the user taps on the button to navigate to the profile and item screens.

@Composable
fun HomeScreen(items: List, onTapProfile: () -> Unit, onTapItem: (ItemData) -> Unit) {

    Box(
        Modifier.fillMaxSize().background(Color(0xFF3F51B5)).safeDrawingPadding(),
        Alignment.Center
    ) {
        LazyColumn {
            item {
                Box(Modifier.fillMaxWidth(), Alignment.Center) {
                    Button(
                        modifier = Modifier.fillMaxWidth().padding(20.dp),
                        onClick = { onTapProfile() }
                    ) {
                        Text("Go to Profile")
                    }
                }
            }

            item {
                Text(
                    "Items : ",
                    fontSize = 30.sp,
                    color = Color.White,
                    modifier = Modifier.padding(10.dp)
                )
            }

            items(items) { item ->
                Column(
                    Modifier.fillMaxWidth()
                        .height(50.dp)
                        .background(Color(item.color))
                        .clickable { onTapItem(item) }
                        .padding(horizontal = 20.dp)
                ) {
                    Spacer(Modifier.size(8.dp))

                    Text("Item  #${item.id}", fontSize = 20.sp, color = Color.White)

                    Spacer(Modifier.size(8.dp))

                    Box(Modifier.fillMaxWidth().height(1.dp).background(Color.White))
                }
            }
        }
    }
}

Profile Screen

The profile screen is the simplest screen of all. It just has a title and text positioned at the center. We will come back to the ProfileViewModel later.

@OptIn(ExperimentalMaterial3Api::class)
@Composable
fun ProfileScreen() {

    val viewModel: ProfileViewModel = koinViewModel()

    Scaffold(
        topBar = {
            CenterAlignedTopAppBar(
                title = { Text("Profile", color = Color.Black, fontSize = 30.sp) },
                navigationIcon = {
                    IconButton({ viewModel.navigateBack() }) {
                        Icon(
                            painterResource(R.drawable.back_arrow),
                            "back",
                            tint = Color.Black,
                            modifier = Modifier.size(30.dp)
                        )
                    }
                },
                modifier = Modifier,
                colors = TopAppBarDefaults.topAppBarColors(containerColor = Color.Transparent)
            )
        }
    ) { paddingValues ->
        Box(Modifier.fillMaxSize().background(Color.White), Alignment.Center) {
            Text("Profile Screen", fontSize = 30.sp, color = Color.Black)
        }
    }
}

Item Details Screen

The ItemDetailsScreen will take the data from the ItemDetailsViewModel to display the number of the item and use the color for the background.

@OptIn(ExperimentalMaterial3Api::class)
@Composable
fun ItemDetailsScreen() {

    val viewModel: ItemDetailsViewModel = koinViewModel()

    Scaffold(
        topBar = {
            CenterAlignedTopAppBar(
                title = { Text("Item Details", color = Color.White, fontSize = 30.sp) },
                navigationIcon = {
                    IconButton({
                        // TODO: Add back navigation
                    }) {
                        Icon(
                            painterResource(R.drawable.back_arrow),
                            "back",
                            tint = Color.White,
                            modifier = Modifier.size(30.dp)
                        )
                    }
                },
                modifier = Modifier,
                colors = TopAppBarDefaults.topAppBarColors(containerColor = Color.Transparent)
            )
        }
    ) { paddingValues ->
        val item by remember { mutableStateOf(viewModel.item) }

        Box(Modifier.fillMaxSize().background(Color(item.color)), Alignment.Center) {
            Text("Item #${item.id}", fontSize = 30.sp, color = Color.White)
        }
    }
}

The Domain layer

To replicate a real-life scenario, let’s utilize a service that will supply us with the necessary data to showcase on our various screens. The ItemService will be injected into both the AppViewModel and ItemDetailsViewModel. These viewModels will then retrieve the required data and send it to the view.

interface ItemService {
    val items: List
}

class RealItemService : ItemService {

    override val items: List = generateItems()

    // Generate a list of 100 items with the index as ID and a random color from the list below
    private fun generateItems(): List =
        (0 until 100).map { ItemData(id = it, color = getRandomColor()) }

    private fun getRandomColor(): Long {

        val colorList =
            listOf(
                0xFFF44336,
                0xFF009688,
                0xFF9C27B0,
                0xFF673AB7,
                0xFF3F51B5,
                0xFF4CAF50,
                0xFFFF5722,
                0xFF5F1700,
                0xFF690024,
                0xFF000D53,
                0xFF003602
            )

        return colorList[(0..colorList.lastIndex).random()]
    }
}

data class ItemData(val id: Int, val color: Long)

Dependency Injection

In order to be able to inject the service into the ViewModels and inject the ViewModels into the views, we are going to use Koin. The setup is very simple.

First, we need to create a custom App class:

class MainApp : Application() {

    override fun onCreate() {

        super.onCreate()

        startKoin {
            androidContext(this@MainApp)

            modules(appModule)
        }
    }
}

Set the MainApp as the class to run at launch in the manifest:

Almost there! Just create a kotlin file called appModule.kt. This file will contain all the different components to inject:

val appModule = module {

    // create a viewModel with all the required dependencies
    viewModelOf(::ItemDetailsViewModel)

    viewModelOf(::ProfileViewModel)

    viewModelOf(::AppViewModel)

    // Inject a Singleton
    single { RealItemService() }
}

And now we can create our viewModels to inject in the views:


val viewModel: ViewModel = koinViewModel()

class AppViewModel(itemService: ItemService) : ViewModel() {
    val itemList = itemService.items
}

class ItemDetailsViewModel(itemService: ItemService) : ViewModel()

class ProfileViewModel(private val navigator: Navigator) : ViewModel()

// Call this view from the MainActivity
// setContent {
//     TutorialNavigationTheme {
//         AppScreen()
//     }
// }

@Composable
fun AppScreen() {

    val viewModel: AppViewModel = koinViewModel()

    val navController = rememberNavController()

    NavHost(navController = navController, startDestination = HomeDestination.route) {
        composable(HomeDestination.route) {
            HomeContent(
                viewModel.itemList,
                {
                    // TODO: Add Profile Navigation
                }
            ) {
                // TODO: Add Item Navigation
            }
        }

        composableSlideInOut(ProfileDestination.route) { ProfileScreen() }

        composableSlideInOut(
            ItemDetailsDestination.route,
            arguments = ItemDetailsDestination.navArgs
        ) {
            ItemDetailsScreen()
        }
    }
}

composableSlideInOut is just an extension to customize the transition between two screens:

private const val transitionDuration = 700

fun NavGraphBuilder.composableSlideInOut(
    route: String,
    arguments: List = emptyList(),
    deepLinks: List = emptyList(),
    enterTransition:
        (@JvmSuppressWildcards
        AnimatedContentTransitionScope.() -> EnterTransition?)? =
        {
            slideIntoContainer(
                AnimatedContentTransitionScope.SlideDirection.Left,
                tween(transitionDuration)
            )
        },
    exitTransition:
        (@JvmSuppressWildcards
        AnimatedContentTransitionScope.() -> ExitTransition?)? =
        {
            slideOutOfContainer(
                AnimatedContentTransitionScope.SlideDirection.Left,
                tween(transitionDuration)
            )
        },
    popEnterTransition:
        (@JvmSuppressWildcards
        AnimatedContentTransitionScope.() -> EnterTransition?)? =
        {
            slideIntoContainer(
                AnimatedContentTransitionScope.SlideDirection.Right,
                tween(transitionDuration)
            )
        },
    popExitTransition:
        (@JvmSuppressWildcards
        AnimatedContentTransitionScope.() -> ExitTransition?)? =
        {
            slideOutOfContainer(
                AnimatedContentTransitionScope.SlideDirection.Right,
                tween(transitionDuration)
            )
        },
    content: @Composable AnimatedContentScope.(NavBackStackEntry) -> Unit
) {

    composable(
        route,
        arguments,
        deepLinks,
        enterTransition,
        exitTransition,
        popEnterTransition,
        popExitTransition,
        content
    )
}

Within the NavHost, you'll find composables that specify the various views and how to navigate between them. Remember to include a NavController using rememberNavController to handle the navigation.

The NavHost must designate a start destination to determine the initial screen to show. This start destination is simply a String that corresponds to one provided to a composable.

Here, we want the app to start on the HomeScreen.

Destinations

There are numerous effective approaches to handle destinations - scattered Strings however, is not one of the recommended approaches. It's quite easy to misspell them and encounter a crash. Instead, a popular approach is to utilize either an enum class or a sealed class.

For now, we'll handle destinations differently. Every destination will be a class that contains a static string for the route.

object HomeDestination {

    private const val root = "home"

    const val route = root
}

Or:

object ProfileDestination {

    private const val root = "profile"

    const val route = root
}

This will work nicely for a simple navigation without passing any arguments between screens. It might even be overkill.

Issues may arise when trying to send data - like the item id - to ItemDetailsScreen in this case.

To send parameters to a different screen, you must include the parameter name after the destination name in the route definition, for example: "$root/$index". As you construct the route, the argument name will be substituted with its actual value.

To make it easy, each destination will extend NavDestination.

interface NavDestination {

    fun buildRoute(): String
}

object HomeDestination : NavDestination {

    override fun buildRoute(): String = route

    private const val root = "home"

    const val route = root
}

object ProfileDestination : NavDestination {

    override fun buildRoute(): String = route

    private const val root = "profile"

    const val route = root
}

class ItemDetailsDestination(val index: Int) : NavDestination {

    constructor(
        savedStateHandle: SavedStateHandle
    ) : this(index = requireNotNull(savedStateHandle.get(inputArg)))

    override fun buildRoute(): String = "$root/$index"

    companion object {

        private const val root = "item_details"

        private const val inputArg = "index"

        const val route = "$root/{$inputArg}"

        val navArgs = listOf(navArgument(inputArg) { type = NavType.IntType })
    }
}

As you can see, ItemDetailsDestination will pass the index of the selected item to the detailed screen. For this, we pass the static route and navigation arguments navArgs which consist of a list of name (inputArg which is index) and a type (Here NavType.IntType).

The custom constructor will be used to recreate ItemDetailsDestination with the params that were passed from HomeScreen thanks to SavedStateHandle. More to come on that.

Navigator

Let's look at the main component of this architecture - the Navigator :

interface Navigator {

    fun setController(navController: NavController)

    fun navigate(route: NavDestination, builder: NavOptionsBuilder.() -> Unit = {})

    fun popBackStack()

    fun popBackStack(route: NavDestination, inclusive: Boolean, saveState: Boolean = false)
}

class RealNavigator : Navigator {

    private var navController: NavController? = null

    override fun setController(navController: NavController) {

        this.navController = navController
    }

    override fun navigate(route: NavDestination, builder: NavOptionsBuilder.() -> Unit) {

        navController?.navigate(route.buildRoute(), builder)
            ?: Log.w("Navigator", "No NavController set in the Navigator")
    }

    override fun popBackStack() {

        navController?.popBackStack() ?: Log.w("Navigator", "No NavController set in the Navigator")
    }

    override fun popBackStack(route: NavDestination, inclusive: Boolean, saveState: Boolean) {

        navController?.popBackStack(route.buildRoute(), inclusive, saveState)
    }
}

The Navigator will handle the navigation for us. From now on, every time we want to navigate, we are not going to call the usual navController.navigate("route") but navigator.navigate(NavDestination) instead. The Navigator will also take care of the back navigation calling popBackStack() to navigate back to the previous screen or to a desired screen present in the navigation back stack.

The Navigator will be injected into the viewModel of every screen and the view will call a viewModel function that will handle the desired navigation.

Now, let's see how to set that up.

In the appModule that we created previously, define how to instantiate the Navigator

val appModule = module {
    viewModelOf(::ItemDetailsViewModel)

    viewModelOf(::ProfileViewModel)

    viewModelOf(::AppViewModel)

    single { RealItemService() }

    // Add this line
    single { RealNavigator() }
}

In order for the Navigator to work, it needs to have the Compose NavController used by the NavHost. As the Navigator is a singleton, only one instance will be created, ensuring that we have a common Navigator across the app.

So we can inject it in the AppScreen where we will pass the NavController:

@Composable
fun AppScreen(
    // Inject the navigator
    navigator: Navigator = koinInject()
) {

    val viewModel: AppViewModel = koinViewModel()

    val navController = rememberNavController()

    // Pass the navController to the navigator
    LaunchedEffect(navController) { 	
    	navigator.setController(navController) 
    }
    
    ...
}

Now we can modify each viewModel by adding the navigator to their constructor. As the navigator is defined in the appModule, Koin knows how to instantiate and pass it to the ViewModel

class AppViewModel(itemService: ItemService, private val navigator: Navigator) : ViewModel() {

    val itemList = itemService.items

    fun navigateToProfile() {
        navigator.navigate(ProfileDestination)
    }

    fun navigateToItem(index: Int) {
        navigator.navigate(ItemDetailsDestination(index))
    }
}

The ViewModel will now handle the navigation. We can fill the HomeScreen lambda with the navigation logic:

fun AppScreen(navigator: Navigator = koinInject()) {
    ...
    NavHost(navController = navController, startDestination = HomeDestination.route) {
        composable(HomeDestination.route) {
            HomeScreen(viewModel.itemList, { viewModel.navigateToProfile() }) { item ->
                viewModel.navigateToItem(item.id)
            }
        }

        ...
    }
}

Receiving arguments

In order to receive the arguments, we will inject the Navigator and the SavedStateHandle which holds the arguments in a key-value format.

Koin takes care of SavedStateHandle as stated here.

class ItemDetailsViewModel(
    itemService: ItemService,
    private val navigator: Navigator,
    savedStateHandle: SavedStateHandle
) : ViewModel() {

    private val route = ItemDetailsDestination(savedStateHandle)

    val item = itemService.items[route.index]

    fun navigateBack() {
        navigator.popBackStack()
    }
}

First, ItemDetailsViewModel retrieves the index of the item from the SavedStateHandle and then gets the item object from the itemService.

We can now call navigateBack() from the view to navigate back to our HomeScreen

Scaffold(
    topBar = {
        CenterAlignedTopAppBar(
            title = { Text("Item Details", color = Color.White, fontSize = 30.sp) },
            navigationIcon = {
                IconButton({
                    // Call back navigation here
                    viewModel.navigateBack()
                }) {
                    Icon(
                        painterResource(R.drawable.back_arrow),
                        "back",
                        tint = Color.White,
                        modifier = Modifier.size(30.dp)
                    )
                }
            }
        )
    }
)

So there you have it! We've just explored the best way to handle navigation in your Jetpack Compose Android apps.

By using this architecture you can create a navigation structure that's not only robust but also super easy to maintain and scale, without using too many callbacks to call the NavController from the parent view with the NavHost.

This approach makes for cleaner code and reduces the chance of errors. If you're looking for help building your Android product, contact Studio today.

Coming soon

Vikalp Jain — Wed, 05 Jul 2023 12:48:19 GMT

This is Studio Knowledge, a brand new site by Vikalp Jain that's just getting started. Things will be up and running here shortly, but you can subscribe in the meantime if you'd like to stay up to date and receive emails when new content is published!

Lorem ipsum dolor sit amet consectetur adipisicing elit. Numquam, distinctio autem. Ipsa esse repellendus hic at possimus. Aliquam consequatur deleniti inventore aut tenetur sint perferendis neque natus unde eveniet qui odio hic sunt, labore laborum, ratione ut enim modi facilis consequuntur iure quam dolor quidem amet! Corporis dignissimos recusandae placeat repellendus nemo? Architecto maiores tenetur alias non voluptatem! Repellendus, sequi non consectetur dolore animi odit doloremque modi? Impedit praesentium eaque ipsum recusandae iusto delectus perspiciatis sed maxime.

Similique, provident id beatae quisquam dolorem porro earum illo eligendi numquam blanditiis necessitatibus aliquid consequatur ullam voluptatibus nam tempore corporis libero aliquam fuga veritatis est totam natus. Necessitatibus dolorum error rem et dicta quibusdam culpa voluptatibus illum, dolor tempore, dolore itaque quisquam tenetur. Iure quibusdam sed delectus aspernatur maxime? Ullam, aliquam quisquam. Optio dolorem ipsum fugit corporis, modi soluta rem id totam nam tenetur ex cum cupiditate voluptate eius quod vel sequi labore. Quibusdam, velit! Quaerat maiores fugiat rerum distinctio, quis quae autem non ea ipsa unde repellat ullam minus veritatis expedita labore neque mollitia eos inventore possimus corporis facere.

Aperiam minima a soluta excepturi cupiditate reiciendis quas amet aliquam eos, autem eum doloribus sit ut nulla. Laboriosam sit ex fuga magnam aperiam soluta corrupti tempore earum debitis omnis officia deleniti aut, aspernatur magni, vero nemo. A optio vel nesciunt quasi. Ea vel consequatur eveniet sint itaque! Officia praesentium eos voluptas ea et temporibus aperiam porro eius corrupti ratione vitae vero, quia necessitatibus rem reiciendis reprehenderit blanditiis, provident ullam optio velit tenetur exercitationem maiores? Dolore mollitia aliquam molestias harum consectetur!

Unde numquam culpa, molestiae laboriosam obcaecati veniam voluptate neque delectus consequuntur, iusto aut consequatur adipisci at ipsam nulla sapiente beatae est assumenda quis dicta! Error commodi dolorem harum! Ex molestias culpa voluptatibus minus tempore quod maiores nobis commodi vitae ratione. Tenetur, qui amet?