About writing

Throughout primary and secondary schools, I always had problems with languages. Not just Swedish but with English and Finnish too. The skills never seemed to stick. I’ve always liked reading, but the main issue was in producing sane language or sentences to paper. I struggled with this a lot. My language grades in primary and secondary schools were horrible. Still I’ve always yearned to be better at writing.

Nowadays my language skills have improved a lot; especially in English. The main reason is that I mostly read in English. There weren’t that many good sources for learning programming in Finnish and thus I was “forced” to improve my English skills. Video games, pen and paper RPGs, board games and Magic: The Gathering were also good way to get motivated to get better at English.

In 80’s and 90’s Finland was a good place for getting an ear for English mainly because there weren’t that many dubbed cartoons or movies. Stuff intended for preschool kids were usually dubbed, but after that it was either reading the subtitles or not watching. I’m not quite sure how the dubbing is handled nowadays, but I think the amount has increased.

I’m not going to say much about talking the language. Like most Finns, I’m really self-conscious about my horrible English pronunciation and am a bit scared of talking. Not every Finn is embarrassed about the pronunciation, for instance the couple who are doing the The Hydraulic Press -channel in Youtube. I find it really awesome that they can speak what Finns usually call rally-english so freely

Concerning this blog, I think I am a bit too critical about my writing. I’m fairly confident with my grammar and spelling. But I just can’t seem to get the tone, tempo or structure right. I don’t like the sentence structures I come up with. Also, I pay much attention to the repeated uses of same words and phrases.

The criticality of my own writings is the biggest reason why it takes me a long time to create a post from start to finish. Just can’t seem to be satisfied with my posts.

What’s the point of this post? For one, I thought I’d convey some of the things that are going through my mind when I’m trying to put thoughts into words. One of the reasons for this whole blog thing is to improve myself. Not just technical skills but writing skills. This is not a plea to give me support or anything. Just some ramblings that came into mind while writing.

 

Unity3D Reflections – Part 2 – Limiting Access

In the last blog post we discussed how to do runtime-coupling or dependency injection using Reflections. I mentioned that I don’t think it’s really safe, because there wasn’t any way to control the injection. You could block the injector with adjusting the protection level for the property or by not using property for holding the reference. I think that’s the wrong way around the problem.

We could leave the disabling of property injection to the component, but don’t really like it. I’d much rather have a system where the user has to enable the injection for the property.

We’re going to use Attributes to handle the enabling of injection for the properties. We’re going to use the project from the last post and add on to it. But first, let’s scratch the surface of Attributes.

Attributes

Attributes are simply a way to attach metadata to your assemblies, types, methods, properties and such. Attributes can be easily accessed with Reflections. Attributes are attached to parts of code with square brackets and you most likely seen them used in Unity3D code.

Couple of examples from unity and C# itself

// Unity specific Attributes
// Hides the public variable from the inspector
[HideInInspector]
public Vector3 direction;

// Displays a header in Unity3d inspector
[Header("Player Health")]
public int health = 0;

// Set's the available range of the variable in the inspector.
[Range(0, 100)] 
public int speed = 0;

// Marks the private field to be serialized
[SerializeField]
private string name = "Some name";

// C# specific attributes
// Marks the class to be serializable
[Serializable]
public class SomeClass { /* ... */ }

// Imports the GetKeyState() method from user32.dll.
[System.Runtime.InteropServices.DllImport("user32.dll")]
public static extern short GetKeyState(int key);

 

An attribute is defined when a class inherits from System.Attribute class. Today, we will use only the bare minimum to create a CustomAttribute for our example project. For more details about the Attribute class, see Microsoft System.Attribute documentation.

I’m not going to use any of the predefined Attributes here. I’m planning on writing couple of posts about StructLayoutAttribute and as short one on Caller Information. Might do others too, if I find anything interesting.

The code

This is going to be short and simple. The amount of code we have to do to enable the EnableInject-attribute is almost criminal. To begin with, we need to create a class for the attribute. I’m going to call it EnableInjectAttribute.

using System;

[AttributeUsageAttribute(AttributeTargets.Property, AllowMultiple = false)]
public class EnableInjectAttribute : Attribute {
    public EnableInjectAttribute() {

    }
}

The AttributeUsageAttribute isn’t really necessary. It’s used to add limitations to the CustomAttribute. In our case, It makes the EnableInjectAttribute to be only usable with properties. Some of the other possible targets were mentioned in previous part. AllowMultiple part prevents us from using the EnableInject multiple times for a single property. It’s here mainly for displaying the option for enabling or disabling multiple usage.

Now we need to change the Injector itself.

using System.Reflection;
using System.Linq;
using System;

public static class Injector 
{
  // Simple static injector
  public static void InjectProperty<T>(GameObject gameObject, T dependency) 
  {
    // Go through the child objects
    foreach(Transform child in gameObject.transform) 
    { 
      foreach(Component childComponent in 
              child.gameObject.GetComponents<Component>()) 
      {
        // Using the power of LIQN to get the settable properties for 
        // the Components where we can read and write the value and 
        // is of type T
        var properties = childComponent.GetType().GetProperties().Where(
          prop => prop.CanRead && prop.CanWrite).Where(
            prop => prop.PropertyType == typeof(T));

        // If nothing of suitable type is found, properties variable 
        // should be null
        if(properties != null) 
        {
          foreach(PropertyInfo pi in properties) 
          {
            // Use SetValue of System.Reflection.PropertyInfo to set the value
            // of the property
            var a = Attribute.GetCustomAttribute(pi, typeof(EnableInjectAttribute));
            if(a != null) 
            {
              pi.SetValue(childComponent, (object)dependency, null);
            }
          }
        }
      }
    }
  }
}

I decided to show the whole code for clarity’s sake. (The highlight in PrismJS isn’t working correctly. Not sure why.) The code changes are on lines 31-36.

We call the GetCustomAttribute() for the PropertyInfo pi. We are only interested in attributes of type EnableInjectAttribute. Next we just check if the EnableInjectAttribute was found, and inject the dependency.

The last bit of code we need, is the part where we use the EnableInjectAttribute with the RigidBody property.

using UnityEngine;

public class Gravity : MonoBehaviour 
{
  // This is the property we'll be set with Injector.PropertyInject<>()
  [EnableInject]
  public Rigidbody GravityRigidbody 
  {
    get; set;
  }

  public float gravityForce = -9.81f;

  private void FixedUpdate() 
  {
    // Just to be sure, check if GravityRigidbody was set correctly
    if(GravityRigidbody != null) 
    {
      GravityRigidbody.AddForce(Vector3.up * gravityForce, ForceMode.Acceleration);
    }
  }
}

We don’t need to use the Attribute part of the attribute name when using it here.

Whole project is stored in github: https://github.com/jkelanne/Reflections-part_02

Next in the series

I’m probably doing a shorter post next time. It’s about something I ran into while exploring the Attributes: Caller Information. It’s not really needed in Unity3D or at least in the form I’m going to be using it. It’s something I was missing coming from C/C++.

Unity3D Reflections – Part 1

Those of you who are already familiar with managed languages might be familiar with reflections. Me, having a longer background in unmanaged programming languages, reflections as a concept are new and shiny. Reflections provide the ability for the program to examine and modify it’s own structure and behavior at runtime. In this post we are only going to be using a small portion of functionality provided by the C#’s System.Reflection library. Mainly, GetType()GetProperties() and SetValue(). Today, we are going to implement a simple way for injecting dependencies (properties in this case) to a child object (prefab). The example i’m using here is just an example. I tried to keep it as short as possible. In the example project we’re going to use dependency injection to pass parent object’s RigidBody component to a prefab which will apply acceleration force to that RigidBody component.

Unity Part

Let’s first create the Unity-editor stuff. We’ll need a 3D plane, a cube and an empty GameObject. Plane should have a collider by default, so no need to add anything. For the Cube, we’ll add a script named Cube.cs  and a RigidBody3D component. Rename the empty GameObject as Gravity, add Gravity.cs script and create a prefab out of it. Finally, add the newly created prefab under the Cube GameObject. The prefab part isn’t really necessary.
That’s all of the Unity-editor stuff done. Next up, the code.

C# Part

In the Cube.cs all we really have to do is to call the Injector.InjectPropert<T>() which will be covered in the last code snippet. We’ll give it the parent object to whose children we want to inject the given Component.
// Cube.cs
using UnityEngine;

public class Cube : MonoBehaviour 
{
  // Use this for initialization
  private void Awake() 
  {
    Injector.InjectProperty<Rigidbody>(
      this.gameObject, this.GetComponent<Rigidbody>());
  }
}
Next up is the code for the Gravity-prefab object. The important part is the public Rigidbody GravityRigidbody property. The rest of the code is just for demonstration purposes.
// Gravity.cs
using UnityEngine;

public class Gravity : MonoBehaviour 
{
  // This is the property we'll be setting 
  // with Injector.PropertyInject<>()
  public Rigidbody GravityRigidbody 
  {
    get; set;
  }

  public float gravityForce = -9.81f;

  private void FixedUpdate() 
  {
    // Just to be sure, check if GravityRigidbody was set. 
    if(GravityRigidbody != null) 
    {
      GravityRigidbody.AddForce(Vector3.up * gravityForce, 
          ForceMode.Acceleration);
    }
  }
}
Finally the most important part, Injector.cs. I decided to make it static and to keep it generic. We could define it under Cube.cs, but we might want to use it elsewhere. The most important parts of the code are the way we get the properties for Components (lines 19-21) and how we set the value for given Component (line 31)
// Injector.cs
using UnityEngine;

using System.Reflection;
using System.Linq;

public static class Injector 
{
  // Simple static injector
  public static void InjectProperty<T>(GameObject gameObject, T dependency) 
  {
    // Go through the child objects
    foreach(Transform child in gameObject.transform) 
    { 
      foreach(Component childComponent in child.gameObject.GetComponents()) 
      {
        // Using the power of LINQ to get the settable properties for 
        // the Components where we can read and write the value and 
        // is of type T
        var properties = childComponent.GetType().GetProperties().Where(
          prop => prop.CanRead && prop.CanWrite).Where(
            prop => prop.PropertyType == typeof(T));
        
        // If nothing of suitable type is foundt, properties variable
        // should be null
        if(properties != null) 
        {
          foreach(PropertyInfo pi in properties) 
          {
            // Use SetValue of System.Reflection.PropertyInfo to 
            // set the value of the property
            pi.SetValue(childComponent, (object)dependency, null);
          }
        }
      }
    }
  }
}
On the lines 19-21, what we’re doing is just getting all the properties from a Component under a child which can be written to and read from and are of type T (which is the RigidBody in our case).  If GetProperties() returns anything else than null, we know that we have a match. GetType() is quite straightforward. It returns the instance of Type class that contain information about the the object’s type. See Microsoft’s documentation for more information. We’re only interested about the GetProperties() method here. GetProperties() returns the list of properties. We’re using Liqn to go through the result. In line 31, we use System.Reflection.PropertyInfo.SetValue() to set the value of the property. Microsoft’s documentation defines SetValue as:
public virtual void SetValue (object obj, object value, object[] index);
  • obj – The object whose property value will be set
  • value – The new property value. Which in our case is the reference to Cube’s RigidBody
  • index – Optional index value. In our case this can be left as null. This is only used when dealing with indexed properties.

Limitations and problems

As you might have already noticed, the way we’re forcing the RigidBody to Cube’s children isn’t really that safe. We might have solved the coupling issue and made our lives a little bit easier, but at the same time we’re burdening ourselves with the notion that now we might have to handle disabling dependency injection for some parts of the code. What if two or more scripts wants to inject dependencies to the same child object? We’ll figure out ways to limit the Injector in some other post. GitHub link: https://github.com/jkelanne/Reflections-part_01

Hello World

This is the hardest part of this first blog entry. I should probably introduce myself somehow, but don’t really know what to say. Could say something about my hobbies and interest, but are they really that interesting? Anyhow, one of my longest hobbies has been programming, just can’t seem to get enough of it. I love learning new programming languages and techniques. For the past year or so I’ve been learning Unity3D and C#, and it’s been a blast. I also love baking, but I’m not that skilled so writing about it would be mainly embarrassing. There might or might not be some baking photos on my Instagram page (@null_pntr). I also read a lot, but this blog will most likely not contain any book related stuff. I also love video games, but lately I’ve just been too busy with other stuff and haven’t played anything for ages. Just reading about games and watching other play is enough for now.

My background

I’ve been programming on and off for the past 20 something years, though only around 10 years as a professional. I got my degree of Bachelor of Engineering from the Turku University for applied sciences. I specialized in embedded systems software and been working in that industry for the past 10 years. The company I’m currently employed at makes stuff that can be considered as medical devices. Most of my work related code is done using C and C++, but this blog is going to focus more on thing I do on my spare time. These things might include stuff in C and/or C++, but for starters I’m going to focus on Unity3D/C# stuff. Although, I have a blog series in mind which is related to Unity3D and will contain stuff in C++. I have a longish background in Linux, but will most likely not write anything about that. Unless I find something really interesting to write about.

Why I decided to start blogging

The main purpose for this blogs is learning. For me, one of the most effective ways of learning and instilling understanding of stuff, is to teach them to others. So the purpose is pretty selfish, but don’t mind if as a coproduct someone out there finds my rambling helpful. The other reason is my dislike of video tutorials and guides. Usually you waste 5-10 minutes just to realize that the provided solution or explanation doesn’t really suit your problem. With written stuff you can pretty quickly see if the text contains information related to your problem. Videos can be helpful too, but mainly for getting new ideas and viewpoints on things. The final reason is just that I might have done something awesome and really want to tell people about it. Or at least I think they might be awesome.

Some planned blog subjects

I have couple of blog series mind. The first one will be about Using C# reflections in Unity3D. Reflections are something totally new to me due to my background in unmanaged languages. The series will contain stuff about enabling dependency injection using reflections; Using reflections with ScriptableObjects; How reflections can aid you with Unity3Ds custom editor views. Second series I’m thinking about will be about Native DLL’s in Unity3D. We’ll create two simple DLL’s and use them in Unity3D. The example project won’t be anything really useful, but I’m thinking about using some exotic hardware with this. The reason for two DLL’s is: one will be made using unmanaged C++ and the other will be made using managed C++. Using managed DLL’s will be easier, but just in case one might require a “legacy” library in their project we’re going to check out usage of unmanaged DLL’s too. I might do a series about Finite State Machines and Tracker Mod music, but not really sure about those yet. I might include the Finite State Machine thing as an example for creating elaborate custom editor inside unity. The one big issue with these ideas is the size. I will put all of the example projects to GitHub. I’m not sure if I’m going to  include non-programming posts yet. At some point there might be things that I want to write about that aren’t technical. I’m still new to this blogging stuff so we’ll just have to wait and see.

Doges

Finally here are some pics of my dogs, enjoy.
Her name is Peppi.
And she’s called Kerttu (or Kepa)