@codeinabox I’m confused. Does Cart live in your domain or is it input (just a container for the data that creates a Cart in your domain)? If it lives in your domain, then your article read like an FP programmer slowly realizing OO. 😅 If it’s input, then I don’t think it’s duplication of concept because one is used for rendering and the other for creating. 🤔

A lot of android apps still hold on to java base because of familiarity or just not changing what's not broken.

They're provably targeting some who are on the edge.

Huh, that’d be interesting if it was implemented in, like, 2016 or so. But now?

Part of being a good engineer is reading and understanding unclear requirements to make them something that can be worked with and transformed into actual positive business outputs. I'm not saying that the badly written courses are attempting to teach you that but if you're stumbling at this hurdle then that doesn't bode well for a future in software engineering. There's way more resources to teach yourself Kotlin and Android development. You need to actively find these out and synthesise them into your learning. To be honest if you told me this on an interview I would simply not hire you because you're admitting the slightest ambiguity will make you unproductive and want to do different things.

Have you looked into flutter? It's way easier to get into and the performance isn't bad. And you can implement kotlin code in your flutter apps as required.

I started with java, then kotlin but I code with flutter now and I like the ease of use. It isn't perfect and there's some getting used to but it's beginner friendly and I hope big breaking changes are behind.

There's some extra baggage and performance loss but if you're just starting off and want to explore your ideas and get it out there to see if it is worth expanding on, I recommend flutter.

If your idea catches on and gets a user/customer base, you can start turning it into native application in the future.

Also it might be specific to that particular course you're doing, try learning it a bit from other resources and see if it helps.

For me also AI has been very helpful. At times I've been doing some really sketchy code because I couldn't find any good guidance for those areas, so asking AI something like "how do I implement this piece of code in a better way and why it would be better that way?" was really helpful, since it was pointing out my mistakes and unveiling some concepts that I could search specifically (and again: some of them were not properly described in the official documentation).

Kotlin has been the right way to make Android apps for 5 years now and a first class citizen for far longer. Kotlin Compose has been the right way to make UI on Android for about 3 years. going back to Java will ultimately hurt you and will be coming from either a very opinionated, controversial source or something that is way out of date.

i started on Android in 2012, and Kotlin + Compose is just better. also, tutorials are a dime a dozen since they’re generally AI slop or just recreations of the official docs. i hesitate to take a “git gud” stance, but learning from official docs is a career skill.

speaking of AI slop, i don’t think it’s the worst idea to get an LLM to guide the learning experience. use it like a calculator: it’s not an excuse not to learn; it’s a tool to help you learn, even if it will to some extent do the work for you.

I've used both for some side-projects. Both are hell when it comes to Android because Android itself is one hell of a spaghetti.

To me, the hardest part was not the language itself but the fact that many things you find (including in the most official Android docs!) are quite outdated — both for Java and Kotlin.

And then you do circles and circles searching the web. Then you end up upgrading some of the dependencies or the SDK itself, and here another bunch of your dependencies stops working...

So no clear winner or loser for me. In the end they both seem to be almost identical, especially when it comes to Android APIs (apart from tons of generic boilerplate code that Kotlin wraps in cool concepts of flows, coroutines and so on).

There's indeed more decent documentation for Java, but most of the new code (starting from Google itself) seems to be coming out mostly in Kotlin, so I wouldn't advise against learning it, you probably will need it anyway at some point.

Yes, basically. Heavily inspired by Flask-Admin (https://flask-admin.readthedocs.io/)

I use ktor and exposed. Are you saying this module lets me do crud operations in a web admin portal?

It's about handling the CRUD operations using the respective data access objects (DAOs). Abstracts the database operations for entities (https://github.com/believemanasseh/ktor-panel/blob/main/lib/src/main/kotlin/xyz/daimones/ktor/panel/database/dao/ExposedDao.kt), hides details of the underlying database and unifies the API (https://github.com/believemanasseh/ktor-panel/blob/main/lib/src/main/kotlin/xyz/daimones/ktor/panel/database/Interfaces.kt).

Since an admin panel ultimately needs to manage database entities, it's a vital part of the development process.

Sounds interesting, but what does managing database models mean?