getWriteablePath Question

I intend to use getWritabePath for a very critical part of my game. I want to know if it always returns the same result, or i should save the initial result in defaults and use the path from there.

and is it guaranteed to return a path, if no, what’s a reliable way to always get a path to write to?

It should always return the same result. This result is however platform specific. iOS and Android for example have different paths returned.

You should always use getWriablePath() to save your data.
This is the only reliable method.

It’s not the only method to get the correct paths, and it’s usage, especially on iOS, is dependent on the type of data you will be writing. You should read up on the requirements here:

Even Android has it’s own requirements now:

It’s best if you just implement your own functions on iOS and Android to get the correct path for the type of data you want to save on the user device.

Of course there are platform specific implementations. Do you think it is worth it? For what reasons?

You are using cocos2d-x, Do you bother to call the native function?
every time?
Do you understand the meaning of multi-platform?

Unfortunately, several applications I’ve worked on have been knocked back because of the issue of using certain locations on the device to save content that those locations are not suitable for, so the locations had to be changed before the apps were approved. This isn’t a Cocos2d-x specific issue either, but given that there is only one method, which is getWritablePath(), there is only one path returned.

On iOS, that path is Documents/, which is a folder that is backed up to the Apple cloud service. The bigger the content, the longer it takes for user data to be backed up, so Apple placed restrictions on what content should be placed in that path.

For instance, this is an excerpt from the Apple docs:

Put user data in Documents/ . User data generally includes any files you might want to expose to the user—anything you might want the user to create, import, delete or edit. For a drawing app, user data includes any graphic files the user might create. For a text editor, it includes the text files. Video and audio apps may even include files that the user has downloaded to watch or listen to later.

Now, say your app requires downloadable content, something that can be hundreds of megabytes of data. That data cannot be placed in Documents/ on iOS, and instead needs to be placed in either Library/Application support/ or Library/Cache, depending on specific use cases.

Perhaps for the majority of apps made with Cocos2d-x, where there is only a need to save small files, then Documents/ is fine, as long as that data should be accessible to the user (the user can browse that location), and that the data needs to be backed up. If that data is large (even a few MB), and can be recreated any time, then it shouldn’t go in that path, because it’s just taking up bandwidth and storage space in the user cloud storage (which has limits).

It’s trivial to implement code once that can be re-used in applications to return more appropriate paths depending on the type of data that will be written. For example:


Each one has a very specific purpose, and on some platforms (like Windows), the paths returned by all may be exactly the same; it really depends on the requirements set out by that platform.

1 Like

Yes, do you?

While cross-platform frameworks exist, like Cocos2d-x, rarely if ever do they cover all use-cases, and when that happens, it’s up to the developer using that framework to add the missing bits and pieces. I would be surprised if the majority of developers that have worked on such applications haven’t had to dig down into the native layer at some point.

From experience, at least with Cocos2d-x, you can usually get >95% cross platform code, but at some point you’ll have to actually resort to implementing your own interfaces to the native code for functionality that you need. You can even make it cross-platform yourself.

Even if a developer is lucky enough to not require such functionality, it’s in the best interest of the developer to understand as much as they can about the platform that they are targeting.

Thanks. I understand your point better now. Also, I’ll keep this in mind for my own projects.