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.
Related
I am looking for a solution on how to setup the Windows CE 6.0 design image to integrate my custom application.
I want after building the image and starting it on the target machine to be able
to access my application from the \Hard Disk\Program Files\CustomApp folder.
In addition I require the application to be persistent. It must not be lost after reboot.
I am aware of copying the application to the Hard Disk out of the NK.BIN but if is possible I want a solution like adding dlls or other files to Windows folder.
I am usign an SQL CE database along with the application so I want the data to be persistent too.
Thanks in advance.
If the \Hard Disk folder contents are not persistent (and I assume they aren't since you're asking this questions), then getting the app to "persist" can be done only as a slight-of-hand trick, just like the contents of the Windows Folder. At boot, the OS will get expanded into RAM, and if you've included your app in that OS, it will get extracted too.
First, you must include your app files (exe, dlls, all dependencies, etc) into the OS image by adding them to a BIB file.
Next, you must understand that all files get extracted to the \Windows folder. There are no exceptions. If you want it in a different folder, you must use a DAT file to tell the OS where to put it one the OS has been extracted. Be aware that the DAT file does a copy, not a move, so if you want it elsewhere, you'll have two copies of the app on the device. A typical solution is to use the DAT file to place a shortcut, not a full copy.
The last part of your question is the hard, or maybe impossible, part. Your database is not going to persist. You could include a copy in the OS, but every time you hard reset, a new copy of the database as it was when the OS was built will get copied out. No new data will survive.
To get that to work, you need a persistent file store on the device. If you're the OEM, you might be able to implement one with any remaining on-board storage (where the OS image file resides) or with separate mounted USB/CF/SD/HDD media. How you do this is highly hardware and BSP dependent, plus it's way more complex than can be described here on SO.Without knowing anything about the target device, it difficult to even give you any pointer on where to begin. Here's a very generic starting point for Flash storage.
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.
Sometimes when we issue an upgrade to our application we need to install some files to the application's Data folder. We want to make it possible for the users to move this folder to a place of their liking. But how to deal with this at install time?
I was thinking of deploying to the user's AppData folder and have the application somehow check there for new files at startup.
Any advice or references would be very welcome!
We use InnoSetup for a VB6 application if that matters for your answer.
Generally the best solution I've found is to allow the user to move the folder from within the application.
This allows the application to keep track of where its data is being kept (by adding a reference to it in a file or registry entry which it accesses at load time) and to access it seamlessly in the future.
Your update routines can then also access this information to determine where to place the update files.
Alternatively, make sure the folder name is as distinctive as possible and add a search routine to look for the directory in a number of sensible places at load time. Then write your manual specifying that the data folder can be moved to one of those locations ONLY.
Wouldn't the users just run an update or patch package? I'm not sure why they'd want or need to see such files. It's pretty rare for commercial software to offer users the options of where to store program settings and other internal-use files.
Give some thought to this before putting a lot of stuff into users' roaming profiles. You might want LocalAppData instead.
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.
I am developing for the iPhone and the prevailing advice on auto-generating files from entities, when using Core Data, is to select the *.xcdatamodel file and the create the new file(s) etc. This creates the *.m and *.h files in the Resources directory. These are then moved to the Classes directory or a subdirectory of Classes.
However, when viewing my github repository I notice that all of the model files which have been auto-generated in the above mentioned way are present on the root of the project folder (as if they were a resource).
The underlying file structure may or may not matter (I'm unsure on this point) but I would like to make my repository less disorganised. I can see entropy taking over as the project gets much bigger and there are more files to contend with.
My question is therefore: is there a way to organise the underlying file structure without messing up the project settings or the way github sees the project?
I hope the above isn't unclear and I look forward to your replies.
Yes, this is possible. The Xcode groups (the yellow "folders," like your Resources) are completely independent of the file system - they don't directly represent directories. If you select a group and go to File -> Get Info, you can select the base path for that group of files. You can create and select a new folder through the file chooser there.
Once you do this, all the files in that group will go red - Xcode can no longer find them through the new path. Use the Finder (or Git) to move them into your new directory, and all should be well.
Xcode defaults to placing new Managed Object classes in the folder that the model is in, so new resources will get placed there automatically.
As a sidenote, I highly recommend Rentzsch's Mogenerator to handle Managed Object class creation. It divorces Xcode's auto-generated code from your custom code, and then automagically regenerates the template code every time your model changes (without losing your own code).