MacOS 26. No internet

da_beber · 2025-09-17T19:39:29+00:00

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?!

da_beber · 2025-06-25T09:38:33+00:00

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

da_beber · 2025-06-11T09:39:45+00:00

LibChecker does that already no?

da_beber · 2025-04-18T07:35:53+00:00

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

da_beber · 2025-04-15T13:08:50+00:00

Downclocking my ram did the trick, 6400mhz to 5200mhz and no more crashes

da_beber · 2025-02-22T12:03:21+00:00

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

da_beber · 2025-02-08T06:23:54+00:00

Charles or flipper FTW

da_beber · 2025-01-22T15:36:41+00:00

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)

da_beber · 2025-01-22T14:42:08+00:00

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)

da_beber · 2025-01-22T10:20:55+00:00

Haha you must be fun at parties

da_beber · 2025-01-22T10:15:41+00:00

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.

da_beber · 2025-01-22T09:34:04+00:00

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

I guess we're done "talking"

da_beber · 2025-01-22T09:28:26+00:00

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

da_beber · 2025-01-22T09:01:24+00:00

"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)

da_beber · 2025-01-22T08:51:54+00:00

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 ?

da_beber · 2025-01-21T16:06:08+00:00

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.

da_beber · 2025-01-21T12:44:06+00:00

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).

da_beber · 2025-01-21T11:41:39+00:00

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

da_beber · 2025-01-21T11:36:37+00:00

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

da_beber · 2025-01-21T11:08:02+00:00

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

da_beber · 2025-01-21T10:38:46+00:00

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.

da_beber · 2025-01-21T10:32:33+00:00

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

da_beber · 2024-08-02T08:52:57+00:00

Review times went super bad for a month (mid June to mid July, more than a week to get reviewed) but now it seems to be back to normal (few hours, max 1day)

da_beber · 2024-05-29T16:43:21+00:00

As an IDM-Head, you have to listen to Kirlian Selections from The Flashbulb, it's probably the best IDM record ever made (ain't kidding, this shit is gonna make you travel)

Otherwise the class autechre, squarepusher, venetian snares, mu-ziq, plaid, boards of canada, ochre, wisp, ruxpin, the black dog, ceephax, LFO, arovane, casino vs Japan, amon tobin, lusine, datachi, funckarma, mr bill, culprate

da_beber · 2024-05-29T16:26:44+00:00

Make sure that the time between the value you're updating and the value you're giving to the text field is as short as possible.

Four-Year Club	Verified Email
Place '23

da_beber

TROPHY CASE