DEV Community: Agustín Tomas Larghi

Oof – look, that's a legacy codebase!

Agustín Tomas Larghi — Sun, 16 Jul 2023 22:26:12 +0000

If you are an engineer who has been in the industry for over nine or ten years, you will likely have experienced projects that are not "in such great shape".

You know what I'm talking about. Those projects where the first engineer decided to implement an MVP architecture based on some random article they skimmed from Medium about using one Activity and custom views for each screen.

Then, when the Jenga tower was shaking on the brink of collapse, the engineer figured it was time to "go looking for a new adventure" thus, a new developer had to be hired!

The new dev figured that the previous one had no idea what they were doing, so they decided to flip things over – this time we go with a custom BottomSheetDialogFragment for each screen. Surely this time it'll work!

It didn't.

And yet again, this engineer had to go looking for new challenges. Repeat this 5 times over a period of 5 years and you no longer have a piece of software — you have a ticking bomb. You have a Coke that will explode in your hand as soon as you grab it from the shelves and leave you with a face full of shrapnel.

Now it is your turn. I will share a few things I have learned to help you deal with these situations. Hopefully, some of these tips might come in handy.

Remove unused resources

Issue

You go through the codebase and more often than not see pieces of code that are completely grayed out, unused. There is no such thing as keeping code "just in case", you either use the code or you don't – keeping leftovers there is just going to confuse people, and it is probably a symptom of a deeper issue.

Solution

Android Studio has a "Remove unused resources" tool under Refactor

You can preview what the removal of the unused resources would look like and exclude some of those deletions if you don't feel comfortable enough with some of the things Android Studio picks.

PR templates

Issue

So, the QA engineers complain that every fix your team submits is like a butterfly effect: it creates 3 new different bugs, or they say the fix/feature isn't even working at all. This is what I call late-stage "I don't give a flying fig" syndrome. The code base is so fragile and so prone to bugs that no one even cares to test stuff, or even run those changes locally.

Solution

Set a PR template for the team. It is not necessary to use a super-long annoying-to-fill form, just put two items to complete every time an engineer wants to submit a PR. A short description of what's in there, and a video walkthrough of the engineer explaining the changes and showing how the feature works.

You know Slack lets you record and download videos?

You can use that tool to record videos, then download them, and drag-and-drop them into the PR description. It's a piece of cake, and won't take more than 5 minutes. But if your engineers can't even find the time to whip up a 5-minute video to explain their work, well, that's a whole other cake.

Kotlin basics

Issue

You go through the code and see things like mutable data types being used on re-assignable (mutable) variables

var someLiveData = MutableLiveData<Something>()

var someCollection = mutableListOf<Something>()

or maybe you see data class structures abusing var properties

data class Something(
  var prop1: SomethingElse?,
  var prop2: SomethingElse?
  // ...
)

This is usually a symptom of engineers who haven't fully migrated from Java to Kotlin. It is important to fully understand concepts like mutability and nullability.

Solution

This is a symptom of a lack of Kotlin basics. I'd like to defer to a super-helpful article I read some time ago:

https://www.javacodegeeks.com/starting-with-kotlin-cheatsheet

Tech Soup

Issue

Alrighty, in different corners of the app, you have screens that are either using ViewBinding, Kotlin Synthetics, Butterknife (because why not?), or Composables.

Some screens have the ViewModels communicate back to the UI using either LiveData, Flow, or Kotlin Channels, and some are using DataBinding.

Every engineer that passed through this project had their own unique genius way of doing things... because the guy before them was a complete idiot, obviously.

Solution

Try to find a balance between what the team thinks the best practices are and what you already have there in the codebase. Schedule either weekly or bi-weekly meetings with the engineering team, go layer by layer through the architecture and decide what the best practices are going to be from now on. For example:

"Okay, we use Retrofit for the API calls, do we wrap the responses on a Response wrapper to carry over the status response or we don't care about it?"

"Okay, how do we have ViewModels communicate to the UI from now on? We have all these options, what do we use and why?"

"Okay, do we use Jetpack Compost or do we use something else as a UI framework?"

You go layer by layer, figure out what the available options are (please don't thrust yet another tool into the mix!), and pick one. If possible, document that somewhere, either Notion or a wiki or whatever, but do document it – agreeing on something and not writing it down is the same as doing nothing.

Navigation Soup

Issue

It's like a choose-your-own-adventure book...except in the land of app navigation! Some parts of the app are using Navigation Graphs. Some are going for the one Activity, many custom views approach. Some are full-screen DialogFragments. Others are full-height BottomSheetDialogFragments. What will you choose for your app journey?

Solution

Same as above, sync with the rest of the team and pick one solution. I'd recommend that whatever you decide, you use Fragments. Think about all the third-party libraries out there that provide some sort of UI; they all do it either through Activities or Fragments. The goal for each flow of your app (the login flow, the account creation flow, the onboarding flow, etc.) should be exactly that — expose each of those flows as if you were sharing an SDK that would be used by other developers.

Of course, this requires a bit more technical brainstorming depending on the spaghetti you have at hand – I'd recommend that if the app has a base class for each screen (those awesome noodles of wisdom) you keep using them. Hear me out:

Let's say your app works using BaseSomethingFragment, each screen extends on this base class. Internally, BaseSomethingFragment extends from BottomSheetDialogFragment and it tweaks it so it prompts at full height.

Something you could do is to tweak this base class so it has a FragmentViewContainer and it uses a Navigation Graph internally, that way you can create the rest of the screens using Fragments, and eventually move every screen into bare Fragments instead of using that base class.

Just an idea, it's not a foolproof plan, but it'll give you the chance to do things one step at a time.

Isolate new code through modules

Issue

Given that the app is one large monolithic :app module, containing all the above items, how can we begin to implement our fresh approaches and start to separate the components?

Solution

Sunset the APP module. All the apps out there can be divided into different flows. For example, when the user goes through the login screens, that's the login flow – it might be a collection of 2, or 3 screens, but that's a self-contained flow. You might also have an onboarding flow, account creation flow, etc.

Each of these flows should be contained in a feature module (just a fancy name for a library module) and each of these feature modules should be completely independent of each other so we prevent dependency-spaghetti. You can do this step by step:

First, you have your monolithic app module

Now, just to keep things tidy let's rename that module into :app-legacy just everyone knows that we aren't supposed to keep adding things in there.

We are going to create a new application module, namely :company-app and have it depend on the old :legacy-app module. We have also turned the :legacy-app module from an application module into a library module.

Most likely, your old :legacy-app module had an Application class – in situations like these, the Application class is usually highly bloated with code. So, to start fresh you can have your new :company-app application module have its own Application class that extends from the old one. You can also mark the old CompanyApp as @Deprecated to prevent further things from being added in there.

You might also have to move many plugins from the :legacy-app down into the new :company-app application module. For example, if you are using Firebase and google-service.json you might have to move these down there, as they need to be plugged into the application module.

Now you can create completely independent feature modules to either refactor existing flows or create new ones. Let's say we had an account creation flow that was rid of bugs and we want to extract it out into an isolated module so we can refactor things safely.

First, we create a new library module for this new flow.

Now, we move all the classes, all the Fragments, all the stuff specific to that flow into that new library module. If something is reused between flows, let's say you have a SharedPreferences wrapper, that stays up in the :app-legacy module.

What about if we want to navigate between feature modules? Let's say we have another feature module for another flow of the app.

Well, you can use a Navigation class. You can declare an interface up in the :app-legacy that exposes the entry points for each of the screens in each flow. Something like:

interface MyNavigationProvider {
   fun getLoginFragment(context: Context): `BaseSomethingFragment`
   fun getUserProfileDetail(context: Context): Intent
   // ...
}

You can provide either Fragments or Intents, whatever fits your architecture best.

This interface would be implemented in the NewCompanyApp Application class, and since the :company-app module ties all the feature modules together it knows about all these classes.

If you ever need to jump from one screen in one feature module to another, the only thing you need to do is to cast the application context into the MyNavigationProvider interface that was declared up in :app-legacy

Something like:

getApplicationContext() as? MyNavigationProvider

and that's it!

Now, don't think the job is done yet. This is the first step on a long road. Eventually what I try to do is turn the :app-legacy into a :core module, with just the things that are common to all feature modules. I try to extract the UI and everything else down into feature modules.

But this, at least, should be enough to provide your team with a way to create new flows independently.

There are many things you can do after this, you can extract all your base UI into a :design-system library module, so you encapsulate the look-and-feel of your app in one single place, but I would strongly recommend you first get the basics working, then you can start thinking about adding extra stuff.

Set a coding standard

Issue

Every PR someone submits seems to have more changes due to code formatting than actual substance - it's like a one-line bugfix needs 30 changes; one for the bug and 29 for imports turning into wildcard imports or tab-formatting. Who knew code formatting could be so complicated?

Solution

Either push some of the .idea files up into the repo, or share the code style configuration across the team.

That's all

Finally, set expectations with everyone in the team, engineers and uppermanagement, lay all the things on the table so everyone is aware of what's going on and what needs to be fixed.

I'm sure most people will cry "micromanagment!" at some of my proposals, but hey, to each their own – you like to push code up and pretend it's working, that's your prerogative. That's not my thing.

The Performance Pyramid (part 4) – Team Management

Agustín Tomas Larghi — Wed, 05 Apr 2023 19:21:50 +0000

Index

The Performance Pyramid (part 1) – Communication
The Performance Pyramid (part 2) – Ownership [TBD] I'll talk about the "Ownership" boulder
The Performance Pyramid (part 3) – Tech Skills [TBD] I'll talk about the "Tech Skill" boulder
The Performance Pyramid (part 4) – Team Management
The Performance Pyramid (part 5) – Remote Culture [TBD] I'll talk about remote working; how to manage time-zone differences, working with people from different cultures, and how to efficiently work with people from all around the world

About

Some management books encourage people to build relationships with your teammates so you can provide better, more honest feedback. They say that if you don't connect with your teammates, you won't be able to provide feedback that they actually listen to. I disagree with this. I have tried to do that many times before, and it has never worked. No one is going to get along in a team where they have repeatedly missed deadlines, where they have repeatedly misinterpreted requirements, where communication is next to none – if you want your team to get along, first, they need to start winning.

Shrinking egos

A team's issues and dysfunction stem from egos. A successful team needs everyone, from individual contributors to the CTO, to completely humble themselves. This is no easy task; first, we need to understand why there are such big egos in the software engineering industry. I have seen that many engineers out there make programming their primary personality trait. They are the cool nerds, the savvy engineers, so even the smallest amount of criticism would make them feel personally attacked

How can we fix this problem without making it worse? Here are some ideas:

Be humble in front of everyone. Humility is the best antidote against big egos. Ask for help. Tell everyone that you don't know what a certain topic is about. If there's a technical challenge that you need to face, make it clear that you don't know what to do. Engineers aren't a limitless knowledge repository with all the algorithms and solutions hardcoded into their brains, make this clear to everyone. People with big egos might notice this behavior and lower their defenses a little.
Publicly thank people for their help and their work. You might think that doing things like this might inflate people's egos even more, but, on the contrary, more often than not, people's egos get inflated because they feel they don't get the recognition and praise they deserve. So they push even harder.
Pay attention to the tone of every conversation. Even if an engineer is right about a technical decision, if they communicate their arguments in a way that is hurtful or spiteful, that needs to be addressed. Usually, having that person read out loud what they wrote during a private 1:1 meeting, is enough to make them realize their mistake. Make sure you point out that you do appreciate their passion for their jobs and the attention to detail, but that they need to be careful about how they communicate things.

Balancing opinions

Software engineering is a creative profession, and oftentimes team members will have different opinions about how to solve a problem. It is important to be mindful of how these situations are handled in order to create a positive work environment.

For example, let's say you have two engineers who have different opinions about how to solve an issue; how do you unblock this situation? First, ask if they have any technical proof to back up their arguments; many times, engineers push an idea just because they "feel" it is the right thing to do. Second, try to bring everyone back down to earth, remind everyone that we are working as a team and that sometimes we have to compromise and accept other people's ideas just as they accept ours. Third, everyone should get a vote; the best solution is whatever the engineering team accepts as a whole. Fourth, never shoot down someone else's ideas. You may have to deal with situations in which no argument is enough to convince someone about a technical decision, even when everyone else has agreed to it. In these situations, suggesting to "put a pin in it" or "revisit it later" can keep the conversation going.

Meeting etiquette

Every day, more and more companies are moving to a remote-first model. It is essential to have a policy during online meetings so they don't turn into an annoyance for everyone involved.

Make yourself presentable. This might be a common requirement for experienced remote workers, but for most people who haven't worked remotely until the COVID pandemic, this isn't so obvious. Don't join a meeting wearing a robe. Don't join a meeting from your bed. Always keep your webcam on so other people know you're paying attention. I understand that some people are shy about turning their cameras on and having eyes on them when they speak, but if that's the case, you can just switch tabs. Switch to another tab where you don't have to look at the people in the meeting, and that's it. And please don't attend a meeting shirtless – yeah, I've seen that before.
Filter out the noise. If you are in a noisy environment, try to invest in some noise-canceling software or a headset with built-in noise-canceling hardware.
Use the chat section. If you feel uncomfortable about interrupting people, you can always write something in the chat section or use the "raise your hand" action.

How to encourage good traits

There is no simple answer to this. People normally do not like being told what to do, especially engineers. Ideally, you would want all members of the team to spontaneously embrace these best practices, without needing to enforce any rules, without having to guide or repeat the same thing time and again. That's not the case most of the time. Let me share some ideas that might help you see things in a different light:

The "Broken Windows" theory states that places with visible signs of crime – like loitering, vandalism, jaywalking, etc. – are more prone to crimes than places without those signs. Makes sense, right? I mean, if you go to a landfill, you are not going to look for a dumpster to throw the trash in; you are just going to toss it anywhere. The same thing goes for software, it would be unlikely that an engineer stays motivated if they see an untidy code base where no one cares where the trash goes.

The term "Bilbao Effect" was coined in response to the construction of the Guggenheim Museum in Bilbao. Subsequently, the entire region began to experience a period of growth and increased prestige. The Bilbao effect is quite different from the Broken Window theory. The Bilbao effect proposes that a tidy, pristine building can have a positive impact on the environment around it. If you're leading an engineering team, it's important to remember that showing the way is key to motivating your team. Set the example, push for clean PRs, and be clear in your communication, and your team members will follow. It won't happen overnight, so don't give up if it takes some time.

Leadership roles

Many engineers do want to pursue a leadership role at some point in their careers. It might be for good reasons. They might feel comfortable with that kind of role and want to improve their soft skills, or they might feel they are more valuable in coordinating things across different teams rather than being an individual contributor. It might also be for the wrong reasons. They think they are getting too old and it is the next step (even though a good individual contributor is as valuable as a lead) or because they like the big badge that says "lead". I'm going to share a few tips for anyone who is interested in pursuing a leadership role.

Things that a leader should never do

Saying that something is "above your pay grade". If you are a leader, your main responsibility is to make sure you unblock your team, and that you provide everything they need to move things forward. They need to implement a feature and we are missing the design? Go and talk with the design team and figure things out. Is there a bug out there in production and we need backend engineers to help? Drag everyone into a meeting and coordinate things. Going through all the usual ceremonies; Backlog grooming, sprint planning, retros, etc. all these things can be very exhausting at times, and on top of that you might have to deal with people's egos, people dropping the ball and not doing things. If at any point doing all this you say: "This is above my paygrade" you have failed as a lead. I understand that there is a limit to everything; it is unreasonable to expect that you do everything. If that ever happens, get into a meeting with whoever you report to and try to figure out how to delegate more.
Finger pointing. Never blame someone for something publicly. When you talk publicly, it is always "we", never "I" or "They". "We" fixed an issue. "We" dropped the ball and introduced a bug. "We" improved the app quality. For better or for worse, we are all in the same boat when we win, and when we lose.
Badge flashing. If you ever have to say, "Do it because I'm the lead and I say so," then that's it — find another role. You're not fit to be leading people. I understand that people might be dense, and even if you convey a solid argument with proof that backs up your decision, people might still push back out of spite or sheer stupidity. But there are other ways to solve those kinds of situations. For example, getting another person involved can help you see things from a fresh perspective — maybe you are making a mistake, and you just haven't realized it yet. But never use your authority to close an argument; people will immediately lose any respect they have for you if you do that.

Things that a leader should always do

Leading by example. If you are in a leadership role or aspire to pursue a leadership role, there are things you cannot do. You cannot submit sloppy, untidy, and barely tested Pull Requests. You cannot skip meetings. You cannot go radio silence. If someone asks you something, you need to answer. You should be an example of how all your engineers should perform. It might be exhausting at times, but that's how it is.
Taking notes and sharing your screen. Taking notes is an important part of any meeting, but it's also essential that you fully share your screen so everyone can see what you're talking about. If you talk about goals, tasks, or milestones without sharing your screen and showing people what you are talking about, they will very likely forget about what you said or have a hard time trying to follow what you are saying. Put an agenda doc on every Google Calendar event you schedule. This will let everyone put their thoughts out and you will have a document full of actionable items when you're done with the meeting. Meetings can get quite hectic if you don't take notes. For example, let's say you schedule a meeting with your team to talk about the deadlines for a new feature that's going out. Then someone chimes in and says that there's something else they need to do before that, and someone else jumps in, and so on. If you don't keep track of what is needed to be done in a document, by the time you finish the meeting you will have more questions than answers.
Enforce good practices. We have talked about how to diagnose problems in your team, and how to fix them, but it is the job of the leader to make sure everyone keeps up with those best practices. If someone Direct Messages you, tell them to continue that conversation on a public channel. If someone submits a sloppy Pull Request, ask them to fix it.

Letting people go

There's a limit to everything. Many leadership books suggest that you should try to be empathetic with people, connect with them, make them part of your family, etc. However, there is a limit. Sometimes people just don't care. Maybe they're going through personal issues. Maybe they don't feel fulfilled. Who knows? If you have repeatedly expressed your concerns and feedback to one of your engineers about how to improve and they continue to provide lackluster results, if they are showing no signs of improvement, then that person needs to go. It makes other engineers' jobs harder and sets a bad example when under-performers get a free pass.

The Performance Pyramid (part 1) – Communication

Agustín Tomas Larghi — Wed, 05 Apr 2023 19:00:47 +0000

Index

The Performance Pyramid (part 1) – Communication
The Performance Pyramid (part 2) – Ownership [TBD] I'll talk about the "Ownership" boulder
The Performance Pyramid (part 3) – Tech Skills [TBD] I'll talk about the "Tech Skill" boulder
The Performance Pyramid (part 4) – Team Management
The Performance Pyramid (part 5) – Remote Culture [TBD] I'll talk about remote working; how to manage time-zone differences, working with people from different cultures, and how to efficiently work with people from all around the world

About

Despite what movies and TV shows may suggest, the stereotype of the lonely engineer coding in a dark room wearing a hoodie is far from the reality of software engineering. This profession is highly collaborative and requires teamwork and communication skills similar to those of soccer players or medical professionals. A successful engineering team must be on the same page at all times, conducting with clear and effective communication. Every team member must be aware of their role and responsibilities to ensure the project's success.

This article aims to share a few things I have learned throughout my career as an engineer.

Cut the ego

The software industry doesn't need egos, any solution that gets the job done is a fine solution. Everyone should focus on pushing towards the same goal, not on who gets the credit, who gets to shine, or whose PR gets approved. The only thing that matters is getting a quality product out there.

In this article I'll share practical and actionable tips to lead engineering teams effectively. I'll share my own experiences and also reference books that have been very inspirational. This article is not just a rant about the problems in the industry, but it also provides specific solutions to fix these issues.

Again, my goal with this article is to provide the tools and strategies you need to lead your engineering team effectively and foster a culture of collaboration and teamwork that drives results.

Why should I care?

This article talks a lot about ownership, communication, and how to improve things within your team and organization so you can all achieve the best results and provide quality products to your users, but first, you should ask yourself if you really care or not. Some people don't like ownership; they see a software engineering job as a temporary gig until the next thing comes around. Maybe they are too good for their current company. Maybe they should have been working with John Carmack, but you know, life didn't give them the chance. If you are like that, please don't even bother reading this article. If you are too good for your current team, please re-think your career choices. Because software engineering is a highly collaborative profession and there's no place for misunderstood geniuses.

Remote work

I have been working remotely since before the COVID pandemic hit. After the pandemic, remote work became more common, and companies that were reliant on adopting it have come to see its benefits. But I do see that many companies do not know how to manage remote employees. This article will tackle that topic, providing step-by-step instructions on how to educate your resources into a remote work culture. I will share my experience helping companies understand the benefits, pitfalls, and challenges of remote work.

The performance pyramid

This is without a doubt the most important and valuable concept that I'll be sharing in this article, the "performance pyramid". This is a visual representation that helps you understand how to improve your team's performance over time by focusing on a few key areas at a time.

Communication is the most important boulder in your team's pyramid. Communication is the key to team success. I don't mean that everyone on the team has to speak fluent English. You might have an engineer from South America, Eastern Europe, or Asia who has a thick accent, but he might communicate better than a native English speaker. What I mean by communication is that your team is able to effectively and efficiently communicate ideas, problems, and solutions to each other through public channels in a transparent and honest way.

If you see a team where most of the conversations are done through DM, where engineers sweep things under the rug and don't speak up because they are afraid of opening a can of worms, that's a team that has failed to communicate effectively.

I'll share a few tips to improve communication – turning your engineers into Slack power-users, teaching your engineers how to take notes during meetings, using agenda docs to keep track of action items, how to multitask effectively, learning to mediate between egos and unblock conversations.

Ownership is the second-most important boulder in your team's pyramid. It means that engineers actually care about what they do and they care about the quality of the product they are building. This means that engineers feel accountable for the PRs they submit and that they actually perform some basic testing on the code.

A team with no ownership of their product is a team where PRs are submitted with no descriptions, no tidiness, single big-bang commits, commented code, and constant back-and-forth with QA because no engineer feels the need to do some basic testing on the code they implement, and even the most basic use case doesn't work as expected.

Tech skills, surprisingly enough, are the least important boulder in the pyramid. I've seen junior, inexperienced engineers turn into very sharp programmers. I have also seen senior engineers struggle with communication and ownership due to professional baggage.

I think it's easier to find talented engineers than to make them. I'll share some tips about how to improve your tech interviews.

Communication

I have seen many talented engineers fail because of communication issues. Sometimes they cannot communicate their ideas well, but more often than not it is because they are too insecure or anxious. Overthinking is common trait among software engineers.

I have seen engineers get stressed out over having to ping a manager, schedule a meeting, or do an @here on a Slack channel. I'd like to think that I am very loud and clear on Slack, and no one has ever slapped my wrist for hitting that @here to get people in sync. No one has ever yelled at me for trying to express my ideas or made me feel stupid for trying.

Your team will have reached effective communication when they can talk things through without a second thought. There are many steps you need to go through to achieve such a thing. That's why for this communication boulder and for every other boulder in the "Performance Pyramid", we will run a self-diagnosis test to see how well (or not) your team is doing. Based on the results of the self-diagnosis test, you will be able to make the necessary adjustments to improve your team's communication.

Self-diagnosis

I want you to underline each bullet item if it applies to your team or if you've seen this happen:

More often than not, when you are in a meeting and someone asks a question directed at your team, no one answers until specifically pulled into the spotlight.
People rarely communicate through public channels in Slack. You suspect that most of the conversations are done through DMs (Direct Messages).
Sometimes people don't reply when they are directly @ pinged on Slack. Sometimes they don't even answer that same day.
There is lack of communication between the Customer Support team and the engineering team. If someone is unhappy with the product, you rarely hear about it.
You don't know what the rest of your engineering team is doing.

If you have underlined some of these items, you could use some help improving communication within your team.

Actionable items

Public channels over private conversations

It's important to encourage your team to communicate through public channels. If you see that many conversations are happening through Direct Messages rather than through public channels, you should ask the team to stop using Direct Messages for work-related conversations. People should be using Direct Messages only for private issues like health or time off. If people use DM as their default communication channel, that usually leads to other people missing context on things, or not being aware of how things are going. If you hold long technical discussions over DMs, and then you need to include someone else in that conversation, then you have to waste time looping that person in. Instead, if that same conversation was being held on a public channel, you could just point that person to the thread where that conversation was being discussed and that's it. Abusing DMs leads people to sweep things under the rug, or be overly cautious when speaking on a public channel.

Use the @here to communicate high-pri messages

Here are two examples of incorrect communication: (1) Do not ping the entire channel just to say hi or things like that. (2) If there's a fire, do not doubt about pinging everyone in the channel. Most often than not, engineers get anxious over-thinking if they should communicate something or not, don't overthink, just do it. No one is going to slap your wrist.

Always ping people directly

Slack (or any other communication tool) can become quite a hectic place for people who aren't used to it. People don't actively browse the Slack channels and see what is going on; they act only if pinged directly. So, if you need to communicate with someone, ping them directly on public channels.

Use threads to keep the conversation flow tidy

Let’s say that someone pings you on Slack, and you jump to the channel to see that you are 30+ messages behind in an ongoing conversation. It is going to be tricky to figure out what’s going on, and on top of that, the conversation might trail off if someone starts talking about something else in that same channel.

But! If you keep threaded conversations things might be a bit more manageable 👇

This is how that same thread looks when expanded 👇

If you don't keep the conversation flow tidy on Slack, things can get messy really quickly. Try to encourage your team to create threads for every topic they need to discuss.

The team needs some design adjustments on a new feature? Start a thread about that in the #design channel.
The team detected an issue and needs to re-prioritize the current work with the Product Manager? Start a thread.
You have quite a few different ideas about how to fix an issue or implement a feature and cannot decide which to use? Start a thread in the #engineering channel.

It's also helpful to keep contextualized threaded conversations, so you can link the Slack threads to PRs, JIRA tickets, Azure tasks, Trello cards, or Monday tickets to give the people some context about what's going on or what conversation led to the fix.

Using reminders

I use Slack reminders for most of my day. If someone pings me about an issue, but I don't have time to check it right now, I'll put a reminder to check it in about an hour. If someone reaches out to me after office hours, I'll put a reminder for tomorrow morning. If I ask someone to review something, I'll set a reminder for tomorrow to check on the progress. Not just Slack, but every chat platform has some sort of "snooze" functionality, even Gmail does.

Taking notes

How often have you gotten into a Retro meeting and had no feedback to share because you couldn’t remember anything worth sharing? Keeping notes is essential. You can use whatever platform is comfortable for you. I use Notion because I feel it is quite flexible, and it does allow me to keep TODO items and notes everywhere. You can use whatever is comfortable for you, even a Google Doc.

Anything that isn't work-related; things that you would like to improve in the code base. Feedback that you would like to share with your teammates. Ideas for new features. All that should go into your TODOs, so when you have a 1:1 with someone or have a retro meeting, you'll have plenty to talk about.

Cross-team communication

I have often seen engineering teams fail to communicate with non-engineering teams. It is important to educate engineers on how to communicate with other non-engineering teams, such as designers or product managers, so they don't use technical terms and mambo-jumbo that no one understands. Instead of talking about UI widgets, talk about "screens" or "pages". Instead of talking about endpoints and API calls, just call it "fetching data" or "sending a message to the server".

More often than not, people agree or nod their heads to things they know nothing about, out of shame thinking they would look dumb or because they think everyone else already knows what is going on and don’t want to slow down the conversation. So, educate your team to bridge the gap between engineering and non-engineering team communication.

The 500 DON'Ts about Android Development

Agustín Tomas Larghi — Tue, 21 Mar 2023 23:55:20 +0000

FYI There are no 500 DON'ts in here, just random 8 things I was thinking about. The 500 is a reference to this Simpsons episode.

I decided to do a small post about some of the most common mistakes I have seen during my career as an Android engineer.

You will see a little bit of everything here, Kotlin, Android SDK, commonly used third-party libraries, etc. 😉

1️⃣ .let isn't a replacement for if != null

I have seen many engineers misinterpret what the .let function is for and use it like:

data class EspressoMachine(
    val amountCoffee: Int,
    val hasWater: Boolean
)

fun testFoo(espressoMachine: EspressoMachine?) {
    var canPrepEspresso = false
    espressoMachine?.let {
        canPrepEspresso = it.hasWater && it.amountCoffee > 0
    }
    if (canPrepEspresso) {
        // Do something else
    }
}

The let scoping function or the let operator (call it whatever you want, potato-poteto) it lets you run an algorithm on a variable, it is designed to transform a variable into something else.

The correct usage would be something like

fun testFoo(espressoMachine: EspressoMachine?) {
    val canPrepEspresso = espressoMachine?.let { it.hasWater && it.amountCoffee > 0 } 
}

Simple as that, again, let isn't a replacement for the if statement. Also, please do not end up in these kind of situations

fun testFoo() {
    foo?.let {
        boo?.let {
            // Just go with a if (foo != null && boo != null)
        }
    }
}

So Donnie, please don't abuse the .let

None of the scoped-functions are meant to be a replacement for if != null

The same thing applies to any other scoped function, apply, run, let, etc.

For example, the apply lets you apply changes upon an object. For example, if you have something like this 👇

fun testApply(): Intent {
    val someIntent = Intent()
    someIntent.putExtra("foo", 123)
    return someIntent
}

You can easily change it to something a bit more readable, like:

fun testApply() = Intent().apply {
    putExtra("foo", 123)
}

So Donnie, please don't go over the top with the scoped functions and the elvis operator.

2️⃣ Using RecyclerView instead of LinearLayout

I often see engineers try to create a dashboard-like UI using a RecyclerView, where each item is a "section" of the dashboard. This does not scale well and it is not the use case for the RecyclerView. It is far easier, and more scalable to just have a LinearLayout with a bunch of Fragments 👇

  <LinearLayout
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <fragment
      android:name="com.something.company.SectionOneFragment"
      android:layout_width="match_parent"
      android:layout_height="wrap_content"/>

    <fragment
      android:name="com.something.company.SectionTwoFragment"
      android:layout_width="match_parent"
      android:layout_height="wrap_content"/>

    <fragment
      android:name="com.something.company.SectionThreeFragment"
      android:layout_width="match_parent"
      android:layout_height="wrap_content"/>

  </LinearLayout>

If you try to implement this using a RecyclerView, you will have to worry about:

The recycling of the ViewHolders. If one of these "sections" contains an EditText you will be forced to keep track of that value in the Adapter.
The sheer amount of callbacks to communicate back to the UI.

So Donnie, if every item in the Adapter is going to be different, don't go with a RecyclerView use a LinearLayout instead.

3️⃣ Mutable and immutable data

I have seen this with people who are moving away from Java. In Kotlin you have two types of variables, read-only variables (val), and re-assignable variables (var). You also have mutable (for example ArrayList<String>) data, and immutable data (for example Array<String>) data.

Let's try to picture a RecyclerView.Adapter<VH> and think about the data structure we are going to use to model the list.

If we go with a read-only mutable data structure, we can update the items one way only 👇

class MyAdapter : RecyclerView.Adapter<RecyclerView.ViewHolder>() {

    private val myList = mutableListOf<String>()

    fun updateList(newList: List<String>) {
        myList.apply { 
            clear()
            addAll(newList)
        }
        notifyDataSetChanged()
    }
    // ...

If we go with a re-assignable variable and immutable data, there's also only one way to update the list 👇

class MyAdapter : RecyclerView.Adapter<RecyclerView.ViewHolder>() {

    private var myList = listOf<String>()

    fun updateList(newList: List<String>) {
        myList = newList
        notifyDataSetChanged()
    }

But, if we go with both, a var variable and also use mutable data, it kinda defeats the purpose 👇

class MyAdapter : RecyclerView.Adapter<RecyclerView.ViewHolder>() {

    private var myList = mutableListOf<String>()

    fun updateList(newList: ArrayList<String>) {
        myList = newList
        notifyDataSetChanged()
    }

And also notice that now I'm tied to use ArrayList🫠

So Donnie, please use either val with mutable data or var with immutable data.

4️⃣ Too much `lateinit var`

I find that way too many times engineers rely a bit too much on the lateinit operator, it doesn't always guarantee that your variable will be initialized, it is just re-introducing NullPointerException as an UninitializedPropertyAccessException exception. I find it much more safe to go with either using lazy initialization or just initializing the var variable with something. For example 👇

private lateinit var myRecyclerViewAdapter: MyAdapter

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    // ...
    myRecyclerViewAdapter = MyAdapter()
    myRecyclerView.adapter = myRecyclerViewAdapter
}

Instead you could

private val myRecyclerViewAdapter by lazy {
    MyAdapter()
}

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    // ...
    myRecyclerView.adapter = myRecyclerViewAdapter
}

5️⃣ Checking if context != null

It might come as a surprise to some, but there is a whole requiresSomething() API out there for Fragments and Activities so you don't have to null-check things that are late initialized, such as the context. For example:

If you are doing something like

class TestFragment : Fragment() {
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        someButton.setOnClickListener { 
            if (context != null) {
                startActivity(Intent(context, SomeActivity::class.java))
            }
        }
    }
}

You can instead do something like

class TestFragment : Fragment() {
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        someButton.setOnClickListener {
            startActivity(Intent(requireContext(), SomeActivity::class.java))
        }
    }
}

Like this you have the requireActivity() to get the attached Activity or the requireView() to get the root view, quite useful to prompt Snackbars. Do keep in mind that if the context hasn't been initialized, you will get an exception.

So Donnie, no need to null-check everything here.

6️⃣ Observables, Callbacks, and where to use them

There are two widely-use mechanisms to communicate data between components, Callback interfaces and Observables:

Callback

It might be a callback interface like this 👇

data class EspressoMachine(
    val callback: EspressoMachine.Callback
) {
    interface Callback {
        fun onCoffeeReady(isTooHot: Boolean)
    }
}

fun testCallback() {
    val espressoMachine = EspressoMachine(object : EspressoMachine.Callback {
        override fun onCoffeeReady(isTooHot: Boolean) {
            // Do something when ready
        }
    })
}

or you might use high-order functions, like this 👇

data class EspressoMachine(
    private var callback: ((Boolean) -> Unit)? = null
) {
    interface Callback {
        fun onCoffeeReady(isTooHot: Boolean)
    }

    fun setOnCoffeeReady(func: ((Boolean) -> Unit)) {
        callback = func
    }
}

fun testCallback() {
    val espressoMachine = EspressoMachine()
    espressoMachine.setOnCoffeeReady {
        // Do something
    }
}

This is the kind of API that we see in the Android SDK. For example, when you want to set an onclick event 👇

fun testCallback(view: View) {
    // () -> Unit
    view.setOnClickListener { 

    }
    // (View, MotionEvent) -> Unit
    view.setOnTouchListener { v, event -> 
        true
    }
    // (View, Boolean) -> Unit
    view.setOnFocusChangeListener { v, hasFocus -> 

    }
}

So let me ask you something; it is a good practice to keep code homogeneous, right? If you approach a code base where they are using ViewBinding you are not going to start using Butterknife or Kotlin Synthetics, right? – Okay, following that same way of thinking, if you create a custom view, you should keep things homogeneous with the Android SDK, right? That's the idea here.

Observables

So we have a quite a few "observables" out there, RxJava, Kotlin Flow, LiveData, MutableLiveData, the SingleLiveEvent ugly cousin, the (we-got-it-right-this-time) StateFlow and ShareFlow – all these observables address different use cases, some people might argue that you could use them all in the same project, if you use them to address specific use cases, and some people might tell you to just pick one. I'm kinda in the middle. I differentiate between two different use cases:

1# Use Case: ViewModel <> UI comms

You want to communicate data from your ViewModels back to your Activity, Fragment or Composable, right? You have a few options here:

LiveData / MutableLiveData / SingleLiveEvent: The "old" Android solution, I don't see anything bad about going with this option, but keep in mind that you will have to deal with the SingleLiveEvent issue, a swept-under-the-rug Google solution.
StateFlow / ShareFlow: It would be the solution that Google recommends nowadays, and it addresses the SingleLiveEvent issue AFAIK.

2# Use Case: Exposing an API for UseCases / Interactors / Repositories

However you structure your app, I'd like to think that we should not do things like querying the backend API or fetching things from the DB, straight in the ViewModel. Usually, most engineers, create a middle layer, call them Repositories, UseCases, Interactors, whatever you want – basically a wrapper to fetch or submit data. What comes next is to figure out what kind of API these components are going to expose. We have a few solutions out there:

RxJava: You have rx.Observable or rx.Single depending on if your stream is going to emit one (a GET request, for example) or many (actively listening for DB changes) objects. It has a .zip, .contact, .merge API so you can combine streams any way you want. Quite flexible – I did use it a lot before moving to Kotlin Coroutines and Flows.
Kotlin Flow: You have Flow for when your stream is emitting multiple items, and you can use simple suspendable functions for when you expect a one-time response.

This is a very-brief and utterly-simplified version of the kind of data bus solutions we have out there, and I haven't talked about Kotlin Channles and what's the use case for that. Hopefully by now you can dig that there are two types of "observables" the ones used to communicate data from the ViewModels back to the UI, and the one used to expose data from the Repositories / UseCases/ Interactors out to the ViewModels

So, Donnie please –

Don't use Callback interfaces in ViewModels.
Don't use LiveData as callbacks for custom views.
Don't use RxJava observables to expose data from the ViewModels

7️⃣ Re-using UI

The ways in which you can re-use UI on Android are: Fragments, Custom Views, the <includes> tag, and now also
Composables. Each of these has a different use case.

If you want to re-use a completely static piece of UI, then you can go with the <includes> tag. For example, a banner with hardcoded text, or a Toolbar that's the same everywhere.
If you want to re-use a piece of UI that has functionality but the functionality is independent of your business, then you can go with a Custom View. For example, a carousel of ImageViews, anything that makes you think "oh, I could push this up to GitHub as a lib" can probably be done as a Custom View.
If you want to re-use a piece of UI that has functionality and that functionality is closely related to your business, then go with a Fragment. For example, you prompt a screen during onboarding so the user can invite people to download your app, and you also want to prompt the same screen within the app.

So Donnie, don't re use UI using ViewHolders or anything else.

8️⃣ Incorrect usage of LiveData + Coroutines

I have seen some people do things like:

sealed class State {
  data class Loading(
    val isLoading: Boolean
  ): State()
  data class DataSuccessfullyFetched(
    val someData: Data
  ): State()
  object ErrorFetchingData : State()
}

val state = MutableLiveData<State>() // Or SingleLiveEvent 

viewModelScope.launch(Dispatcher.IO) {
   state.postValue(State.Loading(true))
   val response = someRepository.fetchData()
   if (response != null) {
     state.postValue(State.DataSuccessfullyFetched(response))
   } else {
      state.postValue(State.ErrorFetchingData)
   }
   state.postValue(State.Loading(false))
}

We want the state property to go through the State.Loading(true) state, then either State.DataSuccessfullyFetched(response) or State.ErrorFetchingData and finally State.Loading(false), right?

Well, what's going to happen is that the state property is just going to "broadcast" the last set value, State.Loading(false).

The issue here is that you shouldn't be using postValue – "but if I use setValue instead I get a background thread error message", that's correct, because you shouldn't be using the Dispatcher.IO at all, the only thing that needs to run on a "background thread" is the fetchData() suspendable function, which you created as:

suspendable fun fetchData() = withContext(Dispatcher.IO) {
  ...
}

What we should actually be doing is 👇

...
viewModelScope.launch {
   state.value = State.Loading(true)
   val response = someRepository.fetchData()
   if (response != null) {
     state.value = State.DataSuccessfullyFetched(response)
   } else {
      state.value = State.ErrorFetchingData
   }
   state.value = State.Loading(false)
}

So Donnie, using Dispatcher.IO doesn't make things magically run in the background thread, also just adding the suspendable keyword to a function doesn't make that function run in the background either. There is no reason why we should use the postValue in the ViewModel

Sorry, I lied, there are no 500 don'ts 😜 – Many of the things I pointed out here are up to personal criteria, you can use a knife as a fork if you want, you would probably still be able to pick up the food, no one can stop you. You might also want to use your underwear as a hat – and some people might even think you are cool! – but I'm not sure people will feel totally comfortable around you 🤷.

Anywho, hope you liked it! 😉

Is Jetpack Compose ready for production development?

Agustín Tomas Larghi — Wed, 09 Nov 2022 20:07:22 +0000

What's this about?

Hi everyone! 👋

I'm a senior Android engineer who is diving into Jetpack Compose, I'd like to share my experience so this help anyone else going through the same situation. This is probably going to be the first of many posts.

At this point, everyone knows what Jetpack Compose is about. I’m writing this article to help me figure out if I should start using Jetpack Compose or not – to figure that out I have gone through a little exercise where I have developed a few screens using XML and then see how long it would take me to implement that same UI with Jetpack Compose. Hopefully this article might help you a little in your own journey with (or without) Compose!

There are many opinions out there about Jetpack Compose, at both ends of the spectrum, some people love Jetpack Compose unconditionally and some hate it. I try to be neutral and look at both sides equally. I have been doing mobile development for the last 10 years and have grown very cautious about the technologies I pick, my main goal is to use technologies that are comfortable for everyone and not to get the whole team nerd-blocked just because we got caught in the hype of a new technology.

To make this article a bit more digestible I have recorded a video explaining what I found so far 👇

The experiment 🧪

I built a simple app that goes through some of the common scenarios that we see during our day-to-day development.

These are the XML screens:

And these are the Compose equivalent screens

First, we have a simple list that I build with a RecyclerView + CoordinatorLayout so I could hide/show that FloatingActionButton, all this done through XML.

Second, we have a bit more complex screen, we have a Google Map Fragment wrapped inside a CoordinatorLayout where we have two FloatingActionButton, the left FloatingActionButton triggers a layout using the BottomSheetBehavior from the CoordinatorLayout and the right FAB triggers a BottomSheetDialogFragment.

Finally, we have a WebView with a loading layout on top.

You can check the code in this GitHub repository.

The results 📈

It took me three hours to implement the XML UI and most of the behaviors, like hiding or showing the FloatingActionButton when we scroll or the bottom sheet behavior in the Google Maps page, all that was done through XML using a CoordinatorLayout.

Learning curve 📚

Learning the basics about Jetpack Compose, implementing those same screens, and finally comparing my code to other GitHub repositories took me three to four days. Maybe it is because I already have Android development experience or the Dunning–Kruger effect (it probably is), but I have to say, learning Jetpack Compose has been really simple so far, if one of the goals for Jetpack Compose is to make UI development easier, they have definitely nailed that.

The sources I have used so far are:

Stevdza-San YouTube Channel: I found this playlist very helpful to learn the basics of JetPack Compose. If you don't know anything at all, this is helpful to introduce you to the basic Compose concepts, like State Hoisting and the basic layouts.
Philipp Lackner's YouTube Channel: Great playlist to add on top of the previous one. Also this MVVM tutorial is great to see all these pieces come toghether.
Jetpack Compose Playground: Once you have gone through the basic concepts related to Compose, this GitHub repository has a good amount of content to learn more about each Composable.

Once I had some basic understanding of how Composables work, I compared my solution to some other apps out there — a good thing about Compose is that there is no shortage of Compose clone-apps out there.

Things I like so far 👍

I think it might be easier for new devs to learn Jetpack Compose instead of XML: I'm quite comfortable with XML, but that's because I have years of experience behind me, I know all the recipes, tricks and hacks — sure, if you know your way around XML you can probably create features faster than with Jetpack Compose, but not everyone knows all the tricks about CoordinatorLayout or how to use all the layout_behaviors, things like that.
It unifies everything: I got to learn SwiftUI before Jetpack Compose, and I can see how all these technologies are moving towards declarative UI — iOS with SwiftUI/TCA, Android with Compose/MVVM, Flutter, and React.
I like being able to preview each component individually: Sure, you could argue that you can achieve the same thing if you extract your layouts and use the include tag with the tools namespace on top of that, but still, I can see Compose UI being less prone to conflicts when submitting code, if you are tidy enough.

Things I didn't like that much so far 👎

The preview: I think the Composable preview on Android Studio still needs some work. The exercise we have gone through is just a simple single-module app, but if the Android Studio preview needs to build the entire project in order to preview your Composables, this could be an issue on large production-level projects where you have longer building times. Also, a few things got me thinking; I've seen some people say that they actually create an independent UI module just to use as a playground to build the Composables and then copy-paste them into the main project[1] — a good workaround, but a workaround nonetheless. Also, I was a bit surprised to see that if you develop desktop UI using IntelliJ + the Jetpack Compose Preview plugin, it actually previews faster than on Android Studio [2][3].

I miss the CoordinatorLayout: I think the CoordinatorLayout is one of the, if not the most, powerful layouts. You can achieve common UX behaviors just from the XML. I guess the Compose equivalent would be the Scaffold, but I don't see it is as flexible or as powerful as the CoordinatorLayout yet.
The MotionLayout future: AFAIK the MotionLayout will eventually be incorporated into the Compose SDK, but right now is under alpha development [1][2]. I hope that whatever happens, we get to keep the scene editor, I had to implement some quite tricky animations in the past and the MotionLayout was a lifesaver — being able to preview each frame of the animation, is extremely helpful.
More @OptIn annotations than I had expected: All the examples I have gone through so far use ~~some experimental features~~ APIs that might go through changes in the future [1] from either Compose or Material. I'm sure you can use workarounds or alternative solutions to avoid using these APIs, I guess I could have done something else instead of using the BottomSheetScaffold, but still, I was expecting the API to be more mature at this point. Edit: Apparently, the @OptIn annotation is very commonly used in Compose right now, it means that the API is likely to go through breaking changes in future versions, but it doesn't mean the API is untested or unreliable.
No WebView support so far: The only way to use a WebView is to bridge the Android SDK WebView into Composable using the AndroidView Composable.

Who else is using Jetpack Compose out there?

Twitter has moved some of its UI modules to Jetpack Compose — I highly recommend watching Chris Banes' talk during Droidcon 2022.

Airbnb did start working with Jetpack Compose during the early preview[1]. They have also developed a library to easily browse all the Composables within your app[2] — Vinay Gaba, Airbnb Tech Lead, is one of the biggest Jetpack Compose advocates. I recommend watching his Jetpack Compose by Example GitHub repository and going through his Compose Snippet library, which looks like it has potential to become Android Arsenal future successor 😜.

Some other companies that I'd like to highlight are Lyft and Square.

I've also been doing some sleuthing myself — I want to figure out if there are other companies out there using Jetpack Compose. To do that I downloaded the apk binaries from Spotify, TikTok, Uber Eats, WhatsApp, Reddit and decompile them with jadx.

First, just to be sure that I could compare correctly, I decompile both the Airbnb app and the Lyft app.

We can see that both, Lyft and Airbnb, they both have references to the Jetpack Compose packages androidx.compose.*

Spotify, TikTok and WhatsApp did not have any references to Jetpack Compose that I could find 😕

Uber Eats did have some references to the Jetpack Compose library so it might be possible that they are using it somewhere.

Finally, it looks the Reddit app also uses Jetpack Compose — again, seeing these references doesn't really mean much, they might be just experimenting with Jetpack Compose in one place or two.

Things I want to try next

I still have a lot to learn. Some of the things I'll be playing with next are:

Testing Composables: I'm a big Robolectric fan and I've heard only good things about testing Composables. I'm eager to see how it plays out.
Is there any ViewPager2 equivalent?: I'm guessing you can implement the equivalent behavior with a LazyRow, but I haven't tried this yet. I also want to play with the Accompanist's Pager lib — I understand it was developed as a replacement for the ViewPager.
Pagination: Pagination with the RecyclerView is as simple as initializing a custom RecyclerView.OnScollListener and referencing the LinearLayoutManager to know when to hit the ViewModel and request the next batch of items — I want to see how complex (or not) it would be to do this with a LazyColumn.
Architect a more scalable solution: This experiment has just gone through a little UI and nothing else. I'll architect a serious production-level architecture that allows engineers to create new screens independently with XML or Compose and see what results I get.
Canceling API calls: Most Image Loading libraries like Glide or Picasso allow you to cancel the API calls when fetching an image from the network — if you are using a RecyclerView you can cancel any API call as soon as you dispose the ViewHolder that way you don't push unnecessary API calls, I want to see if I can achieve the same with a LazyColumn.
Is it necessary to use the Jetpack Compose Navigation library? I'm not a big fan of the Navigation library and I'd like to figure out if it is really necessary. Also, what is the expected architecture? One Activity per screen? One Fragment per screen?
Try the Accompanist’s libs: Try the SwipeRefreshLayout, WebView and ViewPager replacements from the Accompanist library. If I understood correctly, this library will be eventually integrated into Jetpack Compose.
Review the official docs: These API do change and the most up-to-date place are the Android docs.

tl;dr

I think Jetpack Compose is the future of Android development, but I do not think it is wise to rely 100% on it. I would use it on my next project, but I think it is wiser to architect a solution that allows you to use both Compose or XML when you want, so if you run into a situation where a Compose solution isn't doable, you can default to XML.

I am very cautious when updating my tech stack, I do not like to make life any harder for my co-workers, and I do not like opt-in to new technologies just because they are trendy, that being said — moving from Java to Kotlin was a good thing, moving from MVP to MVVM was a good thing, and moving from Eclipse to IntelliJ was a good thing, now the time to move to Jetpack Compose has come.

I do not think XML will go extinct anytime soon, not this year or next one or the one after, but in 5 years? Who knows? Is there anyone else out there actually using Java nowadays? — probably, and probably you would not be too comfortable working with that code base. Same thing is going to happen with XML.

Feedback! 🙇🙇🙇

Thank you so much for reading this article! Please, let me know what you think and feel free to point out any errors so I can correct them immediately. Also, if there's some topic that you think I should cover next, let me know. Best!

Software shenanigans

Agustín Tomas Larghi — Tue, 31 Aug 2021 13:49:31 +0000

I've decided to start a new series of posts ("Software shenaningans") oriented to soft-skill improvements, communication, how to coordinate things with your team, the kind of things that - opposite to software technologies - won't get outdated.

Since the pandemic started, I've noticed many companies have turned onto remote work, yet many people are not used to working remotely. So I thought about writing a quick post about a few things I've learned to improve productivity when working remotely.

FYI, I've been working remotely most of my career, even before COVID, so most of the things I'm going to talk about here come from my remote work experience.

I've seen many talented engineers fail because of communication issues, sometimes because they can't communicate their ideas properly, but more often than not it is because of their own insecurities. I've seen engineers get anxious over having to ping a manager, schedule a meeting, or do an @here on the Slack general channel. I'd like to think that I'm very loud on Slack, I'm not afraid of hitting that @here to get people in sync, and no one ever has slapped my wrist by doing so. No one is ever going to yell at you because you are trying to express your ideas.

If you are an over-thinker here’s a simple diagram to help you figure things out.

Let's go through some examples:

Is this okay? 🙅‍♂️ No, don't ping the whole channel just to say hello. Is it okay - and I encourage - being cheerful and polite, but don't disrupt people unnecessarily. Thinks that as soon as you do an @here you will have most people on that channel context switch from whatever they were doing onto Slack.

Is this okay? 🙅‍♂️ No, if things are getting on 🔥 ping everyone, the faster you all address the issue, the better. Again, think that most people when they look at Slack they will see something like this 👇

All channels highlighted all the time, unless you ping people directly, chances are they won't notice what you just write until the end of the day 😕.

Is this okay? 👍 Yes, the same thing we were talking about before, if you need someone to take immediate action on something that is blocking you, ping that person directly.

Yet More Slack tips

1️⃣ Keep 🧵 conversations

If you don't keep the conversation flow tidy on Slack, things can get messy. For example, picture you jump on the #engineering channel, and you see you are 30-something messages behind this convo 👇

Not easy to catch up, right? For new people joining this conversation, it may be hard to get the context of what's going on when you don't know where the conversation started. And it will very likely take you a considerable amount of time until you do catch up. Plus, things can get muddy if other people are talking about different things.

Keeping threaded conversations may mitigate this issue 👇

Also, you can later link this conversation to Jira/Azure/Trello tickets - or whatever CMS your team uses - for future reference. Same for the PRs, you can link the Slack conversations so whoever reviews your PR can have a little bit of context about what the changes are for.

I'm a big fan of using PR templates, and linking the Slack convos to the PRs gives much more context to the person doing the review.

2️⃣ Using the /remind command

Usually, on my day-to-day, I do almost all my work following the reminders of the day before. The /remind me command is quite helpful to keep track of things.

Let's say you were discussing something with someone and you need to follow up later 👇

You can target the /remind command to different people or channels, not just to yourself.

For me this is the most powerful tool on Slack.

3️⃣ Grouping channels into sections

As we were saying before, most of us, when we open Slack in the morning, the first thing we see is just a humongous list of highlighted channels. Some of them we don't even care - for example, a #random channel just for fun, channels that are completely unrelated to the work we do, etc.
So instead of having to waste time going through each channel, sort out the channels by priority using sections.

Something like this 👇

Becomes this 👇

That way you can check the truly important channels first, and if you have time, go through the rest later.

4️⃣ Rule of thumb

Avoid DMs as much as possible. Try to post on public channels as often as possible, in my experience, teams who communicate through public channels perform better than the ones who rely mostly on DMs. Think that if you are discussing something with someone else via a private DM 🅰️ other people won't be able to catch up with what you are talking about, you may be talking about some technical adjustments in the back-end with just one single engineer, what if some other engineer had something to say about but he couldn't because he didn't know about this conversation? 🅱️ Also, you cannot link or reference private DMs, if someone new joins the DM he won't be able to see any previous conversation.

Finally, speaking on public channels encourages people to speak up, be more transparent, and it removes that feeling that some people have of--"Oh, I better not talk about this here so I don't open a can of worms!"

Always try to ping people directly. It is unlikely that people will reply immediately to you if you don't ping them directly 👇

I've seen so many people so quick to jump the 🔫 and hit the SEND button way too soon when sending emails. A bad email can cause more confusion than anything else, and if the tone set in the email sounds rude it can complicate things even further. So, I'll just drop some tips I've found useful:

Read your emails aloud before you send them. The tone in an email is key. I remember once I had this lengthy email thread going on with a back-end engineer from a contractor company working with us. We would only talk via email, so that made things even more difficult. And these guys were working in a completely opposite time zone than ours, so it was basically sending an email, and waiting for the response to come back the next day. I'm not going to lie, I was getting annoyed by the whole situation 😅.
The whole thread was about us asking for some credentials to use an SDK in the front-end, and we were going back and forth with the back-end guys because they would provide the credentials but this wouldn't work as expected. So at some point, I replied something like this 👇

John, I know this is doable because I've seen it in the documentation here: http://somelink-to-some-documentation.com

Of course, one minute after hitting send, I'm pinged via Slack by one of my Engineer Managers - and rightly so - and he asks me to read my response aloud, and then I realize that I'd completely dropped the ball. The tone was rude, and it didn't get us any further into solving the issue.

Double check names. Many people, myself included, can get annoyed when other people misspell their names. Just take a minute to double-check that you have correctly written the name of the person you are addressing. Once, in one of my previous jobs, I was helping a new hire, a new Android engineer getting on board. We would talk over email because he didn't have his Slack credentials set yet. I usually go that extra mile when onboarding someone because I want them to have a pleasant experience. But this person would keep misspelling my name on every email. Augustin instead of Agustin. So, I let the first email pass. Then in the second email, I bold my signature so he could see my name. The same thing again, so I finally add a PS on the third email -- "FYI my name spells Agustin 🙂". So, take that extra minute to double-check names. Don't skip accents on the letters. Otherwise, it looks as if you don't care about the email content.

If you are not a native speaker, use some tools to enhance your grammar. A text with spelling mistakes won't be taken as seriously as one that's not. There are some great tools out there to avoid common grammar mistakes. Like Grammarly or Ginger. Both are great tools to prevent those little details, that especially us who are not native English speakers, often do.

A good intro is a nice way to start a new job with the right foot. I always encourage people to present themselves when they are about to join a new team, just doing a quick intro on the Slack #general 👇

I would even recommend that you ask your manager if it would be okay to send an email to your whole team presenting yourself more in detail 👇

And you know, try to be personal, don't be like -- "Hi, I'm Agus and I like coding, and coding is also my hobby". I don't think anyone has so little going on in their lives. Also, sometimes using emojis helps to set the emotional tone in a message.

1️⃣ Always have your camera turned on. Seeing someone else's face on the screen helps people connect more, and it also helps you being taken more seriously by your teammates. I mean, if someone has their camera turned off, you don't know what they are doing, right? Are they paying attention to what you're saying? Are they watching Netflix?
If you feel uncomfortable by having 50 people stare at you through your webcam during a meeting, just switch tabs. I often do that if I have to talk at a meeting where I know there's going to be a lot of people, I just switch tabs so I don't have to see the amount of users or anything else, but I keep my cam turned on so everyone else can see me.
It is okay if you don't want to turn on your webcam during a meeting because you're having lunch - although I don't recommend having lunch in front of your laptop, it's not healthy 🙂 - or because of something else. But do so once you've become comfortable with your team.

2️⃣ If you are in a noisy environment use audio filtering.You can buy a headset with noise filtering included or use audio filtering software such as Krisp. Most people won't even tell you if you have noise in the background out of shyness or because they think it would be disrespectful. So, make sure no one has to try to figure out what you are saying behind the barking of your 🐕.

3️⃣ If you need to say something, but feel uncomfortable interrupting people, use the chat section.

4️⃣ Watch out for the "radio silence" during conversations. When you start working with a new team where each member knows little to nothing about each other, or if you start working with a team that isn't used to work remotely, you may run into those uncomfortable situations where someone asks a question, a minute goes by, and no one answers. Then, what can we do to solve these situations?

For example, let's say we are on a Zoom call, and one of the front-end engineers asks a question like:-" How is the UX supposed to look like when we navigate into this section, and there's no internet connectivity?" Let's say 10 seconds go by then:

1️⃣ If you think you know to answer the question, answer it. It doesn't matter if you think it would be a dumb answer, it will prompt someone else to chime in.
2️⃣ Redirect the question to someone who may know how to answer the question. For example, if a front-end engineer wants to know how to implement the UX for a specific edge-case scenario, redirect that question to one of the designers.
3️⃣ If no one knows how to answer the question, they are taking too much time, or just going back and forth, then park the convo and propose to follow up on a Slack thread later.

Something else to keep in mind is that these situations may be a direct result of a lack of ownership across team members. It takes time and effort to boost people into taking more ownership, this is something that the team achieves through regular 1:1 meetings and giving honest feedback to each other.

Reach out to people. Don't overthink about sending messages or scheduling a meeting with your teammates. That's what we are paid to do.
Don't be an emotionless drone. Talk to people over Slack as if you were in a real office.
Step up, have ownership of the product. Even if sometimes you think it is not your responsibility to lead some initiative or organize something, just do it. It will make everyone’s work - including yours - easier in the future.

A production-level architecture for Android apps (part 2)

Agustín Tomas Larghi — Sat, 15 Feb 2020 22:07:36 +0000

A production-level architecture for Android apps (part 1)

Agustín Tomas Larghi ・ Feb 15 '20

#android #architecture #kotlin #mvvm

Index

Context
Layers
DataSources
Repositories
Interactors
ViewModel
View
Notes
Next

Context

We are going to go through all the different layers of the architecture, explaining what’s the protocol and the logic of each layer. The protocol is what the layer exposes to the above layer. The logic of the layer is what the layer is supposed to do internally.

Layers

“This architecture looks like an overkill, you can achieve the same thing using less layers, and it will scale properly.”

It may, it may not. I’m used to working on large-scale projects, where the requirements may change from one day to the next, where you may have to tweak features all the time. That’s why I try to go with the most flexible architecture possible. This is what I’ve been using and it has worked fine for me. I prefer to waste 5 minutes creating some extra classes today, that spend 1 day trying to wire something up, so it just works.

Datasources

Protocol

The protocol of the data sources is pretty straightforward, fetch data from somewhere.

Logic

There are only two places from where we can fetch information, from the network (through API endpoints or some other service) or from the cache (either through something like the SharedPreferences, a database, or some other local source)

Network Logic

Fetching information from a backend API through RESTful endpoints. For this example, I’m using Retrofit. There are some other tools out there like Volley, but discussing the pros and cons of each tool goes beyond the scope of this article.

Code example

With Retrofit, you usually just declare an API Interface that represents the available endpoints.

/**
 * Retrofit's interface that we use to communicate with a mock API hosted on apiary.io
 */
interface ExampleApi {
    /**
     * Fetches a paginated response containing the news.
     */
    @GET("news")
    fun fetchNews(
        @Query("page") page: Int
    ): Single<Response<ApiNewFeedListResponse>>

    /**
     * Fetches the most recently viewed news.
     */
    @GET("news/recent")
    fun fetchRecentlyViewedNews(): Single<Response<ApiNewFeedListResponse>>

    /**
     * Fetches the user profile information
     */
    @GET("profile")
    fun fetchProfileInfo(   ): Single<Response<ApiProfileResponse>>

    /**
     * Fetches the user business skills
     */
    @GET("business")
    fun fetchBusinessSkills(): Single<Response<ApiBusinessSkilssResponse>>

    /**
     * Fetches a list of cooking recipes
     */
    @GET("recipes")
    fun fetchAllRecipes(): Single<Response<List<ApiRecipeResponse>>>
}

ExampleAPI interface to fetch information from a mock API hosted on ApiAry.

/**
 * Retrofit's interface API that we use to communicate with the Imgur API.
 */
interface ImgurApi {

    /**
     * Fetches the comments associated with one particular post.
     * @param id The id of the post.
     * @param sort "best" if we want to fetch the comments sorted by the most up voted. "new" if
     * we want to fetch the comments sorted by date.
     */
    @GET("gallery/{id}/comments/{sort}")
    fun fetchComments(
        @Path("id") id: String,
        @Path("sort") sort: String // best, new
    ) : Single<Response<ApiCommentsResponse>>

    /**
     * Fetches the posts using the specified search criteria.
     * @param sort "top" If we want to fetch the latest posts. "viral" If we want to fetch the
     * most trendy posts.
     * @param window If sort equals "viral" this parameter gets ignored. If sort equals "top" we
     * can specify if we want to fetch the most important posts from this "month", "day", or "week"
     * @param query The search query.
     * @param page The page number, starts from 1.
     */
    @GET("gallery/search/{sort}/{window}/{page}")
    fun searchGallery(
        @Path("sort") sort: String = "top", // viral, top
        @Path("window") window: String = "all", // if sort == top { day, week, month }
        @Path("page") page: Int = 1,
        @Query("q") query: String = ""
    ) : Single<Response<ApiImgurGalleryResponse>>

    /**
     * Fetches the posts using a tag.
     * @param sort "top" If we want to fetch the latest posts. "viral" If we want to fetch the
     * most trendy posts.
     * @param perPage Max amount of results per page.
     * @param tag The tag query.
     * @param page The page number, starts from 1.
     */
    @GET("gallery/t/{tag}/{sort}/{page}")
    fun searchTags(
        @Path("sort") sort: String = "top", // viral, top
        @Path("page") page: Int = 0,
        @Path("tag") tag: String = "",
        @Query("perPage") perPage: Int = 20
    ) : Single<Response<ApiImgurTagResponse>>
}

ImgurAPI interface that we use to fetch image posts from through the Imgur API.

Notice that on each API call we return a rx.Single, that’s because when we hit an API endpoint we send a request and get a single response.

The second step is to expose the Retrofit dependency to all our other dependencies, we do this through the network modules (ExampleNetworkModule and ImgurNetworkModule) and the RetrofitModule.

On the network modules we build the REST client and we configure all the things that we need.

@Module
class ExampleNetworkModule {
    @Provides
    @Singleton
    fun provideGson(): Gson {
        return GsonBuilder()
            .setFieldNamingPolicy(FieldNamingPolicy.LOWER_CASE_WITH_UNDERSCORES)
            // Gson deserializer to deserialize dates from the Imgur API
            .registerTypeAdapter(Date::class.java, DateDeserializer())
            .create()
    }

    @Provides
    @Singleton
    fun provideOkHttpClient(): OkHttpClient {
        val builder = OkHttpClient.Builder()
        return builder.build()
    }

    @Provides
    @Singleton
    fun provideRetrofit(okHttpClient: OkHttpClient, gson: Gson): Retrofit {
        return Retrofit.Builder()
            .baseUrl("http://private-cc89a2-examples21.apiary-mock.com/")
            .addConverterFactory(GsonConverterFactory.create(gson))
            .addCallAdapterFactory(RxJava2CallAdapterFactory.create())
            .client(okHttpClient)
            .build()
    }
}

ExampleNetworkModule where we provide all the dependencies that we need to fetch data from the ApiAry backend.

@Module
class ImgurNetworkModule {
    @Provides
    @Named("authInterceptor")
    fun providesAuthInterceptor(): Interceptor {
        return Interceptor { chain ->
            var request = chain.request()
            request = request.newBuilder()
                .header("Authorization", "Client-ID 6ea78556ea84b48")
                .build()
            chain.proceed(request)
        }
    }

    @Provides
    @Singleton
    @Named("imgurOkHttp")
    fun provideOkHttpClient(
        @Named("authInterceptor") authInterceptor: Interceptor
    ): OkHttpClient {
        val builder = OkHttpClient.Builder()
        builder.addInterceptor(authInterceptor)
        return builder.build()
    }

    @Provides
    @Singleton
    @Named("imgurRetrofit")
    fun provideRetrofit(
        @Named("imgurOkHttp") imgurOkHttp: OkHttpClient,
        gson: Gson
    ): Retrofit {
        return Retrofit.Builder()
            .baseUrl("https://api.imgur.com/3/")
            .addConverterFactory(GsonConverterFactory.create(gson))
            .addCallAdapterFactory(RxJava2CallAdapterFactory.create())
            .client(imgurOkHttp)
            .build()
    }
}

We use Gson to deserialize the endpoint’s responses and turn them into backend model classes (naming convention ApiSomethingResponse). We provide the OkHttp client that the Retrofit instance is going to use as their HTTP client. And finally, we provide the actual Retrofit instance that we are going to use to instantiate the API interface.

Notice that in the ImgurNetworkModule we need to provide an OkHttp instance that authenticates against the Imgur API. We need to provide different Retrofit instances on both modules, since one points to the Imgur base host and the other to the ApiAry host. Also, notice that we actually reuse the same Gson instance for both modules.

Then we have the RetrofitModule where we provide the API Interface instance for both the Imgur API and the ApiAry API.

@Module
class RetrofitModule {
    @Provides
    @Singleton
    fun provideExampleApi(
        retrofit: Retrofit
    ): ExampleApi {
        return retrofit.create(ExampleApi::class.java)
    }

    @Provides
    @Singleton
    fun provideImgurApi(
        @Named("imgurRetrofit") imgurRetrofit: Retrofit
    ): ImgurApi {
        return imgurRetrofit.create(ImgurApi::class.java)
    }
}

Cache Logic

Fetching information locally, either through the SharedPreferences, a DB or some other source. For this example, I’m using Room. There are some other tools that you can use like Realm or SQLDelight.

Code example

There are a few classes that we need to implement when setting up Room. The first is the RoomDatabase class, that basically handles the DB creation:

@Database(
    entities = [DbRecipeDto::class],
    version = 1,
    exportSchema = false
)
@TypeConverters(Converters::class)
abstract class ExampleRoomDatabase : RoomDatabase() {
    companion object {
        fun create(context: Context, useInMemory: Boolean): ExampleRoomDatabase {
            val databaseBuilder = if (useInMemory) {
                Room.inMemoryDatabaseBuilder(context, ExampleRoomDatabase::class.java)
            } else {
                Room.databaseBuilder(context, ExampleRoomDatabase::class.java, "example.db")
            }
            return databaseBuilder
                .allowMainThreadQueries()
                .fallbackToDestructiveMigration()
                .build()
        }
    }

    abstract fun recipesDao(): RecipesDao
}

Then we need to create the classes to map the database responses (naming convention DbSomethingDto) into objects.

@Entity(
    tableName = "db_recipe_dto",
    indices = [Index(
        value = ["id"],
        unique = true
    )]
)
data class DbRecipeDto(
    @PrimaryKey
    val id: Int,
    val name: String,
    val ingredients: List<String>,
    val isBookmarked: Boolean = false
)

In this example, we are mapping a table that stores information about cooking recipes.

Next, we have to create the DAO to query the information from the database (naming convention SomethingDao).

@Dao
abstract class RecipesDao {
    @Query("SELECT * FROM db_recipe_dto")
    abstract fun getAllRecipes(): Flowable<List<DbRecipeDto>>

    @Query("SELECT * FROM db_recipe_dto where id = :id")
    abstract fun getRecipeById(id: Int): Flowable<DbRecipeDto>

    @Insert(onConflict = OnConflictStrategy.IGNORE)
    abstract fun storeRecipes(
        dbRecipeDtos: List<DbRecipeDto>
    ): Single<LongArray>

    @Update
    abstract fun updateRecipes(dbRecipeDto: DbRecipeDto): Single<Int>
}

Notice that if we want to keep track of the database changes we use Flowables to stream the query’s results. If we don’t care or if we want to listen for the results just once, we can use rx.Single.

Repositories

Protocol

The repository protocol is to expose data from the data sources through a unified reactive interface (rx.Obsevable). This data may come from the network layer, because we hit some endpoint, or may come from the cache layer because we ran some query on a database or fetched something from the database.

Logic

It fetches the data from the data source and wraps the response with a DataResponse¹ class. This DataResponse class is used to carry around any information that we may need about the origin of this data (if it’s a cached response, if it came from the backend through a 304, or if it came from the backend through a 200, etc.)

Code example

Let’s say that in our example app we need a repository to access all the information related to the news.

Keeping in mind that we have these two endpoints:

    /**
     * Fetches a paginated response containing the news.
     */
    @GET("news")
    fun fetchNews(
        @Query("page") page: Int
    ): Single<Response<ApiNewFeedListResponse>>

    /**
     * Fetches the most recently viewed news.
     */
    @GET("news/recent")
    fun fetchRecentlyViewedNews(): Single<Response<ApiNewFeedListResponse>>

Then the interface (protocol) of our repository would look like:

interface NewsRepository {
    fun fetchRecentlyViewedNews() : Observable<DataResponse<ApiNewFeedListResponse>>
    fun fetchNews(page: Int) : Observable<DataResponse<ApiNewFeedListResponse>>
}

Notice that the only thing that these repositories are supposed to expose are rx.Observables, doing that we are able to plug different repositories that fetch information from different sources through RxJava.

The actual implementation (logic) of our repository would look like:

class NewsNetworkRepository (
    private val retrofitApi: ExampleApi,
    private val uiScheduler: Scheduler,
    private val backgroundScheduler: Scheduler
) : NewsRepository {
    override fun fetchRecentlyViewedNews(): Observable<DataResponse<ApiNewFeedListResponse>> {
        return retrofitApi.fetchRecentlyViewedNews()
            .toDataResponse()
            .observeOn(uiScheduler)
            .subscribeOn(backgroundScheduler)
    }

    override fun fetchNews(page: Int): Observable<DataResponse<ApiNewFeedListResponse>> {
        return retrofitApi.fetchNews(page)
            .toDataResponse()
            .observeOn(uiScheduler)
            .subscribeOn(backgroundScheduler)
    }
}

The toDataResponse() function, is just an extended function from rx.Observable that wraps the stream on a DataResponse.

Why making the Repositories return rx.Observables?

You need your repositories to have a sort of plug-and-play behavior. That means, using a reactive API (zip, flatMap, merge, concat, etc.) so you are able to combine different repository calls within your Interactors.

For example, if you need to create an Interactor that’s going to return both, the recently viewed news and all the news, you can zip the fetchRecentNews() and the fetchNews(page) calls together.

Another example, if you need to hit one endpoint and based on the response from that endpoint, hit another endpoint, you can just flat map the calls from both repositories and that’s it.

That’s wrong, if you have to zip two API calls together, you should get the backend to return both responses together through one single endpoint.

Again, these are real-world scenarios, and unless you’re working for a company that solely relies on mobile as its source of income (Uber, Instagram, WhatsApp, etc.) mobile is probably going to be a second-class citizen. Meaning that you may not get all the endpoints that you need. That’s neither good nor bad, it is just how it works. But if you have to juggle API calls together, better to keep it tidy.

Why using a response wrapper?

I’ve found that using a wrapper class to keep track of the origin of the data is very useful. That DataResponse wrapper that we have there is just a simple class that keeps track of where the data is coming from.

For example, let’s say that you want to do one thing if a specific endpoint returns a 401 (Not Authorized) and another if the endpoint returns a 500 (Internal Server Error). You can do that just by looking at the DataResponse wrapper.

Another example, let’s say that you’re storing the information on a cache layer if the endpoint replies with a 304 (Not Modified) you want to skip that from being stored on cache (because it’s the exact same information that you already have, so it’s going to be a waste of time storing that information gain). So using a wrapper class to keep track of the source of the information may come handy when trying to handle some specific scenarios.

Why do you separate your repositories into interface and implementation?

That's something that I got used to from working with clean architectures. I can't say that it's super useful all the time, but I do like the idea of having a contract between a component's protocol and its implementation. Even if requires some extra work.

Interactors

Protocol

The interactor protocol is to expose data to the ViewModels through a callback interface. The data that we expose from the interactor to the ViewModel goes as model classes. While on the repository layer we may return backend model classes (ApiSomethingResponse) from the network API or database responses (DbSomethingDTO) from the database, the interactor returns plain model classes. By doing this we completely decouple the backend responses, the database responses and the actual model classes that we use across the app.

That looks like an insane amount of work, keeping three different model classes for the backend responses, database responses and for using on the app. Why not just use the same class to map the backend responses (through Gson) and keeping the database tables?

Like many other topics that we talked about in this article, most of the layers are totally customizable. If you think that it is better to use one single model class for mapping the backend responses, the database tables, and for use across the app, you can do it. My personal experience tells me otherwise. Things may change on the backend, new fields may get exposed, some fields may get removed, you may need to track specific fields within the database, etc. I prefer to code a bit more of boilerplate code and be ready for changes that stick with a short solution and risk reliability.

Logic

An interactor uses one or more repositories to perform an action, this may be something like calling two different endpoints, wait for them to reply, and then return that information through the callback interface.

Why using a callback interface here? Shouldn’t we expose a rx.Observables?

My personal experience is that it is better to hide everything related to RxJava beneath the interactor layer. If you are working on a large-scale project you may have some junior developers on the team, and working with technologies such as RxJava it’s a bit tricky for inexperienced developers. I find it more comfortable to keep all this hidden beneath the interactor layer, that way the most senior developers can word developing the interactors, and then the developers with less experience can just use them on the ViewModels.

Also, it saves you a bit of boilerplate code. Let’s say that you need to zip two repositories together to fetch data and show it on an Activity. If have to do the same thing again on some other Activity you would have to duplicate the code for zipping those repositories.

And finally, I think it looks tidier to have some sort of contract (callback interface) between the use cases and the ViewModels.

Code example

This is how the interface (protocol) of the interactor looks like:

/**
 * Fetches the recently viewed news and the paginated news altogether.
 */
interface GetNewsInteractor {
    interface Callback {
        /**
         * Triggered when we successfully fetch the paginated news
         * @param news The list of news for this page.
         * @param currentPage The current page.
         * @param totalPages The total amount of pages available.
         */
        fun onNewsSuccessfullyFetched(
            news: List<NewFeed>,
            currentPage: Int,
            totalPages: Int
        )

        /**
         * Triggered when we successfully fetch the recently viewed news.
         * @param news The list of recently viewed news.
         */
        fun onRecentlyViewedNewsFetched(
            news: List<NewFeed>
        )
        /**
         * Triggered when something goes wrong either fetching the recently viewed news or
         * the paginated news.
         */
        fun onErrorFetchingNews()

        /**
         * Triggered when we try to hit the endpoints without internet connection.
         */
        fun onNoInternetConnection()
    }

    /**
     * Execute function to trigger this Interactor.
     * @param callback A GetNewsInteractor.Callback usually implemented on the ViewModel.
     * @param page The current page that we are trying to fetch.
     */
    fun execute(callback: Callback, page: Int)
}

In this example, we see the GetNewsInteractor, an interactor that fetches a list of recently viewed news and paginated news through two different endpoints.

Here I'm just handling two error scenarios for when the API call fails and for when we try to hit the API without an internet connection. If you need to handle more in-detail errors, for example, a 401/403 error response from the API, you could just add a new onNotAuthorizedError() callback function here and implement the handling of that exception in the actual implementation.

The implementation (logic) looks like this:

class GetNewsInteractorImpl(
    private val newsRepository: NewsRepository
) : GetNewsInteractor {
    override fun execute(callback: GetNewsInteractor.Callback, page: Int) {
        // If we are fetching the first page either because we did a PTR or because this is the
        // first time opening this screen we need to fetch both
        if (page < 1) {
            fetchRecentlyViewedNewsAndPagedNews(page).subscribe(
                {
                    val pagedNews = it.first
                    val recentlyViewedNews = it.second

                    callback.onNewsSuccessfullyFetched(
                        news = pagedNews.list,
                        currentPage = pagedNews.current,
                        totalPages = pagedNews.total
                    )

                    callback.onRecentlyViewedNewsFetched(
                        news = recentlyViewedNews.list
                    )
                },
                {
                    if (it is ConnectException || it is UnknownHostException) {
                        callback.onNoInternetConnection()
                    } else {
                        callback.onErrorFetchingNews()
                    }
                }
            )
        } else {
            fetchPagedNews(page).subscribe(
                {
                    callback.onNewsSuccessfullyFetched(
                        news = it.list,
                        currentPage = it.current,
                        totalPages = it.total
                    )
                },
                {
                    if (it is ConnectException || it is UnknownHostException) {
                        callback.onNoInternetConnection()
                    } else {
                        callback.onErrorFetchingNews()
                    }
                }
            )
        }
    }

    /**
     * Fetches both, the recently viewed news from the /news/recent and the paginated news from the
     * /news?page={page}
     */
    private fun fetchRecentlyViewedNewsAndPagedNews(page: Int): Observable<Pair<NewFeedMetadata, NewFeedMetadata>> {
        return Observables.zip(fetchPagedNews(page), fetchRecentlyViewedNews()) {
                pagedNews: NewFeedMetadata, recentlyViewedNews: NewFeedMetadata ->
                Pair(pagedNews, recentlyViewedNews)
        }
    }

    /**
     * Fetches the recently viewed news from the /news/recent endpoint.
     */
    private fun fetchRecentlyViewedNews(): Observable<NewFeedMetadata> {
        return newsRepository.fetchRecentlyViewedNews()
            .map {
                it.response.toNewsFeedMetadata()
            }
    }

    /**
     * Fetches the paginated news through the /news?page={page}
     */
    private fun fetchPagedNews(page: Int): Observable<NewFeedMetadata> {
        return newsRepository.fetchNews(page)
            .map {
                it.response.toNewsFeedMetadata()
            }
    }
}

You can see that we call the fetchRecentlyViewedNewsAndPagedNews(Int) function which zips two calls from the NewsRepostitory and returns them wrapped into a Pair object.

Through RxJava you can manage to handle the responses however you want. For example, let’s say that, specifically, if the call to fetch the recently viewed orders fail you want to display a Snackbar on the UI, you can hook from the doOnError() and use the callback to communicate the ViewModel that something went wrong while trying to fetch the recently viewed news.

Also, you can pass any other dependencies that you might need. Let’s say that you want to track these errors through Crashlitycs, you can pass the Crashlitycs instance into the interactor and report the exceptions hooking from either the doOnError() or in the onError() from the Subscriber.

The same thing goes if the behavior of your interactor depends on some SharedPreferences configurations. You just pass the SharedPreferences instance through the interactor’s constructor and check whatever value you need and call one function from the repositories or the other.

What about memory leaks? Don’t you dispose the Observable once you’re done with it.

Yes, disposing of the Observables as soon as you are done with them is a good practice. You can hook from the onCleared() function on the ViewModel and dispose of all the Observables through the interactor. For the sake of keeping things simple, I didn’t include an example of that on every interactor. But you can see an example of that in the GetImgurPostsInteractor and how we call the dispose() function from within the ExampleImgurViewModel.

ViewModel

Protocol

The ViewModel protocol is to expose data to the view layer through LiveData properties. These LiveData properties are usually MutableLiveData properties of sealed classes that represent the state of the ViewModel.

Logic

There are a few little rules from the ADT about what we are supposed to do on a ViewModel and what not. One of them is:

Do not use or handle any view-related classes on the ViewModel. The ViewModel is not supposed to know anything about the view layer.

Then there are a few rules that I came out with by myself:

You can extend from the AndroidViewModel class and use the Application context, in case that for example, you need to fetch a String resource. I highly discourage using the AndroidViewModel class, because I think that anything related to fetching resources and things like this should be done on the view layer. Also, if you need to use an Android SDK class that isn't view-related, for example as the SharedPreferences, you should use them inside your interactors. There's no need to have this logic inside the ViewModel.
Try to keep as few LiveData properties as possible. This makes the ViewModel easier to handle and easier to scale. Ideally, you should have a single MutableLiveData property that represents the state of the ViewModel and that’s it. By state I mean, “showing the information”, “loading”, “no internet connection”.
Sometimes you may need to have more than one LiveData property or even use a MediatorLiveData property to handle changes within the other properties. For example, let’s say that you have an Activity where you can search for different things using a search bar on the Toolbar. Usually, you will have a MutableLiveData property of a String to represent the query of what you are searching for, you can hook this into a MediatorLiveData and listen for the changes on the query LiveData property, then perform the search accordingly.
Another example is trying to handle different error situations. Let’s say that you have an endpoint that is prone to return a 500 response. If the user opens the app from scratch and gets a 500 when fetching the data you want to show a full display error message (a nice ImageView with a nice title explaining what just happened). On the other hand, if the user opens the app, fetches information successfully, then do a Pull-To-Refresh, and gets a 500, you may want to show just a Snackbar instead of the full error display. In a situation like this, you want to keep two different sealed classes to represent the state of the app. One that represents the state of the ViewModel, and the other that represents all the possible error messages. You can see an example of this in the "LiveData Example", there we display a list of posts through a search feature, this search feature also goes with a few filtering options, all this gets coordinated through LiveData.

Code Example

Taking a look to the "LiveData Example" we are going to see that we have two sealed classes to represent the state of the ViewModel, State and Message. And another sealed class to represent the state of the current search, SearchParams.

The State class which can be either IsLoading (to reflect whether we are currently loading the search results or not), Success (to reflect the success state once we have fetched the search results), NoInternetError (to reflect the state when there's no internet connection) and UnknownError (to reflect the state when something goes wrong while trying to fetch results)

class ExampleImgurViewModel @Inject constructor(
    private val getImgurPostsInteractor: GetImgurPostsInteractor
) : ViewModel(), GetImgurPostsInteractor.Callback {

    // region Sealed classes declaration
    sealed class State {
        data class IsLoading(
            val isLoading: Boolean
        ) : State()
        data class Success(
            val query: String,
            val list: List<ImgurGallery>
        ) : State()
        object NoInternetError : State()
        object UnknownError : State()
    }

    // ...

The Message class represents the error messages. As I mentioned before, if we got search results through a search and then we try to search for something else and something unexpected happen (a 500 response from the endpoint, connectivity lost, etc.) we don't want to remove the information that the user is currently seeing and show the full error state, we just want to display a nice friendly Snackbar.

    // ...

    sealed class Message {
        object NoInternetError : Message()
        object UnknownError : Message()
    }
    // endregion

You can see that on the GetImgurPostsInteractor.Callback implementation within the ExampleImgurViewModel we handle two error callbacks, one for generic errors and the other for connectivity errors.

    // ...

    override fun onErrorFecthingImgurPosts() {
        state.value = State.IsLoading(false)
        if (_imgurGalleryPosts.isEmpty()) {
            state.value = State.UnknownError
        } else {
            message.value = Message.UnknownError
        }
    }

    override fun onNoInternetConnection() {
        state.value = State.IsLoading(false)
        if (_imgurGalleryPosts.isEmpty()) {
            state.value = State.NoInternetError
        } else {
            message.value = Message.NoInternetError
        }
    }

    // ...

The first thing that we do is to turn off the loading state through the State.IsLoading(false). Then we check against the _imgurGalleryPosts property which is a mutable collection of the Imgur posts that we have fetched so far. If the collection is empty, then we know that the user isn't seeing any post-related information, so we go with the full error state. If the collection isn't empty, then we know that the user is seeing posts, and we don't want to hide them, so we go with the message.

class ExampleImgurActivity : AppCompatActivity(), SimpleSearchView.OnQueryTextListener,
    Toolbar.OnMenuItemClickListener, PopupMenu.OnMenuItemClickListener {

    // ...

    // region Lifecycle functions declaration
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // ...
        observeStateChanges()
        observeMessageChanges()
        // ...
    }

    // ...

    private fun observeMessageChanges() {
        viewModel.message.observe(this, Observer {
            when (it) {
                is ExampleImgurViewModel.Message.NoInternetError -> {
                    onShowNoInternetConnectionSnackbar()
                }
                is ExampleImgurViewModel.Message.UnknownError -> {
                    onShowUnknownErrorSnackbar()
                }
            }
        })
    }

    // ...

    private fun onShowUnknownErrorSnackbar() {
        Snackbar.make(
            activityExampleImgurContainer,
            getString(R.string.error_unknown_error),
            Snackbar.LENGTH_LONG
        ).show()
    }

    private fun onShowNoInternetConnectionSnackbar() {
        Snackbar.make(
            activityExampleImgurContainer,
            getString(R.string.error_no_internet_connection),
            Snackbar.LENGTH_LONG
        ).show()
    }

    // ...

    private fun observeStateChanges() {
        viewModel.state.observe(this, Observer {
            when (it) {
                is ExampleImgurViewModel.State.IsLoading -> {
                    onLoadingStateChanged(it.isLoading)
                }
                is ExampleImgurViewModel.State.NoInternetError -> {
                    onShowNoInternetConnectionError()
                }
                is ExampleImgurViewModel.State.UnknownError -> {
                    onShownUnknownErrorStateView()
                }
                is ExampleImgurViewModel.State.Success -> {
                    if (it.list.isEmpty()) {
                        onShowNoResultsStateView(it.query)
                    } else {
                        onShowImgurPosts(it.list)
                    }
                }
            }
        })
    }

    // ...

    private fun onShownUnknownErrorStateView() {
        activityExampleImgurStateDisplay.show {
            image(R.drawable.ic_sentiment_very_dissatisfied_black_24dp)
            title(R.string.error_unknown_error)
        }
    }

    private fun onShowNoResultsStateView(query: String) {
        activityExampleImgurStateDisplay.show {
            image(R.drawable.ic_youtube_searched_for_black_24dp)
            title(getString(R.string.error_no_search_result_found, query))
        }
    }

    private fun onShowNoInternetConnectionError() {
        activityExampleImgurStateDisplay.show {
            image(R.drawable.ic_signal_wifi_off_black_24dp)
            title(R.string.error_no_internet_connection)
        }
    }

    // ...

Here you can see how we observe these changes from the view layer and react accordingly. Keep in mind that in the source code we have a custom view called SimpleStateDisplay, which is basically just a FrameLayout with an ImageView and a TextView that I use to display the full error states.

To perform the actual search we have a MediatorLiveData property of SearchParams.Query called searchParams.

class ExampleImgurViewModel @Inject constructor(
    private val getImgurPostsInteractor: GetImgurPostsInteractor
) : ViewModel(), GetImgurPostsInteractor.Callback {
    ...
    sealed class SearchParams {
        enum class Sort(val value: String) {
            TOP("top"),
            VIRAL("viral")
        }
        enum class Window(val value: String) {
            DAY("day"),
            WEEK("week"),
            MONTH("month")
        }
        data class Query(
            val query: String,
            val window: Window,
            val sort: Sort,
            val page: Int
        )
    }

    ...

    val sort = MutableLiveData<SearchParams.Sort>().apply {
        SearchParams.Sort.TOP // Default sort
    }
    val window = MutableLiveData<SearchParams.Window>().apply {
        SearchParams.Window.MONTH // Default window
    }
    val query = MutableLiveData<String>().apply {
        "" // Default query
    }
    private val page = MutableLiveData<Int>().apply {
        1 // Default page
    }

    ...

    // LiveData property that reflects the state of what we are currently searching.
    val searchParams = MediatorLiveData<SearchParams.Query>().apply {
        addSource(sort) { newSort ->
            // Remove all the current posts since the query has changed
            _imgurGalleryPosts.clear()
            value = _searchParams.copy(
                sort = newSort
            )
        }
        addSource(window) { newWindow ->
            // Remove all the current posts since the query has changed
            _imgurGalleryPosts.clear()
            value = _searchParams.copy(
                window = newWindow
            )
        }
        addSource(query) { newQuery ->
            // Remove all the current posts since the query has changed
            _imgurGalleryPosts.clear()
            value = _searchParams.copy(
                query = newQuery
            )
        }
        addSource(page) { newPage ->
            value = _searchParams.copy(
                page = newPage
            )
        }
    }

    ...

The idea here is that from the View layer we set all the different properties to configure our search criteria. We set the query, the page, the sorting order, the window, etc. The searchParams reacts to these changes and updates its state. The _searchParams property is a SearchParam.Query property that helps us to keep track of the current search criteria, internally, in the ViewModel.

class ExampleImgurActivity : AppCompatActivity(), SimpleSearchView.OnQueryTextListener,
    Toolbar.OnMenuItemClickListener, PopupMenu.OnMenuItemClickListener {

    // ...

    private fun observeQueryChanges() {
        viewModel.searchParams.observe(this, Observer {
            viewModel.searchPosts(it)
        })
    }

    // ...

We observe the searchParams changes from the View layer and if we detect that anything has changed on the search criteria, we call the ViewModel and perform a new search against the Imgur API through the GetImgurPostsInteractor.

View

Protocol

The view protocol is to expose data to the user through a UI.

Logic

The logic on the view layer consist of interacting with the ViewModel, observe the changes on the ViewModel through the LiveData properties and update the UI accordingly.

Code Example

Here you just do the usual set up of the views. For example, setting the listener for a Button, preparing the adapters for a RecyclerView, or setting up any other view. Other than that the implementation of the view layer should be pretty straightforward. In the onCreate(Bundle?) hook we want to inject the dependencies, instantiate the ViewModel, set up the views, and listen for the ViewModel changes.

class ExampleImgurActivity : AppCompatActivity(), SimpleSearchView.OnQueryTextListener,
    Toolbar.OnMenuItemClickListener, PopupMenu.OnMenuItemClickListener {

    ...

    // region Lifecycle functions declaration
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.example_imgur_activity)

        // Instantiate the ViewModel
        viewInjector.inject(this)

        viewModel = ViewModelProviders.of(this, viewModelProvider)
            .get(ExampleImgurViewModel::class.java)

        // Setup the Views' listeners
        setupSwipeRefreshLayout()
        setupRecyclerView()
        setupToolbar()

        // Observe the changes from the ViewModel
        observeStateChanges()
        observeMessageChanges()
        observeQueryChanges()
        observeQuerySortChanges()
        observeQueryWindowChanges()
        observeSearchQueryChanges()
    }
    ...

Another thing that you need to care for is the state of the Fragment/Activity. You can save and restore the state of the view through the onSavedInstanceState(Bundle) and onRestoreInstanceState(Bundle) hooks.

    ...
    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        viewModel.onSaveIntanceState(outState)
    }

    override fun onRestoreInstanceState(savedInstanceState: Bundle) {
        super.onRestoreInstanceState(savedInstanceState)
        viewModel.onRestoreInstanceState(savedInstanceState)
    }
    ...

What about using Jetpack's SavedStateHandle?

At the time of writing this articles implementing this solution using SavedStateHandle requires way more boilerplate code than just hooking the ViewModel from the onSavedInstanceState(Bundle) and onRestoreInstanceState(Bundle) hooks. I'll probably update the article as soon as I find a more adequate solution.

My next article will be about how to integrate Unit Testing (through Robolectric + Square's MockWebServer) and Instrumentation Testing (through Espresso) into this architecture.

Notes

[1] The DataResponse "pattern" is also used by Google on the 2019 IOSched app. It is really useful when you need to do something based on the origin of the data.

A production-level architecture for Android apps (part 1)

Agustín Tomas Larghi — Sat, 15 Feb 2020 17:39:46 +0000

A production-level architecture for Android apps (part 2)

Agustín Tomas Larghi ・ Feb 15 '20

#android #mvvm #kotlin #architecture

Context

I thought it was time to write a series of articles about how to design a proper, scalable architecture that you may apply to any medium-large projects. This series of articles is the sum of all the knowledge that I’ve learned from working on different projects for different companies. Working on all these different projects has taught me the does and donts that you need to keep in mind when you are working on a large project. There are things related to the technology itself and there are things related to how the architecture that you choose to apply is going to impact your engineering team.

Before you start

This article assumes that you are at a semi-senior or senior level. That means that you feel comfortable working with the most well-known technologies related to Android development, such as Dagger, Kotlin, RxJava, Google-related libraries (FCM, Remote Config, Crashlytics) and obviously, the Android SDK.

I’m going to start talking about the tech-stack setup, then show the example app that I have created for this article, and then in the next article I'll go on through each layer of the architecture.

Tech-stack setup

Since some time ago I have permanently moved from MVP to MVVM because MVVM has become the first officially supported Android architecture, through Android’s LiveData and ViewModels. Also, since this article aims towards a large-scale architecture this is going to be a multi-module architecture, with feature modules, a core module, and a base module.

The technologies that I’m going to use here are; Dagger for dependency injection, OkHttp/Retrofit as my networking layer, RxJava to wrap the network layer into repositories.

Example App

I have created an example app as an example - no pun intended - of how this architecture works. This example app shows different real world scenarios, scenarios where we have to use cache, perform search, mix different endpoints, and so on.

Each feature module shows different use cases and different scenarios. I often see that when you look for examples online you only see the most straightforward, simple and unrealistic scenarios¹. For example, just fetching something from the backend and display it on the UI. In my personal experience that’s not how real-world development works like. In the real world, you’re going to have to go back and forth with different resources within your company, and due to different constraints you may have to settle with API endpoints that are not totally mobile-friedly², or you may have to hit different endpoints to display the whole information to the user.

RxJava Example #1

The "RxJava Example #1" shows how we can conditionally zip two API calls together.

In this example, we use two different endpoints to fetch the "recently viewed news" and the regular paginated news. If we do a Pull-to-Refresh or open the Activity from scratch, we are going to fetch both, the recently viewed news and the first page of the paginated news. If we continue to scroll down until we reach the next page, we are only going to call the API to fetch the second page.

This example also handles error situations like doing a Pull-to-Refresh without internet connection.

RxJava Example #2

The "RxJava Example #2" shows how we can zip responses from different endpoints through RxJava.

In this example, we zip the responses from two different endpoints, one that provides the user's "business skills information" and another that provides the user's "personal information". We zip these requests together through RxJava and use wrapper objects to carry the responses around. Also, we handle different error situations for each endpoint and update the UI accordingly.

This example supports Pull-to-Refresh behavior and handling no internet connection states.

Cache Example

The "Cache Example" shows how we can use a cache repository and a network repository to display data to the user, update data dynamically, and without using any sort of EventBus technology, get these updates into the UI by relying on Room's Flowables.

In this example, we fetch a list of recipes from a mock endpoint host on ApiAry, store those recipes on cache, and allow the user to bookmark the recipes. When we bookmark a recipe we can see the change reflected on the recipe list as soon as we do it, all this thanks to Room's Flowables.

This example also supports Pull-to-Refresh behavior and handles different error states, such as trying to fetch the list of recipes without internet connectivity.

LiveData Example

The "LiveData Example" shows how we can achieve a complex search by relying on LiveData.

In this example, we can search image posts using the Imgur API, through this API we are able to search using a query String as the search term, and we have a few filtering options. We can select if we want to get the latest posts (Top) or if we want to get the most trendy posts (Viral). If we choose to filter by top posts, we can also specify a date windows, getting the top posts from the day, week, or month.

This example supports handling the Pull-To-Refresh gesture and pagination. Also, we handle different error states such as trying to search for something without internet connection (it shows a Snackbar if we are seeing content or a full error state if we open the Activity from scratch).

All this is done through LiveData.

In the next article, I will go in detail through each layer of the architecture.

Notes

[1] By unrealistic scenarios I mean when you go through an article and they show you how to fetch data, save it on cache, and display it on a RecyclerView. That’s all well and good; But what happens if you fetch a 500 (Internal error)? What happens if you fetch a 304 (Not Modified)? Do you waste time and store a duplicate response on the cache? What happens if there’s no internet connection? All these edge-case scenarios, that are actually very likely to happen in the real world, are totally omitted by most articles.

[2] Some may argue that if this was to happen, you should push forward and settle for nothing else other than what you want. But that’s not how a company works. A company needs to deliver a product. Backend and frontend developers, they have deadlines, and trying to fix an endpoint so it is more mobile-friendly may take time, time that the backend resources don’t have.

DEV Community: Agustín Tomas Larghi

Oof – look, that's a legacy codebase!

Remove unused resources

PR templates

Kotlin basics

Tech Soup

Navigation Soup

Isolate new code through modules

Set a coding standard

That's all

The Performance Pyramid (part 4) – Team Management

Index

About

Shrinking egos

Balancing opinions

Meeting etiquette

How to encourage good traits

Leadership roles

Letting people go

The Performance Pyramid (part 1) – Communication

Index

About

Cut the ego

Why should I care?

Remote work

The performance pyramid

Communication

Self-diagnosis

Actionable items

The 500 DON'Ts about Android Development

1️⃣ .let isn't a replacement for if != null

2️⃣ Using RecyclerView instead of LinearLayout

3️⃣ Mutable and immutable data

4️⃣ Too much lateinit var

5️⃣ Checking if context != null

6️⃣ Observables, Callbacks, and where to use them

Callback

Observables

7️⃣ Re-using UI

8️⃣ Incorrect usage of LiveData + Coroutines

Is Jetpack Compose ready for production development?

What's this about?

The experiment 🧪

The results 📈

Learning curve 📚

Things I like so far 👍

Things I didn't like that much so far 👎

Who else is using Jetpack Compose out there?

Things I want to try next

tl;dr

Feedback! 🙇🙇🙇

Software shenanigans

Yet More Slack tips

A production-level architecture for Android apps (part 2)

Previous

A production-level architecture for Android apps (part 1)

Agustín Tomas Larghi ・ Feb 15 '20

Index

Context

Layers

Datasources

Protocol

Logic

Network Logic

Code example

Cache Logic

Code example

Repositories

Protocol

Logic

Code example

Interactors

Protocol

Logic

Code example

ViewModel

Protocol

Logic

Code Example

View

4️⃣ Too much `lateinit var`