BigMichi1
commented
10 years ago I understand what you mean, it is up to you if you give the developer the restriction to make clear what your framework expects as a parameter or to be less strictly and force the developer to read the docu and he must understand that he needs to include the magical _id column. With the restriction you can focus the developer more on the business columns instead of the technical restrictions that the android framework has when working with thecontent providers. I can tell you from my daily work that nobody reads really javadoc and you can't put as much restrictions to the framework. The work that needs to be done to change from an existing implemention to provigen is not really much for this case. The existing contracts must be modified eighter because of the new annotations so doing this additional change is not worth to speak about. And if you force the user to use the baseclass you can react better of the changes by the android framework, like the magical _count column.
Hi @BigMichi1,
Thank you for this contribution. :)
I feel like helping the developer figuring out how to use the ProviGenProvider is a good thing. And maybe we can improve the ProviGenProvider's javadoc to guide people a bit more.
About enforcing the contract class to inherit from ProviGenBaseContract, I feel like it's a good thing to do for auto-completion and clarity, but on the other hand it's less flexible. I imagine someone working on an existing code base who want's to replace the existing ContentProvider implementation with ProviGen. Maybe he already have some contract class with custom stuff used by other components and changing how his contract class is used across his code base may be painful.
If his current contract class could looks like :
He will need to replace every reference to
PersonIDwith_ID.What do you think ?
I'm wondering if I'm thinking things to deeply or not. :)
Tim