Legacy SDK resources only
Legacy SDK Validation Procedure
Prior to release, Yospace will inspect your App(s) to ensure that they are integrated correctly with our SDKs. This is to make sure that our services are not being overloaded and that all analytic beacons are being correctly fired. In order to do this we will usually ask for two things cli network capture log e.g. Charles, Fiddler etc showing the streaming session being set up and play back traversing an ad break (from content to ad break and back again) system log (console, adb, trace etc) showing the output from the SDK and App with the appropriate debug flags set.
Note: Please ensure you start the capture just before the beginning of a playback session and then stop it just after the stream comes out of the ad break. The system log and network log must be for the same playback session.
You will need to provide these logs via an FTP / sharing service because the network logs are likely to be very large. Also, please ensure that you have named the logs file pairs in a simple and meaningful manner.
You’ll need to set up the network capture tool as documented by the vendor. Specifically you should ensure that the following items are configured SSL proxying is enabled if you are using SSL/HTTPS (for Yospace hosts at a minimum). Note that this may involve installing the appropriate SSL certificate on your device and/or application. The proxy should operate in transparent mode where possible. The proxy should be bypassed for non-internet addresses i.e. \’localhost\’, 192.168.x.x etc
You’ll need to set the correct debug flags in the Yospace SDK so that we can see the trace messages for various operations.
Note: if you have existing trace output from your app or third party component which is verbose, it would be helpful to try to reduce this, or to filter it. This is because for typical validation we shouldn’t need this information.
Session.SessionProperties properties = new Session.SessionProperties(VIDEO_URL);
YSSessionManager.DEFAULTS.DEBUGGING = true;
Additionally, depending on your target platform, you may need to define the following debug function:
Debugger.print = function(msg)
Here you should use your target platform’s relevant tracing capability to print the contents of msg eg. console.log(msg)
SessionProperties sessionProperties = new SessionProperties(mUrl)
Stream Startup and Playback through an Ad Break
- Begin playback of a Yospace SSAI-enabled stream. Ensure playback of stream begins in content (not in an ad)
- Wait until an an Ad Break completes then stop the stream.
Interact with an Ad
This test case is dependent on your App’s support for interaction features of an advert (clickthroughs, nonlinear overlays, full screen, mute, pause). If there is no support you may skip that test.
- click-through on the linear portion of the advert
- click-through on the nonlinear portion of the advert
- change the screen size to full screen and back again, or vice-versa
- mute and unmute the sound
- pause and resume the advert
Note: Yospace does not support pause and resume in live because it can cause analytics to fail in several ways.
Backgrounding and Foregrounding
This test case is dependent on your App’s target platform’s support for backgrounding. Typically this applies to mobile devices but may extend to other platforms.
Yospace sessions will timeout after approximately 2 minutes if the stream manifest is not requested in that time. You must be mindful of this fact with respect to the behaviour of the player you are using when playback is stopped/paused especially in the case that an App is backgrounded.
Yospace recommend that the session is shutdown on backgrounding and a new session is started on foregrounding.
- Background the App
- After waiting for over 2 minutes bring the App back to the foreground
Switching Streams or Shutting Down Manually
In cases where it is possible for the App or user to terminate playback we need to ensure that the session is correctly cleaned up.
In cases where a user may switch from one stream to another we need to ensure that the existing session is correctly cleaned up and that a new session is created for the new stream.
If your App supports both of these cases then you must run this test case for each.
- Stop the stream OR switch channel