Integrating custom mobile content into an existing solution is a straight forward process that is more about planning than code writing. Using the SDK, a developer can deploy a full ringtone store with a single Flash embed tag or build their own ringtone editor using their own billing and delivery mechanism. This section introduces some of the design considerations that help scope the implementation process.

Custom mobile content solutions imply the end user is creating an item from source material. The source material typically is one of 3 types: content the end user owns, content the host application owns, and content the host application licenses. All 3 types are just source files to the platform, but require different mechanisms to transfer them to Phone Sherpa’s servers (see File Upload and Flow for details).

Elements of the SDK that help perform the file transfer of source content are:

1. Flash Editor Client – has modes enabling end user file selection and upload. Also can sideload files from a host URL into the Phone Sherpa system.
2. LoadFileFromURL(…) – asks Phone Sherpa to sideload a file via HTTP GET from a public URL. Content is cached so that requests to sideload the same file use the internal copy (flush after 24 hours of non use). Programmatic file transfer hides the location of the source material from the end user and enables secure access by only Phone Sherpa servers.
3. GetPostFileInfo(…) – returns a URL in which to HTTP form POST a file to and gives the internal source file name to pass to that page.

Phone Sherpa provides a simple yet flexible Flash editor client enabling users to select the portion of an audio file to be a ringtone. All color elements of the component can be modified to match the host UI environment. It has the ability to transition back into the host’s page flow upon the user selecting “Continue” within the editor. It is recommended that integrators use this component. That said, some developers may want to create their own look and feel for their audio editor UI. The platform SDK provides API’s to help build a custom editor UI.

Elements of the SDK that help perform UI editing of source content are:

1. Flash Editor Client – allows the user to select the clip they want to be a ringtone. Passes that information back to the host for further processing.
2. GetRingtoneEditorFiles(…) – generates support files for building a custom editor UI, such as playback audio stream and waveform images.

Once the portion of the source content has been selected by the end user, the clip needs to be generated and converted into the proper format for the user’s phone model. There are several options at this point. If the Flash editor is used in conjunction with the Flash billing component, conversion and delivery of the content is handled automatically. If the host wants to do their own billing and/or delivery, then the developer needs to programmatically convert the audio clip into the target format.

Phone Sherpa maintains a database of 1500+ phone models with their supported content formats. Gathering the user’s phone model from host stored account information or by asking the user explicitly via a form, enables Phone Sherpa to convert clips to the best quality and format for the selected phone model. If the host already knows the target audio codec, they can use the Phone Sherpa API to create a clip in that codec in an explicit manner.

Elements of the SDK that help perform the content conversion into phone model formats:

1. Flash Billing Component – if used, the billing component collects user information, phone information, converts the content into the proper format, and delivers the content to the user’s phone automatically.
2. EditAudioContentForPhone(…) – cuts and converts an audio file into a new clip for use on a particular phone model.
3. EditAudioContent(…) – the generic version of EditAudioContentForPhone allowing developer to specify the exact audio codec to use.

If the host application is using the Phone Sherpa Platform to deliver the content to the end user’s phone, information about their phone number, carrier, and phone model are required by the APIs. This information can come from the host’s notion of a user account (gather from other uses) or explicitly asked of the user for the purpose of delivering mobile content.

In either situation, it’s up to the host application to map the enumeration values for carrier, country, and phone model into those that the platform API recognizes. Elements of the SDK that help the gathering of user phone delivery information are:

1. Flash Billing Component – if used, the billing component collects user information, phone information, converts the content into the proper format, and delivers the content to the user’s phone automatically.
2. GetCountryList(…) – gets a list of countries supported by the platform.
3. GetCarrierList(…) – gets a list of carriers supported by the platform.
4. GetStateProvinceList(…) – gets a list of states, only required for billing API’s.
5. GetPhoneModelList(…) – gets a list of phone models supported by the platform.
6. ValidatePhoneNumber(…) – validates and formats a user phone number for use with API methods that request a phone number.
7. ValidateUserPhoneInformation(…) – validates and formats a user phone information construct, including carrier, country, phone number, and optional email address. Used by many API calls in the platform.

It is common for a custom mobile content solution to charge the user for the service. Phone Sherpa provides a Flash billing component that will charge a user’s credit card or phone bill (if supported by carrier) and then revenue share this with the host. The host can set the price and Phone Sherpa does the rest. The billing component is robust, secure, and easy to deploy.

That said, billing is the most overridden function by host integrators of the SDK. Monthly ringtone subscriptions, ringtone bundles, shopping cart integration with other products, and promotional giveaways are all examples of host application behavior that one can integrate custom content creation into. It is up to the developer in these cases to bill, charge, credit, or give away content as they see fit. Phone Sherpa acts purely as a delivery and editing system.

An important consideration when billing a user for mobile content is validating that the user has the proper data plan to receive mobile content. The main point of customer failure to receive content is that they do not have an active data plan to receive mobile content. Providing a button or similar UI mechanism for user's to test thier phone before purchasing content is a great way to reduce customer service requests for non-delivery or non-compatible phones.

Elements of the SDK that bill the end user for content delivery:

1. Flash Billing Component – if used, the billing component collects user information, phone information, converts the content into the proper format, and delivers the content to the user’s phone automatically.
2. SendTestToPhone(…) – Delivers a test ringtone or wallpaper to a user's phone via SMS/WAP/MMS. Validates user has properly configured phone and the appropriate data plan to receive mobile content.

Once the content has been edited for a particular user’s handset, they need to get the file onto their phone. The Flash billing component automatically publishes delivers content to the user’s handset. Developers may choose to programmatically publish and/or deliver the content using the platform APIs. Publishing files moves them into a public URL space for pickup, applies OMA 2.0 forward locking (if supported by the phone), and performs any carrier specific modifications to the content such as GDC or similar wrappers. Published files are in essence ready to be downloaded into a user’s phone and are hosted by Phone Sherpa’s servers for 24 hours in a public URL space.

Alternatively, the developer may choose to host the files on their own website and/or use their own delivery mechanism. PublishContent(…) provides the developer access to download ready files and ResolveContentHandle(…) provides access to the raw converted files without the extra steps PublishContent(…) performs.

Elements of the SDK that help the publishing files for download are:

1. Flash Billing Component – if used, the billing component collects user information, phone information, converts the content into the proper format, and delivers the content to the user’s phone automatically.
2. PublishContent(…) – DRM forward locks, moves files into a public URL space, and wraps them with carrier specific meta data (where appropriate). Does not sent any notifications to the user’s handset.
3. ResolveContentHandle(…) – takes any internal source file and makes it available for sideloading via a public URL. Integrator can then do whatever they need to with the file.

The Phone Sherpa Platform has programmatic and end user client facilities (via the Flash billing component) to deliver content to the end user. If using the billing component, delivery is automatic. If host is doing its own billing, then they must either leverage the API delivery mechanism or use their own phone connectivity to deliver content to the end user. In the case of the host using its own connectivity, they need to use ResolveContentHandle(…) to extract the created content from the Phone Sherpa system into their own application.

Elements of the SDK that help the delivering files to the end user phone are:

1. Flash Billing Component – if used, the billing component collects user information, phone information, converts the content into the proper format, and delivers the content to the user’s phone automatically.
2. SendContentToPhone(…) – takes an internal source file, publishes it, and sends a message to the user’s phone enabling download of the content.
3. ResolveContentHandle(…) – takes any internal source file and makes it available for sideloading via a public URL. Integrator can then do whatever they need to with the file.