linkedin.svg

LinkedIn

large_Tomek-iOS.jpg

medium_Tomek-iOS.jpg

small_Tomek-iOS.jpg

thumbnail_Tomek-iOS.jpg

Tomek-iOS.jpg

When building an application with _XCode_, we have an option to set the **Enable Bitcode** flag to either **YES** or **NO** via _Build Settings > Build Options_.
By embedding bitcode (setting the flag to _YES_), we give Apple an opportunity to rebuild our application on their side and optimize it further, without being required to upload a new build. It can happen, if some bugs in the compiler are fixed, or a new device type with a new architecture type is introduced.

There are some situations, however, that we might want to disable this functionality altogether.
- The project with bitcode enabled requires all of its frameworks to be compiled with bitcode support as well. Sometimes, the third-party dependencies that we use, are compiled without it, or are created with newer versions of the compiler, that we cannot support yet in our project for some reason.
- Another scenario is related to _dSYM_ files and crash reporting services, which require these files to present a crash report that is informative and readable for us. Now, as the bitcode is enabled, the final _dSYMs_ are produced by Apple. It means that we would have to download them from the portal and then upload them to the third-party service of our choice.

In the _Unity game engine_, the bitcode is enabled by default with no options in project settings to disable it and it is also suggested to leave it **enabled**. However, due to the situations described above, we might actually have to _disable_ it. To do so, we would have to generate a XCode project and then change it in build settings _manually_ every time we create a build - which is inefficient.
Fortunately, we have **Scriptable Build Pipeline (SBP)** at our disposal, which will allow us to automatically modify projects generated by XCode whenever we trigger a build.
Create a new file in _Assets > Scripts > Editor_ directory called _IOSBitcodePostprocessor.cs_ and paste the following as the content:

````csharp
using UnityEditor.Callbacks;
using UnityEditor.iOS.Xcode;
using UnityEditor;
 
public sealed class IOSBitcodePostprocessor
{
   public static bool enableBitcode = true;
  
   [PostProcessBuildAttribute]
   public static void OnPostprocessBuild(BuildTarget target, string pathToBuiltProject) {
       switch(target) {
           case BuildTarget.iOS:
               setupBitcode(pathToBuiltProject);
               break;
           default: break;
       }
   }
 
   private static void setupBitcode(string pathToBuiltProject) {
       var project = new PBXProject();
       var pbxPath = PBXProject.GetPBXProjectPath(pathToBuiltProject);
       project.ReadFromFile(pbxPath);
       setupBitcodeFramework(project);
       setupBitcodeMain(project);
       project.WriteToFile(pbxPath);
   }
 
   private static void setupBitcodeFramework(PBXProject project) {
       setupBitcode(project, project.GetUnityFrameworkTargetGuid());
   }
 
   private static void setupBitcodeMain(PBXProject project) {
       setupBitcode(project, project.GetUnityMainTargetGuid());
   }
 
   private static void setupBitcode(PBXProject project, string targetGUID) {
       project.SetBuildProperty(targetGUID, "ENABLE_BITCODE", enableBitcode ? "YES" : "NO");
   }
}
````

This code will modify every iOS build triggered by the Unity game engine by applying the desired value to the **Enable Bitcode** flag to **both** targets (main & framework). We can now change it easily, by modifying `enableBitcode` variable on top of the script. We use an attribute called `PostProcessBuildAttribute` to mark a method as being our entry point for the Scriptable Build Pipeline post processor, in which we check what platform we are currently building for and act accordingly.

medium_today i learned - bitcode.png

small_today i learned - bitcode.png

thumbnail_today i learned - bitcode.png

today i learned - bitcode.png

Enable bitcode flag support through the Scriptable Build Pipeline (SBP) in the Unity game engine.

TIL: Enable Bitcode flag in Unity

# Introduction

_Reactive Programming_ is a programming paradigm that focuses on data streams and events. It is inspired by the _Observer_ pattern, _Iterator_ pattern and _functional programming_. It allows us to describe applications in such a way, that whenever a new set of data is emitted by the stream, the chain of operations is applied to that data to either emit a transformed value or perform some operations with the use of this data by subscribing to stream changes.
The paradigm is provided by _ReactiveX_ libraries, which are available in various programming languages (full list is available [here](https://reactivex.io/languages.html)).
Since reactive programming operates on asynchronous data streams, to understand this approach, it might be helpful to get familiar with asynchronous programming in the Unity game engine described in my [previous article](https://tomasz-lewandowski.appunite.com/post/unity-asynchronous-programming).

# Reactive Extensions for .NET

Reactive Extensions for .NET (_Rx.NET_ for short) is an official and open-source implementation of Rx for C# language that brings the power of reactive programming to the .NET platform by extending the use of _LINQ_ (Language Integrated Query) operators to asynchronous collections. In fact, it was the first implementation of reactive extensions in history. It would be our first pick, but unfortunately, it does not work with the Unity game engine and has problems with the iOS _IL2CPP compiler_.

# UniRx - Reactive Extensions for Unity

_UniRx_ is a reimplementation of _Rx.NET_ designed specifically for the Unity game engine. It can be integrated into the project by using the [Unity Asset Store](https://assetstore.unity.com/packages/tools/integration/unirx-reactive-extensions-for-unity-17276) or Unity’s package manager. If you choose the later option, you can go to the project's [GitHub](https://github.com/neuecc/UniRx#upm-package) for more information. It can also be used smoothly with the [UniTask](https://github.com/Cysharp/UniTask) introduced in my [previous article](https://tomasz-lewandowski.appunite.com/post/unity-asynchronous-programming). So as the possibility of reactive programming is now open for us, let's move to the problem example.

# The problem

In this article, we will assume that a player is able to spawn fireballs in our game.
To do so, they have to tap a spacebar or an UI button. Then, the fireball spawns and the cooldown is applied, so the next one will not be spawnable for a certain amount of time.
We will review two solutions to do this exact thing:
- The first of them will be a classic approach of combining the `Update` function for spacebar checking and assigning a callback to a UI button.
- The second approach will use reactive programming to solve the same problem.

As both solutions will require a similar setup, it will be covered briefly in this section, but the article assumes that you have basic knowledge of the Unity game engine. To keep things simple, we will leave actual spawning of fireballs as an implementation detail.
So to keep going, we need an object that we will later on attach a script to. For this purpose, we can add a cube to a scene. We also have to create a canvas and a button inside of it, which will provide us with everything that we need.

### Solution 1: Non-reactive

First of all, we have to create a new `MonoBehaviour` and attach it to our cube. The next step will be to prepare entry points for both fireball spawn cases. The key-pressed check will be performed on every update and, for the button click, we have to prepare a separate method that will be bound through the editor. To be visible in the editor, the method has to be marked as `public`.
So the `MonoBehaviour` skeleton may look as follows.

```csharp
public class UpdateBehaviour : MonoBehaviour
{
   void Update()
   {
   }
 
   public void onButtonClicked()
   {
   }
}
```

Then, in the editor, we have to select our button and, in the *OnClick* section reference, the `onButtonClicked` method of our cube’s `UpdateBehaviour`.
As we are done with the setup, now we can proceed to the implementation.
First, let’s define both cases of spawning a fireball. So in the `Update` method, we can check if the spacebar is being pressed by using the `Input.GetKeyDown`, provided for us by the Unity game engine. If that’s the case, we can schedule a cooldown check and fireball spawning. The UI button tap handler can call this logic directly.

```csharp
void Update()
{
   if (Input.GetKeyDown(KeyCode.Space))
   {
       spawnFireballIfNotCoolingDown();
   }
}

public void onButtonClicked()
{
   spawnFireballIfNotCoolingDown();
}
```

In order to satisfy the cooldown check, we have to introduce a cooldown field. It will hold time left that needs to pass before we can fire another fireball. As we start with no cooldown, we initially assign a value of 0 to the variable. We introduce another helper property to determine if the cooling down really happens at any given moment.

```csharp
private float cooldown = 0.0f;
private bool isCoolingDown => cooldown > 0;
```

The actual cooldown check will be the implementation of the `spawnFireballIfPossible` method.
It will check whether or not the cooldown has already passed and apply appropriate logic for each case.

```csharp
private void spawnFireballIfNotCoolingDown()
{
   if(isCoolingDown)
   {
       reduceCooldown();
   }
   else
   {
       applyCooldown();
       spawnFireball();
   }
}
```
So this would be an abstracted logic for spawning fireballs by utilizing the classical approach without applying reactive programming.


### Solution 2: UniRx

As with the first solution, we have to prepare our `MonoBehaviour`. This time however, we will setup everything in the `Start` method. We will need a field that will hold a reference to our button, so that we can observe clicks that are performed on it and act accordingly. We will make the field `public` so that it’s actually available in the editor and we can set up the reference there.

```csharp
public class ReactiveBehaviour : MonoBehaviour
{
   public Button button;
 
   void Start()
   {
   }
}
```

After tying everything together, we can move to reactive programming itself. First of all, we will create an observable that describes our first scenario - the spacebar pressing. We can define the logic inside the `Start` method. There is no possibility to react on the keystrokes itself, so we will have to do a manual check on every update. Since we will actually have two different events that we want to react to in a single subscription, we need to make sure the result of each of the observables is of the same type. To ensure that, we can map the result of each observation by using the `Select` operator and change it to the `Unit` instance, indicating that the result is not important.

```csharp
var spaceObservable = Observable
   .EveryUpdate()
   .Where(_ => Input.GetKeyDown(KeyCode.Space))
   .Select(_ => Unit.Default);
```

The second event that we want to observe is the interaction with the button. _UniRx_ provides multiple extension methods. One of them is just what we need, because it will emit an event on every button tap, so basically it solves our problem. As previously, we have to map the result to the `Unit` using the `Select` method to unify the results.

```csharp
var buttonObservable = button
   .OnClickAsObservable()
   .Select(_ => Unit.Default);
```

Now that we have all of the cases covered, we can implement the logic that will act on them.
To act on multiple observables, we can use the `Merge` operator, which will emit an event whenever any of the observables that's being merged, emits its own one.
Our problem solution has to include a cooldown mechanic. To accomplish this, we can make use of the `ThrottleFirst` operator and pass a cooldown duration as an argument to it. What the operator will do, is that it will emit only the first event out of all the events that happen in a particular time window and ignore the rest. Once the time window is complete, it will allow the emission of events again.
We have our cooldown mechanic - that’s cool. We are ready to actually subscribe to the events and spawn our fireball by passing a _lambda_ to the `Subscribe` method, so we end up with the following piece of code.

```csharp
Observable.Merge(spaceObservable, buttonObservable)
   .ThrottleFirst(TimeSpan.FromSeconds(3))
   .Subscribe(_ => spawnFireball());
```

We’ve completed the part of code that does the logic. But in a reactive world, we have to remember and do one more thing. What we’ve created is a subscription that will go on and on with every emission of the event that happens in these two scenarios. We would actually like to stop this behaviour when the object gets destroyed. Every call to `Subscribe` returns a _cancellable_ that we can hold in a field or variable and call `Dispose` on it, whenever we want to stop the subscription. If we had many subscriptions going on and we would like to cancel all of them, it might get really inefficient to do so separately. _UniRx_ provides us with a `CompositeDisposable` that we can add the cancellables to and keep them all together for easier management. Let’s define a field that will hold this disposable for us.

```csharp
private CompositeDisposable _compositeDisposable;
```

As a next step, we should create an instance of it, so we can add the following code at the top of the `Start` method to do so.

```csharp
_compositeDisposable = new CompositeDisposable();
```

Now, having it set up, we can attach the cancelable to the disposable we’ve defined.
To do so, we have to add another step after our `Subscribe` call, which would be calling `AddTo` on the result as follows:
```csharp
.AddTo(_compositeDisposable);
```

The actual disposal of the subscriptions in our case will happen on _GameObject_ destruction. In the Unity game engine, we can do this by providing `OnDestory` method in the script we’ve just created.

```csharp
private void OnDestroy()
{
    _compositeDisposable.Dispose();
}
```

By writing this down, we actually have finished our Rx solution to the problem we’ve previously defined.

# Conclusions

As you can see, reactive programming lets us describe and combine our logic in a more event-based approach by using asynchronous streams. We’ve learned that we can bring it to the Unity game engine by integrating _UniRx_ to the project. By the way, some of the operations done on observables can be treated like queries, so it even opens the possibility of using _LINQ query syntax_ on them if you wish.

large_pablo-molina-W-coJc40SeQ-unsplash.jpg

medium_pablo-molina-W-coJc40SeQ-unsplash.jpg

small_pablo-molina-W-coJc40SeQ-unsplash.jpg

thumbnail_pablo-molina-W-coJc40SeQ-unsplash.jpg

pablo-molina-W-coJc40SeQ-unsplash.jpg

Bringing the reactive programming world to the Unity game engine with UniRx.

Introduction to Reactive Programming in Unity

javier-allegue-barros-C7B-ExXpOIE-unsplash.jpg

large_javier-allegue-barros-C7B-ExXpOIE-unsplash.jpg

medium_javier-allegue-barros-C7B-ExXpOIE-unsplash.jpg

small_javier-allegue-barros-C7B-ExXpOIE-unsplash.jpg

thumbnail_javier-allegue-barros-C7B-ExXpOIE-unsplash.jpg

Executing tasks over several update calls?
Let's explore different approaches to asynchronous programming in Unity game engine.

Executing tasks over several update calls? Let's explore different approaches to asynchronous programming in Unity game engine.

Tomasz Lewandowski

TIL: Enable Bitcode flag in Unity

Introduction to Reactive Programming in Unity

Introduction to asynchronous programming in Unity