a-ha! context :) for the record, I have used SharpZipLib to decompress 200-500Mb *downloads* (post-install), which makes a lot of sense for certain applications (say, a magazine reader).
I don't think you are getting much value from ZIPping something you ship in the IPA. As previously mentioned, the IPA's contents will be unpacked into the app home directory on the device: so if you've compressed it, uses 200Mb (but you need to unzip) and if you don't it's obviously taking up the full 700Mb - PLUS another 700mb when you've decompressed it into a read/write file location. The problem of 3 mins to unzip seems to override any other consideration tho' - if your app doesn't start-up and be usable quickly, the app's size doesn't really matter so much? So i'd definitely consider just bundling the full-size file... anyway, your call :-) Now, regardless of what you decide there, you also need to know this: do NOT put the 700Mb sqlite file in /Documents/ as Apple will reject your app within seconds of it hitting the approval process! How do I know this? I followed exactly the same pattern (copy out a pre-built file from the bundle into /Documents/ - and it was only 2.3Mb!!). Also - there is that plist property that lets users access /Documents/ from within iTunes... you may not have it enabled *now*, but if you wanted to in a future version of your app, you'll be 'screwed' if your main database is located there too... Why does it get rejected immediately? It violates the *iOS Data Storage Guidelines* https://developer.apple.com/icloud/documentation/data-storage/ Point #1 - your data is "not" user-generated, and it "can" be re-created from the bundle. You might then continue reading Point #2, and think you should put your sqlite file in <Application_Home>/Library/Caches/ BUT there is a process called 'Cleaning <http://www.marco.org/2011/10/13/ios5-caches-cleaning>' whereby iOS will (under extremely low storage situations) delete the contents of /Caches/ without asking! The solution I've gone for (and which I think is what Apple approves of) is storing the file in <Application_Home>/Library/ (or in a subfolder that you create there, but NOT /Caches/) AND following Point #4 whereby you mark the file with SetSkipBackupAttribute(). So what does this mean? Your 700Mb file is safe from being deleted, is in a location that will never be exposed to the user, and is read-write. Good, right? HOWEVER it also won't be backed-up (not to an iTunes PC nor to iCloud). That's fine - unless your user deletes and restores your app, or buys a new device and does a backup/restore to move everything from the old hardware to the new... your app (with prefs and whatever was in /Documents/) will be copied across - but your 700Mb read-write sqlite database won't be! In your FinishedLaunching you are probably doing a 'check' to see if the database has already been moved (and moving/uncompressing if required) - the trick is to decouple this from any data that _is_ backed-up (so don't store a flag in userprefs, or in a file) -- because the flag that says 'sqlite file is loaded' would be backed-up and restored, but the file itself wouldn't be (ugh, confusing eh? i'm only explaining all this 'cause i made the mistake myself, thinking a boolean prefs-check was faster than a System.IO.File.Exists). I think the physical file-exists check is safest (open to other suggestions tho). if it doesn't exist, unpack from the bundle all-over-again... also, don't store any user-generated data in that same 700Mb sqlite. Any user-entered data should be in a separate sqlite that DOES get backed-up (too bad about FK dependencies) unless you want to get into an approval-argument with Apple... clear as mud? hope it makes some sense... after two rejections my app did finally get approved with SetSkipBackupAttribute used. but if Apple was concerned about my 2.3Mb file, they're sure to raise an eyebrow at 700Mb! let me know if you have questions/need clarification ;-) HTH cd On Fri, Apr 13, 2012 at 6:10 PM, johnHolmes <[email protected]>wrote: > > Nic Wise wrote > > > > > > Keep in mind that the file that is downloaded to the users device - > > .ipa - is a ZIP file already, so you will not benefit from double > > compression. If you need to keep them all together,then try using > > store, see what the size of the resulting .ipa is, and the speed > > difference. > > > > > > Good point. I'll try to explain why I need to compress the file prior to > the > .ipa. > > The file is a sqlite db. It's uncompressed size is ~700mb. I need > read/write > permission on that file. If I'm not wrong, all "content" file stored in the > bundle is read only, so i need, once the application is installed, to copy > the original db to a writable folder. A good candidate seems to be the > /Document folder. At this point the user will have 2 copy of the file, one > compressed and one uncompressed, readable and writable, in the /Document > folder. I know it's not good to have rendundant 200mb of data but I haven't > found any alternative to this. > > Any suggestion? > > -- > View this message in context: > http://monotouch.2284126.n4.nabble.com/SharpZipLib-performances-tp4553235p4554119.html > Sent from the MonoTouch mailing list archive at Nabble.com. > _______________________________________________ > MonoTouch mailing list > [email protected] > http://lists.ximian.com/mailman/listinfo/monotouch > >
_______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
