I just finished and this video was great, Matthias. Thanks! The work you do with Canvas results in very interesting and beautiful displays (like the bubbles and top header). These are a challenge to modify to make responsive to different screen sizes due to the hard-coded dimensions, but I had a lot of fun to figure this out. A little algebra goes a long way 🙂
This video provides so much clarity and I can say that now I can make a modular application. However, I still confused with uni-directional data flow between each layer. Please make a video about it.
Wonderful video my dear. I was able to capture important things from compose for my day to day. I need to say that you have a natural talent for programming, you do it very well, I like your logic. Thank you for this content, may the channel grow a lot, I've been here since the beginning and it's going to be great to see it grow.
Hi Matthias! I see this channel has a bright future. Keep it up, bro! I would only say my thoughts: change channel name. It is not memorizable, or better to say unnoticable, I guess. Of course, it is just my humble opinion.
Hey, I am sorry but currently I have absolutely no time for recording videos because of my study and freelancing :( But I am planing new videos when I find a period where I have more time.
First of all, thank you so much for such advanced content for free. And how about videos about designing the UI with Compose? I mean how we set up the UI the old way with XML.
I dont do that much XML anymore. My videos will be always with Compose. The companies I work for will also only use Compose for future projects and existing ones will also be migrated to compose step by step. XML will be obsolete in the future and in my opinion Compose should be in the main focus of learning UI building in Android. (Nevertheless it is of course also recommended to understand the basics of the xml approach)
Hmm for me Compose is faster especially with creating responsive UI. If done right you can use the same composables everywhere in the app if you have for example a custom button. In XML you need the same boilerplate code with little adjustments here and there. Also Compose has a better separation of concerns and you can build your app in the presentation layer in a leaner way.
For those who would like to experiment with flexible values for the bubbles (not hardcoded): this seems to work for me... Box( modifier = modifier .onGloballyPositioned { size = it.size.toSize() } ) { val maxWidth = size.width val maxHeight = size.height val bubbleRadius = maxWidth.coerceAtMost(maxHeight) / 10f val littleBubbleRadius = 0.6f * bubbleRadius val brushWidth = bubbleRadius * 2f then use these values to calculate the min and max x, y, radii, and brush widths instead of fixed values.
Hey Matthias, since this is a video on the clean/correct way to do this, what do you think of the Use Cases including the actual error messages, perhaps in a sealed class rather than an enum? This would allow the presentation layer to present more friendly error messages (like "Password must be longer than 8 chars!" or "Password must contain one of: !@#$%^&**") while keeping the ViewModel from knowing these details (separation of concerns). It seems like the errors and suggestions are business logic.
Mhh i don’t know if this would be the right way (Of course this can be done and it would definitely work). The use cases should not know anything about what messages to display on the UI in my opinion. If you want to log something depending on the validation result then a sealed class with log messages would be fine but determining what message is displayed on the UI is more presentation layer responsibility. Another idea would be a new ui data class which represents the specific validation hint. Then the enum class could be mapped to this ui class with specific error messages(and maybe even more specific UI related things like error colors) which is then used by the view model .
@@kapps7407 The UI Data Class feels right. My point is that the actual password requirements belong in the Use Case, yet the instructions to the user (and the error messages) are in UI - how to reconcile without violating the separation of concerns? It is quite likely the need to show the user something like: "Passwords must be >8 chars and contain at least one Upper character, and one of {!@#$%}" instead of just letting them guess what is wrong. Maybe the UseCase layer also would have a "passwordRequirements" interface returning length, special chars, etc. enough to form a localized message in the UI.
Why shouldn't the password requirements belong in the use case? It is business logic what your app domain accepts as a valid password or not. The ViewModel then processes this business logic with a corresponding error message which you can also indeed define in your domain layer with some kind of sealed class instead of a plain enum class and then just read from the properties within your viewmodel
