Retrofit: java.lang.IllegalArgumentException: Method return type must not include a type variable or wildcard: retrofit2.Call<model.DataModelResponse<T>>

[andishejavan]

how define generic T class in interface api and rest mansger ?
api this

 @GET("api/customer/")
    Call<DataModelResponse<T>> getList(@Query("take") int page, @Query("skip") int step);

call rest manager this

mManager = new ServiceGenerator();
            Call<DataModelResponse<T>> listCall = mManager.getService().getList(ClientConfigs.PAGAE_RECYCLER, skip);

rest manager this

public Api  getService() {
        return Api;
    }

[ly1054]

"Method return type must not include a type variable or wildcard " it seems to be clear

[JakeWharton]

You cannot. Type information needs to be fully known at runtime in order for deserialization to work.

[developer--]

would be great

[lordplagus02]

So for example, a request such as:
Call<T[]> call = apiService.getResources(...); where T extends Resource would not be possible? (Resource being a class from the moshi-jsonapi library, which allows you to extend a class as a Resource.)
Would I then need to create a different retrofit API interface for each of these Resources?

Sorry to bring up old issues...

[JakeWharton]

Yes. Retrofit has no idea what type to create to fulfill that contract.

On Wed, Jul 19, 2017 at 8:53 PM Michael Barnett [e-mail]
wrote:

So for example, a request such as:
Call would not be possible? (Resource being a class from the moshi-jsonapi
https://github.com/kamikat/moshi-jsonapi library, which allows you to
extend a class as a Resource.)
Would I then need to create a different retrofit API interface for each of
these Resources?

Sorry to bring up old issues...

—
You are receiving this because you modified the open/close state.

Reply to this email directly, view it on GitHub
https://github.com/square/retrofit/issues/2012#issuecomment-316564976,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEEQBZjtVZlvDqL1k90Fi-rZLYoLV6ks5sPqUngaJpZM4J1bpG
.

[lordplagus02]

So... If I have 6 different types of resources, I'm going to create 6 different interfaces, and this is how people have been doing it the whole time? I'm sorry I'm just not sure what the alternative is here when trying to keep my code DRY.

[shahsurajk]

@lordplagus02
How about this, define the Call so as to return a JsonElement as the class type, something like this,
Call<JsonElement> getObjectByID(); and then parse the jsonElement yourself

CustomObject1 customObject1 = new Gson().fromJson(response.body().getAsJsonObject().toString(), CustomObject1.class);

CustomObject2 customObject2 = new Gson().fromJson(response.body().getAsJsonObject().toString(), CustomObject2.class);

So here, the parsing dependency is upon you and not retrofit. Hope it helps.

this way you can create just one interface for all object by ID queries, alternatively you can also add query map to add additional options and set null if not required.

[LessTalk]

oh This will be very troublesome

[shahsurajk]

You can create these methods once and then you're done. A utility sort of thing

[khushbu-shah]

yes It will work but May I have some more in explanation if possible with example with 2 or more service call
Thank you shahsurajk