piannaf’s avatarpiannaf’s Twitter Archive—№ 2,467

                    1. Highlights from Today's #TouchlabShare with @ahmedre Android lead @careem and has also worked @fb_engineering, @TwitterEng, and @evernote @TouchlabHQ/1256331779499122690
                  1. …in reply to @piannaf
                    His team used callbacks to delegate threading to the platforms. On a new team now, but previous team was building SDKs where #KotlinMultiplatform made a lot of sense. #TouchlabShare
                1. …in reply to @piannaf
                  Two rules of the #KotlinMultiplatform threading * immutable and shared between threads * mutable and confined to a single thread #TouchlabShare
              1. …in reply to @piannaf
                Immutable singletons can be called on the main thread or background thread and you get the right calculation. Instances of a mutable class gives you an error. This can be confusing or surprising when you first see it. #TouchlabShare
            1. …in reply to @piannaf
              What you are seeing is that Kotlin on iOS doesn't know that the class is immutable. Pass it through a freezer that tells the runtime that it is immutable (frozen) and it works. #TouchlabShare
          1. …in reply to @piannaf
            Properties of objects are frozen by default. The @threadlocal annotation makes it so you can have different instances in different threads without error. But what if you want to share the same mutable object between threads? #TouchlabShare
        1. …in reply to @piannaf
          There are concurrency classes like AtomicInt kotlinlang.org/api/latest/jvm/stdlib/kotlin.native.concurrent/-atomic-int/ that allow you to do more with objects between threads #TouchlabShare
      1. …in reply to @piannaf
        You might want to mark global state as SharedImmutable kotlinlang.org/api/latest/jvm/stdlib/kotlin.native.concurrent/-shared-immutable/ #TouchlabShare
    1. …in reply to @piannaf
      The Callback Pattern is useful for Multithreading in #KotlinMultiplatform. For example, on the iOS side you can create a background calculator, that runs on another thread while communicating with the shared Kotlin code. #TouchlabShare
  1. …in reply to @piannaf
    You may not know that an object is part of an object's subgraph, and freeze() will freeze the entire graph of an object so you sometimes need to check that something is frozen. #TouchlabShare
    1. …in reply to @piannaf
      Unit tests (in commonMain) are your friend. Tests can catch properties of objects getting frozen, etc. See also @JakeWharton's post jakewharton.com/litmus-testing-kotlins-many-memory-models/ #TouchlabShare
      1. …in reply to @piannaf
        You can't assume that the shared code will work on iOS if you start on Android first. You may want to start with iOS first to ensure the shared code meets expectations #TouchlabShare
        1. …in reply to @piannaf
          Think about immutability early. Does something need to be mutable or not? What made multithreading easier for iOS devs was being able to see a simplified sample app to see how it works from the iOS side #TouchlabShare
          1. …in reply to @piannaf
            Ahmed encourages anyone who hasn't got into it yet to start small and the value becomes clear very quickly. His coworkers agree that #KotlinMultiplatform is a mindset, and once you get into the mindset, you start seeing more opportunities to share code with Kotlin #TouchlabShare
            1. …in reply to @piannaf
              Thanks @ahmedre! That's it for today. Join us next time to get all the details and have a chance to ask questions to the presenters. #TouchlabShare