I still haven't quite got this "Intent" thing down when it comes to the details. What I'd like to do is to receive an intent when a certain email attachment is opened. The attachment will be a file that is actually an SQLite database with a structure specific to my app, and with a file extension that is also specific to my app.
What I've noticed in experimenting with this is that, when I send the file attachment from my PC (using Thunderbird), it is coded with a MIME type of "application/octet-stream". When I try to open this on my Android phone (using K-9 mail), it tells me that there is no app for "application/octet-stream".
So what do I do in my app to be recognized as a servicing app for this particular type of attachment, especially since I expect it's not a good idea to try to open anything with this MIME type.
So what do I do in my app to be recognized as a servicing app for this particular type of attachment, especially since I expect it's not a good idea to try to open anything with this MIME type.
You don't.
Inventing new documents as email attachments doesn't work well pretty much anywhere. Android is just a notch worse in this regard.
You cannot realistically set up an ACTION_VIEW <intent-filter> by MIME type, because your MIME type is too general. You cannot set up an ACTION_VIEW <intent-filter> by file extension, because there is no file extension on email attachments as is processed by the AOSP email app, and perhaps other email clients as well.
I encourage you to abandon email attachments as a delivery vector for your files, and find some other solution where you can have a customized MIME type (e.g., download the files from a Web server, with the emails containing a link to the files). Then, an ACTION_VIEW <intent-filter> by MIME type can work OK.
Related
What I want is a custom intent-filter that can receive any file types like text, audio, image, video, apk, pdf, word, excel, power point, etc sharing from other apps. The important thing that must be mentioned is that my app is a file sharing app. Using mentioned mimeType in intent-filter, caused any sharing content received in my app like shared location, text and everything else. However I want to accept only physical shared files:
<data android:mimeType="*/*"/>
And also based on this documentation which said:
filters can list just a data type and don't need to explicitly name
the content: and file: schemes
putting these two schemes (file and content) with mentioned mimetype doesn't resolve the problem.
Using mentioned mimeType, caused any sharing content received in my app like shared location, text and everything else.
Well, sure. ACTION_SEND is for sharing content.
However I want to accept only physical shared files
That is not possible on Android using ACTION_SEND. You are welcome to use some other Intent action, such as ACTION_VIEW, where the scheme used in your <intent-filter> will be applied.
I was wondering if there is any way to save a string of text (URL) to an NFC tag, let us say MIFARE or NTAG203, that can be read by other devices (smartphones) without the need of any special tag reading application.
I have tested several applications, e.g. Trigger for Android, and noticed that if the device reading the tag does not have the required application to read the data/instructions off the tag it still opens a URL that sends you to the Play Store to download that application.
So there must be a way to save some data readable by all/some NFC enabled phones. Simply put I want to create an applcation for Android that will write data to NFC tags and the data can be read/opened/executed by a random NFC enabled phone.
So is it possible to prepare an NFC tag that triggers some action on the reading device without requiring a specific application? What type of data could I write on an NFC tag with my app to achieve this?
First of all, in general, I agree with CommonsWare point of view that it's always a "special" app that handles NFC events. However, when looking into Android, I would consider the various platform apps from AOSP as part of the Android system. Even though not all of them may be available on all devices.
Looking into Andrid 4.4+, the following data types are handled by such system apps:
Browser: URIs with schemes "http:" and "https:".
Contacts and Dialer: MIME types "text/vcard" and "text/x-vcard" for importing contacts.
E-mail: URIs with scheme "mailto:"
In addition, if no other app handles a certain tag, NFC devices should(?) have the Tag app, that tries to handle various types (upon user confirmation):
URIs with scheme "tel" will cause an ACTION_CALL intent to call the given number.
URIs with schemes "sms"/"smsto" will cause an ACTION_SENDTO intent to start editing an SMS message.
Other URIs should(?) be forwarded in ACTION_VIEW intents.
MIME type records with type "text/x-vcard" (if not already handled) should be forwarded in ACTION_VIEW intents.
The text message of Text RTD records (not text/* MIME types!) should be displayed in the Tag app. Unfortunately many stupid(!) NFC apps register for Text records, thus you will normally not get to the Tag app.
MIME type records with type image/* (if image type is supported by Android) should be displayed in the Tag app.
Some records are handled by the NFC service itself (this should always be available on Android):
Android Application records (NFC Forum external type with type name "urn:nfc:ext:android.com:pkg") cause an ACTION_VIEW intent with the URI "market://details?id={PACKAGE_NAME}" to be sent.
NFC Forum external types with type name "urn:nfc:nokia.com:bt" are parsed for Bluetooth connection handover.
NDEF messages starting with a Handover Select RTD record and containing a MIME type record of type "application/vnd.bluetooth.ep.oob" are parsed for Bluetooth connection handover.
Everything with NFC involves an application for responding to the tag. Whether that is a "special tag reading application" depends on your own personal definition of "special tag reading application".
For example, some Web browsers will support NDEF-formatted tags with the payload being a URL. But that's a browser thing, not an OS thing. For example, the AOSP browser app has the manifest entry to respond to NDEF-formatted tags with URLs beginning with http or https. By my definition of "special tag reading application", the AOSP browser is a "special tag reading application". While hopefully all NFC-capable devices will ship with a Web browser that supports NDEF-formatted tags, that's not guaranteed.
If your "some data" is anything else, whether or not there is an app that is set up to respond to that sort of data. After URLs, the next-most-common tag payload is identified via a MIME type, just like you use with Web apps, and so if there is an app installed that supports NDEF and is set up to respond to your MIME type, it will pick up your data. This is no different than having your Web server serve up content under some MIME type -- an app needs to be installed that honors http/https URLs (or files downloaded by a browser) and that MIME type.
if the device reading the tag does not have the required application to read the data/instructions off the tag it still opens a URL that sends you to the Play Store to download that application
An AAR (Android Application Record) was added to the NDEF message written to the NDEF-formatted tag. That is the only NDEF item that can be thought of as being handled by the platform itself, and that's only for devices that support the Play Store (and apps that are distributed via the Play Store).
I have built an app that generates JSON files that store app data with a custom file extension. I'm currently using a standard ACTION_SEND intent and adding the Uri to the world readable file. I tried setting the type as application/json however this brought up an error saying that 'No applications can perform this action'. Would it be more effective not to send a MIME type even though I have code for detecting files coming into the app with a specific type. Is there a better way of doing this sharing procedure?
I'm currently using a standard ACTION_SEND intent and adding the Uri to the world readable file. I tried setting the type as application/JSON however this brought up an error saying that 'No applications can perform this action'.
In android I didn't find any application which displayed JSON file as a Viewer document. May be its available, If available then just install it in your device and check the mime type which it responds to View particular JSON file.
Its better to parse this JSON file and make (Convert) it to Text or HTML file, then using Intent with ACTION_VIEW you can view this file in many pre-installed application on your device..
When someone longpresses a link and chooses share link and select my app it grabs it and does what it does.. but this also works with other sharable text items. I would like to only accept links. Currently i have the mime type as text/plain. Is there a mime type for links?
No, sorry. At least for the standard Android browser, it uses text/plain. You are welcome to examine the value that is sent to you, see if it looks like a URL via a regular expression, and pop up an error indicating that you only send links.
In theory, you could even then turn around and execute startActivity() for the same Intent, to allow the user to choose something else to try sharing with. I have not tried this, though, so there could be some hiccups here that I am not aware of.
I am reading the intent filter of the android, and having a few question need to ask.
Do they match the filter within the same application or all of the applications?
The scheme within the data tag, I have looked on the documentation on the android sdk website but no idea what it mean. It say scheme://host:port/path or pathPrefix or pathPattern
What is the host port and path .... What does the path relate to?
1) Depends on the type of intent that was requested. See implicit vs explicit intents in the "Intent resolution" section of the docs:
http://developer.android.com/guide/topics/intents/intents-filters.html
If you name the component exactly then you know which activity will launch. Other intents name a generic action and can be matched by multiple activities. The user gets a menu asking which app they want to use to complete the action normally. For instance download the Firefox app from the Marketplace and click on a link in an email, you'll get a prompt asking if you want to use the Browser or Firefox to open the URL.
2) That's for intercepting a custom URL scheme or overlaying HTTP requests. Sounds like that not something you're interested in doing, you can safely ignore it unless you need to use it. If you do want more info about it there's a question with some good answers already:
Launch custom android application from android browser
1) see #mikerowehl answer
2) data is referenced through Uniform Resource Indentifiers (URI's). In Android, scheme could be http, tel, file, content (don't know about others) and by specifying a certain scheme in a filter you're saying that your component can handle data provided that way.
host+port=authority. In case of a data whose scheme is http, host will of course be something like stackoverflow.com, port will probably be left unspecified (if you're accessing a proxy it could be 8080). In case of a content provider, the authority is by convention "the fully-qualified class name of the content provider (made lowercase)", without a port.
This should be the general idea. Documentation in this field is pretty scattered but you should be able to find information on a particular task (say opening email attachments) when you'll need.