FEATURE REQUEST: Use Extension classes to support Customizations about android-contentprovider-generator HOT 2 CLOSED

Hello,

Your idea is interesting and I agree that it would be useful to be able to have a way to add your own code to the generated class, without it being overwritten when re-generating the code.

Your idea is to add to the hierarchy some classes that the user could touch, and that would not be overwritten.

There is another possible way to achieve the same result: to have a special "user" section at the end of each generated file (delimited by a specific comment marker that the generator would recognize), that would be kept when re-generating.

I am not sure which way is better... Here are a few pro/cons of each way. What do you think?

New classes in the hierarchy

• + Easier to implement in the generator
• - More classes in the project, including empty ones that most people won't need
• - Having code split in several classes may not be ideal (the class hierarchy existing solely because a tool is used, and not for because it makes sense otherwise)

User section

• + Less cumbersome (less generated files)
• - Harder to implement in the generator
• - A bit "hacky"... The comment delimiting the section would have to be very clear (and the documentation too)

Please don't hesitate to comment.

Regards,

from android-contentprovider-generator.

Hi.
At first, thank you for answering and starting the discussion.

the User section approach:
I use the generator outside of my project and then copy the generated classes back into the project, so it would not work in my case, but thats not really an argument against it :) I think it would be harder to understand for users and you would be bound to generating in place.

The new classes in the hierarchy approach:
-i would indeed extend the hierarchy with more classes. I would say, for the best extensibility it would be necessary that each and every class has an equivalent extension class.This would blow up hierarchy a "bit".
-We could make it configurable whether the classes shall be generated. The granularity of the confiiguration needs to be defined, but it would make sense to configure it per abstract classes set (_config.json) and per entity (Entity.json).
-we could package the extension classes in a subpackage of the entity and base classes, so it won't be too big in the AndroidStudio hierarchy viewer and empty classes won't take up much of the dex file method limit.

Regards.

from android-contentprovider-generator.