B4J Question Zipping - advice sought

[JackKirk]

I need to be able to zip a large number of .jpg and .mp4 files using B4J.

Trolling the forums didn't seem to provide what I would consider "solid" solutions.

Any advice would be appreciated.

Thanks...

 

[stevel05]

Erel provided a method that I still use and don't have any problems with. You can see it in this thread

I also worked out a way to check if the JDK was installed / available, again this is still working with Java14. See it in this thread.

Strangely I was modding that old app today.

 

[emexes]

I need to be able to zip a large number of .jpg and .mp4 files using B4J.

For what purpose?

To use in a B4X app? doesn't have to be same app as did the compressing
in which case, try the archiver library https://www.b4x.com/android/forum/threads/lib-archiver.21688/ or similar
I usually use CompressedStreams which is bundled with the RandomAccessFile library, but it only does one file at a time, ie doesn't bundle multiple files into one compressed archive (but having said that, because it's a stream, it's easy enough to do that yourself into a simple handcoded format if you really need it)
https://www.b4x.com/b4j/help/jrandomaccessfile.html#compressedstreams

Or to use in other programs, eg Windows File Explorer?
in which case, use 7-Zip (or even Windows File Explorer?)
both can produce 64-bit Zip files (not sure if they can produce the older format Zip files, which have a 2GB file size limit)
if you the compression has to be done within B4X app, then try the archiver library mentioned above

Also, are you intending to have multiple images inside one compressed file, or to do the each-in-its-own .gz style?

In fact, now I'm thinking: are you doing this just to organise multiple files into one? Because JPEG and MP* files (and GIF and PNG files) are already pretty tight, and general compression algorithms don't usually have much effect on them. If you're looking to save space, then the usual route is to decrease the resolution and quality settings of the codec used to produce the files in the previous step.

 

[emexes]

general compression algorithms don't usually have much effect on them

I just zipped up the 395 random JPEG files that were sitting in my download folder, and they compressed down by 10.6%
from 114,400,047 bytes to 102,323,329 bytes, according to the archive listing
using maximum (aka slowest) compression setting
the archive overhead is another 80 kB ie ~500 bytes per file; the actual .zip file is 102,403,381 bytes

 

[emexes]

Just brainstorming here...

If the images are all small and regularly-sized eg icons, thumbnails, sprite animation frames, then another approach is to combine them all as grid of images in a single JPEG file, and then cut them out as required in your B4X program. Although probably best to keep the single combined JPEG size down to that of a typical camera photo eg perhaps 6 MP which would be about 6000 icons.

Another idea would be to use B4J to add all the images and video to a SQLite file as BLOBs, and then make that SQLite downloadable from the internet. First time your appis run, it downloads that database file and then extracts the images and video as needed.

You could include a bare-bones database file in your app's distribution eg APK, so that your app is still usable in a bare-bones demo mode even before the full database is downloaded.

 

[JackKirk]

For what purpose?

emerexs thanks for your interest.

I need to be able to send 40-100 jpgs + 5-10 mp4s in a single file to recipients - who assume responsibility for unzipping etc their end

They will receive an email with a URL which lets them do the download.

In fact, now I'm thinking: are you doing this just to organise multiple files into one? Because JPEG and MP* files (and GIF and PNG files) are already pretty tight, and general compression algorithms don't usually have much effect on them. If you're looking to save space, then the usual route is to decrease the resolution and quality settings of the codec used to produce the files in the previous step.

I am well aware of the compressed nature of jpgs and mp4s - been working with them for yonks.

I am really only interested in the packaging aspect.

In the meantime I have come across ArchiverPlusZip - a component in Informatix's ProBundle - which I have. This is intended for B4A but supposedly works in B4J (just copy the relevant jar and xml from the B4A additional libraries folder to the B4J equivalent).

This 2022 post:

https://www.b4x.com/android/forum/threads/zipping-a-folder.140564/#post-890372

suggests it still works - I will give it a go in 1-2 weeks time.

Anyone have any recent experience with it (in B4J)?

 

[emexes]

who assume responsibility for unzipping etc their end

In that case, PKZIP format that works with Windows ZipFolders.

Easiest and most compatible to create the Zips with Windows File Explorer directly: select files, right-click, Send to, Compressed (zipped) folder)

or use 7-Zip (has a command line version that accepts file lists)

or is there some reason that the compressed file has to be created by the B4X program?

I am really only interested in the packaging aspect.

In that case, if other solutions don't pan out, then the PKZIP format looks simple enough that a non-compressing version of it could be written in an afternoon in B4X, which'd then work in B4I and even B4R too. Hardest bit would be the CRC but it wouldn't surprise me if most decoders would just issue a warning but still give you the file. I had a compatible CRC routine in PowerBASIC 10 years ago (3 laptops) ago but can't lay me hands on the source code. TBH I think there was some inline assembly involved.

The structure of a PKZip file

Extraction by a B4X program just becomes a RandomAccessFile ReadBytes (ok... first you have to find the file header, but that's just a sequential search).

 

[emexes]

relevant jar

There is a Java SDK here, but I think it is only for the compression operation, not the packaging multiple files into one operation.

Again, to make it easier for your users doing the unpackaging, Zip files compatible with Windows Zip Folders would be the go. Same as used by JAR, APK, DOCX, ODT.