Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Twitterizer is a .NET class library that provides an easy-to-use interface for the Twitter web api. It is written for developers. It's features are easy to discover and follow a consistent design pattern.
branch: develop
Failed to load latest commit information.
ExampleApplications Upgrade all projects to use .net framework 4 or the client profile as…
Twitterizer.OAuth Fixed xml documentation errors. Removed unused assemblie references.
Twitterizer2.Async.Silverlight Fixed xml documentation errors. Removed unused assemblie references.
Twitterizer2.Async Merge branch 'master' of https://github.com/blooksa/Twitterizer into …
Twitterizer2.Data Upgrade all projects to use .net framework 4 or the client profile as…
Twitterizer2.Silverlight Fixed xml documentation errors. Removed unused assemblie references.
Twitterizer2.Streaming.Silverlight Fixed xml documentation errors. Removed unused assemblie references.
Twitterizer2.Streaming Added proxy support to streaming APIs
Twitterizer2.TestCases Merge pull request #52 from sconno05/develop
Twitterizer2 Core(TwitterCommand): avoid calling Encoding.UTF8.GetString() twice
Twitterizer2lite Removed reference to nuget target from project files.
XML Documentation Start of documentation for mono usage.
lib Changes for a nuget update.
packages Update Json.4.5.7
.gitignore Supersized gitignore
CommonAssemblyInfo.cs Changes for a nuget update.
CustomDictionary.xml
GettingStarted.txt Fixing invalid endpoint values in list command classes.
Json.NET.license.txt
NugetPackage.bat Prepping changes for nuget update.
NugetPublish.bat Prepping changes for nuget update.
PackageReleases.bat Re-included entities in the timelines.
Packages.dgml Nuget fixes for externals for each project and source files so projec…
README.md Update README.md
Twitterizer2.license.txt
Twitterizer2.nunit Changed CommandPerformer so that it isn't generic, but the PerformAct…
Twitterizer2.shfbproj Fixes 88 (Thanks Ian)
Twitterizer2.sln Modifications to the solution file. The release driectory will now lo…
twitterizer.FxCop
twitterizer.nuspec Changes for a nuget update.

README.md

Twitterizer

Example

var response = TwitterStatus.Update(credentials, "Twitterizer is fantastic!");
if (response.Result == Success)
{
    DisplaySuccessMessageFor(response.ResponseObject);
}
else
{
    DisplayErrorMessage(response.ErrorMessage);
}



var myFeed = TwitterTimeline.HomeTimeline(credentials);

History

Twitterizer started in May of 2008 as an excuse for me to explore design patterns, have a little fun coding, and stretch out my architectural legs. I never set out to create an open source library, much less a popular one (in the last 30 days of its life, Twitterizer.net pulled 8,560 unique visitors and nearly 52k views).

In 2009 the [https://github.com/meebey/smuxi Smuxi] project made use of the Twitterizer library to support Twitter as a built-in feature in their popular IRC client. As of 2013 Twitterizer is part of the Smuxi project umbrella and thus actively maintained. In August 2012 Smuxi ported Twitterizer to Newtonson.Json 4.5.8, in August 2013 Twitterizer was ported to the Twitter v1.1 API, in November 2013 proxy support was added to the Streaming API, and in Janary 2014 Twitterizer was ported to enforced HTTPS.

Plans for the future

Version 2.4.3

The next minor version will contain only high priority bug fixes while Version 3 is in development.

Version 3

  1. Drop support of Silverlight (unless developers come forward to own it)
  2. Twitterizer project to be async-only using the TPL
  3. Drop Twitterizer.OAuth library (let's face it, it's not a very great product) and, in fact:
  4. Evaluate relying upon an external OAuth library (DotNetOpenAuth, for example)
  5. Sync command classes and objects with Twitter's 1.1 documentation
  6. Redesign unit tests; properly mock objects and run tests using static json data
  7. Establish continuous deployment to Nuget

Contribute

  1. Create or claim an issue
  2. Fork the repository
  3. Create a branch named appropriately for the issue (based on the develop branch)
  4. Make happy code
  5. Submit a pull request to merge your changes to the develop branch
  6. Watch for comments or questions about your changes

Branch Naming

From now on, all work will be performed in feature or bug branches. The will follow this pattern: /-.

For example, say I was working on issue #63, the branch would be called bug/63-fix-unit-tests

Something went wrong with that request. Please try again.