2.10 Access to SD Cards
Opened this issue · 0 comments
SD Card storage is handled differently than the other Wii U data storage types.
Applications do not need to distinguish between the system NAND memory and USB storage, and the types of data stored to these two media are the same. The saved data is also tied to the system, such that it cannot be used on another console even if transferred via USB storage. (This does not apply to system transfers.)
Meanwhile, SD Card storage allows for the transfer of data between the Wii U console and other consoles or PCs. The data expected to be saved to the SD Card are shown below (for example, data that is exported to a PC). Managing application-specific data on the SD Card is not recommended.
JPEG files and other image data
WAV files and other sound data
CSV files, TXT files, and other general-purpose data
It is still TBD whether to allow applications to load data from an SD Card directly, or only via System Settings.
Generally, an SD Card has the following characteristics; as such, it requires more caution from the application and users when in use compared to other types of storage.
Data corruption caused by powering down the system during a write.
SD Cards might become corrupt on rare occasions.
Data corruption caused by insertion/removal of an SD Card during writing, or writing before or after insertion/removal.
You must contact Nintendo at support@noa.com in advance if you will use a function that accesses an SD Card from within the application.
Use extra caution when writing before or after insertion/removal of the SD Card. Specifically, do not write immediately after inserting the SD Card. "Immediately after" means within 1 second of when the SD Card is inserted.
The system may recognize that the SD Card has been inserted when the user is still inserting it. Writing under this unstable situation may cause unexpected behaviors.
Writing should be avoided immediately after the SD Card is inserted since the connection has not been stabilized.
A possible workaround for this is to require some time between when the user inserts the SD Card and when the system actually starts to write as shown below.
Break the process into two steps ("inserting the SD Card" →"beginning a write operation") by starting a write only when the user explicitly chooses to do so.
Display a message such as "Starting to write to the SD Card. Do not touch the SD Card slot or the POWER Button." and wait for the user's approval.
Alternatively, simply poll the SD Card status and wait for more than 1 second after the insertion is detected. Furthermore, loading immediately after insertion/removal of an SD Card is not recommended because the connection has not been stabilized.
When accessing the SD Card constitutes a very important element of the enjoyment of the application, you must implement the appropriate handling and display appropriate messages in situations given below.
When the SD Card is removed or swapped with the console power turned on:
The program must continue to operate without any problems.
When shutting down while saving to an SD Card:
Always confirm that writing has completed before performing a shutdown.
While saving to an SD Card:
Display a message informing the user that the system is saving to the SD Card, and that the user should not remove the SD Card or turn off the power.
When an unsupported card or a card with unsupported format is inserted in the SD Card slot:
Display a message informing the user that the SD Card cannot be used, or that reading from or writing to the SD Card failed.
When insufficient storage space is detected on an SD Card while saving data:
Display a message informing the user that the SD Card has insufficient free space. It is acceptable to use a different unit other than KB. The Error Viewer is not currently supported, but it is under consideration.
When writing to an SD Card and the write-protect switch is toggled on:
Display a message informing the user that the SD Card is write-protected, and that the user must move the write-protection switch to the unlocked position. This error display can be implemented using the Error Viewer.
When an error occurs during SD Card processing in circumstances other than those listed above:
Display a message informing the user that an SD Card error has occurred. This error display can be implemented using the Error Viewer.
Note:
Under the current specifications, when an SD Card with an unsupported format is detected, the error is not properly displayed if FSGetLastErrorCodeForViewer is passed unchanged to the Error Viewer. However, when an unsupported card is detected (MMC cards, etc), you can use FSGetLastErrorCodeForViewer to display the error in the Error Viewer.
When you use the SD Card only for special features, make sure there are no memory leaks, freezes, or other fatal errors in any of the above situations.
On the application side, determine the importance of the data to be saved to the SD Card. As a general rule, base your decision on whether corruption of data or a lack of messages could cause the user any serious disadvantages in terms of game progress. The following are a few examples.
When writing to the SD Card as the result of explicit user operations:
In such cases, behaving as if the operation succeeded even when SD Card access failed could cause the user considerable distress when later finding that the data is not on the SD Card. Such behavior could also be interpreted by users as a bug in the application.
When saving an in-game screenshot to the SD Card without informing the user, and then displaying it to the user as a surprise after play has finished (or switching to some other screen if saving failed):
In such cases, a failed write would not cause the user much distress, and actually halting play to display an error message could instead be an inconvenience to users during gameplay.
When writing character images or other data to an SD Card where they could be created at any time from save data or ROM data:
Not displaying a message when such a write operation fails could more likely be viewed as a bug by users than the previous case, but conversely, not finishing the write when shutting down would probably not inconvenience users all that much.
Note:
Applications that use SD Cards must also comply with some other file system guidelines. Check each of the following sections individually.
2.2 Access Frequency
2.4 Display While Writing Data
2.5 Programs that Depend on Access Speed
2.8 Using System-Specific Information to Restrict Use of Save Data