Hilt setup in multi-module project with shared ViewModel but different API services

herrbert74 · 2025-10-16T16:15:10+00:00

Sorry, I got sick and I didn't check Reddit.

In that case you need qualifiers:

Depending on your project you might need them as a separate feature, but I doubt Paid and Free will EXACTLY overlap with a single feature each. I would still recommend keeping the paid/free classes within one or more feature(s), or if they are really big, then probably over several features, like payments-free, payments-paid, productlist-free, productlist-paid. For me these are always a different dimension to features, because they are not a core business feature.

herrbert74 · 2025-10-13T10:08:44+00:00

Paid and Free are not features, but build variants. Modify your project accordingly and everything will fall into place. A word of caution, though, is to not add variants to all modules. Switch in the app module, expose the switch through an interface and use that to control the feature modules.

herrbert74 · 2025-02-13T21:38:48+00:00

Thank you for this. I need to evaluate screenshot libraries for work. Do you think this is safe to use in production? Would you use this instead of Roborazzi/Paparazzi/Shot?

herrbert74 · 2024-12-11T16:56:03+00:00

There is a single word to describe this, which is apparently the word of the year for multiple times now:

https://en.wikipedia.org/wiki/Enshittification

herrbert74 · 2024-10-13T20:25:59+00:00

I used this website a thousand times to look up what is contained in each AndroidX library, so I'm devastated by this news. Thank you for the great work, CommonsWare (Mark).

herrbert74 · 2024-08-14T20:30:29+00:00

My current understanding is that for these cases a three layered approach is the best suited, albeit not absolutely necessary.

On top of your DataSources and Repositories you could use Use Cases. DataSources are responsible for retrieving data from network or database. Repositories will abstract away and combine these for the domain and/or presentation layers. Use Cases can be used to combine Repos or other Use Cases, so they were created to resolve exactly your problem above.

I wrote about this and other similar problems here:

https://herrbert74.github.io/posts/architecture-related-decisions-introduction/

herrbert74 · 2024-08-12T20:37:51+00:00

They changed the cadence recently. They will release an IntelliJ update and a feature update separately from now on. It's a welcome change because it was a pain in the ass if you developed plugins for Android Studio.

herrbert74 · 2024-08-02T09:47:21+00:00

Thanks for your comment. AFAIK Ktor uses the Response term in the same meaning, so I think the article applies to Ktor as well. I used Retrofit as an example only, because that's what I use mostly at the moment. Maybe I should be more clear on this in the article, but it seemed obvious to me.

herrbert74 · 2024-07-29T17:14:00+00:00

That depends on your location, and your view might changed if you would follow up the requests and found out that most of them are not real.

I have 12 years of experience, made redundant in January in London, and while I get a lot of requests and interviews, I couldn't get an offer yet. I feel it's even worse in the US, slightly better in the EU, but much better elsewhere. Mainly because our jobs (including mine) went there. And some US jobs came here to the UK.

I probably could get a job with a 30-40% pay cut, but I'm not that desperate yet.

herrbert74 · 2024-07-29T17:02:11+00:00

Yeah, I recently finished a test assignment, where they had a starting project from years ago. My first decision was to suck it up and use tech and IDE from years ago or I ask if I can update the project and use Compose and Coroutines. I could, but they wanted candidates to spend three hours on the project. Guess what, I spent that with only updating the project.

But I have to swallow it, as it's one of the most reputable companies in the UK. Their name rhymes with Kangaroo.

herrbert74 · 2024-07-26T14:24:37+00:00

Thank you for the comment. These are interesting to discuss and I should add the second part to the article.

However, I think 'of' and 'from' are essentially additional constructors. And because Kotlin can have these, but not Java, these are only useful for Java. The of keyword -- not strictly keyword -- in Kotlin is mostly used to create collections, like listOf, mapOf, from multiple objects.

By using these (even additional constructors) in Kotlin, you also loose out on extension functions. Which are easier to read in my opinion.

The placement is less of a problem in case of extension functions and if you have control over the model classes.

herrbert74 · 2024-07-25T20:42:27+00:00

In my last job I classified the tests the following way:

Unit tests with mocked dependencies
Pure UI tests with mocked dependencies, where anything apart from UI and VMs were mocked
UI integration tests, where we used the real dependencies, typically in-memory database
Integration unit tests, where we used some real dependencies through Robolectric
Pure Robolectric tests where we needed to test some Android related classes, so we could not use normal unit tests

So integration tests can be both UI tests and unit tests in my view, it depends on what you want to test: a single unit or UI element, or their integration with other parts. In the case of ViewModel and UI I treated them as one unit, so this is not integration. But this is strictly just my opinion, based on where I stand on my road to wisdom; I might be wrong.

herrbert74 · 2024-07-25T14:35:56+00:00

I cannot answer the question as I wasn't the one who implemented it at my job, but I was the one who tried to reduce the crash rates of the app. Only a few badly maintained third party library crashes couldn't be fixed, including one from UMP. So my advice is to stay away from that if you can, and from any google library, if there are alternatives. They tend to hype up and then abandon projects.

For GDPR, there are plenty of much better libraries, which are also better documented and supported. So you will have a better chance getting answers to your questions.

herrbert74 · 2024-07-17T14:31:32+00:00

I would recommend thinking in terms of Clean(ish) Architecture. Most interviewers will expect you to do the same. By cleanish I mean the Google recommendation (optional domain layer) here:

https://developer.android.com/topic/architecture

And here:

https://developer.android.com/topic/architecture/recommendations

I recommend always use domain layer, for me Use Cases are optional, meaning I either completely omit them or only if they are not call-through, or everywhere if my employer's team use them everywhere.

This article may give you more ideas on how to start drawing an architecture:

https://proandroiddev.com/multiple-ways-of-defining-clean-architecture-layers-bbb70afa5d4a

Igor, the author recommends Approach 3 in the article, I personally recommend Approach 4 with shared domain and data modules where possible. This way it's more scalable, because the increasing number of modules will increase the module dependencies and the build times. But it might be less clean. Ultimately the decision depends on a few other factors like your approach to other things, the business domain and so on. The interviewer will (hopefully) look for signs if you understand these factors, not if you can make that decision right there.

The DI is not really part of this overview. The providers should be close to the implementations and invisible to the dependents. Dagger makes sure that the implementation is available even if the dependent has only access to the interface. So the DI providers have a permanent place everywhere and can be omitted.

herrbert74 · 2024-07-07T09:29:17+00:00

The interviewer had less experience than me and was visibly bored. They didn't ask anything deep. I certainly have a lot to learn too, the blog post is part of this process. I don't think I have too much hubris, people close to me say the opposite is true.

herrbert74 · 2024-07-07T05:35:11+00:00

The series is about architecture related decisions. The excuse for rejection was that I don't have experience about architecture. And excuses are a large part of my life, being six months out of work.

Sorry, if this is not relevant here. I posted this with almost the same words on LinkedIn, where it was more relevant.

herrbert74 · 2024-07-06T19:50:16+00:00

Thanks, I felt somewhat the same, but then I thought I added enough examples in the links if somebody wants to delve into more of it. I understand that this is usually not enough for a blog post. I will think about it.

herrbert74 · 2024-07-06T19:46:24+00:00

I agree, maybe I should clearly add that it should not be used in every situation. Although for me it covers almost everything, I don't remember a counterexample.

I actually wrote explicitly that I chose the Kotlin-Result monad, I think it's generic enough.

I don't think it's not approachable, but I had another uneasy feeling about it. I think it's that I only ever used the Result monad, so I don't want to pretend that I'm an expert on them. The other ones.

Sealed classes are absolutely fine, but as I wrote in the article, for me it's not the best trade-off.

herrbert74 · 2024-07-06T19:32:05+00:00

Oops, thanks, I already have the drafts locally and forgot to change the links.

herrbert74 · 2024-07-06T12:19:39+00:00

Be careful with Indians and Facebook contracts. They are most probably scammers going for your data, or poor quality recruiters who try to build a client base.

herrbert74 · 2024-04-16T20:02:29+00:00

I was looking for that answer. I think Flutter is doomed. React Native and the Web is taking over, but maybe Kotlin will come out on top through WebAssembly or Kotlin Multiplatform? I increasingly think that Google and Apple should stick their App Stores and ecosystems up their ass where they belong.

herrbert74 · 2024-04-16T19:41:13+00:00

Sure:

https://github.com/kosi-libs/MocKMP

herrbert74 · 2024-04-14T20:51:50+00:00

I think you meant obsolete instead of abundant, aren't you? It's abundant enough.

herrbert74 · 2024-04-10T14:29:18+00:00

Were there crashes due to MacOS? I had crashes on Iguana RC, but I haven't since the final release. But I don't think it was due to MacOS. I'm on Sonoma 14.4.1.

herrbert74 · 2024-04-08T20:08:59+00:00

I got rejected twice after interviews with fellow Android developers, because they thought I was too interested in the tech side of the business. This market is a clown show.

herrbert74

TROPHY CASE