Introduction.

In Kotlin, we declare variables with the val or var keywords:

val name = "Jane Doe" // Read only variable (value cannot be changed)

var age = 18 // Read-Write variable (value can be changed)

Let’s use these variables to construct a Person class:

class Person(val name: String, var age: Int)

In the Person class constructor, name and age are called properties. Properties are attributes of a class.

We can create a person from Person class like so:

val person1 = Person(name="Jones", age=23)

person1 has the name Jones and is 23 years old.

Every class property has a field (variable) that stores the property value, a corresponding getter to access the value of a read-only property, or a corresponding getter and setter to access and update the value of a writable property.

These getters and setters are called Accessors and are built into the Kotlin programming language.

To access person1 name, you can write the code:

person1.name // <-- generates a getter

Accessing person1 name generates a getter because the name property is read only.

To update person1 age, you can write the code:

person1.age = 24 // <-- generates a getter, and setter

Updating person1 age generates a getter and setter because age is a read-and-write property.

Example 1: Custom getter.

What if we want to compute another property of a class from the properties in its constructor? — we can accomplish that using a custom getter.

Imagine we want to verify that person1 is an adult. To do this, we can create a custom setter on a property, isAdult, like so:

class Person(val name: String, var age: Int) {

    val isAdult: Boolean
        get() {
            return age >= 18
        }
}

In the code above:

1. We initialized the isAdult property with a Boolean type.
2. We created a custom getter using the get() { } syntax. Within the braces, we return a boolean value of true or false depending on the value of age.

To check that person1 is an adult, you can access the isAdult property as you did for name or age:

person1.isAdult

Like the name property, the isAdult property has a corresponding backing field that stores its value every time it is called. Therefore, there is no use in creating another field to hold the value.

Example 2: Custom getter and setter.

Let’s look at another example.

To begin, let’s construct an Employee class:

class Employee(
    val employeeId: Int,
    val name: String,
    var status: Status
)

Employee has read-only properties: employeeId and name; and writable property status of type Status.

Status is a class defined as:

enum class Status(val hoursPerWeek: Int) {
    FullTime(40), PartTime(20)
}

The role of status is to mark whether an employee works full-time or part-time.

Next, let’s construct an Organization class:

class Organization(var name: String, val employees: MutableList<Employee>)

Organization has a mutable property, name, and read-only property: employees.

To create an organization:

First, define multiple employees using the Employee class:

val employee1 = Employee(
        employeeId = 1,
        name="Bob",
        status = Status.FullTime)

    val employee2 = Employee(
        employeeId = 2,
        name="Jane",
        status = Status.PartTime)

    val employee3 = Employee(
        employeeId = 3,
        name="Bill",
        status = Status.PartTime)

    val employee4 = Employee(
        employeeId = 4,
        name="Chloe",
        status = Status.FullTime)

Then, assign a mutable list of our predefined employees to employees property:

val shield = Organization(
        name = "Shield Corp.",
        employees = mutableListOf(employee1, employee2, employee3, employee4)
    )

Imagine we want to access full-time employees from shield. We can achieve that using a custom getter:

class Organization(var name: String, val employees: MutableList<Employee>) {

    // private backing field for fullTimeEmployees property
    private val _fullTimeEmployees =
        employees.filter { employee -> employee.status == Status.FullTime }

    val fullTimeEmployees: List<Employee>
        get() = _fullTimeEmployees
}

The code above uses the _fullTimeEmployees field or variable to store the value of fullTimeEmployees. _fullTimeEmployee is called a backing field.

To print employees with full-time status from shield, you can do this:

// print only full time employees in shield corp
    shield.fullTimeEmployees.forEach {employee ->
        println(employee.name)
    }

The output will be:

What if we want to hire full-time employees? What if we want fullTimeEmployees to handle the addition of full-time employees in our organization?

You can achieve such a feat with a custom setter:

class Organization(var name: String, val employees: MutableList<Employee>) {

    // private backing field for fullTimeEmployees property
    private var _fullTimeEmployees =
        employees.filter { employee -> employee.status == Status.FullTime }

    var fullTimeEmployees: List<Employee>
        get() = _fullTimeEmployees
        set(value) {
            when {
                value.isEmpty() -> println("$name needs Employees!.")

                value.all{employee -> employee.status == Status.FullTime } -> {
                        _fullTimeEmployees = value
                        employees.addAll(_fullTimeEmployees)
                        println("$name recruited full-time employees")
                    }

                value.any { employee -> employee.status == Status.PartTime } -> {
                        println("Unfortunately, $name only needs full-time employees")
                    }
            }
        }
}

Three things are worth noting:

1. _fullTimeEmployees is now a mutable backing field because we want to change its value.
2. fullTimeEmployees is now a mutable property because we want to implement our custom setter logic.
3. The custom setter syntax: set(value) {} to update the value of fullTimeEmployees.

Within the braces, assigning a list of employees to fullTimeEmployees will change the value of _fullTimeEmployees and update the employees property if the list only consists of full-time employees.

To test our custom setter:

First, we will assign a list of full-time employees to shield’s fullTimeEmployees property as its value:

shield.fullTimeEmployees = listOf(
        Employee(
            employeeId = 10,
            name = "Mark",
            status = Status.FullTime
        ),

        Employee(
            employeeId = 11,
            name = "Sherley",
            status = Status.FullTime
        )
    )

Next, we will print the names of full-time employees from shield’s employees property:

println("=========Full TIME AGENTS OF SHIELD===================")
    shield.employees.forEach {employee ->
        if (employee.status == Status.FullTime) {
            println(employee.name)
        }
    }

This will return:

That’s It!

TL;DR:

• Properties are attributes of a class.
• Properties, like variables, are declared with the val or var keyword.
• When you declare a property, you declare its getter and setter.
• Custom properties are computed from other properties of a class.
• Use get() { } syntax to specify the getter of a custom property.
• Use set(value) { } syntax to specify the setter of a custom property.

Introduction.

In this blog post, we will learn to create a composable UI on Android.

By the end of this post, you will have the skills to convert your designs to Android using Jetpack Compose.

Prerequisite.

• Basic understanding and usage of Jetpack Compose elements, Layouts, and Modifiers.
• The Source code for this article.

The Design.

We will build this UI:

When creating this design, we will not include the BottomNavigation Bar as it is a material design component.

Let's explore the steps needed to convert the design to a composable UI.

The Steps.

1. Break the Design into Modular parts.

The green bounding boxes are called Modules. A module is a composable UI element that is part of the screen.

You can find modules by navigating to ui/screens/WelcomeScreen.kt.

In code, we declare a module as:

@Composable
private fun ModuleName(modifier: Modifier = Modifier) {

}

For example, we declare the TopAppBar module as:

@Composable
private fun TopAppBar(modifier: Modifier = Modifier) {

}

The private keyword ensures that the module is used only in the WelcomeScreen.kt file— the principle of Encapsulation.

View the source code in Project View and navigate to the ui/screens/WelcomeScreen.kt file to locate modules declaration. You don't need to worry about each module's content right now. You can explore them later.

2. Identify Common Composables.

Common Composables are reusable building blocks comprising our modules shown in blue bounding boxes.

3. Build Common Composables.

Unlike Modules, common composables are without a private keyword. Multiple modules and screens can customize these components using their modifiers or parameters.

For example, CustomIcon composable has implementation:

@Composable
fun CustomIcon(
@DrawableRes icon: Int,
backgroundShape: Shape,
size: Dp,
color: Color,
modifier: Modifier
) {
 Box(
        modifier = modifier
            .size(size)
            .clip(backgroundShape)
            .background(color = color)
    ) {
        Image(
            painter = painterResource(id = icon),
            contentDescription = "",
            modifier = modifier.align(Alignment.Center))
    }

}

CustomIcon can be any icon with a background shape, size, or color by assigning values to the parameters icon, backgroundShape, size, and color.

Open the source code in Project View. Look at the reusable components found under the ui/components package and examine them individually.

4. Combine composables to create modules.

Let's combine our reusable components with the essential elements of Jetpack Compose inside of layouts while tweaking their modifiers to build the modules.

For example, the ChooseBrand composable module positions the list of BrandItems horizontally using a Row and places the SectionHeader and BrandList vertically using a Column.

@Composable
private fun ChooseBrand(
    modifier: Modifier = Modifier
) {

    Column(
        modifier = modifier
    ) {

        SectionHeader(name = "Choose Brand", modifier = Modifier)


        // BrandList
        Row(
            modifier = Modifier.horizontalScroll(rememberScrollState())
        ) {


            BrandItem(
                brand = R.string.adidas,
                icon = R.drawable.adidas,
                modifier = Modifier.padding(start = 5.dp))

            BrandItem(
                brand = R.string.nike,
                icon = R.drawable.nike,
                modifier = Modifier)

            BrandItem(
                brand = R.string.fila,
                icon = R.drawable.fila,
                modifier = Modifier)

            BrandItem(
                brand = R.string.puma,
                icon = R.drawable.puma,
                modifier = Modifier)

        }
    }


}

We use the Modifier.horizontalScroll(rememberScrollState()) to enable scrolling.

View the source code in Project View and navigate to ui/screens/WelcomeScreen.kt file to see each module implementation.

5. Combine Modules to complete the Design.

Finally, we will create a new WelcomeScreenContent module by combining our existing modules. This module will include the content for the WelcomeScreen.

WelcomeScreen is an app entity, and it is essential to expose the Screen, not its content. We do this to ensure the application is appropriately composed, with WelcomeScreen being a part of the entire app.

Another reason for the abstraction is to apply app-related settings to WelcomeScreen. For example, by placing WelcomeScreenContent inside Surface with the modifier parameter set to fillMaxSize, WelcomeScreen fills the entire space.

Navigate to ui/screens/WelcomeScreen.kt file and check out the full implementation of WelcomeScreenContent composable.

Conclusion.

Do not forget to place WelcomeScreen inside the setContent{} block in MainActivity.kt.

To interact with the screen, run the app, and you should see this:

Resources.

• Laza Figma file.

Laza - Ecommerce Mobile App UI Kit | Figma Community

User interfaces are essential for every Android app. They serve as the medium through which your users interact with your app. When built right, users are delighted as they use your app. If not, it will lead to bad user experiences.

And we know developing interfaces on Android is more challenging than our users might think. Let me introduce you to Jetpack Compose to simplify and accelerate this process.

What is Jetpack Compose?

Jetpack Compose is the new toolkit to build native UIs for Android. The name is derived from the combination of “Jetpack” and “Compose.”

Jetpack are libraries to help Android developers build apps consistent across Android devices and versions using best practices and consistent codebases.

Compose is a component of Jetpack that simplifies the process of creating user interfaces on Android devices. The name comes from the Object Oriented Principle of Composition.

In other words;

Jetpack Compose is a modern library or framework for building native UI on Android using Composition.

Why Jetpack Compose?

1. Declarative over Imperative thinking.

The hardest part about building a UI is how it changes or updates over time. For such changes to happen, the following must occur:

• Views that make up the UI should capture users’ specific actions, gestures, or events.
• Update the UI state in response to user-generated events.
• Update the UI to represent the new state.

Traditionally, you can use imperative thinking in Android to perform such changes. Imperative programming uses functions to describe how the UI should look when data or state changes.

By being imperative, you tell the UI to do what you want or show the views you need.

Below is a profile screen in two different states:

Using imperative thinking, the code to render the user profile might be:

You must handle 12 “if statements” to display the user profile. If you forget one if statement, the user profile will render an incorrect UI.

With Jetpack Compose, you use the declarative approach.

By being declarative, you describe what the UI should be, rather than how the UI should look.

When displaying the user profile to the left, declarative programming would show a red follow button rather than make the follow button have a red background.

The user profile would be declared in Jetpack Compose as:

2. Composition over Inheritance.

Inheritance is a programming pattern where a child class inherits the properties or behaviors of a parent class. The original Android UI toolkit is built on the principle of Inheritance.

Take a look at the image below.

ImageButton is a child widget of ImageView, and so is ImageView to View and View to Object. This means methods of ImageView are methods of ImageButton.

It would take a lot of work to build and maintain a custom ImageButton due to the many parent methods you must re-implement.

Jetpack Compose is built on Composition.

Composition is a principle in object-oriented programming that says that classes should achieve different behaviors and code reuse by containing instances of other classes to implement the desired functionality.

In Jetpack Compose, Composition will mean that you can build your UI by using multiple classes rather than inheriting a single class.

An ImageButton can be built in Jetpack Compose as such:

ImageButton contains Icon() and Box() components, both pre-built widgets offered by Jetpack Compose.

This makes building complex views easy because there are compositions of other views. Also, there is code reusability. Just as Icon() and Box() are used to build ImageButton composable, ImageButton() can likewise be used to implement another widget.

3. Encapsulation over Callbacks.

There are two things to think about when building UIs on Android:

• Which view you’d use to display any given data?
• Who is responsible for data changes?

The Android UI toolkit has widgets that assume both roles. While it’s evident that views should display states, it is not to have them manage states. Views managing data changes (states) implement callbacks or listeners in the form of interfaces.

For instance, TextView, used to display text, has the addTextChangedListener callback that tells you whenever the text has been changed. But the changes to the text can be from the user or another source.

Jetpack Compose decouples components responsible for displaying state from parts responsible for updating state by embracing Encapsulation.

Encapsulation is a concept in object-oriented programming(OOP) that hides class implementation from other parts of a computer program.

Using this concept means your UI will represent the state and isn’t responsible for managing the state.

Imagine building a simple contact list:

Contact is a state, defined in Kotlin as:

Using Jetpack Compose, you create a Contact composable like this:

Here, your Contact Composable or widget displays each Contact and has nothing to do with updating the Contact.

4. Separation of Concerns: Cohesion over Coupling.

Building a simple Android UI requires defining a layout in XML and inflating it into a Kotlin or Java Object. Making the UI responsive requires that you connect it with your business logic.

While this allows you to see your UI in action, the lengthy process goes against a concept known as Separation of Concern.

Separation of Concern is a design principle that suggests that you should separate your program into distinct sections with each section addressing a distinct concern.

A concern is a set of information that affects the code of a computer program.

It could be as general as the hardware on which you run your app, or as specific as the name of which class to instantiate.

If you have always heard that you should separate your business logic from your UI logic, that is a separation of concern.

Separation of Concern has two main concepts: Cohesion and Coupling. To better understand these concepts, imagine an app to be a group of modules, and each module contains many units.

Dependencies between modules would represent Coupling.

On the other hand, interactions between units in a module would describe Cohesion.

The goal is to group related code as much as possible(reduce coupling and increase cohesion). This way, your code is maintainable over time and scales as your app grows.

By design, implementing a UI in Android encourage implicit dependencies between the layout written in XML and the business logic written in Kotlin.

Implicit dependency is not by your own doing but by how the Android UI framework is designed—such dependency results from the language difference between the modules, hence, a forced line of separation.

This forced line of separation disappears in Jetpack Compose because everything is written in Kotlin.

Jetpack Compose is built with the idea that a framework should not separate your concerns for you. You should be able to decide where to draw the line of separation, depending on what makes sense for your situation.

This means that the implicit dependencies you had between your layout and business logic now become explicit.

Another benefit of having your UI and business logic written in Kotlin is that you can refactor those explicit dependencies to reduce Coupling and increase Cohesion.

Components of Jetpack Compose.

There are several components that makeup Jetpack Compose. These components can be placed into two distinct parts we shall call hosts.

1. Development host

The first part contains all the tools that would help you write composables. They are:

• Kotlin Compiler: Jetpack Compose is written in Kotlin and uses many features, like trailing lambdas and commas, so it is easy to build your UI.
• Compose Compiler Plugin: If you have noticed, every compose code is a function that begins with the @Composable annotation. This plugin translates those annotations to UI-specific code for Android to render on the screen.
• Android Studio: As the preferred IDE for Android development, it offers specific tools that make building with Compose easy.

2. Device host.

The second part contains the components necessary to run compose code on your device. Those components are:

• Compose Runtime: Compose logic doesn’t know anything about Android or UIs. It only knows how to work with tree structures to emit specific items. The runtime provides an entry point for the compose compiler to understand the tree structure and emit UIs or other UI-related things like animations.
• Compose UI Core: It handles interaction with the device, such as layout, drawing, measurement, and input management.
• Compose UI Foundation: It contains essential building blocks like Text, Button, Row, Column, and other default interactions.
• Compose UI Material: An implementation of the Material Design System. It provides Material components, making using Material Design in your app easy.
• Compose UI Material 3: Implementing the Material Design 3 system, the new Material Design on Android 12 and higher. It provides Material 3 components, making using them in your app easy.
• Compose UI Animation: It includes components for adding animations to your app.

Resources

Now that you know what Jetpack Compose is, its components, and how different it is from the Old Android UI toolkit, these resources should help you learn how to build interfaces using the framework.

Setup: To use Jetpack Compose in a new or existing Android app, check out:

Quick start | Jetpack Compose | Android Developers

Playgrounds: To delve right into experimenting with the different device components, check out:

Overview - Jetpack Compose Playground

Codelabs: If you enjoy a step-by-step approach, here are two codelabs that cover the basics of the framework:

• Jetpack Compose basics | Android Developers
• Basic layouts in Compose | Android Developers

Samples: There are sample projects that you should follow through if you fancy how to build full apps with the framework.

GitHub - android/compose-samples: Official Jetpack Compose samples.

Courses: If you prefer a mix of different content materials(text, video, and codelabs) while earning badges and tracking your progress, here are courses provided by the Jetpack team that covers everything from having a material-designed app to building for different devices.

Jetpack Compose for Android Developers

As a software developer, it is likely that you have heard of the term “freelancing” and wondered what it is and whether it is a good fit for you or not. For the sake of this article, let’s assume this is your first encounter with the word and want to consider the option. So you pose the question, what is freelancing?

Freelancing is a term used to describe the act of offering one’s time and skills in exchange for money. The term is common and often used to describe anyone capable of working on their terms and for whoever. Though it sounds good when spoken about, especially with the powers you possess as a developer to conjure whatever software you decide, it is more complicated than you think if not approached with the right mindset.

In this article, I will go to length to highlight and explain common mistakes made by freelance software developers during their early stages. Also, I’d offer suggestions for avoiding such errors.

Whether you are thinking of shifting to freelancing or have been for a while, this article is for you.

Mistake #1: Freelancing is my job.

This is a common trait amongst most software developers and is more rampant for first-time freelancers. Having worked as an employee or not, there is this tendency to approach freelancing as though it is a regular job. Trading your time for money and taking orders from your new boss, all while doing this in the comfort of your location. Similar actions you tend to exhibit as employees, except for the choice of place in some sense.

You should instead act as an entrepreneur or, if that scares you, a solopreneur. As an entrepreneur, you should say: Freelancing is my business.

By changing such a mind shift, freelancing becomes exciting, fulfilling, and a lifestyle you enjoy waking up and working towards. Also, you get to think differently about how you would price your services.

Mistake #2: I do everything for every client. I can multitask.

When you see freelancing as a job, you get to behave like a clueless employee to many new bosses. Ignorant in the sense that you don’t know that you are one. You become all capable and have no filter for your role and what it isn’t.

You can multitask, taking whatever is thrown at you to do. And that translates to the need to work tirelessly for every client by taking on tasks that you are not an expert in or don’t enjoy doing at all.

You are to think otherwise to avoid this mistake at all costs. And the way to go about it is by specializing. Taking on projects that match your skillset or doing that one thing you know to do well while seeking help on the things you are not so good at through delegation.

Mistake #3: I have to make money. I’d take whatever deal walks the door.

This might be your move for someone not sure about taking freelancing seriously. To work with whatever budget a client has to offer.

But if you decide to take a leap and be intentional, you must understand your worth and not settle for less. Remember, you are the entrepreneur. Money needs to be made that reflects your expertise and experience.

Mistake #4: I would have little to deal with. There is more time for myself, my family, and my friends.

I get it. 9–5 is tedious and time-consuming. Sitting at the office almost all day is exhausting and less fulfilling. But that won’t change much when you are just getting started in the world of freelancing.

Your ability to take initiative and be on top of things would be tested. And that takes time. You would have a lot of responsibilities because you are your employer.

Such responsibilities involve managing your clients and yourself, learning to market and make sales, paying your taxes, etc.

Knowing this, it is advisable to plan. To create time for your loved ones once you make the switch. You would likely work more hours as a freelancer, but the good news is you can do so on your schedule.

Mistake #5: Freelancing platforms are my friends.

In the tech world, the widely known freelancing platforms are Fiverr and Upwork. Such platforms are designed to help professionals like you begin your journey as a freelancer. However, they aren’t your friends. They aren’t intended to give you the life you want.

While they are filled with jobs and clients, there is no visibility into the decision process of any client to hire you. Moreover, they aim at cutting a percentage from any payment received(and yes, they deserve to).

I’d recommend using them for a start. To learn and gain some exposure and land your first few gigs.

Conclusion.

Phew!!. I know that was a lot to take in. Hopefully, I hope you enjoyed reading this work, and if there is one thing to take away from this article, it would be

“When you think to freelance, think to become an entrepreneur”