This chapter describes the precautions for opening and closing the Nintendo 3DS system. Note that FTR systems cannot be physically opened or closed, but the same effect is achieved by pushing the sleep switch on and off. To apply this chapter to FTR systems, read all instances of "opening/closing the system" below as "pushing the sleep switch on/off."
2.20.1 Detecting When the System Is Opened and Closed via Sleep Requests and Wakeup Callbacks
Frequent opening and closing of the system can damage or shorten the life of the product. Our basic policy is that the opening or closing of the system should not be used as input. An application can detect when the system has been closed or reopened based on sleep requests and wakeup callbacks, but as a general rule, do not use the open/close detection feature as device input.
Examples of when opening/closing the system is considered to be device input and when it is not are given below.
- When Opening/Closing the System Is Considered to Be Device Input
- Opening and closing is counted as a button press, and continuous opening and closing is required
- Opening and closing is used to turn pages in an electronic book
- Compressing or stretching out characters with the action of the system
- Calling an event after the system has been opened and closed a set number of times
- When Opening/Closing the System Is Not Considered to Be Device Input
- Implementing sound effects when the system is opened or closed
- Auto-saving applications when closing the system where a manual save method is provided
- Pausing the application or transitioning to a mode or state similar to a paused state when closing the system, provided that another method of pausing is implemented separately
Exceptions may be made when the use of opening and closing the system as input is essential to gameplay and the system does not have to be opened and closed frequently. If your plans call for such specifications, contact support@noa.com.
2.20.1.1 Prohibiting Determination of Device Input Based on Opening and Closing the System
Guideline Item |
Applications must not use the opening and closing of the system as device input. |
---|---|
Software to Be Tested |
All applications. |
Exceptions |
When performing any of the following actions:
|
Test Method |
Open and close the system in each application mode. |
Pass/Fail Determination |
Passes if in-application events are not linked to the opening and closing of the system. |
2.20.2 Support for Postponing or Refusing Sleep Requests
If a sleep request is issued when the system is closed but that sleep request is postponed for some reason (for example, because data is being written), be aware that the system may be opened while the request is still postponed. Specifically, if you perform no rendering while requests are postponed and the system is opened before the operation finishes, a black screen will continue to display for a short time, which is in violation of what is written in section 2.3.2 Intervals During Which Device Input Is Ignored and section 3.2.3 Screen Display When Writing Data.
For this reason, we recommend implementing some mechanism to restart rendering when the sleep recovery callback is called—even if a sleep request is currently being postponed—so that the user does not think the system is frozen.
An application does not need to respond to a sleep cancel callback if returning REPLY_LATER within 4 seconds.
No required guideline items.