Monday, July 11, 2016

Web API with ASP.NET Core MVC

I was exploring the new ASP.NET Core from Microsoft and being on a Mac, to start things off, I was following this guide, which includes setting up .NET Core and Visual Studio Code with the C# extension + scaffolding a template project using Yeoman. Pretty simple and works out of the box.

Now, to get going with Web API, the next guide would be https://docs.asp.net/en/latest/tutorials/first-web-api.html. However, this is based on Visual Studio 2015, where there are ready-made templates for a Web API project. I continued using the guide with my Yeoman template to see how far it would take me.

Turns out that I got pretty far, by just following the examples. The first thing that hit me was the change in the

ConfigureServices
file, namely the
services.AddMvc();
method. There was no notion of a MVC-framework in the generated Yeoman code, and I had to add
"Microsoft.AspNetCore.Mvc": "1.0.0"
to
project.json
to make it compile. To finally get the application to serve my API instead of the generated "Hello World" page, I changed
app.Run(async (context) =>
  {
    await context.Response.WriteAsync("Hello World!");
  });
to
app.UseMvcWithDefaultRoute();
To wrap things up, I changed the default namespace from
EmptyWeb1
to
TodoApi
to make things consistent.

At the very end of the guide, I also found the link to the source code, which could have saved me from figuring things out for myself.

/Mattias

Saturday, December 6, 2014

Locked rotation on Ipad - The Last Resort

I've been having a lot of issues over the past year with my Ipad's rotation being locked. I think I've been through every support page, blog and even youtube videos in search for a solution. Sure, I've been reading about all the obvious stuff, like checking that "Lock Rotation" isn't enabled (either through swiping up to get to the shortcut menu, or through the side switch option), or rebooting the device by pressing the home and lock screen button for about 10 sec.

In fact, rebooting used to work most of the time, but only if I made sure to quit all running applications before doing it. I.e. double-click the home button and swipe up on all open applications. Seems like some applications manage to lock the rotation indefinitely. Anyway, this time it's not working! Once in a while, it starts working for a day, or two, and then it's locked again. It usually starts working after an iOS update, like the latest 8.1.1, but soon starts locking again.

Now, to The Last Resort! I was really looking forward to watch a movie on the Ipad the other day, but wasn't really that keen on doing it in portrait mode. So, in order for force the device into landscape mode, I found this little thing called "AssistiveTouch". It's hidden under "Settings->General->Accessibility->AssistiveTouch" and will, if you enable it, show a black control button on your screen. Click the control button and choose "Device->Rotate Screen" and choose to rotate it anyway you want. Violá!

Monday, February 24, 2014

Handlebars integration with Yeoman’s webapp-generator

I was looking for an instruction on how to add Handlebars to my application based on Yeoman’s webapp-generator. There is an instruction on the old wiki on GitHub, but it’s out-of-date. For this exercise I’ve been using Yeoman 1.1.2 and the 0.47 version of the webapp-generator.

First off, go ahead with step 1 and 2 (but obviously using the latest versions).

There’s no need to load the "grunt-contrib-handlebars" in your Gruntfile.js (step 3), as "require('load-grunt-tasks')(grunt);" is used to load all referenced tasks.

I did some changes to the file structure in step 4, but I guess that’s a matter of taste? One thing to note is the change from “temp” to “.tmp” as this is the temporary directory name being used in other places:

handlebars: {
  compile: {
    files: {
      '.tmp/scripts/compiled-templates.js': [
        '<%= yeoman.app %>/templates/**/*.hbs'
      ]
    },
    options: {
      namespace: 'MyApp.Templates',
      wrapped: true,
      processName: function(filename) {
        // funky name processing here
        return filename
                .replace(/^app/, '')
                .replace(/\.hbs$/, '');
      }
    }
  }
}

The watch task needs some additions to it, as well (step 5). Note the addition on watching .js-files in livereload:

handlebars: {
    files: ['<%= yeoman.app %>/templates/*.hbs'],
    tasks: ['handlebars']
},
livereload: {
    options: {
        livereload: '<%= connect.options.livereload %>'
    },
    files: [
        '<%= yeoman.app %>/{,*/}*.html',
        '.tmp/styles/{,*/}*.css',
        '.tmp/scripts/{,*/}*.js',
        '<%= yeoman.app %>/images/{,*/}*.{gif,jpeg,jpg,png,svg,webp}'
    ]
}

Step 6 handles the configuration of Handlebars tasks being run during build, test and serve:
// Run some tasks in parallel to speed up build process
concurrent: {
    server: [
        'compass:server',
        'copy:styles',
        'handlebars'
    ],
    test: [
        'copy:styles',
        'handlebars'
    ],
    dist: [
        'compass',
        'copy:styles',
        'handlebars',
        'imagemin',
        'svgmin'
    ]
}

Don't forget to get the actual Handlebars package using "bower install handlebars" (step 7).

In step 8, as I changed the file structure - just add
<script src="scripts/compiled-templates.js"></script>
and you're done!

/Mattias

Tuesday, November 5, 2013

Loading Google Maps API asynchronously with RequireJS

With Single Page Web Applications becoming more and more popular, I decided to understand the concepts of various Javascript frameworks a little better. There are literally hundreds of them, but I decided to start with a really nice tutorial written by Alex Young. Cornerstones in this tutorial are BackboneJS, Underscore, Bootstrap and RequireJS.

After been through the tutorial I decided to roll my own project based on the same setup. I wanted to use Google Maps for this, and searched for a way to load the API using RequireJS. Turned out that there are a few different approaches, but the most common seems to be to use the async-plugin created by Miller Medeiros.

Jason Wyatt has another interesting solution which caught my attention. Being new to all this, I really didn't feel like start involving plug-ins from remote repositories. It might be the most natural thing to do, but one step at a time is more my melody.

Jason's solution had some drawbacks mentioned in the comments of his post, such as the way Google loads itself asynchronously and how the return value will be an empty stub before everything is loaded. I guess the point is to put the actual maps implementation in the anonymous callback function, but I'd rather have more separation between the loading mechanism and the implementation. The same actually applies to the async-plugin solution, as far as I can tell.

I updated Jason's implementation to look like this:

  define(['config'], function(config) {

    function AsyncLoad(callback) {
      // create a global callback method for Google to use
      var callbackName = 'googlemaps'+(new Date()).getTime();
      window[callbackName] = callback;

      // load the api asynchronously
      require(['http://maps.googleapis.com/maps/api/js?key=' + config.apiKey + '&sensor=false&callback=' + callbackName], function(){
        // do nothing and wait for callback instead
      });
    }

    return AsyncLoad;
  });
The way to use it is to instantiate it with a callback function as an argument. And the key is to make this function operate on the calling object and not from the window object, i.e. 'this' should point to the calling object. This is where Function.prototype.bind comes in, as it creates a new function where the 'this' keyword is bound to the supplied value.

This is how to use it:

define(['asyncload'], function(AsyncLoad) {
  var App = function() {
    this.loadMaps();
  };

  App.prototype = {
    loadMaps: function() {
      var asyncLoad = new AsyncLoad(this.renderMaps.bind(this));
    },
    renderMaps: function() {
      console.log(this); // the App
      var mapOptions = {
        zoom: 8,
        center: new google.maps.LatLng(-34.397, 150.644),
        mapTypeId: google.maps.MapTypeId.ROADMAP
      }
    }
  };

  return App;
});
The callback function is bound to the App and the renderMaps-function will be called just as if it was done from the the App itself. Now, the good thing that comes out of all this is that the renderMaps-function holds all code related to Google Maps, no matter how it was loaded.

Wednesday, November 28, 2012

Greasemonkey to rescue!

Greasemonkey is an add-on to Firefox that seems to prove to be really useful, so I wanted to give it a spin.

Basically, what it does is to modify webpages on-the-fly as you load them - using JavaScript. Many times I guess people use it to get rid of nasty ads and so forth. There are plenty of other add-ons able to do that - like removing a specific element each time, which doesn't require any coding. What fun is that?

Nonetheless, my first Greasemonkey-script does just that - removes an ad. But for the site in question - www.di.se (all in Swedish) - it isn't as easy as removing an element. The site is divided into 3 rows using a frameset that looks like this:

 
<frameset frameborder="no" framespacing="0" rows="0,210,*">
<frame class="noprint" frameborder="no" framespacing="0" name="historyFrame" noresize="" scrolling="no" src=""></frame>
<frame class="noprint" frameborder="no" framespacing="0" name="headerFrame" noresize="" scrolling="no" src=""></frame>
<frame class="" frameborder="no" framespacing="0" name="contentFrame" noresize="" scrolling="auto" src=""></frame>
</frameset>
As you maybe can tell, removing the second frame (which contains the 210px ad) doesn't cut it, because the third frame (content) will now take it's place.

This is where Greasemonkey comes to rescue! Creating the following script tells Greasemonkey to change to rows-attribute of the frameset to hide the ad frame, allowing the content frame to use all available space:

// ==UserScript==

// @name          Clean up di.se
// @namespace     http://www.technowobble.com
// @description   Removes the top add from www.di.se
// @include     http://www.di.se/
// @grant       none
// ==/UserScript==

var frameset = document.getElementsByTagName('frameset');

if (frameset[0]) {
 frameset[0].rows="0,0,*";
}
It will only be applied to http://www.di.se/ (notice the trailing slash which seems to be required) and I will never have to see the ad again. Sweet. But what more can you do with it? Anything, from removing ads, changing look & feel etc, to do automatic user interface testing or exploiting vulnerabilities, I guess?

Tuesday, August 28, 2012

Fighting Dell!

Ok - so I've been having trouble with my Dell Latitude e5410. What kind of trouble, you ask? Well, I discovered it when listening in on my favorite tunes on Spotify. Intermittent there was a "buzzing" sound for a brief moment, like if my headphones weren't properly attached, or poorly fitted into the jack.

This happened 5-10 times per song and was really annoying me, but I couldn't really figure out what it was. Tried a couple of things, like testing with different headphones, downloading new audio drivers, but it never when away. It even occurred when listening without headphones. And no matter if it was streaming media or music on from my local library.

So I gave up. Sigh! Stopped listening on music while working, that is.

Half a year later, and some hours to kill, I started searching for a solution (again). But how do you Google it? "Dell sound noise"? "Dell e5410 audio buzz"? No luck.

Turned out the magic word was "music", as this issue is most annoying when listening on favorite music, it seems. I finally found this thread, which didn't specifically mention the e5410. It eventually led me to try to upgrade the Intel Storage Controller provided by their Rapid Storage Technology anyway. Simply downloaded the driver from Intel and installed it.

Problem solved. Thanks to a dedicated community. Really - big thank you! Wish Dell was monitoring their own community and supplied hot fixes to issues like these. The driver download section isn't very helpful, even with your computer's identity tag supplied...

Friday, November 25, 2011

Getting filters to play nicely with Spring

After having some struggle with getting filters to integrate well with my Spring context, I decided to write down a small tutorial for it...

To begin with, filters are defined in web.xml and are therefore not automatically part of the Spring application context, which is normally set up using the DispatcherServlet. A good way to abstract away all this is to use the DelegatingFilterProxy, which is a Spring utility class that acts as a filter, but will delegate the doFilter-method to a Spring-managed bean - normally a class extending GenericFilterBean.

As a filter is defined in web.xml and looks for the bean defined in the Spring context in applicationContext.xml, it's not really the set up that I want. Filters are part of a web application and should have access to what's usually defined in webmvc-config.xml, as part of the DispatcherServlet set up. To be able to use, e.g. request scoped beans in applicationContext.xml, you need to defined them as proxied objects in order to have them looked up at a time where the web context is available.

The small application I'll be showing here is set up with an example filter that stores a request header value into a request scoped variable which is available as a Spring bean, and can therefor be autowired in any other Spring bean later on in the execution of the request. This demonstrates a nice way to have a loose coupling between the different components, without having to e.g. pass the information in method variables. It also gives the ability to test the components outside a web context.

To begin with, a normal filter definition using the DelegatingFilterProxy needs to be added to web.xml:

    
    
        Header Filter
        org.springframework.web.filter.DelegatingFilterProxy
        
        
            targetBeanName
            headerFilter
        
    

    
        Header Filter
        /*
    


Make sure the init param "targetBeanName" is set to the name of the Spring bean to delegate to (or rely on the default, where the filter's name is used to look up the bean). Now, let's have a look at the definition of the Spring filter bean and the request scoped bean in applicationContext.xml, incl. the acutal implementation of the filter:

    
    

     
    
        
   


Note how the request scoped bean is defined to be a proxied, using
.

    package com.technowobble.web;

    import java.io.IOException;
    import javax.servlet.FilterChain;
    import javax.servlet.ServletException;
    import javax.servlet.ServletRequest;
    import javax.servlet.ServletResponse;
    import javax.servlet.http.HttpServletRequest;
    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.web.filter.GenericFilterBean;

    /**
     * Intercepts all incoming requests and parses out Ninaa headers into a session scoped variable.
     */
    public class HeadersFilter extends GenericFilterBean {
        @Autowired
        private Headers headers;

        @Override
        public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
            if (request instanceof HttpServletRequest) {
                HttpServletRequest httpRequest = (HttpServletRequest) request;
                Headers.Types[] values = Headers.Types.values();
                for (int i = 0; i < values.length; i++) {
                    headers.setHeader(values[i], httpRequest.getHeader(values[i].toString()));
                }
            }

            chain.doFilter(request, response);
        }
    }


For this set up to work and have the filter to acutually be able to look up the real object at runtime, we need to add a RequestListener to web.xml, which will wire up the request context to all beans running outsite of the DispatcherServlet, i.e. our filter.

    
    
      org.springframework.web.context.request.RequestContextListener
    


Ok - so far so good. Let's wire it up together in a controller, which uses an example component that will serve as the component that will use the information gathered from the filter. Note that the component used by the controller is not aware of any request/response objects and doesn't have any parameters in it's methods.

    package com.technowobble.controller;

    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.stereotype.Controller;
    import org.springframework.web.bind.annotation.RequestMapping;
    import org.springframework.web.bind.annotation.RequestMethod;
    import org.springframework.web.bind.annotation.ResponseBody;
    import com.technowobble.component.MyComponent;

    @Controller
    @RequestMapping("/myController")
    public class MyController {
        @Autowired
        MyComponent myComponent;
        
        @ResponseBody
        @RequestMapping(method = RequestMethod.GET)
        public String createResponse() {
            return myComponent.getSomethingDependingOnHeaders();
        }
    }


The @ResponseBody is just an easy way to get rid of all view lookups and send the header values straight to the browser...

    package com.technowobble.component;

    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.stereotype.Component;

    import com.technowobble.web.Headers;

    @Component
    public class MyComponent {
        @Autowired
        Headers headers;
        
        public String getSomethingDependingOnHeaders() {
            return "You are accepting " + headers.getHeader(Headers.Types.Accept);
        }
    }


Now, check if everything workes as expected by launching the application using "mvn jetty:run" and browse to "http://localhost:8080/technowobble/myController/".

The last thing to report is how to test the MyComponent in a separate JUnit-test... First of all, there's no web context in a JUnit-test, and therefor no notion of a request scope. This is solved by defining a custom scope (implemented by a ThreadLocal implementation) in a separate applicationContext-test.xml which is used in the test.

  
    
      
        
          
        
      
    
  


After this, the actual test is straightforward:

    package com.technowobble.component;

    import static org.junit.Assert.assertEquals;

    import org.junit.Before;
    import org.junit.Test;
    import org.junit.runner.RunWith;
    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.test.context.ContextConfiguration;
    import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

    import com.technowobble.web.Headers;

    @RunWith(SpringJUnit4ClassRunner.class)
    @ContextConfiguration(locations="classpath*:META-INF/spring/applicationContext*.xml")
    public class MyComponentTest {
        @Autowired 
        private Headers headers;
        
        @Autowired
        private MyComponent myComponent;
        
        private static final String ACCEPT = "text/html";

        @Before
        public void setUp() throws Exception {
            headers.setHeader(Headers.Types.Accept, ACCEPT);
        }

        @Test
        public void test() {
            assertEquals(myComponent.getSomethingDependingOnHeaders(), "You are accepting " + ACCEPT);
        }
    }


Note that the headers bean is setup during the setUp()-method and that the myComponent have access to it using normal dependency injection.

That's it. The full source code can be downloaded from here

Thanks for reading!