juullabs / exercise Goto Github PK

Attempted to add macosArm64 target to SensorTag example but am now getting the following build time failure:

* What went wrong:
Could not determine the dependencies of task ':app:compileNativeDarwinMainKotlinMetadata'.
> Could not create task ':app:kspNativeDarwinMainKotlinMetadata'.
   > class org.jetbrains.kotlin.gradle.tasks.KotlinNativeCompile_Decorated cannot be cast to class org.jetbrains.kotlin.gradle.tasks.KotlinCompileCommon (org.jetbrains.kotlin.gradle.tasks.KotlinNativeCompile_Decorated and org.jetbrains.kotlin.gradle.tasks.KotlinCompileCommon are in unnamed module of loader org.gradle.internal.classloader.VisitableURLClassLoader @6db3646e)

Commenting out ksp(libs.exercise.compile) in app/build.gradle.kts allows the Native targets to build, but obviously breaks the Android target (because it relies on Exercise).

The readme is far from complete, and it definitely shouldn't be the only documentation we have.

Moshi has some here as an example of what they look like.

They seem to be backed by kotlin-compile-testing.

See: https://developer.android.com/training/basics/intents/result#kotlin

Use case here is easier integration into AndroidX Navigation (as an alternative to SafeArgs, since it's not supported when using the XML-free DSL).

@Exercise(Argument("foo", Int::class))
class DestinationFragment : Fragment() {
    // ...
}

class SourceFragment : Fragment() {
    fun navigateToDest() {
        findNavController().navigate(R.id.action, DestinationFragmentArgs(foo = 5))
    }
}

Not to assume the function name here.

Danger of implementing against an alpha API

This would be arguments, not extras, but I don't see why the same concept can't apply.

Would be really cool if this was more robust, instead of just being an isEqualTo with syntax highlighting.

Look into using Kotlin/grammar-tools or similar to provide something more robust.

See: https://github.com/android/kotlin

Exercise only makes sense on a JVM platform, so we don't need the cross-platform side of things, but KSP processes more quickly than KAPT does so there would be less of a compile time penalty.

The logic for creating a launch Intent can be exactly the same for Service as it is for Activity.

However, unlike an Activity, there is no getIntent function to power an extras extension property. Instead, services pass the Intent to functions as needed, such as IntentService.onHandleIntent(intent: Intent?).

Cleanest solution is probably something like this:

// Your Source
@Exercise(Extra("example", Int::class))
class MyService : IntentService() {
    init { setIntentRedelivery(true) } // Lets us ignore null intent case to simplify sample

    override fun onHandleIntent(intent: Intent) {
        Log.d("MyService", "Example extra: ${extras(intent).example}")
    }
}

// Generated
class MyServiceParams(
    private val intent: Intent
) {
    val example: Int
        get() = intent.extras.get("${intent.component.packageName}.example") as Int
}

fun MyService.extras(intent: Intent): MyServiceParams
    get() = MyServiceParams(intent)

We don't get the parameter as a val extension, but this is probably the best we can do.

Stop assuming that a Context's packageName is global to the application.

A lot of our feature prioritization is done so we can eat our own dog food. Would be nice if we didn't have to issue a release for every feature, so we could make them more meaningful.

When someone is using Exercise, it will generate code that uses bundleOf (androidx.core.os.bundleOf).

When setting up Exercise, library consumers will commonly use the following Gradle configuration:

implementation("com.juul.exercise:annotations:$version")
ksp("com.juul.exercise:compile:$version")

Unfortunately, the generated code will not compile if the core-ktx dependency is not manually pulled in, as annotations module does not define core-ktx as api (nor should it do so).

Not sure the best approach to getting core-ktx pulled in, aside from either instructing that consumers pull in core-ktx manually or pull in an Exercise module that has core-ktx as api.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency com.squareup:kotlinpoet to v1.18.1
• Update plugin kotlinter to v4.4.1
• Update plugin api to v0.16.0
• Click on this checkbox to rebase all open PRs at once

Detected dependencies