Archive for the ‘C#’ Category

LA .NET Hackathon 2011

Monday, December 5th, 2011

Tropo is partnering with the LA .NET Developers Group and Outlook Amusements to sponsor this weekend’s LA (Burbank) Hackathon at Outlook Amusements on Saturday, December 10, 2011 from 9:00 AM to 6:30 PM (PT).

Here’s the address: Outlook Amusements 2900 W. Alameda Ave suite 400 Burbank, CA 91505

The theme of the LA Hackathon is “Build Voice/SMS apps for Holidays”! Here are a few ideas to get you thinking:

  • Santa Caller (similar to http://santacall.us) – Build a website that allows a parent to schedule a call to their kids from Santa. Have Santa ask the kid what they would like for Christmas and then email the parents their kid’s recorded message and/or transcribe the message for the email.
  • Santa Tag (similar to http://www.bloggingbistro.com/jc-penney-comes-up-with-a-new-use-for-qr-codes-video/) – Build a website that calls someone to record a message then associates the message with a QR code that plays when scanned.
  • Holiday Greetings Hotline – Build a holiday greetings hot line where user can leave a voice message that will be transcribed into text and posted to “Holiday Greetings” twitter account.

Even though this event is sponsored by the .NET Developers Group, we will be supporting all development languages and will have Tropo expertise onsite in .NET, PHP, Ruby/Rails, and Javascript, and Node.JS!

Register today!

Sending Outbound SMS with C#

Thursday, April 14th, 2011

This post is a follow up to one done previously demonstrating how to use the C# library for the Tropo WebAPI to send outbound SMS messages.

We’ll walk through the process of setting up a Tropo account, loading in the start URL for your application and invoking the Tropo Session API to send a message.

The first thing you’ll need to do, is get the Tropo C# library – follow the instructions in the previous post for cloning the GitHub repo for this library. If you’d rather not use Git, you can simply download the ZIP file and extract the contents to a convenient location.

Either way, once you get this source for the library, fire up Visual Studio and follow the instructions for obtaining project dependencies and successfully building the solution.

Setting up Your Application

In order to send outbound SMS messages, you will need two things:

  1. A “starter” component that will initiate outbound messages by invoking the Tropo Session API and include any information needed to compose a message to an end user. (This component could be a Windows service, a WCF application, etc. The only requirement is that it must be able to make an HTTP request to the Tropo Session API.) Note – do not set this starter component as the start URL for your application.
  2. A “catcher” component that will use information submitted with your API request to compose the text of an outbound message and instruct the Tropo platform to send it. This component must return valid JSON to the Tropo platform in response to an HTTP POST.

Our “catcher” application for this example will be a simple ASP.NET page – it’s included in the Tropo Samples project within the Tropo C# library solution, called OutboundSMS.aspx. If you look at the code behind for this page, you’ll see that it uses the Tropo Session object to get parameters that are submitted by Tropo. These parameters are sent to Tropo by your “starter” application – we’ll get to that in a moment.

Note that the exception handlers in this example will attempt to write an entry into the event viewer using a log source of “TROPOWEBAPI”. You can use entries in your event viewer to help you debug problems that you might be having as you develop your Tropo application.

This “catcher” app needs to be in a location that can be accessed by the Tropo platform. Tropo will make an HTTP request (using the POST method) for this script, sending along a JSON payload. the structure of this payload can be seen here. In addition, any parameters that you use when invoking the Tropo Session API will be included in this JSON payload.

You can stage this ASP.NET application on a public server, on a hosting platform like AppHarbor, or on your lcoal development machine (if you have set up a way for external HTTP requests to be received, i.e., with Tunnlr). Once you’ve done this, log into your Tropo Account and create a new WebAPI application.

Enter the URL for your ASP.NET application in the Start URL field. Click “Create Application” to create your application and view settings.

Create a new Tropo WebAPI Application

Make note of the voice and messaging tokens provisioned for your application. We’ll need those in the next step.

Also, make sure you provision a phone number for your application – applications without a provisioned phone number will not be able to send outbound SMS messages.

For the purposes of this post, our “starter” application (which will be used to invoke the Tropo Session API) will be a simple console application. The code for this example is in the TropoOutboundSMS project in the Tropo C# library solution.

The code for this console application looks like this.

using System;
using System.Collections.Generic;
using System.Web;
using System.Xml;
using TropoCSharp.Structs;
using TropoCSharp.Tropo;

namespace OutboundTest
{
    class Program
    {
        static void Main(string[] args)
        {
            // The voice and messaging tokens provisioned when your Tropo application is set up.
            string voiceToken = "your-voice-token-here";
            string messagingToken = "your-messaging-token-here";

            // A collection to hold the parameters we want to send to the Tropo Session API.
            IDictionary<string, string> parameters = new Dictionary<String, String>();

            // Enter a phone number to send a call or SMS message to here.
            parameters.Add("sendToNumber", "15551112222");

            // Enter a phone number to use as the caller ID.
            parameters.Add("sendFromNumber", "15551113333");

            // Select the channel you want to use via the Channel struct.
            string channel = Channel.Text;
            parameters.Add("channel", channel);

            string network = Network.SMS;
            parameters.Add("network", network);

            // Message is sent as a query string parameter, make sure it is properly encoded.
            parameters.Add("msg", HttpUtility.UrlEncode("This is a test message from C#."));

            // Instantiate a new instance of the Tropo object.
            Tropo tropo = new Tropo();

            // Create an XML doc to hold the response from the Tropo Session API.
            XmlDocument doc = new XmlDocument();

            // Set the token to use.
            string token = channel == Channel.Text ? messagingToken : voiceToken;

            // Load the XML document with the return value of the CreateSession() method call.
            doc.Load(tropo.CreateSession(token, parameters));

            // Display the results in the console.
            Console.WriteLine("Result: " + doc.SelectSingleNode("session/success").InnerText.ToUpper());
            Console.WriteLine("Token: " + doc.SelectSingleNode("session/token").InnerText);
            Console.Read();
        }
    }
}

Sending SMS Messages

You’ll want to replace the default values in the above script with the voice and messaging tokens provisioned for your application in the last step. You’ll also want to replace the values for sendToNumber (the number where the SMS message will be sent) and the sendFromNumber (the caller ID that will be used for the outbound SMS).

An important note – the value of sendFromNumber must be the same as a phone number provisioned for your application in your account settings. Otherwise, your SMS message may be dropped. Carriers have very specific rules regarding caller ID settings on outbound SMS messages, and unless the caller ID on the messages match the number set up in your account the message will not be delivered properly.

Once you have made these changes, just run the console application (Program.cs). The easiest way to do this is to make the TropoOutboundSMS project the startup project for your solution. Simply right mouse click on the project and select “Set as Startup Project”‘. Once this is done, you can hit F5 to run it.

That’s it!

If you run into issues, there are two places you can look for information – first, have a look in the event viewer on the host running your ASP.NET web app. (Remember, we’re logging information there when exceptions get thrown.)

You can also open the real time Application Debugger in your Tropo account when you run your console application. This will display any errors or exceptions and allow you to identify something that might have gone wrong.

Because the Tropo C# library for WebAPI is housed on GitHub, it can be forked, modified and customized to your needs.

If you have some ideas for changes or modifications that you’d like to see, let us know or simply fork the repo and have at it!

Using C# to Send Outbound Calls and SMS Messages

Monday, November 8th, 2010

“Choices are the hinges of destiny” — Pythagoras

From a developer’s perspective, one of the most attractive things about the Tropo platform is the array of choices it provides. Choice can empower developers.

In addition to supporting two different methods for running Tropo applications – Tropo Scripting and Tropo WebAPI – developers can use a wide variety of languages to build Tropo applications. Tropo scripting applications can be written in JavaSctipt, PHP, Ruby, Python or Groovy. The Tropo WebAPI lets developers write applications in any language that can parse JSON and speaks HTTP.

A number of libraries exist to assist developers in building WebAPI applications and also for interacting with the Tropo Session API – which lets developers initiate outbound messages over several different channels.

If you are a C# developer, one of the easiest ways to move into developing Tropo applications is to use the Tropo C# library. And while this library is currently focused on building Tropo WebAPI applications, it can also be used to interact with the Tropo Session API to initiate outbound telephone calls and SMS messages.

This post will introduce C# developers to the Tropo C# library and walk through a simple example of using C# to send outbound calls and SMS messages. To keep things simple, we’ll use a very simple Tropo scripting application written in JavaScript. (more…)

Calling all C# developers! Now YOU can build voice, SMS, IM, Twitter apps with Tropo!

Tuesday, September 28th, 2010

csharp.jpgDo you develop your applications in C#? Are you looking for a way to bring voice, SMS, IM app development into the Windows world? Would you like to write automated agents for Twitter using Microsoft tools?

If so, we’re very pleased to let you know that we now have a C# library for Tropo! You can see the source code and download it for yourself at:

http://github.com/tropo/tropo-webapi-csharp

Developed by Tropo community member Mark Headd, who also developed the PHP library for Tropo, this C# library makes it easy to use the Tropo Web API to add voice, text messaging, IM or Twitter connectivity to your C# apps.

Sample code is available at:

http://github.com/tropo/tropo-webapi-csharp/tree/master/TropoSample/

Mark is continuing to work on the library and welcomes any and all feedback on it. If you are a Github user, feel free to fork the repo and make changes in your copy. You can also raise issues at:

http://github.com/tropo/tropo-webapi-csharp/issues

We’re delighted to make it easier for C# users to more easily build Tropo apps – and stay tuned for some more blog posts and tutorials in the future.

P.S. To use the library, you do need a free Tropo developer account if you don’t already have one. The Tropo Web API documentation also explains how to get started.

New Guidelines for Naming Tropo Web API Language Libraries (ruby, PHP, python, C#)

Tuesday, August 31st, 2010

UPDATE, Sept 3, 2010:After some discussion, the consensus is to make the language library naming even a bit easier for developers and move the module names from “tropo-webapi” to simply “tropo”. The table below has been updated to show the change.


With the availability of the Tropo Web API, it’s been great to see the development of Tropo libraries for various programming languages, which let developers easily and quickly build Tropo apps for voice and SMS.  We now have Tropo Web API libraries available for Ruby, PHP, Python and C#:

http://github.com/tropo

However, as those libraries have evolved, we’ve found that they’ve developed in slightly different directions with regard to the naming of the repository on Github and to the module names, etc.  We gave some thought to the best way to provide guidance to make it easier on developers, and came up with these goals:

  • Provide a consistent repo name so developers using multiple languages can easily locate their downloaded/cloned directories on their local systems.
  • Provide consistent naming of module/library names and function/class names so developers can move with ease from one language to another. (Use case: a developer builds a Ruby app for one client for Tropo. Developer then needs to build a PHP app for another client. Developer should be able to move from one Tropo library to another without having to relearn or guess what the names are.)
  • Allow for the future creation of additional Tropo-related modules/libraries

To get there, the existing repositories are going to migrate to these new names:

  • http://github.com/tropo/tropo-webapi-ruby
  • http://github.com/tropo/tropo-webapi-php
  • http://github.com/tropo/tropo-webapi-python
  • http://github.com/tropo/tropo-webapi-ruby

Going forward, we’ll ask that anyone creating a new Tropo Web API module please follow this same naming convention.

We’re also going to move the names of the actual modules to be more consistent. The result will be something like:

Ruby require ‘tropo-webapi-ruby’
require ‘tropo’
PHP require ‘tropo-webapi.class.php’;
require ‘tropo.class.php’;
python import tropo_webapi
import tropo
C# using TropoCSharp.TropoWebAPI;
using TropoCSharp.Tropo;

You’ll note that we’re treating “webapi” as one word in the names. (Note: These may be the final names, but they may change as the changes get made to each library.)

We’re in the process of working with the library authors to make these changes now.  The migration is a pain, quite honestly, because it’s going to break existing applications, samples, tests, etc., but we want to do this once so as these modules start to get more widely used, there is a good degree of consistency between them.

We’ll let you know as the libraries are moved over to the new convention – and please let us know now if you have any feedback on this issue.

Thanks – and we’re definitely looking forward to continuing to see the awesome apps you all are building with Tropo!