DEV Community: Zaccheaus Amenya

The AI Void Comes to Nairobi: What One Engineer's Emptiness Tells Us About Africa's Looming Jobs Reckoning

Zaccheaus Amenya — Tue, 03 Mar 2026 13:53:29 +0000

I stumbled on a blog post by a software engineer named Buono, a 40-something who spent years grinding toward his dream of remote work and location independence. He finally landed the IT role. Then AI hit.

He barely writes code anymore. He writes prompts.

"If tests pass, ship it."

On the side, he built a full pictogram-based English vocab app, Pikutan, in two weeks. Google Auth, payments, analytics, cloud deployment. Work that would have taken him the better part of a year just a decade ago. First reaction? Pure hype. Then the crash. That quiet, creeping emptiness.

"I reached the engineering level I dreamed of at 30… but AI did the heavy lifting. What was the point?"

That line stopped me cold. Because here in Nairobi, Buono's story isn't just one man's mid-life crisis. It's a preview of what millions across Africa are about to face, and the clock is ticking faster than most people realize.

The African Reality Check

Let's start with the numbers, because they're not abstract.

A December 2025 ODI report, the first data-driven analysis of its kind using Kenya's own household survey data, found that approximately 2.5 million Kenyans currently work in roles with high or significant exposure to generative AI automation. The most vulnerable group: around 400,000 clerical and knowledge-intensive workers: bookkeepers, payroll clerks, data entry operators, earning above the national median wage and concentrated in urban centers like Nairobi. These aren't low-skill, low-pay jobs. These are the roles that educated young Kenyans have been chasing.

Meanwhile, a separate report by Caribou and Genesis Analytics, in partnership with the Mastercard Foundation, found that 40% of tasks in Africa's BPO and tech-outsourcing sectors could shift dramatically by 2030. Customer Experience roles, which make up 44% of current BPO employment, are especially exposed, with roughly half of their tasks automatable.

And this is happening at precisely the worst moment. According to the World Bank and the African Development Bank, 10 to 12 million young Africans enter the labor market every single year, with only around 3 million formal jobs are created annually. That structural gap existed before AI. AI just multiplied the pressure.

Our education systems, still largely built on rote learning, standardized exams, and a narrow set of "safe" career tracks in engineering, accounting, law and IT are producing graduates into a market that is quietly moving the goalposts. The degrees that felt like insurance in 2015 are becoming the risky bets of 2030.

The Void Is Already Here

Buono's emptiness isn't his alone. It's spreading.

Friends in Nairobi's BPO sector, banking operations, teaching, and entry-level legal work are telling me the same thing: "I'm orchestrating AI now. I'm not really doing the work anymore." The dopamine of quick AI-assisted wins is real. But so is the identity crisis that quietly follows: the unsettling feeling that the skills you worked years to develop are becoming the thing a prompt can replace in seconds.

This isn't technophobia. It's a rational response to a genuine disruption. When your professional identity is tied to a skill, and that skill is suddenly something a machine handles in the background while you review the output, and the question "What was the point?" is not self-pity. It's an honest reckoning.

But Africa Is Already Moving, and That Matters

Here's where the story shifts.

Last month, the Nairobi AI Forum 2026 (February 9–10) brought together governments, private sector leaders, development partners, and tech innovators right here in Kenya. Out of that forum, the African Development Bank Group and UNDP announced the AI 10 Billion Initiative, a co-designed partnership targeting up to $10 billion in mobilized capital by 2035, aimed at unlocking up to 40 million new jobs across the continent through responsible, locally-owned AI adoption.

The initiative isn't about replacing African workers with imported AI systems. It's explicitly oriented around building AI that serves African priorities, voice AI in local languages, agricultural tools that keep farmers in the loop, climate resilience systems, health diagnostics built with human judgment as a non-negotiable component.

Kenya's own National AI Strategy 2025–2030 directly confronts the displacement risk and is attempting to get ahead of it, calling for digital infrastructure investment, reformed education tracks, and AI literacy at scale.

These aren't just policy documents gathering dust. They're signals that the continent is taking the conversation seriously. Implementation speed, however, will determine whether that matters.

What This Means for Three Groups Right Now

For Current Employees: The Buono Cohort

Your role may not disappear tomorrow. But the moat around your skillset is narrowing. The fix isn't panic-quitting. It's becoming the person who can orchestrate AI and bring what AI still cannot, which is local context, physical judgment, taste, ethical reasoning under uncertainty, and genuine human relationships. The professionals who will thrive aren't the ones who resist AI, or the ones who blindly defer to it. They're the ones who know exactly when to trust it and when to push back.

For the education system and new graduates

We have to stop training people to compete with machines at the tasks machines do best. Robotics clubs in secondary schools. Fab labs in universities. Mandatory AI literacy woven into every curriculum, not as an elective, but as foundational as mathematics. The goal is not to produce people who use AI tools. It's to produce people who can think critically about AI outputs, design systems around human needs, and build things AI cannot imagine without human direction.

For society at large

If we get this wrong, the gap between the AI-fluent urban elite and everyone else grows into a chasm. The informal economy, which absorbs 70 to 80 percent of African workers, doesn't disappear; it gets squeezed indirectly as formal sector disruption ripples outward. Youth frustration grows. Mental health strain rises.

If we get it right, we leapfrog. We become the continent that demonstrates, at scale, what human-centered AI actually looks like when it's designed for people who were never the default user.

What I'm Doing and What I'm Telling My Friends

I'm taking Buono's eventual conclusion seriously: use AI ruthlessly for speed and output, but invest your evenings and weekends in the zones AI cannot reach.

For me, that means five to ten hours a week building skills in physical making, community storytelling, and local problem-solving, the work that requires you to be present, to understand context that no training dataset captures, to make judgment calls that involve real stakes and real people.

And it means pushing, through whatever voice I have, for reskilling programs that are genuinely useful, not just resume padding. For our institutions to treat the $10 billion initiative as a floor, not a ceiling. For our universities to catch up with the labor market before another generation graduates into a gap that didn't exist when they enrolled.

Buono ended his piece stepping into electronics and YouTube, the physical and the authentic. I'm stepping into that same energy, right here in Nairobi.

The Question I'm Sitting With

Buono said it plainly: "The skills that feel safe right now might not be safe for long. The things that feel niche: physical making, authentic content, human-in-the-loop work. Those might be the most valuable in the next decade."

He's probably right. And if he's right in Japan, he's doubly right here, where the stakes of getting this wrong are not just individual, but generational.

The AI void is coming to Nairobi. The question isn't whether it arrives. It's whether we're the ones who shape what comes after it.

What about you?

Whether you're in Lagos, Accra, Johannesburg, or right here in Nairobi, have you felt that void yet? Which sector do you think takes the first real hit? And what's one human skill you're doubling down on in 2026?

The Speed-Accuracy Paradox: Why "Faster AI" Doesn't Always Mean "Better Decisions"

Zaccheaus Amenya — Tue, 03 Mar 2026 11:50:12 +0000

A researcher's perspective on calibrated trust in artificial intelligence

We've all heard the pitch.

"AI processes data faster than any human. AI removes bias. AI simplifies your work."

And on the surface, it sounds compelling. Medical imaging that catches diseases earlier. Credit scoring that's more consistent. Weather predictions that save lives.

But here's the question nobody is asking loudly enough:

What happens when something is very fast and very wrong at the same time?

The Core Contradiction Nobody Is Talking About

Speed and accuracy are not the same variable. They can and often do move independently of each other.

An AI system can be extraordinarily fast and extraordinarily wrong simultaneously. And that combination is precisely where the danger lives.

What makes this particularly concerning is not the error itself. Humans make errors too. The real issue is the error delivery mechanism.

When a human expert makes a mistake, there are usually visible signals hesitation, hedging, a request for a second opinion. When an AI system makes a mistake, it delivers that mistake with the same confident, fluent, well-structured output as a correct answer.

The presentation quality gives you no signal that something has gone wrong underneath.

The "Simplification Narrative" Is a Commercial Story, Not a Scientific One

The framing that AI is here to simplify human labor has been incredibly effective marketing. But what it quietly does is shift the cognitive burden back onto the user in a more dangerous direction.

Before AI, a person doing a task carried the full weight of their own judgment.

After AI enters the picture, that same person now has to:

Use the AI output
Evaluate whether the AI output is actually correct
Understand the domain well enough to catch errors
Resist the psychological pull of a confident-sounding answer

That is actually a more cognitively demanding task not a simpler one.

The result? A well-documented psychological phenomenon called automation bias the tendency to stop scrutinizing outputs because we assume the machine is more reliable than ourselves. Research consistently shows this leads to worse outcomes in high-stakes decisions than either pure human judgment or properly supervised AI assistance.

The Self-Awareness Gap The Part Most People Miss

Here is the most critical piece of this conversation, and the one that gets the least airtime:

Current AI systems have no reliable internal mechanism to distinguish between:

✦ What they know confidently

✦ What they are pattern-matching from incomplete context

✦ What they are, essentially, fabricating

They generate the next most probable output based on training. They do not verify against reality before responding. This means the system cannot flag its own uncertainty the way a human expert would say "I'm not sure you should double-check this."

The uncomfortable implication:

The user carries 100% of the verification responsibility, yet the system's confident presentation actively works against that verification instinct.

So Is AI Worth Trusting?

I'd argue that question is malformed.

Trust is not binary. A more precise question is:

"Under what conditions is AI output appropriate to act on?"

From a research standpoint, the answer involves three non-negotiable elements:

1. Domain Clarity
The narrower and better-defined the task, the more reliable the output. General reasoning and ambiguous contexts are where errors concentrate.

2. Human Verification Capacity
Trust should only be extended where the person reviewing the output has enough domain knowledge to catch errors. An AI medical tool used by someone with no medical background is a liability, not an asset.

3. Accountability Structures
Until there is clear legal and institutional accountability for AI-generated errors, we are deploying systems with a responsibility vacuum. That vacuum will be filled by consequences that fall on users and affected third parties.

The Bottom Line

AI's speed advantage is real.

Its accuracy advantage is conditional and context-dependent.

The gap between those two facts is where most real-world harm from AI is currently happening not from malicious intent, but from misplaced trust that the industry has actively cultivated for commercial reasons.

Skepticism about AI is not technophobia. It is the appropriate epistemic response to a technology that has been overpromised and under-explained.

The goal should never be full trust or blanket rejection. It should be calibrated trust where humans remain in the loop, where accountability is clear, and where AI proposes while humans decide and verify.

That is not a limitation of AI.

That is how intelligence, artificial or human, should work.

What's your experience with AI decision-making in your field? I'd love to hear how you're navigating the trust question. Drop your thoughts in the comments.

The Art of Client Engagement in the Digital Age

Zaccheaus Amenya — Mon, 29 Dec 2025 15:14:06 +0000

Clients & Digitization

In today's rapidly evolving digital landscape, businesses face the challenge of balancing technological advancements with the timeless need for personal interaction. This article explores the nuances of client engagement, particularly in the realm of custom-built digital solutions.

Understanding Client Needs

The foundation of successful client relationships lies in understanding their unique processes and requirements. Businesses often falter by not aligning their offerings with the client's operational needs. Custom-built systems should be designed to integrate seamlessly with the client's existing processes, ensuring a tailored fit that pre-built software solutions may not provide.

The Personal Touch

Despite the allure of artificial intelligence and automated solutions, clients often seek the human touch that only personalized service can offer. This personal interaction is a key differentiator in a world where technology is ubiquitous. By taking the time to understand a client's business model and financial standing, businesses can tailor their proposals to meet specific needs, fostering a sense of partnership and trust.

Flexible Business Models

Adapting to a client's financial constraints can lead to long-term benefits. Offering flexible pricing or service models, such as reduced rates in exchange for future business opportunities, can strengthen client relationships and lead to mutual growth. This approach not only builds goodwill but also positions the business as a trusted partner rather than just a service provider.

The Power of Referrals

Networking and referrals remain powerful tools in business development. Engaging in community-based networks, such as local business chapters, can provide organic growth opportunities. These networks, composed of professionals from diverse fields, facilitate trust-based referrals that can lead to new business opportunities and collaborations.

Conclusion

In conclusion, the key to thriving in the digital age is not just about leveraging technology but also about maintaining the human element in business interactions. By understanding client needs, offering personalized solutions, and building trust through flexible business models and networking, businesses can create lasting relationships that drive success.

Compose Multiplatform the Powerful Tool for User Interfaces Building

Zaccheaus Amenya — Wed, 19 Apr 2023 07:03:23 +0000

User interfaces are essential for today's software development. They allow users to interact with applications in a visually appealing and intuitive way, permitting them to perform tasks and access information quickly and easily. Building user interfaces, however, can be a complicated process, especially when targeting multiple platforms such as desktop, mobile, and web. To solve this problem, Google has developed Compose Multiplatform - a powerful tool for constructing cross-platform user interfaces.

What is Compose Multiplatform?
Compose Multiplatform is a modern UI toolkit for developing native user interfaces on multiple platforms such as Android, iOS, macOS, Windows, and the web. It works with a declarative approach to UI development which permits developers to create the user interface in an easy-to-understand and concise way. This enables developers to write once and deploy everywhere, minimizing development time and cost.

Key features of Compose Multiplatform:

Declarative UI: Compose Multiplatform uses a declarative approach for constructing UI allowing developers to define the user interface quickly and simply. This helps to make sure the code is easier to comprehend and maintain whilst reducing the risk of errors or bugs happening in the process.
Cross-Platform Support: Compose Multiplatform supports all types of platforms like Android, iOS, macOS, Windows as well as web which means that it’s possible for developers to compile their UI once then deploy it on multiple systems thus saving time and money during development.
Jetpack integration: Compose Multiplatform is integrated with Jetpack - an Android development toolkit - providing an effortless experience throughout all stages of Android development while supporting Kotlin - the preferred language for Android apps – creating an easier transition for existing Android developers looking at adopting it.
Theming & Styling: Through Compose Multiplatform you can customize the design & look of your user interface in order to match your brand or specific design requirements through theming & styling features available within this toolkit too!
Animations & Transitions: With this sophisticated platform you can also create eye-catching animations & transitions resulting in immersive experiences for your users.

Benefits of using Compose Multiplatform:

Reduced Development Time & Cost – by writing code once you are able to deploy multiple times across various platforms reducing time spent on writing code from scratch enabling higher efficiency at more economical costs
Improved Developer Productivity – by defining your user interface through its declarative approach making it simpler for developers to understand & maintain their code meaning fewer errors/bugs occur with more productivity overall
Seamless User Experience – by creating consistent experiences across different platforms users can always be sure they will have similar interactions wherever they use your app
Easier Adoption – due its support of Kotlin making it easier for existing android developers as well as its familiarity among web technologies like React & Vue meaning other devs/teams will find it much easier transitioning onto using this platform too!
Conclusion:
Compose Multiplatform is a powerful tool used specifically when constructing cross-platform user interfaces due its convenient features such as declarative UI approaches coupled with multi-system support plus theming/styling options along with animations/transitions; clearly making this an incredibly versatile yet powerful tool perfect for modern software development applications.

View Binding vs. Data Binding

Zaccheaus Amenya — Fri, 29 Jul 2022 18:48:00 +0000

According to the official documentation, view binding just ties views, but data binding links views to both views and data from code.

Whats Binding?
By eliminating boilerplate code and minimizing the data representation portion of activities, binding makes it simple for us to bind (associate) layout files with activities.

View binding
We can develop code that interacts with views more quickly and simply thanks to view binding. When view binding is enabled in a module, each XML layout file contained in that module receives a binding class. All views having an ID in the associated layout are directly referenced by an instance of a binding class.

Benefits:
Speed Increase -> No need to use the findViewById procedure anymore, and removing a view won't cause any problems because errors will appear straight immediately.
Code Readability -> Giving the views reasonable ids will greatly improve the readability of the code.
*Reduces Crashes *-> If you never describe what a view is to be cast as you cannot make a mistake, type safety does this.

Data Binding
In simple terms, data binding is something that performs the same thing as view binding but adds a bit more to it and decreases the amount of work we have to do even more. First, as the name implies, we must tie the data to the views, which is precisely what occurs. The XML file specifies a data source, and when the view is presented, an instance of the data is also supplied, which may be used to automatically set attributes.

Benefits
Complexity Reduction-> Data Binding could be not so straight to start with, but once you get the hang of it will boost your development speed.
Reduces code -> The ease of letting go of updating a view multiple times can easily reduce many lines of code

Differences between View Binding and Data Binding

Layouts do not require a layout tag when using view binding.
Viewbinding cannot be used to connect layouts to data in xml (No binding expressions, no BindingAdapters, nor two-way binding with viewbinding)
The primary benefits of viewbinding are speed and efficiency. It offers a lower build time because it eliminates the overhead and performance difficulties related with databinding caused by annotation processors.
View Binding library is quicker than Data Binding library since it does not need annotation processors below, and View Binding is more efficient when it comes to compilation time speed.
View Binding's sole duty is to bind the views in the code. In comparison, Data Binding provides more choices, such as Binding Expressions, which allows us to build expressions that relate variables to layout views.
The Data Binding library uses Observable Data objects. When the underlying data changes, you don't have to worry about updating the UI.
Binding Adapters are provided by the Data Binding library.
The Data Connecting library includes Two-way Data Binding, which is a method of binding your objects to xml layouts so that both the object and the layout may transfer data to one other. In summary, there is nothing that viewbinding can accomplish that databinding cannot do (albeit at the expense of longer build times), and there are many things that databinding can do that viewbinding cannot.

Conclusion
While data binding may seem fascinating, it is a somewhat heavy-loaded library, which may result in a longer build time. So, if you're not just utilizing DataBinding for functionality, you might want to explore ViewBinding, which has some advantages in terms of build time and apk size.

Saving UI State for Android (ViewModels with Saved State)

Zaccheaus Amenya — Tue, 12 Jul 2022 07:52:42 +0000

ViewModel has developed into one of the most "core" Android Jetpack libraries since its debut. Approximately 40% of Android developers have included ViewModels in their apps, according to our 2019 Developer Benchmarking data. This might not be obvious if you're unfamiliar with viewmodels: By separating your data from your UI, viewmodels encourage better architecture. This makes it simple to manage UI lifecycles and increases testability. Visit ViewModels for a detailed explanation.

Since ViewModel objects, not activities, are typically where UI state is kept or referenced, using onSaveInstanceState() needs some boilerplate that the saved state module can take care of for you.

ViewModel objects get a SavedStateHandle object through its constructor if this module is being used. You can write and retrieve items to and from the preserved state using this object, which is a key-value map. These values are still accessible through the same object even after the system kills the process.

The Challenge of onSaveInstanceState

There was a perplexing problem with onSaveInstanceState when ViewModels first came out. There are three techniques to destroy activities and fragments:

You intended to navigate away permanently: The user navigates away or intentionally quits the activity, such as by clicking the back button or activating a code that calls finish (). The action has ended completely.
There is a configuration change: The user turns the device on or makes another configuration modification. The activity needs to be restored right away.

The app is put in the background and its process is terminated: This occurs when the device has to free up memory quickly because it is running low on memory. The activity will need to be rebuilt when the user returns to your app.

You want to restore the activity in cases 2 and 3. Because the ViewModel is not destroyed upon a configuration change, ViewModels have always assisted you in handling case 2. However, in situation 3, the ViewModel is also destroyed, necessitating the use of the onSaveInstanceState callback in your activity to save and restore data.

Saved state module for ViewModel

A new library by the name of ViewModel SavedState has been made available by Google as an extension to ViewModel to provide Activity or Fragment state persistence through process stop.
The ViewModel Saved State module handles the third scenario (process death). There is no longer a requirement for the ViewModel to communicate state to and from the activity. Instead, you can now manage to save and restore data entirely within the ViewModel. The ViewModel can now manage and store all of its data effectively.

A SavedStateHandle is used for this; it's a key-value map of data and is quite similar to a bundle. The ViewModel contains this SavedStateHandle "bundle," which endures the termination of background processes. You can now save any information you previously had to save in onSaveInstanceState in the SavedStateHandle. For example, you might keep information in the SavedStateHandle, such as a user's ID.

Note that the code below is snippets from this CodeLab reWritten in Kotlin, though.

Setting Up

Step 1: Add the Dependency

SavedStateHandle is a distinct library presently in alpha (meaning the API may change, and we're seeking feedback). The additional dependence is:

app/build.gradle:

dependencies {



     def version = "2.2.0"


     implementation "androidx.lifecycle:lifecycle-viewmodel-ktx:$version"


     implementation "androidx.lifecycle:lifecycle-livedata-ktx:$version"


     implementation "androidx.lifecycle:lifecycle-viewmodel-savedstate:$version"


     // or lifeycle-compiler if not using Java 8


     //kapt "androidx.lifecycle:lifecycle-compiler:$version"


     implementation "androidx.activity:activity-ktx:1.1.0"


     implementation "androidx.fragment:fragment-ktx:1.2.1"


    }

SavedState_DetailsViewModel:

class DetailViewModel(



     private val handle: SavedStateHandle


    ) : ViewModel() {


     fun loadData() {


     val id = handle["id"] ?: "default"


     // Load data for ID...


     }


    }

Step 2: Update the call to ViewModelProvider

The following step is to develop a type of ViewModel with a SavedStateHandle. Update your call to ViewModelProvider in your activity's or fragment's onCreate method to:

    // This ktx requires at least androidx.fragment:fragment-ktx:1.1.0 or


    val viewModel by viewModels { SavedStateVMFactory(this) }


    // Or the non-ktx way...


    val viewModel = ViewModelProvider(this, SavedStateVMFactory(this))


     .get(MyViewModel::class.java)

The class that creates ViewModels is called a ViewModel factory, and another ViewModel factory named SavedStateVMFactory produces ViewModels with SavedStateHandles. The activity/fragment supplied in will now be connected by a SavedStateHandle to the newly generated ViewModel.

Step 3: Use SaveStateHandle in ViewModel

You may then utilize the SavedStateHandle in your ViewModel after completing this. Here is an illustration of how to store a user ID in the SavedStateHandle:


class MyViewModel(state : SavedStateHandle) : ViewModel() {

    // Keep the key as a constant
    companion object {
        private val USER_KEY = "userId"
    }

    private val savedStateHandle = state

    fun saveCurrentUser(userId: String) {
        // Sets a new value for the object associated to the key.
        savedStateHandle.set(USER_KEY, userId)
    }

    fun getCurrentUser(): String {
        // Gets the current value of the user id from the saved state handle
        return savedStateHandle.get(USER_KEY)?: ""
    }
}

Construct: MyViewModel accepts SavedStateHandle as a constructor parameter.
Save: An illustration of saving data in a SavedStateHandle is provided by the save NewUser function. You first save the current userId and then the key-value pair USER KEY. The SavedStateHandle should be updated as data changes in the ViewModel.
Retrieve: The current value saved in the SaveStateHandle can be obtained using the method savedStateHandle.get(USER KEY).
Now, if the activity is destroyed, we can be ensured the SavedStateHandle will have our data.

Clean Architecture(MVVM)

Zaccheaus Amenya — Wed, 29 Jun 2022 20:52:05 +0000

There has always been a discussion about which Android architectural pattern to use. You had the impression that something was wrong with the way things were set up from the beginning. Many people then experienced difficulty with architecture in general as a result of this.
However, writing applications in a clean manner has been discussed for a while.
Understanding the concept behind the Clean architecture and why it's a good solution for the majority of issues we encounter today as programmers is very instructive because it can be used in any application and platform, not just Android.

Like other software design philosophies, clean architecture seeks to offer a practical method for creating high-quality code that performs better, is simpler to change, and has fewer dependencies.
The rings up top stand for the various software tiers in your app. Two important considerations must be kept in mind before continuing:

The most concrete ring is on the outside, and the most abstract ring is in the middle. The Abstraction Principle states that implementation details should be in the outer rings while business logic should be in the inner rings.
Another principle of Clean Architecture is the Dependency Rule. According to this rule, each circle can only rely on the inner circle that is closest to it, allowing the architecture to work.

MVVM

A software design framework called Model-View-ViewModel (MVVM) distinguishes between program logic and user interface elements. In 2005, it was unveiled by John Gossman and Ken Cooper, two well-known Microsoft architects. In addition, MVVM is also referred to as a model-view-binder. The MVVM design pattern, like many others, aids in code organization and program module separation, enabling quicker and simpler code development, updating, and reuse. Windows and web graphics presentation software frequently use this design. The MVVM design is used by the Windows Presentation Foundation (WPF), which utilizes Microsoft's.NET platform. Silverlight, a multimedia plug-in that runs on the internet and is similar to Microsoft's WPF, also uses MVVM.

Using MVVM, your view—that is, your activity and fragments—is separated from your business logic. MVVM is adequate for small projects, but as your codebase gets bigger, your viewmodels start to bloat, and it gets difficult to divide responsibilities. In these situations, MVVM with Clean Architecture is a good option. It goes a step further in clearly defining the roles in your code base. Your app's actions have abstracted logic that makes them unintelligible. The Model-View-Presenter (MVP) architecture and Clean Architecture can now work together. As a result, we're choosing MVVM over MVP because Android Architecture Components already comes with a built-in ViewModel class, eliminating the need for an MVVM framework.

The Advantage of Clean Architecture

Compared to MVVM standard, code is simpler to test.
Perfectly designed separation (the most important benefit).
User-friendly package structure.
It's simple to keep the project going.
New features can be added by your team even faster.

Disadvantages of Clean Architecture

The learning curve is somewhat acute. Learning how all levels interact may take some time, especially if you're coming from architectures like simple MVVM or MVP.
It has a lot more extra classes than is necessary, making it unsuitable for applications with simple requirements.

Layers of MVVM

Different people have different ideas about how many levels Clean Architecture should have. The design does not specify separate layers but instead lays the groundwork. The idea is that you can change the number of layers based on your requirements. Here, we'll use five to keep things succinct; take a look at them.

Presentation: This is a layer that interacts with the (UI)user interface.
Domain: The app’s business logic is stored here.
Use cases: Interactors are another name for them.
Data: All data sources are defined in a broad sense.
Framework: implements interfaces with the Android SDK as well as co ncrete data layer implementations.

Gson, Moshi, Jackson

Zaccheaus Amenya — Wed, 29 Jun 2022 06:55:28 +0000

Retrofit is generally regarded as the lone constant in the network layer of every program. On the other hand, JSON Parser is used to deserialize responses into data objects or serialize information objects into requests.

Gson

The most widely used of the lot is Google's own JSON Parser package for Android (sitting at 18.5k Github stars, vs 5.9k and 6.5k). Due to the introduction of its 1.0 version in 2008, it is also the oldest.

We can transform Java objects into JSON representations using the Gson Java package. Additionally, We can use it to translate a JSON string into a corresponding Java object.

Why ought you use this library?

Gson is a standardized library run by Google that adheres to specific standards.
Efficient This Java standard library addition is dependable, quick, and efficient.
Enhanced optimization has been applied to the library.
Support for Generics It offers a lot of support for generics.
Supports large inheritance hierarchies and complicated objects with complex inner classes.

Features of Gson

Easy to use − Gson API provides a high-level facade to simplify commonly used use-cases.
No need to create mapping − Gson API provides default mapping for most of the objects to be serialized.
Performance − Gson is relatively fast and is of low memory footprint. It is suitable for large object graphs or systems.
Clean JSON − Gson creates a neat and compact JSON result that is easy to read.
No Dependency − Gson library does not require any other library besides JDK. -Open Source − Gson library is open-source; it is freely available.

Jackson

Gson's longest rival is trying to outperform it with a quicker and more feature-rich parser. Fun fact: Its 1.0 version in 2009 went by the codename "Hazelnut," which was chosen because many people choke on nuts.
It is a prevalent library to map JSON responses to the POJO or Model classes in Android. The Jackson parser has a better parsing speed as compared to other popular parsing libraries like JSONP, GSON,
It contains a built-in Object Mapper class that analyzes JSON files and deserializes them into custom Java objects. It facilitates the production of JSON from Java objects.

Jackson is a JSON API for JavaJava comprising:

Jackson Core(Streaming API) – low-level streaming API is defined and contains JSON-specific implementations
Jackson Annotations – includes the standard Jackson annotations.
Jackson Databind – provides support for data-binding (and object serialization) on streaming packages; it is dependent on the streaming and annotations packages.

Some of the most notable features of Jackson for Java include:

The capacity to annotate fields to map them to particular JSON keys. You can use Jackson to annotate fields in Java objects so that they correspond to specific JSON document keys. Working with complex JSON documents is now considerably simpler as a result. For instance, We can use the @JsonProperty("name") annotation to access a field in a Java object that is mapped to a "name" key in a JSON document.
POJOs (Plain Old Java Objects) and JAXB beans (Java Architecture for XML Binding): Jackson is compatible with both JAXB beans and POJOs. With no boilerplate code needed, you can now serialize and deserialize objects.
Various modules offer additional functionality: Jackson includes several modules that provide additional functionality. These modules all support the XML, YAML, and CSV formats.

Moshi

The most recent of the three parsers was initially made available in 2015. It was created by Square, the same company that made Retrofit, and some Gson team members are involved.
When compared to GSON, the fact that Kotlin was considered when writing it shines. It is considerably simpler to use and create tests for a polymorphic adapter or a primary Type adapter. This allows us to enhance our projects' code quality further.

Will there ever be circumstances where one is preferable to the other? Maybe. Can we gather them all together to decide on an objective best? We'll soon find out, though.

Moshi offers a more condensed API than libraries like Jackson or Gson without sacrificing performance. As a result, we can design more testable code, making it simpler to integrate into our apps. In some circumstances, such as developing for Android, a lesser reliance may be crucial.

Standard Java types are already supported by Moshi, which accurately converts to and from JSON. This includes:

All primitives – int, float, char, etc.
All the JavaJava boxed equivalents – Integer, Float, Character, etc.
String
Enums
Arrays of these types
Standard Java collections of these types – List, Set, Map

In addition, Moshi will automatically transform any random Java bean into a JSON object, with the values converted per the same guidelines as any other kind. This indicates that Java beans are successfully serialized as profoundly as necessary within Java beans.
We then get access to specific additional conversion rules thanks to the Moshi-adapters dependency, including:

An Enums adapter is a bit more robust, enabling a fallback value when reading an uncertain value from JSON, a Java adapter. util
supporting the RFC-3339 format for dates