I have generated a Vcard in rails and set it to download by using the following code
send_data Card.generate_vcard(asset).to_s, :filename => "contact.vcf", :type => "text/x-vcard; charset=utf-8",:disposition => 'attachment'
When someone goes to URL, the Vcard gets downloaded. But I also require that it automatically gets opened in phone's contacts app - or at least present an "Open with" option.
I followed this link http://lrvick.net/blog/accessibly_importing_vcards_from_qr_codes/ and went for second approach mentioned there, set the proper headers as well - but it is not work for me.
Thank you for Your Help
There is no way to do that, the file will just get downloaded.
You should also add a filename, such as
Content-Disposition: attachment; filename="name_surname.vcf"
I noticed some browsers would not accept it as vCard otherwise.
Besides, this encourages the user to click on the downloaded file (and open it).
For Apple:
iOS now accepts vCard, for older version (> 4) you can cheat and embed the .vcf in a calendar .ics. See this tutorial for more details
For oldest version (<3) you must send the vCard by email..
For both, the best solution should would a URI-Scheme that would let us add a contact. But that is not available yet, even though I know iOS has some specific tools for that.
We're waiting for a better HTML5 there :).
Related
I have a Vue.js website with a PDF file which is included in my ultimate javascript bundle via webpack. (It's my CV.) The following build and delivery process has worked perfectly fine for me since 2017, but suddenly stopped working in iOS 14:
Build the PDF with LaTeX.
Use webpack's url-loader to include the PDF in my webpack bundle as a base64 data URI.
Load that URL into a vuex data store, and then just deliver it as a link when clicked.
For the last three years, this has worked fine: I've been able to click on the link and get a working PDF. It's been kind of random and platform-specific whether the PDF opens in-browser or shows up in a download folder, and whether it gets the filename I've asked it to get or not, but, well, that doesn't matter to me. And the core functionality of click the link and get the PDF has worked on every browser and every platform I've ever tried it on.
All of a sudden, with iOS 14, it's stopped working. Now, when I try to activate the PDF link in iOS Safari, nothing happens at all. When I do it in iOS Chrome, it produces a little popup claiming it downloaded a document, but nothing seems to actually be able to open the document. And when I do it in iOS DuckDuckGo, it just displays the base64 data URI in the address bar.
Interestingly, if I take the dataURI that DDG displays in the address bar and copy and paste it into Safari or Chrome on iOS, it actually displays my pdf. So the browsers still have the capacity to display a PDF from a data URI. It just doesn't want to do so from my link.
And my site still works as expected on the desktop. Including in Safari on the desktop. Also, it still works on my wife's phone (she's still on iOS 13). So this is clearly something Apple changed in iOS 14. But what? And how to get my site working again?
I'm guessing that Apple has changed the behavior of the renderer in iOS in some fashion to cause it to break across browsers but nowhere else (since browsers in iOS are all still required to rely on webkit, right?)
This is a pretty important feature to me. I made this decision deliberately for perceived performance---combined with pre-rendering, everything on my site, including the PDF, loads very close to instantly from the user perspective. So I'd really like to keep it.
I'm using Webpack 2.6.1 and Vue 2.3.3. This is a stable build that has been working flawlessly for three years, so I haven't felt the need to update anything except for security updates.
After searching around, I did find this Apple dev discussion which suggests that in iOS 14, Apple newly blocks redirects to data URIs. But I'm not doing a redirect, I'm actually navigating directly to the URI through a link. And the linked discussion suggests that the newly banned behavior just brings Apple in line with what other browsers already ban---but my code works in every other browser, so that can't be it.
Relevant code, to the extent it matters (though it's so basic and obvious that I doubt a simple code fix will be the answer here):
from my webpack.base.js:
{
test: /\.(pdf)$/,
loader: 'url-loader'
},
from my vuex store, in state.js
import cvURL from './assets/pdf/gowdercv.pdf';
from the component containing the link that points to PDF:
<p><a :href="cvURL" download="gowdercv.pdf"><img src="../../assets/icons/file-pdf.svg" class="cvicon"> Download in PDF</a></p>
which is loaded as a computed property to the component, i.e.,
computed: {
cvURL: function(){return this.$store.state.cvURL;},
Does anyone know how to get functionality back in iOS? Is there a workaround built in recent versions of webpack or vue for this? Thanks!
Update: after some help off SO, an acquaintance turned up this similar problem, which also came up with a solution: turning the base64 URI into a blob and passing that data url. Which also solves my problem. Though that SO doesn't have an accepted answer, so I can't vote to close my own question as a duplicate, alas.
I'm currently working on a intranet webapp for a company.
I've created it so the administrators of the site are able to upload files
(.docx, .pdf, .xlsx, .ppt etc) up to the webapp, to provide easier access
to documents for the employees. It works very well, however my client wasn't
too fond of having to download the files, and wanted it to pop up in the browser,
or open up the file-spesific program instead of download.
I was playing with some ideas:
1. Somehow parse the files to JSON at upload, and then show the content in browser with html.
2. Generate a pdf from the uploaded file (which automatically launches in the browser).
3. Somehow use a previewer to show the filecontent in the browser
4. Clients computer launches the uploaded file automatically on download, however I think this is a bit more tricky...
What would be the best and most time-efficient way to go about this?
It feels like what you actually want/need is a javascript document viewer (only) such as http://viewerjs.org/.
We have a website where users pay for download access to a given document, and so we need to ensure the download can be successfully executed.
Our download action looks like this:
send_data generate_document(),
filename: "yourfile.pdf",
type: "application/pdf",
disposition: "attachment"
...and it works perfectly fine on all the browsers I've tested.
However, I often see download pages with prompts similar to the following:
"If your file doesn't download automatically, click this link."
What's the reason for those prompts? Why would downloads fail initially, and what happens differently when users click the link?
I think most of the cases it's for very old browsers (at least that's what I was told by my colleague). Also some websites implement this using JS, those who don't have it enabled for some reason, can't see the download.
When user clicks a link, he explicitly directs browser to that location, such actions usually should work everywhere.
I'm sending ICS files to Blackberry phones, and when you open the mail I get the following error on the phone:
application/X-rimdevicecalendar, that when opened, the BlackBerry smartphone states this attachment type cannot be viewed on your device.
I found in the blackberry knowledge base the problem, but I could not fix it. Does anybody knows how to fix it? How I should send the ICS files?
.ics files are the calendar event files for Apple's iCal calendar software. Some other apps support this file type, but not all ... and some of the ones that do have some problems doing so.
You have at least a couple choices, depending on how these calendar event files are being generated and sent.
you could try sending them as .vcs files instead (and of course, reformatting the content as VCS files)
if you are going to stick with .ics files, take a look at this CrackBerry.com thread
Basically, it looks like there is a workaround, where you might have to programmatically edit the .ics files, and replace this content:
METHOD:PUBLISH
with this:
METHOD:REQUEST
I haven't done this myself, so no guarantees. But, that looks like a promising potential solution that you could try.
I understand the basic of Document Interaction Programming and UIDocumentInteractionController and I've got it working in my app. However I'm having trouble with specific details of using custom file types. I can't find this addressed in the Apple docs anywhere.
My app uses it's own file types with unique extensions. The files themselves are just plists (xml), but I want the device to treat the files as only openable in my app. Originally I implemented the Document Interaction stuff to treat them as XML while I got it working, but now I want it to treat them as binary files that it needs to hand off to my app.
At the moment, if you have one of my files in an email attachment, iOS first shows the QuickLook (which just spews all the text content of the xml out) before you can choose to Open In. Similarly if one of my files is opened with Safari, Safari just shows the XML and doesn't give you the option to show it in my app at all.
So how do I get iOS to not treat my files as XML? I've changed the "Conforms to UTI" value and "public.mime-type" value in the info.plist, but it seems to have no effect.
Any tips greatly appreciated.
As far as i understand the UIT concept of Apple you cannot just change the file extension to change a potential UIT of the file. If the file contains XML-Data, other apps as well as internal apps might recognize your content and show it internally as XML.
Try to store your Plists with NSPropertyListSerialization NSPropertyListBinaryFormat_v1_0 (then you readble XML)
When you did that without success, why not trying this:
use zlib to compress the XML plists afterwards to a zipped file.
make a "unique" file extensions (<file>.myappname)
this should "hide" other apps and quick view.
Tell me if one of the ways did work for you.