Smart Client Development

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

This is not a lesson You should attend

What is “good application”?

Architecture…

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

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

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

The Process

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

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

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!

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

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

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

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

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!

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

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

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>?

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);

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; }

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

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

The Concept

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

Real life software Async Process Queues Storages Dispatcher Processor Worker

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

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

WPF – Huh?

Architecture (should)= Simplicity

Are you familiar with WPF?

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

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)

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

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

http://khason.net	1527
http://www.slideshare.net	13
http://sharpsoft.net	4
http://translate.googleusercontent.com	2
http://205.164.56.138	2
http://rss2.com	2
http://rss.khason.net	1
http://www.linkedin.com	1

Smart Client Development

by Tamir Khason

Accessibility

Categories

Upload Details

Usage Rights

8 Embeds 1,552

Statistics

Smart Client Development Presentation Transcript