My first AngularJS web app, part 2

Picking up from my previous installment, I created my web app layout and styling using Bootstrap, heavily customized so it doesn’t look like the standard Bootstrap-built site. Now it’s time to start hanging the meat on the bones by integrating AngularJS and JavaScript. Note that in this and subsequent blog posts I will discuss the high-level design of the app rather than reviewing individual code snippets. Frankly, assuming you can code, I believe it’s more important to understand the design reasoning and notable learnings rather than wading through code to demonstrate syntax.

As you can see on Minecraft Free News, there are essentially two major areas on the page: the feed selection at the very top of the page, and the content (individual feed items) displayed on the rest of the page. After creating the AngularJS module, I created two AngularJS controllers: FeedController to manage the feed source selections at the top, and ContentController to manage populating the feed items into the content area. I created an Angular service that simply provides a data object containing an array of all feed sources including the title, URL, whether the feed is enabled or disabled, and the maximum number of feed items to pull. Via this service, the data object is shared between the FeedController and ContentController. When the user clicks on a feed source to toggle its enable/disable attribute, the specific feed in the data object is changed by the FeedController, and that information is provided to the ContentController which immediately acts upon it to show or hide that feed’s items in the content area. In other words, this service serves as a communication conduit between my two controllers.

I created another Angular service called PullFeeds to interface with Google’s Feed API to pull each individual feed’s content items. This object relies upon Angular promises, an entity bundled with Angular to support asynchronous interactions. As our app is sourcing RSS data from other websites, we are at the mercy of the network and server delays. Per the Google Feed API, we can make a call to pull the feed items from a specific feed URL, and we must supply a call-back function that will process the items received from that feed. Without using a promise, when the PullFeeds service is executed, it will return immediately without any feed items because the action via Google’s Feed API is asynchronous and thus not yet completed. However, when using a promise in the service, only when our call-back function receives the data will the promise be fulfilled and data returned from the service as desired.

I also use promises elsewhere in the app (via another custom service) to pull JSON data from my own server in order to insert custom ads and news items inline in the content. Beyond returning data, promises can also return a rejection that indicates the deferred action failed (i.e. a failed promise to deliver). In my case, if the promise to read the data from my server failed (e.g. the server is down, network inaccessible, etc.), our web app can handle it gracefully by receiving the rejected promise and displaying the feed items without ads.

As a final note for this installment, I want to point out that all of the Javascript execution described thus far occurs on the client side. The HTML, CSS, and Javascript are read by the client from my server, and using AngularJS the resulting page is rendered entirely by the client. All of the feed items are pulled by the client. My server is only used to serve the relatively small HTML/CSS/Javascript, and to supply a small JSON object for custom ad and news items. Though seen as a dynamic web app from the client side, from the server’s perspective it’s all static content and thus very little bandwidth is required.