• 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.

  • Resolving Angular $http promises in services vs. controllers

    Resolving Angular $http promises in services vs. controllers

    For some time now I’ve been asking myself one thing when it comes to resolving $http promises in Angular – “would it be a better practice to resolve them in services that make the calls or in controllers that call these services?”. I always simply went with whatever was the practice on the current project as I didn’t want to introduce inconsistencies into the project. Well I finally set down, played around with it a bit and gave it some active thinking. Turns out, the answer is hugely dependent on the context and there is no right or wrong way to do it but I’ll explain how I decided to do it from now on.

    This post is not about basic usage of $http, then, success, error, callbacks or promises in general. For that I recommend a very nice blog post by dwmkerr.

    Now, one “sub”-question I had here was should I use then or success. Although I noticed a lot of people seem to dislike using success and error callbacks because their signatures are inconsistent with the then callback (they are only a thin wrapper around it), I actually find it very useful that I don’t have to extract the “data” from the response object on my own. If I need to do something like that I still have the option of falling back to using then (which is fine). Some people seem to be really bothered by this so they even go as far as to wrap their responses in new promises using $q to match the then signature, but as Rick Strahl wrote – in this case I don’t really mind trading a bit of inconsistency for simplicity. I don’t see a point in adding additional chunk of wrapper-code to every API call just for the sake of it. So, I decided to go with the success/error combination.

    Back to the main question.. I never make any $http requests directly from controllers and along with any additional “client-side business logic”, that code goes into services. As a rule of thumb, I decided to go with a very simple approach. Since most often what happens after the success callback kicks in is controllers concern, my services return $http promises. Success promises are then resolved from within controllers. If there really is a need (and if it’s logical) to resolve the success callback in the service i will then do it there instead. The whole thing looks something like this:

    Now you’re probably wondering – what about the error callbacks? I could think of a couple of different scenarios of what could go wrong here:

    1. Unhandled exceptions
    2. 404’s
    3. “Expected exceptions” such as unauthorized (401), forbidden (403) or anything else you might knowingly return from the back-end
    4. Back-end model validation (I decided to go with 422 for this)

     

    To make my life easier, for the first three I decided to go with an http-interceptor-service which is in charge of handling WebAPI exceptions. This way I don’t have to rewrite the same error callback code for every $http request. It’s nice, centralized and provides enough flexibility (assuming you’re taking good care of your WebAPI and return proper http statuses).

    As for the last, fourth case, I created a couple of directives that wrap html input elements (text, textarea, dropdown..), WebAPI model state and validation messages (which have the format of foundation abide). For this to work, model state is needed inside a controller and since $http treats 422 status code as an error so far this was the only situation where I had to resolve the error callbacks inside controllers. In this case the http interceptor simply skips any 422 it encounters and it can then be taken care of elsewhere. I will explain this in more detail in my next-next post. Pinky swear. ;)

    The explained might not be the best way to cope with the whole problem but I it worked well for me so far so I hope I was at least able to provide a couple of useful ideas. I did try to google out other blog posts / SO threads about this but I only found a few ones that dealt with something similar but not entirely. If you know of any good ones, please feel free to drop a link down in the comments. Also, if you have a different approach which works for you or you see any problems with mine, do let me know! :)

    Cheers!

  • Dynamically resolving function shared arguments in JavaScript

    Dynamically resolving function shared arguments in JavaScript

    Sometimes we have functions which expect the same arguments as other functions, all fine there. Sometimes these arguments are obtained/resolved asynchronously. If there are a lot of these functions that share the same resource, we can come up with lot of unnecessary boilerplate.

    Imagine having a function like resolveMetaData() which asynchronously obtains fresh data every time it’s called (to keep the code at a very simple level, for the purpose of this post I’ll be using setTimeout() instead of something a bit more complex like an AJAX call):

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    function resolveMetaData(callback) {
        // for the purpose of the demo we'll simply mock the metaData object    
        var metaData = { message: "Meta message", start: new Date() };

        // async business logic example
        setTimeout(function () {
            metaData.end = new Date();
            // after metaData is ready, resolve callback
            callback(metaData);
        }, 1000);
    }

    And two functions that require a new instance of metaData upon their execution:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    function fnOne(data, metaData) {
        console.log(data);
        console.log(metaData);
    }

    function fnTwo(id, data, metaData) {
        console.log(id);
        console.log(data);
        console.log(metaData);
    }

    The simplest way to provide the latest metaData to these functions would be to use callbacks like this:

    1
    2
    3
    4
    5
    6
    7
    resolveMetaData(function(metaData) {
        fnOne("fnOne", metaData);
    });

    resolveMetaData(function(metaData) {
        fnOne(1, "fnTwo", metaData);
    });

    If you had to write a lot of functions similar to fnOne() and fnTwo() (ie. 10 or more) and all of them required the latest metaData, you would most probably be tempted to somehow reduce the code and get rid of the callback boilerplate. The first two ideas that came to my mind on how to resolve this were function overloads and/or having a base function that would handle metaData resolving. Since JS doesn’t really support overloading (in the same way as say C# does), having a base function to handle metaData resolving seems like a safe bet. The only question is – how do we call a function in JS with the parameters we got and resolve the shared parameters asynchronously?

    Fortunately Function.prototype.apply() comes to the rescue! It allows us to call a function with arguments as an array which is quite handy. Since functions in JS are objects, we can now create a base function which accepts the function object of the function we wish to call, and the args we have at that point. It then resolves metaData, appends it to the arguments array and calls the passed function with these arguments. This is how the base function would look like:

    1
    2
    3
    4
    5
    6
    function fnBase(fn, args) {
        resolveMetaData(function (metaData) {
            args.push(metaData);
            fn.apply(this, args);
        });
    }

    And this is the how we can now call fnOne() and fnTwo() through the fnBase():

    1
    2
    fnBase(fnOne, ["fnOne"]);
    fnBase(fnTwo, [1, "fnTwo"]);

    It would be possible to place metaData as a first argument in fnOne() and fnTwo() signatures but that would require additional args position handling in fnBase() so it is probably best to put metaData as the last argument.

    That’s it, hope it helps. Enjoy! :)

  • Returning value from fragment into parent activity on Android

    Returning value from fragment into parent activity on Android

    This post will show you how to return a value set in a dialog fragment back to the parent activity it was called from. Code sample provided here is from the Auto-WOL app I made not so long ago, so if you need the bigger picture, feel free to check TimePickerFragment and DeviceActivity classes over at github. This example uses TimePickerDialog. It also keeps track of the layoutId (where the layout it is bound to acts as a button in the UI) because in my app I have multiple buttons which can invoke the same TimePickerFragment so I needed to know which button invoked the dialog fragment because upon selecting the time the button caption gets updated.

    auto-wol-fragment-activity

    So, to make this whole thing work, we will need a fragment class which will extend DialogFragment and implement TimePickerDialog.OnTimeSetListener. This class will expose the OnTimePickedListener interface so it could later be consumed by the parent activity. This class will also be responsible for registering and calling the callback on time set event. The defined OnTimePickedListener interface has only one method signature – onTimePicked(), which will need to be implemented by the parent activity. Other than this, the class only has a few more overrides and that’s all.

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    /**
     * This class is used so values from TimePickerFragment could be
     * returned back to the activity from which it was called.
     */

    public class TimePickerFragment extends DialogFragment implements TimePickerDialog.OnTimeSetListener {
        OnTimePickedListener mCallback;
        Integer mLayoutId = null;

        /**
         * An interface containing onTimePicked() method signature.
         * Container Activity must implement this interface.
         */

        public interface OnTimePickedListener {
            public void onTimePicked(int textId, int hour, int minute);
        }

        /* (non-Javadoc)
         * @see android.app.DialogFragment#onAttach(android.app.Activity)
         */

        @Override
        public void onAttach(Activity activity) {
            super.onAttach(activity);

            try {
                mCallback = (OnTimePickedListener)activity;
            } catch (ClassCastException e) {
                throw new ClassCastException(activity.toString() + " must implement OnTimePickedListener.");
            }
        }

        /* (non-Javadoc)
         * @see android.app.DialogFragment#onCreateDialog(android.os.Bundle)
         */

        @Override
        public Dialog onCreateDialog(Bundle savedInstanceState) {
            mCallback = (OnTimePickedListener)getActivity();

            Bundle bundle = this.getArguments();
            mLayoutId = bundle.getInt("layoutId");
            int hour = bundle.getInt("hour");
            int minute = bundle.getInt("minute");

            // Create a new instance of TimePickerDialog and return it
            return new TimePickerDialog(getActivity(), this, hour, minute, DateFormat.is24HourFormat(getActivity()));
        }

        /* (non-Javadoc)
         * @see android.app.TimePickerDialog.OnTimeSetListener#onTimeSet(android.widget.TimePicker, int, int)
         */

        public void onTimeSet(TimePicker view, int hour, int minute) {
            if(mCallback != null)
            {
                mCallback.onTimePicked(mLayoutId, hour, minute);
            }
        }
    }

    The parent activity class implements the OnTimePickedListener defined in TimePickerFragment. This means we are requried to override the onTimePicked() method. This method is what gets executed after time has been picked in the dialog pop-up and “Done” confirmation button has been pressed. From here you’re back in your activity class and can do whatever you want with the obtained data.

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    public class DeviceActivity extends BaseActivity implements OnTimePickedListener {    
        ...
       
        /**
         * On time picked event, converts hour and minutes values to milliseconds
         * milliseconds and sets a new value for the layout in the activity.
         * @param layoutId      QuietHoursFrom or QuietHoursTo layout Id.
         * @param hour          Hour value.
         * @param minute        Minutes value.
         */

        @Override
        public void onTimePicked(int layoutId, int hour, int minute) {
            Long timeInMillis = TimeUtil.getTimeInMilliseconds(hour, minute);
           
            // Here you can do whatever needed with value obtained from the fragment
        }
       
        ...
    }
Back to top