Эта страница является переводом страницы ModuleTestAndApprove. Перевод выполнен на 100%.

---

Rules for testing and publishing modules

Follow the rules given below to place a module in iRidium store
Functionality:
The moderator disapproves modules that

• crash
• contain evident errors
• do something different from what is written in the description
• contain undescribed or hidden functions
• download, install or launch an executable code
• are «beta», «demo» and «test» versions
• contain advertizing and materials
• make incorrect diagnostics and display wrong data about a device
• show apps by other developers
• use push-notifications incorrectly
• send personal or confidential information in push-notifications
• contan viruses, spam, ads
• use third-party monetization mechanisms
• discharge a battery fast or heat a device
• have nothing to do wtih controlling a smart device or service
• allow illegal data exchange
• work incorrectly on several panels (except cases when a device limits work of several panels, in this case it must be written in the description)
• restores connection to a device correctly after reloading
• have memory leaks that lead to the app crach some time later
• have a design that does not agree with the style guide

The moderator may disapprove modules that

• repeat modules that are already placed in the store

Other

• developers who clutter the store with different versions of one and the same module will be blocked
• modules must ask a user's permission to share his/her personal data and inform where and why these data will be used

Technical requirements to a module

• There must be a request for module development in the system of module order
• A module must contan at least 1 subdevice
• A module must have as many subdevices as there are working zones supported by a device
• There must be at least ibe widget for each subdevice
• The graphica part of a module must consist of items from the gallery
• A module must contain such Actions, Events and Conditions that described the mininal functions of a device.
• Scripts must be devided into driver, interface and general
• Driver scripts must have no mention of the interface part.
• All names in the interface part must have a localization flag
• All text in the interface must be in English
• To register a module write a correct description in the form of module registration. The description must agree with a developed module.
• Functions with module name space must be used instead of IR name space.
• All Remotes must have a version for a tablet and a smart phone.

Rules of module testing before making it public

Before making a module public do the following

1. Check that the module name, screenshots and icon are correct
2. Check all text. All names must be in English and have no mistakes.
3. Check the module functions. All functional items must work without causing errors in scripts.
4. Check that a module understands that connecion to a device is lost and it shows information about it to a user.
5. Check that a module restores connection to a device and continues to work correctly afer the app is mininized and maximized.
6. Check that a module works on 2 panels semultaneously.
7. Check that a module works on the server.
8. Check that all Actions, Events and Condidtions work.
9. Check that the Setup file is correct and changes in setting work correctly.
10. Check that a module has a design for a tablet and a smart phone.
11. If a module has a text field, check that a keyboard appears when this field is clicked.
12. Check if there is memory leak in the module. To do it, launch a module on a panel and let it work for 24 hours. 24 hours later a module must continue to work correctly.