In a simple client-server architecture a service is typically capable of handling everything that is required to handle a command issued but in systems designed with a distributed architecture (to address various needs) a command issued may require several services on several systems to complete the work. These processes can be long lived elapsing minutes, hours or even days. Some domains may even include manual steps combined with the electronic processing.

For example a website with the ability to sell merchandise to customers may have orders submitted to an order service but the billing, shipping and emailing responsibilities are distributed.

The saga pattern was created as a way to coordinate these distributed long living asynchronous activities. A saga is a set of relatively independent transactions. Transactions can execute on multiple systems in sequential order, in parallel or combination of both. Sagas orchestrate the state changes as transactions return successful or faulted.

When one of the transactions returns successful in a saga with a series of sequential transactions the saga executes the next transaction. Each transaction could potentially execute on entirely different systems. When all transactions have returned successful the saga is considered completed.

Keep in mind the use of the word transaction in this post does not imply a database transaction. Transactions in a saga could represent any kind of processing the saga needs to coordinate. I flip flopped whether I should use the word transaction but since all the originating material around sagas uses this terminology I decided to stay consistent.

Sagas fit really well within systems designed with an event-driven architecture. The saga can subscribe to events and handle state changes when the events get published. The saga can issue commands as a result of the events (which in turn could generate more events).

Sagas use the correlation messaging pattern to match events related to the saga instance. The correlation pattern is one of the most fundamental messaging patterns. Correlation is used to track state since executing asynchronous processes we can’t rely on a call stack to have the state needed.

Faults

Sagas can handle both transaction failures and system faults. If a transaction returns failed the saga executes compensating actions to undo the changes. Distributed transactions seen in relational databases (SQL Server, Oracle, etc.) have similar abilities to roll back when faulted but if processing is long lived and spans several databases it’s not feasible to do a distributed transaction and lock data on multiple databases for minutes, hours or days. Another thing to consider is some processing may not occur on a technology that supports the concept of transactions which means compensating actions must occur within your application architecture.

Distributed transactions still have uses. If the saga or portions of the saga are short lived, a distributed transaction may make sense for rolling back some of the state. Sagas give you the ability to choose to issue compensating actions when distributed transactions don’t make sense.

If there is a need to retry when a saga has failed one approach to solve this is to nest sagas. The retrying workflow can be coordinated within the parent saga to handle when the nested saga fails. This allows the option to retry the transactions in the nested saga on another system than the one that originally faulted.

The example of the ProcessOrder saga shown below is a sequential saga. Compensating actions are created for each transaction in the workflow. If billing the customer fails both the BillOrder and SubmitOrder compensating actions execute to undo the changes.

Persisting saga state

Handling system faults is also important. Persisting saga state during any state change to some storage allows the system that has crashed to recover when it returns to availability. Reloading the state of the saga and begin processing un-processed messages (commands/events) allows the saga to resume where it left off. Both saga state persistence and reliable messaging is important for recovery. If the billing service publishes an OrderBilled success event while the order service is down it’s important the saga on the order service can resume when the service is available again to continue the workflow and issue the ShipOrder command to the shipping service. To do this when order service is back on line it should reload all sagas not completed from the persisted storage and since events will be waiting in the reliable message queue it can then process the unprocessed events.

Example

There are many different ways to implement a saga and for the purpose of this post I’ll be using a saga example that is inspired from NServiceBus for handling a sequential ordering process.

The saga needs a class to store data that will get persisted (document or relational database?) to allow the saga to resume even if the service is restarted or in the worst case crashes.

public class ProcessOrderSagaData : ISagaEntity
{
    public virtual Guid Id { get; set; }
    public virtual string Originator { get; set; }
    public virtual Guid OrderId { get; set; }
    public virtual Guid CustomerId { get; set; }
    public virtual List<Guid> ProductIdsInOrder { get; set; }
    public virtual bool CustomerHasBeenBilled { get; set; }
}

Now that we have a class to store the state for our saga we can create the saga itself.

public class ProcessOrderSaga :
    Saga<ProcessOrderSagaData>,
    ISagaStartedBy<OrderAccepted>,
    ISagaStartedBy<AcceptOrderFailed>,
    IHandleMessages<CustomerBilledForOrder>
{
    public void Handle(OrderAccepted message)
    {
        this.Data.ProductIdsInOrder =
            message.ProductIdsInOrder;

        this.Data.CustomerId = message.CustomerId;
        this.Data.OrderId = message.OrderId;

        this.Bus.Send<BillCustomerForOrder>(
            (m =>
            {
                    m.CustomerId = this.Data.CustomerId;
                    m.OrderId = this.Data.OrderId;
            }));
    }

    public void Handle(AcceptOrderFailed message)
    {
        this.Bus.Send<CancelCustomerOrder>(
            (m =>
            {
                m.OrderId = this.Data.OrderId;
            }));
    }

    public void Handle(CustomerBilledForOrder message)
    {
        this.Data.CustomerHasBeenBilled = true;

        this.Data.CustomerId = message.CustomerId;
        this.Data.OrderId = message.OrderId;

        this.CompleteIfPossible();
    }

    private void CompleteIfPossible()
    {
        if (this.Data.ProductIdsInOrder != null &&
            this.Data.CustomerHasBeenBilled)
        {
            this.Bus.Send<ShipOrderToCustomer>(
                (m =>
                {
                    m.CustomerId = this.Data.CustomerId;
                    m.OrderId = this.Data.OrderId;

                    m.ProductIdsInOrder =
                        this.Data.ProductIdsInOrder;
                }
                ));
            this.MarkAsComplete();
        }
    }
}

The ISagaStartedBy<T> interface provides a mechanism for NServiceBus to detect when this saga should be created and started. When an event of type OrderAccepted or AcceptOrderFailed  is received the saga will begin. The saga would be subscribed to handle the events you see in the Handle() methods. If the AcceptOrderFailed event is published from the order service the saga will issue the CancelCustomerOrder command. I didn’t implement all the compensating actions in the example but similar compensating commands would exist for the other failure events.

Other uses

The saga pattern was designed for executing long living processes that execute transactions on distributed systems but the pattern itself is very helpful for more than just those situations. The saga pattern gives the developer ability to use an elegant API even when some of the needs from the original intent of the saga pattern aren’t desired (fault tolerance, distribution, long living). Composite applications that use an event aggregator for messaging within the same process between decoupled components have similar needs as distributed systems that communicate with messaging.

I could be convinced the name saga doesn’t make sense for some of these uses but the fact is the saga classes available in various libraries are still useful in situations beyond the original intent of long-living transactions.

Look out for more posts on sagas. I plan to show more examples and scenarios that I have found them useful.

Conclusion

Sagas allow us to coordinate complex asynchronous workflows that potentially process on distributed services. Event-driven architecture helps build a nice publish/subscribe communication for the saga. Compensating actions allow us to undo any changes we need to undo when any of the processing fails and persisting saga state allows us to be fault tolerant and support long living processes.

I was looking at a change set on a source repository to learn how something was implemented and realized a bulk of the change set was changing an identifier field from an int to a string. I’m not going to go into the details why but this is a simple refactoring exercise. The alarming thing was how much code was affected by changing only one thing. We’ve all done refactoring like this where a data type doesn’t suite our needs in a later iteration right?

What came to mind for me in this instance was Domain Driven Design’s Value Object (don’t confuse it with the CLR’s Value Type). A good description for the people who haven’t read about DDD yet is: "An object that represents a descriptive aspect of the domain with no conceptual identity is called a VALUE OBJECT." [Evans 2003]

A Value Object isn’t something that would represent for example a user in a system. A user is uniquely identified and should be represented as an Entity. A Value Object could represent something like an Address or Price.

Value Objects encapsulate the data type and isolate much of the data type specifics within the Value Object class. This means if you refactor that data type the collateral damage is dramatically reduced. In the case of Price, instead of the code spread throughout your code base being coupled to a data type like double you would create a class named Price which encapsulates the double. This gives you the freedom to change the internally held data type with minimal change.

In the case that a price is defined as a double, how do we want to represent when something has no price versus when it is simply just free? Some code may treat it with a –1 value meaning it has no price (not suggesting this). What if you decide –1 doesn’t work for you and you change it? What if you change it to a string, do you check for “-1” now? These are the kinds of changes I saw in the refactoring. The meaning of “zero” completely changed and impacted the code base throughout two dozen classes.

If Price was a Value Object in the sense defined by DDD then we would wrap all this in a class that may look something like this:

public class Price
{
    const double ZERO = 0.0d;
    double value = ZERO;

    public Price(double value)
    {
        this.value = value;
    }

    public double Value
    {
        get { return value; }
    }

    public override bool Equals(object obj)
    {
        if (obj == null)
            return false;

        if (this.GetType() != obj.GetType())
            return false;

        Price comparisonPrice = obj as Price;

        return this.Value == comparisonPrice.Value;
    }

    public override int GetHashCode()
    {
        return value.GetHashCode();
    }

    public static Boolean operator ==(Price v1, Price v2)
    {
        if ((object)v1 == null)
        {
            if ((object)v2 == null)
                return true;
            else
                return false;
        }

        return (v1.Equals(v2));
    }

    public static Boolean operator !=(Price v1, Price v2)
    {

        return !(v1 == v2);
    }

    public static Price Zero
    {
        get { return new Price(0.0d); }
    }
}

This gives us the ability to do things such as:

Price price1 = Price.Zero;
if (price1 == Price.Zero)
    Console.WriteLine("Price1 is ZERO!");

Price price2 = new Price(1.0);
Price price3 = new Price(1.0);
if (price2 == price3)
    Console.WriteLine("Price2 and Price3 are EQUAL!");

Price price4 = new Price(1.0);
Price price5 = new Price(1.1);
if (price4 != price5)
    Console.WriteLine("Price4 and Price5 are DIFFERENT!");

The great thing about using Value Object this way is all the comparison code throughout your code base doesn’t need to change based on your changes in the future of what a Price data type may be or what zero may mean in the future if you choose to change that.

Another benefit of Value Object is the ability to be immutable. If you want to reduce bugs and prevent developers or bad code from accidentally modifying a value you can simply only allow the value to be set in the constructor and not in any setter as I did above. This reduces chances of bad behaviour altering values.

Using alternative constructors you can also provide migration paths (although I’m not sure if this is a well advised move) to take different data types and convert it to the new data type after a refactoring of the Price’s internal data type.

Value Objects provide more flexibility, isolates refactoring impact and reduces bugs. It’s a little bit more work but not much! It leaves the code base in better hands for the next developer who may need to refactor the choices I made.

Next time I catch myself exposing a data type directly and require calling code to couple to the data type I hope to remember where I can leverage Value Objects.

ObservableCollection<T> is a core piece to most WPF or Silverlight applications. It aligns perfectly with the MVVM pattern that is very popular in XAML based applications these days. For example binding a ListBox’s ItemsSource to an ObservableCollection give’s the WPF or Silverlight databinding engine the ability to listen to the change events that ObservableCollection offers whenever an item is added or removed to the list. This makes it very simple for the developer, in their ViewModel they just add or remove items as they wish and the UI updates itself. Magical!

There’s a catch though. Although this is automatic, it’s far from fast. If you are removing or adding 1 item at a time, you likely won’t see any issues but we must keep in mind when we call ObservableCollection.Add() or ObservableCollection.Remove() an event is being fired per call and the layout engine is calculating layout on the items. If you load 100 users, and you add them one by one as ObservableCollection requires you to, you will be hitting layout calculations on each call.

What we really want is to fire one change event when a batch of add or removes has executed so that the layout engine recalculates the visuals once. There is no need to recalculate layout on each item add. I’m not sure why this was left out of ObservableCollection but it’s a pretty simple addition and offers some great performance increases.

Adding an AddRange() method to ObservableCollection will give us the flexibility we need when we want to add a batch of items or we can still call Add() when we need more fine grained updates.

public class OptimizedObservableCollection
    : ObservableCollection
{
    private bool suppressOnCollectionChanged;

    public void AddRange(IEnumerable items)
    {
        if (null == items)
        {
            throw new ArgumentNullException("items");
        }

        if (items.Any())
        {
            try
            {
                suppressOnCollectionChanged = true;
                foreach (var item in items)
                {
                    Add(item);
                }
            }
            finally
            {
                suppressOnCollectionChanged = false;
                OnCollectionChanged(
                    new NotifyCollectionChangedEventArgs(
                        NotifyCollectionChangedAction.Reset));
            }
        }
    }

    protected override void OnCollectionChanged(NotifyCollectionChangedEventArgs e)
    {
        if (!suppressOnCollectionChanged)
        {
            base.OnCollectionChanged(e);
        }
    }
}

As you can see in the AddRange() we are supressing the event from firing until the batch is completed so that the event only fires once.

I created a sample which uses two ListBox’s databinding against ObservableCollection and OptimizedObservableCollection that adds 1,000,000 items to these collections. Keep in mind that 1,000,000 is a rather unrealistic number but I needed to crank the volume in this simplistic of a sample to see the difference. When you use DataTemplate’s and create custom visuals (which is very common) this limitation of ObservableCollection can start showing to the user in the amount of seconds with only 100 items databound. Remember the impact of the layout calls per Add() will be based on the size and complexity of your visual tree. In the case of this sample ListBox is only using one control so the layout cost is very small.

Once you start building richer UI’s you will hit views that take a few seconds to databind when loading data but you can avoid this with OptimizedObservableCollection that I will show you.

From the screenshot of the sample application we can see there is only 1 layout calculation even after we added 1,000,000 items (the count says 2 because the initial application loading also requires a layout calculation). The real shocker is the amount of time spent on the UI thread databinding with the regular ObservableCollection.

Whenever possible we should be spending as little time in the UI thread as possible so that the application rendering doesn’t get interfered with. The more time we spend in the UI thread crunching CPU the less is available to the WPF or Silverlight rendering engine for updating UI in other places in our application such as changes in other areas or animations we may have running.

Here’s a copy of the sample code and OptimizedObservableCollection<T>

Download

For people unaware, Microsoft Lync is the new name for Microsoft Office Communications Server (OCS). In the past couple months I’ve been working with the Lync Client SDK to build client experiences on top of the recently released Lync Server RC and Lync Client SDK RC. I’m going to go through what is available to you in the Client SDK.

The Client SDK allows you to integrate client functionality like messaging, presence, voice, video and automation into your applications. It can be as simple as showing a users presence status in your application to being a full communicator-like experience that you can customize yourself.

I’m going to discuss the high level out-of-the-box functionality the SDK provides, the differences from the Communicator 2007 SDK as well as what UI Suppression mode is and what it means to you and how you decide to integrate with Lync Client (more on that later).

Office Communicator 2007

I won’t spend much time on Communicator 2007 but I wanted to mention it because the integration options in Lync Client that are available today are different than in Communicator 2007.

In Communicator 2007 you had the ability to integrate into the actual Communicator user interface and you could embed things like Silverlight to build rich experiences within Communicator. This was removed in Lync Client. You can no longer integrate within the user interface. Optionally the SDK gives a whole new twist to the problem of building communications driven applications based on Lync by exposing a collection of reusable WPF (Windows Presentation Foundation) and Silverlight controls.

Lync Client 2010

As mentioned in the Lync Client SDK we get an array of pre-canned controls for both WPF and Silverlight to use. These controls are very much identical to the Lync Client user interface. In a sense these are building blocks that allow you to add specific features into your already existing applications such as Presence, Messaging and Voice etc. If you wanted you could build a user interface using these controls that looked almost identical to the Lync Client themselves.

These controls like most WPF or Silverlight controls support templating so you can completely overhaul the visuals if you wish or you can keep the default Lync Client matching styles.

Here are some examples of the controls available to you (these are the WPF versions):

PresenceIndicator
MyStatusArea
MyNoteBox
StartIMButton
StartVideoCallButton
ScheduleMeetingButton
SendEmailButton
SendFileButton
ShareDesktopButton
StartAudioCallButton
MyPresenceChooser
ContactCard
ContactList
ContactSearch

The great thing about these controls is you don’t have to do anything to get them to work. You drop them on your application and they will communicate with Lync Client behind the scenes and automatically display the data. You can use these to built a feature filled experience or you can drop something as simple as the PresenceIndicator if you want to display status of a user within your application. Alternatively you could just drop a call button if you want a user to have quick access to calling another user. There is lots of possible user experiences you can create from these.

These controls as I mentioned earlier are like any other WPF or Silverlight control. You can customize their appearance through Styling and Control Templates.

Using these controls has a caveat when we enable UI Suppression Mode. What is UI Suppression Mode? Let’s find out.

UI Suppression Mode

Some people will use the reusable controls to enable Presence, Messaging, Voice and other features in their applications but some of you may want to build a custom Lync Client user interface tailored to your needs. At first glance, UI Suppression looks like it is the last piece to your puzzle. UI Suppression Mode disables the Lync Client user interface. This means you can implement your own to replace Microsoft’s Lync Client while still leveraging the Lync Client functionality. Lync Client is still running, but the UI layer is not initialized. This sounds perfect right? Not exactly.

You enable UI Suppression on Lync Client via a registry key and when you do so, this disables all UI functionality, not just the visuals of the UI. This means all of the reusable controls above get disabled. They no longer just work as magically as they did before. I think Microsoft possibly misunderstood what people’s needs were when they wanted to hide Lync Client to implement their own user experience. They gave us a bunch of amazing controls we can reuse and style/template to our visual needs that just automatically hook up to the underlining Lync Client behind the scenes but at the time we want to hide Lync Client that all goes away. This includes the ConversationWindow as well. We have gone from having a cookie-cutter build your own Lync experience to losing all of that and only having the lower-level API’s to deal with.

With these lower-level API’s we can implement our own client but it has now become a much larger task. Things that were for free, are now very big implementations we must develop ourselves rather than customize:

• ConversationWindow
• All the major controls like PresenceIndicator, Contact List, Contact Card etc.
• Options window. In Lync Client there is an options window to configure a bunch of options. We would love to just have a method to bring this on the screen. We don’t want to re-implement all of that.

This is an unfortunate situation here because all we wanted to do was swap the Microsoft Lync Client UI with our own and choose which reusable UI pieces we want. This gives us the option to use their excellent built-in control functionality or we can rewrite the world if we really wish to, but it doesn’t work that way right now. They make the call for us which is all or nothing. Hopefully this changes in the future.

Client & Automation API

The Client API and Automation API allows you to do some pretty powerful things which I will go into further detail in following blog posts. You can programmatically control things such as:

• Publishing Presence & Availability
• Publish Personal Note
• ConversationManager (start IM and audio conversations, respond to conversation invitations, etc)
• ContactsAndGroupsManager (search contacts, query presence, set privacy, etc)
• Subscribe to events

There is a pretty good complement of events you can listen to so that you can track state of contacts, conversations among other things in your application.

On top of all that, using the SDK is very simple and straight forward for the most part. The biggest caveat is UI Suppression Mode. If this doesn’t impact you then everything else is pretty straight forward.

I plan to blog more specific use cases with samples coming soon as well as some other surprises I have found along the way. I’m looking forward to blogging more about Lync Client development and some tricks I have discovered along the way.

If you have any feedback please leave a comment or hit me on Twitter: http://twitter.com/simongui

It’s been awhile since I’ve had some content to blog about. I’ve been pretty quiet for the last 6 months. I have a bunch of content I’m looking forward to posting. Right now I am primarily in the telecom industry and will be blogging about Microsoft Lync, both server and client.

I still do mobile development in my spare time when I get a chance so there may be some upcoming mobile related content as well.

It’s a bit of switching gears for me but I look forward to trying to push out some great Lync content and howto’s.

Stay tuned!

There has been lots of talk about the new restrictions in the latest developer agreement on the AppStore that came about when iPhoneOS 4 was announced. It has been a hotly debated topic to say the least. The new legal text in section 3.3.1 is essentially trying to lock in what languages and tools developers use to build their iPhone, iPod Touch and iPad applications.

I’m not going to rehash the same Apple vs Adobe banter that has been going on. It’s been talked about to death. What I am going to talk about is what I believe in as a developer, and why MonoTouch was chosen to build Diggify.

There has been much confusion among various blogs and publications regarding what MonoTouch is and how it works. This stems from the root of what MonoTouch is, which is a .NET and C# offering for iPhone. When people read .NET they jump to conclusions by associating MonoTouch with Microsoft’s user interface libraries such as Windows Forms or Silverlight. This steers people into believing MonoTouch is a non-native UI toolkit ala Flash or various others. Let me clarify before I jump to the experiences and comments.

What MonoTouch is not:

• Non-native UI toolkit
• Cross-platform UI toolkit
• JIT and Intermediate Language runtime

What MonoTouch is:

• Native Cocoa Touch UI
• Native ARM compilation
• Bindings to iPhone SDK libraries that you can use in C#
• .NET class library
• Ability to wrap any native API in C#
• Fast
• Garbage Collected to simplify memory management
• Debugging over WiFi (Xcode cannot do this)
• Very quick to support new API’s from Apple’s iPhone SDK (usually within 24 hours)
• Fully supported by Novell
• Direct access to Novell software engineers via chat rooms, forums etc
• Vibrant and friendly community

I started with MonoTouch during the closed beta program from the very beginning and can’t say enough good things about the MonoTouch team at Novell. During that time, I decided to write a Digg client app for release on the AppStore. At the time this beta program began I had nearly a year of Objective-C development under my belt. This was not a case of “I will only write iPhone applications if my favorite language somehow gets on the iPhone“. Although C# is the main language I have used through my career, I have many others and am not a 1 trick pony. If MonoTouch did not exist, I would be writing Objective-C based applications.

The app built is called Diggify and is available on the AppStore today which can be found here on iTunes and also has a website describing the application which you can find at http://www.diggifyapp.com.

The goals in Diggify were to make a rich Digg application that had great user experience and visuals as well as good usability for navigating the application while at the same time making it as speedy as possible. All of these goals were achieved.

The reasoning for going with the MonoTouch SDK cover several reasons. As mentioned earlier, C# is the language I know the most which means any previously written non-UI code I have in C# I can leverage on the iPhone. This is huge because if I wish to write Diggify for Windows Mobile (at the time) or Windows Phone 7, I can carry over large chunks of my code but leverage the native UI API’s of both iPhone and Windows Phone 7. Remember from above, MonoTouch is not a cross-platform UI toolkit.

To clarify, this means I can write the core meat of my applications logic, data, REST requests for multiple platforms, while leveraging the powerful native UI on the local device. On iPhone this would compile down to Cocoa Touch API calls in native ARM and on Windows Phone 7, Silveright.

In addition to this, MonoTouch is essentially giving me the iPhone SDK+.NET framework. I am getting both. I can use Apple API’s for things like Core Animation to make my transitions and visuals pop, and use System.Xml, System.Xml.Serialization and System.IO from the .NET framework to parse XML and persist them to the file system. I have 2 SDK’s at my arsenal, while not sacrificing the UI. This is key because Apple does not provide things like XML libraries, or WCF/SOAP libraries. I can lean on the .NET API’s to quickly and easily offer these functionalities to me.

MonoTouch comes with MonoDevelop a first rate developer IDE which integrates very smoothly with Apple’s Interface Builder to build your UI’s with. I believe MonoDevelop integrates more seamlessly with IB than Xcode does from Apple. The MonoTouch team has done a great job at trying to make the productivity of building iPhone applications as good as possible.

When writing Objective-C based applications with the iPhone SDK you do not have the garbage collector that Apple provides on the Mac. This and various API’s missing makes developing iPhone applications more time consuming and error prone. Managing memory is a more difficult task and can cause hard crashes in your application. As you grow in experience you get better at these things, but I found using Objective-C I was spending more time on plumbing than on the application’s features, visuals and user experience.

With MonoTouch I was able to really spend a lot of time fine tuning UI and performance. Rich iPhone applications can tend to be a little sluggish if not done right. Like on any mobile device, squeezing performance is skill. You do not have 2ghz dual cores on these phones. This is why apps like Tweetie do so well. Their using rich visuals while blazing fast. I was able to do the same with Diggify by having a rich dynamic user interface while maintaining fast scrollable lists that looked great.

To say this simply: I was able to focus on building a great application rather than spending all my time on low-level book keeping.

When Diggify launched on the AppStore Digg had already released their Digg application a week or so previous, and for free. I had planned and did price Diggify at 99c. In reality Digg’s free app hurts our chances because it was free and obviously it is their own app and they have the platform to market it on their own website to millions of users.

Even though the Diggify application is richer in visuals and user experience (in my opinion and several others from feedback given), one interesting thing happened on the official Digg app launch. The app was rampant with bugs. The AppStore reviews were terrible and the complaints of the app crashing constantly were the common theme. Twitter was also full of comments about how crashtastic the application was. I was able to boost my sales by simply tweeting to people encountering this difficulty (and there were many of them) and making them aware that Diggify existed. Since our marketing is very small and awareness was the largest issue, this helped a great deal.

Using this tactic we had reached as high as 8th in the top paid news category.

In addition to this, all of the feedback we were receiving was all about adding X, Y feature. Not one comment was about a crash or performance issues. The users simply wanted more. One tweet was as follows:

benny_b0i
Got @diggify and like what I see. Transition FX and upcoming are cool, and it’s fast! Would like to be able to digg and see comments tho.
4:53 AM Apr 6th via Twitbit for iPhone in reply to diggify

After initial launch we were able to quickly add some UI tweaks and small features right away based on other user feedback received.

Steve Jobs recently posted an article clarifying his opinions and stance on the topic and although I do agree with parts of what he is saying, there are a couple statements I disagree on. Steve on his article states the following:

“We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.”

MonoTouch is a 3rd party SDK however Diggify vs Digg’s official app is a no contest regarding which is the more stable application. Much of this is credited to MonoTouch’s garbage collector, type safety, etc.

Steve goes on to add:

“Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms”

MonoTouch adds new API’s when Apple releases them within 24 hours. If I didn’t like Novell’s quality in their SDK or support I have the choice to go elsewhere or back to Objective-C.

The initial release of the official Digg app’s main issue was a start-up crash. How that got past QA I don’t know. From there most updates have been fixing various crashes and issues.

We submitted the first app update mostly based on user feedback of UI tweaks they requested 2 days after the initial AppStore approval. Let’s compare the Digg/Diggify updates:

Based on the experience, the quoted statements above from Steve are not the case and is actually the opposite. We are receiving inherited benefits from using a 3rd party SDK which also builds on top of the iPhone SDK. MonoTouch is adding value to the iPhone SDK, not an alternative.

My opinion comes down to this. Bad developers write bad applications. The official Digg application was a bad application to release at the time. It was bug filled. They have refined it over time, but during that time I had 0 complaints, and was moving forward. Since MonoTouch uses the native iPhone API’s and compiles to native ARM, there is no risk in Apple allowing us to write applications in C# via MonoTouch.

Languages and compilers are tools. Do I not get to choose which hammer I wish to use when hitting a nail? In the end as long as we are using documented API’s (which MonoTouch is) and native UI, Diggify is no different than any other iPhone application. Not even 1 user has said that the application feels different. No cycles were spent on making it feel like a native iPhone application simply because, that is what it is. Diggify is calling the same API’s. No extra work is needed. The source language that the application is written in has nothing to do with the look and feel or usability of an application.

By no means is this a post against Objective-C. I simply feel the diversity which is the development world should be embraced not suffocated. MonoTouch was chosen for Diggify for the reasons above. Perhaps you have reasons for using Objective-C or any other language, I believe that it should be our choice.

Perhaps the team writing the official Digg app had unrealistic time constraints and this was the end result. Regardless, from our experience MonoTouch gave us a product that allowed us to focus on the app, preventing us from repeatedly shooting ourselves in the foot all while our time to dedicate to the project was limited.

I feel if Apple truly wants to go the proper route to filter out crappy apps, the path is through QA, not by banning the source language the app was written in.

Apple, let’s work together as a community to rise the level of quality on applications in an effective way that retains the freedom of choice and creativity that developers love rather than lock handcuffs on our wrists.

Update:

As pointed out in the comments below from @redth, I forgot to mention MonoTouch has a btouch tool. btouch allows us as the developer to wrap any native API ourselves in C#. If we need something Novell does not yet provide or binding to an external Objective-C library we can do so. This is an important fact to remember.

Last week I unveiled Project-D as its real name, Diggify. We unveiled the website www.diggifyapp.com as well as the Twitter account @diggify

Submitting to Apple will be very soon. Awaiting feedback from the test team whether any minor issues have been discovered.

It’s been awhile since I blogged. A job switch certainly has made things chaotic.

I also haven’t found as many “sexy” topics to blog about as I did early on in the development of Diggify.

So I ask the people reading my blog, is there anything you see in Diggify that you want to know how I did it? If not I have some ideas of some minor things I can talk about but if there is something people want to hear about, feel free to send feedback.

Looking forward to the release. It will be a good learning experience.

I have been debugging UITableView rendering performance when scrolling in Project-D because I feel it is a bit sub par.

Project-D uses a custom UITableViewCell designed in IB with the exact same method I talk about in my howto blog post you can find here: http://simon.nureality.ca/?p=91

I have used a lot of transparent images, and the upcoming Ticker at the bottom of the application may also be causing additional alpha blending.

I believe the performance has something to do with the amount of alpha blended layers I have added in my UI.

I have not yet found the solution but I did find a nifty way on the device and simulator to make the display visualize the alpha blended layers in shades of green/red.

Green is good, red is bad. The more red, the more alpha blending is occurring in that region. Alpha blending is very expensive on the iPhone.

As you can see, most of Project-D is red and in some areas a deep red which I suspect means alpha layers on top of alpha layers. I did heavily use transparent png’s and perhaps went a bit too much and am curious how this has affected iPhone 3G users since I own an iPhone 3GS and I am just now just barely noticing a bit of what feels like frame rate impact.

You can do this on device or simulator however I like the simulator method the best because once launched, you can continue development in MonoDevelop, where as with Instruments on device you have to run it in Xcode and attach separately in Instruments.

Here’s how to launch the simulator with visible alpha blended layers enabled:

1. Open a new file in TextEdit
2. Click Format -> Make Plain Text
3. Enter the following in the document

#!/bin/bash
CA_COLOR_OPAQUE=1 /Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/iPhone\ Simulator.app/Contents/MacOS/iPhone\ Simulator

4. Save as Simulator.sh on the desktop.
5. Start Terminal and chmod +x Simulator.sh
6. Double click Simulator.sh on the desktop and the iPhone Simulator should run with layers showing up in shades of red and green.
7. Run your application or start it via the brand new MonoTouch/MonoDeveloper debugger.
8. Play with your app ui and watch the invalidated regions.

Enjoy! As always feel free to retweet the post and you can always find me on twitter via @simongui