On Mon, Mar 25, 2013 at 11:58 AM, Howard W. Smith, Jr. <
smithh032...@gmail.com> wrote:
> On Mon, Mar 25, 2013 at 11:54 AM, Howard W. Smith, Jr. <
> smithh032...@gmail.com> wrote:
>
>> On Mon, Mar 25, 2013 at 9:00 AM, Thad Humphries <thad.humphr...@gmail.com
>> > wrote:
>>
>>> On Sun, Mar 24, 2013 at 4:46 PM, Konstantin Kolinko
>>> <knst.koli...@gmail.com>wrote:
>>>
>>> > 2013/3/25 Thad Humphries <thad.humphr...@gmail.com>:
>>> > > I have a web-app that uses a servlet for downloading files from a
>>> > > repository--PDF, Office, images, zip, etc. It works with desktop
>>> > > browsers--IE, Firefox, Chrome, and Safari--on their various
>>> platforms. It
>>> > > also works fine with Firefox from Android (2.3 and 4.x tested).
>>> However
>>> > > when I try with Android's default WebKit browser, the servlet fails
>>> > > immediately with org.apache.catalina.connector.ClientAbortException
>>> (so
>>> > > says the stderr log).
>>> >
>>> > 1. Is this issue specific to some kind of files, or it occurs with all
>>> of
>>> > them?
>>> >
>>>
>>> All of them--PDF, XLS, DOC, DOCX, TIFF, ZIP, etc. Every file type I've
>>> tried.
>>>
>>
>> Hmmm, interesting thread (and responses so far). I think I am aware of
>> this 'Android default Webkit browser' you are referring to. I always avoid
>> using it, and download Google Chrome from Google Play store to my Android
>> devices, and I don't think I ever tested my web app with the default
>> browser installed on Android devices.
>>
>> I have downloaded PDF files (generated in-memory) from my java/JSF web
>> app to Android device, and I have never seen this ClientAbortException. my
>> web app also has at least one iPad enduser (which has Google Chrome
>> installed on iPad). I am unaware of his experience and I don't think he
>> downloads PDF files from web app to his iPad, but I am quite confident that
>> it works or will work. :)
>>
>> > >
>>>
>> > > I suspect this is a problem with mobile WebKit, and that circumventing
>>> > the
>>> > > abort might be a "bad thing" even if it's possible. However I
>>> thought I'd
>>> > > inquire here if there is a Tomcat way around it. If not, it seems my
>>> > > alternatives are (1) use Java Mail to mail the user the file, since
>>> mail
>>> > > apps open their attachments; and (2) write iOS and Android apps file
>>> > query
>>> > > and downloading. Neither prospect thrills me.
>>>
>>
>> Okay, i just tested this with/in my web app on my Google Nexus 7
>> (android, of course). I offer Download, Print, and View hyperlinks within
>> the web app. Mind you, this is PrimeFaces xhtml below.
>>
>> ---download---
>> <p:commandLink value="Download" ajax="false"
>>
>> actionListener="#{pf_ordersController.refreshContractsToDownload()}">
>> <p:fileDownload value="#{contractToDownload.file}"/>
>> </p:commandLink>
>>
>> Test and results:
>>
>> clicked Download button, PDF downloaded to Google Nexus 7 (Google Chrome
>> browser, of course), showed up in notifications, instead of PDF Viewer app,
>> I selected to open the PDF document in Adobe Acrobat (app that was
>> downloaded from Google Play).
>>
>> ---view---
>> <h:commandLink value="View" target="_blank"
>>
>> actionListener="#{pf_ordersController.refreshContractsToDownload()}">
>> <p:fileDownload value="#{contractToDownload.file}"
>> contentDisposition="inline"/>
>> </h:commandLink>
>>
>> Test and results:
>>
>> clicked View button, I saw another web page tab open rather quickly in
>> the Google Chrome browser on Google Nexus 7, and then the new tab closed
>> immediately, and then I saw the 'Starting download' toast (at bottom of
>> Google Nexus 7), but I didn't see the file in notifications or downloads,
>> and I didn't see any exceptions in my TomEE/tomcat7 logs.
>>
>> With that said, maybe I just duplicated this issue/exception that you
>> have been experiencing. If I'm not mistaking, PrimeFaces is using the
>> servlet solution for file downloads.
>>
>> So, based on this test of mine, it is best to offer a 'download'
>> hyperlink 'only' on mobile devices as I am already detecting mobile devices
>> when they login to the web app.
>>
>> Thanks for this topic. now I know what i 'need' to do. :)
>>
>>
> Forgot to mention; i would definitely provide an option for files to be
> emailed to endusers. my web app has that option as well as it is more
> reliable.
>
> i have found that endusers do a lot of multi-tasking on mobile devices,
> and mobile browsers seem to lose connection when they go to some other app.
> i may not be describing this correctly, but I have noticed this behavior,
> myself.
>
>
UPDATE:
1. Reached out to 2 mobile endusers of my web app that does file downloads
2. iPad enduser says that the View commandLink
(contentDisposition="inline") works 'always', he has no issues
3. Android enduser informed me that the View commandLink
(contentDisposition="inline") 'does not always' work, sometimes it works,
sometimes it does
4. Per the test results, this email thread, and what my endusers want, i
just made a change to 'only' provide the View commandLink
(contentDisposition="inline") to iPad (and nonmobile devices), and the
Download commandlink is provided to Android endusers
