# annotation-processor Published articles for annotation-processor. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Scaling with Deeplinks on Android DevFeed: [Scaling with Deeplinks on Android]() Original publisher: [Read original article]() Author: Doximity Published: 2024-04-08T11:34:00Z Content type: tutorial Language: en Sources: [Doximity]() Topics: [Android](), [Kotlin](), [Code](), [Library]() Tags: [android](), [annotation-processor](), [build](), [code](), [complexity](), [deeplinks](), [dependencies](), [kotlin](), [library](), [manifest](), [mapping](), [module](), [pipeline](), [route]() ### AI overview This tutorial explains how to scale Android deeplink handling as definitions grow from a small set to dozens. It describes reducing router boilerplate with annotations and build-time code generation, and simplifying order-sensitive routing by mapping top-level paths to deeplink definitions. ### Source excerpt Deeplinking support in Android is relatively straightforward. You declare your deeplinks in the app's manifest, receive the incoming Intent passed in to your Activity and then navigate the user to the associated destination. This pipeline works just fine when you only need to support a handful of deeplinks. What happens though as the number of deeplinks grow? How do you deal with several dozen, or possibly even hundreds, of deeplinks? First Stab at Deeplinks When we first implemented deeplinking in our app, we only had to support 12 different deeplinks. We introduced a DeeplinkRouter class that would take the incoming Intent and determine where to navigate the user: interface Deeplink { fun route(uri: Uri): Boolean } class NotificationsDeeplink(val navigator: Navigator) : Deeplink { override fun route(uri: Uri): Boolean { return if (uri.path == "/notifications") { navigator.goToNotifications() true } else { false } } class ProfileDeeplink( val navigator: Navigator, val userRepository: UserRepository ) : Deeplink { override fun route(uri: Uri): Boolean { val profileId = uri.getQueryParameter("id") val isCurrentUser = userRepository.getCurrentUser().id == profileId return if (uri.path == "/profile" && profileId != null) { navigator.goToProfile(profileId, showColleagues = isCurrentUser) true } else { false } } } // ... more deeplink definitions ... class DeeplinkRouter( notificationsDeeplink: NotificationsDeeplink, profileDeeplink: ProfileDeeplink, // ... ) { private val deeplinks = listOf( notificationsDeeplink, profileDeeplink, // ... ) fun route(intent: Intent) { intent.data?.let { uri -> deeplinks.find { it.route(uri) } } } } Problems at Scale As the number of deeplinks and the complexity of their definitions grew, two big issues started to emerge. The first was managing the sheer number of deeplinks - we had nearly 50 at one point! Each of these had to be injected into DeeplinkRouter and then passed to its internal deeplinks list. We decided to resolve this by int ## Scaling GraphQL development at Meetup DevFeed: [Scaling GraphQL development at Meetup]() Original publisher: [Read original article]() Author: Doug Tangren Published: 2024-02-05T22:11:32Z Content type: article Language: en Sources: [Making Meetup - Medium]() Topics: [GraphQL](), [Development](), [maintenance]() Tags: [annotation-processor](), [code](), [development](), [graphql](), [java](), [maintenance](), [testing]() ### AI overview Meetup describes how it scaled GraphQL development by reducing maintenance and turnaround time for common GraphQL changes. The article examines GraphQL Java's DataFetcher and TypeRuntimeWiring model, and explains how repetitive schema wiring and file organization created complexity and testing difficulties. ### Source excerpt Photo by Alev Takil on Unsplash At Meetup we're invested a great deal of our products technical strategy in GraphQL. For our core product API's we lean heavily on GraphQL Java for exactly that. Scaling can be defined in several ways. Typically people talk about scaling out servers to handle request load. In this post I'll take about scaling (in) development time, through the lens of reducing load placed on developers so they can make better use of their time. Over the years we've evolved our practices to optimize for reducing maintenance and faster turn around time for common GraphQL-oriented changes. This post outlines our current practices based on what we've learned. To start off, it's useful to introduce the vocabulary of GraphQL Java. A DataFetcher is the interface through which you fetch data for a given field or set of fields that a GraphQL client selects. GraphQL Java invokes these when a client selects their associated field based on a TypeRuntimeWiring which is what binds your code to your GraphQL schema. To some degree you can think of this like AWS Lambda where the trigger integration is GraphQL Java and your functions are DataFetchers. In fact we're not the first to think of that analogy . In our humble beginnings we started out with an approach that looked similar to the hello world example in the GraphQL docs: a single class with multiple runtime type wirings for various fields. This quickly grew unwieldy so we split that into multiple files which represented types and all of their respective fields. This worked for a while, but not before a few less than obvious issues started to creep in. Exposing a field meant writing the code that fetched the field's data and also the code required to wire that into the schema, and that became onerous. The latter was very repetitive, sometimes error prone, and the file that contained that grew slowly but surely into the same shape as our initial approach over time. It surfaced as nonessential complexity to new eng ## Annotation Processing DevFeed: [Annotation Processing]() Original publisher: [Read original article]() Published: 2023-12-11T00:15:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Java](), [Kotlin](), [Code](), [Development](), [Library]() Tags: [annotation](), [annotation-processor](), [code](), [implement](), [java](), [java-libraries](), [kotlin](), [testing](), [workshop-learning-programming]() ### AI overview This tutorial explains how Java annotation processing works and how to implement a custom annotation processor in Kotlin/JVM. It describes processor-generated files, notes that annotation processing requires Kotlin/JVM and javac, and introduces Kotlin Symbol Processing (KSP) as its successor for a later chapter. ### Source excerpt Implement your first annotation processor in Kotlin. ## Kotlin JSON Benchmark on Android (2022): Moshi vs Kotlin Serialization DevFeed: [Kotlin JSON Benchmark on Android (2022): Moshi vs Kotlin Serialization]() Original publisher: [Read original article]() Author: Christophe Beyls Published: 2022-10-14T17:31:03Z Content type: comparison Language: en Sources: [Stories by Christophe Beyls on Medium]() Topics: [JSON](), [Kotlin](), [Benchmark](), [Gson](), [build times](), [Code generation](), [legacy]() Tags: [android-app-development](), [annotation-processor](), [benchmark](), [gson](), [json](), [kotlin](), [kotlin-serialization](), [legacy](), [moshi](), [performance](), [serialization](), [vs]() ### AI overview This article sets up a 2022 Android benchmark comparing Moshi and Kotlin Serialization for JSON serialization and deserialization of Kotlin classes. It discusses Kotlin metadata compatibility, generated adapters, reflection, streaming support, Okio integration, runtime dependencies, and build-time tradeoffs. The supplied text does not include the benchmark results or identify which library is fastest. ### Source excerpt When it comes to automatic serialization and deserialization of Kotlin classes using the JSON format, the two main libraries compatible with Kotlin metadata are currently Moshi and Kotlin Serialization. This compatibility is especially important for non-null types and default values during deserialization, where lack of proper Kotlin support could result in unexpected values occurring at runtime, such as null values in non-null fields. If you're still using legacy libraries like Gson to parse Kotlin classes, it's time to reconsider. Moshi has been supporting Kotlin classes since version 1.5.0, released in 2017. One year later, the next major release 1.6.0 added an annotation processor to generate adapters for Kotlin classes at compile time. I was quite interested in the performance gains allowed by this solution and wrote an article detailing what the generated code does. JetBrains released version 1.0.0 of Kotlin Serialization in 2020 with built-in support for JSON. This library generates adapters at compile time similarly to Moshi's annotation processor while being compatible with more platforms and formats. The lack of initial support for streaming was disappointing, so I didn't even consider using it in production until streaming support was eventually added in version 1.3.0 in 2021. The JSON engine had also been rewritten in the meantime in order to improve performance. Recently, version 1.4.0 added integration with the Okio library, the same library used by Moshi under the hood. Now that Kotlin Serialization looks full-featured and well-optimized, I thought it would be a good time to compare its performance against Moshi on Android devices with some benchmarks. Which one is the fastest? Take your bets. The contendersMoshi-Kotlin Reflection The runtime Kotlin plugin of the Moshi library. The JSON adapters are generated at runtime using reflection. The main downside of this library is that it adds a runtime dependency to the big kotlin-reflect library (currently ## Using Kotlin Symbol Processing (KSP) to Generate Enum Mappers DevFeed: [Using Kotlin Symbol Processing (KSP) to Generate Enum Mappers]() Original publisher: [Read original article]() Author: Vaios Tsitsonis Published: 2022-08-02T10:45:00Z Content type: tutorial Language: en Sources: [Blueground Engineering blog]() Topics: [Kotlin](), [Gradle](), [Boilerplate](), [Compiler](), [build times]() Tags: [android](), [annotation-processor](), [build-times](), [compilation](), [gradle](), [how-to](), [kotlin]() ### AI overview This tutorial explains Kotlin Symbol Processing (KSP), its advantages over Java annotation processing, and how to set it up with Gradle. It demonstrates using KSP to generate mapper classes for enums and reduce duplicated conversion code. ### Source excerpt Let's prepare the ground Before we start examining how to use KSP a.k.a Kotlin Symbol Processing, let's say a few words about what it is. For the familiars with the annotation processing, we could say that is an annotation processing tool for Kotlin. This ## Compiling a Kotlin application with Bazel DevFeed: [Compiling a Kotlin application with Bazel]() Original publisher: [Read original article]() Author: Marc Plano-Lesay Published: 2019-12-08T00:30:00Z Content type: tutorial Language: en Sources: [Marc Plano-Lesay]() Topics: [bazel](), [Kotlin](), [Dagger](), [Maven](), [Command-line interface]() Tags: [annotation-processor](), [bazel](), [dagger](), [dependencies](), [dependency](), [how-to](), [java](), [kotlin]() ### AI overview A tutorial on compiling a small Kotlin application with Bazel. It explains the Phosphorus application's structure, its image-comparison purpose, Maven dependencies, rules_jvm_external, tests, Dagger's annotation processor, and Kotlin integration. ### Source excerpt This post will describe how to compile a small application written in Kotlin using Bazel, tests, as well as how to use static analyzers. Phosphorus Phosphorus is the application that this post will cover. It's a small utility that I wrote to check if an image matches a reference. If it doesn't, Phosphorus generates an image highlighting the differences. The goal is to be able to check that something generates an image in a given way, and doesn't change - at least if it's not expected. The actual usage will be covered later in this series. While it's not open-source yet, it's something I intend to do at some point. It's written in Kotlin, as a couple external dependencies ( Clikt and Dagger), as well as a few tests. This is the structure: classDiagram namespace loader { class ImageLoader { <> } class ImageIoLoader { } } namespace differ { class ImageDiffer { <> } class ImageDifferImpl { } } namespace data { class Image class DiffResult } class Phosphorus ImageIoLoader ..|> ImageLoader ImageDifferImpl ..|> ImageDiffer Phosphorus --> ImageLoader Phosphorus --> ImageDiffer Phosphorus's class diagram The differ module contains the core logic - comparing two images, and generating a DiffResult. This DiffResult contains both the straightforward result of the comparison (are the two images identical?) and an image highlighting the differences, if any. The loader package is responsible for loading and writing images. Finally, the Phosphorus class orchestrates all that, in addition to processing command line arguments with Clikt. Dependencies Phosphorus has two dependencies: Clikt, and Dagger. Both of them are available as Maven artifacts. In order to pull Maven artifacts, the Bazel team provides a set of rules called rules_jvm_external. The idea is the following: you list a bunch of Maven coordinates and repositories, the rule will fetch all of them (and their transitive dependencies) during the loading phase, and generate Bazel targets corresponding to ## AutoValue Extensions DevFeed: [AutoValue Extensions]() Original publisher: [Read original article]() Published: 2016-05-16T07:00:00Z Content type: tutorial Language: en Sources: [Blogs on Ryan Harter]() Topics: [Code generation](), [Extension](), [Code](), [Java](), [serviceloader](), [Protocol (disambiguation)]() Tags: [annotation-processor](), [article](), [code](), [code-generation](), [extensions](), [java](), [maven](), [serviceloader]() ### AI overview This tutorial explains AutoValue Extensions, which extend AutoValue's compile-time generation of immutable Java value types. It describes how extensions add functionality to generated implementations, are discovered through Java ServiceLoader, and can support integrations such as JSON, Protocol Buffers, databases, and Android Parcelable. ### Source excerpt This is the third article in a series on AutoValue. The first article introduced AutoValue, the code generating annotation processor for value types. The second took a more in depth look at the code generated by AutoValue, and the benefits of compile time code generation. In a previous article introducing AutoValue, I briefly mentioned AutoValue Extensions. Now it's time to go a bit more in depth to look at what extensions are, how they work, and how they can help you get even more out of AutoValue. ## A Deeper Look at AutoValue DevFeed: [A Deeper Look at AutoValue]() Original publisher: [Read original article]() Published: 2016-04-08T07:00:00Z Content type: tutorial Language: en Sources: [Blogs on Ryan Harter]() Topics: [Java](), [Code](), [Android](), [Gradle](), [Maven]() Tags: [annotation-processor](), [code-completion](), [dependencies](), [gradle](), [isn-t](), [java](), [maven]() ### AI overview This tutorial examines how AutoValue works as a compile-time Java annotation processor. It explains the effects of generated code on application size and performance, and describes configuring AutoValue correctly for Android Gradle projects and Maven builds to avoid bundling processing dependencies in the final application. ### Source excerpt In my last article, I gave a basic introduction to AutoValue, the code generating annotation processor that makes immutable value types in Java easy. Now I'd like to take a bit of a deeper look at AutoValue and how it works. Compile Time Annotation Processing First things first, AutoValue is a compile time annotation processor. This means that it only runs when you compile your code, as opposed to when your app is running. This has a few implications for your app, namely that including AutoValue doesn't significantly effect your application's performance or size. ## An Introduction to AutoValue DevFeed: [An Introduction to AutoValue]() Original publisher: [Read original article]() Published: 2016-03-22T07:00:00Z Content type: tutorial Language: en Sources: [Blogs on Ryan Harter]() Topics: [Java](), [Library]() Tags: [annotation-processor](), [class](), [constructor](), [dependencies](), [java](), [library](), [object](), [properties](), [property]() ### AI overview This introductory tutorial explains Java value types and the boilerplate required to make them immutable, compare them by property values, and provide useful string representations. It presents Google's AutoValue library as an annotation processor that generates this routine code, with extensions added in a recent update. ### Source excerpt Value types in Java are hard. Well, not hard, but tedious. Google's AutoValue library makes them much easier and has just received the long awaited update that adds the flexibility of extensions. Value Types in Java Before we can talk about how great AutoValue is, let's look at the problem it solves: value types. A value type is simply an immutable objects whose equality is based on property values, as opposed to identity. Think of a Money object: ## Annotation Processing 101 DevFeed: [Annotation Processing 101]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2015-06-05T00:00:00Z Content type: article Language: en Sources: [Hannes Dorfmann]() Topics: [Boilerplate](), [Java](), [Android](), [Programming](), [Compiler]() Tags: [android](), [annotation-processor](), [code](), [compiler](), [generate](), [java](), [programming]() ### AI overview This presentation introduces Java annotation processing, explaining how compiler hooks can generate code from annotations. It covers reducing boilerplate in Java and Android applications and aims to teach attendees how to write annotation processors. ### Source excerpt Writing Java application can be annoying because the Java programming language requires to write boilerplate code. Writing Android apps makes no difference. Moreover, on Android you have to write a lot of code for doing simple things like setting up a Fragment with arguments, implement the Parcelable interface, define ViewHolder classes for RecyclerViews and so on. ## Annotation Processing 101 DevFeed: [Annotation Processing 101]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2015-01-10T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [Java](), [Compiler](), [Code]() Tags: [annotation-processor](), [blog](), [compiler](), [files](), [generate](), [how-to](), [java](), [reflections]() ### AI overview This tutorial explains Java annotation processing, including how it works at compile time, what annotation processors can generate, and what they cannot change in existing classes. It then begins a step-by-step implementation of a simple processor. ### Source excerpt In this blog entry I would like to explain how to write an annotation processor. First, I am going to explain to you what annotation processing is, what you can do with that powerful tool and finally what you cannot do with it. In a second step we will implement a simple annotation processor step by step. ## AnnotatedAdapter DevFeed: [AnnotatedAdapter]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2014-09-24T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [Android](), [Code](), [Development]() Tags: [android](), [annotation-processor](), [code](), [development](), [layout](), [recyclerview](), [view](), [xml]() ### AI overview A tutorial introducing AnnotatedAdapter, an Android annotation-processor approach for generating repetitive RecyclerView adapter code such as layout inflation, ViewHolder setup, and view-type handling. ### Source excerpt With FragmentArgs and ParcelablePlease I have already shown that Annotation Processor is really helpful to speedup development by reducing writing boilerplate code. Regarding Android I found one scenario where I find myself writing nearly the same code ever and ever again. I'm looking at you Adapter with your ViewHolders, layout inflating code and view types. ## ParcelablePlease: Generating Android Parcelable Code with Annotation Processing DevFeed: [ParcelablePlease: Generating Android Parcelable Code with Annotation Processing]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2014-09-24T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [Android](), [Boilerplate](), [Code](), [Java]() Tags: [android](), [annotation-processor](), [blog-post](), [code](), [fragments](), [java](), [parcelable]() ### AI overview This tutorial introduces ParcelablePlease, an Android annotation processor intended to reduce boilerplate code when implementing Parcelable. It compares the approach with Parceler and AutoParcel, explaining their generated wrapper or subclass designs and compatibility trade-offs. ### Source excerpt In my last blog post I have introduced FragmentArgs an Annotation Processor for Fragments that reduces writing boilerplate code. In this post I want to talk about a similar problem android developer face: Writing boilerplate code for Parcelable This post is part of a series of posts about useful annotation processors like FragmentArgs or AnnotatedAdapter