anton-novikau / boringyuri Goto Github PK

when we declare path which contains the same keys
@UriBuilder("/bg/single/color/{color}")

BoringYuri generates uri without hardcoded path (in this particular case without /color/ path)

In the current configuration auto publishing a release version of artefacts doesn't work because of a PGP signature check on attempt to sign the artefacts:

* What went wrong:
Execution failed for task ':api:signMavenPublication'.
> Error while evaluating property 'signatory' of task ':api:signMavenPublication'
   > org.bouncycastle.openpgp.PGPException: checksum mismatch at 0 of 20

As a workaround publishing to MavenCentral is handled manually.

Hello!

I hope you are doing well!

We are a security research team. Our tool automatically detected a vulnerability in this repository. We want to disclose it responsibly. GitHub has a feature called Private vulnerability reporting, which enables security research to privately disclose a vulnerability. Unfortunately, it is not enabled for this repository.

Can you enable it, so that we can report it?

Thanks in advance!

PS: you can read about how to enable private vulnerability reporting here: https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository

When @UriFactory has additional annotation @WithUriMatcher there should be generated <factory_name>UriMatcher that extends android.content.UriMatcher and defines mapping between uri paths from the @UriBuilder annotated methods and matcher codes @MatchesTo(INTEGER_CODE).

New annotations to be added in boringyuri-api: @WithUriMatcher for target ElementType.TYPE and @MatchesTo(Int) for target ElementType.METHOD
New generator step to be added to UriFactoryProcessor: UriMatcherGeneratorStep

Add some lint checks for correct annotations usage. For example:

• generic type in BoringTypeAdapter matches the type of the method parameter
• @Path and @Param can not be used together
• @TypeAdapter is required for a non-standard type
• @Path must be @NonNull

And probably some more.

Independent Uri data interfaces can't inherit other independent data interfaces because @UriData annotation processor doesn't read parent's annotated methods (eg. @Path and @Param), so it can't generate implementation for them.

@UriData("/album/{genre}"
interface BaseAlbum {
    @Path("genre")
    String getGenre();
}

@UriData("/album/{genre}/{id}"
interface Album extends BaseAlbum {
    @Path("id")
    long getId();
}

in the example above the generated implementation of Album doesn't have an implementation for getGenre() so the compilation fails.

Workaround: copy annotated methods from the parent interface (override the parent's method), so you'll keep the class hierarchy in your code (so you may use a more abstract type when you need it) and the processor will know how to generate the implementation for the parent's methods.

@UriData("/album/{genre}"
interface BaseAlbum {
    @Path("genre")
    String getGenre();
}

@UriData("/album/{genre}/{id}"
interface Album extends BaseAlbum {
    @Override
    @Path("genre")
    String getGenre();

    @Path("id")
    long getId();
}

Add validation of the method parameters annotated with @Path and break the code generation if the parameter doesn't have @NonNull annotation or marked as @Nullable.

@StringParam, @BooleanParam, @LongParam and @DoubleParam annotations produce package private getter methods in associated data classes and they are not accessible outside of the data class package.

These getter methods are supposed to be public and must be accessible as all the other (non-constant) query parameters or path segments.

• Serialize every non-null item from Array typed method parameters with @Param into a bunch of query parameters with the same name:
  Example:

@UriBuilder("/friends")
Uri buildSaveFriendsUri(@NonNull @Param("name") String[] friends)

Calling builder.buildSaveFriendsUri(new String[] { "John", "Jane", "Meg" }) will build /friends?name=John&name="Jane"&name="Meg"

• Deserialize Array method parameters from repetitive query parameters.
  Example:
  For Uri /friends?name="John"&name="Jane"&name="Meg" and the builder

@UriBuilder("/friends")
Uri buildSaveFriendsUri(@NonNull @Param("name") String[] friends)

it will be deserialized as a String[] of 3 elements: John, Jane and Meg.

For the same Uri and the builder

@UriBuilder("/friends")
Uri buildSaveFriendsUri(@NonNull @Param("name") String friends)

it will be deserialized as a single String: John.

For Uri /friends?name="John" and the builder

@UriBuilder("/friends")
Uri buildSaveFriendsUri(@NonNull @Param("name") String[] friends)

it will be deserialized as a String[] of 1 element: John.

Serializing and deserializing of the Array items should be done in the same way as for single parameters: @TypeAdapter for the array component type on the method parameter, @TypeAdapter on the custom type of the array component, standard type convertor if the component type is supported.

Since Google released a stable version of KSP it makes sense to investigate how to port all the declared annotation processors to KSP and think how the library can work in pure java, hybrid (kotlin+java) and kotlin only environments.

Introduce a new annotation @DefaultValue to specify what value can be used instead of the one passed as a method parameter if the value of this parameter is null. The same annotation can be used for parsing data from the Uri as a fallback for not specified query parameter or for invalid data passed into the specified path segment or query parameter (eg. random string instead of a number for int type field).

Create an annotation processor that generates a Dagger module that provides the generated Uri factories as injectable Dagger dependencies.

Support of Dagger must be a pluggable option and shouldn't be a part of the core library API.

Since JFrog decided to shut down JCenter, it is necessary to publish Boring YURI to a different public repository. Sonatype's MavenCentral looks like the best alternative at the moment, so by the beginning of April 2021 the migration should be finished.

As a future enhancement for maintaining the repository there should be added GitHub Actions support for auto builds and publishing snapshots to Sonatype's snapshot repository.

Add support to insert a named @Path method parameter into an appropriate placeholder in the @UriBuilder base path.

Example:

@UriBuilder("/user/{id}/admin")
Uri buildUserUri(@Path("id") long id);

Java Enum is a constant type supported by annotations. Add support of constant query params based on enum type similar to @StringParam or @LongParam.

In 1.0.0 every instance of a custom type adapter is created at use to perform one operation: serialize or deserialize an object. There should be a possibility to cache and reuse BoringTypeAdapter instances to reduce wasting memory and minimize triggering garbage collector.

Annotation processors execution order not specified and can be especially tricky during incremental build. Sometimes build fails with:

error: [ComponentProcessor:MiscError] dagger.internal.codegen.ComponentProcessor was unable to process *my.package*.BoringYuriModule because not all of its dependencies could be resolved. Check for compilation errors or a circular dependency with generated code.

So I think boringyuri-dagger MUST be executed only after main boringyuri processor. Maybe it can be achieved by creating @BoringYuriGenerated annotation and adding it to all generated files. In this case boringyuri-dagger can listen for this annotation and generate dagger module when all dependencies could be resolved.

Dagger component that includes a generated BoringYuriModule can not be a Kotlin interface because kapt generates Java stubs for dagger annotation processor and the generated module that is added to @Component annotation has not created yet.

So the workaround is to get rid of the Java stubs generation step and make the Component a java interface. In this case Boring Yuri's dagger processor will be able to produce the module file before the Component is compiled.

If anybody knows how to fix the issue properly, you're welcome to pull request.

Since 1.1.4 using ordered path segments approach is deprecated in favour of named path segments. The ordered approach was introduced in version 1.0.0 and was maintained for compatibility. Since this approach is very unreliable and may cause some weird bugs in the generation it was decided to drop the ordered path support in 1.2.0