Tech

The other day we released DND Me, a simple Mac app that lives in your menu bar with which you can easily enable DND for a certain amount of time.

50% off during launch!

Just like it’s beneficial for the brain to learn several spoken languages, the same can be said about programming languages. The benefit might not seem big, but it adds up.

Each language has its own set of rules, of best practices, of approaches and paradigms. Learning more than one language will increase your ability to see a problem from different angles, to widen your perspective, to bring and apply principles from one language to another.

[Adrian][1], in his post about [being a developer over 40][2], gives advice as to learn a new programming every year and his approach is to build a simple calculator with whatever he learns — getting familiar with the IDE and APIs.

We all love animations. On one hand, they help our eyes be guided, but they also bring a nice finishing touch, a bit of extra care, a bit of emotion; we also prefer a lively UI to a static one, a UI that gives us feedback, that interacts back with us. But, as with anything, too much will be harmful, so let’s explore a few finishing touches that can be added to an app without overwhelming it.

If you’d like to learn a new programming language, try to aim for ”write a line of code” every day. You might rightfully ask ”how will one line help in the long run?” and the answer is rather simple: you will almost never stop at one line of code; it also keeps you connected and the process ongoing.

This is how I learned Ruby a few years ago, by aiming for ”a couple of lines of code”. From there, I ended up creating a ”real” blog with Sinatra (was using some WYSIWYG editor until then). This, in turn, led to me using my blog as a playground for every technology I wanted to learn ever since: Node.js, Swift and now React (still WIP).

Don’t dismiss the power of small progress. You’ll eventually end up learning that new language/framework/tool, which, in turn, might lead to other improvements down the line.

Everyone loves animations and I think every app should make use of them; with care, but that in a future post. The easiest way to add animations is with UIView’s animate method, or with UIViewPropertyAnimators. Pretty straightforward and easy to use, but they don’t support animating CALayer properties, like borderColor or borderWidth. For these, we have CABasicAnimation, or rather all of its concrete subclasses: CABasicAnimation, CAKeyframeAnimation, CAAnimationGroup, or CATransition. In this post we’ll quickly cover CABasicAnimation and CAAnimationGroup.

Say we want to animate the borderColor of a view, this is how we’d go about it:

The other week we released [My Travel Stories][1], an app to journal your travels, share beautiful photos with the world, but also find inspiration from others.

There are many apps you could use to journal your travels, be it diary apps, or the stock Photos app; but none of them are a true, focused, travelling journal app. [My Travel Stories][2] is a dedicated app, where you can add photos and descriptions for each; nothing more, nothing less.

A couple of [posts][1] ago I was writing about handling the Next button automatically. In this post I’d like to write about avoiding the keyboard automatically, in a manner that provides both a good user experience and a good developer experience.

Most apps have some sort of form that requires to be filled, even if just a login/register, if not several. As a user, having the keyboard cover the text field I'm about to fill makes me sad; it's a poor user experience. As developers, we'd like to solve this as easily as possible and have the solution as reusable as possible.

What does a good user experience mean?

In a [previous post][1] I was talking about an easier way to create UIFonts:

extension UIFont {
 
   static func regular(_ size: CGFloat) -> UIFont {
      return .systemFont(ofSize: size, weight: .regular) // Or any other font.
   }
	
   static func medium(_ size: CGFloat) -> UIFont {
      return .systemFont(ofSize: size, weight: .medium)
   }
 
}

While this indeed improves the usage, it doesn’t address the repeatability of our code. We tend to use one font in several places:

let titleLabel = UILabel(frame: .zero)
titleLabel.font = .medium(16)
 
// [...] Another part of the app
 
let otherTitleLabel = UILabel(frame: .zero)
otherTitleLabel.font = .medium(16)

For example’s sake, let’s say we have a UIButton subclass that we want to be customizable at call site, so we add two parameter’s to its init method:

final class Button: UIButton {
 
   init(textColor: UIColor, borderColor: UIColor)
 
}
 
// ...
 
let button = Button(textColor: .darkText,
                    borderColor: .darkText)

Looks pretty OK.

Some time passes and the need to customize its background color appears, at which point we’d need another param:

final class Button: UIButton {
 
   init(textColor: UIColor, borderColor: UIColor, backgroundColor: UIColor)
 
}
 
// ...

In a previous post I was writing about improving working with UIFont and now I’d like to take it one step further in regards with having a quick and easy way to set fonts, if you use a single typeface (font family):

extension UIFont {
 
   static func regular(_ size: CGFloat) -> UIFont {
      return .systemFont(ofSize: size, weight: .regular) // Or any other font.
   }
	
   static func medium(_ size: CGFloat) -> UIFont {
      return .systemFont(ofSize: size, weight: .medium)
   }
 
}

This might not seem much, or maybe I’m just lazy, but I find it easier to write and read

let nameLabel = UILabel()
nameLabel.font = .regular(15)

than

let nameLabel = UILabel()
nameLabel.font = .systemFont(ofSize: size, weight: .regular)