delegates

A bit of history

I remember the day when I started writing the HLinq query language. It was weekend and I was experimenting with writing Single endpoints for Hamster Wheel. Single endpoints were almost done and next step was to write List endpoint. This would allow to get list of records of specific type. After I got single GET returns correct data for chosen record id, list should not be hard to implement. Then just create, update and delete. Basic CRUD API in Hamster Wheel would be finished. I was thrilled that I actually was able to do such thing.

There are 2 ways of writing OWIN middleware in ASP.NET Core.

• Pure OWIN - usefull if you want to integrate with OWIN compatible module but not written in C#
• ASP.NET Core OWIN middleware

ASP.NET Core Middleware:

This type of middleware can be:

• delegate of Func<HttpContext, Func<Task>, Task>
• class with IMiddleware imlementation

app.Use(async (context, next) =>
{
    // Do work that can write to the Response.
    await next.Invoke();
    // Do logging or other work that doesn't write to the Response.
});

Pure OWIN Middleware:

This rather would be used to integrate with OWIN middlewares written in different language, so that ASP.NET Core implementation directly is not possible.

• enables implicit reference conversions for
  • arrays
  • delegates
  • generic type arguments
• Covariance preserves assignment compatibility
• Contravariance reverses assignment compatibility
• allows for matching signatures of delegates and method groups
  • to assign to delegates from method that returns more derived types - covariance
  • to assign to delegates from method that returns less derived types - contravariance
• Covariance and Contravariance are supported in Generics for implicit conversions for type parameters
  • allows method to have more derived return type than defined by generic type parameter of the interface
  • this allows implicit conversions from one generic interface to another (from IEnumerable<string> to IEnumerable<object> even if first does not inherits from second)
  • allows generic types to have less derived argument types than specified by the generic parameter of the interface (implementation of IEqualityComparer<BaseClass> can be implicitly converted to IEqualityComparer<DerivedClass> because IEqualityComparer.Equals is contravariant)
  • implicit conversions works for interfaces but not classes that implement from those interfaces (i.e. this won’t work List<Object> list = new List<String>())

Assignment compatibility is when object of a more derived type is assigned to an object of a less derived type.

Introduction

Delegates can be converted easily to another type if you know types of those delegates. But if you do not know it is impossible without really complicated code.

Introduction

It is quite strange that you can’t easily detect if software keyboard is visible or not on Android. Because of that, it is also complicated thing to do in Xamarin.

Reflection.Emit is very powerful tool. It creates IL code and since C# is converted into IL too, we have the same functionality as in C# and even more. It is very powerful and at the same time very complicated. Because of that it is worth to discuss how and for what it should be used. One idea is to create dynamic code with automatic implementations of interfaces - proxy types.

This is third article in series, that explains how to create delegates for public and non-public members of public, non-public or not known in compile-time types. If you are not familiar with previous articles and looking for detailed explanation of how delegates works, how they are created and why, I strongly encourage you to read first two. If you are just looking for a way to create delegates for methods or constructors it is not necessary. Code with new features and with bug fixes is available on GitHub and as Nuget package.

This is second article in series, that explains how to create delegates for public and non-public members of public, non-public or not known in compile-time types. If you are not familiar with previous article and looking for detailed explanation of how delegates works, how they are created and why, I strongly encourage you to read it first. If you are just looking for a way to create delegates for methods or constructors it is not necessary. Last article in series you can find here . Code with new features and with bug fixes is available on GitHub and as Nuget package. In previous article and first one in series, we covered:

1. Static
   1. Properties
   2. Fields
2. Instance
   1. Properties
   2. Fields
   3. Indexers

Now it is time to cover following members.

1. Static
   1. Methods
2. Instance
   1. Methods
   2. Constructors

This article is first part of the series of three. Next ones you can find here and here . Code for all three articles, with new features and bug fixes is available on GitHub and as Nuget package.

Why not Reflection?

If you working with .NET and C# (probably other languages too), at some point, you will have to write more advanced and generic code, that i.e. reads all properties of a type, searches for attributes, etc. Or maybe you want to call some private method or property? It is not that rare to use some internal mechanism of framework or library. Usually, the first solution involves Reflection. But the thing is: Reflection is slow. Of course, it is sufficient if you need to use Reflection rarely and it is not the main code of the application. If it is used more often at some point, you will probably try to optimize it. And now is the fun part: how to do it?

First things first - Why?

First of all I do not like how creating of views and navigation works in Xamarin. There is much boilerplate needed to just navigate from one page to another. Typically like in Xamarin documentation we have to obtain INavigation interface instance, create instance of a new page, create instance of view model and all dependencies it requires. When you page do not require view model things are real easy and Xamarin sample is just enough.