I made an Android Applicatiob to upload videos to my server, it's working fine but if the file bigger than 21MB it's forced close.
so i think it's a memory issue, i tried to use setFixedLengthStreamingMode method
conn.setFixedLengthStreamingMode((int) new File(existingFileName).length());
but it's not working at all with the small & big files.
I passed the value to the Log to make sure it the file size in bytes and that is correct but the method not working
I tried to convert the connection to chunk mode by using this line
conn.setChunkedStreamingMode(100);
but also this line makes the Application fails
so I don't know what to do
Probably you are loading entire file into memory. This link may be helpful to cater your problem https://stackoverflow.com/a/9630475/830945
Related
I am using docx4j library to create/open/edit docx file. But it takes around 30 seconds to initialize this line
wordMLPackage = (WordprocessingMLPackage)loader.get(file);
It takes same time either it simple document(may be empty or single word/line file) or complex document with images and tables.
I have increased memory for eclipse in eclipse.ini and VMHeap for emulator but no effect .It is slow on emulator as well as on real device. Please help!
See forum post wordprocessingmlpackage-load-file-is-extremely-slow
The JAXB context init time is unavoidable (unless you remove some of the packages listed, or hack your JAXB implementation to do some funky on demand type loading), but only needs to be done once.
I am developing android phonegap application. which has around 65 images (~10kb size for each). My application is working as expected on Ripple chrome plugin as well as on Chrome and FF browser. but when I load it on emulator some images are not able to load.
I have attached screenshot for the reference.
I tried using the jQuery preload plugin but no luck.
Can anyone help me please! Thanks
EDIT:
I have tried the same code without any change on iPhone and WindowsPhone7, Images are showing up fine on both the platform.
Try creating an identical copy of the image (../image_copy1.png, for example), and swap that code out in lieu of the image location that isn't working.
Sometimes emulator programs freak out with file paths either due to localized caching of data or actual logistical errors in the emulator program itself. Dreamweaver has similar problems, as do a host of other dev/testing suites - local caching of images is not an uncommon problem. You can circumvent this issue sometimes by uploading a copy of the desired file (but not copying it within the program itself) - causing a fresh, noncached upload of it. This is by no means a "proper" solution, but it's a quick and dirty workaround for a buggy emu/dev program.
If you are loading the images from an external source, you may need to 'whitelist' the source. Did you add the domain name into the Cordova config file? It is under res/xml/config.xml
<access origin="www.example.com" />
I know that it is necessary for cross domain AJAX requests but not sure for images, you could give it a try.
Can't help much.
Emulator acts cranky some times.
I have faced the issue multiple times.
At the best, you can try creating another avd-image... but at least I cannot guaranttee that it will work.
I'm parsing large XML files (~1-2M) in my application. Occasionally parser fails
when parsing some files.
Symptoms:
Sometimes the same file is parsed successfully, sometimes - not.
If parsing of a file fails it will take some time before the file can be parsed
successfully again.
I use 2 types of XML parsers: SAX (XMLReader) and Pull (XMLPullParser),
both of them fail near the same place in the file.
I use FileInputStream as the input source for parsers.
The same file compressed via zip and then opened via ZipFile.getInputStream
(almost) always parsed successfully.
I tryed to wrap FileInputStream with BufferedInputStream - nothing changed.
If parsing fails the next attempts to parse the file fail in the same place in the file.
I believe there can be two causes:
FileInputStream works incorrectly.
XML parsers work incorrectly with FileInputStream's (I heard both parsers
implemented on the same base in Android).
Please help to fix the problem or advise a workaround.
Thanks.
This is the case if you experience the problem only sometimes. If the problem occurs each time you run the application the problem could be with XML.
In my case I believe it is device (I have Samsung I5700) or sdcard issue, because none of my application's users report same problem.
I'm going to reformat sdcard with android or try/buy another one.
I'm working on an archiving mechanism of my application's log files and would like some advice.
What I want to do: When receiving a LogEntry, the LogListenerService will save it in a buffer and at some point it will print all the log entries in a file. When the file reaches a certain size an archiving service is called that will zip the contents of the log files and clean it.
I've implemented most of the functionality but have some questions:
How do I go about defining the ideal size of the buffer?
How do I make sure the log file size is kept under a given "maximum size"?
Thanks
Answering my own question.. :)
Depends on the application but the maximum memory an application can use is 16MB.
Simply by adding a check before writing to the file (I was hoping for a cleverer way)
Have you considered e.g. DroidDrop instead of rolling your own? (Caveat: haven't tested it myself yet.)
I want to load a single XML file of 1.2Mb in android through assets folder as raw file. I heard that there is a limitation in android of 1Mb for a single xml file. How can I get rid of it? Is there any option to overcome this issue?
First, don't use assets/ for XML, if your intention is to use it in your application. Use res/xml/, as parsing will be about ten times faster, and will also take up less space.
Then, I would simply try it with your file and see if it blows up. I know there is a limit, but I do not know what the threshold size is.
If it blows up, you will either need to split it into multiple files (each with a subset of your data), or not package it with the application, instead downloading it from a server on first run of your appl.