Fancy Pixel

A while ago we released Gulps on the AppStore. Gulps is a simple water tracking app that also reminds you when to drink throughout the day.
This was an app of “firsts” for me: first Swift app, first full app open sourced, first WatchKit app, first HealthKit app, first 3D touch implementation. It’s my go-to app when I need to experiment with new stuff. The streak continues with WatchOS 2.
In this post we’ll cover how to share data between the main app and the watch extension with the WatchConnectivity framework, and how to create a simple set of watch face complications. As an added bonus we’ll be doing that with a full open source app, that’s live on the AppStore. Off we go.

UIDynamics was a welcome addition to the iOS 7 SDK. It’s basically a physics engine backing common UIViews, allowing us to define physics traits to the UI elements. The API is fairly straightforward, so you can easily create animations and transitions that look and feel great. I already covered the basics in this article a while ago, this time we’ll be looking at what’s new in UIDynamics in iOS 9.

When iOS8 opened the API to have actionable notifications many of us were disappointed that the text input action used in Messages wasn’t available. It turns out that with iOS9 this API is now public, although as I’m writing this the documentation doesn’t mention it. After some digging in the UIKit changelog I was able to build a sample making use of this new behavior.
Like with iOS8 the NDA is more relaxed this year, but it still forbids showing screenshots. In any case, you’ll find the full sample on GitHub.
Let’s take a step by step look at what changed.

Lately my work at Fancy Pixel has focused on the backend of a product we’re about to launch and for which we decided to build a JSON API-only server. These APIs can be consumed from third party clients/services but are also used by our frontend. In this short report I’d like to share with you the simple solution that we’re using for the JSON generation and that in my humble opinion can be a quick and easy alternative to most commonly used systems like Jbuilder or ActiveModel::Serializers.

We released a new app on the AppStore and decided to open source it. The app is called Gulps, a simple tracker of your daily water consumption. Gulps was a fun little side project built to learn a bit more about WatchKit and to strengthen my Swift-fu.
If you read our latest post on how to share data with Realm, you’ll find a lot of code in common in this app, but there’s also quite a bit of new stuff that’s worth checking out. For starters I personally really like the water meter that follows your device movement, made possible by the amazing DPMeterView. You might also like the Facebook Paper-like wavy effect in the onboarding, provided by one of my pride and joys, AMWaveTransition.
You’ll find the source here.

Let us know what you think.
Until next time.

Andrea - @theandreamazz

It’s been a busy year for iOS developers. We got a slew of new toys to play with: a new version of iOS, new frameworks, a new language, new screen sizes and some new hardware to put on our wrists, just as soon as we thought that watches were anachronistic.
New technology is always exciting, but keeping up to date can be a daunting task when deadlines keep getting closer. Lately I’ve been taking some time off to delve deeper in these new topics and build a simple app out of it (that we are planning to open source). At the time of this writeup the app is still waiting to be reviewed, so we’re going to just focus on something that I learned in the process and that can be useful to a lot of other iOS devs: sharing data between your app and its WatchKit extension, using Realm.

This is the last part of “React + Flux backed by Rails API”, make sure to check out Part 1 and Part 2 if you have missed them.

In part 1 we built a Rails API for a tiny clone of Medium, called appropriately Small. In part 2 we went through the setup of a React app with a Flux architecture, and built our authentication workflow. We close this series by providing the list of the stories and a creation page, protected by authentication. A note of warning: this is a quick and sometimes naive implementation, its main purpose is to show you how to get started with React and Flux, that’s why we didn’t put too much effort in handling possible errors or, for that matter, even showing progress indicators.

This is the second part of “React + Flux backed by Rails API”, make sure to checkout Part 1.

In part 1 we created our fancy Rails API, setup the authentication and defined a resource for our tiny clone of Medium. Time to reach the core of this post: the frontend built in React with the flux architecture.

I’ve been working on a frontend for a project we are developing here at Fancy Pixel. We are embracing what looks like a good habit: slicing what would be a monolithic Rails app in a lightweight backend serving APIs and a frontend consuming them. We did this in the not so distant past using Angular.js. It was all fine and dandy, until it wasn’t. There’s something about it that doesn’t sit right with me, I wouldn’t go in detail, since many others already did, but let’s just say that there’s too much magic involved for my tastes (says the guy using Rails). Magic is fine as long as I can figure out how to tinker with the internals when things go down south. With Angular the effort seems too much, but that’s just personal taste really. Also I can’t deny that the major structural changes introduced in 2.0 were the last nail in the coffin.
I wanted to try something new, something that would enforce a solid architecture of our apps, letting me control the single cogs in the engine. React got a lot of good press in the past months, so I took the chance to dive in. In this three-part post you’ll find pretty much everything I learned by writing a frontend using React, with a vanilla Flux architecture, consuming an API written in Rails.

You probably know already what iBeacon is, but just to reiterate, iBeacon is the Apple way of saying Bluetooth 4 Low Energy. At the cost of sounding like a mindless drone, by ‘the Apple way of’ I mean ‘it just works and shows a lot of potential’. An iBeacon is a simple B4LE device that keeps broadcasting its presence. Other B4LE devices can sense when they reach the beacon without draining the battery (hence the LE) and making the user scream in agony. “Oook, what do I do with it?”. The best thing you can do is locating a user without the GPS, which means locating a user inside a building. The cool thing is that it’s fast, it takes seconds to detect a beacon and to react to its vicinity (or lack there of), and it works within the reach of Bluetooth technology (let’s say around a 50 meters radius). I should also mention that it works fine with Android too.

This week an Estimote developer kit arrived in our offices, so we took the chance to play around with it.