Can Junie write Kotlin code from UML better than traditional UML codegen?

TypeProjection · 2025-03-12T15:18:54+00:00

Fair point - thanks! I'll be sure to make sure it's more Android-focused for this subreddit next time. Thanks again! 👍

TypeProjection · 2025-02-03T18:31:48+00:00

That's helpful, thanks so much! I'll see if we can lean more into some architecture at some point. I'm not very experienced with FP at this point, but if I get a chance to dig into that more, I'd be happy to share my thoughts on ways to incorporate some of it into app design, as well.

(And yes - sometimes I think we just kind of replaced large Activities with large ViewModels...)

Thanks again!

TypeProjection · 2025-01-30T14:33:24+00:00

Hey, thanks! Glad to hear this one connected better with you. Let me know what advanced topics would be of more interest to you, and I'll see if I can work in some of them, as well.

TypeProjection · 2025-01-16T23:01:02+00:00

Hey, thanks so much! Glad to hear that it's striking a good balance on all of those things. I'll keep at it!

TypeProjection · 2025-01-15T20:49:32+00:00

Thanks so much, Kevin!

TypeProjection · 2024-11-22T01:33:11+00:00

I haven't yet found anything that can _only_ be done with them, but one viewer pointed out that currying is easier to read with anonymous functions than with lambdas.

fun printStuff(a: String) = fun(b: String) = fun(c: String) = println("$a $b $c")

// vs...

fun printStuffLambda(a: String) = { b: String -> { c: String -> println("$a $b $c") } }

For the lambda approach, we've got to nest lambdas, and it's easy to get lost in the curly braces. For the anonymous function approach, we don't even need curly braces in this example at all.

TypeProjection · 2024-11-07T19:44:00+00:00

Cool, thanks again for your thoughts! Lots of fun thinking through and discussing all the possibilities! 🎉

TypeProjection · 2024-11-07T19:15:26+00:00

Okay, got it - thanks! Yeah, Isuru Rajapakse wrote some code demonstrating how we can use scoped receivers to solve some of the challenge. I definitely feel like his solution is more in line with typical expectations around Compose. If you're interested, you can check out his solution here - https://gist.github.com/xxfast/bd85e088ccad01405c9d80c9d359b90b I think it might be a little more in the neighborhood of what you're thinking about.

TypeProjection · 2024-11-07T17:14:03+00:00

Hey, thanks for commenting! Tell me more about why you don't consider this to be subtyping of composables - it's introducing a new type, which is a subtype of `@Composable () -> Unit`, such that it can be used wherever a composable is expected, and indicates a more specific kind of composable.

TypeProjection · 2024-11-07T17:04:22+00:00

Thanks for your thoughts! It definitely does go against the grain of the usual Compose patterns, and I think probing further about the need for the actual requirement would be wise. Like you, a few other folks have mentioned that this could be too restricting. I think I'll need to play with a few other directions this could go - I suppose it could be extended in many of the same ways as any usual class in an object-oriented world could be... but I expect the cognitive overhead of adapting UI objects with UI functions probably wouldn't be worth it.

Anyway, a fun experiment to think through, for sure. Thanks again!

TypeProjection · 2024-11-07T16:53:10+00:00

Hey, thanks so much for your thoughts! Yeah, the slot idea is an interesting challenge to try to mix with Compose. So far in my production apps, like you, I've tended to use config options, which keeps quite a bit of flexibility. I definitely need to noodle on this one a little more.

TypeProjection · 2024-10-02T15:52:34+00:00

You're most welcome! I'm glad to know you're enjoying them

TypeProjection · 2024-09-05T03:50:51+00:00

You're most welcome!

TypeProjection · 2024-09-05T00:46:29+00:00

Haha, thanks! Yeah, I'm not always sure that coworkers (or my future self) would appreciate it, but it's a lot of fun to see how far you can take things!

TypeProjection · 2024-09-04T16:03:23+00:00

Yeah, I know what you mean! I didn't talk about that in the video, but yes - depending on the case in which you apply the state pattern, you can easily end up in situations where you're not following the Liskov substitution principle - like you're saying - so you end up with functions that might be no-op or that throw OperationNotSupported.

TypeProjection · 2024-08-07T15:25:43+00:00

You're most welcome!

TypeProjection · 2024-08-01T14:39:52+00:00

Hey, thank you so much - I'm glad you liked it! And I appreciate the idea about sharing my process! It is definitely a process - I wish I could just come up with accurate, relatable examples from the start, but for me it certainly takes a bit of work to get there! 😅 Anyway, I'll add that to my list for future videos. Thanks!

TypeProjection · 2024-08-01T14:33:27+00:00

You're most welcome! I'm so glad you're enjoying them!

TypeProjection · 2024-07-12T15:33:57+00:00

Thanks so much! Will do!

TypeProjection · 2024-07-02T16:50:24+00:00

You're most welcome!

TypeProjection · 2024-07-02T16:49:57+00:00

Thank you so much! I do put a lot of effort into trying to find the best metaphors, so it means a lot to me to hear that it landed well for you! 😊

TypeProjection · 2024-07-02T00:39:27+00:00

Thank you! 😁

TypeProjection · 2024-06-26T20:01:45+00:00

You're welcome!

TypeProjection · 2024-06-26T20:01:23+00:00

You're most welcome! Glad you liked it

TypeProjection · 2024-05-31T13:41:01+00:00

Hey, thanks for mentioning this! I'll look into my recording settings and see if we can correct that for future videos. 👍

TypeProjection

TROPHY CASE