Hey everyone,

I'm excited to share iCore, a new library designed to streamline Android application development with modular and reusable components. iCore supports the MVVM architecture and provides base classes, extension functions, and various utility classes to reduce code duplication and speed up the development process.

Key Features:

• Reducing Code Duplication: By abstracting commonly used operations, it prevents the writing of repetitive code.

• Quick Start: With ready-to-use core components, it allows for a quick start to projects.

• Easy Integration: Easily integrates common operations like Retrofit, LiveData observation, and theme/language selection.

• Reactive Data Management with Kotlin Flow and LiveData: iCore manages asynchronous data streams using Kotlin Flow and handles UI updates with LiveData, offering a more reactive and modern data processing model.

• Extensive Extensions: Its extensible structure allows for customization according to application needs.

• Centralized Management: Provides centralized management by allowing easy access to application resources with ResourceProvider.

Links:

🔗 GitHub: iCore on GitHub

🔗 JitPack: iCore on JitPack

I'm looking forward to your feedback and contributions. Happy coding!

Changelog

v1.24.4 - 2024-06-24 - Flat Sun

Focus in this release has been on improving and refactoring frontend code, adding UI features such as column and row hiding and locking through Visibility and Position meta classes. Other UI related features, such as supporting the height and width of individual cells have also been implemented, allowing for column and row span functionality.

Additional frontend changes include adding a marker, which allows cells to be selected and improves the way input is passed on to underlying UI cell content. This allows for better widget and chart functionality among other improvements for code that wishes to extend the frontend functionality.

Finally, a more flexible approach is now supported around providing custom HTML/CSS/JS allowing for alternative styling and other such changes to the frontend rendering. Two view configs are provided out of the box to illustrate this, the compact and the spacious, with compact being the default choice when using show(..).

It is expected that this will be the final alpha release of v1.

Added

• Add a cell marker, allowing cells to be selected with input passed to underlying cell content
• Add functionality to position columns to the left or right and rows to the top or bottom
• Add functionality to hide columns and rows
• Add support for custom UI config with custom HTML/CSS/JS
• Implement cell height and width rendering when these are defined on cell

Fixed

• Nothing

Changed

• Rename init parameter to receiver for on(..) functions and process to processor on related for improved API intuition
• Change HTML structure of cells, also harmonize this with column and row headers
• Update widgets and charts to work with frontend changes
• Various documentation updates relating to changes

Removed

• Nothing

Cross-posted from: https://programming.dev/post/13516196

I came across this post (and more like it) claiming extensions to be a good, or at least different, solution for mapping DTO's.

Are they though? Aren't DTO's supposed to be pure data objects? I've always been taught to seperate my mappings in special mapping services or mapping libraries like MapStruct and ModelMapper for implementing the good practice of "seperation of concerns".

So what about extensions?

I have a screen where I want a lazy-loading card of various items below some necessary information, all of which will scroll down. My initial approach was to nest the lazycolumn under the card which is nested under a Column with a calculated nested height based on the size of the calls list. However, I can't do that, and neither can I do the following.

``` @Composable @Preview fun mockup() { val calls = mutableStateListOf(Pair(1..418, 418 downTo 1)) MaterialTheme { LazyColumn(Modifier.verticalScroll(rememberScrollState())) { item { Text("Text and some necessary UI elements") Slider(value = .418f, onValueChange = {}) } Card(Modifier.fillMaxWidth()) { items(calls.asReversed()) { Row { Text(it.first.toString(), Modifier.fillMaxWidth(0.5f), fontWeight = FontWeight.Black) Text(it.second.toString(), Modifier.fillMaxWidth(0.5f)) } } } } } }

```

I found https://stackoverflow.com/questions/68182413/compose-lazylist-section-background, for which the only viable solution found was to hack a special composable widget so that when combined, it looks like a continuous card. Still, I want to see if there's a "proper way" of doing this...

I've had a long time fascination with Conway's Game of Life, and with the Sigbla APIs starting to stabilize I thought it would be fun to play around a bit and implement it as an example.

You can find the Conway example code here, and it should hopefully, even if you're unfamiliar with Sigbla, be fairly straight forward to understand.

It's using various core features, such as views, batching, transformers and cloning, with about 100 lines of code to get it all working. It's not really what I would envision Sigbla being used for, but it's a fun little example..

!Conway's Game of Life in Sigbla

Looks like we have some extra support for Kotlin projects.

1. http4k
2. mockk

Each given $2,500 (which is chump change for a company like Target, but it's better than 0) from https://opencollective.com/target-tech

If you've played around with version catalogs enough, you will inevitably come to a point when you when you want to also use a BOM in your version catalog. Doing that just feels so...clunky? You need to declare the BOM in the libraries section, and then you have to declare each individual dependency from the BOM as a library (without a version). Alternatively, you can just skip using the BOM entirely and declare each dependency without the BOM. In either case it's not a great experience and definitely could use some improvement.

I wrote a Gradle plugin (in Kotlin) to automatically generate a version catalog from a BOM so you only have to specify it once, let me know what you guys think!

Hello developers!

I need some programming advice and I hope that I am not off-topic. I couldn't find a more relevant group in Lemmy.

I have a Gradle convention plugin (written in Kotlin) that needs a buildscript classpath. But I can't get it to resolve correctly in the project.

1. If I add the buildscript classpath to the convention plugin and then apply the plugin to the project, it throws an error saying that buildscript is not allowed and the plugins section should be used instead.
2. If I add the buildscript classpath to the project itself (although this doesn't feel right because the convention plugin should be already compiled), then it throws an error saying that the dependencies are not met (classpath not applied).

Any advice?

I've for a good while been using an excellent port of Scala's persistent data structures in my Kotlin code known as Dexx. This also works well from Java code.

However, while the project is what I would call feature complete, it's no longer maintained, resulting in outdated dependencies. It would also become problematic should any bugs or issues pop up.

Hence I decided to fork it as Sigbla PDS and tidy it up a bit, with v1.0 now released and ready for use.

I was using freecodecamp's tutorial on Kotlin but I was told that a video isn't a good way to learn a language. So I did the hyperskill course but it marks all of my answers as wrong even when the code works, and the subscription for more than ten questions a day is crazy expensive. I will be getting atomic kotlin soon but I still want to learn before it comes

At least they took the grant from the Kotlin Foundation... Let's wait for version 3 to be ready!

It supports various data types, reactive programming and events, user input, charts, among other things.

Cross-post da: https://programming.dev/post/3241281

Seen this post by Donn Felker (!) on some other discussion platform and though I'd like to see the opinion of Lemmings about it.

Usually when I read a KMP article it talks about mobile. This one is about JS and the JVM.

>In this episode, we talk to Rick Clephas, one of the Kotlin Foundation Grants Program winners and the creator of KMP-NativeCoroutines and KMM-ViewModel.

When I last used KMP it was before the new memory model so I avoided coroutines as much as possible. A year later and it looks to be so much easier and better now.

Hey, I am trying to do some data storing on compose multiplatform for ios and Android and tried using Jetpack Datastores but it seems that the class Context does not exist for shared platforms does anyone have any ideas on how to do this?

I bumped into this interesting behavior around unsigned types. At first I was confused why UInt doesn't extend Number, but as I was experimenting, it got weirder. It sometimes is a Number (see case c below) and sometimes isn't (see case d)?!

``` val a: Int = 12 a is Number // true

val b: UInt = 12u b is Number // doesn't compile, Incompatible types: Number and UInt

val c: UInt = 12u (c as Any) is Number // true, Idea says "No cast needed"

val d: Any = 12u d is Number // false ```

I guess this is partly legacy of Java, which doesn't have unsigned types, and partly effect of UInt being value class. I'm curious if someone has a deeper explanation.