Great acropolis explanations
Today I ran across two very interesting and well written explanations of different aspects of Acropolis written by folks outside of Acropolis team! I am stoked to fine such good stuff for an effort that is so early form folks that were not directly involved in building it. Thanks to everyone in the community who is jumping in head-first on acropolis...
Also, over on the Acropolis team blog, Kathy is aggregating useful acropolis posts from the team.. is there something else you'd like to see more information on?
Microsoft Codename Acropolis - Unwrapped
By Kevin Hoffman on The .NET Addict's Blog
In this post I take a look at Acropolis - what it is and why should developers be concerned about it. Also, I compare it to some offerings on OS X to help clear things up. <<...snip...>>
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.
Acropolis NavigationManager
By avalonboy
Microsoft Code Name "Acropolis" is a set of components and tools intended to make it easier for developers to build and manage modular, business focused, client applications for Microsoft Windows on the .NET Framework <<...snip...>>
Basically, a "NavigationItem" is associated to a child part during the application execution. See the schema below 3 Parts are dropped as Children in the application.
<<...snip...>>
Depending which kind of NavigationManager you use, the behavior is below:
- With SinglePartNavigationManager, only the last added part is activated (TaskPadPart3) and 2 first are deactivated (TaskPadPart1 and TaskPadPart2). See Figure 1.
- With MultiPartNavigationManager, all parts are activated (TaskPadPart1, TaskPadPart2 and TaskPadPart3). See Figure 2.
Figure 1.
Figure 2.