A day in the life of...

I love the idea of the Redux pattern, the way all reducers are pure and predictable. I love the way they are effectively listeners that act on event notifications received from a central dispatcher, and I really like the way the whole approach simplifies the application and makes code in my Angular app's components only concerned with view related concerns rather than business logic. However, what I am not a big fan of is the normalised data approach. I've seen it recommended so many times for use with the Redux approach. You essentially have any object (read "row from table on server") in memory once and then everywhere else you hold a reference to the locally stored record/object by its unique ID. So, a view state you receive that looks like this [ { "id": "Emp1024", "name": "Peter Morris", "address": { "id": "123", "street": "xxx" } }, { "id": "Emp4096&qu

public static class AssemblyLoader { private static readonly ConcurrentDictionary<string, bool> AssemblyDirectories = new ConcurrentDictionary<string, bool>(); static AssemblyLoader() { AssemblyDirectories[GetExecutingAssemblyDirectory()] = true; AppDomain.CurrentDomain.AssemblyResolve += ResolveAssembly; } public static Assembly LoadWithDependencies(string assemblyPath) { AssemblyDirectories[Path.GetDirectoryName(assemblyPath)] = true; return Assembly.LoadFile(assemblyPath); } private static Assembly ResolveAssembly(object sender, ResolveEventArgs args) { string dependentAssemblyName = args.Name.Split(’,’)[0] + ".dll"; List<string> directoriesToScan = AssemblyDirectories.Keys.ToList(); foreach (string directoryToScan in directoriesToScan) { string dependentAssemb

1: Run dotnet restore to restore package dependencies. 2: Run dotnet build to build the binaries. 3: Run dotnet test to run the tests. Note the additional parameters --no-build to prevent a rebuild and --logger "trx;LogFileName=tests-log.trx " to ensure the test results are written to disk, 5: Use  a Publish Test Results tasks to output the results of the tests. Make sure you set the following properties Test Result Format = VSTest Test Results Files = **/tests-log.trx And under the Advanced section make sure you set the Run This Task option so that it will run even if the previous task failed.

import { PipeTransform, Pipe } from "@angular/core"; @Pipe({ name: 'keys' }) export class KeysPipe implements PipeTransform {   transform(value, args:string[]) : any {     return Object.keys(value);   } } Then to get a list of errors for a form element you can do this <ul *ngIf="form.get('userName').invalid" class="help-block with-errors">    <li *ngFor="let error of form.get('userName').errors | keys">{{ error.key }}</li> </ul>

I was trying to get a list of a type's constructors at runtime using reflection, so that I could create an instance of the class using dependency injection. All worked just fine until we tried to build the app for iOS. At first we were using Mono as the scripting back-end, but it seems that new versions of iOS pop up a dialog telling the user the app is 32 bit and may run slowly (i.e. "Your app is crap"). When switching the backend scripting to IL2CPP (in File->Builder->Player Settings) the app suddenly wasn't working. It turns out that SomeType.GetConstructors().Count was returning zero, which was a problem because obviously I wanted to invoke those constructors with dependencies. The problem was that because these constructors weren't being calling explicitly from anywhere in my app IL2CPP decided I didn't need them, and stripped them out. The solution is to create a file in your Assets folder called link.xml and fill it in like so.... <lin

Unity3D has a Screen class with an orientation property that allows you to force orientation in code, which lets you have different scenes with different orientations (useful in mini-games). this works fine for Android but crashes on iOS. The problem is the file UnityViewControllerBaseiOS.mm that gets generated during the build for iOS has an assert in it which inadvertently prevents this property from being used. It is possible to create a post-build class that runs after the iOS build files have been generated that can alter the generated code before you compile it in XCode. Just create a C# script named iOSScreenOrientationFix.cs and paste in the following code - adapted from  this Unity3D forum post . using UnityEngine; using UnityEditor; using UnityEditor.Callbacks; using System.IO; namespace Holovis { public class iOSScreenOrientationFix : MonoBehaviour { #if UNITY_CLOUD_BUILD // This method is added in the Advanced Features Settings on UCB // PostBuildProc

I've recently been working on implementing an IHttpService that can work outside of a MonoBehaviour and call out to web services asynchronously. Rather than providing my IHttpService.JsonPost method with callbacks I decided to have it return a Promise, the code for which I took from this  Real Serious Games  GitHub repository. The problem is that when you use WebClient's async methods they call back the Complete events on the worker thread, so code like this won't work because you cannot manipulate UI from any thread other than the main one. httpService.JsonPost<MyInfo>(url)   .Then(myInfo => someTextUiObject.text = myInfo.Name); And there seems to be no kind of thread Dispatcher in Unity3D for UI updates as there is in Windows.Forms - so I wrote my own. using System.Collections; using System; using System.Threading; using System.Collections.Generic; using UnityEngine; public class UiThreadDispatcher : Singleton<MonoBehaviour> {     static volatil