koobas.hobune.stream
Do I need an Android Equivalent to DirectoryInfo.GetFiles()?
I have a custom save/load interface for my game. I serialize all my data into .dat files and deserialize them when I load the data.
I'm using this code to get the directory information where all my save games are being stored:
enter code here //This function gets a list of all the files
public FileInfo[] GetDirectoryList()
{
string path = Application.persistentDataPath + savePath;
DirectoryInfo info = new DirectoryInfo(path);
FileInfo[] fileInfo = info.GetFiles();
return fileInfo;
}
It works perfectly on PC, but on Android it does not return anything. Nothing displays. When I use Astro File Viewer (external file browser) I can see that the save files are being placed where they should be. Is there a different method I should be using for Android? Why is this code not returning anything?
Also, to be clear, I have enabled "Write Access: External SD Card" in the Player Settings.
Just wondering, why not use PlayerPrefs ins$$anonymous$$d for saving/loading? It will automatically sets the file depending on the platform the game is run on.
I have large lists of data that need to be kept track of (hundreds of variables). $$anonymous$$anually setting a player pref for each one would be too time consu$$anonymous$$g. Additionally, this generates a single file which can be transferred from machine to machine, which is ideal for my needs
Additionally, my method allows a player to easily store multiple save profiles.
After a comically lengthy amount of time, I discovered the problem. This was one of those bugs that makes you pull your hair out, just to find out that you forgot a semicolon somewhere.
The solution was this: I used a "\" in my pathing. Switching it to "/" solved it. I don't know why.
My final path now looks like this: Application.persistentDataPath + "/" + filename;
While this issue is now solved, I would appreciate anyone who can explain this to me.
Hrm, use Path.Combine(System.IO namespace) for stuff like that, it will put the directory separator in there for you.
If things are correct, then the Path.DirectorySeparatorChar that is used should ("SHOULD") resolve correct between windows('\') and un*x like systems('/')
Windows is the only OS that uses "\" ...everything else uses "/". Except you can just go ahead and always use "/" for the sake of consistency, including Windows builds, and it will work. Technically you can use "\" on Windows, but it can potentially lead to problems like this if you accidentally used it on other systems, so it's safer to always use "/".
