DEV Community: Dandan Meng

Swift vs Kotlin

Dandan Meng — Mon, 18 Jul 2022 01:23:20 +0000

This article is aiming to help an Android developer get a quick knowledge of the Swift programming language. (Writing from this perspective.)

I didn’t mean to write a very long and detailed article to cover everything, just a quick one to get you onboarded.

This article is also suitable for:

Experienced programmer (who knows other programming languages) wants to learn Swift.
iOS developer (who knows Swift) wants to learn Kotlin.
iOS beginner developers.
Developer hasn’t used Swift for a while and wants to get a quick refresher memo.

Basic types

Swift	Kotlin
Bool	Boolean
Array	Array, List, MutableList
Set	Set
Dictionary	Map

Other types are basically the same.

Syntax

	Swift	Kotlin
variables (not totally equals, see elaboration below)	let/var	val/var
named arguments	at: 0	at = 0
function	func name() → returnType	fun name(): returnType
absence of a value	nil	null
unwrapped type	String!	-
if	if number != nil	if(number != null)
provide default value if nil or null	xxx ?? “default string”	? : ”default string”
if it has value, do {}	if let number = Int(”333”) {}	?.let {}
for loop	for i in 1...5 {}	for (i in 1..5) {}
for loop	for i in 1..<5 {}	for (i in 1 until 5) {}
do while loop	repeat {} while	do {} while ()
this instance	self	this
value object	struct	data class
	as?	as?
	as!	as
	try?	-
	try!	-
class initializer	initializer	constructor
init a mutable list	var someInts: [Int] = []	val someInts = mutableListOf()
init a empty dictionary/map	var namesOfIntegers: [Int: String] = [:]	val namesOfIntegers = mutableMapOf()

Constants and Variables

Swift:

let you can not assign value again. If the type is struct, you can not update any var properties of the instance. (If it's a class, then you can update var properties).
var can both assign values or update properties of the instance.
var also makes an array mutable.

Kotlin:

val means final in java, you can not assign values again, but you can update the public vars of the instance.
var means you can assign values again.
collections types’ immutable or mutable are controlled by the data type.

Switch case

Swift:

var x = 3
switch x {
    case 1: print("x == 1")
    case 2, 4: print("x == 2 or x == 4")
    default: print("x is something else")  
}

Kotlin:

val x = 3
when (x) {
    1 -> print("x == 1")
    2, 4 -> print("x == 2 or x == 4")
    else -> print("x is something else")
}

String interpolation

Swift:

var name = "Mike"
print("Hello \(name)")

The string can also be output in a format:

let str = NSString(format:"%d , %f, %ld, %@", 1, 1.5, 100, "Hello World")
print(str)

Kotlin:

var name = "Mike"
println("Hello $name")

val str = String.format("%d, %f, %d, %s", 1, 1.5, 100, "Hello World")
print(str)

Function and Closure

The Swift function has an argument label:

func someFunction(argumentLabel parameterName: Int) {
    // In the function body, parameterName refers to the argument value
    // for that parameter.
}

while parameterName is used inside the function, argumentLabel is used by the caller.

When an argument label is not provided, parameterName also plays the role of argumentLabel.

If you don't want to specify an argument label at all, the argument label can be omitted by using underscored _.

Closure

Closure is similar to lambda in Kotlin.

A simple Swift example:

let sayHello = { (name: String) -> String in
    let result = "Hello \(name)"
    print(result)
    return result
}

sayHello("Mike")

Do the same thing in Kotlin:

val sayHello : (String) -> String = { name: String -> 
    val result = "Hello $name"
    print(result)
    result
}

sayHello("Mike")

Common:

The type can be inferred from the context.
Can be passed as arguments as another function’s parameter to achieve nested functions (high-order functions).
if the closure/lambda is the last parameter, we can put it outside the function’s parentheses. if it’s the only parameter, we don’t need to write parentheses().

Differences:

In Swift, only single expression closure can omitting the return keyword; In Kotlin, the last expression will be treated as the return value, no return keyword in lambda.
Swift has shorthand argument names such as $0, $1, $2.

Custom types

Swift	Kotlin
class	class
protocol	interface
extension	extension methods

class

The class of Swift and Kotlin looks quite the same.

The inheritance is using : and the subclass function could override the super class's function.

There is an order requirement: the class need to be put before any protocols.

The only thing different is the constructor, in swift it’s initializer:

class Person {
    let name: String
    init(name: String = "") {
        self.name = name
    }
}
let p1 = Person()
print("\(p1.name)") // default name: ""

let p2 = Person(name: "haha")
print("\(p2.name)")

In Kotlin, we could achieve the same result by writing like this:

class Person(val name: String = "") {
}
val p1 = Person()
print("${p1.name}") // default name: ""

val p2 = Person(name="haha")
print("${p2.name}")

struct

Struct is value type.

struct vs class:

class can inherit.
struct is value type, copies never share data; class is reference type, all copies will share the same instance.
class has deinit.
class instance can be let , and you can change the var property of the class.

class Person {
    var name = "Lily"
}

let p1 = Person()
p1.name = "Justin"

print("\(p1.name)")

This is ok.

But if Person is a struct:

struct Person {
    var name = "Lily"
}

let p1 = Person()
p1.name = "Justin"
// Compiler error: Cannot assign to property: `p1` is a `let` constant

When using struct, we have to use **var** p1 = Person().

protocol

protocol is just like interface in Kotlin.

We could define function and properties as contracts.

The properties could be:

protocol SomeProtocol {
    var mustBeSettable: Int { get set }
    var doesNotNeedToBeSettable: Int { get }
}

There are slight differences in protocol and interface, like the class implementing the protocol doesn’t need to use the override keyword on functions.

extension

extension is also different. In Swift, extension is more like a place to hold the functions and properties.

extension String {
    func trimmed() -> String {
        self.trimmingCharacters(in: .whitespacesAndNewlines)
    }

    mutating func trim() {
        self = self.trimmed()
    }

    var lines: [String] {
        self.components(separatedBy: .newlines)
    }
}

In Kotlin the extension method could be the top level method, just add the type before .:

fun String.someMethod() : String {
    return this.trim()
}

enum

Swift enum:

enum CompassPoint {
    case north
    case south
    case east
    case west
}

Multiple cases can be put in one line, separated by comma:

enum Planet {
    case mercury, venus, earth, mars, jupiter, saturn, uranus, neptune
}

When using the enum, we can drop the type using a shorter dot syntax:

var directionToHead = CompassPoint.west
directionToHead = .east

Swift enum has an allCases property, which exposes a collection of all the cases.

Kotlin:

enum class Direction {
    NORTH, SOUTH, WEST, EAST
}

In enum we can also define properties and functions, which is the same for Swift and Kotlin.

Optionals

While the syntax of Swift’s optional type and Kotlin’s nullable type looks similar (a question mark following the type), they are different.

Swift’s optional type is more like Java’s Optional.

You will always need to unwrap it before using the value.

var someString : String? = nil
print(someString?.count) // print nil
print(someString!.count) // Fatal error: Unexpectedly found nil while unwrapping an Optional value

When the variable has value, we want to use it:

var someString : String? = "Hello"

if (someString != nil) {
    print("\(someString) with length \(someString?.count)")
    // print: Optional("Hello") with length Optional(5)

    print("\(someString!) with length \(someString!.count)")
    // print: Hello with length 5
}

Note that when used directly, the variable will always be an Optional.

Actually in Swift there is a simpler way to do this, using if let:

if let someStringValue = someString {
    print("\(someStringValue) with length \(someStringValue.count)")
}

The someStringValue is the unwrapped value from someString, and the block is only entered when it's not nil.

In Kotlin:

var someString : String? = null
print(someString?.length) // print null
print(someString!!.length) // NullPointerException

The difference is mainly when the variable has value:

var someString : String? = "Hello"
if(someString != null) {
   print("$someString with length: ${someString.length}")  
}
// print: Hello with length: 5

In Kotlin, after we check the variable is not null, we could use the value directly, in the following code inside {} , the compiler knows the variable is not null.

If let and guard let

As we see in the above sample in the Optional section, the if let can unwrap the Optional value, and only execute the block when it has value.

The guard let does the opposite: the else block will be entered only when the value is nil .

func printSquare(of number: Int?){
    guard let number = number else {
        print("Oops we got nil")
        return
    }

    print("\(number) * \(number) is \(number * number)")
}

guard let can be used to do the argument checking and early return.

After the guard, the number is no longer optional, it has value.

Last note

I won’t suggest spending much time to learn a language syntax in every detail.

Just grab some basics and you are ready to go, you will explore more on your daily work.

Anyway, I hope this article is handy and useful to you.

References

Swift book: https://docs.swift.org/swift-book/

Android navigation with multiple back stacks

Dandan Meng — Mon, 20 Jun 2022 17:26:47 +0000

What is multiple stacks

When users navigate in the app, they may choose to go back to the previous destination.

The history is kept as a “back stack” by Android.

Sometimes we might need to maintain multiple back stacks in the app and switch between them.

A typical example is for the bottom navigation bar: each tab could have its own back stack, and when switching tabs, the history will be kept.

You may have a different design such as a side drawer, the idea is the same, but for this article, let’s take bottom navigation as the example.

The multi-stack requirements

First thing first, let’s get clear about what we need to achieve.

When the bottom navigation does not support multi-stacks, the behavior is: after switching to another tab and back, all the destinations opened on that tab are gone, only the root destination shown.

That’s also acceptable, and even mentioned as the default behavior for Android platform in material design.

But it also claims that it can be overridden when needed.

If we want to keep whatever user viewed on the previous tab, that’s a multi-stack requirement.

Often, it may not be the only requirement.

Do we want to reset the stack when people double-click the tab?

Do we want to customize the animations?

Do we want to support history between tabs? Like if tab A → B → C, when we are on C’s root screen, do we want to go back to B?

For the bottom navigation’s default behavior (if you create a new bottom nav example using Android Studio), when on the root level of a tab, when clicking the back button, it will first go back to the home tab (the first tab), and when clicking back again, the app will exit.

It applies to the fixed start destination principle.

But if you have special needs, you might also consider how to customize that.

When you go deep dive to the implementations, you will also find details on how to push to the specific stack and how to pop destination out.

Let’s list our requirements here:

Maintain multiple stacks.
Switching tabs: by manually clicking tab or some interactions on the other tab. i.e. Dashboard to a specific content tab.
Push/pop destinations.
Reselect tab will reset the stack to root level. (clear history.)
Transition animations.
Tab history.

Technical Background

It’s important to know what your “destination” is.
For composable or fragments, the solutions could be very different.

For this article’s scope, let’s focus on a traditional android app built using Activity and Fragments.

Fragment lifecycle

The fragment’s lifecycle is quite important to check about, as the Fragment’s lifecycle is related to whether we will need to care about state loss or refreshing action, for example, the re-creation of the ViewModel.

Let’s recap on Fragment’s lifecycle callbacks.

When would Fragment onDestroy called?

If the replace transaction is without addToBackStack() .
when the fragment is removed or popped out by popBackStack().

When a replace transaction is called with addToBackStack(), the old fragment will be pushed into the stack, and the lifecycle is only reached onDestroyView().

When the top one popped out from the back stack, the old fragment’s instance is still the same. The come-to-show fragment’s lifecycle starts with onCreateView().

This is what we expected for a single back stack.

If the project is using ViewModel, the Fragment’s ViewModel’s lifecycle is also aligned with the Fragment.

Whenever the Fragment’s onDestroy() is called, the ViewModel’s onCleared() is called.

We can keep variables we cared about in the saved instance bundle, or by using SavedStateHandle. But if the fragment is not destroyed, we get everything for free.

Navigation Libraries/ Possible Solutions

To compare different solutions, I put some samples together.
See my demo: https://github.com/mengdd/bottom-navigation-samples

Jetpack navigation component

official site: https://developer.android.com/guide/navigation

Even in the FragmentManager’s doc it’s recommended to use the navigation library to manage app’s navigation.

The multiple back stack support added in Navigation 2.4.0-alpha01 and Fragment 1.4.0-alpha01.

Tried the demo, it’s quite simple and clean, and the app does not need extra code to get this.

We can check the ideas in this article: https://medium.com/androiddevelopers/multiple-back-stacks-b714d974f134

Pros:

Most well-known. It’s the official library built by Google.
Safe args supported.
NavigationController supports popping to a specific destination.
Can work together with the Compose navigation library.

Cons:

Multi-stack support: When switching bottom tabs, the fragments on the previous tab will be destroyed, when navigate back, they will all be re-created. The page may be refreshed again.
Because each tab should be a nested navigation graph, the xml navigation graph files feels like boilerplate code to maintain, especially for common destinations.

FragmentManager

If we are doing more customization we could also try to build the multi stack solution by using FragmentManager’s new APIs.

As in this doc suggested:

FragmentManager allows you to support multiple back stacks with the saveBackStack()
and restoreBackStack( methods. These methods allow you to swap between back stacks by saving one back stack and restoring a different one.

Here we can find that it’s what navigation component is using under the hood.

And the why the fragments are all destroyed:

saveBackStack() works similarly to calling popBackStack() with the optional name
parameter: the specified transaction and all transactions after it on the stack are popped. The difference is that saveBackStack() saves the state of all fragments in the popped transactions.

Pros:

Fine control. Developers get more control and are aware of what is going on.
Proper if we are working on a project without any navigation library. We don’t need to migrate a lot of code to a new navigation library.

Cons:

Lots of fragment transaction boilerplate code.
Same as navigation components: Fragments on the old tab will be destroyed and re-created.

Enro

https://github.com/isaac-udy/Enro

For large projects with multiple modules, I really recommend this navigation library.

It helps to decouple the modules dependencies.

For multi-stack demo: https://github.com/mengdd/bottom-navigation-samples/tree/main/enro-fragment-multi-stack-sample

Pros:

Based on annotation, you only need minimal code to do the navigation, making navigation easy like a breeze.
Designed for multi-module projects, decoupling modules.
Can get navigation handle in ViewModel.
Easy to pass type safe arguments and get results.
Compose Support.
Having a companion test tool for Unit Test.

Cons:

Not that well-known. Need to convince others to learn and apply this.
For Fragments’ multi-stack support: can not reset the stack when reselecting the tab. And it is hard to customize this.

Simple-stack

https://github.com/Zhuinden/simple-stack

I would suggest this article for the multi-stack solution using simple-stack: https://zhuinden.medium.com/creating-a-bottomnavigation-multi-stack-using-child-fragments-with-simple-stack-c73c1ca3bbd4

At the beginning the author showed a demo using child fragments.

This is another idea if we want to implement the multi-stack by ourselves.

After I tried the multi-stack demo provided by simple-stack, I found that actually more code is required to let any fragment gain the instance of each tab’s local stack.

In that way we could push/pop the detail fragment.

Pros:

The author is quite active in the community, so there are a bunch of speeches and articles for the simple-stack library. Good community support and learning resources.
Multi-stack support: keep fragments alive.
Can control or clear the history.
Compose Support with extensions.

Cons:

If your bottom tab is in an Activity layout, when using simple-stack’s multi-stack solution, you have to move things into a RootFragment.
The multi-stack sample provided by the author is quite simple. Need to write some code to retrieve the correct stack instance to push/pop a fragment to/from the current stack.

Other libraries

There are other libraries designed only for multi-stack navigation.

Such as:

The samples are just along the repos.

Pros:

Simple solutions with only a few classes. We could even copy them to our codebase to customize.
The change scope could be limited only to the bottom navigation part.

Cons:

The libraries are not so well-known, and have the risk of not being maintained anymore.
Might not be able to work together with other navigation solutions, like Navigation Components. If the project is aiming to apply some nice navigation library in the future, we have to touch this bottom navigation part again.

Conclusions

Possible solutions for android multi-stack navigation:

Solution	Popular	A completed suite of navigation solution	Actively Maintained	Supporting clear stack history	Fragment kept, not destroyed	Multi-modules supported	Compose Extensions
Jetpack Navigation Components	Official, Most Well-known navigation library	Yes	Yes	Yes	No	Yes	Yes
Fragment Manager	Android SDK	-	Yes	Yes	No	No	-
Enro	Star: 188	Yes	Yes	No	Yes	Yes	Yes
Simple Stack	Star: 1.2k	Yes	Yes	Yes	Yes	Yes	Yes
Child Fragments	Android SDK	-	Yes	Yes	Yes	No	-
JetradarMobile/android-multibackstack	Star: 224	No	No	Yes	No	No	-
DimaKron/Android-MultiStacks	Star: 32	No	Not sure	Yes	Yes	No	-

Note:

A Completed suite of navigation solution means the solution can be applied to the whole app as a way to navigate, not just to solve the multi-stack navigation. Here I skipped the ways using Android SDK’s fragment manager or child fragments. Of course in your whole app you can depend on them to do all the navigations.
Fragment kept: means the fragments in stack will not be destroyed when pushing back to the back stack, or switching the bottom tabs. Even though the fragments will be recreated after switching back, we need extra work to cache what state we had before.

References:

The anti-patterns in Android codebase and why I hate them

Dandan Meng — Tue, 14 Jun 2022 17:27:16 +0000

As developers, we work with the code everyday.
Mostly we will be working on some existing code created by others, or as we always like to refer to it as “legacy code”.

Actually, no matter if the codebase is very old or pretty new, there are always some anti-patterns to complain about. Perfect codebase is quite rare.

In this article I want to list something I hate most in any android codebase, only biased opinions from a normal developer. So feel free to disagree.

No. 1 No Kotlin

If a project is purely java and still in an active development state, I don't believe it has the ambition to embrace all the new technologies.

I don't think working on this project is a good choice for younger developers who are just entering the Android world.

I would suggest we migrate to Kotlin at least for new features or new code we are touching, bit by bit.

If we can't do even this, run from this project.

No. 2 No DI framework

Well, it is 2022 already.

For the Android world, Dependency Injection is not a new topic.
In the old days we had dagger, and now Hilt makes things even more easier and simpler.

If you don't like to follow Google's recommendations you could also choose from many third party solutions such as Koin.

There are so many options to choose from and you like neither of them.

The consequences may be:

There are many boilerplate codes just to assemble dependency instances.
Your singleton instances might be a disaster to look at and maintain.
If you are using ViewModel, you are writing a lot of Factories to create ViewModels.

No. 3 object with global variables

This can be another broader topic whether singleton is a pattern/anti-pattern.

Yes, singleton is useful.

Only when you are clear about the boundaries.
When you are sure if it's necessary.
Don’t over use it for everything.

It's even worse when the object has public vars in it.
Everyone at every place can read and write it.
Yes, it's global variables.

It feels like a key to the devil's gate.

You can't image the tricky usages, and it's hard to debug and maintain.

The object is bad for the following reasons:

It's hard to be unit tested.
Sometimes you have to write ugly code to assign value to it and then set it to null.

It's only nice when there are only some utilities functions inside it.
But in the Kotlin world we also have other choices such as the top-level functions and extensions functions.

No. 4 More than 10 Feature Toggles and A/B Tests

If you are a product manager you might have strong reasons for all the feature toggles and A/B Tests. And I'm not challenging the values of them.

As mentioned from the beginning, I'm just a normal developer who deals with this if-else nightmare.

Even if I totally understand and agree with the business values, it can not stop me from hating them.

Implementing new features with the feature toggle could be trivial work as you need to keep everything as before when the toggle is off.

If developers do this on a large scale, like copying the whole file and giving a different name, there could be some duplications. And other changes (for other features) might need to apply to both versions.

If developers choose to do this on a small scale, like the if-else on several lines. They have to be precise on every change.
There will be multiple if-else.

Implementing compatibility is not fun.
And it generates code smells.
If the developer is very patient, he will add unit test cases for both toggle on and off scenarios. But he may also have missed some conditions, if the old code is not test covered.
And often, there will be no refactoring.
What's the point of refactoring the code we might not need soon?

It is also annoying for QA's work as every feature needs to test more flows, which not only means feature A's on and off, but also feature B on feature A's on and off.

Yup, things would definitely get worse when our feature toggles nested.
They just have the complex relationship you need to explain to QA and yourself. If more than 2 feature toggles are nested, I think it's time to talk to your PO to remove one.

No. 5 Legacy dependencies

Some libraries were really popular and now are deprecated.

I'm looking at you, ButterKnife.

This is a famous one and I believe it’s quite rare to see it from any android project.

But in reality we may encounter others.

Also, there may be some 3rd-party libraries that are not maintained anymore.

if you have this flag in your gradle.properties:

android.enableJetifier=true

You can run this task to check if any of your dependencies are still using the legacy support library rather than AndroidX:

./gradlew checkJetifier

If you find some libraries, I bet they have not been updated for years.

Please evaluate whether you can find a better replacement.

No. 6 Misused Inheritance

It's really painful to see a codebase that has a bunch of base classes for its Activities, Fragments, and ViewModels.

A bunch means several, or, a lot.

For example, between the feature's Fragment and AndroidX's Fragment, there may be 2 or 3 parent fragments that play their mysterious roles.

When a developer wants to add a new Fragment, he might get confused whether to inherit from a base Fragment, and which “base” to use.

And the same for ViewModel. Do you really need a ViewModel to hold the Loading state and another ViewModel to hold the navigation variable?
So a new ViewMoel has to decide if it needs to reuse them all or do things by itself.

Normally, the BaseFragments and BaseViewModels will have some base type defined as generic types. Or even worse, you have BaseUseCase.

Please try to get rid of this inheritance net, it makes navigating in IDE harder than before.

We should minimize the complexity, isn't it?

I hope you always remember composition over inheritance.

No. 7 Interface for everything

You don't need interfaces for everything.

If the interface has only 1 implementation, there is no reason to keep it.

Maybe some developer designed this for good intention, but we only ended up with a lot of boilerplate code.

If the other implementation is for the test, let's review whether it's a real case or just not using any mock framework yet.

No. 8 EventBus Style

EventBus is a famous library.
It is also well-known as an anti-pattern, because it's so free, you can publish one thing and receive it anywhere. Making things unorganized.

The overuse of EventBus in a codebase could be a disaster.
It will decrease the intention to write better structured code.

Sometimes we are writing “EventBus code” even without actually using the Library.
I hope it’s applied only for a few cases, not a common pattern in your codebase.

Summing up

That’s it for now.

Hope this article is helpful to you. You may find we are suffering with the same issues.
Or you get to know why developers in your team are not that happy or struggling with their hair in hand everyday.

Let’s make our life easier.