From Module developer
This page is a translated version of the page ModuleTestAndApprove and the translation is 100% complete.
Rules for testing and publishing modules
Follow the rules given below to place a module in iRidium store
The moderator disapproves modules that
- 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
- 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
- Check that the module name, screenshots and icon are correct
- Check all text. All names must be in English and have no mistakes.
- Check the module functions. All functional items must work without causing errors in scripts.
- Check that a module understands that connecion to a device is lost and it shows information about it to a user.
- Check that a module restores connection to a device and continues to work correctly afer the app is mininized and maximized.
- Check that a module works on 2 panels semultaneously.
- Check that a module works on the server.
- Check that all Actions, Events and Condidtions work.
- Check that the Setup file is correct and changes in setting work correctly.
- Check that a module has a design for a tablet and a smart phone.
- If a module has a text field, check that a keyboard appears when this field is clicked.
- 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.