this is most probably not really android related, but in my game users can download content via akamai cdn. this works nicely except for jpeg files which for some users are delivered with a different compression. this is somehow depending on the device / android build version / provider / location (and therefore actual akamai node).
since i do a hash check after download to check if the file was delivered properly i get a different hash for a manipulated jpeg file and detect an error.
i already changed the download process so that all files are named
filename_ext.bin
so that the mime type would be application/octet-stream instead of mage/jpeg, but still it seams that some node in the middle ( a proxy maybe? ) checks for the file content and recompresses the jpeg (to save 10-20% of jpeg size; after all, cpu power is cheap, bandwith is expensive).
does anyone have any experience with this kind of problem?
maybe a solution would be to zip every file and unzip on the device ( hoping that whatever is altering the file does not unzip / change jpeg / zip again).
thanks in advance.
ok, just got answer from akamai support:
"some providers have transparent proxies installed that dynamically re-compress image graphics (jpg and gif) - they also modify HTML pages. Images are recognized based on their file signature and not based on file extension."
so I actually have to encrypt / zip the files to circumvent that...
also:
http header
Cache-Control no-transform
also did the trick.
Related
I am developing an Android app in Java using OSMDroid to deliver offline maps in Mapnik tile format in a .zip file.
My question is about how to deliver these maps to users who download the app from the Play Store.
I don't know the exact size of my finished tileset but it will be a .zip file of about 100MB.
In protyping I am including a smaller tileset in my project's /assets folder, and on first run copying it to the user's external storage directory using the getExternalStoragePublicDirectory(Environment.MEDIA_SHARED) folder and replacing /shared with /osmdroid (on my phone it is /storage/emulated/0/osmdroid) and creating the directory if necessary. It's a bit of a hack but it works.
The problems with this are that the tileset (about 100MB) remains attached to the application while a copy is created in external storage. Which is kinda wasteful of space. I may also encounter problems with the APK being too big.
I thought of allowing the user to download the .zip file from an FTP server after they're finished installing the app (prompting them that it's a biggish download and to use WiFi if possible). I haven't looked at the technicalities in detail but this strikes me as being fairly straightforward to implement. However, I can't find any descriptions of people using this method.
So, my questions are:
Is there a standard or recommended way of delivering Mapnik tiles to users in live for offline use?
If so, what is it? (preferably with links to examples if possible)
Thank you to everybody in advance for your help!
In the end I downloaded the zip from an FTP server. This has been tested with a group of test users in a real-life environment and it seems to work well.
The zip file is downloaded to the directory returned by the method getExternalFilesDir. This returns the app's data storage directory which gives the advantage over a hard-coded path that when the app is uninstalled the zip files are also deleted.
We are developing a PhoneGap application (iOS & Android). That needs to store some data in mobile database(SQLite) and some PDF/JPG files File system to make application working in offline mode.
We will download this data once the application has been installed. My question is, Which format we should use to store the PDF/JPG files in filesystem ? It is in Zip format? Any other compression ? Or No compression ?
Which one is recommended?
Do not use any compression, save the files as they are in file system. Make sure you have appropriate file size ready before download(for eg: 100kb png images is enough for mobile). Make sure you keep your data safe here is a good link how to here
I am trying to transfer files from my android emulator to my server. I observed that files of size around 2MB or greater are just not getting transferred.
Is it because of the internal memory I've provided to the emulator. If it is, should I change the way I'm transferring the file? My transfer method is similar to the only here: Android:How to upload .mp3 file to http server?
Yes, I found the answer. I had to make a change in the PHP ini file and increase the limit to my desired size :)
So there is nothing wrong with the emulator as such, it was a problem at my webserver end.
I created a rudimentary browser with help of a WebView.
When I visit a website (containing some text and a few images), the cache directory in /data/data/com.mayexample/cache/webViewCacheChromium gets filled with a few files called index, data_0, data_1, data_2, f_00001, f_00002 etc.
I was wondering, what's the format of these files, what do they contain? I thought about "so, a few of these files surely have to be the website's images then" and tried opening them in a file manager (open as image). But whatever file I pick, the process says "Failed loading!". Even if I rename some of them to .jpg, still I can't open anything.
I have read on the internet that this worked for some people though (look at Android WebView - Load Images from cache, it's exactly what I want to do), but I can't do anything with the cache's files.
Do you know a way to open webview cache files? Doesn't one file represent a corresponding cached image for example?
What I really want to achieve (once I understand the structure of the cache files) is to programmatically fetch images of the webview from it's cache, like the author of the link posted above (unfortunately this posting's answers don't help much)
Thanks!
The cached files might be one of the CSS, or JS/image/html types. On earlier Android releases, one cached file maps exactly one CSS or JS/image/html file.
As far as I know the Browser engine (actually the HTTP module) maintains such cached files in a URL-to-HashKey manner. So what you found (such as "4f42185de3a3a461_1") may be associated with any web resource files such as JS/CSS/images/HTML, etc.
I remember WebView used to store such URL-to-HashKey mapping data in sqlite3 tables in earlier Android versions.
The problem here is you have no idea about the mapping relations so you can hardly retrieve the file you want. A tricky way is to read the AOSP source code then you may be able to know how the generate the HashKey by an unique URL, or you can manipulate the sqlite3 tables, if there are still any on Android 4.4.
I was able to view files in the webViewCacheChromium folder using this tool designed for the Chrome desktop browser:
http://www.nirsoft.net/utils/chrome_cache_view.html
The contents are basically what you'd expect for web cache - images, javascript, css, html.
I'm currently working on an app which downloads a zip file and extracts a bunch of tiny mp3 files into external storage. The zip file is about 2.5 meg.
I'm wondering if it would be a better idea to include the zip file in app resources, and then copy and extract it to the file system. This would prevent the headaches involved in something like a lost connection during the zip file download. I noticed some missing mp3s, and when I checked the zip file, the last 20 or so weren't it it. So, it looks like the system can successfully (an unfortunately) extract from an incomplete zip file.
The downside including the zip file in app resources is obviously that it increases the size of the app by 2.5 meg. I've specified "prefer external storage" in the manifest. This isn't supported before release 2.2, i.e. level 8, so I'm already excluding those phones, which probably is 20 or 30 percent of the total android phones. But I'm not entirely sure if that guarantees the app will be installed on the SD card.
It could be worth including the zip file in the app just to avoid the potential hassles in handling the download of the zip file; but if the size of the app makes it unappealing, then that's kind of a drawback - especially if the "prefer external" doesn't work on some devices.
Which is the better option? Ideas are welcome.
One of the highest selling Android Games, Gun Bros, does what you are thinking about: small app, that downloads the content on demand. This allows them to also serve ads while the content is downloading. In addition, by downloading the content you can make use of compression over the network thus reducing the total amount of data a user will actually have to use to get the whole application. I think in the end it is a personal preference, but I would lean towards downloading over the network.
Given the fact that there are some apps/games out in Android market which are in the 40+ MB range a 2 MB additional download doesn't seem that much to me. Anyway your users have to download it one way or another. Either in the apk or as a separate zip file.
Now Android market allows you to post updates to your application so your users can get new content through there.
Regarding prefer external storage, it is just that - a preference. If external storage is not available or a user is installing it on a 2.1 phone, then it will install the application to internal storage, as long as your applications minimum SDK level is 7 or lower.
But there are other applications I can think off that download content from sites, things like scripting for android (SL4A). If you want to update your game content that way, I would recommend creating a mechanism whereby your application can first discover the size of the download, then do the download. And once the download completes, verify the size against the size it should be. If the two don't match, then run the download again or something like that.
I'd recommend just including it in the apk file. Many apps on the market are like 5-10 MB, and games can be even bigger (I've seen games range anywhere from 1 MB to 40 MB), so adding 2,5 MB to your app shouldn't really be a problem, even if they don't support installing to sd-cards.
My phone for example have 2.1 and therefor can't install to the sd-card and I've so far never run out of space even after installing a bunch of 2-5 MB apps.
And no "prefer external storage" does not guarantee that it's installed on the sd-card, if the user doesn't have an sd-card for example, or if they choose themselves to move it to the internal storage.
Point is, adding 2,5 MB to your apk isn't anything anyone will really notice or care about, and you shouldn't need to either.