I develop with lwuit to Nokia and Blackberry.
I try to load from internet some images.
In Nokia all work fine, but in blackberry i get IllegalArgumentException.
I found that problem is occurs in createImage(byte[] bytes, int offset, int len) function . The device Log tell me that source function that occurs to fail is in encode Image class.
Do Anyone encounter this problem?
I found the problem. This occurs because i use POST method. I think in case that we dont send parametes but use method POST is occurs to problem with Content-Length in header of http message and this the reason that i recieve error(400 or 411)
The problem is probably related to networking in Blackberry which is well documented. There are multiple suggested fixes (e.g. using deviceside=true) which work for some cases but fail for others. Explaining RIM networking problems is just too much for this post, but we did solve these issues for Codename One.
Related
I have a website written in ASP.NET MVC (Razor). Recently, a few days ago the images on the website started swapping all over the place. When refreshing the site, it might just hang for quite some time or load all images correctly. So I plugged my iPhone to my Mac and used the web inspector to see whats going on. I found out that at the time of load the browser hangs on certain files. These files are either images or js libraries. The images are very small. Less then 10kb so it is not the size of the image.
This issue only happens on iPhones. I checked on several iPhones.
I have tried multiple Android devices, Mac and Windows computers and they all load fast and every image is in the right place - no issues.
I researched a bit and found out some interesting references to HTTP Pipelining. But if that was is the case, why would these issues start now?
I do not know what to thing anymore.
What am I trying to understand is why would that only happen on the iPhone?
Thank you,
Any clue would be appreciated.
I had the same issue. After months of breaking my head I decided to implement lazy load on all images. After that, swapping never occurred.
Page hanging could happen because of multiple reasons. I would definitely check the code again and in particular look for the way you handled unmanaged resources. More on unmanaged resources
I have weird issue running the last version of Raknet on iOS with Unity3D: I get CONNECTION_ATTEMPT_FAILED when trying to connect to the server.
Now let's me detail the issue:
he exact same Library connects fine when used in an ObjectiveC application, so the issue seems to be Unity3D related.
I already managed to pinpoint my issue to be located in Raknet reliability layer:
Apparently, during the last step of the connection process (when the connection handshake as been completed) the reliability layer of the server thinks that the ID_CONNECTION_REQUEST packet received from the client is an acknowledgment instead of a message. Therefore it doesn't answer. Ultimately after a few tries, (and a 10s timeout) the client fails with the CONNECTION_ATTEMPT_FAILED error.
Does anybody there as an idea? I will update the question when I manage to get more info.
Update
We are using Unity3D 5.1.1f1
We managed to find a workaround! See answer for more information. As the workaround doesn't tell us much about what really happened, I would gladly hear some C++/XCode/Unity/iOS/AppleLLVM6.1 experts around here explain what really happened.
The issue was that the Raknet header wasn't properly generated by the iOS client. Namely we were sending ACK messages in place of simple packets. The rest of the message was considered as garbage by the server and the packet was dropped. The client kept trying to send the corrupted handshake packet a few times before timeouting.
This doesn't tell us why, doesn't it? Apparently the serialize method of the class DatagramHeaderFormat wasn't called as it should have been when running Raknet in Unity (iOS). Something else (and I don't know what) was linked in place of this method and was filling the BitStream with a corrupted header.
I am quite sure that the serialize method wasn't called because printf calls from inside weren't displayed in the console.
We renamed DatagramHeaderFormat::serialize into DatagramHeaderFormat::serializeHeader and... voila, it works.
Now I only want to understand what did the compiler (and why).
I'm wondering if someone could point me in the right direction for this problem. A bit of introduction:
In an app we maintan we just rewrote our network layer to remove support for OS 4. We're using the cleaner ConnectionFactory provided in OS 5. Please note the issues we're encountering are device-only, not simulator related.
There are two ways or app has connectivity, a data thread that polls specific urls and stores data, and a "generic web view" (a BrowserField).
So far it seems there's no problems with the data thread connectivity, it properly builds the urls based off transport type and downloads the data correctly. In the BrowserField we have a different problem. There's an OS 6 curve causing problems (no other OS 6 device though) when we open the BrowserField with a URL there's a chance it will show a "Could not select proper transport descriptor" message - the most common culprit is WAP2.
I guess we're a bit baffled that BlackBerry doesn't seem to handle the transport descriptor choosing as well as we had hoped. Does anyone have any recommendations?
Due to its length, I've posted our connection utility class on gist: https://gist.github.com/3490101
The most common connection form, used by the data thread, is the getUrlAsString(String etag) function, which does a GET and caches the response based off the etag/url.
To build URLs for our BrowserField we use the buildURLTransport(String url) function, which gets a connection on the url, determines the transport information, and returns the built URL.
TL;DR: There's an oddity in a BrowserField we can't seem to debug, we'd appreciate a new set of eyes: we think there's something wrong in the above posted gist in the buildURLTransport(String url) function.
Thanks a tonne in advance.
Be careful with your code because getUrlAsString isn't thread safe. I didn't understand why you keep reference to the ConnectionFactory sometimes why you don't for other.
I aslo didn't understand why do you need method buildUrlTransport. Why don't use BrowserFieldConfig together with ConnectionFactory for BrowserField as here.
So I would instantiate one ConnectionFactory, configure it with your specific parameters and use it everywhere. In case of preferences change I would recreate ConnectionFactory and update BrowserFieldConfig. Sure this code should be thread safe.
Also be more consistent - sometimes you use quick connection check, sometimes you don't.
I read some of the similar posts on this site that deal with what seems to be the same issue and the responses didn't really seem to clarify things for me.
My application works fine in the simulator. I believe I'm on Bold 9000 with OS 4.6. The app is signed.
My app makes an HTTP call via 3G to fetch an XML result. type is application/xhtml+xml.
In the device, it gives no error. it makes no visual sign of error. I tell the try catch to print the results to the screen and I get nothing.
HttpConnection was taken right out of the demos and works fine in sim.
Since it gives no error, I begin to reflect back on things I recall reading back when the project began. deviceside=true? Something like that?
My request is simply HttpConnection connection = (HttpConnection)Connector.open(url);
where url is just a standard url, no get vars.
Based on the amount of time I see the connection arrows in the corner of the screen, I assume the app is launching the initial communication to my server, then either getting a bad result, or it gets results and the persistent store is not functioning as expected.
I have no idea where to begin with this. Posting code would be ridiculous since it would be basically my whole app.
I guess my question is if anyone knows of any major differences with device versus simulator that could cause something like http connection or persistent store to fail?
A build setting? An OS restriction? Any standard procedure I may have just not known about that everyone should do before beginning device testing?
Thanks
Just providing the URL will not work. You will have to append some info after the URL to determine the transport method your HTTP connection will use. For instance http://example.com;deviceside=true will use DirectTCP (you might also have to supply APN information but that's saved on the device for my phone). http://example.com;interface=wifi will use wi-fi. On OS 5 there's a ConnectionFactory class that makes this a lot easier. Here's a link that goes into more detail.
This was a tough one for me!
As Jonathan said you have to put some parameters in the url to make it work on the device. You shouldn't do it by hand but use the ConnectionFactory instead.
As you may thing this would just make it work but it doesn't!
The real problem is that not the url has been altered because it has ;interface=wifi;deviceside=true in it (in my case). Depending on the webserver accepting your request this could broke the code.
A solution I tried and that works is try to happend a fake parameter like
&foo=true -> &foo=true;deviceside=true
This will result as a standard parameter for the webserver but your device would use it to driver your connection.
On the simulator this work without this extra code because behind it there is a BIS server for you. On the device (as in my case) there isn't because I'm using a development device unregistered and without SIM (just wifi).
Another point is that the HttpConnection class doesn't handle HTTP 302 Redirect and if you get one you have to handle it manually.
It's probably an issue with the APN not being specified. See my answer for this question for details:
video streaming over http in blackberry
I would make this a comment, but I think I don't have enough rep yet for that... So I'll just answer and hope this doesn't get hosed for just pasting in some links.
I've been working on this exact sort of networking issue on our app this past week, and it is indeed tricky as some others have pointed out. Here are two links which really helped us out using HTTP on different devices, especially older devices which do not provide ConnectionFactory.
http://supportforums.blackberry.com/t5/Java-Development/Connecting-your-BlackBerry-http-and-socket-connections-to-the/td-p/206242
The first one has some code examples, including demonstration of querying the system's ServiceBook and CoverageInfo classes to make a decision about what kind of connection will work.
I have a simple application, which should send a single byte to a serial port once a minute. But sometimes, from some strange reason, it freezes somewhere in the WriteFile() function. Both sw and hw flow controls are turned off. I've googled some stuff about pending read operations performed from another threads, but I believe this is not a problem, because my app has single thread. Also, handle from CreateFile looks valid, so the port should not be used by any other applications. Have anybody suffered this?
If you google for the words writefile hangs, you'll find a number of discussions on this problem. Some leads are buffer overruns, sizing your buffer correctly, a defective COM port, clearing the status on error... Seems like there are plenty of things to try.
Another thing I would suggest is to use a communications library instead of calling the API directly, something like Async Professional (http://sourceforge.net/projects/tpapro/). Even if they add some overhead to your application, they might simplify your work and avoid a number of potential pitfalls...
Well, I'm using this library: http://lhdelphi.ic.cz/uploader/storage/ComDrv32.pas in Delphi 7, on Windows XP, but the component inside is just a wrapper around some Win API calls, CreateFile, WriteFile, etc.
Have you tried setting CommPortDriver.CheckLineStatus to true ("to prevent hangs when not device connected or device is OFF")? The source for the comdrv32.pas library contains that suggestion.
You can also try ComPort, which was neglected for some time but is now actively developed again.