android - Is there a "proper" way to keep a content provider implementation seperate from it's users? -
i have custom contentprovider
class, developed in same project file application using it. since application intended 1 of many users of contentprovider
, want split in different project. code being developed on android pdk, future clients might developed on sdk (on custom sdk, or sdk plugin, etc).
the problem i'm facing, constants in contentprovider
class, e.g. content_uri, column names , constants used interpret values returned queries. these of course cannot accessed project. seems me have 3 options @ point:
1) ignore problem, , type in values directly in user application code. makes accessing contentprovider
uglier. have change columns, encode columns strings instead of integers, keep code maintainable.
2) put constants in separate class, , include full copy in applications using contentprovider
. i'm not fan of duplicating code though. keeping duplicate of code in each target app, make things more annoying maintain.
3) abuse fact i'm developing on pdk, , expose platform library, described in vendor/sample/frameworks/platformlibrary
. however, platform libraries don't have manifest file, if understanding correct means can't include contentprovider
. means need 1 "normal" project contactprovider
, , separate 1 expose class constant values. feels wrong.
the answer @ class structure contentprovider having multiple sub tables seems imply option (1), looks best option right now.
however, maybe have missed another, neat & tidy, way this? keeping in mind developing on pdk, contentprovider
usable in same manner stock google providers.
you have @ least 1 class/interface defines "contract" of contentprovider
using static constants column names, content uri, etc.
if put own android sdk library project (just android classes on build/classpath), can use library actual sdk/pdk application's contentprovider
, distribute myapp-api.jar
jar others use.
this way best of both worlds: no outdated code (because contentprovider
depends on it) , other people can use nice constants uris , column names.
for example of contract class, see contactscontract.
Comments
Post a Comment