iPhone SDK - Adding zipped content in resources and then unzipping into Documents folder - iphone

I have some resources (zipped) that needs to be shipped with my iphone application. When the app launches for the first time, this zipped file needs to be moved/copied to the Documents folder and unzip it there. User can then add more files to this path from the application. Can someone please suggest how can I achieve this?
Thanks!

Based on your comment above:
The reason I want to add a compressed
resource because there are multiple
files. If I don't compress then I'll
need to move files individually. I'll
also need to maintain a list of files
somewhere so that I can read the file
name and then move them. I thought
zipping and unzipping was a simpler
solution.
You could add all the files to a folder in your bundle. When the app launches for the first time use fast enumeration to run through the folder and what ever it finds in that folder, it copies into the Documents folder. Handling folders within folders is slightly more complex (add recursion maybe). This way you don't have to worry about zip or tar, nor to keep a directory of files to install.
Just place the folder of files you want into Xcode's resources folder and tell it to import as a folder not as a group. That way the files get installed in your resources inside a folder instead of just as individual files all over the place.
EDIT:
Better yet, do what I say about putting all the files you want in one folder, add to your project, but not as a "Group", and then at first launch use:
[[NSFileManager defaultManager] copyItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath error:(NSError **)error];
and it will copy your whole directory from one place to another. EASY!

Add the libz.dylib Framework to your project, and include Deusty's NSData gzip category which will give you compression/decompression methods.

While this is available by using the libz.dylib, it really is unnecessary as it save you little (if any) space. You application bundle is already compressed when being transferred to the phone. Compression on top of compression usually yields little additional compression.
Try it out yourself. You may find that shipping your app with unzipped contents may take up just as much space as zipped contents.

Related

Packing and loading asset files (midi) in Unity

I considered if this would be more of a Unity or specific library question, but considering it's tied to the loading of assets, it might come in handy to know of a workaround if there is any.
I'm using the DryWetMidi library with Unity, and have a number of midi files I can load and swap in runtime. DWM loads midi files from a file path, so I just keep them in a folder and build the file path from Application.dataPath + filename before loading. However, when the project is built, the files no longer are at the given path (unless you manually place them there afterwards).
Unity doesn't have a variable type that can store midi files (unless you store it as .bytes file), but even so, DWM needs the filepath to load the midi.
Could there be a way to go around this that I'm not seeing? I've looked at using Resources, but that doesn't really allow me to tie in with the library's loading method. I thought about using resources (or storing the files as byte files) to load the files during runtime, copy and create a temp file to load it with the library, and afterward delete it, but am unsure if that is overkill and there might be a simpler way to do it.
Many thanks!
As said what you want to go with would be the StreamingAssets folder and Application.streamingAssetsPath.
Those assets are either shipped alongside with the build or even packed into the resulting apk (depending on your target platform).
The Application.dataPath you are using is actually just the install folder / project root folder again depending on your target platform and mostly not accessible at all in a build.
Also not to confuse with Application.persistentDataPath which is an external path which allows the application to persistently store and access data. This you would e.g need to use if you want your user to be able to modify and save modified midi files later.

Best way to store large number of files in Swift

I currently have around 4,000 SVG files in the Project directory of my macOS app.
And Fetching them using the line below, and it's working as expected.
Bundle.main.url(forResource: "icon1", withExtension: "svg")
But due to the large number of files I'm having issues such as slow searches in the project directory in XCode.
I'm looking for a better approach to storing these files.
Put them in an asset catalog.
If the only issue is in Xcode, you can also make the directory a folder reference (drag the folder into Xcode and select "folder references" rather than groups. This will keep Xcode from managing the folder directly. It'll treat the entire folder as one "unit."
If the main issue is searches, you can create a scope that excludes your images.

subfolders in iPhone localization folders

I would like to localize some images in my iPhone project. So I created files:
en.lproj/Images/iPad/btn-check-pressed~ipad.png
en.lproj/Images/iPadRetina/btn-check-pressed#2x~ipad.png
ru.lproj/Images/iPad/btn-check-pressed~ipad.png
ru.lproj/Images/iPadRetina/btn-check-pressed#2x~ipad.png
and so on and added them to my project. But Xcode shows "English 0 files localized", "Russian 0 files localized" in Localizations list.
It also shows a warning
Warning: Multiple build commands for output file /Users/User/Library/Developer/Xcode/DerivedData/TestLocalizationDefaultPNG-ckplzmcjurofxrccjuvyzjaqketc/Build/Products/Debug-iphonesimulator/TestLocalizationDefaultPNG.app/btn-check-pressed~ipad.png
for each of my files when I try to build the project. So, as far as I understand, it copies all files in one folder, and since my files have the same names - only one of them can survive. But, if I remove my subfolders:
en.lproj/btn-check-pressed~ipad.png
en.lproj/btn-check-pressed#2x~ipad.png
ru.lproj/btn-check-pressed~ipad.png
ru.lproj/btn-check-pressed#2x~ipad.png
everything works fine.
Is there is a way to keep subfolders? Here http://developer.apple.com/library/ios/#documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html in Listing 2-4 subfolder used for the audio files, so it should be.
It looks like the only way localization works in iOS is different. You base folders hierarchy should be by inverted: first goes actual folders structure and in each and every folder you want to localize, you put corresponding .lproj sub-folder with localized resources. So in your example it should be something like:
/Images
/iPad
/en.lproj
btn-check-pressed~ipad.png
/ru.lproj
btn-check-pressed~ipad.png
/iPadRetina
/en.lproj
btn-check-pressed#2x~ipad.png
/ru.lproj
btn-check-pressed#2x~ipad.png
This might be sub-optimal if you intended to have big hierarchy but this is the only way it works out of the box.
Of course you can always say that you don't need Xcode support and use some custom build rules to re-arrange files in you project in the way you like and then copy them into proper structure during build but I doubt it worths troubles.
Update: it looks like XCode (4.5) build script is the main villain.
According to my experiments build script should flattens resources structure at least for images. So the only way localized app can be inside is:
/YourApp
YouApp
info.plist
....
/en.lproj
btn-check-pressed~ipad.png
btn-check-pressed#2x~ipad.png
/ru.lproj
btn-check-pressed~ipad.png
btn-check-pressed#2x~ipad.png
The trick is that by default XCode (as of version 4.5) can flatten your project structure only if it is as described above and I don't see a standard way to change this behavior.
Of course, original comment about custom build scripts is still true.

how to Uncompress/Extract *.nib files from a compiled iOS app

Is there any way to get uncompressed *.nib files from a *.ipa file which is downloaded from iTunes? I know there are ways to extract the resources (jpg/png/sounds) using File juicer or similar tools. But I'm looking for a tool which can extract the *.nib or *.xib files from an *.ipa file to reuse the nib.
Thanks for any help.
I believe in an older version of Xcode, maybe 3.0 or even before, Interface Builder could read .nib files. These are basically compiled, like source code, and there is no way to decompress them or to see the contents, much like .png images are crushed.
Update
Found a video on Youtube, http://www.youtube.com/watch?v=dInaIlzVsn8, but have not tried it. Claims to be able to open compiled .nib files.
Update 2
Here is another possible way to open a compiled .nib. This process requires you to retrieve a .nib from Hulu Desktop application, which is not compiled, and replace it's contents.
http://www.macstories.net/tutorials/how-to-edit-nib-files-in-snow-leopard/
A bit of a late reply, but could save others the hassle of finding a better solution.
To extract the nib files from the .ipa file:
Rename the MyApp.ipa to MyApp.zip
Extract it
Inside the extracted folder right click the MyApp.app and press "Show package contents"
Here you will have all the resources, including the nib files.
To open the nib files in interface builder convert them into xib files using NibUnlocker from http://www.charlessoft.com

iPhone project - collect files into one place

Sorry if this has been answered before but all my searches do not return anything related to this.
Is there a way to collect all the files referenced in a project and save them in the procject folder automatically? Rather that having links to places where you may accidentally delete the files.
Thanks,
Eds
Xcode doesn't have a particular feature to support this, but when you add items to your Xcode project it does give you the option to copy those items to the project directory. Otherwise you need to manually copy the items to a common location.
What do you mean collect all the files? Do you mean your external files or class files. Your external files like images or audio/video files should be added into Resources directory, it does not matter where is the root directory of these files. Then, you can access with their name in the project.