Android Question web view problem !

[mrezaes]

hi friends!
i have a webform app that show a report in stimulreport component . when i choose save as pdf browser starts to download pdf but in web view i cant catch the file .
here is a link sample :
http://2.186.116.200:600/reporter.aspx?key=MAAyADkAOQAwADUA&m=5&hid=NgAyADUANQA3AA==&year=1402

pls provide a sample pls.

thanks .

 

[MicroDrie]

Use the search function in this forum

save a PDF file from WebView

And what do you think of post 5?

 

[drgottjr]

#1 webview is not a browser. webview can do some (many) things that a
browser can. it also cannot do many things that a browser can do.

there are 2 ways you can get your .pdf from that site (which looks suspiciously
like the bank where i hide my offshore money from my ex-wife):

1) using okhttputils2.
2) using webview's print facility.

i have tested both. both work for me.

there are, potentially, issues with either approach. that you could not see
how to download the file by yourself makes me wonder how much
experience you have trying to resolve conflicts between browsers
and webview.

i have attached both versions. as i said, they both work for me today.
neither one may work tomorrow. you would have to be in a position to
be able to figure out what may have changed. i refer particularly to the
dynamic nature of random values used as parameters. sites often
change values they assign to identifying features.

the okhttputils2 version does not use a webview. a webview - or even a
browser - is not needed to download the pdf. in fact, as you have already
discovered, you are unable to download the file using a webview so it
serves no purpose here. in order to download the file, you need only know
how to make the request. i simply used the browser to tell me what i needed
to know in order to make an independent request to download a file from the
site. the information provided by the browser is definitely valid for the several
times i tested downloading the file on android using okhttputils2. generally,
changeable parameters tend to be different with each request. in this case,
they did not change when i tested. that could mean you might be able to
download the file successfully whenever you wanted. note: okhttputils2 has
a "success" variable which does not always mean what you think it means.
it means there was no error in the request transfer. it does not mean the
response from the server was what you asked for. you would have to see
what the server actually said.

the webview version loads the site in a webview and then uses android's built-in
functions to capture the page as a .pdf file. this is due to the webview's not
being able to handle the way the site provides for downloading files.
so, while you cannot download the file directly, you can "print" it to a .pdf file.
that is what the second version does. it's not as smooth nor as fast as the
okhttputils2 version, but it does the job, and it does not depend on knowing
certain information which is only available from looking at the site in a desktop
browser. printing has to be enabled on your device. you may or may not actually
have to have a wifi printer attached for this to work. i do, so it does. webview is
told to create a print job of the current page. it does this, and the next thing you
see is a printing dialog. you select "save to file", and the pdf is save in your
documents directory. i can tell you right now you will not be happy with the
quality of the .pdf. it is very small because an android screen is small. even if
you transfer the file to a pc for display, it is very small. the result obtained from
using okhttputils2 is much better. when you use the webview version, you have
to wait until the spinning wheel stops and you can see the page before tapping
the "download" button. although the page load quickly, rendering takes a few
seconds.

if i forgot to mention it, version1 (okhttputils2) puts the file in safedirexternal, which
you can see from a PC. method2 (webview) leaves the file in your root files or
documents folder, which you can also see from a PC (as well as from the device).
that's what android does with it. in method1, it would be possible to store the file
in documents too, but it involves a bunch of extra code which i didn't add. you can
search for that and add it yourself.

 

[mrezaes]

#1 webview is not a browser. webview can do some (many) things that a
browser can. it also cannot do many things that a browser can do.

there are 2 ways you can get your .pdf from that site (which looks suspiciously
like the bank where i hide my offshore money from my ex-wife):

1) using okhttputils2.
2) using webview's print facility.

i have tested both. both work for me.

there are, potentially, issues with either approach. that you could not see
how to download the file by yourself makes me wonder how much
experience you have trying to resolve conflicts between browsers
and webview.

i have attached both versions. as i said, they both work for me today.
neither one may work tomorrow. you would have to be in a position to
be able to figure out what may have changed. i refer particularly to the
dynamic nature of random values used as parameters. sites often
change values they assign to identifying features.

the okhttputils2 version does not use a webview. a webview - or even a
browser - is not needed to download the pdf. in fact, as you have already
discovered, you are unable to download the file using a webview so it
serves no purpose here. in order to download the file, you need only know
how to make the request. i simply used the browser to tell me what i needed
to know in order to make an independent request to download a file from the
site. the information provided by the browser is definitely valid for the several
times i tested downloading the file on android using okhttputils2. generally,
changeable parameters tend to be different with each request. in this case,
they did not change when i tested. that could mean you might be able to
download the file successfully whenever you wanted. note: okhttputils2 has
a "success" variable which does not always mean what you think it means.
it means there was no error in the request transfer. it does not mean the
response from the server was what you asked for. you would have to see
what the server actually said.

the webview version loads the site in a webview and then uses android's built-in
functions to capture the page as a .pdf file. this is due to the webview's not
being able to handle the way the site provides for downloading files.
so, while you cannot download the file directly, you can "print" it to a .pdf file.
that is what the second version does. it's not as smooth nor as fast as the
okhttputils2 version, but it does the job, and it does not depend on knowing
certain information which is only available from looking at the site in a desktop
browser. printing has to be enabled on your device. you may or may not actually
have to have a wifi printer attached for this to work. i do, so it does. webview is
told to create a print job of the current page. it does this, and the next thing you
see is a printing dialog. you select "save to file", and the pdf is save in your
documents directory. i can tell you right now you will not be happy with the
quality of the .pdf. it is very small because an android screen is small. even if
you transfer the file to a pc for display, it is very small. the result obtained from
using okhttputils2 is much better. when you use the webview version, you have
to wait until the spinning wheel stops and you can see the page before tapping
the "download" button. although the page load quickly, rendering takes a few
seconds.

if i forgot to mention it, version1 (okhttputils2) puts the file in safedirexternal, which
you can see from a PC. method2 (webview) leaves the file in your root files or
documents folder, which you can also see from a PC (as well as from the device).
that's what android does with it. in method1, it would be possible to store the file
in documents too, but it involves a bunch of extra code which i didn't add. you can
search for that and add it yourself.

thanks for answer . but how did you get this code . i think i will be different for another link.( links are dynamic )


"stiweb_component=Viewer&stiweb_action=ExportReport&stiweb_parameters=eyJ2aWV3ZXJJZCI6IlN0aVdlYlZpZXdlcjEiLCJmb3JtVmFsdWVzIjp7fSwiY2xpZW50R3VpZCI6Ijk1ZGRhY2U4NDZjNjQzZDU4YjExYzkxNWIyZGZkZTk2IiwiZHJpbGxEb3duR3VpZCI6bnVsbCwiZGFzaGJvYXJkRHJpbGxEb3duR3VpZCI6bnVsbCwiY2FjaGVNb2RlIjoiT2JqZWN0Q2FjaGUiLCJjYWNoZVRpbWVvdXQiOjEwLCJjYWNoZUl0ZW1Qcmlvcml0eSI6IkRlZmF1bHQiLCJwYWdlTnVtYmVyIjowLCJvcmlnaW5hbFBhZ2VOdW1iZXIiOjAsInJlcG9ydFR5cGUiOiJSZXBvcnQiLCJ6b29tIjoxMDAsInZpZXdNb2RlIjoiU2luZ2xlUGFnZSIsInNob3dCb29rbWFya3MiOnRydWUsIm9wZW5MaW5rc1dpbmRvdyI6Il9ibGFuayIsImNoYXJ0UmVuZGVyVHlwZSI6IkFuaW1hdGVkVmVjdG9yIiwicmVwb3J0RGlzcGxheU1vZGUiOiJUYWJsZSIsImRyaWxsRG93blBhcmFtZXRlcnMiOltdLCJlZGl0YWJsZVBhcmFtZXRlcnMiOm51bGwsInVzZVJlbGF0aXZlVXJscyI6dHJ1ZSwicGFzc1F1ZXJ5UGFyYW1ldGVyc0ZvclJlc291cmNlcyI6dHJ1ZSwicGFzc1F1ZXJ5UGFyYW1ldGVyc1RvUmVwb3J0IjpmYWxzZSwidmVyc2lvbiI6IjIwMjEuMS4xIiwicmVwb3J0RGVzaWduZXJNb2RlIjpmYWxzZSwiaW1hZ2VzUXVhbGl0eSI6Ik5vcm1hbCIsInBhcmFtZXRlcnNQYW5lbFNvcnREYXRhSXRlbXMiOmZhbHNlLCJjb21iaW5lUmVwb3J0UGFnZXMiOmZhbHNlLCJleHBvcnRGb3JtYXQiOiJQZGYiLCJleHBvcnRTZXR0aW5ncyI6eyJQYWdlUmFuZ2UiOiJBbGwiLCJJbWFnZVJlc29sdXRpb24iOiIxMDAiLCJJbWFnZUNvbXByZXNzaW9uTWV0aG9kIjoiSnBlZyIsIkltYWdlUXVhbGl0eSI6IjAuNzUiLCJFbWJlZGRlZEZvbnRzIjp0cnVlLCJFeHBvcnRSdGZUZXh0QXNJbWFnZSI6ZmFsc2UsIlBkZkFDb21wbGlhbmNlIjpmYWxzZSwiT3BlbkFmdGVyRXhwb3J0IjpmYWxzZSwiQWxsb3dFZGl0YWJsZSI6Ik5vIiwiUGFzc3dvcmRJbnB1dFVzZXIiOiIiLCJQYXNzd29yZElucHV0T3duZXIiOiIiLCJLZXlMZW5ndGgiOiJCaXQ0MCIsIlVzZURpZ2l0YWxTaWduYXR1cmUiOmZhbHNlLCJHZXRDZXJ0aWZpY2F0ZUZyb21DcnlwdG9VSSI6ZmFsc2UsIlVzZXJBY2Nlc3NQcml2aWxlZ2VzIjoiUHJpbnREb2N1bWVudCwgTW9kaWZ5Q29udGVudHMsIENvcHlUZXh0QW5kR3JhcGhpY3MsIEFkZE9yTW9kaWZ5VGV4dEFubm90YXRpb25zIn19"

 

[drgottjr]

thanks for answer . but how did you get this code . i think i will be different for another link.( links are dynamic )

if you use method 2, you don't need any special code.

the links are visible in the developer's tab of the browser. i already suggested they would probably be dynamic.

for method 1 (okhttputils2), you need to analyze what the browser is doing and how it does it. what you are trying to do (and, frankly, i don't know what it is you are trying to do) is not meant to be done in a webview on a small device. i could be mistaken, but anything captured in a webview will reflect the size of the webview: the smaller the webview, the smaller the result. the only way around this is to deal with underlying code, that is obtaining resources without regard to how they fit on a tiny screen. you need to learn about browsers. this has nothing to do with b4x.

once you see what the browser is doing, you may or may not be able to translate it to a webview. in this case, the browser does a simple post to get the .pdf. because the buttons used in the browser's javascript code don't work in a webview, we can't use them. what to do? b4x has a tool to handle an http post: okhttputils2. we can use that. but we need to know what the browser is passing to the server in the post request. the browser tells you that if you trace what the browser is doing. once you see what is passed, you can copy it over to okhttputils2 to see if it works. it does. so that's what you do. if you don't pass the correct information, you get an answer, but it's not the .pdf. it only took 1 or 2 tries to see what was required. but the key is to analyze what the browser is doing.

by the way, here's a new method1. it lets you peek at the file after downloading so you can check if it's a pdf without going through the hassle of finding it with your pc (or writing something to open it up and view it as a pdf on the device.

 

[mrezaes]

if you use method 2, you don't need any special code.

the links are visible in the developer's tab of the browser. i already suggested they would probably be dynamic.

for method 1 (okhttputils2), you need to analyze what the browser is doing and how it does it. what you are trying to do (and, frankly, i don't know what it is you are trying to do) is not meant to be done in a webview on a small device. i could be mistaken, but anything captured in a webview will reflect the size of the webview: the smaller the webview, the smaller the result. the only way around this is to deal with underlying code, that is obtaining resources without regard to how they fit on a tiny screen. you need to learn about browsers. this has nothing to do with b4x.

once you see what the browser is doing, you may or may not be able to translate it to a webview. in this case, the browser does a simple post to get the .pdf. because the buttons used in the browser's javascript code don't work in a webview, we can't use them. what to do? b4x has a tool to handle an http post: okhttputils2. we can use that. but we need to know what the browser is passing to the server in the post request. the browser tells you that if you trace what the browser is doing. once you see what is passed, you can copy it over to okhttputils2 to see if it works. it does. so that's what you do. if you don't pass the correct information, you get an answer, but it's not the .pdf. it only took 1 or 2 tries to see what was required. but the key is to analyze what the browser is doing.

by the way, here's a new method1. it lets you peek at the file after downloading so you can check if it's a pdf without going through the hassle of finding it with your pc (or writing something to open it up and view it as a pdf on the device.

thanks . helps a lot.

 

[drgottjr]

#1 are the parameters from the developer's tab
#2 a snippet from the server's javascript. it shows it gets the .pdf file by making a post request. so i did the same thing (without the webview, since the buttons don't work in the webview)

 

[mrezaes]

unfortunately i could not solve the problem .
@Erel pls take a look at this thrad

 

[sirjo66]

I think that @drgottjrhave give to you the solution, but my question is:
Where did you get this link http://2.186.116.200:600/reporter.aspx?key=MAAyADkAOQAwADUA&m=5&hid=NgAyADUANQA3AA==&year=1402 ??
I think that you navigate to a website with webview object, and then you get this link.
Well, now you need to use OkHttpUtils2 and download it as an array of byte, and save it as PDF

 

[mrezaes]

I think that @drgottjrhave give to you the solution, but my question is:
Where did you get this link http://2.186.116.200:600/reporter.aspx?key=MAAyADkAOQAwADUA&m=5&hid=NgAyADUANQA3AA==&year=1402 ??
I think that you navigate to a website with webview object, and then you get this link.
Well, now you need to use OkHttpUtils2 and download it as an array of byte, and save it as PDF

the link has been generated from web app . i just want to download pdf