The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter describes the Cisco StadiumVision Mobile SDK Release 1.3 for Google Android, and contains the following sections:
•New Features in Cisco StadiumVision Mobile Release 1.3 Android SDK
•Introduction to Cisco StadiumVision Mobile API for Google Android
•Cisco StadiumVision Mobile Android API
Note the following for release 1.3 of the Cisco StadiumVision Mobile SDK:
•None of the release 1.2 APIs have changed for release 1.3.
•The Cisco StadiumVision Mobile SDK release 1.3 is backwards compatible with release 1.2, and can be imported into your project without any software changes.
New Features in Release 1.3
•StadiumVision Mobile Service up and down indicator and notifications
•In-venue detection and notifications
•Setting the SDK Configuration at Run-Time
•StadiumVision Mobile Streamer detection
•Statistics collection enhancements, including StadiumVision Mobile Reporter upload statistics, multicast channel announcement statistics, and licensing statistics
•Video player State notifications
•Video player background audio
•Video player Inactive channel callback
The Cisco StadiumVision Mobile API uses Android and Java classes and method calls to access the StadiumVision Mobile data distribution and video playback functionality within the StadiumVision Mobile Android SDK library.
The Cisco StadiumVision Mobile client application supports Android 2.1 or later.
This document contains the following sections:
•Cisco StadiumVision Mobile Android API
Table 2-1 lists the various Android SDK build environment requirements.
Table 2-1 Build Environment Requirements
|
|
|
|
---|---|---|---|
Mac or Windows PC |
— |
— |
— |
Eclipse |
3.7.1 or later |
Eclipse "Classic" for Mac OSX (64-bit) |
http://www.eclipse.org/downloads/ |
The Cisco StadiumVision Mobile SDK that we provide to app developers includes the source code for an Android demo app. The purpose of the app is demonstrate what is possible, an to enable a new app developer to quickly get a working app up and running.
Step 1 Download the Android Developer Tools ADT.
Step 2 Follow these instructions to set up ADT on your computer.
Step 3 Launch the Eclipse application and when prompted select a folder to use as your workspace.
Step 4 Launch the Android SDK Manager from the Window dropdown menu.
Step 5 Open the Android 2.2 (API 8) folder and check the SDK Platform box. Uncheck everything else and then install the selected package.
Step 1 Download the StadiumVisionMobileSample-Android-xxxx.tar.bz2 SDK and demo app package.
Step 2 Extract the downloaded package into a directory.
Step 3 Import the demo app project into Eclipse as follows:
a. In Eclipse go to File=>Import
b. Then go to General=>Existing Projects into Workspace, and select Next.
c. Set the Select root directory to the folder where you unpacked the SDK, and then click Finish.
d. Restart Eclipse from File=>Restart.
Step 4 Right click on CiscoStadiumVisionMobile in the left Package Explorer window, and select Android Tools=>Export Signed Application Package.
Step 5 Click Next when the Project Checks window appears.
Step 6 Select Create new keystore, then browse to a folder where you wish to store the key store file. Click Next.
Step 7 Fill in the Key Creation form. There are no right or wrong answers. Click Next.
Step 8 Browse to the folder where you wish to place the apk file, then click Finish.
Step 9 Download the apk file to your Android device by placing it on a web server, emailing it, SD card, USB flash key, etc.
Step 10 Now install the apk on your device.
Here are some of the first items you may want to customize in the demo app:
Change the text for the app icon:
•In the the file "res/values/strings.xml" change "SVM Demo" to "My SVM App"
Change the name space so your custom app can be installed side by side with the out of the box demo app:
•Edit the file "AndroidManifest.xml":
–Change "package="com.cisco.sv"" to "package="com.cisco.svm.foo"
–Change "android:name="com.cisco.svm.app.StadiumVisionMobile" to "android:name="com.cisco.svm.foo"
Note The package name must start with "com." (excluding the quotes).
•Search and replace com.cisco.sv.R with com.cisco.svm.foo.R in all *.java files in src/app/demo.
The Cisco StadiumVision Mobile Android SDK contains the following components:
•A set of static libraries, configuration files, player layout XML files, and a sample Android application.
•Customizable video player
Figure 2-1 describes the three main Android API classes used in Cisco StadiumVision Mobile. The top-level StadiumVisionMobile class acts as a custom Android application context. An application context is a structure created within a screen or activity. There is no global state across an Android application.
Each SDK API method is called using the StadiumVisionMobile class. The SVMVideoPlayerActivity class is a customizable stand-alone video player.
Figure 2-1 StadiumVision Mobile Class
Figure 2-2 depicts the Android OS with regard to Activities. An Activity represents both the screen layout and controller code. A new Activity is launched by sending an Intent to the Android OS. An intent is a message to Android OS to launch a particular activity. Extra parameters contained in an Intent and are passed to an Activity. The back button is a hard device button used to generically display the previous Activity, and moves back down the Activity stack.
Figure 2-2 Android Activity Overview
Figure 2-3 depicts the Activity inheritance between the Android OS, Cisco StadiumVision Mobile, and the client application.
Figure 2-3 Android Video Player Activity Inheritance
Table 2-2 summarizes the Android API library. Following the summary are detailed tables for each API call.
Table 2-2 Cisco StadiumVision Mobile Android API Summary
The following tables describe each API call in more detail, including example usage.
Each API call returns an `SVMStatus' object whenever applicable. Table 2-3 lists the SVMStatus object fields. This section contains the following API calls and tables:
•getStats API Hash Keys and Stats Description
Table 2-3 SVMStatus Object
Table 2-4 Start
Table 2-5 getVideoChannelArray
|
public static SVMChannel[] getVideoChannelArray(); |
---|---|
|
N/A |
|
This method returns a Java array of available video channels as 'SVMChannel' objects. |
|
N/A |
Table 2-6 getDataChannelArrayList
Table 2-7 addDataChannelObserver
Figure 2-4 onData
Table 2-8 removeDataChannelObserver
Table 2-9 getStats
|
public static HashMap<String, String> getStats(); |
---|---|
|
N/A |
|
This method returns the StadiumVision Mobile SDK stats as a hash of name / value pairs. |
|
N/A |
Table 2-10 lists the hash keys and stats description for the getStats API.
Table 2-10 getStats API Hash Keys and Stats Description
Table 2-11 onPause
Table 2-12 onResume
Table 2-13 getWifiInfo
Table 2-14 getBatteryInfo
Table 2-15 getLogLevelArray
|
public static String[] getLogLevelArray(); |
---|---|
|
N/A |
|
This method provides a Java array of available logging levels that can be applied to any component. |
|
N/A |
Table 2-16 getLogLevelArrayList
Table 2-17 setLogLevel
Table 2-18 getLocalIpAddress
|
public static String getLocalIpAddress(); |
---|---|
|
N/A |
|
This method returns this device's local IP address. |
|
N/A |
Table 2-19 getDeviceUUID
Table 2-20 getAppSessionUUID
Table 2-21 sdkVersion
|
|
---|---|
|
N/A |
|
This class property contains StadiumVision Mobile SDK version string. |
|
N/A |
The SVMVideoPlayerActivity class can be extended and customized. Table 2-22 lists the SVMVideoPlayerActivity API methods, and contains the following tables:
Table 2-22 Video Player Activity API Summary
Table 2-23 setVideoSurfaceView
|
public static String sdkVersion; |
---|---|
|
N/A |
|
This class property contains StadiumVision Mobile SDK version string. |
|
|
|
N/A |
Table 2-24 seekRelative
Table 2-25 seekAbsolute
Table 2-26 rewindForDuration
Table 2-27 playLive
Table 2-28 shutdown
Table 2-29 setConfig
Table 2-30 setConfigWithString
Table 2-31 getConfig
|
public static JSONObject getConfig() |
---|---|
|
N/A |
|
This method returns the current SDK configuration as a 'JSONObject' object. |
|
NSDictionary* |
Table 2-32 getStreamerArray
Table 2-33 getStreamerArrayList
This section describes the SDK workflow, and contains the following sections:
•Getting the Video Channel List
•Presenting the Video Channel List
•Seeking Within the Video Buffer
•Getting the Data Channel List
•Activity Life-Cycle Notifications
•StadiumVision Mobile Service Up or Down Indicator
•Set the SDK Configuration at Run-Time
•setConfigWithString API Method
•Get the Available Streamer Servers
•Video Player State Notifications
•Cisco Demo Customized Video Player
Start the StadiumVision Mobile SDK from the application's main Android launch Activity, as shown in the following example.
import com.cisco.svm.app.StadiumVisionMobile;
// app's launch activity `onCreate' notification
void onCreate() {
// call the parent method
super.onCreate();
// start the StadiumVision Mobile SDK
StadiumVisionMobile.start();
}
The StadiumVision Mobile SDK dynamically receives all of the available channels (via WiFi multicast). The client application gets an array of channel objects (SVMChannel[]) through the "getVideoChannelArray" API call, as shown in the following example:
import com.cisco.svm.app.StadiumVisionMobile;
// get the list of available video channels
SVMChannel[] channels = StadiumVisionMobile.getVideoChannelArray();
// display some channel information
Log.d(TAG, "Channel Name = " + channels[0].name);
Log.d(TAG, "Channel Bandwidth = " + channels[0].bandwidthKbps);
Log.d(TAG, "Channel Body Text = " + channels[0].bodyText);
Each "SVMChannel" video channel object contains all of the information needed to display the channel list to the user. The SVMChannelObject properties and descriptions are shown in Table 2-34.
Table 2-34 SVMChannel Object Properties
The following example shows playing a video channel, and performs the following actions:
•Selects a channel from the locally saved channel list
•Starts video playback of the channel by launching the custom video player Activity ("MyVideoPlayer")
Note The "SVMChannel" object is parcelable (instances can be written to and restored from a parcel).
The last 30 seconds of played video is stored in device RAM. The following example shows jumping backwards 20 seconds in the video buffer (instant replay):
public class MyVideoPlayerActivity extends SVMVideoPlayerActivity {
// seek backwards 20 seconds in the video buffer
super.seekRelative(-20000);
}
The following example shows jumping back to the top of the video buffer ("live" video playback):
public class MyVideoPlayerActivity extends SVMVideoPlayerActivity {
// seek to the top of the video buffer (0 ms offset)
super.seekAbsolute(0);
}
The video region is rendered within a SurfaceView. The video region is configured using standard Android layout XML files. The video region can be set to full screen or to specific pixel dimensions
The XML layout file below shows how to configure the video `SurfaceView' to fill the entire screen, as shown in the following example:
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout
xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:background="@drawable/black">
<SurfaceView
android:id="@+id/videoSurfaceView"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:layout_centerInParent="true">
</SurfaceView>
</RelativeLayout>
The XML layout file below shows how to configure the video `SurfaceView' to specific pixel region, as shown in the following example:
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout
xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:background="@drawable/black">
<SurfaceView
android:id="@+id/videoSurfaceView"
android:layout_width="320px"
android:layout_height="240px"
android:layout_centerInParent="true">
</SurfaceView>
</RelativeLayout>
The StadiumVision Mobile SDK dynamically receives all of the available data channels (via WiFi multicast). The client application gets an array of channel objects (SVMChannel[]) through the "getDataChannelArray" API call, as shown in the following example:
import com.cisco.svm.app.StadiumVisionMobile;
// get the list of available data channels
SVMChannel[] channels = StadiumVisionMobile.getDataChannelArray();
// display some channel information
Log.d(TAG, "Channel Name = " + channels[0].name);
Log.d(TAG, "Channel Bandwidth = " + channels[0].bandwidthKbps);
Log.d(TAG, "Channel Body Text = " + channels[0].bodyText);
Any data channel can be observed by registering a class to receive callbacks for all data received on that channel. The registered class needs to implement the "ISVMDataObserver" interface, as shown in the following example:
import com.cisco.svm.data.ISVMDataObserver;
public class MyDataViewerActivity extends Activity implements ISVMDataObserver {
...
}
The "onData" method is called to push the received data to the registered class, as shown in the following example:
public void onData(String channelName, byte[] data) {
// display the received data parameters
Log.d(TAG, "DATA CALLBACK: " +
"channel name = " + channelName + ", " +
"data length = " + data.length);
}
The client app needs to notify the StadiumVision Mobile SDK of it's life-cycle notifications. This allows the StadiumVision Mobile SDK to automatically shutdown and restart as needed. Each client Activity needs to forward its life-cycle notifications, as shown in the following example:
import com.cisco.svm.app.StadiumVisionMobile;
void onPause() {
// notify the cisco sdk of the life-cycle event
StadiumVisionMobile.onPause();
}
void onResume() {
// notify the cisco sdk of the life-cycle event
StadiumVisionMobile.onResume();
Release 1.3 of the Cisco StadiumVision Mobile SDK includes an indicator to the application indicating if the SVM service is up or down. This indication should be used by the application to indicate to the user whether the SVM service is available or not. Service is declared 'down' by the SDK when any of the following are true:
•The SDK detects that the video quality is poor
•The SDK detects that no valid, licensed channel are available
•The mobile device's WiFi interface is disabled
Poor video quality can occur when the user is receiving a weak WiFi signal; causing data loss. There are two different ways that the iOS app can get the "Service State" from the SDK:
•Register to receive the "Service Up / Down" notifications
•Fetch the current service state from the SDK on-demand
When the app receives the "Service Down" notification, the SDK will supply a bitmap containing the reasons why the service was declared as 'down' by the SDK. The 'reasons' bitmap is given in
The following example shows how to register and handle the "Service Up / Down" notifications from the SDK:
import com.cisco.svm.app.StadiumVisionMobile;
import com.cisco.svm.app.StadiumVisionMobile.SVMServiceState;
// define the service state broadcast receiver
private BroadcastReceiver serviceStateReceiver;
// create the service state broadcast receiver
serviceStateReceiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
// get the intent extras
Bundle bundle = intent.getExtras();
// get the service state from the bundle
SVMServiceState serviceState = (SVMServiceState)bundle.get(StadiumVisionMobile.SVM_SERVICE_STATE_VALUE_TAG);
// determine the service state
if (serviceState == SVMServiceState.SVM_SERVICE_STATE_UP) {
Log.i(TAG, "### SERVICE STATE: UP");
} else if (serviceState == SVMServiceState.SVM_SERVICE_STATE_DOWN) {
Log.i(TAG, "### SERVICE STATE: DOWN");
// get the service state changed reasons bitmap
int reasons = bundle.getInt(StadiumVisionMobile.SVM_SERVICE_STATE_CHANGED_REASONS_TAG);
// determine the reasons that the service state changed
if ((reasons & StadiumVisionMobile.SVM_SERVICE_STATE_DOWN_REASON_SDK_NOT_RUNNING) != 0) {
Log.i(TAG, "Reason for Service State Change: SDK NOT RUNNING");
} else if ((reasons & StadiumVisionMobile.SVM_SERVICE_STATE_DOWN_REASON_WIFI_DOWN) != 0) {
Log.i(TAG, "Reason for Service State Change: WIFI DOWN");
} else if ((reasons & StadiumVisionMobile.SVM_SERVICE_STATE_DOWN_REASON_NO_CHANNELS) != 0) {
Log.i(TAG, "Reason for Service State Change: NO CHANNELS AVAILABLE");
} else if ((reasons & StadiumVisionMobile.SVM_SERVICE_STATE_DOWN_REASON_POOR_QUALITY) != 0) {
Log.i(TAG, "Reason for Service State Change: POOR QUALITY");
}
}
}
};
// register to receive the service state intents
IntentFilter serviceStateIntentFilter = new IntentFilter();
serviceStateIntentFilter.addAction(StadiumVisionMobile.SVM_SERVICE_STATE_CHANGED_INTENT_TA G);
registerReceiver(serviceStateReceiver, serviceStateIntentFilter);
The "getServiceState" API method can be used to fetch the current service state from the SDK. The following example show how to fetch the current service state from the SDK using the "getServiceState" API call:
import com.cisco.svm.app.StadiumVisionMobile;
import com.cisco.svm.app.StadiumVisionMobile.SVMServiceState;
// get the current svm service state
SVMServiceState serviceState = StadiumVisionMobile.getServiceState();
// determine the current service state
if (serviceState == SVMServiceState.SVM_SERVICE_STATE_UP) {
Log.i(TAG, "### SERVICE STATE: UP");
} else if (serviceState == SVMServiceState.SVM_SERVICE_STATE_DOWN) {
Log.i(TAG, "### SERVICE STATE: DOWN");
}
The Cisco StadiumVision Mobile Release 1.3 SDK provides a mechanism to detect whether the mobile device is connected within the SVM-enabled venue or not.
There are two different ways that the Android app can get this "In-Venue Detection" state from the SDK:
•Register to receive the "In-Venue Detection" notifications
•Fetch the current "In-Venue" state from the SDK on-demand
The following example shows how to register and handle the "Service Up / Down" notifications from the SDK:
import com.cisco.svm.app.StadiumVisionMobile;
// define the 'in-venue status changed' broadcast receiver
private BroadcastReceiver inVenueReceiver;
// handle the venue connection changed event
venueConnectionReceiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
// get the intent action
String action = intent.getAction();
// determine whether the device is inside or outside of the venue
if (action.equals(StadiumVisionMobile.SVM_VENUE_CONNECTED_INTENT_TAG)) {
Log.i(TAG, "##### App Received 'VENUE-CONNECTED' Notification");
} else if (action.equals(StadiumVisionMobile.SVM_VENUE_DISCONNECTED_INTENT_TAG)) {
Log.i(TAG, "##### App Received 'VENUE-DISCONNECTED' Notification");
}
}
};
// register to receive the venue connected / disconnected intents
IntentFilter inVenueIntentFilter = new IntentFilter();
inVenueIntentFilter.addAction(StadiumVisionMobile.SVM_VENUE_CONNECTED_INTENT_TAG);
inVenueIntentFilter.addAction(StadiumVisionMobile.SVM_VENUE_DISCONNECTED_INTENT_TAG);
registerReceiver(venueConnectionReceiver, inVenueIntentFilter);
The "isConnectedToVenue" API method can be used to fetch the current in-venue state from the SDK. The following example shows how to fetch the current service state from the SDK using the "isConnectedToVenue" API call:
import com.cisco.svm.app.StadiumVisionMobile;
// get whether the device is currently connected to the SVM licensed venue
boolean isConnectedToVenue = StadiumVisionMobile.isConnectedToVenue();
// log whether the device is currently connected to the SVM licensed venue
Log.i(TAG, "### Connected to the venue: " + (isConnectedToVenue ? "YES" : "NO"));
Previously, the Cisco StadiumVision Mobile SDK could only be configured by using a JSON-formatted config file ("cisco_svm.cfg") bundled within the Android app. Starting with the 1.3 release, the application can now set the SDK configuration at run-time through an API method. This allows the application to dynamically configure the SDK. For example, the application can fetch the SDK configuration information from a network connection, and then pass that configuration to the SDK.
Two different methods are provided for setting the SDK configuration at run-time:
•"setConfig"
The signature of the "setConfig" API method is given below:
// configure the sdk using a JSON object containing the configuration settings
public static SVMStatus setConfig(JSONObject givenJsonConfig)
// configure the sdk using an nsdictionary containing the configuration settings
•"setConfigWithString"
The signature of the "setConfigWithString" API method is given below:
// configure the sdk using a json-formated string containing the configuration settings
public static SVMStatus setConfigWithString(String jsonConfigStr)
The following example shows how to set the SDK configuration using the "setConfigWithString" API method:
// create the json config string
String configString =
@"{"
" \"license\": {"
" \"venueName\": \"MyVenueNameKey\","
" \"contentOwner\": \"MyContentOwnerKey\","
" \"appDeveloper\": \"MyAppDeveloperKey\""
" }"
"}";
"getConfig" API Method#
The signature of the "getConfig" API method is given below:
// get the current cisco sdk configuration
public static JSONObject getConfig()
The example below fetches the current configuration from the SDK, and then accesses the configuration values in the configuration JSON object:
// get the sdk configuration dictionary
JSONObject configObj = StadiumVisionMobile.getConfig();
// get the license dictionary from the config dictionary
JSONObject licenseObj = null;
try {
licenseObj = configObj.getJSONObject("license");
} catch (JSONException e) {
e.printStackTrace();
}
// if the license object is valid
if (licenseObj != null) {
// get the current set of configured license keys
String venueName = licenseObj.getString("venueName");
String contentOwner = licenseObj.getString("contentOwner");
String appDeveloper = licenseObj.getString("appDeveloper");
}
The following example shows how to set the SDK configuration using the "setConfig" API method:
// create the config json object with the set of licensing keys
JSONObject jsonConfig = new JSONObject();
JSONObject licenseConfig = new JSONObject();
try {
licenseConfig.put("venueName", "MyVenueNameKey");
licenseConfig.put("contentOwner", "MyContentOwnerKey");
licenseConfig.put("appDeveloper", "MyAppDeveloperKey");
jsonConfig.put("license", licenseConfig);
} catch (JSONException e) {
// log the error
Log.e(TAG, "Error building the json config object");
e.printStackTrace();
}
// update the cisco sdk configuration at run-time
StadiumVisionMobile.setConfig(jsonConfig);
The signature of the "setConfigWithString" API method is given below:
// configure the sdk using a json-formated string containing the configuration settings
public static SVMStatus setConfigWithString(String jsonConfigStr)
The following example shows how to set the SDK configuration using the "setConfigWithString" API method:
// create the cisco sdk json configuration string
String config =
"{" +
" \"license\": {" +
" \"venueName\": \"MyVenueNameKey\"," +
" \"contentOwner\": \"MyContentOwnerKey\"," +
" \"appDeveloper\": \"MyAppDeveloperKey\"" +
" }" +
"}";
// update the cisco sdk configuration at run-time
StadiumVisionMobile.setConfigWithString(config);
The Android SDK detects the available Streamer servers and provides an API to get the list of servers. A venue will typically only have a single Streamer server. The list is presented as an array of "SVMStreamer" objects.
There are two different methods available that present the "SVMStreamer" objects in either a Java array or ArrayList collection. The signatures for the two API methods are given below:
// get the detected streamer servers as a java array of "SVMStreamer" objects
public static SVMStreamer[] getStreamerArray()
// get the detected streamer servers as a java ArrayList of "SVMStreamer" objects
public static ArrayList<SVMStreamer> getStreamerArrayList()
Each "SVMStreamer" object contains the following properties listed in Table 2-36.
Table 2-36 "SVMStreamer" Object Properties
The following example shows how to get the list of StadiumVision Mobile Streamer servers detected by the SDK:
// get the list of currently available streamer servers
ArrayList<SVMStreamer> streamerList = StadiumVisionMobile.getStreamerArrayList();
// iterate through the list of streamer objects
for (SVMStreamer nextStreamer: streamerList) {
// get the properties of the next streamer server object
String ipAddress = nextStreamer.getIpAddress();
String statsUploadUrl = nextStreamer.getStatsUploadUrl();
int statsSampleIntervalMs = nextStreamer.getStatsSampleIntervalMs();
int statsPublishIntervalMs = nextStreamer.getStatsPublishIntervalMs();
boolean isAllowed = nextStreamer.isAllowed();
}
In the Cisco StadiumVision Mobile Release 1.3 SDK, the existing "stats" API call returns the following additional categories of stats information:
•Reporter upload stats
•Multicast channel announcement stats
•Licensing stats
The signature of the existing "getStats" API method is given below:
// get the current set of cisco sdk stats as a hashmap
public static HashMap<String, String> getStats()
The new stats and their associate dictionary keys and description are given in Table 2-37.
Table 2-37 Stats API Dictionary Keys
The 1.3 SDK generates broadcast Intent notifications for each of the video player state transitions (listed in Table 2-38). The application can listen to these notifications and take action based on the video player's state transitions.
Table 2-38
Video Player State Notification
The following example shows how to subscribe to receive the video player Intent broadcast messages, and then parse the messages for the (1) channel name and (2) video player state:
// create the channel state change broadcast receiver
channelStateReceiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
// get the intent action
String action = intent.getAction();
// get the intent extras
Bundle bundle = intent.getExtras();
// determine the broadcast intent type
if (action.equals(StadiumVisionMobile.SVM_CHANNEL_STATE_CHANGED_INTENT_TAG)) {
// get the updated channel name and state info
String channelName = (String)bundle.get(StadiumVisionMobile.SVM_CHANNEL_NAME_VALUE_TAG);
String channelState = (String)bundle.get(StadiumVisionMobile.SVM_CHANNEL_STATE_VALUE_TAG);
// determine the channel state
if (channelState.equals(StadiumVisionMobile.SVM_VIDEO_PLAYING_STATE) == true) {
// channel is now playing
}
}
}
};
// create the intent filter
IntentFilter channelStateReceiverIntentFilter = new IntentFilter();
channelStateReceiverIntentFilter.addAction(StadiumVisionMobile.SVM_CHANNEL_STATE_CHANGED_I NTENT_TAG);
// register the intent filter
context.registerReceiver(channelStateReceiver, channelStateReceiverIntentFilter);
To detect that a currently playing video channel has become invalid (due to Streamer server admin changes), the SVM video player ("SVMVideoPlayerActivity") provides a callback to tell the video player sub-class (ie: "MyVideoPlayerActivity") that the currently playing channel is no longer valid.
When a channel becomes invalid, playback of the video channel is automatically stopped.
To receive these callbacks, the "onCurrentChannelInvalid" method must be overridden by the 'SVMVideoPlayerActivity' sub-class (ie: "MyVideoPlayerActivity"). The following example shows the method signature and implementation of this overridden callback method:
@Override
protected void onCurrentChannelInvalid() {
// call the parent method
super.onCurrentChannelInvalid();
/*
* This "MyVideoPlayerActivity" implements the following app-specific
* behavior when receiving the 'onCurrentChannelInvalid' callback
* from the Cisco SVM SDK
*
* 1) Stop video player
* 2) Display a toast message describing why video playback was stopped
* 3) Dismiss the video player Activity
*/
// shutdown video playback
shutdown();
// display a notification that the channel is no longer valid
Toast.makeText(this, "\nChannel is no longer valid and the video player has been stopped\n", Toast.LENGTH_LONG).show();
// exit this video player activity now
thisActivity.finish();
}
This section describes customizing the video player.
The default Cisco video player has the following features:
•Implemented as a separate Android "Activity"
•Supports fullscreen and partial-screen video views
•Renders video frames using an Android "SurfaceView"
•Customizable by extending the "SVMVideoPlayerActivity" class
•Uses a customized video player
Figure 2-5 Default Cisco Video Player
Figure 2-6 SVMVideoPlayerActivity API
The Cisco demo video player:
•Implemented as "MyVideoPlayerActivity"
•Extends the "SVMVideoPlayerActivity" class
•Handles all video overlays and gestures
•Uses standard Android XML layout files ("layout/player.xml")
The video player's XML layout file defines:
•The "SurfaceView" video rendering area
•Any transparent video overlays
•Play / Pause / Rewind button graphic files
•Animations used to show / hide the transport controller
The customized video play extends the "SVMVideoPlayerActivity" base class, as shown below:
import com.cisco.sv.media.SVMVideoPlayerActivity;
public class MyVideoPlayer extends SVMVideoPlayerActivity {
}
You need to register the new custom Activity in "AndroidManifest.xml, as shown below:
<activity android:label="@string/app_name"
android:name="com.company.MyVideoPlayer"
android:screenOrientation="landscape"
android:configChanges="orientation|keyboardHidden"
android:theme="@android:style/Theme.NoTitleBar.Fullscreen">
</activity>
The following section describes the required configuration.
There are three configuration files that must be bundled with any Android app using the StadiumVision Mobile SDK.
Table 2-39
Configuration Files
An example set of fields in the "cisco_svm.cfg" file is shown below.These fields must match the channel settings in the Cisco "Streaming Server" for the channels to be accessible by the application.
{
"license": {
"venueName": "Stadium-A",
"contentOwner": "Multi-Tenant Team-B",
"appDeveloper": "Vendor-C"
}
}
The "cisco_svm.cfg" config file can optionally include an array of WiFi AP information that will be used by the StadiumVision Mobile SDK for statistics reporting if available. Below is an example WiFi AP info entry in the "cisco_svm.cfg" config file:
{
"network": {
"wifiApInfo": [
{
"name": "Press Box Booth 5",
"bssid": "04:C5:A4:09:55:70"
}
]
}
}
This section describes customizing the StadiumVision Mobile application, and contains the following subsections:
Figure 2-7 Cisco StadiumVision Mobile Integration Overview
1. Supported Android OS Version
–Set the app's Android version target to v2.1u1 or above
2. Android App Permissions
–Add the required permissions to "AndroidManifest.xml"
3. Copy Config Files
–Add the config files to the app's "assets" folder
4. Copy Libraries
–Add the Java and native libraries to the app's "libs" folder
5. Set a Video "SurfaceView"
–Add a "SurfaceView" to the player Activity's layout XML file
6. Life-Cycle Notifications
–Forward life-cycle notifications to the StadiumVision Mobile SDK
7. Android Project Build Paths
–Set the project build path to include the Jar files in "./libs/"
Figure 2-8 illustrates the roles of the customer application. The application must specify:
•Getting the list of video channels
•Displaying the list of video channels
•Handling user gestures for selecting video channels
•Adding video overlays and layouts
•Handling user gestures to control video overlay
Figure 2-8 Customer Application Responsibilities
The following Android permissions are needed by the StadiumVision Mobile SDK. Each permission is set in the "AndroidManifest.xml" file.
<uses-permission android:name="android.permission.WAKE_LOCK" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.CHANGE_WIFI_STATE" />
<uses-permission android:name="android.permission.CHANGE_WIFI_MULTICAST_STATE" />
Each Java JAR library needs to be included in the Android app's "libs" folder, as shown in the following example.
•Cisco StadiumVision Mobile Android SDK
•Apache HTTP Client 4.1
•Jackson JSON 1.8.1
./libs/StadiumVisionMobile.jar
./libs/httpclient-4.1.1.jar
./libs/httpcore-4.1.jar
./libs/httpmime-4.1.1.jar
./libs/jackson-core-lgpl-1.8.1.jar
./libs/jackson-mapper-lgpl-1.8.1.jar
Each library needs to be included in the Android app's "libs/armeabi" folder.
./libs/armeabi/libsvm-android.a
./libs/armeabi/libvoAACDec.so
./libs/armeabi/libvoAACDec_v7.so
./libs/armeabi/libvoH264Dec.so
./libs/armeabi/libvoH264Dec_v7.so
./libs/armeabi/libvoLiveSrcCTS.so
./libs/armeabi/libvoLiveSrcCTS_v7.so
./libs/armeabi/libvoMMCCRRS.so
./libs/armeabi/libvoMMCCRRS_v7.so
./libs/armeabi/libvoTsParser.so
./libs/armeabi/libvoTsParser_v7.so
./libs/armeabi/libvoVidDec.so
./libs/armeabi/libvojni_svmobile.so
./libs/armeabi/libvojni_vome2_sw_v20.so
./libs/armeabi/libvojni_vome2_sw_v22.so
./libs/armeabi/libvojni_vome2_sw_v23.so
./libs/armeabi/libvojni_vome2_sw_v30.so
./libs/armeabi/libvojni_vome2_sw_v31.so
./libs/armeabi/libvompEngn.so
Android Project Classpath
To add Java JAR files to your Eclipse project, use the following steps:
Step 1 Right-click your project in Eclipse
Step 2 Select "Properties"
Step 3 Select "Java Build Properties"
Step 4 Select "Add JARs"
Step 5 Add each of the Java JAR files listed in Adding Java JAR Files in Eclipse14.
Figure 2-9 Adding Java JAR Files in Eclipse
Your "classpath" file should look like the following example:
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="src" path="src"/>
<classpathentry kind="src" path="gen"/>
<classpathentry kind="con" path="com.android.ide.eclipse.adt.ANDROID_FRAMEWORK"/>
<classpathentry kind="lib" path="libs/httpclient-4.1.1.jar"/>
<classpathentry kind="lib" path="libs/httpcore-4.1.jar"/>
<classpathentry kind="lib" path="libs/httpmime-4.1.1.jar"/>
<classpathentry kind="lib" path="libs/jackson-core-lgpl-1.8.1.jar"/>
<classpathentry kind="lib" path="libs/jackson-mapper-lgpl-1.8.1.jar"/>
<classpathentry kind="lib" path="libs/StadiumVisionMobile.jar"/>
<classpathentry kind="output" path="bin"/>
</classpath>
App Obfuscation Using ProGuard
If you choose to obfuscate your application with ProGuard, consider the following points:
•Use the latest version of ProGuard (which is version 4.7 as of August, 2012)
•If a crash takes place that you would like Cisco to analyze, please run retrace.jar on the stack trace output with your map file before sending us the un-winded stack trace file.
•Specify our libraries as input jars with "-libraryjars". See the example below and remember to modify the paths as needed:
-libraryjars ./libs/httpclient-4.1.1.jar -libraryjars ./libs/httpcore-4.1.jar -libraryjars ./libs/httpmime-4.1.1.jar -libraryjars ./libs/jackson-core-lgpl-1.8.1.jar -libraryjars ./libs/jackson-mapper-lgpl-1.8.1.jar -libraryjars ./libs/StadiumVisionMobile.jar -libraryjars ./libs/StadiumVisionMobileSender.jar
If you extend or implement any of our classes or interfaces please specify that in the config file,, as shown in the following example:
-keep public class * extends com.cisco.svm.data.ISVMDataObserver
Specify the following in the configuration file, to work with our JARS, as it prevents the StadiumVision Mobile JARS from being obfuscated: -keep public class com.xxxxxx.vome.* public protected private *; }
-keep public class com.cisco.** { public protected private *; } #for the Jackson library -keepattributes *Annotation*,EnclosingMethod -keepnames class org.codehaus.jackson.** { *; }
If ProGuard complains about "joda.org.time" and you have included the library as well as the configuration options above, you can ignore the warnings with the "-ignorewarnings" flag.
Cisco recommends not obfuscating all the classes that implement or extend the basic Android classes. The following ProGuard configuration is not meant to be a complete configuration, but rather a minimum:
-keep public class * extends android.app.Activity -keep public class * extends android.app.Application -keep public class * extends android.app.Service -keep public class * extends android.content.BroadcastReceiver -keep public class * extends android.content.ContentProvider -keep public class * extends android.app.backup.BackupAgentHelper -keep public class * extends android.preference.Preference -keep public class com.android.vending.licensing.ILicensingService -keepclasseswithmembernames class * { native <methods>; } -keepclasseswithmembers class * { public <init>(android.content.Context, android.util.AttributeSet); } -keepclasseswithmembers class * { public <init>(android.content.Context, android.util.AttributeSet, int); } -keepclassmembers class * extends android.app.Activity { public void *(android.view.View); } -keepclassmembers enum * { public static **[] values(); public static ** valueOf(java.lang.String); } -keep class * implements android.os.Parcelable { public static final android.os.Parcelable$Creator *; }
Channel ListView Activity Example
The following example illustrates the following actions:
•Periodically obtains the list of available video channels
•Updatse the Activity's ListView with the channel list
•Plays the video channel selected in the ListView
// set the click listener for the list view
channelListView.setOnItemClickListener(new OnItemClickListener() {
public void onItemClick(AdapterView<?> parentView, View clickedView,
int position, long id) {
// get the selected video channel
SVMChannel selectedChannel = videoChannels[position];
Log.d(TAG, "Selected Video Channel = '" + selectedChannel.name);
// get a reference the StadiumVision Mobile SDK
StadiumVisionMobile svm = StadiumVisionMobile.getInstance();
// play the selected video channel with custom video player
Intent intent = new Intent();
intent.putExtra("channel", selectedChannel);
intent.setClass(MyActivity.this, MyVideoPlayer.class);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
}
});