I recently had the opportunity to write a Xamarin app for the first time. It wasn’t anything complicated – basically a CRUD application that would list items for the user with the option to add, edit and delete – but it afforded me a chance to compare and contrast with the way I’ve been writing mobile apps for the past few years. Continue reading “Xamarin vs. PhoneGap”
Angular routing is pretty nifty. Going into how it works is beyond the scope of this post (and there’s plenty of resources out there doing just that), but suffice it to say if you’re working on an Angular application, you’re using Angular’s routing.
One of the things Angular’s routing does to increase performance is reusing a Component for a route that has already been instantiated. Say you have a Component, “MyComponent”, tied to a route, “/MyPath”. “MyComponent” isn’t created until the user actually navigates to the “/MyPath” route. That makes perfect sense – why instantiate a component that doesn’t need to be used yet? What’s interesting about this design, though, is how parameters factor into it. Let’s say you add a parameter to your “/MyPath” route, making the route “/MyPath/:id”. The first time the user navigates to some version of this route, let’s say “/MyPath/1”, “MyComponent” will be instantiated (with the id parameter set to 1). Then if, without leaving that route, the user changes only the parameter – for example, there’s a link in the component to go to “/MyPath/2”, “MyComponent” will not be recreated. In fact, if not handled correctly, to the user nothing will have changed. It will still look like they’re seeing the “/MyPath/1” version of “MyComponent”. Continue reading “Angular – Refreshing a Route with Parameters”
With the push to move away from On-Premise SharePoint environments in favor of the Office 365 SharePoint environment, Microsoft has drastically changed the landscape of SharePoint development. I’ve been a SharePoint developer since 2007 and making the jump to SharePoint Online has been the most jarring change yet. Of course when SharePoint Online was first announced and as features have been introduced, I’ve played around with them in a strictly “Hello World” capacity, but as any developer will tell you, creating a “Hello World” project for play purposes is drastically different from actually creating a real-world-use project.
I recently got to create my first “real” SharePoint Framework Web Part and here are my thoughts, as someone coming from over 10 years of On-Premise SharePoint development.
When working with Angular Routing, it’s very useful to be able to respond to routing events – the most obvious and useful being when the route changes. In AngularJS this was accomplished with by attaching a callback function to one the “$routeChange” events on the $scope. In Angular the concept is similar but has some key (and in my opinion, useful) differences.
Once you have a reference to the Router for your application you can subscribe to its “events” observable. This observable will emit a route-event whenever applicable that you can listen for. Being an observable you can subscribe to it in multiple places, filter for the specific event you want, transform the raw event, or anything else you could do with an observable.
Many years ago we worked on a project that would allow the client to perform inspections digitally on the various restaurants in their franchise. One of the goals of these inspections was to make sure the restaurants were following the client’s procedures and policies. These procedures and policies are constantly being reviewed and updated, so one of the main requirements of this inspection project was to allow the client to update the inspection on the fly without requiring development updates each time. In other words, it needed to be reasonably configurable by the client. We ultimately created a dynamic form that would be constructed in real-time based on data provided by the client. The idea was that as the client updated their procedures and policies, they would add/remove items from the form to keep it up-to-date.
I had an issue recently with a pretty standard form in Angular 2. The form had some required fields, one of which was a drop down / select field that wouldn’t populate with options until the user had made some selections earlier in the form. The submit button for the form was disabled until all required fields were filled in.
The issue arose when the client started testing the form in their environment. Despite completely filling out the form, the submit button would stay disabled. Obviously something was wrong.
In my Observables in Parallel blog post I discussed how I’ve been moving away from Promises in favor of Observables and how to translate functionality from promise-based solutions to observable-based solutions. The aforementioned blog post discussed how to wait for multiple Observables to complete before performing some action. In that scenario all the Observables were independent of each other, meaning none of the Observables depended on the results of another.
In this blog post I’m going to discuss how to use Observables that do depend on a different Observable to complete before executing – AKA Cascading Observables. One such use case scenario for Cascading Observables is when you need to call a web service to get some data, then use that data to call another web service, all in a single operation.