Row’s Quantum Soaker

In the dimly lit basement of an old Victorian house, Dr. Rowan “Row” Hawthorne tinkered with wires, circuits, and vials of iridescent liquid. His unruly hair stood on end, a testament to his relentless pursuit of scientific breakthroughs. Row was no ordinary scientist; he was a maverick, a dreamer, and a little bit mad.

His obsession? Teleportation. The ability to traverse space instantaneously fascinated him. He’d read every paper, dissected every failed experiment, and even tried meditating in a sensory deprivation tank to unlock the secrets of the universe. But progress remained elusive.

One stormy night, as rain drummed against the windowpanes, Row had a revelation. He stared at the super soaker lying on his cluttered workbench. Its neon green plastic seemed out of place among the high-tech equipment. Yet, it held promise—a vessel for his audacious experiment.

Row connected the soaker to his quantum teleporter, a contraption that looked like a cross between a particle accelerator and a steampunk time machine. He filled the soaker’s reservoir with the iridescent liquid—a concoction of exotic particles and moonlight. The moment of truth had arrived.

He aimed the soaker at a potted fern in the corner of the room. The fern quivered, its fronds trembling with anticipation. Row squeezed the trigger, and a beam of shimmering energy shot out, enveloping the plant. The fern vanished, leaving behind a faint echo of chlorophyll.

Row’s heart raced. He stepped onto the teleporter’s platform, gripping the soaker like a futuristic weapon. The room blurred, and he felt weightless. In an instant, he materialized in the heart of the United Nations General Assembly—an audacious move, even for a scientist.

Diplomats gasped as Row stood before them, dripping wet and clutching the super soaker. The UN Secretary-General, a stern-faced woman named Elena Vargas, raised an eyebrow. “Who are you, and why are you interrupting—”

Row cut her off. “Ladies and gentlemen, I bring you the solution to global conflict.” He waved the soaker dramatically. “This humble water gun is now a weapon of peace.”

The assembly erupted in laughter. Row ignored them. “This device teleports emotions,” he declared. “Love, empathy, forgiveness—they’re all encoded in these water molecules. Imagine if we could share these feelings across borders, erase hatred, and build bridges.”

Elena Vargas leaned forward. “You’re insane.”

“Am I?” Row adjusted his lab coat. “Watch this.” He sprayed a mist of teleportation-infused water into the air. The room shimmered, and suddenly, delegates from warring nations embraced. Tears flowed, and old grievances dissolved. The super soaker had become a conduit for understanding.

Word spread. Row’s Quantum Soaker became a symbol of hope. He traveled to conflict zones, dousing soldiers and rebels alike. The Middle East, Kashmir, the Korean Peninsula—all witnessed miraculous transformations. The soaker’s payload wasn’t water; it was humanity’s shared longing for peace.

As the Nobel Committee awarded Row the Peace Prize, he stood on the podium, soaking wet, and addressed the world. “We’ve spent centuries fighting over land, resources, and ideologies,” he said. “But what if we fought for compassion, kindness, and understanding instead?”

And so, the super soaker became a relic of a new era. Rows of them lined the halls of diplomacy, ready to douse flames of hatred. The world learned that sometimes, the most powerful inventions emerge from the unlikeliest of sources—a mad scientist’s basement, a child’s toy, and a dream of a better tomorrow.

And Dr. Rowan Hawthorne? He continued his experiments, pushing the boundaries of science. But he never forgot the day he wielded a super soaker and changed the course of history—one teleportation at a time.

Structural Design Patterns in Android Kotlin

Structural design patterns are all about how you compose objects and classes to obtain new functionality. They help you simplify the design by finding a simple way of realizing relationships between entities ¹. In this blog post, we will cover three common structural design patterns: adapter, decorator and facade. We will also see how to implement them in Kotlin using some of its features such as extension functions, data classes and delegation.

Adapter Pattern

The adapter pattern allows you to convert the interface of a class into another interface that clients expect. It lets you make incompatible classes work together by wrapping one of them with an adapter class that implements the desired interface ². For example, suppose you have a class that represents a book:data class Book(val title: String, val author: String, val pages: Int) Copy

And you have another class that represents a library:class Library { private val books = mutableListOf<Book>() fun addBook(book: Book) { books.add(book) } fun getBooks(): List<Book> { return books } } Copy

Now, suppose you want to use a third-party library that provides a function to print a list of books in a nice format. However, this function expects a list of objects that implement the Printable interface:interface Printable { fun print(): String } Copy

How can you make your Book class compatible with this function? One way is to use the adapter pattern. You can create an adapter class that implements Printable and wraps a Book object:class BookAdapter(private val book: Book) : Printable { override fun print(): String { return "Title: ${book.title}, Author: ${book.author}, Pages: ${book.pages}" } } Copy

Then, you can use this adapter class to convert your list of books into a list of printable objects:val library = Library() library.addBook(Book("The Lord of the Rings", "J.R.R. Tolkien", 1178)) library.addBook(Book("Harry Potter and the Philosopher's Stone", "J.K. Rowling", 223)) library.addBook(Book("The Hitchhiker's Guide to the Galaxy", "Douglas Adams", 180)) val printables = library.getBooks().map { book -> BookAdapter(book) } printBooks(printables) // This is the third-party function that expects a list of Printable objects Copy

Alternatively, you can use an extension function to achieve the same result without creating an adapter class:fun Book.toPrintable(): Printable { return object : Printable { override fun print(): String { return "Title: ${this@toPrintable.title}, Author: ${this@toPrintable.author}, Pages: ${this@toPrintable.pages}" } } } val printables = library.getBooks().map { book -> book.toPrintable() } printBooks(printables) Copy

The advantage of using an extension function is that it reduces the amount of code and classes needed. However, it may not be suitable for complex scenarios where you need more control over the adaptation logic.

Decorator Pattern

The decorator pattern allows you to add new behavior or functionality to an existing object without modifying its structure or subclassing it. It lets you wrap an object with another object that implements the same interface and delegates all the requests to the original object while adding some extra logic before or after ². For example, suppose you have an interface that represents a coffee:interface Coffee { fun cost(): Double fun description(): String } Copy

And you have a concrete class that implements this interface:class Espresso : Coffee { override fun cost(): Double { return 1.5 } override fun description(): String { return "Espresso" } } Copy

Now, suppose you want to add some extra ingredients to your coffee, such as milk, whipped cream or caramel. One way is to use the decorator pattern. You can create an abstract class that implements Coffee and wraps another Coffee object:abstract class CoffeeDecorator(private val coffee: Coffee) : Coffee { override fun cost(): Double { return coffee.cost() } override fun description(): String { return coffee.description() } } Copy

Then, you can create concrete subclasses that extend this abstract class and add their own logic:class Milk(private val coffee: Coffee) : CoffeeDecorator(coffee) { override fun cost(): Double { return super.cost() + 0.5 } override fun description(): String { return "${super.description()}, Milk" } } class WhippedCream(private val coffee: Coffee) : CoffeeDecorator(coffee) { override fun cost(): Double { return super.cost() + 0.7 } override fun description(): String { return "${super.description()}, Whipped Cream" } } class Caramel(private val coffee: Coffee) : CoffeeDecorator(coffee) { override fun cost(): Double { return super.cost() + 0.8 } override fun description(): String { return "${super.description()}, Caramel" } } Copy

Then, you can use these decorator classes to create different combinations of coffee:val espresso = Espresso() println("${espresso.description()} costs ${espresso.cost()}") // Espresso costs 1.5 val espressoWithMilk = Milk(espresso) println("${espressoWithMilk.description()} costs ${espressoWithMilk.cost()}") // Espresso, Milk costs 2.0 val espressoWithMilkAndWhippedCream = WhippedCream(espressoWithMilk) println("${espressoWithMilkAndWhippedCream.description()} costs ${espressoWithMilkAndWhippedCream.cost()}") // Espresso, Milk, Whipped Cream costs 2.7 val espressoWithMilkAndWhippedCreamAndCaramel = Caramel(espressoWithMilkAndWhippedCream) println("${espressoWithMilkAndWhippedCreamAndCaramel.description()} costs ${espressoWithMilkAndWhippedCreamAndCaramel.cost()}") // Espresso, Milk, Whipped Cream, Caramel costs 3.5 Copy

Alternatively, you can use delegation instead of inheritance to implement the decorator pattern in Kotlin. You can create an interface that represents a decorator:interface Decorator<T> : T { val delegate: T } Copy

Then, you can create concrete classes that implement this interface and delegate all the requests to the wrapped object while adding their own logic:class Milk(override val delegate: Coffee) : Decorator<Coffee>, Coffee by delegate { override fun cost(): Double { return delegate.cost() + 0.5 } override fun description(): String { return "${delegate.description()}, Milk" } } class WhippedCream(override val delegate: Coffee) : Decorator<Coffee>, Coffee by delegate { override fun cost(): Double { return delegate.cost() + 0.7 } override fun description(): String { return "${delegate.description()}, Whipped Cream" } } class Caramel(override val delegate: Coffee) : Decorator<Coffee>, Coffee by delegate { override fun cost(): Double { return delegate.cost() + 0.8 } override fun description(): String { return "${delegate.description()}, Caramel" } } Copy

Then, you can use these decorator classes to create different combinations of coffee as before:val espresso = Espresso() println("${espresso.description()} costs ${espresso.cost()}") // Espresso costs 1.5 val espressoWithMilk = Milk(espresso) println("${espressoWithMilk.description()} costs ${espressoWithMilk.cost()}") // Espresso, Milk costs 2.0 val espressoWithMilkAndWhippedCream = WhippedCream(espressoWithMilk) println("${espressoWithMilkAndWhippedCream.description()} costs ${espressoWithMilkAndWhippedCream.cost()}") // Espresso, Milk, Whipped Cream costs 2.7 val espressoWithMilkAndWhippedCreamAndCaramel = Caramel(espressoWithMilkAndWhippedCream) println("${espressoWithMilkAndWhippedCreamAndCaramel.description()} costs ${espressoWithMilkAndWhippedCreamAndCaramel.cost()}") // Espresso, Milk, Whipped Cream, Caramel costs 3.5 Copy

The advantage of using delegation is that it avoids creating unnecessary subclasses and makes the code more concise and readable.

Facade Pattern

The facade pattern simplifies the interaction with a complex system or library by providing a unified and easy-to-use interface. It hides the details and implementation of the system from the clients and exposes only the essential functionality. For example, suppose you have a complex library that offers various functions for image processing:class ImageProcessingLibrary { fun loadBitmap(path: String): Bitmap { ... } fun resizeBitmap(bitmap: Bitmap, width: Int, height: Int): Bitmap { ... } fun cropBitmap(bitmap: Bitmap, x: Int, y: Int, width: Int, height: Int): Bitmap { ... } fun applyFilter(bitmap: Bitmap, filter: Filter): Bitmap { ... } fun saveBitmap(bitmap: Bitmap, path: String) { ... } // ... more functions } Copy

Using this library directly may be cumbersome and error-prone for the clients. They need to know how to use each function correctly and in what order. For example, if they want to load an image from a file, resize it, apply a filter and save it back to another file, they need to write something like this:val library = ImageProcessingLibrary() val bitmap = library.loadBitmap("input.jpg") val resizedBitmap = library.resizeBitmap(bitmap, 300, 300) val filteredBitmap = library.applyFilter(resizedBitmap, Filter.GRAYSCALE) library.saveBitmap(filteredBitmap, "output.jpg") Copy

To make this task easier and more convenient, you can use the facade pattern. You can create a class that acts as a facade for the library and provides a simple interface for common operations:class ImageProcessor(private val library: ImageProcessingLibrary) { fun processImage(inputPath: String, outputPath: String, width: Int, height: Int, filter: Filter) { val bitmap = library.loadBitmap(inputPath) val resizedBitmap = library.resizeBitmap(bitmap, width, height) val filteredBitmap = library.applyFilter(resizedBitmap, filter) library.saveBitmap(filteredBitmap, outputPath) } // ... more functions for other operations } Copy

Then, the clients can use this facade class to perform the same operation with less code and complexity:val processor = ImageProcessor(ImageProcessingLibrary()) processor.processImage("input.jpg", "output.jpg", 300, 300, Filter.GRAYSCALE) Copy

The advantage of using the facade pattern is that it reduces the coupling between the clients and the system or library. It also improves the readability and maintainability of the code by encapsulating the logic and details of the system or library in one place.

Conclusion

In this blog post, we have learned about three common structural design patterns: adapter, decorator and facade. We have seen how they can help us simplify the design and implementation of our Android applications by composing objects and classes in different ways. We have also seen how to implement them in Kotlin using some of its features such as extension functions, data classes and delegation. We hope you have enjoyed this post and found it useful. If you have any questions or feedback, please feel free to leave a comment below. Happy coding!

Apple 2024 Mac Mini Desktop Computer with M4 chip with 10‑core CPU and 10‑core GPU: Built for Apple Intelligence, 16GB Unified Memory, 256GB SSD Storage, Gigabit Ethernet. Works with iPhone/iPad

(50)

$559.00 (as of November 21, 2024 13:41 GMT -05:00 - )

Amazon Fire 10 Kids tablet (newest model) ages 3-7 | Bright 10.1" HD screen with ad-free content and parental controls included, 13-hr battery, 32 GB, Blue

(3336)

$109.99 (as of November 21, 2024 13:41 GMT -05:00 - )

Amazon Fire HD 8 Kids tablet, ages 3-7. Top-selling 8" kids tablet on Amazon - 2022. Ad-free content with parental controls included, 13-hr battery, 64 GB, Blue

(8609)

$179.99 (as of November 21, 2024 13:41 GMT -05:00 - )

Amazon Fire HD 10 Kids Pro tablet (newest model) ages 6-12 | Bright 10.1" HD screen | Slim case for older kids, ad-free content, parental controls, 13-hr battery, 32 GB, Nebula

(3850)

$109.99 (as of November 21, 2024 13:41 GMT -05:00 - )

HP Chromebook 14 inch Laptop, FHD Display, Intel N100, 4 GB RAM, 64 GB eMMC, Intel UHD Graphics, Chrome OS 14a-nf0009nr (2024)

(72)

$199.99 (as of November 21, 2024 13:41 GMT -05:00 - )

Creational Design Patterns in Kotlin Android

Creational design patterns are a set of solutions to common software development problems that deal with how objects are being created. Using such patterns will ensure that your code is flexible and reusable, and that you avoid hard-coded dependencies and tight coupling between classes.

In this blog post, I will show you some of the most important and widely used creational design patterns in Kotlin Android. You will learn how to apply these patterns to your projects and how they can help you write better and more maintainable code. I will cover four creational design patterns:

Factory and abstract factory (provider model) method
Singleton
Builder
Dependency injection

Factory and abstract factory (provider model) method

The factory method pattern defines an interface for creating an object, but lets subclasses decide which class to instantiate. The abstract factory pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes.

These patterns are useful when you want to decouple the creation of objects from their usage, or when you want to provide different implementations of the same interface depending on some conditions. For example, you can use these patterns to create different types of views or fragments based on the device configuration or user preferences.

In Kotlin, you can use the provider model to implement these patterns. The provider model is a way of creating objects using lambda expressions or function references that act as factories. For example, you can use a provider function to create different types of fragments based on a parameter:

// An interface for fragments that display some content interface ContentFragment { fun showContent(content: String) } // A concrete implementation of ContentFragment that shows content in a text view class TextFragment : Fragment(), ContentFragment { private lateinit var textView: TextView override fun onCreateView( inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle? ): View? { return inflater.inflate(R.layout.text_fragment, container, false) } override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) textView = view.findViewById(R.id.text_view) } override fun showContent(content: String) { textView.text = content } } // Another concrete implementation of ContentFragment that shows content in a web view class WebFragment : Fragment(), ContentFragment { private lateinit var webView: WebView override fun onCreateView( inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle? ): View? { return inflater.inflate(R.layout.web_fragment, container, false) } override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) webView = view.findViewById(R.id.web_view) } override fun showContent(content: String) { webView.loadUrl(content) } } // A provider function that returns a ContentFragment based on a parameter fun provideContentFragment(type: String): ContentFragment = when (type) { "text" -> TextFragment() "web" -> WebFragment() else -> throw IllegalArgumentException("Unknown type: $type") }

Singleton

The singleton pattern ensures that a class has only one instance and provides a global point of access to it. This pattern is useful when you want to have a single source of truth for some data or functionality in your app. For example, you can use this pattern to create a repository that handles data access from different sources.

In Kotlin, you can use the object declaration to create a singleton class. The object declaration combines a class declaration and a single instance of that class into one expression. For example, you can use an object declaration to create a news repository that fetches data from a remote data source:

// A singleton class that acts as a repository for news data object NewsRepository { // A reference to the remote data source private val newsRemoteDataSource = // getDataSource() // A flow that emits the latest news from the remote data source val latestNews: Flow<List<ArticleHeadline>> = newsRemoteDataSource.latestNews // A function that returns the details of an article by its id suspend fun getArticleDetails(id: String): ArticleDetails { return newsRemoteDataSource.getArticleDetails(id) } }

Builder

The builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. This pattern is useful when you want to create objects with many optional parameters or when you want to have more control over how the object is constructed. For example, you can use this pattern to create an alert dialog with various options.

In Kotlin, you can use named arguments and default values to implement this pattern. Named arguments allow you to specify the name of a parameter when calling a function, which makes the code more readable and avoids errors when there are many parameters. Default values allow you to omit some parameters when calling a function if they have a predefined value. For example, you can use named arguments and default values to create an alert dialog builder class:

// A class that represents an alert dialog with various options class AlertDialog( val title: String, val message: String, val positiveButton: String = "OK", val negativeButton: String? = null, val icon: Int? = null, val onPositiveClick: () -> Unit = {}, val onNegativeClick: () -> Unit = {} ) { // A function that shows the alert dialog on the screen fun show() { // Create and display an alert dialog using the Android SDK ... } } // A builder class that creates an AlertDialog instance using named arguments and default values class AlertDialogBuilder { // A function that returns an AlertDialog instance with the given parameters fun build( title: String, message: String, positiveButton: String = "OK", negativeButton: String? = null, icon: Int? = null, onPositiveClick: () -> Unit = {}, onNegativeClick: () -> Unit = {} ): AlertDialog { return AlertDialog( title = title, message = message, positiveButton = positiveButton, negativeButton = negativeButton, icon = icon, onPositiveClick = onPositiveClick, onNegativeClick = onNegativeClick ) } }

Dependency injection

The dependency injection pattern is a technique whereby one object supplies the dependencies of another object. A dependency is an object that can be used (a service). An injection is the passing of a dependency to a dependent object (a client) that would use it.

This pattern is useful when you want to reduce coupling and increase testability between classes by delegating the responsibility of creating and providing dependencies to another object or framework. For example, you can use this pattern to inject dependencies into your activities or view models.

In Kotlin Android, you can use frameworks like Dagger or Koin to implement this pattern. These frameworks provide annotations or DSLs to define dependencies and inject them into your classes. For example, you can use Koin to inject dependencies into your view model:

// A class that represents a user profile view model with some dependencies class UserProfileViewModel( private val userRepository: UserRepository, private val analyticsService: AnalyticsService ) : ViewModel() { // Some view model logic using userRepository and analyticsService ... } // A module that defines dependencies using Koin DSL val appModule = module { // Define UserRepository as a singleton using factory function single<UserRepository> { UserRepositoryImpl(get()) } // Define AnalyticsService as a singleton using constructor injection single<AnalyticsService> { AnalyticsServiceImpl() } // Define UserProfileViewModel using constructor injection viewModel { UserProfileViewModel(get(), get()) } } // Start Koin with appModule in Application class class MyApp : Application() { override fun onCreate() { super.onCreate() startKoin { androidContext(this@MyApp) modules(appModule) } } } // Get UserProfileViewModel instance using Koin extension function in Activity class class UserProfileActivity : AppCompatActivity() { // Inject UserProfileViewModel private val viewModel by viewModel<UserProfileViewModel>() override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_user_profile) // Use viewModel ... } }

Conclusion

In this blog post, you learned how to use creational design patterns in Kotlin Android. You learned how to apply these patterns to your projects and how they can help you write better and more maintainable code. You learned how to use factory and abstract factory (provider model) method, singleton, builder, and dependency injection patterns.

If you want to learn more about design patterns and other Kotlin features for Android development, check out these resources:

I hope you enjoyed this blog post and found it useful. Happy coding! 😊