In case you've been living under a rock, or you don't spend all day hitting Refresh on Microsoft sites waiting for new stuff to come out, Acropolis is a new framework currently in CTP (Community Technology Preview) from Microsoft. Basically Acropolis is a framework providing support for composite application development using Visual Studio "Orcas", WPF (Windows Presentation Foundation) and the .NET Framework v3.5 (currently in Beta 1).

To get Acropolis, you need to download the 5.7GB disk image for Orcas and install that. Once you've managed to install that whopper, you then download the Acropolis CTP. If you're feeling lucky, also go ahead and download the Silverlight, Astoria, and Jasper CTPs. Hell, if you're going to slap a 5.7GB beta on your disk, you might as well drop all the goodies from Microsoft on the same machine (or virtual machine).

As I mentioned, Acropolis is a composite application development framework. This basically means that Acropolis is a kind of scaffolding. When you build your Acropolis application, you start with this basic scaffolding. As you build the application you take all of these building blocks (think of them as C# legos) and insert them into your application while standing on the scaffolding. Eventually, all of the individual components you've been building will work together and create a powerful new (desktop-only!! no web apps [yet]) application.

So let's unwrap Acropolis and take a look at the pieces of the framework:

• Parts. A part is a reusable, discrete component of business logic. Don't try and map this to an existing class in an existing app because unless you're currently doing composite app building using something like the CAB (Composite Application Block, another offering from Microsoft's Patterns and Practices gurus) you probably don't have any one object that performs this task. Let's say you're building a point of sale application and you have a screen that has a transaction ledger on it. You might (if you're a good little programmer) encapsulate the business logic required for maintaining a transaction ledger in a Part. This leads us to the next piece of the puzzle: Part Views.
  
• Part View. A part view is essentially a self-contained class (comprised of both XAML and C#) that is the view of a part. In true and proper Model-View-Controller/Model-View-Presenter fashion, the view is responsible for receiving input from the user and rendering underlying data. It does nothing more than that.
  
• Services. Unlike what the current buzz around the word "service" indicates, this is not a web service, nor is it a network service or a REST/POX service and it is not a 24-hour service station serving donuts (though, that would be awesome...mmm...donuts....). In the Acropolis (and generic Composite Application Programming terminology), a service is a self-contained piece of loosely coupled code that provides a service to a part or to the entire application. In the financial ledger example, you might have a Service that downloads transactions from the bank. That Service can then feed the transactions to the Part, which will be picked up automatically by bindings in the Part View. Savvy?
  
• Service Dependencies. A service dependency is declared by a part or an application. In our overused ledger example, if the ledger part requires the existance of the BankDownloader service, it can use XAML to declare such a dependency. At runtime, the name of the dependency becomes a service instance, allowing you to write code (in the Part code-behind) like: BankDownloder.Download(myBank);
  
• Connection Points. A connection point is that little dangly thing that we all used to love seeing on COM diagrams back in the day... It is a point of interface between the Part and containing Part Panes and Part Views. In the Acropolis implementation, connection points are really wrappers around a value of type System.Object that has special rigging for existing within the Acropolis framework and exposing itself to the Acropolis runtime.
  
• Notifications. Notifications allow a part to send up a signal flare to other parts. If one part wants to convey useful information to another part, notifications allow data to be bundled inside.
  
• Transitions and Navigators. A navigator is a tool that allows for navigation between parts that is either user-stimulated or fired programmatically (or both). When a navigator moves from one part to another, it can perform a transition such as a fade, a wipe, a slide, and Acropolis even comes with some fancy rotating cube effects, etc. The Acropolis runtime takes care of shuffling stuff in and out of memory, instantiating things and so on, leaving the developer free to think about his application in a truly compositional manner. In theory, this results in apps that are designed better, more reliable, and just...well..cooler.

I think of design patterns and code implementations as something similar to the difference between faith and religion. Consider that a particular religion might be an implementation of a faith as Acropolis is a specific implementation of the MVC/MVP patterns applied to compositional UI building. Hopefully this won't start a huge religious flame-war :) The point is - Acropolis is just one side of the coin. What would Composite Application Programming look like in another platform...say...maybe... Cocoa?

• Part - To me, a part and part view in Acropolis would be accomplished using a custom view in Cocoa. Basically the Part View would be a defined GUI in Interface Builder and the Part would be a controller class in Xcode. For example, Acropolis when building a new Part and Part view pair, you get the following files:
  
  
  • Part.xaml (Acropolis)
  • Part.xaml.cs (Acropolis)
  • PartView.xaml.cs (Acropolis)
  • PartView.xaml (Acropolis)
  • MyPart.nib (Interface Builder/Cocoa)
  • MyPartController.m (IB/Cocoa)
    
• Part View - see above.
  
• Services - While there aren't any built-in notions of creating self-contained services, it is rather easy to create a class in Objective-C that does not violate separation of concerns. The controller class (Acropolis Part) could then instantiate the service, use it, and dispose of it. Acropolis takes care of maintaining either a pool of services or providing a Singleton, but you could write a wrapper for that in Objective-C
  
• Service Dependencies - This is essentially meta-data. Declaratively in the Part (or Application) XAML in Acropolis, you say something like "I need a service of type ILedgerService, and it is required to be here. Gimme." and then magically the code for the Part (or Application) gains an instance variable with the same name as your dependency. This reminds me a lot of some of the benefits of Spring, etc. I don't know of any built-in mechanism for declaring dependencies in objects, but I'm sure if you really wanted to you could write such a wrapper in Objective-C. Again, keep in mind that I'm comparing a meta-framework (Acropolis) with a core framework (Cocoa), so obviously Acropolis should have more high-level features.
  
• Connection Points - Ok, this where I get jealous of Objective-C and Cocoa when writing my .NET code. In interface builder, I can simply control-drag from any GUI element (custom or otherwise) and drop onto a controller class and pick the method invoked by the GUI element. I can do the same in reverse to allow my controller class to address GUI elements. That takes care of the communication between Part and Part View (NIB and .m).
  
• Notifications - Again, this is another spot where I really wish I had some Cocoa-like functionality. Built into the Acropolis framework is the ability to fire notifications within the Acropolis runtime (which is really a suite of objects instantiated at app bootup for maintaining an Acropolis app) and subscribe to those notifications. Anybody who has used Cocoa will think this sounds familiar - NSNotificationCenter does just that within the context of an application and to take it a step further, NSDistributedNotificationCenter does that within the context of an entire machine. Notifications in Acropolis are used to send signal flares. In the case of the sample financial application, the ledger part might send a notification indicating that a user has selected an individual transaction. This notification would be received by the runtime, eventually resulting in the appearance of a Part called TransactionDetailPart.
  
• Transitions and Navigators - Core Animation makes transitions pretty easy, though navigation you'd have to rig up manually, probably by creating a controller class that is responsible simply for pulling away old views and replacing them with new views. Again, not a really complex task in Cocoa, but it is something that Acropolis aims to automate or at least make trivial.

There are huge benefits to building applications compositionally. First and foremost is the adherence to MVC or MVP as a defacto standard. You cannot build a composited application and violate MVC at the same time - good news all around there. Secondly, if everyone is thinking compositionally, developers can divide and conquer, adequately unit test individual parts on their own time and then regularly perform integration tests within the main Acropolis application.

What remains to be seen is if Acropolis will arise as the be-all-end-all solution for composite desktop application building for Windows, or if developers will simply stick to writing their own building block frameworks. Also, I'm curious to see how my experience in building Acropolis applications might carry over into the Cocoa world, hopefully making me think more about the proper segmentation of my application components.

Time will tell and since Acropolis is only a CTP right now, we've got plenty of time.

tags: acropolis  cocoa  mac  apple  microsoft  xcode  ib
links: digg this  del.icio.us  technorati  reddit