Thanks for the additional feedback.
>>Peli - Probably you should not mis-use getType()…<<
I originally choose getType() for simplicity (URI in -> String out),
but I will now use query() instead. However, as my application is not
compatible with any other software (i.e. my data exchange has no MIME
type), I would be interested if anyone could provide a concrete
example of where an inappropriate getType() response might cause
problems.
Also, for simplicity I am not using intents.
>>Dianne Hackborn - ...Along those same lines, looking for your own special
>>text in the authority to identify content providers you are going to work
>>with is also kind-of screwy. Typically how we do this is attach meta-data to
>>the component that whoever is interested in identifying specifically tagged
>>components looks for. Look at the way input method service components are
>>discovered in Cupcake as an example. <<
Here is a small component discovery rewrite, now using meta-data to
mark valid Content Providers:
####AndroidManifest.xml####
<provider
android:name="test.TheirContentProvider"
android:authorities="myComponentNamespace.theirApplicaitonNamespace"
>
<meta-data android:name="type" android:value="myComponentNamespace"/
>
</provider>
####Java Code####
List<ProviderInfo> pis = androidContext.getPackageManager
().queryContentProviders(null, 0, PackageManager.GET_META_DATA);
...
for(ProviderInfo pi:pis) {
Bundle md = pi.metaData;
if (md != null &&
md.getString("type") != null &&
md.getString("type").equals("myComponentNamespace")) {
//Congratulations you have now found a valid Content Provider
//Note: keep looking as you might find more
}
}
The upside of this is that the application developer can now deploy my
Content Provider using any URI namespace they choose. However, I will
still recommend the previous naming scheme to prevent damaging naming
conflicts.
>>Dianne Hackborn - …Also, have you thought about security at all? What kind
>>of information is stored on the content provider? Who can access it?<<
As I understand it, any cross application Content Provider on Android
needs to implement its own (i.e. roll-your-own) security solution when
handling incoming requests.
My current application (an advertising server) treats this as an open/
free to use API, with risk scenarios being managed mainly on the
server side.
My next application (component for peer-to-peer data sharing) will
require a custom Android Permission for sending data. This is similar
to the “android.permission.INTERNET” permission whereby the user still
gets a say as to whether the application can send data off the phone.
I am not yet confident enough in the security capabilities of Android
and/or my knowledge of them, to implement an application that handles
confidential data.
Regards
Mark
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
