Categories

Recently we did a Techrally day at one of our clients, Intergamma. The client provided a couple of subjects of their interest, from voice search to automated classification. With a team of 4, we decided to build an augmented reality mobile app which shows DIY assembly instructions to help a customer ‘on the spot’. Did we succeed? Read on…

So, let’s say you have a nice React Native setup with the Jest testing library. You want to snapshot-test all your components of course! But you’re getting seemingly unrelated errors when you tried to mock a third party module in your snapshots and you’re lost in all that API documentation. Let’s dig into an example and get a clear picture of what’s happening under the hood.

When you want to use gRPC in your React Native app there is no official support yet, but that shouldn’t stop you! In this post I’ll show you how we designed an implementation with type safety in mind and successfully called a service remotely from React Native on Android.

When you want to link a custom animation to the scroll position in a ScrollView, like in the card example below, you are in for some bad performance on low end devices. Let’s figure out why and learn how to make it buttery smooth.

During a React Native project for one of our clients we added some custom Android and iOS libraries to our code and wanted to call a few exposed methods. In such a case, React Native requires you to write a wrapper class to call those public APIs. It was a small boilerplate nuisance and these wrappers would be unnecessary if we made a generic method call bridging API. Also, using such an API wrapper you can call any (obscure) available Android API that is not wrapped yet. Let’s see how far we can get!

This post is part of a series of ES2015 posts. We’ll be covering new JavaScript functionality every week!

In several previous posts we’ve been using Babel to actually run our (transpiled) code. But how far can we get if we only use natively supported features? Let’s dig in the stable features of Node.js 4 and see how much of our code can be written without a transpiler dependency.

This post is part of a series of ES2015 posts. We’ll be covering new JavaScript functionality every week!

One of the new features of ECMAScript 2015 is the WeakMap. It has several uses, but one of the most promoted is to store properties that can only be retrieved by an object reference, essentially creating private properties. We’ll show several different implementation approaches and compare it in terms of memory usage and performance with a ‘public’ properties variant.

This post is the first in a series of ES2015 posts. We’ll be covering new JavaScript functionality every week for the coming two months.

ES2015 brings a lot of new functionality to the table. It might be a good idea to evaluate if your new or existing projects actually require a library such as lodash. We’ll talk about several common usages of lodash functions that can be simply replaced by a native ES2015 implementation.

At my current client, we have a large AngularJS application that is configured to show a full-page error whenever one of the $http requests ends up in error. This is implemented with an error interceptor as you would expect it to be. However, we’re also using some calculation-intense resources that happen to timeout once in a while. This combination is tricky: a user triggers a resource request when navigating to a certain page, navigates to a second page and suddenly ends up with an error message, as the request from the first page triggered a timeout error. This is a particular unpleasant side effect that I’m going to address in a generic way in this post.