Kotlin Symbol Processing (KSP) and remedy to DRY code

Transcript

1. Kotlin Symbol Processing (KSP) & remedy to DRY code • Annotations • Processors • KSP • KSP vs the world • How KSP works • Our DRY case • Solution • Q&A Nikola Despotoski Android Tech Lead @ WSAudiology
2. Annotations • Introduced in Java 1.5 • Useful information about element in the source code • Relevant for the compiler and developers interacting with the code • Used on source code elements classes, properties, functions/methods etc
3. You’ve met them before:
4. Processors • Extract information to perform actions outside existing code • Code generation • Error checking
5. Kotlin Symbol Processor – KSP • A lightweight compiler buddy • Understands Kotlin language features • Faster alternative to KAPT, different • Understands Java and can produce Java code – alternative to previous annotation processors.
6. Features • Part of the build process • Improved performance and build time • Supports incremental and parallel processing • Reduced overhead when processing symbols • Fully compatible with Kotlin type system • Improved developer productivity & learning curve!
7. Use cases • API usage correctness checks • Code generation
8. KSP vs KAPT vs KCP: • KSP is faster compared to KAPT in larger projects • KAPT could be troublesome when incremental processing is enabled • KAPT has trouble understanding Kotlin • KCP is superior when it comes to accessing compiler mechanics • KCP can transform or manipulate the code directly in the source files or output build files, KSP can not perform such action
9. Through KSP lens: • Setup caveats • Kt file dissected • Anatomy of an annotation
10. Setup caveats
11. Setup caveats src/main/resources/META-INF/services/com.google.devtools.ksp.processing.SymbolProcessorProvider META-INF file must be create in the root of the processor module Must reference full name of the processor provider mk.nikola.ksp.demo.MyProcessorProvider
12. Kt file dissected
13. Kt file dissected
14. Kt file dissected
15. Kt file dissected
16. Kt file dissected
17. Anatomy of an annotation
18. Anatomy of an annotation
19. Anatomy of an annotation
20. Anatomy of an annotation
21. Anatomy of an annotation
22. Over and over again • Each Bluetooth request • Taking a lot of time • Repetitive and boring • Still experiencing DRY although good code reusability
23. Goal • Write all Bluetooth request in less time than we normally did • Measurable – user stories related to newly introduced services • Improved developer experience
24. Retrofit for Bluetooth requests • Similar Retrofit • Annotations inspired from HTTP methods (GET, PUT, POST etc) • Easy to use
25. R/W/N • @Read used for read requests • @Write used for write request w/ or w/out payload • @Notification receive Bluetooth notification • @WritePayload payload in Write request • @DeviceAddress denotes peripheral device address • @BluetoothService denotes container of the characteristics • @Priority connection priority
26. Ground rules • @Read requests can be a suspend function • @Write request might not require return type • @Notification functions return type must be Flow<T> • @WritePayload must be used on an argument • @DeviceAddress must be used on an argument of type String • @BluetoothService must be used on a class or interface • @Priority must be used on an Int argument
27. Ground rules • Strong type checks during evaluation • Ensure consistency and API correctness usage • Discourage misuse of the API
28. Steps
29. Apply
30. Apply
31. Apply
32. Apply
35. Codegen 1. Kotlin Poet https://square.github.io/kotlinpoet/ - Fluent API for generating Kotlin code - Interop with KSP 2. Code-as-string (plain text) 3. Maybe plug conversational AI?
36. Thank you! in/nikoladespotoski nikoladespotoski