• TwitPic support – snap a photo with your phone’s camera or upload existing images
• Viewing retweets from people you follow
• Switched to using the new “Home Timeline” which includes proper retweet support
• A new “View Conversation” – shows a tree of tweets related to each other. Very useful for tracking long-running conversations
• Support for reporting users as spam, blocking and unblocking users
• The ability to completely disable screens you do not use – a great way to reduce clutter and lower memory usage

As per usual you can obtain this version in multiple ways;

• AppToDate users can check for updates through AppToDate and automatically install the newest version that way.
• By visiting http://get.twaddle.mobi on your Pocket PC’s browser
• Pocket PC installation – Run this file from your phone
• Desktop installation – Run this file from your Desktop. Twaddle will be installed next time you sync with that PC

Finally, if you have Microsoft Tag Reader (visit gettag.mobi on your phone’s browser) installed on your phone you can scan the tag below.

This is a major release so please report any problems you have to me via email (support@twaddle.mobi), via the comments section or on Twitter (@TwaddleWM).

Thanks for waiting!

First of all: Where does a developer place their plugins for Twaddle to pick them up? With 0.3 there’ll be a “Plugin” directory in the main Twaddle application directory. Developers should install their plugins into a subdirectory of the Plugins directory. Eg: \Program Files\Twaddle\Plugins\MichaelsCoolPlugin\. Any linked assemblies, resources, etc, should also sit within this directory. The only other point to mention here is that if you want your plugins to be loaded the filename must contain the string .Plugin. (Note the period at the start and end) as well as .dll. This way if the directory \Program Files\Twaddle\Plugins\MichaelsCoolPlugin\ contains the files Michael.Resources.dll, Michael.Plugin.dll and ThirdParty.Library.dll Twaddle would only attempt to load plugins from Michael.Plugin.dll. This helps to ensure start times for Twaddle are low.

Once Twaddle has found your assembly it will look through all of the public, non-abstract, non-interface types in your assembly and look at the interfaces they implement. There are several different interfaces you can implement which control the style of plugin you’re writing. The same class can implement multiple interfaces and there can be multiple plugins in the one assembly. Note that if your class does implement several plugin interfaces then one instance will be created for each plugin interface. So if you need to share data between the instances you’ll have to handle that yourself.

All of these interfaces (as well as many others Twaddle gives you) are defined in the Twaddle.Interface assembly (which I’ll distribute) and your plugin will need to link to. In addition all of the different interfaces are marked as implementing the Twaddle.Interface.IPlugin interface. This interface is an informational interface that tells Twaddle about your plugin (some of which is then displayed to the end user). The definition of IPlugin is as follows:

public interface IPlugin {
    /// <summary>
    /// A Unique identifier that will remain consistent regardless of locale, build, etc.
    /// </summary>
    string Id { get; }

    /// <summary>
    /// The short name for this plugin
    /// <example>Public Timeline</example>
    /// </summary>
    string Name { get; }

    /// <summary>
    /// A longer descriptor of the plugin
    /// <example>The Public Timeline plugin updates and displays the current user's timline</example>
    /// </summary>
    string Description { get; }

    IPluginConfiguration Configuration(IAppSettings settings);

    /// <summary>
    /// A rough indication of the amount of network data this plugin uses
    /// </summary>
    UsageAmount Data { get; }

    /// <summary>
    /// A rough indication of the amount of memory this plugin uses
    /// </summary>
    UsageAmount Memory { get; }

    /// <summary>
    /// A rough indication of the amount of processor this plugin uses
    /// </summary>
    UsageAmount CPU { get; }

    /// <summary>
    /// A rough indication of the amount of battery this plugin uses
    /// </summary>
    UsageAmount Battery { get; }

    /// <summary>
    /// A rough indication of the amount of disk space this plugin uses
    /// </summary>
    UsageAmount Storage { get; }
};

The Id property should be a unique value for your plugin as it’s used to store user settings. A good candidate would be a pre-generated guid constant (ie return “21EC2020-3AEA-1069-A2DD-08002B30309D” instead of doing return Guid.NewGuid().ToString() or the namespace of your plugin (“Michael.CoolPlugin.SomeSnazzyEventResponderPlugin”. The Name property is displayed to the user when configuring your plugin whilst the Description property is used to tell the user a little bit more about your plugin.

The UsageAmount returning properties (Storage, Battery, etc) are intended as a rough guide to the User so they can make an informed decision as to if they want to leave your plugin enabled or not. The values are None, Inconsequential, Low, Medium, and High. As an example a video uploading plugin would likely have a High Storage and Data value (as they save and upload video files). A picture uploading plugin would probably be Medium Storage and Medium Data. A plugin that pings your server once an hour might have a Data value of Inconsequential. Whilst one that has no network connectivity would be None.

I’m going to skip the Configuration() method because it would comprise its whole own post. But if your plugin has no configuration at all you can return null from this method.

Of course these IPlugins don’t describe much on their own. The interfaces you’d actually be implementing are ITaskPlugin, IFormControlPlugin, IEventResponderPlugin, IMenuPlugin, IPendingItemProcessorPlugin,IPostFormControlPlugin and ISendMessageFormControlPlugin. The final two may get merged before 0.3 (I haven’t decided yet). Hopefully the name of these interfaces should give you some indication of what they do, but I’ll give more details in a future post.

Before I finish up here there is one more interface a plugin developer will need to be familiar with. IDependencyResolver. This is defined as:

public interface IDependencyResolver {
    TDependency Resolve<TDependency>() where TDependency : IDependency;
    TDependency Resolve<TDependency>(string name) where TDependency : IDependency;
}

IDependency is a marker interface used to give compile-time checking over what interfaces defined in Twaddle.Interface are obtained through the IDependencyResolver. This is because some are implemented by the developer and others are passed into methods that different plugins use. All plugin types are given an IDependencyResolver at instantiation and they should maintain a reference to this object. The instance given is different between each plugin instance (as there’s different types returned for some of the dependencies, or instance-specific information returned).

Lets say that you’re implementing a new screen in Twaddle and want to get a list of actions applicable to a tweet (something that other developers can provide by creating IMenuPlugin implementations). How would you do this? Well, there’s an interface IMenuItemFactory which can take a tweet as an argument and return a list of MenuItem’s for you to display in your interface. Sample code might look like:

private void DisplayMenuItems(IDependencyResolver resolver, IStatus selectedTweet) {
  IMenuItemFactory factory = resolver.Resolve<IMenuItemFactory>();
  ICollection<MenuItem> menu = factory.Items(selectedTweet);

  // Now add the items in menu to your on screen menu, or some such.
}

I think that should be enough of a brief introduction for now – I’ll start writing an posts describing each of the plugin interfaces in turn. I’ve put a poll up for you to vote on which you’re most interested in learning more about.

OAuth Echo support – in conjunction with the new extensible architecture of Twaddle – means that over the course of a few hours I was able to provide TwitPic support within Twaddle. This support allows you to take a new picture with your phone’s camera (for devices with cameras) or to use an existing photo, both with preview support.

Image Upload – Take a new photo or upload a file

Image Upload – Selecting an image

Image Upload – Preview the image

Beginning the XAuth process

Finalising the XAuth process

“But isn’t this going back to username / password combinations which is insecure?” you may ask. Well, no, not really. The username / password combination is sent over a secure channel only once (at the time you fill out this form). Twitter verifies this and then sends back a token which is used for all subsequent requests. This is in fact identical to the OAuth process used in earlier versions the difference is how that token is acquired.

All you really need to know is that signing up with Twaddle is now pain free! Hooray!

A couple of things have caused the delay of the latest version: Firstly my Real Job™ I was the Technical Lead on a very large project (since released successfully) which took up a lot of my time and motivation. I have also handed in my resignation and am currently looking for a new job. The upside of this is I’ll be taking a few weeks off before starting a new job. Time which I plan to devote to playing video games / coding Twaddle.

Secondly the announcement of Windows Phone 7, and what it means for developers of Windows Mobile apps, was a bit disheartening.

Thirdly: I’ve worked on a lot of the internals of Twaddle. This working means that third party developers will be able to write plugins for Twaddle. Don’t like the way it does notifications? Write your own! Want Twaddle to automatically hash tag things? Write a plugin! And so on, and so forth. This affects every aspect of Twaddle (The User Interface, background tasks, response to other events, etc) and required a fair amount of thought and tweaking. It also turned out to be a much bigger task than I’d initially anticipated. As to if any third party developers start writing plugins for Twaddle remains to be seen. But even if they don’t it will allow much quicker development of features for Twaddle, providing they fit within the existing model. I’ll release more technical details of this closer to the release date of 0.3 / if people are interested.

In the mean time, I apologise for the delay, but hope the delay will result in something everyone is really excited by.

0.3 Preview – Threaded Conversations

Here we can see a conversation I held between my personal account and the @TwaddleWM account. You may notice a very subtle tree structure of the list – this is to indicate the hierarchy of the conversation. This view only works when statuses are properly tagged as replies to another status (which Twaddle and the Twitter website do, but some clients seem to do less reliably). I’m so far finding this feature really useful to manage long running conversations throughout the day (and you can sometimes find some great new people to follow as a result!). This interface can be brought up from any of the other views within Twaddle and allows you to interact with the tweets just like they were in your normal timeline. Expect the interface and how this is rendered to change before the final 0.3 release – this is after all just a preview! If you have any suggestions on improving the layout, I’d love to hear them.

Also, don’t forget to take part in the poll on the right hand side – it’s a great way for you to voice your views on what feature you desperately want included in 0.3 !