- Internet Explorer 8, 9, and 10
- Safari 5.0.x (Mac OS X only) and above
- Chrome version 17.0 and above
- Firefox 3.6 and above
On a non-compatible browser, calls to SDK will be ignored. Mobile browsers are not officially supported at this time.
Cross-Origin Resource Sharing
Browser support for the Cross-Origin Resource Sharing (CORS) specification is required for the SDK to use an AJAX request to reach the Medio Data Collection Service (DCS), which is hosted on another domain than your application.
Due to the way that CORS is implemented in Internet Explorer (IE) 8 & 9, the protocol used to communicate with the DCS service must match the protocol of the host page. When your application is running in IE 8 & 9, the SDK will automatically determine the protocol of the host page and use that protocol to communicate with DCS. In other words, if your application is hosted at http://mydomain.com, the SDK will communicate with the DCS service using the HTTP protocol. If your application is hosted at https://secure.mydomain.com, the SDK will communicate with the DCS service using the HTTPS protocol. If your website supports IE 8 & 9, it is important to consider the security needs of your application and host your pages using HTTPS whenever possible to ensure secure communication with the DCS service. On all other browsers, the SDK communicates with the DCS service using the HTTPS protocol regardless of the host page protocol.
Browser support for HTML5 Local Storage is required as the SDK uses it as the internal event buffer.
Browser support for HTML5 Geolocation is required only required when you set the
trackLocation property to
true. This feature may require the user’s explicit permission on some browsers. In most cases the user will be prompted by the browser to approve the request for his/her location.
Internal buffer capacity
Flushing of events assumes that the browser is working in online mode and has an Internet connection available. If the application is offline, a flush request is re-scheduled.
The SDK spreads the sending of large amounts of events over several AJAX requests to minimize memory, CPU and network consumption. Once the Medio DCS successfully acknowledges receipt of the events, the Medio Client SDK removes the events from local storage. If the HTTP request fails for any reason, then the events are not removed from the local storage and re-scheduled for a later time. Events that are not sent to the Medio DCS successfully remain queued up (stored persistently in local storage) and will be sent on the next flush either automatically or manually.
The SDK will ignore all other requests to flush if it is already busy with a previous request. New requests to flush will only be accepted after the previous flush has succeeded or failed.
Flushing events and application behavior
The SDK’s automatic flush behavior may not meet every application’s requirements. For example, if you find automatic flushing affecting critical application processing like game play, then you can disable it temporarily during these critical processing points by calling
Medio.EventApi.setProperties and setting the
autoFlush property to false. Automatic flushing can be re-enabled again by setting the
autoFlush property to true once the critical processing section is complete. Note your application can still flush events on demand using the
Medio.EventApi.flushEvents method while automatic flushing is disabled or enabled.
In extreme cases, you may disable automatic flushing entirely for the life of your application. In this case, we recommend calling the
Medio.EventApi.flushEvents method when you perform some other networking activity (if any). If your application does not have any networking activity, then we recommend calling
Medio.EventApi.flushEvents during pauses in user interaction. For example, in the case of a game, you may wish to flush events in a “Game Over” screen or a “Main Menu” screen.
If you choose to flush events on demand instead of or in addition to automatic flushing, your application should not call
Medio.EventApi.flushEvents too frequently to avoid compromising battery life. On the other hand, you also don’t want to take the risk of losing data by calling
Medio.EventApi.flushEvents too infrequently, as old events are purged to allow for new ones when the internal buffer capacity limit is reached.
Performance and resources
- OS: Mac OS X 10.6.8
- CPU: 2.53 GHz Intel Core i5
- RAM: 4 GB 1067 MHz DDR3
For measuring performance, we used the following tools:
- Custom Benchmark
- Speed Tracer Plugin (Chrome only)
- Memory over time (Chrome and Safari)
The following graphs are from our Custom Benchmark, which is designed to measure the current page’s responsiveness. We used a simple game, written in HTML 5 Canvas, to generate load on the browser. Next, we added our SDK to the game to see if it causes anything to slow down. We use a mock version of our SDK (same methods, but those methods are empty) as a control variable.
The graphs below show how many times our game loop executes, broken down into 9 second intervals. The target rate (without any latency) is 600 executions for every 9 seconds. Internet Explorer (not shown) had similar results, but was tested using a different computer. Firefox and Safari performed the best. In the graphs below, there is no significant difference between using our SDK and our mock SDK (an empty implementation).
For this test, we logged two (2) events per second and automatically flushed every fifteen (15) seconds. We set all optional fields and included eleven (11) common key-value pairs. All of the tests below lasted 180 seconds.
Memory usage during the test was approximately 10,000 kb. Memory usage also remained consistent over the duration of an 8-hour test: the highest the memory usage was 17,000 kb with 10,000 kb as the average.
Chrome offers the best glimpse at memory and CPU utilization, on a per tab basis. When running the Mock SDK (an empty implementation) on Chrome 20 with our custom benchmark page, the CPU utilization was approximately 30%. There was an increase of approximately 1-2% when using our SDK. Most of the CPU load came from our game loop.
Local Storage consumption
The smallest an event can be is about 150 characters (300 bytes in storage). An event with a few key value pairs and optional fields is about 200 characters (400 bytes in storage).
In general, to calculate the storage required for an event, take the base event (about 150 characters) and add the string lengths for each field you set. Note that key value pairs add an additional two characters for delimiters. Also note that certain characters (e.g., quotes) are escaped, so allow a small margin for those as well.
If your average event is 512 bytes (256 characters) in size, you can store approximately 2,048 events in the library’s 1MB of local storage.