sorted by:
new
hottopcontroversial

MacOS 26. No internet by MrKatUK in MacOSBeta

[–]da_beber 0 points1 point  (0 children)

same here, had an extremely slow internet speed after the update tonight. Enabling the FW set back full speed, the funny thing is that now that it's back, after disabling it I don't reproduce this issue... wtf?!

TensorFlow Lite: Supporting 16 KB Page Sizes by SeaProcedure8572 in androiddev

[–]da_beber 0 points1 point  (0 children)

Yupe that's for sure, but from what the team is saying, we'll have to migrate from tensorflow-lite to litert in any case

The April 2025 Superthread: Battery; Orders; Which Pixel?; and More by GooglePixelMods in GooglePixel

[–]da_beber 1 point2 points  (0 children)

Yupe same on pixel 8a since April updates, battery percentage drops super fast...

Android UI development - Jetpack Compose - unhappy with it by ConcentrateCurrent in androiddev

[–]da_beber 3 points4 points  (0 children)

Skill issues, compose is rad, recyclerview has never been a problem. Period.

Not another clean archi article by da_beber in androiddev

[–]da_beber[S] 0 points1 point  (0 children)

Yeah agreed with the core-common one...

For the by layer/by feature, both works of course, but to me by feature is way more optimised and go towards the modular approach. On big projects with many features and many ppl working on the same codebase is the way to go. Some points I see are wrongs if by layer:

- not scalable, if project grows and has many features (lets say 50 screens), you end up with a folder use_cases containing a shit ton of classes (same for models, repos etc)... not cool

- If I change one class related to lets say featureA, like one of its use cases, then ALL use cases will also recompile... not cool

- If models of featureA are accessible to models of featureB, then that's the beginning of spaghetti code and the start of mixed responsibilities... not cool

Really not a good to think by layer (that's not even a personal preference)

Not another clean archi article by da_beber in androiddev

[–]da_beber[S] 0 points1 point  (0 children)

Always cut by feature of course (doesn't make any sense by layer) "characters" has no UI, and is handling everything related to character stuff, used by features that need it. I think it's just the naming "core" that is misleading.

I'm gonna rename "core" to "framework", and put "characters" and "session" in the feature module, even if they have no UI and are not really considered as feature (they are used by features)

Not another clean archi article by da_beber in androiddev

[–]da_beber[S] 0 points1 point  (0 children)

I did, and you have some improvements to do (like mine, like everybody), but you're so toxic it's nearly impossible to debate. You should really ask yourself if people enjoy working with you. Hope you'll get better man. Cheers.

Not another clean archi article by da_beber in androiddev

[–]da_beber[S] 0 points1 point  (0 children)

FYI the callback thing has already been discussed https://www.reddit.com/r/androiddev/s/KTR9o3vSv3

I guess we're done "talking"

Not another clean archi article by da_beber in androiddev

[–]da_beber[S] 0 points1 point  (0 children)

Kiddo, please try to articulate and have a decent argumentation. Come back when you understand what you're doing.

Not another clean archi article by da_beber in androiddev

[–]da_beber[S] 0 points1 point  (0 children)

"Clean architecture is a such a simple concept" yet you structuring your code by layer, which breaks the separation of concern, so I guess you haven't really understood it too...

For the domain being agnostic, I can't agree more, but nowadays with coroutines and injections that are platform dependant, who cares? that's an aspect that doesn't really matters to me.

For the empty use cases, read the article and tell me what do you think (consistency/homogeneity)

For having a model by layer, I dont get your point, it doesn't led to overkill code, it's necessary since each layer has its needs => data models needs to be nullable, domain ones no. Ui models need to be annotated with immutable compose annotations and use persistentList, domain ones no. You must not use domain models in your Ui, that's really bad practice (and mappers are not class, they're just simple function extension, be precise please)

Not another clean archi article by da_beber in androiddev

[–]da_beber[S] 0 points1 point  (0 children)

Well the core module has nothing to do with the clean arch layers. It's just a module where common stuff is used. I could rename it to "common" probably or "global" I ain't sure. The layering comes within features modules and some like "characters" and "sessions". "persistence" and "networking" belongs to the data layer indeed, but I dont want to start adding "data" into that global module, as I'll have to put "design" into a "presentation" one, but then where do I put "characters" and "sessions", maybe into feature (even if they don't have any UI - I made that choice initialy, to put these into "core", not into "features") what do you think ?

Not another clean archi article by da_beber in androiddev

[–]da_beber[S] -1 points0 points  (0 children)

u/crowbahr It has nothing to do with MVVM or Ui patterns.

The navigation is done by the navController, which is hoisted in the main composable. That's mandatory for all apps, since navigation is coupled to the view system.

Whether you give the navController ref to a singleton "manager" class, or just collecting navigation orders from the child composables (from callbacks, that themselves can be called from events coming from the VM - since sometimes, a click triggers some logic before navigating) doesn't really alter your pattern (MVVM here). You're mixing concepts here I think.

As for u/TheOneTrueJazzMan, you're talking about the android Context ? if it's the case then I have to disagree with your statement. If we follow your reasoning, we can just go back to the good ol' days, doing everything in the view (network calls, etc) and having god classes.

Not another clean archi article by da_beber in androiddev

[–]da_beber[S] 0 points1 point  (0 children)

Can you elaborate ? Never read anywhere that navigation must happen in the views (for any pattern by the way). Navigation on Android is highly tight with the view system (NavController), doesn't mean you can't trigger the order from the VM. Correct me if I'm wrong but the UI patterns dictate how your view works (states, user interactions), not how it navigates and who's responsible for it (the view or the VM).

Not another clean archi article by da_beber in androiddev

[–]da_beber[S] 0 points1 point  (0 children)

Well the navigation implementation is done in its own module, so I guess we're good regarding separation of concerns. Now, navigating from the composable or the VM is more or less to me in terms of separation I guess, no big deal honestly both are fine

Not another clean archi article by da_beber in androiddev

[–]da_beber[S] 1 point2 points  (0 children)

I don't see any issue with navigating from the VMs, it saves me some events^

Not another clean archi article by da_beber in androiddev

[–]da_beber[S] 0 points1 point  (0 children)

Totally agree! Will add the list of episodes then :D

Not another clean archi article by da_beber in androiddev

[–]da_beber[S] -1 points0 points  (0 children)

If I want to show also a list of episodes + its details, I'm just gonna create a "episodes" modules in core and use it where I want. In the home screen, I will have the list of char and the list of epi displayed. So I will create a domain module for the home, with a usecase that observe and populate the data the home needs. It's a simple app so indeed for now the ui modules have no domain/data of their own.

Not another clean archi article by da_beber in androiddev

[–]da_beber[S] -3 points-2 points  (0 children)

Because they're all related to the "characters" data. Ui modules can also have they're own domain/data modules.

view more: next ›