Posts

Strategy Pattern: Switch Statements, Begone!

Image
Strategy Pattern: Switch Statements, Begone! Switch statements seem like a pretty convenient tool for handling control flow, and it certainly has its places. In my experience, however, switch statements (more often than not) end up leading to code smells. They gradually become parts of your code base that developers actively avoid. Why is that? switch (switchVar) { case "1": // A ton of code case "2": // Some different code break; case "3": // Some more code break; case "4": // This method is getting long break; case "5": // More code break; . . . case "100": // Heeelp break; } This is because switch statements make it very easy to extend functionality in an un-maintainable way. Whenever a new business case comes up, another switch case can be added to this already long function. As time

Communicating with your iOS app over USB (C# and/or Xamarin)

Image
Communicating with your iOS app over USB (C# and/or Xamarin) So, you're writing an iOS app that needs to communicate with a desktop client. A quick google search would suggest that the only way to do this would be to create a small socket server on the desktop client that listens on a given port, and have the iOS app connect to the desktop client through your local network. This definitely works, and often times it's good enough. If you're familiar with socket programming, this is definitely straight forward. However, there are definitely some drawbacks. The app has to be on the same network as the client (which isn't always possible in enterprise environments where your computer is on some private wired network). The client opens a port to your computer that anyone on the network can access, which can be a security concern. Initial setup is also a bit more tedious as the app user must enter the IP Address and Port into the app in order to connect. Being able

Promise Sharing in AngularJS

The Problem As any software project's complexity increases, separation of concerns becomes more and more important for overall maintainability. Angular services are a great way for multiple controllers to share functionality, and promotes the kind of decoupling that leads to clean, maintainable code. Although Angular services can really do anything, one of the more common uses of Angular services is to reach out to your server (via $http) and get some data. This is a great way to separate data-fetching logic from the business logic of your web application. However, this can also be a problem as your application becomes large. Let's say your application has multiple subviews, each with its own controller. These controllers know nothing about each other (since you're a good architect), and each has a dependency on the same Angular service to fetch some data from the same API endpoint. This results in two service calls to the server, each requesting the same data. For

Creating a PayPal IPN Web API Endpoint

Image
PayPal's IPN service allows you to perform server side business logic once you are sure that payment has been received. This is extremely useful if you want to hold off on shipping order until payment has arrived. However, as convenient as it is, it is equally under-documented, and there are little resources for a .NET developer. Here is one way of setting up a PayPal IPN endpoint using Web API. [RoutePrefix("paypal")] public class PayPalController : ApiController { private PayPalValidator _validator; public PayPalController() { this._validator = new PayPalValidator(); } [HttpPost] [Route("ipn")] public void ReceiveIPN(IPNBindingModel model) { if (!_validator.ValidateIPN(model.RawRequest)) throw new Exception("Error validating payment"); switch (model.PaymentStatus) { case "Compl