I need to fetch and list the received emails in my own layout listview.
Is this possible through Content Provider?
There are no documented and supported content providers for "received emails". "Email" is not really a part of the operating system (though there are a few lingering references to it from back in the 2006-2007 timeframe when there was no clear distinction between the OS, apps, and the SDK). There are probably hundreds of email clients, only a few of which might have such content providers, and probably no standards between them.
You will find some blog posts and other answers here on StackOverflow that point you to a Gmail content provider. This is an example of an undocumented and unsupported content provider. It was also just closed off by Google.
You are welcome to write your own email client, store your own emails, and display them as you see fit, though.
Related
I want to create a Contact Provider so I can populate it from our database and let our business workforce to have all the customer data. That's the "easy" part.
But what I need is to isolate those contacts and avoid them to be cloned disallowing the people to copy/clone them and loosing track of that information.
Is there a way to do that? I haven't found a way to do that and I think the only way is to show the contacts in a custom Contact app. The problem with that solution is that it wouldn't be possible to know who's calling.
Is there a way to do that?
On an Android device, there will be roughly zero lines of code that knows anything about a custom ContentProvider that you create. If you do not want to share data from that provider, do not offer any UI to allow people to share data from that provider, and do not export the provider to third-party apps.
I haven't found a way to do that and I think the only way is to show the contacts in a custom Contact app
You needed to write that anyway. There are ~2 billion Android devices. None of them will have a Contacts-style app that knows anything about some custom ContentProvider that you create.
The problem with that solution is that it wouldn't be possible to know who's calling.
Correct. After all, the devices' call managers do not know anything about your custom ContentProvider.
Now, it could be that by "create a Contact Provider", you really meant "not create a Contact Provider". In this case, the "it" in "I can populate it from our database and let our business workforce to have all the customer data" might mean the standard Android ContactsContract ContentProvider. In this case, the Contacts app and in-call screens and everything else that works with contacts will work with your contacts. However, this is a system-supplied ContentProvider, exported to third-party apps, with documentation and so on. There are thousands of apps, both pre-installed and available via the Play Store and elsewhere, that can work with ContactsContract. You have no means of stopping that, and you have no means of preventing those apps from doing whatever it is that they want with this data.
IOW, you cannot satisfy "I want the Contacts app to have my contacts" and "I do not want the Contacts app to have my contacts" at the same time.
I need to make an app, similar to Google Now, which would search other apps content that is exposed via Content Providers.
The problem I have, is that all resources I found talk about making your app searchable, but I need the opposite - how to search through all those apps? Is this a private API that only Google Now uses or can I also make such an app?
Currently, I managed to get a list of all searchable apps by reading all meta tags and filtering those with "android.app.searchable" but there must be a better way.
The logical flow should be:
find apps with "android.app.searchable" meta tag
read searchable.xml config to get the content provider
query the content provider from search box
I have been asked to add a "share" method to one of my Android applications which allows users to share by 1) Facebook 2) SMS and 3) Email
While researching, I have found that to allow users to select from "messaging" applications, I need to create the following Intent:
Intent messageIntent = new Intent(Intent.ACTION_SEND);
messageIntent.putExtra(Intent.EXTRA_SUBJECT, title);
messageIntent.putExtra(Intent.EXTRA_TEXT, content);
messageIntent.setType("vnd.android-dir/mms-sms");
// title and content set elsewhere...
This kind of works, although I am also given email clients in my list...
My Questions:
Is there a list somewhere of the Android specific MIME types that are available for us to use? The "vnd.android-dir/mms-sms" seemed pulled out of thin air to me from the example I found.
Is there the proper way to get ONLY messaging clients (ie. not mail clients) - or is that pretty much impossible to do in Android.
Disclaimer: The above code snippet was found from another SO post. Perhaps it is just me failing at Google - but I cannot seem to find any documentation on the legit Android developer site which listed out that this was the correct way to do this, or what my options are.
I have been asked to add a "share" method to one of my Android applications which allows users to share by 1) Facebook 2) SMS and 3) Email
Please allow the users to share how the users want, which may or may not be via those means.
I have found that to allow users to select from "messaging" applications, I need to create the following Intent
No, that allows users to share via any application that happens to support that undocumented and unsupported MIME type. Not every "messaging" application will necessarily support that MIME type, and applications that are not "messaging" applications are welcome to support that MIME type.
Is there a list somewhere of the Android specific MIME types that are available for us to use?
Not really, as generally they are undocumented or under-documented (e.g., the constant shows up somewhere without explanation).
The "vnd.android-dir/mms-sms" seemed pulled out of thin air to me from the example I found.
It probably came from the Android source code.
Is there the proper way to get ONLY messaging clients (ie. not mail clients) - or is that pretty much impossible to do in Android.
There are ~7 billion people on the planet. Each of them is welcome to have a different idea of what a "messaging client" is, what a "mail client" is, etc. Those are descriptive marketing terms, not technical definitions.
ACTION_SEND is for sharing content via MIME type. Any application can offer to support ACTION_SEND for any given MIME type, as the developers of any application can write what they want. Whether any given application is a "messaging client", "mail client", or something else is up to the end user. You have no means of reading the minds of users, nor do you have any legal means to prevent other programmers from writing what they want.
Now, there are various script-kiddie hacks for limiting the share list to certain apps, by application ID (a.k.a., package name). However, while there is only one Facebook (though I seem to recall they have a few apps), there are many SMS and email apps, and it would be difficult, if not impossible, for you to come up with a list of all of them, let alone maintain that list over time.
My strong recommendation is to format your content usefully, and allow the users to share that content using the apps that they wish.
I'm in a very big trouble in building a simple custom SMS/MMS content provider wrapper class as long as it doesn't exist an official one for the android platform.
Obviously, to get data, i query on the "content://sms" and "content://mms" content provider using a cursor.
I found it fairly simple with SMS, because the columns names are quite intelligible and contains all data that a typical programmer needs in his application ("person" to get the sms sender/receiver contact id, "address" to get the sender/receiver phone number, "type" to get if the sms is an inbox, outbox, draft, sended sms etc...)
Unfortunately with MMS i've found a lot of trouble. The columns has unintelligible names (ex. "d_tm", "ct_cls", "retr_st", "d_rpt" etc.) and basic informations that i need, such as contact id, phone number, the type of the mms etc... seems to miss.
How can i get this information over the MMS?
I searched over all the 32 columns of the content provider but i didn't found what i need.
Thanks in advance!
P.S.
I know that google advise to avoid this kind of "low-level" operation over content providers that doesn't have a series of official class to access them, but i imagine that software house that operates in sms/mms management such as HandCent or Go Dev team, have built their own content provider using the same approach i'm using too.
Am i right or it exists unofficial libraries to manage SMS/MMS?
Thanks!
I googled a little bit more and finally i found that the correct way to get information like contact_id, phone number, type etc. about MMSs, is to open the content provider to the following
URI: "content://mms/{MmsId}/addr"
({MmsId} is the MMS "_id" column value).
Here i found all information i need.
Hope it helps!!!
When querying a ContentProvider on Android, one specifies the ContentProvider of interest by providing the "content URI" for that ContentProvider. What happens when multiple ContentProvider's serve that same URI, either intentionally? or maliciously?
When trying to open a pic on my phone, I've seen it prompt with apps that can "handle" the image. Will the same kind of thing happen here?
Multiple ContentProviders can't do this. The first application that registers a content provider using the element in its manifest has control over the URI pattern. I'm pretty sure that you'll get an installation error if you try to add another provider that uses the same URI pattern. Android keeps track of providers and URIs.
When you see a prompt with multiple apps for handling a file or situation, that's because the apps have specified an with a child that includes
android.intent.category.CATEGORY_ALTERNATIVE or android.intent-category.CATEGORY_SELECTED_ALTERNATVE. In essence, the app or apps are declaring themselves to be alternatives to the action specified in the child. This allows the user to have multiple choices for handling a type of data.
It makes sense to provide alternatives: a user might want to edit a picture, share it via Twitter, or e-mail it.
Note that two content providers can do the same thing, but they can't use the same URI. An app has to make a conscious choice of which one to use, or provide some mechanism of choosing between the two.