• Pre-caching HTML templates with AngularJS ui-router directive

    Pre-caching HTML templates with AngularJS ui-router directive

    Unless you’re using gulp-angular-templatecache (which you probably should) to bundle your HTML templates into an Angular Javascript module, you might in some cases want to pre-cache certain HTML files. For example if you have a specific “error page” HTML template used to display a specific error message telling the user he lost his Internet connection. If you don’t pre-cache such a template, your Angular app won’t be able to fetch it from the server (because the browser is obviously off-line) and as a consequence it will be unable to display this important message.

    If you’re using ui-router, there is an easy way to pull the template from the server before it’s even used. I like having an abstract root state which I setup in my app.config() (inside app.js) to kind of abstract my base layout. Views from this root state can then be overridden by any child state which is very handy for having a few different types of layouts. For example, some with a sidebar, some without, etc.

    The cool thing about the abstract root state is that it will fetch all templates specified inside its views property even if they’re not used right away and it will put them into Angular’s template cache. The next time any of our child ui-router states requires one of these cached templates, it won’t make a request against the server but it will simply reuse the cached template.

    You can use this simple trick to if needed cache any other templates as well. Obviously don’t overdo it because you want to make the smallest amount of initial requests you can to speed-up the loading time. Or even better – use angular-templatecache, it’s wonderful. :)

    Cheers!

  • Global day of code retreat – Dublin, 2015

    Global day of code retreat – Dublin, 2015

    Yesterday I went to a very fine event organized by folks from Intercom here in Dublin. It was the global day of code retreat which is organized in many cities around the world. Initially I got interested because the topic of this years code retreat was Conway’s Game of Life which I had my eye on for some time now but the whole event turned out to be a really pleasant experience.

    The idea is very simple:

    • try to solve a simple problem – Game of Life in this case
    • do it with a partner for 45 minutes
    • add some kind of restrictions to make it more interesting and consider different approaches
    • you don’t really need to implement the whole thing
    • reflect on the session and wipe your code at the end of each one

    We ended up doing 5 or 6 sessions, each with a different person. What’s interesting is that the whole event wasn’t really about the Game of Life but the Test Driven Development approach. Usually one person would write unit tests, and the other one would work on the implementation of Game of Life rules. The restrictions that were placed on us were: use only primitive types, use only objects, do not talk to your partner (apparently everyone’s favourite)… It ended up being funny that my “silent session” partner didn’t really think it through nicely so he wrote his first unit test in such a way that I basically had to make the whole thing work before the first test passed. He realized it and later on added tests with smaller increments. :)

    What I really liked about the coding sessions was pair programming. This was my first real exposure to it and I loved it, I think it’s a great approach to coding. I felt like my concentration was boosted and that I was somehow more motivated because I was coding with someone else on the same thing at the same time. It also felt a bit more safe/secure because both people get to complement each others ideas and code. In general is timply felt more productive than programming on your own.

    It seems that everyone ended up doing all their stuff in Javascript because it turned out to be the most common language between the participants. I believe we all used tryjasmine which makes it really easy to write both the implementation and unit tests (in Jasmine JS testing framework) in browser with literally zero configuration. That’s quite handy for an event such as this.

    We got treated very well – organizers fed us, shoved coffee down our systems and even invited us for pints in a nearby pub afterwards. I got to meet some new, interesting people which was nice. Considering all of this, I was a bit surprised that only 7-8 people actually showed up for the event although it was a stay-late-in-bed kind of Saturday.. But whatever!

    I enjoyed it. Would come again. :D

    Thanks organizers!

  • Downloading/streaming Azure Storage private container blobs to AngularJS through .net WebAPI

    Downloading/streaming Azure Storage private container blobs to AngularJS through .net WebAPI

    When our Azure storage contains files that are meant to be publically accessible, it’s pretty trivial to deliver them to the end-user. We can either embed such items (e.g. images) or simply add links which point to them (e.g. pdfs) because Azure provides direct links to them. But what happens when these files contain sensitive data that is not meant for just anyone? Perhaps some kind of reports?

    Well, it gets a bit more complicated.. Since these files don’t have publically accessible URI’s any more, there are several steps which we need to go through:

    • Authenticate against Azure using SDK
    • Load the file into MemoryStream
    • Deliver the stream to the client (browser)
    • Convert the byte array into an actual file on the client-side and simulate “downloading”

    Since we’ll need more than just the MemoryStream, we’ll wrap it together with the file metadata into a model object.

    We will use AzureProvider class to authenticate against Azure, download the file from Azure and to create the model object.

    Our actual controller will inherit from this BaseApi class which contains a custom IHttpActionResult method which we can name AzureBlobOk. This is something pretty reusable so it’s good to have it at hand in your base class. What it does is it sets up all the content headers and it attaches the stream as the response content payload . It also returns HTTP status 200 which means OK – everything went fine.

    The actual controller is pretty simple..

    On the client side, we’ll need the following service to actually convert the byte array that we got from the API into something meaningful. I tried various approaches, but in the end decided to use FileSaver.js which “implements the HTML5 W3C saveAs() FileSaver interface in browsers that do not natively support it”. What it will do is turn the byte array into an actual file and prompt the user to download it.

    This service can easily be consumed by injecting it into your AngularJS controllers and calling the .getBlob() function which will do all the heavy lifting for you.

    Hope this helped, enjoy! :)

  • PdfSharp/MigraDoc to Azure Storage in-memory upload

    PdfSharp/MigraDoc to Azure Storage in-memory upload

    From my (somewhat limited) experience PdfSharp/MigraDoc seems like a pretty fine and powerful library for creating .pdf documents, but it’s documentation – not so much. It’s a bit all over the place and with multiple different NuGet versions/builds and outdated StackOverflow code samples not really helping the situation.

    However, creating a .pdf document in-memory and uploading it straight to Azure is not really that complicated. When might this be useful? For example when you need to generate a report but instead of immediately giving it to the user it just needs to get stored for later access.

    Magic word we’re looking for is MemoryStream. We’ll use two classes – one which will take a MemoryStream and upload it to Azure (AzureProvider.cs), and another one which will create a very simple MigraDoc document (ReportProvider.cs) which you can then build upon and then feed that document to the AzureProvider in the form of MemoryStream.

    The code is pretty straightforward and looks like this:

    Somewhat related – in the next post I’ll explain how to stream a file from Azure Storage private container through .net WebAPI to an AngularJS app.

  • Handling WebAPI exceptions with Angular http interceptor

    Handling WebAPI exceptions with Angular http interceptor

    It’s good to return meaningful HTTP status codes upon server exceptions. Whether it be invalid model state, conflict upon trying to create/update an object in the database, unauthorized access or something else it adds additional value and sends a message – one that’s different from generic 400’s or 500’s. These messages can then be used to take certain kinds of actions on the client side based on what happened.

    For example you could register a custom ApplicationExceptionHandler.cs inside your WebApiConfig.cs which would then be able to catch and handle any kind of exception thrown by lower server layers (such as business layer or the DB/ORM layer):

    You need to register ApplicationExceptionHandler in WebApiConfig.cs like this:

    You can also use something like ValidationFilter to take care of invalid model states in an easy way (by replying with a 422). After you have all your desired/needed exception handlers in place, it’s time to setup the client side. You can easily intercept every HTTP request and act upon responses from the server with an http request interceptor that looks like this:

    Now you have a centralized way to handle all kinds of WebAPI errors. Simply build upon this infrastructure and add whatever else you might need. In one of the future posts I’ll explain how to create basic html input element directives (for text, textarea, number, datetime and similar fields) which also seamlessly take care of modelState error messages by presenting them to the user just below the input element.

  • Handling .net’s model state with ValidationFilter attribute

    Handling .net’s model state with ValidationFilter attribute

    This is a simple ValidationFilter class which you can attach to any .net controller action method:

    What it provides is a “one-line” way to handle invalid model states. For example – instead of doing ModelState.IsValid check on each POST/PUT action, and then handling it manually again and again (by basically copying and pasting the same chunk of code all around your controllers) you can simply reuse the [ValidationFilter] attribute in front of your action and it will check whether the ModelState is valid. If it is, the action method will execute whatever code it has inside of it, and if it’s not the WebAPI will respond with a 422 (Unprocessable Entity) together with the associated ModelState error messages.

    For example if you had this model/action combination:

    …and you didn’t send any data to the WebAPI in your POST request, this is the 422 response that you would get back:

    This response can then be further parsed/handled by the client-side without problems.

Back to top