Today I presented at MinneWebCon on the University of Minnesota campus. I gave an introduction to AngularJS called “Getting Super with Angular JS”.
To run the application files, you will need Node and Grunt installed on your system.
I’ve been trying to devise a solution to working with mock data in the AngularJS. I’m not a huge fan of the solutions out there because too much debugging logic to determine mock or real data gets put into the code that may end up in production unless stripped out. Many of them are also limited to either having all services mocked, or none. This is difficult to manage when services are being developed by the back end team at the same time as the UI. We needed a quick way to turn specific services on and off on the fly. I think I’ve come up with a pretty nice solution.
The code below was picked apart from the application we’re building, modified with new variable names and had some business logic stripped out, so forgive me if there are some syntax or coding errors – it should be clean enough to get the idea though. I’ve left it in Coffeescript to save space.
To start with, I build a value for service configurations that sets up our end point URLs for both real services, and mock. It also directs the logic to the specific JSON files to return when a mock services is requested.
"use strict" angular.module("Bakery.config").value "$serviceConfig", url: "http://localhost:9000/mock_data/" mockUrl: "http://localhost:9000/mock_data/" useMock: false donuts: call: "donuts" mock: "/food/donuts.json" useMock: false cakes: call: "cakes" mock: "/food/cakes.json" useMock: true
Next we setup the actual services:
"use strict" angular.module("Bakery.services", ["ngResource"]).factory "$bakeryService", ($http, $serviceConfig) -> doCall : (serviceCall, call, args ) -> if $serviceConfig.useMock or call.useMock return $http.get $serviceConfig.mockUrl + call.mock else return serviceCall.apply this, args donuts : -> return @doCall( @_donuts, $serviceConfig.donuts, Array.prototype.slice.call(arguments) ) cakes : -> return @doCall( @_cakes, $serviceConfig.cakes, Array.prototype.slice.call(arguments) ) _donuts : (isFrosted, isFilled) -> console.log start call = $serviceConfig.containers url = $serviceConfig.url + call config = params: frosted: isFrosted isFilled: isFilled $http.get url, config _cakes : () -> call = $serviceConfig.configurations url = $serviceConfig.url + call $http.get url
Now we have a $bakeryService that will look at our configuration to determine if we want to use mock data or pull from the actual service. We can inject this to other areas of the application and make calls easily without having to think about whether or not we want to use mock or service data – it should just work.
"use strict" angular.module("GenesisApp.registeredViews").directive "query", ($bakeryService) -> restrict: "EAC" controller: ($scope) -> $bakeryService.donuts(true, false).then ((response) -> # success $scope.donuts = response.data ), (response) -> # failure console.log "Error getting donuts" $bakeryService.cake().then ((response) -> # success $scope.cakes = response.data ), (response) -> # failure console.log "Error getting cakes"
I like this approach because it limits the amount of extra code for mock services to just a few lines. The doCall method handles the decisions as to whether or not mock data should be used, and passes on the arguments to the real call when needed. The mock data information can be completely removed from the $serviceConfig object when its sent to production, limiting exposure to your mock services setup.
Another benefit is one can set the services to use mock data for all services or individually. This is helpful when services and UI logic are being built at the same time and some services aren’t completely functional or break. Just switch that particular’s service config to useMock: true and you can keep on programming.
The application utilizes the Rotten Tomatoes API to display the top 50 box office movies, allows progressive filtering, local pagination, inspecting movie details and favoriting movies with local storage. Feel free to browse the source code. I built this in about 3 days, so you’ll have to excuse a few rough edges here and there, but I’m pretty happy with the results overall. It uses jQuery, Bootstrap, Angular, Angular UI, Bootbox, LessCSS and Modernizr. Note that I’m not compiling my LessCSS down to css prior to execution. In a normal production environment you’d want to do this, but for demonstrative purposes I like to keep it all out in the open for quick updates.
I’ve marked up the source code heavily with comments to describe some of the details of the implementation. I’m in the process of rebuilding the application using BackboneJS and will write up an extensive blog comparing the development pros and cons of each framework. Place your bets now on which one you think will win!
I’ve been playing around with HTML5’s new Canvas tag and trying to convert some of my old Flash particle and proximity experiments. My favorite of these trials has always been the web spinning art (which unfortunately is no longer working on the blog).
By using a grid-based proximity manager, you click and drag your mouse across the canvas. As you drag, particles are created at your point of contact. They have a random direction and velocity. Particles are slightly attracted to each other, so depending on how much velocity they have, they will turn inward towards each other. There is also friction in the environment that cause the particles to slow down and eventually disappear.
While the code (especially the proximity manager) is pretty ugly, I do take advantage of some new features of the canvas tag, as well as use object-pooling to speed up object creation.
If you are unfamiliar with object-pooling its pretty simple. When I create a particle, it runs it course and is no longer needed, rather than wait for garbage collection to clean up the particle, I move it to a dead-particles array. When a new particle is requested, rather than instantiating a new particle (and thus using more memory), I first check if there are any dead particles that can be reused and grab one of those.
I have two versions of the web spinner, a mouse-only desktop version and an multi-touch version for tablets & phones. The multi-touch version does not use the ‘lighter’ blend mode or multiple random colors to help speed up performance. Also note, that since these are experiments, I’ve done no testing on browsers outside of Chrome or optimized to make touch/mouse events interchangeable.
What is a “Classical Object Oriented model?”
Many people believe that the word “classical” in “classical OO” has something to do with tradition, or a history of OO programming. This is actually incorrect. The word classical in this instance actually refers to the base word “class,” which in OO means a data structure that allows one to create unique instances of objects through classes. If you are familiar with Java or ActionScript3, you have most likely used classes.
How is “prototypal inheritance” different from “classical inheritance?”
Classes can inherit from other classes by extending them. When one class extends another, the extended class is often referred to as the base, super or parent class. For the purposes of this article, I will refer to them as a parent and child relationships when referring to inheritance. The child class inherits a specified set of methods and properties from the parent class.
Prototypal inheritance is based off an an actual instance of an object – not the construct to create that instance. So when you create your parent object with all its specific properties and methods, the child inheriting from the parent gets all the original objects values. They’re live and will change automatically for the child when its created.
I like to think of classical inheritance as blue-prints. You ‘construct’ things from blueprints, and each one will be unique and different. When a child gets a hold of the original parent’s blue-print, it can add on rooms and make changes, but it won’t affect any of the objects already created with either child blue-prints, or their parents. It also does not require any parent objects to be created in order to create children. They can be created directly from their own blueprints.
After some 2 hours of debugging and trying to get my new Nexus 10 to connect to ADB, I finally found this post on StackOverflow outlining the EasyTether problem. After deleting EasyTether from my system, I’ve had no issues getting my Galaxy Nexus or Nexus 10 to connect to my computer for debugging.
There has been a lot of talk about fragmentation in the Android ecosystem. Anyone who says it’s not fragmented has to be kidding themselves. If an iOS user sees a cool app on another person’s iOS device, they know that it is available to them as well. Unfortunately, the same is not true for Android users. When I create an Android application, I try to run it on as many devices as possible prior to release. The tweaks to the OS made by device manufacturers can (and do) affect application performance and stability. One can easily observe this by looking at reviews in the Apps Market where users describe applications force-closing randomly on specific phones.
… is to not use TabNavigator at all. Use a ViewStack and RadioButtons in an HBox!
I like doing skinning work in Flex but there certainly are a few components that I often times find easier to just re-engineer than skin. Scroll bars and TabNavigators are some examples of such components. I’ve heard skinning these components has gotten much easier in Flex 4, but alas, all my projects are still being developed in Flex 3.5.