Jeremy S Brown

Professional Learner with a Passion for Writing Software

cyaFramework

by Leave a Comment

So I’ve decided it was time to start stepping out of my comfort zone and start sharing code I’ve been writing over the years. I want to put them into a series of libraries and stop reinventing the wheel. The primary goals for this project is to:

  1. Stop working in a vacuum by sharing the code and getting feedback.
  2. Make myself write more and better tests. This by far my most negated skill, and I am willing to admit that now.
  3. Write more blog post about my code.

The link to my GitHub repository is:
https://github.com/JeremySBrown/cyaframework

It is blank at the moment, but that will hopefully change here real soon. I plan to start with my base domain and repository patterns. As I add a new library they will start out as a Portable Class Library targeting:

  1. .NET Framework 4.5
  2. Windows 8.1
  3. Windows Phone 8.1
  4. Xamarin.Android
  5. Xamarin.iOS

This may not be practical for each library, but since this is the domain that I work in these days this is where I want to start. I have a love/hate relationship with PCLs and may need to rethink this for some libraries in order to target each platform.

If you have stumbled across this blog post and decide to check it out please contact me if you have any questions. Constructive criticism is most welcome, and if you are a TDD/BDD guru any testing tips would be most appreciated.

 

Note To Self: Async Calls in Property Setter

by Leave a Comment

Recently came across a need to make an async call within a property’s setter. Ok no big deal I’ll just add “async” to the property and use await. Unfortunately this is no allowed, but after a little research I found there is a way to make this happen and thankfully it’s just a line of code. Within the property setter logic do the following:

Deployment.Current.Dispatcher.InvokeAsync(async () => await MyMethodCallAsync());

ASP.NET Web Optimizations and AngularJS

by Leave a Comment

When adding AngularJS to your ASP.NET MVC project that also takes advantage of bundling you may be in for a surprise when you deploy to your production site. Your AngularJS code will no longer work! A quick check of your favorite debugging console will show an error similar to this one:

Uncaught Error: [$injector:modulerr] Failed to instantiate module myApp due to: Error: [$injector:unpr] Unknown provider: n

The reason for this is due to your AngularJS code being minified and the parameter names that AngularJS rely on for dependency injection have been changed. Fortunately there is a way to min-safe your code and still take advantage of ASP.NET Web Optimization.

Typically when defining modules and using the inline functions when defining controllers like so:

var myApp = angular.module("myApp", []);
myApp.controller("controller1", function ($scope, $http, $log) {…});

You replace the inline function with a inline bracket notation that passes an array of strings that represents the parameter names to be injected into the function. So the above sample code is now:

var myApp = angular.module("myApp", []);
myApp.controller("controller1", ["$scope", "$http", "$log", function ($scope, $http, $log) {…}]);

If you are not using an inline function but rather passing the name of a function the same bracket notation works as well. Also this notation will also be needed when defining services or any other AngularJS construct that will be relying on dependency injection.

There are other solutions to this problem like using the $inject property and passing the array of strings for dependency names. Personally I found this method more clunky, but check out the AngularJS documentation for more detail if you’re interested.

If you are using inline functions you can check out “ngmin”. This is a pre-minifier that will modify your code to make it min-safe. This requires using Node.js and again personally I found this be rather clunky when working in ASP.NET. Manually making the changes is just a little more work, but worth it.