Skip to content
This repository has been archived by the owner on Sep 4, 2019. It is now read-only.

File Uploader not working with headers #119

Open
praveen3184 opened this issue Nov 29, 2012 · 10 comments
Open

File Uploader not working with headers #119

praveen3184 opened this issue Nov 29, 2012 · 10 comments

Comments

@praveen3184
Copy link

Hi,

I downloaded FileUploader extension plugin and used it in my code, when i tried to setting header value mentioned in the example code. When i try to upload the file am getting error, in the device log i was able to see my header name and value in the webworks.io.FileUploader error description.

Can you let me know how to use headers in the FileUploader extension.

@gottsohn
Copy link

If you remove the header setting, the error will go away, I also have a problem with this extension, it timeouts every time, it has never worked for me (on both OS 6 and 7.1) simulate and non-simulator, I did exactly as in the example.
I always get this timeout error message. I've tried everything possible. The only option I have is to use iframes which is no good because it change widget's focus..

HELP

Local connection timeout after ~ 30000

@timwindsor
Copy link
Collaborator

What transport options have you set in config.xml?

What headers are you using?

Perhaps a sample would help us debug it easier.

@gottsohn
Copy link

I got and error when I tried to set header content-type to multipart/form-data so I currently set no headers.

I get a timeout error right after net.rim.tcp in my event log of device.

I currently didn't set any header values, do you think I should manually set rim:connection though its consequential, but I'm getting desperate..iframes have failed the purpose in webworks widget

@gottsohn
Copy link

Name: IOException
GUID: 9c3cd62e3320b498
Time: Jan 25, 2013 23:06:29
TCP transmit timed out
net_rim_io_impl(50B7D961)
TcpOutputStream
write
0x315F
net_rim_os-3(50B7E006)
ClientProtocol
writeRequestBytes
0x157A
net_rim_os-3(50B7E006)
ClientProtocol
writeFirstChunk
0x14A8
net_rim_os-3(50B7E006)
ClientProtocol
writeRequest
0x71C
net_rim_os-3(50B7E006)
ClientProtocol
flushOutputStream
0xB4A
net_rim_os-3(50B7E006)
StreamingHttpOutputStream
flush
0xB3E5
net_rim_cldc-1(50B7D8C2)
DataOutputStream
flush
0x221D
rftp-11(510209C7)
UploadRunnable
run
0x8BC
net_rim_cldc-2(50B7D8C2)
Thread
run
0xAAEE

@gottsohn
Copy link

In an attempt to combat the problem I used rim:connection, which is
unnecessary but I got desperate.

which still didn't help.

I'm using a the filePicker extension to select the file, everything works
perfectly, the app also makes connections successfully using XHR, but when
I try the fileuploader, it throws the IOInterrupted error, Local connection
timeout,


For the headers I tried setting "content-type":"multipart/form-data", i got
a whole new error in the event log, so i left the header blank.

On my device i'm getting the Connection closed exception right after
net.rim.tcp

**all these errors were spotted in the event log of the simulator/device

@gottsohn
Copy link

I found the problem/solution, the extension only works with TCP connections (via Wifi or APN). Doesn't run with BIS-B as everyone prefers. Any suggestion as to how to make it work with BIS-B or WAP2 or WPTCP(TCP for BIBS) like xhr does in webworks widgets.

@praveen3184
Copy link
Author

I too got the same problem while transferring over BIS-B. If you found any solution for this let me know.

Thanks for your reply.

@darmie
Copy link

darmie commented Dec 12, 2013

@chukxx have you solved this problem, my app seems to be doing same. It worked without Wifi before, now it doesn't work anymore until wifi is turned on.

@gottsohn
Copy link

the file uploader doesn't work with BIS, so if you aren't connected to wifi and you don't subscribe to a data plan, most service providers charge at a flat rate.

I stated this in the app i developed with it, as also made another version of the app that uses the method stated below, and runs smooth on OS 5 devices:

The only way i solved this was to use HTMLfile upload DOM element, in a HTMLform, which uploads to an iframe (the HTMLform's target). And the iframe calls on "onload" event when the upload is done.

However using iframe in webworks application gives rise to more bugs as the window changes focus to the iframe, thereby making all your app functions as well as window.blackberry === undefined. Would be perfect if you could get the focus back to the original window (parent.window).

So when the upload it done and the "onload" is called you try transfer focus back to the original window, and remove the iframe from the DOM stack

@darmie
Copy link

darmie commented Dec 13, 2013

Shit, can you give a mini example of how you did this? This project of mine is enterprise!!
Sent from Phoenix.

-----Original Message-----
From: Godson Ukpere [email protected]
Date: Fri, 13 Dec 2013 03:09:21
To: blackberry/WebWorks-Community-APIsWebWorks-Community-APIs@noreply.github.com
Reply-To: blackberry/WebWorks-Community-APIs [email protected]
Cc: [email protected]
Subject: Re: [WebWorks-Community-APIs] File Uploader not working with headers
(#119)

the file uploader doesn't work with BIS, so if you aren't connected to wifi and you don't subscribe to a data plan, most service providers charge at a flat rate.

I stated this in the app i developed with it, as also made another version of the app that uses the method stated below, and runs smooth on OS 5 devices:

The only way i solved this was to use HTMLfile upload DOM element, in a HTMLform, which uploads to an iframe (the HTMLform's target). And the iframe calls on "onload" event when the upload is done.

However using iframe in webworks application gives rise to more bugs as the window changes focus to the iframe, thereby making all your app functions as well as window.blackberry === undefined. Would be perfect if you could get the focus back to the original window (parent.window).

So when the upload it done and the "onload" is called you try transfer focus back to the original window.


Reply to this email directly or view it on GitHub:
#119 (comment)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants