STB API aimed to be consistent and comprehensively documented, but the nature of objects and their corresponding methods
is becoming obsolete during the time when new APIs occured.
For safe and predictable usage of STB API functionality and as a best practice it's recommended to check presence of objects
and even methods before first use. Especially for new API objects which can be absent in old firmwares.
There are two main techniques for reducing errors associated with object and their methods presence.
Check API version (suitable when using some features which exist since particular version). Be attentive when using API features
which presented only on supported devices, use additional checking in this case:
var apiVersion = +gSTB.Version().split(';')[0].split(':')[1].trim();
if ( apiVersion < 343 ) {
console.log('API version on STB hasn\'t features of 343 and above');
} else {
// use modern API features which are totally supported in current API across all devices
stbNfs.findServers(function ( error, data ) { /* code*/ });
// but still checking API features whose presence defined by device model
if ( stbBluetooth && stbBluetooth.startDiscovery ) {
stbBluetooth.startDiscovery({duration: 20});
}
}
Alternative approach is checking presence of particular objects and methods immediately:
if ( stbNfs && stbNfs.findServers ) {
console.log('Functionality is available, use it!');
}
To prevent crash of code that uses unstable API it's possible to wrap whole code in try/catch
. This isn't a recommended way
to handle API's features, rather one of possible:
try {
stbUPnP.init();
stbUPnP.getServerListSync();
} catch ( error ) {
console.log('stbUPnP API is unavailable: ' + error.message);
}