Those days, when it seemed, that web applications have overthrown standard “cumbersome” client apps, we’ll speak about present and future of consumer oriented desktop applications. This includes, but not restricted to patterns of LOB applications development with WPF, right multimedia support of DirectX bridge and new features, waiting for you in Windows 7. Also we’ll speak about subject oriented programming, will be introduced in NET. 4.0 and how to leverage it even today with the current version of Microsoft framework. tits will be shown during the session, thus restricted to mature audiences

1. Tamir Khason
http://khason.net
Feb’ 09
Sponsored by:

2. This is not a lesson
You should attend

3. What is “good application”?

4. Architecture…

5. … but what
about me?
This is Nick
… and Nick has
also a lot of letters
for this machine

6. Smart Client Application should be
Simple
Useful
Deployable
Maintainable
Extensible
ACCEPTABLE

8. What is “Smart Client”?
My presentation July 2002 My presentation Feb’ 2009
 WinForms User Interface  Client User Interface
 Deployed via central server  Zero footprint deployment
 Uses local resources  Users local resource
 Uses server based data and  Synchronizes and distributes
processing data and processes
 Works better connected  Smart sensitive to local
 Works offline environment
 Minimum dependencies

10. The Process

11. Planning
Focus on FEATURES Focus on SCENARIOS
 Stability  Excitement
 Incremental  Breakthroughs
improvement  Most probably will
 Most probably “End- leave existing
to-End” scenarios will customers behind
not work

12. Architectural review
But it
cumbersome We need
componentization
There is a ton of
dependencies

13. Dependencies management
 Types in a same component can depend one on each other
 Cross-component dependencies must be controlled
 Can be depend on component in lower layer
 Must not be hard depend on component in higher layer
 Must avoid to be soft depend on component in higher layer
 Need someone else to manage dependencies on the same
layer
 Less dependencies – better!
 Also less assemblies – better!
 … in general – less is better – simpler is better!

14. 10 Design dogmas
Component oriented Primitive Oriented
 Rich APIs with lots of  No external dependencies
features – ton of  Great evolvability, often
dependencies very poor usability
 Great usability, poor  Incoherent type discovery,
evolvability but not required reflection
 Easy type discovery, but  Good for low level stable
need reflection framework
 Good for higher level
components - not for the
core

15. Extensibility Framework?
 There is no “Official” extensibility framework, so you
can…
 Create from scratch
 Buy/use something good…
 Wait for .NET 4.0
 Use MEF - Managed Extensibility Framework + WPF today
Catalog
Value Resolver
Composition container
Part Part Part
Export Import Export Import Export Import

16. How it works?
Who has service
I need?
I have!
[Import]
public IEnumerable<IYourService>
YourServices { get; set; }
[Export(typeof(IYourService)]
public class SomeService : IYourService

17. Who is who and what can it do?
 Parts relate through contracts
 Imports are contracts parts need
 Exports are contracts parts offer
 The Container is matchmaker
 It queues catalogs
 Parts can load lazily
 Parts can have different lifetimes
 Parts are extensible and reusable

18. Contracts
 Preconditions, rather then endless try-catch blocks
 Postconditions, rather then endless if-else blocks
Assumption.SetPolicy(AssumptionPolicy.Break, new AssumptionHelper());
…
public NotNullSet(HashSet<T> set) Assumption.NotNull(set);
…
Assumption.IsTrue(typeof(T1) != typeof(T2), quot;The two types of values in a mapping cannot be the
same type.quot;);
 The best about this is Static Analysis!

19. But what’s with “Compatibility”?
 Cross-Version Compatibility
 Cross-Redistribution Compatibility
 Backward Compatibility
 Forward Compatibility
 Binary Compatibility
 Source Compatibility
 API Compatibility

20. Primitives and extensibility?
 APIs are published as interfaces into a
“programmability” assembly
 Embed interfaces at compile time
 Can be deployed to any version of the managed
application
 We can “cast” one interface into other in runtime
– loose type coupling
 We can add some aspects and logic in compile
time with custom compilers
 In .NET 4.0 only!
 By now – you can use PostSharp

21. Generic co- and contravariance
 It’s scary, but simple
 We can cast to ancestor types
private void WriteSomething(object[] something) { }
…
var something = new string[] { quot;It's somethingquot; };
WriteSomething(something);
 But it not always works
private void WriteSomething(IEnumerable<object> something) { }
…
var something = new List<string> { quot;It's somethingquot; };
WriteSomething(something); // Compiler says “NO”!
 So should we be able to pass Ixxx<TDerived> for
Ixxx<TBase>?

22. Generic co- and contravariance
 If T is an output → IX<TDerived> for IX<T>
 It’s covariance
 …and can be used as IX<out T>
 If T is an input → IX<TBase> for IX<T>
 It’s contravariance
 …and can be used as IX <in T>
private void DoSomething(Func<object, IValueConverter> something) {
this.Converter = something(this.Whatever); // Oh, NOT!!!
}
…
var something = new Func<string, IValueConverter> { };
DoSomething(something);

23. AOP – WTF?
 You have INotifyPropertyChanged primitive
public class MyPrimitive : INotifyPropertyChanged {
public event PropertyChangedEventHandler PropertyChanged;
protected virtual void OnPropertyChanged(string name) {
if (PropertyChanged != null) PropertyChanged(this, new PropertyChangedEventArgs(name));
 For each setter of each descendant you need to call
virtual method OnPropertyChanged
public class MyClass : MyPrimitive {
private int _myProperty;
public int MyProperty { get { return _myProperty; }
set { if (_myProperty != value) { _myProperty = value;
OnPropertyChanged(quot;MyPropertyquot;);
 Rather then use automatic setters
public int MyProperty { get; set; }

24. AOP – WTF?
 The best is to create your own compilation rule…
 … or even some dynamic primitives…
 … but it only possible in .NET 4.0
 Meanwhile, you can use PostSharp and
OnMethodBoundaryAspect primitive to tell compiler
what to do
internal class SetterWrapper : OnMethodBoundaryAspect {
public override void OnEntry(MethodExecutionEventArgs eventArgs) {
var myPrimitive = eventArgs.Instance as MyPrimitive ;
_propertyInfo = myPrimitive.Class.GetProperty(_propertyName);
eventArgs.MethodExecutionTag = myPrimitive.OnBeforePropertyChange(_propertyInfo, newValue,
oldValue);
eventArgs.FlowBehavior = FlowBehavior.Return;
 All the rest will be done automagically

25. Side by Side
 .NET 1.x and 2.x CLR - Side by Side on the same
machine
 Good for programs
 Bad for add-ins
 Breaks on 3.x “red bits”
 .NET 4.x CLR – Side by Side in process with 2.x CLR
 Each module runs again its expected version of CLR
 Can be done today by some unmanaged injections

26. The Concept

27. Real life software Perform
Specialised tasks
Can process
more than one
request at a time
Increase staff
during peek
hours or replace
staff on trouble

28. Real life software
Async Process
Queues
Storages
Dispatcher Processor Worker

29. Need a change of thinking
 To throw out
 Local states
 Client locks, transactions and scopes
 Fault tolerance
 To bring aboard
 Asynchronous operations
 Simplicity
 Self descriptive behaviors and
components

30. Local resources?
 Windows Sensor and Location platform
 Basically the better way to access well-known device types
 Build context aware applications
 Can be used today by wrapping HID_* methods
 Microsoft Sync Framework
 You can synchronize your application or device and provide
it offline capabilities
 Build “sometimes connected” applications
 “DirectHardware” is your friend and savior
 DirectX helps you to leverage client’s hardware
 It also can varnish a bit your app

31. WPF – Huh?

32. Architecture (should)= Simplicity

33. Are you familiar
with WPF?

34. We already have a lot of stuff
 We have trees in WPF
 Logical tree – is what you put in XAML
 Visual tree – the what WPF renders for us
 Inheritance – frozen hybrid of two above
 We have Context
 All Data Context inherited via trees
 Resources inherited via Logical tree
 Routed events and commands can be used
through Visual tree
 Data Templates = Views

35. 2 conclude
 Think as consumer, not as developer
 DO design APIs by using it (writing code)
 Keep It Simple, Stupid!
 Set goals, gates and make an order
Staging Feature
branch branch
Staging
Main Feature
branch
branch
Staging
branch
 Avoid integrating unfinished features (yes, even if it is
very cool feature)

36. 2 Read
 My Blog
http://khason.net
 Windows Client Development
http://windowsclient.net
 Windows Presentation Foundation (Toolkit, Futures,
Ribbon, Labs, M-V-VM)
http://codeplex.com/wpf
 Managed Extensibility Framework (MEF)
http://codeplex.com/mef
 PostSharp + Aspect-Oriented Programming.NET
http://postsharp.org
 Microsoft WHDC site (Sensors)
http://microsoft.com/whdc/sensors
 Microsoft Sync Framework
http://msdn.microsoft.com/en-us/sync

37. Thank you
Questions?
… and I do not need “Potential – Passion” slide anymore…
tamir@khason.biz
http://khason.net