Elegant Data Binding in Objective-C with ReactiveCocoa

If you’re developing apps for iOS then you should be (painfully) familiar with the Key-Value Observing (KVO) pattern. Says Chief NSHipster Matt Thompson about KVO:

Ask anyone who’s been around the NSBlock a few times: Key-Value Observing has the worst API in all of Cocoa. It’s awkward, verbose, and confusing. And worst of all, its terrible API belies one of the most compelling features of the framework.

Unfortunately, KVO seems to be the best way to natively achieve data binding on the iOS platform.

Continue reading Elegant Data Binding in Objective-C with ReactiveCocoa Elegant Data Binding in Objective-C with ReactiveCocoa

Payment services available in Norway

Is your work any good? You know when your customers pay you.
Is your work any good? You know when your customers pay you.

This is a summary of payment services presented or mentioned at The Mobile Meetup Oslo on Wednesday 24th of September.

In general, there are two types of payments services:

  1. The ones with cool APIs that let developers make seemless integrations. The customer stays on your page, but the transaction-information and other sensitive data is handled by the payment service.
  2. The ones that redirects the customer to their own page to complete the payment and then send them back to you when the payment is complete (or canceled or rejected).

Continue reading Payment services available in Norway Payment services available in Norway

async.js: Elegant Asynchronicity

In our #lillygram application cloud backend we have a bunch of async tasks that need to happen in strict sequence. This blogpost explain why we chose the async.js Node.js-library for our asynchronous tasks.

With a few thousand lines of JavaScript currently on our hands in the Lilly Apps enterprise, we are ready to take a step back and learn from our mistakes. JavaScript allows you to write working code extremely fast, but if you are not aware of the lurking dangers, your code may soon turn on you like a black widow. One challenge we faced was maintaining readable and stable code with a lot of asynchronous tasks.

A common pitfall, which we also fell into, is to nest function calls into callbacks, and let the inner-most callback be responsible for what to do once all calls have completed. In an attempt to keep things tidy we tried to declare and assign all callbacks to named variables before nesting the calls. This helps a little bit, but still leaves the code messy and unintuitive. But it starts to feel a little irky when we decide to change the order of calls. Should we also change the order of the declarations?

In the end, it seems that the best way to go is to throw a reference to each function into a list, iterate over this list, and call each in turn. In fact, that’s what async.js, does with its ‘series‘ method.

Intermediate handling in async.js is left to the individual function. In order to maintain flexibility, we persist the outcome of each function within the scope the async tasks, allowing functions down the chain to access the data it needs.

Here’s a highly simplified example implementation of async.js

 [CodePen height=475 show=js href=FguLr user=testower ]

* { Box-sizing: Border-box } FTW

The css box model has been a pain in the ass for me when working on the layout of #lillygram-letters. I have never liked it, but trying to make a print layout I was going crazy.

So i got very exited when I came over this article by Paul Irish: * { Box-sizing: Border-box } FTW. With box-sizing: border-box, padding and border no longer ads to the width and that just feels right!