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.
Related
I have 9000 files in the memory card, I have created an application that read each file and parse it in to a String and put that String in a HashMap in order to avoid repetition,and save the names of only unrepeated files, but that operation is taking about 7 to 10 seconds.. is there any way to make that faster.. I tried to find better method but I didn't find anything...
Object : get the names and Strings of all the unrepeated files..
Is there any way to do that faster using java, new IO, or NDK, is it worth to install NDK and try that using C language and pointers..
I appreciate any help..
Its obviously that even just loading of 9k files takes some time. Imagine there a lot of android devices and there are many devices which are not as fast as device which you are using to test. So the operation gonna take even more time on such devices. The problem is a numerous of small files. Maybe you should pack it in one, lets say a JSON or XML? Reading of 1 file is more faster and reliable.
I am working on an app and one of the features I am working on is to download some binary files. Some of them are really big (more than several mega-bytes). Downloads are completing fine as long as the file size is less than 2 GB.
I got stuck on a file that is 3.2GB in that I get progress updates (I am pooling the DownloadManager for progress updates), but when the download completes, the file is not present on the target file path. Interrogating the DownloadManager for that download id, I get STATUS_FAILED and reason ERROR_UNKNOWN - the favorite error details one will ever wish for!
What is weird is that this appears on most of the devices, but for some (like Samsung SG 4 Active OS 4.2.2 and LG Nexus 5 OS 4.4.2), it doesn't appear.
Doing some extra investigation, I found out that this seems to be a bug in Android DownloadManager implementation. It seems Android implementation stores the download count as an int, but when that count goes above Integer.MAX_VALUE the download ends as failed.
I am thinking to replace the DownloadManager usage with a foreground service, but I wouldn't give up yet ....
Did you guys face this and if so, how did you fix it?
Is there any work-around to use DownloadManager in pre-4.2.2 so I can download more than 2.1 GB per file?
To download such a large files, you need to download those in chunks. Either you can use any library that support HTTP range options to allow to pull down a single file in multiple pieces , supporting resume etc.
Or you can split your large file on your server then have a text file with MD5 hash of each file, when you first start to download then get the MD5 file once finish then check that hashes matches the downloaded pieces. If they do not then delete that piece and add it to queue of items to download.
Once all pieces downloaded and MD5 works, you can put the pieces back together as single file.
If you are thinking to download the file in the SD card then FAT32 is the default file system. There is a 4 GB per file limit with this file system.
From looking at the Android source code, it appears that this issue was resolved in JB-MR2.
It seems that the only way to work around this on older platform versions would be to modify the server such that it uses chunked transfer encoding[1] for these large resources. In that case, that Download Manager will ignore and not attempt to parse the Content-Length header.
[1] http://en.wikipedia.org/wiki/Chunked_transfer_encoding
There is one clear outcome of this:
You can not fix the DownloadManager. If it's a bug in it, it will be so. Therefore, in short, No, you can not workaround this issue using the DownloadManager. You could however workaround it using a server side approach that has been put into words in the other answers.
So, I think your simplest solution would be to force the minimum sdk level to JB-MR2 because #ksasq mentioned that this issue has been resolved.
If that is not plausible nor in your case possible, you can find the best file download library out there and create an interface similar to DownloadManager's for this library. Of course, this interface should be implemented to use the default DownloadManager for versions which do not have this bug and use the custom library for those which had this bug (and for files who cause the issue if possible).
Unfortunately, a search on google showed yingyixu's android-download-manager last updated in 2012.
Another unfortunate note about this topic by CommonsWare simply verifies that there is no DownloadManager in google's support libraries. Worse is that the guy gave up the idea of implementing his own port becuase it was way too complicated. You can only hope that yingyixu's library or some other library you hopefully find is good enough.
You can pass this issue by splitting file into smaller zip files. Next step is to join them on target, I've found ->this<- that might help you. If you will not compress file (split only option) you should have good performance. Other issue is that you will need twice as much storage space. You can download smaller files, about 100MB, write it to joined buffer and remove form file-system, that will preserve space wasting.
You could also take the fixed version of DownloadManager, change the package to your package structure and use this version instead of the system version. Eventually you need to import some classes from the original package android.app. Then register your implementation as a service.
I need to implement a count down timer which countdowns from a specific date, after some research I understand that calendar class isnt the best at handling all this so I should use joda time. However I need this only once in my whole application, so I am concerned that it will be taking too much space in my app when I dont really need it.
So my question is, how much will the size of my application increase if I add joda time library to app.
The actual size of the jar is much smaller than the zip file. I just downloaded the zip file and the current jar that gets distributed (joda-time-2.3.jar) is only 568KB.
The ZIP with sources is about 4.1MB large.
this zip contains the jar which is about 568kB
Information taken from here:
http://sourceforge.net/projects/joda-time/files/joda-time/
I have couple of initialization classes that do nothing else but to fill initial unchanged data structures. In total about 200k lines in 5 data Classes just doing things like:
x = new Y(13);
xTmp.z.add(x);
allElements.add("just some text");
So basically initializing arrays of my structures - these are all basically "constants".
I was wondering how to best structure the project, for example using libraries or doing anything else so the development of the project can be handled more efficiently than to always compile, link and load the large data classes to the device for testing.
Forunately Eclipse is real fast and compiling takes not more than 1 minute (compared to xCode where it takes over 1,5 hours to compile). However, I am sure the experts with experience of writing large projects have thir tips and tricks how to best get their hands around it.
Many thanks!
I wouldn't hard code all that data at all.
Define a file format for all that data, and build a simple parser for it (or better yet, use an existing structured file format and drive from that). There is no reason to have to rebuild your code when you change the initial data.
Bundle those initialization files with your application (you can even put the inside your jar files and access them as resources).
I'm writing a purge function for our software that removes all image files that haven't been used in over a month. To do this, I am checking two things:
the last-modified date of the file
a query on a database that shows recently viewed files.
The query is much slower than the file check. So I would ideally like to be able to reset the last modified date on any files that fail the first check, but pass the second, so that (for example) a list of venerable but often-used files aren't gradually increasing the processing load of the management system.
Is there a way to do this without recourse to something crude (and possibly even slower), like renaming each file to a temporary label, then itself?
As Nik said the setLastModified() method on the File class may not always work depending where you are in the Android file system. If on the SD Card then some devices will return false from that call and thus not change the date.
There are more details about it here:
http://code.google.com/p/android/issues/detail?id=1992
http://code.google.com/p/android/issues/detail?id=1699
Plus some other stackoverflow thread here:
file.lastModified() is never what was set with file.setLastModified()
setLastModified() is a standard method on any Java File object that you can use to update this value.
SDK Documentation.