kalpeshp0310
01/25/2023, 4:06 AMKotlinx_datetimeLocalDate
from Swift, and iOS developers do not feel comfortable working with it.Dmitry Khalanskiy [JB]
01/25/2023, 12:05 PMLocalDateTime
as much as I work on it, so I may be unable to help you. Rather, you can help us 🙂
It’s a pain to create an instance ofIsn't it enough to just call its constructor with the proper numeric values? Is it somehow worse than creating an instance of any other Kotlin class from Swift?from SwiftKotlinx_datetimeLocalDate
iOS developers do not feel comfortable working with it.What kind of work do they struggle with? Are there any specific examples of pain points? We also have some converter functions: https://kotlinlang.org/api/kotlinx-datetime/kotlinx-datetime/kotlinx.datetime/to-n-s-date-components.html Maybe it makes sense to convert
LocalDate
to NSDateComponents
and work with that, populating a LocalDate
when converting back?kalpeshp0310
01/25/2023, 8:18 PMLocalDateTime
to `NSDate`; the conversion function you mentioned is not available on the swift side. Those are only accessible from Kotlin files under the native src directory. And the other reason is the Long name Kotlinx_datetimeLocalDate
. I understand we are nitpicking. But if the names had been the same on both platforms, Like LocalDate
on JVM and Native side, they would feel like they are using just another Library and would not be constantly reminded that they are using Kotlin multiplatform library.
I guess the recent introduction of @ObjCName can solve the issue of the long name.eventDate
field of LocalDateTime
type. To consume that field and show the event date in UI, iOS devs need to convert that LocalDateTime
to Date
or NSDate
type and then convert it to `String`; Of course, we can use an extension function to simplify conversion. But wanted to see what other people were doing in this case.
There is the reverse case as well, where a user selects a date from the calendar UI, which gives a Date
object, and they have to convert it from the Date
type to the LocalDateTime
type before calling the createEvent
function from our common code.
I am not saying that it’s not doable. But it constantly reminds iOS developers that they are not talking to Swift library; They are talking to a library written in kotlin. This is a slight pain when the iOS team resists adopting/working with a library not written in Swift.Dmitry Khalanskiy [JB]
01/26/2023, 11:19 AMConvertThere's a conceptual confusion here: an equivalent totoLocalDateTime
NSDate
NSDate
is kotlinx.datetime.Instant
. And we do have NSDate.toKotlinInstant
/ Instant.toNSDate
.
the conversion function you mentioned is not available on the swift sideI think you're just a victim of dead code elimination. With some effort, you'll be able to access these functions. See https://github.com/Kotlin/kotlinx-datetime/issues/78#issuecomment-740573900
To consume that field and show the event date in UII personally am diligently working on the formatting capabilities in kotlinx.datetime right now, stay tuned, maybe you'll be able to format dates in KMM common code soon.
But it constantly reminds iOS developers that they are not talking to Swift libraryYep, the truth is, they are not. I'm just a library writer and not a KMM expert—if you want one of those, ask around in #multiplatform—but my personal understanding is that our libraries are not supposed to be treated as libraries for every platform. Instead, these are libraries for Kotlin code, and in turn, that Kotlin code can be used on different platforms. So, essentially, the idea is to write the whole thing in Kotlin, except the UI and the other interactions with the platform. For example, in your case, there could be some code in the Native source set that would accept an
NSDate
and call createEvent
with that, using the conversion function and keeping the fact that the Kotlin implementation uses kotlinx.datetime
completely hidden from the (small) Swift wrapper around the Kotlin-based functionality.
Still, I advise asking around #multiplatform regarding usage of Kotlin libraries directly from the platform code would certainly be more useful than my ramblings, as there are people there that actually have some experience with this. Sorry for the wall of text, I just didn't want to send you away empty-handed 🙂kalpeshp0310
01/30/2023, 2:34 PM