and Windows Store Simple.Data.Core references ADO.NET OData has nothing to do with ADO.NET Most of OData adapater code deals with either parsing XML documents returned by an OData service or formatting CLR objects as XML documents to send to OData service These operations should run on any platform
(user + password), create authentication object using one of supported schemes (Basic, Windows etc.) Worked like a charm, either to use in client code var odataFeed = new ODataFeed( "http://www.myservice.com/api", "Vagif", "Password123");
credentials); credentials is an instance of a class that implements ICredentials interface All past and future authentication schemes are supported PCL conformance enforced use of interface
to target any subset of platforms Attempt to choose a set of platforms result in a configuration closely matching the requested set but not necessarily identical to it While PCL support in Mono is not officially released some extra work required to resolve types that reside in different Mono assemblies than on .NET/Windows
removed from PCL for the sake of wide platform support Lazy, Tuple are not supported on SL4/WP7.5. Should platform set be reduced just because of Lazy[ness]? C# dynamic is cool, but lack of dynamic support should not discard the whole platform, there should be a fallback to an alternative API await/async and TPL are cool too but also limit your platforms a) var result = client.FindEntry("Products", x.ProductName == "Chai") b) var result = client.FindEntry("Products?$filter=ProductName eq 'Chai'")
next business logic module a PCL Have an overview of portable CLR subset When selecting external components strive to choose those that have PCLs Strive to use portable types and values converters (BitmapImage vs. base64 string) When publishing your PCLs support profiles preferred by your target developer group Write and test view models first, package them as PCLs, you can go a long way without a single line of UI code