Whacky Labs

JSON vs Plist

2026-05-14T16:34:00+00:00

I recently watched an old WWDC video. The actual content of the video is not relevant but there was this one frame in the video that actually caught my eye. It was about parsing speeds between JSON, XML and Plist

According to the video parsing plist is ~22 times faster than json and ~43 times faster than parsing XML. Since the video was from 2010 and the world has really moved on ever since. So I had validate for myself how much of this is true in the year 2026.

I found a JSON vs Plist benchmarking project and cloned it - mainly for the data set. Then I put 4 parsers provided by Apple today in the arena:

JSONSerialization

let object = try! JSONSerialization.jsonObject(with: data) as! NSDictionary
let list = List(object)

JSONDecoder

let list = try! JSONDecoder().decode(List.self, from: data)

PropertyListSerialization

let object = try! PropertyListSerialization.propertyList(from: data, format: nil) as! NSDictionary
let list = List(object)!

PropertyListDecoder

let list = try! PropertyListDecoder().decode(List.self, from: data)

These are the data objects:

struct User: Codable {
  var uid: Int
  var firstName: String
  var lastName: String

  init(uid: Int, firstName: String, lastName: String) {
    self.uid = uid
    self.firstName = firstName
    self.lastName = lastName
  }

  init(_ dict: NSDictionary) {
    self.uid = dict["uid"] as! Int
    self.firstName = dict["firstName"] as! String
    self.lastName = dict["lastName"] as! String
  }
}

struct List: Codable {
  var List: [User]

  init(List: [User]) {
    self.List = List
  }

  init(_ dict: NSDictionary) {
    let userDicts = dict["List"] as! [NSDictionary]
    self.List = userDicts.map { User($0) }
  }
}

And these are the sample data:

{ 
  "List":[
    {
        "uid": 372796,
        "firstName": "Lupita",
        "lastName": "Jokisch"
    }
  ]
}

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>List</key>
	<array>
		<dict>
			<key>firstName</key>
			<string>Lupita</string>
			<key>lastName</key>
			<string>Jokisch</string>
			<key>uid</key>
			<integer>372796</integer>
		</dict>
	</array>
</dict>
</plist>

Notice that I’m not only benchmarking the parsing time but also the mapping of the data to the data models. Reason being that the modern parsers like JSONDecoder return back the model object unlike the old school parsers like JSONSerialization that return back the “raw” dictionary. And in any useful scenario we would have to always map the raw dictionary to the data model.

Also to be noted that I used the Xcode build setting PLIST_FILE_OUTPUT_FORMAT = binary which automatically converts the xml based plist to binary plist. Otherwise the plist are always slower than json.

This is the result I found for one of the sample sets:

-========== START TESTING ==========-
iterations : 10


fileSize : 1x:

| Parser             | Time (µs) |
|--------------------|-----------|
| JSONSerialization  | 38        |
| JSONDecoder        | 38        |
| PListSerialization | 26        |
| PListDecoder       | 57        |


fileSize : 10x:

| Parser             | Time (µs) |
|--------------------|-----------|
| JSONSerialization  | 126       |
| JSONDecoder        | 117       |
| PListSerialization | 111       |
| PListDecoder       | 267       |


fileSize : 100x:

| Parser             | Time (µs) |
|--------------------|-----------|
| JSONSerialization  | 1125      |
| JSONDecoder        | 963       |
| PListSerialization | 965       |
| PListDecoder       | 2402      |


fileSize : 1000x:

| Parser             | Time (µs) |
|--------------------|-----------|
| JSONSerialization  | 11049     |
| JSONDecoder        | 9468      |
| PListSerialization | 10289     |
| PListDecoder       | 27021     |


fileSize : 10000x:

| Parser             | Time (µs) |
|--------------------|-----------|
| JSONSerialization  | 113883    |
| JSONDecoder        | 96854     |
| PListSerialization | 89497     |
| PListDecoder       | 231899    |


fileSize : 100000x:

| Parser             | Time (µs) |
|--------------------|-----------|
| JSONSerialization  | 1133721   |
| JSONDecoder        | 926670    |
| PListSerialization | 843694    |
| PListDecoder       | 2309075   |


-========== TEST ENDED ==========-

PropertyListSerialization turned out to be the winner in most of the categories but the JSONDecoder always came very close followed by JSONSerialization and then the last one was always PListDecoder.

The source code for this experiment is available here: github.com/chunkyguy/FileDeserializeBenchmarking

One line to add beautiful transition between UICollectionViews

2026-03-04T20:58:00+00:00

UIKit comes with a bag full of techniques to build mind blowing animations and transitions but this one liner has to be my favorite.

useLayoutToLayoutNavigationTransitions = true

So how do you make it work? Simple first you need to have 2 UICollectionViewController instances in a UINavigationController. Then just before you push the second screen set the useLayoutToLayoutNavigationTransitions = true. And done!

Did I say 2 UICollectionViewController? Sorry I meant one. The only thing that is changing is the collectionViewLayout that is powering the UICollectionView.

class TileLayout: UICollectionViewFlowLayout {
  let scale: CGFloat

  init(size: CGSize, scale: CGFloat) {
    self.scale = scale
    super.init()
    let edge = (size.width * scale) - 12
    itemSize = CGSize(width: edge, height: edge)
    sectionInset = UIEdgeInsets(top: 8, left: 8, bottom: 8, right: 8)
    minimumInteritemSpacing = 0
    minimumLineSpacing = 8
  }

  required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
  }
}

struct DataSource {
  let colors: [UIColor]

  init(colors: [UIColor]) {
    self.colors = colors
  }

  init() {
    let count = 48
    let colors = (0..<count)
      .map { 1 - (CGFloat($0) / CGFloat(count)) }
      .map { UIColor(hue: $0, saturation: 0.7, brightness: 0.8, alpha: 1) }
    self.init(colors: colors)
  }
}

class ViewController: UICollectionViewController {
  static let cellId = "cell-id"

  let dataSource: DataSource
  private var selectedIndex: IndexPath?
  private var scale: CGFloat {
    (collectionViewLayout as? TileLayout)?.scale ?? 1
  }

  init(
    dataSource: DataSource,
    selectedIndex: IndexPath?,
    collectionViewLayout: UICollectionViewLayout
  ) {
    self.dataSource = dataSource
    self.selectedIndex = selectedIndex
    super.init(collectionViewLayout: collectionViewLayout)
  }

  required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
  }

  override func viewDidLoad() {
    super.viewDidLoad()
    title = "Zoom: \(scale)"
    collectionView.showsVerticalScrollIndicator = false
    collectionView.register(
      UICollectionViewCell.self,
      forCellWithReuseIdentifier: ViewController.cellId
    )
  }

  override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    if let selectedIndex {
      collectionView.scrollToItem(
        at: selectedIndex,
        at: .centeredVertically,
        animated: false
      )
    }
  }

  override func collectionView(
    _ collectionView: UICollectionView,
    numberOfItemsInSection section: Int
  ) -> Int {
    dataSource.colors.count
  }

  override func collectionView(
    _ collectionView: UICollectionView,
    cellForItemAt indexPath: IndexPath
  ) -> UICollectionViewCell {
    let cell = collectionView.dequeueReusableCell(
      withReuseIdentifier: ViewController.cellId,
      for: indexPath
    )
    cell.backgroundColor = dataSource.colors[indexPath.item]
    return cell
  }

  override func collectionView(
    _ collectionView: UICollectionView,
    didSelectItemAt indexPath: IndexPath
  ) {
    selectedIndex = indexPath
    let detailsVwCtrl = ViewController(
      dataSource: dataSource,
      selectedIndex: indexPath,
      collectionViewLayout: TileLayout(
        size: view.bounds.size,
        scale: min(scale * 2, 1.0)
      )
    )
    detailsVwCtrl.useLayoutToLayoutNavigationTransitions = true
    navigationController?.pushViewController(
      detailsVwCtrl,
      animated: true
    )
    collectionView.deselectItem(at: indexPath, animated: true)
  }
}

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

  var window: UIWindow?

  func scene(
    _ scene: UIScene,
    willConnectTo session: UISceneSession,
    options connectionOptions: UIScene.ConnectionOptions
  ) {
    guard let windowScene = (scene as? UIWindowScene) else { return }

    window = UIWindow(windowScene: windowScene)
    window?.rootViewController = UINavigationController(
      rootViewController: ViewController(
        dataSource: DataSource(),
        selectedIndex: nil,
        collectionViewLayout: TileLayout(
          size: windowScene.screen.bounds.size,
          scale: 0.25
        )
      )
    )
    window?.makeKeyAndVisible()
  }

  // ...
}

Juice it up with UIKit Dynamics

2026-03-02T10:51:00+00:00

One of my favorite framework on iOS has to be UIKit Dynamics and not enough people talk about it. But this is going to change today. Let’s build a color palette generator and have some fun with UIKit Dynamics along the way.

Photo by Bharath Kumar on Unsplash

Set up

To get started we need a simple UICollectionView that draws a 4 cells per screen with each cell colored as one of the color of the color palette.

class ViewController: UIViewController {

  private static let cellId = "cell-id"
  private static let maxPalettes = 24

  private let colors: [UIColor] = {
    // generate a tetradic color palette by generating a random hue value
    // and 4 corresponding colors from that base hue: [h, h+0.25, h+0.5, h+0.75]
    (0..<maxPalettes).flatMap { _ in
      let hueBase = CGFloat.random(in: 0...1)
      let saturation = CGFloat.random(in: 0.5...1)
      return (0..<4).map {
        UIColor(
          hue: hueBase + (CGFloat($0) * 0.25),
          saturation: saturation,
          brightness: CGFloat.random(in: 0.5...1),
          alpha: 1
        )
      }
    }
  }()

  override func viewDidLoad() {
    super.viewDidLoad()

    let layout = UICollectionViewFlowLayout()
    // each cell is 1/4th the height of screen
    layout.itemSize = CGSize(
      width: view.bounds.width,
      height: view.bounds.height * 0.25
    )
    layout.minimumInteritemSpacing = 0
    layout.minimumLineSpacing = 0

    let collectionView = UICollectionView(
      frame: view.bounds,
      collectionViewLayout: layout
    )

    view.addSubview(collectionView)

    collectionView.register(
      UICollectionViewCell.self,
      forCellWithReuseIdentifier: Self.cellId
    )
    collectionView.dataSource = self
    collectionView.contentInsetAdjustmentBehavior = .never
    collectionView.isPagingEnabled = true
  }
}

extension ViewController: UICollectionViewDataSource {
  func collectionView(
    _ collectionView: UICollectionView,
    numberOfItemsInSection section: Int
  ) -> Int {
    return colors.count
  }

  func collectionView(
    _ collectionView: UICollectionView,
    cellForItemAt indexPath: IndexPath
  ) -> UICollectionViewCell {
    let cell = collectionView.dequeueReusableCell(
      withReuseIdentifier: Self.cellId,
      for: indexPath
    )
    cell.backgroundColor = colors[indexPath.item]
    return cell
  }
}

Add UIKit Dynamics

The nice and easy way of introducing UIKit Dynamics in a UICollectionView is by subclassing a UICollectionViewFlowLayout and use that subclass to provide the effective layout data to the UICollectionView

class BouncyListLayout: UICollectionViewFlowLayout { 
  // ...
}

class ViewController: UIViewController {

  override func viewDidLoad() {
    super.viewDidLoad()

    let layout = BouncyListLayout()
    // ...
    let collectionView = UICollectionView(
      frame: view.bounds,
      collectionViewLayout: layout
    )
    // ...
  }
  // ...
}

Within the BouncyListLayout we first need to initialize a UIDynamicAnimator instance. The idea is it have an UIDynamicAnimator and one UIDynamicBehavior per item. We let the base class UICollectionViewFlowLayout do the heavy lifting of creating the UICollectionViewLayoutAttributes we then simply use this UICollectionViewLayoutAttributes to create the UIDynamicBehavior and let UIDynamicAnimator run the physics simulation and return the data back to UICollectionView.

class BouncyListLayout: UICollectionViewFlowLayout {
  lazy var animator = UIDynamicAnimator(collectionViewLayout: self)

  override func prepare() {
    super.prepare()
    setUp()
  }

  private func setUp() {
    // ...
  }

  override func layoutAttributesForElements(in rect: CGRect) -> [UICollectionViewLayoutAttributes]? {
    return animator.items(in: rect).compactMap { $0 as? UICollectionViewLayoutAttributes }
  }

  override func layoutAttributesForItem(at indexPath: IndexPath) -> UICollectionViewLayoutAttributes? {
    return animator.layoutAttributesForCell(at: indexPath)
  }
}

This mapping between physics world and the UI world works thanks to the fact that UICollectionViewLayoutAttributes conforms to the protocol UIDynamicItem and UIDynamicAnimator providing convenience methods to work with UICollectionView

class UICollectionViewLayoutAttributes : NSObject, NSCopying, UIDynamicItem { 
  // ...
}

extension UIDynamicAnimator {

    convenience init(
      collectionViewLayout layout: UICollectionViewLayout
    )

    func items(in rect: CGRect) -> [any UIDynamicItem]

    func layoutAttributesForCell(
      at indexPath: IndexPath
    ) -> UICollectionViewLayoutAttributes?
}

In our setUp method the simplest and the least performant way is to let the UICollectionViewFlowLayout prepare all the items. We invoke super.layoutAttributesForElements for the entire content size. Then for each item we create a UIAttachmentBehavior that controls the springiness of each item. The spring is anchored to the center of the item.

class BouncyListLayout: UICollectionViewFlowLayout {
  // ...

  private func setUp() {
    guard animator.behaviors.isEmpty else {
      // animators already setup - skip
      return
    }
    let items = super.layoutAttributesForElements(
      in: CGRect(origin: .zero, size: collectionViewContentSize)
    ) ?? []

    for item in items {
      let spring = UIAttachmentBehavior(item: item, attachedToAnchor: item.center)
      spring.length = 0
      spring.frequency = 1.0
      spring.damping = 2.0
      spring.frictionTorque = 2.0
      animator.addBehavior(spring)
    }
  }
  // ...
}

The final piece of the magic comes from shouldInvalidateLayout, which is invoked whenever the content within the UICollectionView updates. Remember that the UIScrollView works by changing the bounds origin value.

The plan here is to adjust the spring center by a certain offset based on how far it is from the touch point. So, items just under the finger have no spring effect while the items furthest have the most spring effect. And then finally call the animator.updateItem(usingCurrentState: item) to update the animator which would then in turn run the physics simulation for the item

class BouncyListLayout: UICollectionViewFlowLayout {
  // ...

  override func shouldInvalidateLayout(forBoundsChange newBounds: CGRect) -> Bool {
    guard let collectionView else { return false }

    let touchPt = collectionView.panGestureRecognizer.location(in: collectionView)
    let dy = newBounds.origin.y - collectionView.bounds.origin.y

    for behaviors in animator.behaviors {
      if let spring = behaviors as? UIAttachmentBehavior,
          let item = spring.items.first as? UICollectionViewLayoutAttributes {
        let offset = abs(touchPt.y - spring.anchorPoint.y)
        let yFactor = offset * 0.0001
        item.center = CGPoint(x: item.center.x, y: item.center.y + (dy * yFactor))
        animator.updateItem(usingCurrentState: item)
      }
    }

    return true
  }
  // ...
}

Performance improvements

Now for the last bit, if our UICollectionView has a lot of items, we possibly do not want to load all the springs during setup time but rather on the fly when needed. So we need to get rid of the setUp

class BouncyListLayout: UICollectionViewFlowLayout {
-  override func prepare() {
-    super.prepare()
-    setUp()
-  }
-
-  private func setUp() {
-    guard animator.behaviors.isEmpty else {
-      // animators already setup - skip
-      return
-    }
-    let items = super.layoutAttributesForElements(
-      in: CGRect(origin: .zero, size: collectionViewContentSize)
-    ) ?? []
-
-    for item in items {
-      let spring = UIAttachmentBehavior(item: item, attachedToAnchor: item.center)
-      spring.length = 0
-      spring.frequency = 1.0
-      spring.damping = 2.0
-      spring.frictionTorque = 2.0
-      animator.addBehavior(spring)
-    }
-  }
}

And add spring when needed by keeping track of IndexPath for which the springs have already been added. Notice that we are still getting the UICollectionViewLayoutAttributes from UICollectionViewFlowLayout by invoking the super implementation but still returning the values from the UIDynamicAnimator

class BouncyListLayout: UICollectionViewFlowLayout {
  lazy var animator = UIDynamicAnimator(collectionViewLayout: self)
  private var indexPaths: Set<IndexPath> = []

  private func addSpringIfNeeded(toItem item: UICollectionViewLayoutAttributes) {
    if indexPaths.contains(item.indexPath) { return }

    let spring = UIAttachmentBehavior(item: item, attachedToAnchor: item.center)
    spring.length = 0
    spring.frequency = 1.0
    spring.damping = 2.0
    spring.frictionTorque = 2.0
    animator.addBehavior(spring)
    indexPaths.insert(item.indexPath)
  }

  override func layoutAttributesForElements(in rect: CGRect) -> [UICollectionViewLayoutAttributes]? {
    guard let items = super.layoutAttributesForElements(in: rect) else {
      return nil
    }
    items.forEach { addSpringIfNeeded(toItem: $0) }
    return animator.items(in: rect).compactMap { $0 as? UICollectionViewLayoutAttributes }
  }

  override func layoutAttributesForItem(at indexPath: IndexPath) -> UICollectionViewLayoutAttributes? {
    guard let item = super.layoutAttributesForItem(at: indexPath) else {
      return nil
    }
    addSpringIfNeeded(toItem: item)
    return animator.layoutAttributesForCell(at: indexPath)
  }

  // ...
}

References

Lets make a React Native Host Component

2026-02-13T14:51:00+00:00

They say if you really wanna know how React Native works then make a host component. So that is the task for the day.

I’ll be following the offical guide on making the Host Component by making a native webview and make it available to react native.

Set up

Step one is to create the package. I’m calling my host component as MyWebView

npx @react-native-community/cli@latest init MyWebView --version 0.83

.
├── __tests__
├── android
├── app.json
├── App.tsx
├── babel.config.js
├── Gemfile
├── index.js
├── ios
├── jest.config.js
├── metro.config.js
├── node_modules
├── package-lock.json
├── package.json
├── README.md
└── tsconfig.json

So far this looks a lot like any other react native project that you can actually build and run.

The real difference comes when we configure the codegen by updating the package.json

  "codegenConfig": {
    "name": "AppSpec",
    "type": "components",
    "jsSrcsDir": "specs",
    "android": {
      "javaPackageName": "com.webview"
    },
    "ios": {
      "componentProvider": {
        "MyWebView": "RCTWebView"
      }
    }
  }

and create our spec WebViewNativeComponent.ts in a specs directory at the root level.

mkdir specs
touch specs/WebViewNativeComponent.ts

import type {
  CodegenTypes,
  HostComponent,
  ViewProps,
} from 'react-native';
import { codegenNativeComponent } from 'react-native';

type WebViewScriptLoadedEvent = {
  result: 'success' | 'error';
};

export interface NativeProps extends ViewProps {
  sourceURL?: string;
  onScriptLoaded?: CodegenTypes.BubblingEventHandler<WebViewScriptLoadedEvent> | null;
}

export default codegenNativeComponent<NativeProps>(
  'MyWebView',
) as HostComponent<NativeProps>;

This spec is what is then used by the React Native to generate all the boilerplate code. If all goes well then we would have a component called MyWebView with two props a sourceURL and a callback onScriptLoaded

<WebView
  sourceURL={url}
  onScriptLoaded={() => Alert.alert('Done!')}
/>

iOS implementation

To get started with iOS we need to run the pod install

cd ios
bundle install
bundle exec pod install

And then open the generated Xcode workspace and run the app.

In the terminal I can see that the Codegen generating all of the glue code

[Codegen] Generating Native Code for AppSpec - ios
[Codegen] Generated artifacts: MyWebView/ios/build/generated/ios/ReactCodegen
...

And at the end this is what it generated:

build/generated/ios
├── Package.swift
├── ReactAppDependencyProvider
│   ├── RCTAppDependencyProvider.h
│   ├── RCTAppDependencyProvider.mm
│   └── ReactAppDependencyProvider.podspec
└── ReactCodegen
    ├── RCTModuleProviders.h
    ├── RCTModuleProviders.mm
    ├── RCTModulesConformingToProtocolsProvider.h
    ├── RCTModulesConformingToProtocolsProvider.mm
    ├── RCTThirdPartyComponentsProvider.h
    ├── RCTThirdPartyComponentsProvider.mm
    ├── RCTUnstableModulesRequiringMainQueueSetupProvider.h
    ├── RCTUnstableModulesRequiringMainQueueSetupProvider.mm
    ├── react
    │   └── renderer
    ├── ReactCodegen.podspec
    ├── safeareacontext
    │   ├── safeareacontext-generated.mm
    │   └── safeareacontext.h
    └── safeareacontextJSI.h

And finally the renderer directory is where the real good stuff is:

build/generated/ios/ReactCodegen/react/renderer
└── components
    ├── AppSpec
    │   ├── ComponentDescriptors.cpp
    │   ├── ComponentDescriptors.h
    │   ├── EventEmitters.cpp
    │   ├── EventEmitters.h
    │   ├── Props.cpp
    │   ├── Props.h
    │   ├── RCTComponentViewHelpers.h
    │   ├── ShadowNodes.cpp
    │   ├── ShadowNodes.h
    │   ├── States.cpp
    │   └── States.h
    └── safeareacontext
        └── ...

That is a lot of boilerplate code!

Finally within the Xcode project we need to add the iOS implementation in regular Objective-C++. With the public interface as:

#import <React/RCTViewComponentView.h>
#import <UIKit/UIKit.h>

@interface RCTWebView : RCTViewComponentView

@end

Add then in the class extension we need to import the generated code

#import <Foundation/Foundation.h>
#import <react/renderer/components/AppSpec/ComponentDescriptors.h>
#import <react/renderer/components/AppSpec/EventEmitters.h>
#import <react/renderer/components/AppSpec/Props.h>
#import <react/renderer/components/AppSpec/RCTComponentViewHelpers.h>
#import <WebKit/WebKit.h>

@interface RCTWebView () <RCTMyWebViewViewProtocol, WKNavigationDelegate> {
  WKWebView *_webView;
  NSURL *_sourceURL;
}
@end

The implementation is a straightforward wrapper of WKWebView where the frame is being set by it’s parent. So we fill all the available space

@implementation RCTWebView

- (instancetype)init {
  self = [super init];
  if (self) {
    _webView = [[WKWebView alloc] init];
    [_webView setNavigationDelegate:self];
    [self addSubview:_webView];
  }
  return self;
}

- (void)layoutSubviews {
  [super layoutSubviews];
  [_webView setFrame:[self bounds]];
}

// ...
@end

To hook back to the react native we need to provide ComponentDescriptorProvider as a class method generate by the CodeGen

@implementation RCTWebView

// ...

+ (ComponentDescriptorProvider)componentDescriptorProvider {
  return concreteComponentDescriptorProvider<MyWebViewComponentDescriptor>();
}

@end

Next we need to handle the props by first downcasting to generated types and then reading the data from them. In our case the sourceURL and pass that information to the underlying WKWebView

using namespace facebook::react;

@implementation RCTWebView

// ...

- (void)updateProps:(const Props::Shared &)props
           oldProps:(const Props::Shared &)oldProps {

  const auto &oldViewProps = static_cast<const MyWebViewProps &>(*_props);
  const auto &newViewProps = static_cast<const MyWebViewProps &>(*props);

  if (oldViewProps.sourceURL != newViewProps.sourceURL) {
    NSString *urlString = [NSString stringWithCString:newViewProps.sourceURL.c_str()
                                             encoding:NSUTF8StringEncoding];
    _sourceURL = [NSURL URLWithString:urlString];
    [_webView loadRequest:[NSURLRequest requestWithURL:_sourceURL]];
  }

  [super updateProps:props oldProps:oldProps];
}

@end

Next is the callback, where we listen to the WKNavigationDelegate method didFinishNavigation and again by downcasting the _eventEmitter we invoke the generate onScriptLoaded

@implementation RCTWebView

// ...

#pragma mark - WKNavigationDelegate

- (void)webView:(WKWebView *)webView didFinishNavigation:(WKNavigation *)navigation {
  auto result = MyWebViewEventEmitter::OnScriptLoaded {
    MyWebViewEventEmitter::OnScriptLoadedResult::Success
  };

  auto eventEmitter = static_cast<const MyWebViewEventEmitter &>(*_eventEmitter);
  eventEmitter.onScriptLoaded(result);
}

@end

In case you’re wondering the generated onScriptLoaded function looks like this:

void MyWebViewEventEmitter::onScriptLoaded(OnScriptLoaded event) const {
  dispatchEvent("scriptLoaded", [event=std::move(event)](jsi::Runtime &runtime) {
    auto payload = jsi::Object(runtime);
    payload.setProperty(runtime, "result", toString(event.result));
    return payload;
  });
}

App

Back to the React Native side of things I cleaned up all of the start up code to have a simple home screen

function App() {
  const isDarkMode = useColorScheme() === 'dark';

  return (
    <SafeAreaProvider>
      <StatusBar barStyle={isDarkMode ? 'light-content' : 'dark-content'} />
      <AppContent />
    </SafeAreaProvider>
  );
}

function AppContent() {
  const safeAreaInsets = useSafeAreaInsets();

  return (
    <View style={styles.container}>
      <HomeScreen safeAreaInsets={safeAreaInsets} />
    </View>
  );
}

type HomeScreenProps = {
  safeAreaInsets: EdgeInsets;
};

function HomeScreen({ safeAreaInsets }: HomeScreenProps) {
  return (
    <View
      style={[
        styles.container,
        {
          paddingTop: safeAreaInsets.top,
          paddingBottom: safeAreaInsets.bottom,
        },
      ]}
    >
      
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
  },
  text: {
    color: '#fff',
  },
});

export default App;

And finally add our beautiful MyWebView component

function HomeScreen({ safeAreaInsets }: HomeScreenProps) {
  return (
    <View
      style={[
        styles.container,
        {
          paddingTop: safeAreaInsets.top,
          paddingBottom: safeAreaInsets.bottom,
        },
      ]}
    >
      <MyWebView
        style={styles.content}
        sourceURL="https://whackylabs.com/"
        onScriptLoaded={() => Alert.alert('Done!')}
      />
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
    alignContent: 'center',
  },
  content: {
    width: '100%',
    height: '100%',
  },
});

And voila! It’s alive!

Android implementation

To get the same thing running on Android we need to switch the android directory and generate boilerplate code

cd android
./gradlew generateCodegenArtifactsFromSchema

For some reason I was getting weird error with Java 21 but falling back Java 17 worked!

tree app/build/generated/source/codegen 
app/build/generated/source/codegen
├── java
│   └── com
│       └── facebook
│           └── react
│               └── viewmanagers
│                   ├── MyWebViewManagerDelegate.java
│                   └── MyWebViewManagerInterface.java
├── jni
│   ├── AppSpec-generated.cpp
│   ├── AppSpec.h
│   ├── CMakeLists.txt
│   └── react
│       └── renderer
│           └── components
│               └── AppSpec
│                   ├── AppSpecJSI.h
│                   ├── ComponentDescriptors.cpp
│                   ├── ComponentDescriptors.h
│                   ├── EventEmitters.cpp
│                   ├── EventEmitters.h
│                   ├── Props.cpp
│                   ├── Props.h
│                   ├── ShadowNodes.cpp
│                   ├── ShadowNodes.h
│                   ├── States.cpp
│                   └── States.h
└── schema.json

Then the implementation part is almost the same but with less C++ and less generated boilerplate

class ReactWebView : WebView {
  constructor(context: Context) : super(context) {
    configureComponent()
  }

  constructor(context: Context, attrs: AttributeSet?) : super(context, attrs) {
    configureComponent()
  }

  constructor(context: Context, attrs: AttributeSet?, defStyleAttr: Int) 
      : super(context, attrs, defStyleAttr) {
    configureComponent()
  }

  private fun configureComponent() {
    this.layoutParams = LayoutParams(LayoutParams.MATCH_PARENT, LayoutParams.MATCH_PARENT)
    this.webViewClient = object : WebViewClient() {
      override fun onPageFinished(view: WebView, url: String) {
        emitOnScriptLoaded(OnScriptLoadedEventResult.success)
      }
    }
  }

  fun emitOnScriptLoaded(result: OnScriptLoadedEventResult) {
    val reactContext = context as ReactContext
    val surfaceId = UIManagerHelper.getSurfaceId(reactContext)
    val eventDispatcher = UIManagerHelper.getEventDispatcherForReactTag(reactContext, id)
    val payload = Arguments.createMap().apply {
      putString("result", result.name)
    }
    val event = OnScriptLoadedEvent(surfaceId, id, payload)

    eventDispatcher?.dispatchEvent(event)
  }

  enum class OnScriptLoadedEventResult {
    success,
    error;
  }

  inner class OnScriptLoadedEvent(
    surfaceId: Int,
    viewId: Int,
    private val payload: WritableMap
  ) : Event<OnScriptLoadedEvent>(surfaceId, viewId) {
    override fun getEventName() = "onScriptLoaded"
    override fun getEventData() = payload
  }
}

And a manager class to create and manage ReactWebView instance

@ReactModule(name = ReactWebViewManager.REACT_CLASS)
class ReactWebViewManager(context: ReactApplicationContext) : SimpleViewManager<ReactWebView>(),
  MyWebViewManagerInterface<ReactWebView> {
  private val delegate: MyWebViewManagerDelegate<ReactWebView, ReactWebViewManager> =
    MyWebViewManagerDelegate(this)

  override fun getDelegate(): ViewManagerDelegate<ReactWebView> = delegate

  override fun getName(): String = REACT_CLASS

  override fun createViewInstance(context: ThemedReactContext): ReactWebView = ReactWebView(context)

  @ReactProp(name = "sourceUrl")
  override fun setSourceURL(view: ReactWebView, sourceURL: String?) {
    if (sourceURL == null) {
      view.emitOnScriptLoaded(ReactWebView.OnScriptLoadedEventResult.error)
      return;
    }
    view.loadUrl(sourceURL, emptyMap())
  }

  companion object {
    const val REACT_CLASS = "MyWebView"
  }

  override fun getExportedCustomBubblingEventTypeConstants(): Map<String, Any> =
    mapOf(
      "onScriptLoaded" to
          mapOf(
            "phasedRegistrationNames" to
                mapOf(
                  "bubbled" to "onScriptLoaded",
                  "captured" to "onScriptLoadedCapture"
                )
          )
    )
}

Then there is a package that glues the Android to ReactNative system

class ReactWebViewPackage : BaseReactPackage() {
  override fun createViewManagers(reactContext: ReactApplicationContext): List<ViewManager<*, *>> {
    return listOf(ReactWebViewManager(reactContext))
  }

  override fun getModule(
    s: String,
    reactApplicationContext: ReactApplicationContext
  ): NativeModule? {
    when (s) {
      ReactWebViewManager.REACT_CLASS -> ReactWebViewManager(reactApplicationContext)
    }
    return null
  }

  override fun getReactModuleInfoProvider(): ReactModuleInfoProvider = ReactModuleInfoProvider {
    mapOf(
      ReactWebViewManager.REACT_CLASS to ReactModuleInfo(
        name = ReactWebViewManager.REACT_CLASS,
        className = ReactWebViewManager.REACT_CLASS,
        canOverrideExistingModule = false,
        needsEagerInit = false,
        isCxxModule = false,
        isTurboModule = true,
      )
    )
  }
}

And finally we register our package

class MainApplication : Application(), ReactApplication {

  override val reactHost: ReactHost by lazy {
    getDefaultReactHost(
      context = applicationContext,
      packageList =
        PackageList(this).packages.apply {
          // Packages that cannot be autolinked yet can be added manually here:
          add(ReactWebViewPackage())
        },
    )
  }

  // ...

}

And we have our android web view available in React native

Resources

React Native Navigation 101

2026-02-01T15:45:00+00:00

This is a quick guide to various navigation patterns in react native.

Set up

Let’s create a new project:

npx create-expo-app@latest --template blank-typescript

And update tsconfig.json to be able to handle absolute paths

{
  "extends": "expo/tsconfig.base",
  "compilerOptions": {
    "strict": true,
    "paths": {"@/*": ["./*"]}
  }
}

The very first step is to install react navigation package

npm install @react-navigation/native
npx expo install react-native-screens

Stack

Stack is a navigation pattern where screens are pushed on top of each other and poped back with a back button.

To implement this pattern we need to install the native-stack package.

npm install @react-navigation/native-stack

The have Map between screen name and their parameters. For screen that take no parameters the value is set to undefined. For example, if we wish to have 2 screens where a Home that takes no params and a Details that takes a string as param, we can create our StackParams as:

export type StackParams = {
  Home: undefined;
  Details: { text: string };
};

Then we need to create the Navigator using StackParams. And register our screen components with the StackParams.Key

const Stack = createNativeStackNavigator<StackParams>();

function RootStack() {
  return (
    <Stack.Navigator>
      <Stack.Screen name="Home" component={HomeScreen} />
      <Stack.Screen name="Details" component={DetailsScreen} />
    </Stack.Navigator>
  );
}

And finally at the root we need to provide a NavigationContainer and provide the RootStack as the only child.

export default function App() {
  return (
    <NavigationContainer>
      <RootStack />
    </NavigationContainer>
  );
}

Within HomeScreen we can use the useNavigation() hook to navigate to the DetailsScreen.

export default function HomeScreen() {
  const navigation = useNavigation<NativeStackNavigationProp<StackParams>>();

  return (
    <View style={Styles.screen}>
      <Text style={Styles.h2}>Home Screen</Text>
      <TouchableOpacity
        onPress={() => navigation.navigate("Details", { text: "Hello world!" })}
      >
        <Text style={Styles.button}>Click here!</Text>
      </TouchableOpacity>
      <StatusBar style="auto" />
    </View>
  );
}

The navigation and route are also injected as params to the Screen. So for example in the DetailsScreen we can use the route to read the provided params and then make use of navigation to pop back the stack:

type Props = NativeStackScreenProps<StackParams, "Details">;

export default function DetailsScreen({ navigation, route }: Props) {
  const { text } = route.params;
  return (
    <View style={Styles.screen}>
      <Text style={Styles.h2}>Details Screen</Text>
      <Text style={Styles.text}>{text}</Text>
      <TouchableOpacity onPress={() => navigation.goBack()}>
        <Text style={Styles.button}>Go back</Text>
      </TouchableOpacity>
      <StatusBar style="auto" />
    </View>
  );
}

Modal is a navigation pattern where a screen is shown on top of existing screen.

For simple cases we use the Stack pattern and set the presentation mode to modal and call it a day.

function RootStack() {
  return (
    <Stack.Navigator screenOptions={ { presentation: "modal" } }>
      <Stack.Screen name="Home" component={HomeScreen} />
      <Stack.Screen name="Details" component={DetailsScreen} />
    </Stack.Navigator>
  );
}

But for a more realistic scenario where we have both an existing layout like a Stack navigation and a Modal navigation that can be triggered from both the Home and the Details screen we have to break the view hierarchy in to multiple Navigators.

It is easier to think in terms of file system made up of files and directories. The files are equivalent to the screen contents and the directories are the navigators that do not have much of a content but provide a container for a set of screens that can then transition to each other.

App
├── RootLayout
│   ├── MainLayout
│   │   ├── HomeScreen
│   │   └── DetailsScreen
│   └── ModalScreen

We need to update our RootLayout to have a Main and Modal. The Main can then delegate to the existing Stack navigator.

export type RootParams = {
  Main: undefined;
  Modal: undefined;
};

const RootNavigator = createNativeStackNavigator<RootParams>();

export function RootLayout() {
  return (
    <RootNavigator.Navigator
      screenOptions={ { presentation: "modal", headerShown: false } }
    >
      <RootNavigator.Screen name="Main" component={MainLayout} />
      <RootNavigator.Screen name="Modal" component={ModalScreen} />
    </RootNavigator.Navigator>
  );
}

export type MainParams = {
  Home: undefined;
  Details: { text: string };
};

const MainNavigator = createNativeStackNavigator<MainParams>();

export function MainLayout() {
  return (
    <MainNavigator.Navigator>
      <MainNavigator.Screen name="Home" component={HomeScreen} />
      <MainNavigator.Screen name="Details" component={DetailsScreen} />
    </MainNavigator.Navigator>
  );
}

Within a screen we can use the rootNavigation to show the Modal screen.

export default function HomeScreen() {
  const mainNavigation = useNavigation<NativeStackNavigationProp<MainParams>>();
  const rootNavigation = useNavigation<NativeStackNavigationProp<RootParams>>();

  return (
    <View style={Styles.screen}>
      <Text style={Styles.h2}>Home Screen</Text>
      <TouchableOpacity
        onPress={() =>
          mainNavigation.navigate("Details", { text: "Hello world!" })
        }
      >
        <Text style={Styles.button}>Show details</Text>
      </TouchableOpacity>
      <TouchableOpacity onPress={() => rootNavigation.navigate("Modal")}>
        <Text style={Styles.button}>Show modal</Text>
      </TouchableOpacity>
      <StatusBar style="auto" />
    </View>
  );
}

Bottom Tabs

Bottom Tabs is a navigation pattern where there are tab icons at the bottom of the screen with every icon switching to a different flow.

npm install @react-navigation/bottom-tabs

Extending our example from above if we wish to have bottom tab bar we are looking for this structure:

App
├── RootLayout
│   ├── TabLayout 
│   │     ├── MainLayout
│   │     │   ├── HomeScreen
│   │     │   └── DetailsScreen
│   │     └── SettingsScreen
│   └── ModalScreen

The plan is to have two tabs. First one for the Stack containing both Home and Details screens. And the second one containing just a single Settings screen. And then at the root level we still have the Modal navigation.

export function RootLayout() {
  return (
    <RootNavigator.Navigator
      screenOptions={ { presentation: "modal", headerShown: false } }
    >
      <RootNavigator.Screen name="Tab" component={TabLayout} />
      <RootNavigator.Screen name="Modal" component={ModalScreen} />
    </RootNavigator.Navigator>
  );
}

export type TabParams = {
  Main: undefined;
  Settings: undefined;
};

const TabNavigator = createBottomTabNavigator<TabParams>();

export default function TabLayout() {
  return (
    <TabNavigator.Navigator screenOptions={ { headerShown: false } }>
      <TabNavigator.Screen
        name="Main"
        component={MainLayout}
        options={ {
          tabBarIcon: ({ color, size }) => (
            <FontAwesome name="home" size={size} color={color} />
          ),
        } }
      />
      <TabNavigator.Screen
        name="Settings"
        component={SettingsScreen}
        options={ {
          tabBarIcon: ({ color, size }) => (
            <FontAwesome name="gear" size={size} color={color} />
          ),
        } }
      />
    </TabNavigator.Navigator>
  );
}

References

React Navigation

Introduction to JavaScriptCore with iOS

2025-10-01T20:08:00+00:00

iOS for some reason provides an excellent integration with javascript via JavaScriptCore. Let’s have some fun with it.

Set up

So if we have a function defined in js

// main.js
function greeting() {
  return "Hello from JS!"
}

First we need to set up the js context:

JSVirtualMachine *_vm;
JSContext *_context;

_vm = [[JSVirtualMachine alloc] init];
_context = [[JSContext alloc] initWithVirtualMachine:_vm];

Then we need to load our javascript

- (void)evaluate:(NSString *)filename {
  NSURL *sourceURL = [[[NSBundle mainBundle] bundleURL] URLByAppendingPathComponent:filename];
  NSError *error = nil;
  NSString *script = [NSString stringWithContentsOfURL:sourceURL
                                              encoding:NSUTF8StringEncoding
                                                 error:&error];
  if (error != nil) NSLog(@"Error: %@", [error description]);
  [_context evaluateScript:script withSourceURL:sourceURL];
}

[self evaluate:@"main.js"];

Calling javascript from native

Calling js from native is requires calling evaluateScript which returns a value of type JSValue. JSValue provides several convenience utilities to map the data back to native types.

JSValue *result = [_context evaluateScript:@"greeting()"];
NSLog(@"%@", [result toString]); // Hello from JS!

Another way to perform the same operation is by first getting the reference to the greeting and then invoking it

JSValue *greetingFn = _context[@"greeting"];
JSValue *result = [greetingFn callWithArguments:[NSArray array]];
NSLog(@"%@", [result toString]); // Hello from JS!

Keeping reference to JSValue

Since JSValue has a strong reference to its JSContext. So it is not safe to keep a strong reference to JSValue outside of its immediate scope. If we have a need to keep the reference arround, then the solution is to use JSManagedValue

JSManagedValue *jsv;

jsv = [JSManagedValue managedValueWithValue:_context[@"greeting"]];
[_vm addManagedReference:jsv withOwner:self];

JSValue *greetingFn = [jsv value];
[greetingFn callWithArguments:[NSArray array]];

[_vm removeManagedReference:jsv withOwner:self];

Calling native from javascript

So, if wish to have a print() that is actually implemented on the native side using with NSLog

function greeting() {
  print("Hello from JS!")
}

The simplest way is to use a block. The runtime does all the heavy lifting of mapping data from native to js.

_context[@"print"] = ^(NSString *message) {
  NSLog(@"JS:Log: %@", message);
};

JSValue *greetingFn = _context[@"greeting"];
[greetingFn callWithArguments:[NSArray array]];

Then to add something like console.log we need to first create a console object and have a log function as a property on it.

function greeting() {
  console.log("Hello from JS!")
}

JSValue *console = [JSValue valueWithNewObjectInContext:_context];
_context[@"console"] = console;
console[@"log"] = ^(NSString *message) {
  NSLog(@"JS:Log: %@", message);
};

In case we wisth to inject some native data type into js we need to use the JSExport. The idea is to expose a type interface as protocol JSExport and then provide the implementation is a NSObject subclass.

@protocol JSConsole <JSExport>
- (NSString *)version;
- (void)log:(NSString *)message;
@end

@interface Console : NSObject <JSConsole>
@end

@implementation Console
+ (NSInteger)version {
  return @"1.0";
}
- (void)log:(NSString *)message {
  NSLog(@"JS:Log: %@", message);
}
@end

Chess game

Enough theory, lets now make a chess random vs random game using chess.js.

Since most of the chess implementation is going to be provided with chess.js we just need to create a Chess instance and provide a playRandomMove() to update the state when invoked.

// main.js
const chess = new Chess();

function playRandomMove() {
  if (chess.isGameOver()) {
    return chess.ascii();
  }

  const moves = chess.moves();
  const move = moves[Math.floor(Math.random() * moves.length)];
  chess.move(move);
  return chess.ascii();
}

@interface ChessController () {
  JSVirtualMachine *_vm;
  JSContext *_context;
}
@end

@implementation ChessController
- (instancetype)init {
  self = [super init];
  if (self) {
    _vm = [[JSVirtualMachine alloc] init];
    _context = [[JSContext alloc] initWithVirtualMachine:_vm];
  }
  return self;
}

- (void)evaluate:(NSString *)filename {
  NSURL *sourceURL = [[[NSBundle mainBundle] bundleURL] URLByAppendingPathComponent:filename];
  NSError *error = nil;
  NSString *script = [NSString stringWithContentsOfURL:sourceURL
                                              encoding:NSUTF8StringEncoding
                                                 error:&error];
  if (error != nil) NSLog(@"Error: %@", [error description]);
  [_context evaluateScript:script withSourceURL:sourceURL];
}

- (void)setUp {
  [_context setExceptionHandler:^(JSContext *context, JSValue *exception) {
    NSLog(@"JS:Error: %@", exception);
  }];
  [self evaluate:@"chess.js"];
  [self evaluate:@"main.js"];
}

- (NSString *)playRandomMove {
  JSValue *moveFn = _context[@"playRandomMove"];
  JSValue *result = [moveFn callWithArguments:[NSArray array]];
  NSString *board = [result toString];
  return board;
}
@end

Next for the native UI we only require a simple text view that renders the latest chess board.

@interface ViewController () {
  ChessController *_chessCtrl;
  UITextView *_textVw;
}
@end

@implementation ViewController
- (void)viewDidLoad {
  [super viewDidLoad];
  
  CGSize winSize = self.view.frame.size;
  CGFloat size = MIN(winSize.width, winSize.height);
  CGRect frame = CGRectMake(0, 0, size, size);
  
  _textVw = [[UITextView alloc] initWithFrame:frame];
  [_textVw setCenter:[self.view center]];
  [_textVw setEditable:NO];
  [_textVw setFont:[UIFont monospacedSystemFontOfSize:20
            weight:UIFontWeightBold]];
  [self.view addSubview:_textVw];
  
  _chessCtrl = [[ChessController alloc] init];
  [_chessCtrl setUp];
  
  [NSTimer scheduledTimerWithTimeInterval:1
                                   target:self
                                 selector:@selector(playRandomMove)
                                 userInfo:nil
                                  repeats:YES];
}

- (void)playRandomMove {
  [_textVw setText:[_chessCtrl playRandomMove]];
}
@end

References

Hello NativeScript

2025-09-08T16:27:00+00:00

So the framework for today is NativeScript. I’ve heard quite a few good things about NativeScript and have often heard various comparisons between NativeScript and ReactNative. So I would like to try it out myself and see where it stands.

And for this task I’m going to build my all time favorite app - PhotoApp

Set up

Install nativescript with npm install -g nativescript

Check Android set up ns doctor android

No issues were detected.
✔ Your ANDROID_HOME environment variable is set and points to correct directory.
✔ Your adb from the Android SDK is correctly installed.
✔ The Android SDK is installed.
✔ A compatible Android SDK for compilation is found.
✔ Javac is installed and is configured properly.
✔ The Java Development Kit (JDK) is installed and is configured properly.
✔ Getting NativeScript components versions information...
✔ Component nativescript has 8.9.3 version and is up to date.

Check iOS set up ns doctor ios

No issues were detected.
✔ Xcode is installed and is configured properly.
✔ xcodeproj is installed and is configured properly.
✔ CocoaPods are installed.
✔ CocoaPods update is not required.
✔ CocoaPods are configured properly.
✔ Your current CocoaPods version is newer than 1.0.0.
✔ Python installed and configured correctly.
✔ Xcode version 16.3.0 satisfies minimum required version 10.
✔ Getting NativeScript components versions information...
✔ Component nativescript has 8.9.3 version and is up to date.

Create a new app ns create photo-app --js

.
├── app
├── App_Resources
├── hooks
├── jsconfig.json
├── nativescript.config.ts
├── node_modules
├── package-lock.json
├── package.json
├── README.md
└── webpack.config.js

Run ns run ios

UI

Native script works with a 2 way binding between the UI described in xml files and the corresponding view model written in javascript.

The minimal example would be to create a sample-page.xml and a corresponding sample-page.js:

<Page xmlns="http://schemas.nativescript.org/tns.xsd" navigatingTo="navigatingTo">
    <ActionBar title="Sample" />
    <StackLayout class="p-20">
        <Label text="" class="h2 text-center" textWrap="true" />
        <Button text="Tap here" tap="" class="-primary" />
    </StackLayout>
</Page>

import { Observable } from "@nativescript/core";

function createViewModel() {
  const viewModel = new Observable();
  viewModel.message = "Hello world!"
  return viewModel;
}

export function navigatingTo(args) {
  const page = args.object;
  page.bindingContext = createViewModel();
}

In this example the UI invokes the navigatingTo() whenever the page is rendered for the first time where can create our view model as an Observable type and pass it back to the UI as bindingContext.

Based on this information, if we mock a PhotoService as:

photos = [
    {
      id: "37",
      author: "Austin Neill",
      width: 2000,
      height: 1333,
      url: "https://unsplash.com/photos/erTjj730fMk",
      download_url: "https://picsum.photos/id/37/2000/1333",
    },
    /* ... */
];

export function getPhotos() {
  return photos;
}

export function getPhotoById(id) {
  return photos.find((it) => it.id === id) || undefined;
}

Then we can create our home-page as:

<Page xmlns="http://schemas.nativescript.org/tns.xsd" navigatingTo="navigatingTo">
  <ActionBar title="Photos" />
  <StackLayout height="100%">
    <ListView
      height="100%"
      separatorColor="transparent"
      items=""
      itemTap=""
      margin="10"
    >
      <ListView.itemTemplate>
        <GridLayout
          height="280"
          borderRadius="10"
          class="bg-secondary"
          rows="*, auto, auto"
          columns="*"
          margin="5 10"
          padding="0"
        >
          <Image
            row="0"
            margin="0"
            stretch="aspectFill"
            src=""
            backgroundColor="grey"
          />
          <Label
            row="1"
            margin="10 10 0 10"
            fontWeight="400"
            class="text-primary"
            fontSize="18"
            text=""
          />
        </GridLayout>
      </ListView.itemTemplate>
    </ListView>
  </StackLayout>
</Page>

import { Frame, Observable, ObservableArray } from "@nativescript/core";
import * as PhotoService from "../services/photos.service";

function createViewModel() {
  const viewModel = new Observable();
  viewModel.photos = PhotosService.getPhotos();
  viewModel.onPhotoTap = (args) => { /* TODO */ };
  return viewModel;
}

export function navigatingTo(args) {
  if (args.isBackNavigation) {
    return;
  }

  const page = args.object;
  page.bindingContext = createViewModel();
}

And our details page as:

<Page xmlns="http://schemas.nativescript.org/tns.xsd" navigatingTo="navigatingTo">
    <ActionBar title="" />
     <StackLayout class="p-20">
        <Image src="" />
        <Label text="" class="caption text-center" textWrap="true" />
    </StackLayout>
</Page>

import { Observable } from "@nativescript/core";
import * as PhotoService from "../services/photos.service";

function createViewModel() {
  const viewModel = new Observable();
  viewModel.photo = PhotosService.getPhotoById("42");
  return viewModel;
}

export function navigatingTo(args) {
  const page = args.object;
  page.bindingContext = createViewModel();
}

To navigate from home to details page we need update our home-page.js to:

  viewModel.onPhotoTap = (args) => {
    Frame.topmost().navigate({
      moduleName: "details/details-page",
      context: { photoId: viewModel.photos[args.index].id },
    });
  };

And then the details-page.js to parse the photoId

function createViewModel(args) {
  const viewModel = new Observable();
  viewModel.photo = PhotoService.getPhotoById(args.photoId);

  viewModel.onRefresh = () => {
    viewModel.set("photo", PhotoService.getPhotoById(args.photoId));
  };

  return viewModel;
}

export function onNavigatingTo(args) {
  const page = args.object;
  page.bindingContext = createViewModel(page.navigationContext);
}

Networking

The final piece in the puzzle is fetching the data from the internet. That means updating our PhotoService to async

async function getData(url) {
  try {
    const response = await fetch(url);
    if (!response.ok) {
      throw new Error(`Response status: ${response.status}`);
    }
    return await response.json();
  } catch (error) {
    console.error(error.message);
    return null;
  }
}

export async function getPhotos() {
  return await getData("https://picsum.photos/v2/list?page=2");
}

export async function getPhotoById(id) {
  return await getData(`https://picsum.photos/id/${id}/info`);
}

And then bubbling up the async calls to the view models layer

export async function onNavigatingTo(args) {
  // ...
  const page = args.object;
  page.bindingContext = await createViewModel();
}

async function createViewModel() {
  const viewModel = new Observable();
  viewModel.photos = await PhotoService.getPhotos();
  // ...
  return viewModel;
}

Since the data is now coming via a network call. So we need to add a loading state to the app. This means two things. First we need to update our home page to have a loading indicator.

<Page xmlns="http://schemas.nativescript.org/tns.xsd">
  <ActionBar title="Photos" />
  <GridLayout height="100%" rows="*" columns="*">
    <ActivityIndicator
      busy="true"
      visibility=""
      row="0"
    />
    <StackLayout height="100%" row="0">
      <!-- ... -->
    </StackLayout>

  </GridLayout>
</Page>

And second, we need to update our view model to handle both navigatingTo and navigatedTo

<Page
  xmlns="http://schemas.nativescript.org/tns.xsd"
  navigatingTo="onNavigatingTo"
  navigatedTo="onNavigatedTo"
>
  <!--  -->
</Page>

export function onNavigatingTo(args) {
  if (args.isBackNavigation) {
    return;
  }
  const page = args.object;
  page.bindingContext = {
    loadingVisibility: "visible",
    photos: [],
    onPhotoTap: null,
  };
}

export async function onNavigatedTo(args) {
  const page = args.object;
  page.bindingContext = await createViewModel();
}

async function createViewModel() {
  const viewModel = new Observable();
  viewModel.loadingVisibility = "hidden";
  viewModel.photos = await PhotoService.getPhotos();
  // ...
  return viewModel;
}

Two column grid

And next lets make the UI a 2 column grid. Surprisingly, the official API does not provide anything out of the box and the recommended way is to use a community plugin ui-collectionview-alignedflowlayout. So that means we need update our package.json to:

"dependencies": {
    "@nativescript-community/ui-collectionview-alignedflowlayout": "^6.0.4",
}

And then to configure the plugin we need to update the app.js

import install from "@nativescript-community/ui-collectionview-alignedflowlayout";
install();

And then we can finally update the UI in home-page.xml to:

<gv:CollectionView row="0" items="" colWidth="50%" rowHeight="150">
    <gv:CollectionView.itemTemplate>
      <Image
        row="0"
        margin="8"
        stretch="aspectFill"
        src=""
        backgroundColor="grey"
      />
  </gv:CollectionView.itemTemplate>
</gv:CollectionView>

Conclusion

NativeScript looks really mature. I like the clear separation between xml and js. And I certainly belive some great apps can be built using it and I would love to play more with this tech.

References

SwiftUI stateless bindings

2025-06-25T20:57:00+00:00

In the Apple’s SwiftUI RecipeBook sample there is this code that broke my brain:

private var recipe: Binding<Recipe> {
    Binding {
        if let id = recipeId {
            return recipeBox.recipe(with: id) ?? Recipe.emptyRecipe()
        } else {
            return Recipe.emptyRecipe()
        }
    } set: { updatedRecipe in
        recipeBox.update(updatedRecipe)
    }
}

What this piece of code does is nothing more than providing a Binding to an item within an array of Recipe and it is pretty interesting way to achieve. So no @State involved whatsoever.

This is very useful for situations where we have main screen with a list of items and an editable details screen and we would like the changes to be reflected back on the main screen.

To elaborate let me create a minified version of the above mentioned Apple’s RecipeSample app.

So we obviously first we need the Recipe model

struct Recipe: Identifiable, Codable {
  var id: String
  var title: String
  var isFavorite: Bool
}

And then a RecipeViewModel which is the brain behind our entire app

class RecipeViewModel: ObservableObject {
  @Published var recipes: [Recipe]
  
  init() {
    self.recipes = [
      "Apple Cake",
      "Chickpea Curry",
      "Chocolate Peanut Butter Truffles",
      "Passion Fruit-Mango Sorbet",
      "Mushroom Tapioca",
      "Spicy Tomato Sauce",
    ].map { title in
      Recipe(id: UUID().uuidString, title: title, isFavorite: Bool.random())
    }
  }
  
  func recipe(with id: Recipe.ID) -> Recipe? {
    recipes.first(where: { $0.id == id })
  }
  
  func update(_ recipe: Recipe) {
    guard let index = recipes.firstIndex(where: { $0.id == recipe.id }) else {
      return
    }
    recipes[index] = recipe
  }
}

And then the root view of the app which provides the basic layout of the app and injects the RecipeViewModel as environment object so that it is available throughout the app. This is also where we hold the @State var selectedRecipeId: Recipe.ID?. And thanks to the SwiftUI magic whenever a Recipe is selected the app navigates to the details view RecipeEditView

@main
struct RecipesApp: App {
  var body: some Scene {
    WindowGroup {
      AppView()
    }
  }
}

struct AppView: View {
  @StateObject private var viewModel = RecipeViewModel()
  @State private var selectedRecipeId: Recipe.ID?
  
  var body: some View {
    NavigationStack {
      RecipeListView(selectedRecipeId: $selectedRecipeId)
        .navigationTitle("Recipes")
        .navigationDestination(item: $selectedRecipeId) { recipeId in
          RecipeEditView(recipeId: recipeId)
        }
    }
    .environmentObject(viewModel)
  }
}

The list view RecipeListView is actually pretty basic. It just renders a list of Recipe. The only important thing here is to not forgetting to wrap the content within NavigationLink to have the SwiftUI navigation magic to work.

struct RecipeListView: View {
  @Binding var selectedRecipeId: Recipe.ID?
  @EnvironmentObject private var viewModel: RecipeViewModel
  
  private var recipes: [Recipe] {
    viewModel.recipes
  }
  
  var body: some View {
    List(recipes, selection: $selectedRecipeId) { recipe in
      NavigationLink(value: recipe.id) {
        RecipeEditView(recipeId: recipe.id)
      }
    }
  }
}

Now the most interesting bit, the RecipeEditView. Since so far we have only provided data in terms of Recipe.ID this is where we need to map it to a read-write Binding to the underlying Recipe

struct RecipeEditView: View {
  
  var recipeId: Recipe.ID
  @EnvironmentObject private var viewModel: RecipeViewModel

  private var recipe: Binding<Recipe> {
    Binding(
      get: { viewModel.recipe(with: recipeId)! },
      set: { recipe in viewModel.update(recipe) }
    )
  }
    
  var body: some View {
    RecipeView(recipe: recipe)
  }
}

And finally a view to render Recipe with RecipeView

struct RecipeView: View {
  @Binding var recipe: Recipe
  
  var body: some View {
    HStack {
      Text(recipe.title)
        .font(.title3)
      
      Spacer()

      Button {
        recipe.isFavorite.toggle()
      } label: {
        Image(systemName: recipe.isFavorite ? "heart.fill" : "heart")
          .foregroundStyle(.red)
      }
    }
  }
}

Move me - Flutter edition

2025-05-14T21:03:00+00:00

Let us build the MoveMe one more time but with Flutter.

Set up

First thing first, let’s create an empty project with flutter create move_me.

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(title: 'Move Me', home: MoveMePage());
  }
}

class MoveMePage extends StatefulWidget {
  const MoveMePage({super.key});

  @override
  State<MoveMePage> createState() => _MoveMePageState();
}

class _MoveMePageState extends State<MoveMePage> {
  @override
  Widget build(BuildContext context) {
    return const Placeholder();
  }
}

And give it a run with flutter run.

Layout

Next up, we need 3 blue squares lined up in the center.

So if we have a widget that draws a square

class _Box extends StatelessWidget {
  final Size size;
  final Color color;

  const _Box({required this.size, required this.color});

  @override
  Widget build(BuildContext context) {
    return Container(color: color, width: size.width, height: size.height);
  }
}

And we render three of these squares in a Stack we should be done right?

class _MoveMePageState extends State<MoveMePage> {
  final _origins = [Offset.zero, Offset.zero, Offset.zero];
  final _size = Size(100, 100);

  @override
  Widget build(BuildContext context) {
    return Stack(
      children: [
        for (var idx = 0; idx < _origins.length; idx++)
          Positioned(
            top: _origins[idx].dy,
            left: _origins[idx].dx,
            child: _Box(size: _size, color: Colors.blue),
          ),
      ],
    );
  }
}

Almost there. This would render all the three square right up at the top left corner. But we need them to be at the center remember? The magic is to let the widget tree render once and then update the origins based on the window size:

class _MoveMePageState extends State<MoveMePage> {
  // ...
  final _origins = [Offset.zero, Offset.zero, Offset.zero];

    @override
  void initState() {
    super.initState();
    WidgetsBinding.instance.addPostFrameCallback((_) {
      final window = WidgetsBinding.instance.platformDispatcher.views.first;
      final size = window.physicalSize / window.devicePixelRatio;
      setState(() {
        for (var idx = 0; idx < _origins.length; idx++) {
          // [0,1,2] (x.25) [0,.25,.5] (+.25) [.25,.50,75]
          var dy = (idx.toDouble() * 0.25) + 0.25;
          _origins[idx] = Offset(
            (size.width - _size.width) * 0.5,
            (size.height - _size.height) * dy,
          );
        }
      });
    });
  }

  // ...
}

And now we should be all set for the adventure

Gestures

Next challenge in our journey is to add gestures. What we need is a way to allow dragging of these beautiful squares around.

One way to achieve this by use the Draggable and its sidekick DragTarget.

So first we need to wrap our square within Draggable, actually 3 squares per square - one for each state normal, selected and shadow. The shadow state is the one that is the original start position, the one where square is going to snap back if something goes wrong. Since we don’t care about that state, we would render it with transparent color.

We also need some sort of identifier to tell each square later to keep track of their positions. And we can use the int name just for that.

class _DraggableBox extends StatelessWidget {
  final Size size;
  final int name;

  _DraggableBox({required this.size, required this.name});

  @override
  Widget build(BuildContext context) {
    return Draggable(
      data: name,
      feedback: _Box(size: size, color: Colors.red), // selected 
      childWhenDragging: _Box(size: size, color: Colors.transparent), // shadow
      child: _Box(size: size, color: Colors.blue), // normal
   );
  }
}

With that in place, we need the DragTarget, the parent widget that accepts the drag changes of any of our square. For our case we can simply update the origin of the squares when drag change is detected.

class _MoveMePageState extends State<MoveMePage> {
  // ...
  final _origins = [Offset.zero, Offset.zero, Offset.zero];

  @override
  Widget build(BuildContext context) {
    return Stack(
      children: [
        DragTarget<int>(
          builder: (context, accepted, rejected) => Container(),
          onAcceptWithDetails: (details) {
            setState(() {
              _origins[details.data] = details.offset;
            });
          },
        ),
        for (var idx = 0; idx < _origins.length; idx++)
          Positioned(
            top: _origins[idx].dy,
            left: _origins[idx].dx,
            child: _DraggableBox(size: _size, name: idx),
          ),
      ],
    );
  }

  // ...
}

And with that in place we should have a simple non animated version of MoveMe

Animations

But as they say the last 20 percent takes the 80 percent. Let’s see how much work is it with flutter.

To start with we can update our _Box to handle scale transitions using the TweenAnimationBuilder and the Transform.scale

class _Box extends StatelessWidget {
  final Size size;
  final double scaleBegin;
  final double scaleEnd;
  final Color color;

  const _Box({
    required this.size,
    required this.scaleBegin,
    required this.scaleEnd,
    required this.color,
  });

  @override
  Widget build(BuildContext context) {
    return TweenAnimationBuilder(
      tween: Tween(begin: scaleBegin, end: scaleEnd),
      duration: Durations.medium1,
      curve: Easing.standardAccelerate,
      builder: (context, scale, child) {
        return Transform.scale(
          scale: scale,
          child: Container(
            color: color,
            width: size.width,
            height: size.height,
          ),
        );
      },
    );
  }
}

And then we need to update the _DraggableBox to provide the correct scale start and end values:

class _DraggableBox extends StatelessWidget {
  final Size size;
  final int name;

  _DraggableBox({required this.size, required this.name});

  @override
  Widget build(BuildContext context) {
    return Draggable<int>(
      data: name,
      feedback: _Box(
        size: size,
        scaleBegin: 1.0,
        scaleEnd: 1.2,
        color: Colors.red,
      ),
      childWhenDragging: Container(
        color: Colors.transparent,
        width: size.width,
        height: size.height,
      ),
      child: _Box(
        size: size,
        scaleBegin: 1.2,
        scaleEnd: 1.0,
        color: Colors.blue,
      ),
    );
  }
}

And I guess that is all we need to be able to animate the scale up and down on drag begin and end

Conclusion

Every time I work with flutter, I feel like this is probably the best cross-platform framework out there. All of the documentation is top notch. The API feels very well designed, fits perfectly with the Alan Kay’s principle of designing things: “Simple things should be simple, complex things should be possible”.

I look forward to work more with flutter in the future.

The code from this experiment is at github.com/chunkyguy/MoveMe

Compose multiplatform is real!

2025-01-12T08:56:00+00:00

So yes after getting my hands dirty with Kotlin multiplatform the obvious next step would be to try Compose multiplatform. Which I did. And yes it’s a game changer.

Set up

The setup for compose multiplatfrom as of today is a bit weird. First you need to the same set up as for Kotlin multiplatform, which makes sense. And then, you need to visit the https://kmp.jetbrains.com/ to create the boilerplate project. This web app then gives you a zip file that you download and open with Android Studio. But for me it all went pretty straightforward. No hiccups.

With compse multiplatform you don’t have to think in terms for different platforms anymore. Which is great. The folder structure looks like:

.
├── README.md
├── build
│   ├── ios
│   ├── kotlin
│   └── tmp
├── build.gradle.kts
├── composeApp
│   ├── build
│   ├── build.gradle.kts
│   └── src
├── gradle
│   ├── libs.versions.toml
│   └── wrapper
├── gradle.properties
├── gradlew
├── gradlew.bat
├── iosApp
│   ├── Configuration
│   ├── iosApp
│   └── iosApp.xcodeproj
├── local.properties
└── settings.gradle.kts

So most of the app’s source code lives within the composeApp/src directory.

Another nice thing about compose multiplatform is that you can build and run the app on iOS simulator directly from Android Studio.

Next installing dependencies is a bit challenging. Since you need to figure out if the dependency is okay for compose multiplatform. Otherwise figure out the alternatives and update the dependencies.

Fortunately for our PhotoApp though, all the libraries we wanted to use are already available for compose multiplatform.

Here’s the libs.versions.toml and the composeApp/build.gradle.kts files we need.

[versions]
# ...
ktor = "3.0.3"
kotlinxSerializationJson = "1.6.3"
coroutines = "1.9.0"
coil = "3.0.4"
androidx-navigation = "2.8.0-alpha10"

[libraries]
# ...
ktor-client-core = { module = "io.ktor:ktor-client-core", version.ref = "ktor" }
ktor-client-okhttp = { module = "io.ktor:ktor-client-okhttp", version.ref = "ktor" }
ktor-client-darwin = { module = "io.ktor:ktor-client-darwin", version.ref = "ktor" }
ktor-serialization-kotlinx-json = { module = "io.ktor:ktor-serialization-kotlinx-json", version.ref = "ktor" }
ktor-client-content-negotiation = { module = "io.ktor:ktor-client-content-negotiation", version.ref = "ktor" }
kotlinx-coroutines-core = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-core", version.ref = "coroutines" }
kotlinx-coroutines-android = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-android", version.ref = "coroutines" }
kotlinx-serialization-json = { module = "org.jetbrains.kotlinx:kotlinx-serialization-json", version.ref = "kotlinxSerializationJson" }
coil-compose = { module = "io.coil-kt.coil3:coil-compose", version.ref = "coil" }
coil-network-ktor = { module = "io.coil-kt.coil3:coil-network-ktor3", version.ref = "coil" }
androidx-navigation-compose = { module = "org.jetbrains.androidx.navigation:navigation-compose", version.ref = "androidx-navigation" }

[plugins]
# ...
kotlinMultiplatform = { id = "org.jetbrains.kotlin.multiplatform", version.ref = "kotlin" }
kotlin-serialization = { id = "org.jetbrains.kotlin.plugin.serialization", version.ref = "kotlin" }

plugins {
  // ...
  alias(libs.plugins.composeMultiplatform)
  alias(libs.plugins.kotlin.serialization)
}

kotlin {

  sourceSets {
    androidMain.dependencies {
      implementation(compose.preview)
      implementation(libs.androidx.activity.compose)
      implementation(libs.ktor.client.okhttp)
    }

    iosMain.dependencies {
      implementation(libs.ktor.client.darwin)
    }

    commonMain.dependencies {
      implementation(compose.runtime)
      implementation(compose.foundation)
      implementation(compose.material)
      implementation(compose.ui)
      implementation(compose.components.resources)
      implementation(compose.components.uiToolingPreview)
      implementation(libs.androidx.lifecycle.viewmodel)
      implementation(libs.androidx.lifecycle.runtime.compose)
      implementation(libs.ktor.client.core)
      implementation(libs.ktor.serialization.kotlinx.json)
      implementation(libs.ktor.client.content.negotiation)
      implementation(libs.kotlinx.coroutines.core)
      implementation(libs.kotlinx.serialization.json)
      implementation(libs.androidx.navigation.compose)
      implementation(libs.coil.compose)
      implementation(libs.coil.network.ktor)
    }
  }

  // ...
}

// ...

Writing code

For the PhotoApp I did not had to touch the composeApp/androidMain or the composeApp/iosMain. But if there’s any platform specific code required, this is where it has to live. For our app we only have to touch the composeApp/commonMain.

Starting with the network layer, the NetworkService looks very much like as with the regualar ktor based Android app.

@Serializable
data class Photo(
  val albumId: Int?,
  val id: Int?,
  val title: String?,
  val url: String?,
  val thumbnailUrl: String?
)

class NetworkService {
  private val client = HttpClient() {
    install(ContentNegotiation) { json()}
  }

  suspend fun photos(): List<Photo> {
    return client
      .get("https://jsonplaceholder.typicode.com/photos")
      .body()
  }
}

Next up, the components are also very regular Compose based components

@Composable
fun PhotoCardView(
  photoUrl: String?,
  photoTitle: String?,
  modifier: Modifier = Modifier
) {
  Column {
    Card(
      modifier = modifier,
      shape = MaterialTheme.shapes.medium,
      elevation = 8.dp,
    ) {
      AsyncImage(
        model = photoUrl,
        contentDescription = photoTitle,
        contentScale = ContentScale.Crop,
        modifier = Modifier.fillMaxWidth(),
      )
    }
    Text(photoTitle ?: "")
  }
}

@Composable
fun PhotoGridView(
  onSelectPhoto: (Photo) -> Unit,
  photos: List<Photo>,
  modifier: Modifier = Modifier,
  contentPadding: PaddingValues = PaddingValues(0.dp),
) {
  LazyVerticalGrid(
    columns = GridCells.Adaptive(150.dp),
    modifier = modifier.padding(horizontal = 4.dp),
    contentPadding = contentPadding,
  ) {
    items(
      items = photos,
      key = { photo -> photo.id ?: 0 }
    ) { photo ->
      Surface(onClick = { onSelectPhoto(photo) }) {
        PhotoCardView(
          photoUrl = photo.thumbnailUrl,
          photoTitle = null,
          modifier = Modifier
            .padding(4.dp)
            .fillMaxWidth()
            .aspectRatio(1f)
        )
      }
    }
  }
}

And finally the main App component, which is the starting point for the app also looks like a regular compose UI based component

@Composable
fun App() {
  MaterialTheme {
    Surface(
      modifier = Modifier.fillMaxSize(),
      color = MaterialTheme.colors.background,
    ) {
      val scope = rememberCoroutineScope()
      val navController = rememberNavController()
      var photos: List<Photo> by remember { mutableStateOf(emptyList()) }
      LaunchedEffect(true) {
        scope.launch {
          photos = try {
            NetworkService().photos()
          } catch (e: Exception) {
            emptyList()
          }
        }
      }
      NavHost(
        navController = navController,
        startDestination = "home"
      ) {
        composable("home") {
          PhotoGridView(
            onSelectPhoto = { navController.navigate("photos/${it.id}") },
            photos = photos
          )
        }
        composable("photos/{id}") { entry ->
          val photoId = entry.arguments?.getString("id") ?: "0"
          val photo = photos.first { it.id.toString() == photoId }
          PhotoCardView(
            photoUrl = photo.url,
            photoTitle = photo.title,
            modifier = Modifier
              .padding(4.dp)
              .fillMaxWidth()
              .aspectRatio(1f)
          )
        }
      }
    }
  }
}

And with this I was able to build and run for both iOS and Android.

Conclusion

The first impression of compose multiplatform is really good. To be honest, I was expecting a lot more hiccups. But everything just went fine out of the box. Very impressive! I really loved the ability to run iOS app directly from Android Studio. I’m really looking forward to playing around more with this framework.

The code from this experiment is available at github.com/chunkyguy/PhotoApp

References

https://www.jetbrains.com/compose-multiplatform/

Hello Kotlin Multiplatform

2025-01-05T14:09:00+00:00

What better way to start the new year than trying out the Kotlin Multiplatform.

I wanted to try KMM for a very long time now. But first I wanted to get enough knowledge of Kotlin and the Android development environment. Which I think I’ve sort of good enough now. So let’s take a quick look at KMM.

Setup

To verify if everything is in order we can use the kdoctor.

 kdoctor        
...
Conclusion:
  ✓ Your operation system is ready for Kotlin Multiplatform Mobile Development!

And then there is the amazing KMM plugin for Android Studio which provides a nice template for creating a new project from Android Studio.

Next update the dependencies by updating the libs.versions.toml. The idea here is to list all of the libraries regardless of the platform, we will get the chance later to add libraries to targets later on.

[versions]
ktor = "3.0.3"
kotlinxSerializationJson = "1.6.3"
coroutines = "1.9.0"
coil = "3.0.4"
androidx-navigation = "2.7.7"

[libraries]
ktor-client-core = { module = "io.ktor:ktor-client-core", version.ref = "ktor" }
ktor-client-okhttp = { module = "io.ktor:ktor-client-okhttp", version.ref = "ktor" }
ktor-client-darwin = { module = "io.ktor:ktor-client-darwin", version.ref = "ktor" }
ktor-serialization-kotlinx-json = { module = "io.ktor:ktor-serialization-kotlinx-json", version.ref = "ktor" }
ktor-client-content-negotiation = { module = "io.ktor:ktor-client-content-negotiation", version.ref = "ktor" }
kotlinx-coroutines-core = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-core", version.ref = "coroutines" }
kotlinx-coroutines-android = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-android", version.ref = "coroutines" }
kotlinx-serialization-json = { module = "org.jetbrains.kotlinx:kotlinx-serialization-json", version.ref = "kotlinxSerializationJson" }
coil-kt-compose = { module = "io.coil-kt:coil-compose", version.ref = "coil" }
coil-compose = { module = "io.coil-kt.coil3:coil-compose", version.ref = "coil" }
coil-network-okhttp = { module = "io.coil-kt.coil3:coil-network-okhttp", version.ref = "coil" }
androidx-navigation-compose = { module = "androidx.navigation:navigation-compose", version.ref = "androidx-navigation" }

[plugins]
kotlin-serialization = { id = "org.jetbrains.kotlin.plugin.serialization", version.ref = "kotlin" }

Next we first need to add the dependencies for the shared library in shared/build.gradle.kts.

plugins {
  // ...
  alias(libs.plugins.kotlin.serialization)
}

kotlin {
  // ...

  sourceSets {
    commonMain.dependencies {
      implementation(libs.ktor.client.core)
      implementation(libs.ktor.serialization.kotlinx.json)
      implementation(libs.ktor.client.content.negotiation)
      implementation(libs.kotlinx.coroutines.core)
      implementation(libs.kotlinx.serialization.json)
    }

    androidMain.dependencies {
      implementation(libs.ktor.client.okhttp)
    }

    iosMain.dependencies {
      implementation(libs.ktor.client.darwin)
    }
  }
}

// ...

Notice how we provide different ktor engines per platform. So okhttp for android and darwin for iOS.

Next, for the Android app we need to update the PhotoAppAndroidApp/build.gradle.kts

// ...

dependencies {
  implementation(projects.shared)
  implementation(libs.compose.ui)
  implementation(libs.compose.ui.tooling.preview)
  implementation(libs.compose.material3)
  implementation(libs.androidx.activity.compose)
  implementation(libs.kotlinx.coroutines.android)
  implementation(libs.coil.compose)
  implementation(libs.coil.network.okhttp)
  implementation(libs.androidx.navigation.compose)
}

Regarding iOS app, we can simply open the PhotoAppApple/PhotoAppApple.xcodeproj and update the settings if required. For example I was getting some Java errors due to Xcode unable to find JAVA_HOME so I had to manually update the Build Phase > Run Script to

export JAVA_HOME="/opt/homebrew/opt/openjdk"

cd "$SRCROOT/.."
./gradlew :shared:embedAndSignAppleFrameworkForXcode

Networking

Since networking is part of the shared module, we can have the entire network layer as

package com.whackylabs.photoapp

@Serializable
data class Photo(
  val albumId: Int?,
  val id: Int?,
  val title: String?,
  val url: String?,
  val thumbnailUrl: String?
)

package com.whackylabs.photoapp

class NetworkService {
  private val client = HttpClient() {
      install(ContentNegotiation) { json() }
  }

  suspend fun photos(): List<Photo> {
    return client
            .get("https://jsonplaceholder.typicode.com/photos")
            .body()
  }
}

Android UI

The Android UI can be built with the regular Jetpack compose

package com.whackylabs.photoapp.android

class MainActivity : ComponentActivity() {
  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContent {
      MyApplicationTheme {
        Surface(
          modifier = Modifier.fillMaxSize(),
          color = MaterialTheme.colorScheme.background
        ) {
          val scope = rememberCoroutineScope()
          val navController = rememberNavController()
          var photos: List<Photo> by remember { mutableStateOf(emptyList()) }
          LaunchedEffect(true) {
            scope.launch {
              photos = try {
                NetworkService().photos()
              } catch (e: Exception) {
                emptyList()
              }
            }
          }
          NavHost(navController = navController, startDestination = "home") {
            composable("home") {
              PhotoGridView(
                onSelectPhoto = { navController.navigate("photos/${it.id}") },
                photos = photos
              )
            }
            composable("photos/{id}") {
              val photoId = it.arguments?.getString("id") ?: "0"
              val photo = photos.first { it.id.toString() == photoId }
              PhotoCardView(
                photoUrl = photo.url,
                photoTitle = photo.title,
                modifier = Modifier
                  .padding(4.dp)
                  .fillMaxWidth()
                  .aspectRatio(1f)
              )
            }
          }
        }
      }
    }
  }
}

package com.whackylabs.photoapp.android

@Composable
fun PhotoCardView(
  photoUrl: String?,
  photoTitle: String?,
  modifier: Modifier = Modifier
) {
  Column {
    Card(
      modifier = modifier,
      shape = MaterialTheme.shapes.medium,
      elevation = CardDefaults.cardElevation(defaultElevation = 8.dp)
    ) {
      AsyncImage(
        model = photoUrl,
        contentDescription = photoTitle,
        contentScale = ContentScale.Crop,
        modifier = Modifier.fillMaxWidth(),
      )
    }
    Text(photoTitle ?: "")
  }
}

package com.whackylabs.photoapp.android

@Composable
fun PhotoGridView(
  onSelectPhoto: (Photo) -> Unit,
  photos: List<Photo>,
  modifier: Modifier = Modifier,
  contentPadding: PaddingValues = PaddingValues(0.dp),
) {
  LazyVerticalGrid(
    columns = GridCells.Adaptive(150.dp),
    modifier = modifier.padding(horizontal = 4.dp),
    contentPadding = contentPadding,
  ) {
    items(items = photos, key = { photo -> photo.id ?: 0 }) { photo: Photo ->
      Surface(onClick = { onSelectPhoto(photo) }) {
        PhotoCardView(
          photoUrl = photo.thumbnailUrl,
          photoTitle = null,
          modifier = Modifier
            .padding(4.dp)
            .fillMaxWidth()
            .aspectRatio(1f)
        )
      }
    }
  }
}

iOS UI

Similarly the iOS counterpart can be built with SwiftUI

@main
struct iOSApp: App {
  var body: some Scene {
    WindowGroup {
      ContentView()
    }
  }
}

struct ContentView: View {
  
  @State var photos: [Photo] = []
  
  let columns = [
    GridItem(.flexible(), alignment: .trailing),
    GridItem(.flexible(), alignment: .leading),
  ]
  
  var body: some View {
    NavigationStack {
      PhotoGridView(photos)
        .navigationTitle("Photos")
        .navigationDestination(for: Photo.self) { photo in
          PhotoCardView(
            photoUrl: photo.url,
            photoTitle: photo.title
          )
        }
    }
    .task {
      do {
        self.photos = try await NetworkService().photos()
      } catch {
        self.photos = []
      }
    }
  }
}

struct PhotoCardView: View {
  var photoUrl: String?
  var photoTitle: String?
  
  var body: some View {
    VStack {
      AsyncImage(url: photoUrl.flatMap(URL.init)) { image in
        image
          .resizable()
          .scaledToFit()
      } placeholder: {
        ProgressView()
      }

      Text(photoTitle ?? "")
    }
  }
}

struct PhotoGridView: View {
  var photos: [Photo] = []
  
  init(_ photos: [Photo]) {
    self.photos = photos
  }

  let columns = [
    GridItem(.flexible(), alignment: .trailing),
    GridItem(.flexible(), alignment: .leading),
  ]

  var body: some View {
    ScrollView {
      LazyVGrid(columns: columns) {
        ForEach(photos, id: \.id) { photo in
          NavigationLink(value: photo) {
            PhotoCardView(photoUrl: photo.thumbnailUrl, photoTitle: nil)
              .frame(width: 150, height: 150)
          }
        }
      }
    }
  }
}

Conclusion

I really love the vision of Kotlin Multiplatform. It helps with keeping all the business logic in one place while allowing the platform native UI. So you would love near to nothing. I also like it allows us app developers to use all the latest and greatest each platform has to offer. Like Jetpack Compose, Swift UI on the UI side of things while kotlin coroutines that get nicely mapped to Swift async-await API.

The only headache I had was with dealing with errors related to java vm. But I’m really looking forward to KMM becoming more mainstream.

The code from this experiment is available at github.com/chunkyguy/PhotoApp/tree/master/kmm

References

Finally trying out the Android XML layout

2024-12-28T09:55:00+00:00

So year after year since the dawn of the Android SDK back in 2009 I’ve been making the yearly resolution to try it out. But for one reason or the other I’ve always been putting it off. But not this year. Before the sun goes down for the last time for the year of 2024 let’s make our favorite photo app using the classic Android UI toolkit - The framework with no name - You know that thing where you write XML for layout. Let the fun begin!

Set up

I’m going to use retrofit for networking with glide for loading images all connected together via kotlin coroutines.

The first step is to install all the dependencies. Which from what I understand is now a 2 step job. First you list all the dependencies in the libs.versions.toml file

[versions]
kotlin = "2.0.0"
coroutinesKtx = "2.4.0"
coroutines = "1.9.0"
gson = "2.11.0"
retrofit = "2.11.0"
okhttp = "4.12.0"
glide = "4.16.0"

[libraries]
retrofit = { module = "com.squareup.retrofit2:retrofit", version.ref = "retrofit" }
gson = { module = "com.google.code.gson:gson", version.ref = "gson" }
retrofit-gson-converter = { module = "com.squareup.retrofit2:converter-gson", version.ref = "retrofit" }
okhttp-logging-interceptor = { module = "com.squareup.okhttp3:logging-interceptor", version.ref = "okhttp" }
glide = { module = "com.github.bumptech.glide:glide", version.ref = "glide" }
glide-compiler = { module = "com.github.bumptech.glide:compiler", version.ref = "glide" }
kotlinx-coroutines-core = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-core", version.ref = "coroutines" }
kotlinx-coroutines-android = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-android", version.ref = "coroutines" }
androidx-viewmodel-ktx = { module = "androidx.lifecycle:lifecycle-viewmodel-ktx", version.ref = "coroutinesKtx" }
androidx-runtime-ktx = { module = "androidx.lifecycle:lifecycle-runtime-ktx", version.ref = "coroutinesKtx" }

And then you actually add them to the project by updating the build.gradle.kts file

dependencies {
    implementation(libs.retrofit)
    implementation(libs.retrofit.gson.converter)
    implementation(libs.gson)
    implementation(libs.okhttp.logging.interceptor)
    implementation(libs.glide)
    annotationProcessor(libs.glide.compiler)

    implementation(libs.androidx.viewmodel.ktx)
    implementation(libs.androidx.runtime.ktx)
    implementation(libs.kotlinx.coroutines.core)
    implementation(libs.kotlinx.coroutines.android)
}

And finally, the most important step that I almost always forget. To add the INTERNET permission in the AndroidManifest.xml file

<manifest>
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <application>
        ...
    </application>
</manifest>

Fetching data

Creating the network layer is pretty straightforward with Retrofit. You declare an interface of the API and let retrofit do the rest.

For our needs, the API consists of just a single GET call to fetch a List of Photo

data class Photo(
    val albumId: Int?,
    val id: Int?,
    val title: String?,
    val url: String?,
    val thumbnailUrl: String?
) : Serializable

interface API {
    @GET("photos")
    suspend fun photos(): Response<List<Photo>>
}

class NetworkService {
    companion object {
        fun api(): API {
            val loggingInterceptor = HttpLoggingInterceptor()
            loggingInterceptor.level = HttpLoggingInterceptor.Level.BODY

            val okHttpClient = OkHttpClient
                .Builder()
                .addInterceptor(loggingInterceptor)
                .build()

            val retrofit = Retrofit
                .Builder()
                .baseUrl("https://jsonplaceholder.typicode.com/")
                .addConverterFactory(GsonConverterFactory.create())
                .client(okHttpClient)
                .build()

            return retrofit.create(API::class.java)
        }
    }
}

Next piece of the puzzle is the PhotoListViewModel to map the network data into various UI states. Again pretty straightforward thanks to the beautiful magic of ViewModelScope and StateFlow

class PhotoListViewModel : ViewModel() {
    sealed class State {
        data object Loading : State()
        data class Error(val message: String) : State()
        data class Content(val photos: List<Photo>) : State()
    }

    private val _state = MutableStateFlow<State>(State.Loading)
    val state: StateFlow<State> = _state

    fun fetchPhotos() {
        viewModelScope.launch {
            _state.value = State.Loading
            try {
                val photos = NetworkService
                    .api()
                    .photos()
                    .body() ?: emptyList()
                _state.value = State.Content(photos)
            } catch (e: Exception) {
                val message = e.message ?: "Something went wrong"
                _state.value = State.Error(message)
            }
        }
    }
}

UI

On the UI side we need 2 Activities, a MainActivity to render a grid of images and a DetailActivity to render the detailed image view.

The basic structure of the MainActivity is to simply observes viewmodel changes and update the UI.

class MainActivity : AppCompatActivity() {

    private val viewModel: PhotoListViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()
        setContentView(R.layout.activity_main)
        ViewCompat.setOnApplyWindowInsetsListener(findViewById(R.id.main)) { v, insets ->
            val systemBars = insets.getInsets(WindowInsetsCompat.Type.systemBars())
            v.setPadding(systemBars.left, systemBars.top, systemBars.right, systemBars.bottom)
            insets
        }

        lifecycleScope.launch {
            repeatOnLifecycle(Lifecycle.State.STARTED) {
                viewModel.state.collect { state ->
                    when (state) {
                        is PhotoListViewModel.State.Loading -> showLoading()
                        is PhotoListViewModel.State.Error -> showError(state.message)
                        is PhotoListViewModel.State.Content -> showPhotoList(state.photos)
                    }
                }
            }
        }
        viewModel.fetchPhotos()
    }

    private fun showLoading() {
        Toast
            .makeText(this, "Loading ...", Toast.LENGTH_LONG)
            .show()
    }

    private fun showError(message: String) {
        Toast
            .makeText(this, message, Toast.LENGTH_LONG)
            .show()
    }

    private fun showPhotoList(photos: List<Photo>) {
        // TODO show grid view
    }
}

The interesting bit is with building a photo grid. This requires a PhotoGridAdapter

class PhotoGridAdapter(
    private val context: Context,
    private val photos: List<Photo>,
) :
    BaseAdapter() {

    override fun getCount(): Int {
        return photos.size
    }

    override fun getItem(position: Int): Any {
        return photos[position]
    }

    override fun getItemId(position: Int): Long {
        return position.toLong()
    }

    override fun getView(position: Int, convertView: View?, parent: ViewGroup?): View {
        val contentVw =
            convertView ?: LayoutInflater.from(context).inflate(R.layout.grid_item, parent, false)
        val imageVw: ImageView = contentVw.findViewById(R.id.imageVw)
        val textVw: TextView = contentVw.findViewById(R.id.textVw)

        val photo = photos[position]
        Glide
            .with(context)
            .load(photo.thumbnailUrl)
            .into(imageVw)
        textVw.text = photo.title ?: "-"

        return contentVw
    }
}

And then use this adapter to provide UI data for the GridView

class MainActivity : AppCompatActivity() {
    // ...

    private fun showPhotoList(photos: List<Photo>) {
        val gridVw = findViewById<GridView>(R.id.gridVw)
        val photoGridAdapter = PhotoGridAdapter(this, photos)
        gridVw.adapter = photoGridAdapter
    }
}

Next, when tapped on a photo tile we need to spawn DetailActivity and provide the selected Photo as argument.

class MainActivity : AppCompatActivity() {
    // ...

    private fun showPhotoList(photos: List<Photo>) {
        val gridVw = findViewById<GridView>(R.id.gridVw)

        gridVw.setOnItemClickListener { _, _, position, _ ->
            val photo = photos[position]
            startActivity(Intent(this, DetailsActivity::class.java).apply {
                putExtra("photo", photo)
            })
        }

        // ...
    }
}

And then finally the DetailActivity

class DetailsActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()
        setContentView(R.layout.activity_details)
        ViewCompat.setOnApplyWindowInsetsListener(findViewById(R.id.main)) { v, insets ->
            val systemBars = insets.getInsets(WindowInsetsCompat.Type.systemBars())
            v.setPadding(systemBars.left, systemBars.top, systemBars.right, systemBars.bottom)
            insets
        }

        val photo = intent.getSerializableExtra("photo") as Photo

        val imageVw: ImageView = findViewById(R.id.imageVw)
        val textVw: TextView = findViewById(R.id.textVw)

        Glide
            .with(this)
            .load(photo.url)
            .thumbnail(
                Glide.with(this).load(photo.thumbnailUrl)
            )
            .into(imageVw)
        textVw.text = photo.title ?: "-"
    }
}

Conclusion

The classic Android development feels very much like UIKit for iOS. Most the concepts are 1:1 mapped. Kotlin is always very fun to work with. The one thing I find weird about Android is the lack of in-house libraries for such a basic thing like Networking, which is the core building block for almost all apps these days. And then how various companies have rolled out their own solution for building the data-event pipeline. Like with LiveData, StateFlow and kotlin coroutines leaving the developers to figure out the glue to make it all work.

Before I discovered Glide I tried building my own ImageRepository to handle networking and data caching. And there too I felt the tools offered by Android were very primitive compared to say Apple’s URLSession.

Also before falling back to retrofit, I was trying out ktor for networking. Personally I like ktor as it seems more flexible and more in line with other networking libraries I’m used to.

And finally the XML based layout feels very nice and robust. I like the code-design split view.

The hardest part about Android development is dealing with the unknowns. Like I ran into a runtime crash when running the app on my device with is running on Android 11/SDK 30 while on the emulator I was using Android 13/SDK 34. But I guess that is just a day in life for a developer, you know the classic “Works on my machine” phenomenon.

The code from this experiment is sitting right next to all other experiments. github.com/chunkyguy/PhotoApp/android

References

objc async selectors

2024-12-07T14:21:00+00:00

I very recently learned it the hard way that objc selectors can not be async.

In simple words, this will crash at runtime:

let button = UIButton(frame: buttonFrame)
view.addSubview(button)
button.setTitle("This is a button", for: .normal)
button.addTarget(
  self,
  action: #selector(handleTap), 
  for: .touchUpInside
)
  
@objc func handleTap() async {
  Task {
    debugPrint("handle Tap")
  }
}

No warnings, no errors, no messages on console, nothing. Just crash!

As it turns out all objc selector marked as async will crash. For example:

 perform(#selector(handleTap))

So what is going on here. Let’s first print the selector generated by the compiler for async methods.

debugPrint(NSStringFromSelector(#selector(handleTap)))
// "handleTapWithCompletionHandler:"

As per swift objc interops guidelines, Swift maps all objc methods with suffix "WithCompletionHandler" as `async. So these two are equivalent:

- (void)stopRecordingWithCompletionHandler: void(^ _Nullable)(RPPreviewViewController * _Nullable, NSError * _Nullable)handler;

func stopRecording() async throws -> RPPreviewViewController

So our func handleTap() becomes - (void) handleTapWithCompletionHandler:(CompletionHandler completionHandler) in objc.

The next question naturally is what is the type of CompletionHandler?

I tried to search online if others have also faced this problem. And yes there are quite a number of discussions on this topic. This one even has nice a workaround to the problem:

let completion: @convention(block) () -> Void = {
  debugPrint("completion handler")
}

perform(#selector(handleTap), with: completion)

// prints:
// completion handler
// handle Tap

@convention is a attribute provided by swift for calling conventions in Swift. And @convention(block) is the attribute to represent Objective-C blocks as Swift closures.

Now, with all this acquired knowledge can we fix our crash? We still can’t use the #selector(handleTap) for target action pattern because that pattern is very well documented to support only following method signatures:

func doSomething()
func doSomething(sender: Any)
func doSomething(sender: Any, forEvent event: UIEvent)

Here the sender and event is autofilled by objc runtime while invoking the provided selector. And as you can see there is no place to provide arbitrary arguments. But for this entire mechanism to work we want the sender to be of type @convention(block) () -> Void.

So we can create our own custom UIControl subclass and hijack the target-action mechanism to update the sender. In other words, we need to override the sendAction() method and then call the performSelector.

class MyButton: UIButton {
  override func sendAction(_ action: Selector, to target: Any?, for event: UIEvent?) {
    let sender: @convention(block) () -> Void = {
      debugPrint("completion handler")
    }
    (target as? NSObject)?.perform(action, with: sender)
  }
}

class ViewController: UIViewController {
  
  override func viewDidLoad() {
    super.viewDidLoad()
    let buttonFrame = CGRect(
      x: 20,
      y: (view.bounds.height * 0.5) - 30,
      width: view.bounds.width - 40,
      height: 60
    )
    let button = MyButton(frame: buttonFrame)
    view.addSubview(button)
    button.setTitleColor(.black, for: .normal)
    button.setTitle("This is a button", for: .normal)
    button.addTarget(
      self,
      action: #selector(handleTap),
      for: .touchUpInside
    )
  }
  
  @objc func handleTap() async {
    Task {
      debugPrint("handle Tap")
    }
  }
}

And that is how you can have a button action as async.

References

Getting started with LiteRT (Tensorflow Lite)

2024-11-04T19:00:00+00:00

So Google recently renamed TensorflowLite to LiteRT. And yes that was a genius move indeed. Because now for the first time in my life I actually want to try TFLite … yea, I mean LiteRT.

In the real world you’d ideally think like a regular ML developer and start with discovering a dataset that then you’d use to train a model. And then as a next step you’d invent a problem that could be solved by your trained model.

But for this experiment we are going to keep things simple and build the hello world of Machine Learning universe, the Dogs vs Cat exercise.

Setup

So coincidentally enough I’ve found a trained model from a flutter project that can tell if a given photo is of a dog or a cat.

Nice! So then following the instructions at the official getting started docs we need to add tensorflowlite as a dependency to our project.

use_frameworks!
# pod 'TensorFlowLiteSwift'
pod 'TensorFlowLiteSwift', '~> 0.0.1-nightly', :subspecs => ['CoreML', 'Metal']

In case you’re wondering why are we using the nightly build and not the stable release. It’s because as of today the latest stable release of TensorFlowLiteC won’t work on iOS simulator but according to the last comment on the issue looks like TensorFlowLiteC is now also shipped as xcframework but only in the nightly releases.

And then while we wait for the pod install to finish we can shamelessly rip sample images of various dogs and cats from the Introduction to TensorFlow Lite udacity course as our test set.

And we are all set!

Building the app

For the UI we just need a simple image view, a label and a button. The button obviously would reveal the answer and then randomly load the next image.

Now for the interesting bit. First we need a PetClassifier that takes in an image and returns a text.

class PetClassifier {

  init?(named: String, labels: [String]) {
    // ...
  }

  
  func labelForImage(_ image: UIImage) -> String? {
    // ...
  }
}

And then in the UI layer we can use our PetClassifier to update the label when tapped on the ‘Evaluate’ button.

class ViewController: UIViewController {

  var classifier: PetClassifier?
  @IBOutlet var answerLabel: UILabel!

  override func viewDidLoad() {
    super.viewDidLoad()
    classifier = PetClassifier(named: "dogvscat", labels: ["Cat", "Dog"])
  }

  @IBAction func handleTap() {
    answerLabel.text = classifier?.labelForImage(selectedImage) ?? "Potato"
  }
}

Finally, loading the model is pretty easy. We just need to instantiate Interpreter with the path to our tflite model.

class PetClassifier {
  let interpreter: Interpreter
  let labels: [String]
    
  init?(named: String, labels: [String]) {
    guard let modelPath = Bundle.main.path(forResource: named, ofType: "tflite") else {
      return nil
    }
    
    do {
      var options = Interpreter.Options()
      options.threadCount = Self.threadCount
      interpreter = try Interpreter(modelPath: modelPath, options: options)
      self.labels = labels
    } catch {
      print(error)
      return nil
    }
  }

  // ...
}

Invoking the model

To get the answer from the model is a 4 step process:

Prepare input
Send input data
Read output data
Parse output

/*
 * 1. Prepare input
 */
// user provided image
let image: UIImage 
// image size used for training model
let inputWidth = 224
let inputHeight = 224

// convert image to pixel buffer for further manipulation
let pixelBuffer = ImageUtils.pixelBufferCreate(image: image)
// crop image to size used for training model
let scaledPixelBuffer = ImageUtils.pixelBufferCreateWith(
  pixelBuffer: pixelBuffer,
  resizedTo: CGSize(width: Self.inputWidth, height: Self.inputHeight)
)
// Remove the alpha component from the image buffer to get the RGB data.
let rgbData = ImageUtils.pixelBufferCreateRGBData(
    pixelBuffer: scaledPixelBuffer,
    byteCount: Self.inputWidth * Self.inputHeight * 3
)

/*
 * 2. Send input data 
 */
interpreter.allocateTensors()      
interpreter.copy(rgbData, toInputAt: 0)
interpreter.invoke()

/*
 * 3. Read output data
 */
let outputTensor = try interpreter.output(at: 0)
let results: [Float] = outputTensor.data.withUnsafeBytes {
  Array($0.bindMemory(to: Float.self))
}

/*
 * 4. Parse output
 */      
// Create a zipped array of tuples [(labelIndex: Int, confidence: Float)].
// Sort the zipped results by confidence value
let inferences = zip(labels.indices, results)
  .sorted { $0.1 > $1.1 }
  .map { (label: labels[$0.0], confidence: $0.1) }
      
let bestInference = inferences.first

And there you have it. That is how offload your brain to your computer.

The ImageUtils from this experiment are available here. But there are probably better libraries for these operations. For example, the CoreMLHelpers

References

How to make an accordion with React Native

2024-10-17T19:30:00+00:00

In the journey of making complex animations with React Native, let’s make an accordion!

I don’t know what is the best term for this component. I call it accordion, others call it expandable list. In the first version of material design this component was called as “Expansion Panel”. In the latest version they simply don’t talk about it anymore. In Apple’s Human Interface Guidelines they named it as “Disclosure controls” and in SwiftUI for some reasons they called it DisclosureGroup. But the documentation writer described the component as:

A view that shows or hides another content view, based on the state of a disclosure control.

Yes that is exactly what I mean.

I’m going to use the assets from the frontendmentor challenge because it looks nice.

Setup

To begin, inspired by Android I dumped all the data under one true global variable called R

const R = {
  colors: {
    white: "hsl(0, 0%, 100%)",
    lightPink: "hsl(275, 100%, 97%)",
    grayishPurple: "hsl(292, 16%, 49%)",
    darkPurple: "hsl(292, 42%, 14%)",
  },
  images: {
    background: require("./assets/images/background-pattern.png"),
    iconStar: require("./assets/images/icon-star.png"),
    iconPlus: require("./assets/images/icon-plus.png"),
    iconMinus: require("./assets/images/icon-minus.png"),
  },
  fonts: {
    regular: {
      name: "WorkSans-Regular",
      weight: 400,
    },
    semibold: {
      name: "WorkSans-SemiBold",
      weight: 600,
    },
    bold: {
      name: "WorkSans-Bold",
      weight: 700,
    },
  },
  strings: {
    header: "FAQs",
    content: [
      {
        title: "What is Frontend Mentor, and how will it help me?",
        body: "Frontend Mentor offers realistic coding challenges to help developers improve their frontend coding skills with projects in HTML, CSS, and JavaScript. It's suitable for all levels and ideal for portfolio building.",
      },
      {
        title: "Is Frontend Mentor free?",
        body: "Yes, Frontend Mentor offers both free and premium coding challenges, with the free option providing access to a range of projects suitable for all skill levels.",
      },
      {
        title: "Can I use Frontend Mentor projects in my portfolio?",
        body: "Yes, you can use projects completed on Frontend Mentor in your portfolio. It's an excellent way to showcase your skills to potential employers!",
      },
      {
        title: "How can I get help if I'm stuck on a challenge?",
        body: "The best place to get help is inside Frontend Mentor's Discord community. There's a help channel where you can ask questions and seek support from other community members.",
      },
    ],
  },
};

Layout

The first step of making an accordion is to make a simple list with all elements all expanded out. Which in code looks something like:

export default function App() {
  return (
    <View style={styles.container}>
      <StatusBar style="light" />
      <Image style={styles.backgroundImage} source={R.images.background} />
      <View style={styles.scrollContainer}>
        <ScrollView
          style={styles.scrollView}
          showsVerticalScrollIndicator={false}
        >
          <View style={styles.contentHeader}>
            <Image source={R.images.iconStar} />
            <Text style={styles.contentHeaderTitle}>{R.strings.header}</Text>
          </View>
          {R.strings.content.map(({ title, body }, index) => {
            return (
              <View
                key={title}
                style={[
                  styles.cell,
                  {
                    borderBottomWidth:
                      index === R.strings.content.length - 1 ? 0 : 1,
                  },
                ]}
              >
                <Pressable style={styles.cellHeader}>
                  <Text style={styles.cellTitle}>{title}</Text>
                  <Image style={styles.cellIcon} source={R.images.iconMinus} />
                </Pressable>
                <Text style={styles.cellBody}>{body}</Text>
              </View>
            );
          })}
        </ScrollView>
      </View>
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: R.colors.lightPink,
  },
  backgroundImage: {
    width: "100%",
    resizeMode: "cover",
  },
  scrollContainer: {
    position: "absolute",
    backgroundColor: R.colors.white,
    borderRadius: 16,
    width: Dimensions.get("window").width - 32,
    height: Dimensions.get("window").height - 150,
    top: 150,
    left: 16,
    right: 16,
    padding: 32,
  },
  scrollView: {
    backgroundColor: "transparent",
  },
  contentHeader: {
    flexDirection: "row",
    gap: 32,
    paddingVertical: 8,
  },
  contentHeaderTitle: {
    fontSize: 36,
    fontFamily: R.fonts.bold.name,
    fontWeight: R.fonts.bold.weight,
  },
  cell: {
    paddingVertical: 16,
    borderBottomColor: R.colors.lightPink,
  },
  cellHeader: {
    flexDirection: "row",
    alignItems: "center",
    justifyContent: "space-between",
  },
  cellTitle: {
    fontSize: 20,
    fontFamily: R.fonts.semibold.name,
    fontWeight: R.fonts.semibold.weight,
    width: "90%",
  },
  cellBody: {
    fontSize: 16,
    fontFamily: R.fonts.regular.name,
    lineHeight: 22,
    color: R.colors.grayishPurple,
    paddingTop: 16,
  },
});

The interesting bits are with creating a z-stack layout, with an image view in the background and a scroll view in front.

The tricky thing with ScrollView is that it needs a fixed frame and flexible content size. And what this actually means in ReactNative is that the parent of ScrollView should have a fixed size and then the children can be whatever.

But the container view also needs a position: absolute so we can move it in front of the image. And this bit of css does exactly all of that:

  scrollContainer: {
    position: "absolute",
    width: Dimensions.get("window").width - 32,
    height: Dimensions.get("window").height - 150,
    top: 150,
    left: 16,
    right: 16,
    // ...
  }

If you’re coming from a UIKit background like me and if you squint your eyes a bit this math looks like what you need to do for CGRect.

And with our basic setup is done

State management

Next step in making an accordion is to handle the state. And by state I mean either the selected index or an array of indices.

In code this means to first introduce useState and then using the Pressable to update the state. And finally the UI to consume the state.

export default function App() {
  const [selectedIndex, setSelectedIndex] = useState(0);
  // ...
    <Pressable
      style={styles.cellHeader}
      onPress={() => setSelectedIndex(index)}
    >
      <Text style={styles.cellTitle}>{title}</Text>
      <Image
        style={styles.cellIcon}
        source={
          selectedIndex === index
            ? R.images.iconMinus
            : R.images.iconPlus
        }
      />
    </Pressable>
    {selectedIndex === index && (
      <Text style={styles.cellBody}>{body}</Text>
    )}
  // ...
}

Animate changes

And the final step is to animate the changes. In ReactNative that means using Reanimated to animate the height.

function Cell({ text, isOpen }) {
  const cellContainerStyle = useAnimatedStyle(() => {
    const height = isOpen ? withTiming(100) : withTiming(0);
    return { height };
  });
  return (
    <Animated.View style={cellContainerStyle}>
      <Text style={styles.cellBody}>{text}</Text>
    </Animated.View>
  );
}

<Cell 
  text={body} 
  isOpen={index === selectedIndex} />

Now to calculate the actual expanded height, we need to first calculate the max height of the Cell by wrapping the text within a View with position: absolute and using the onLayout callback to record the evaluated height.

Then, we need to make sure the Animated.View has overflow: hidden to clip the content from being rendered outside of the box.

function Cell({ text, isOpen }) {
  const [maxHeight, setMaxHeight] = useState(0);
  const cellContainerStyle = useAnimatedStyle(() => {
    const height = isOpen ? withTiming(maxHeight) : withTiming(0);
    return { height };
  });
  return (
    <Animated.View style={[
      cellContainerStyle, 
      { overflow: "hidden" }
      ]}>
      <View
        style={
          { position: "absolute" }
        }
        onLayout={(e) => {
          if (maxHeight === 0) {
            setMaxHeight(e.nativeEvent.layout.height);
          }
        }}
      >
        <Text style={styles.cellBody}>{text}</Text>
      </View>
    </Animated.View>
  );
}

And this is how you build an accordion with ReactNative.

The code from this experiment is available on https://github.com/chunkyguy/frontendmentor

Reference

16 years later

2024-09-28T08:36:00+00:00

So today I completed my 16 years of working professionally. This is a quick summary of the past year.

Improved my javascript skills by deep diving into the javascript language design.
Understood more about css. Things like animation, grid layout and just more basic things that I guess almost all web devs are supposed to know.
Made a static portfolio webpage first using old school html-css-js and then again with react.js.
Made a few prototypes using react-native and expo.
Tried out new cross-platform mobile frameworks like .NET MAUI and Ionic.
Made a small api only web service with MEN stack: mongodb, express.js, node.js.
Rewrote my web service using AWS lambda, http-gateway, cognito, s3 and dynamodb.
Expanded on my knowledge on SwiftUI.
Started playing around with Swift structured concurrency. I mean like I had to with Xcode 16/swift 6 migration at our face.

MoveMe - SwiftUI Edition

2024-09-12T18:38:00+00:00

Taking about gestures and animation with SwiftUI is actually not as intuitive as it sounds. But how hard could it be?

Setup

So like always we need 3 squares nicely lined up in the center of the screen. I’m going to use ZStack because I want the squares to layout independently of each other. The only thing the parent container view needs to provide is the initial position.

struct SquareView: View {
  var position: CGPoint
  
  var body: some View {
    RoundedRectangle(cornerRadius: 25.0, style: .continuous)
      .frame(width: 100, height: 100)
      .position(position)
      .foregroundStyle(.blue)
  }
}

struct ContentView: View {
  var body: some View {
    ZStack {
      ForEach(0..<3) { idx in
        GeometryReader { geometry in
          SquareView(position: CGPoint(
            x: geometry.size.width * 0.5,
            y: geometry.size.height * (CGFloat(idx +  1) / 4.0)
          ))
        }
      }
    }
  }
}

Gestures

Next we need a tap gesture and when detected the selected square should become red. The obvious solution would be to use a TapGesture but the TapGesture only activates at touch end and what we need is a way to detect touch began. The actual solution I found is to use the DragGesture with minimumDistance set to 0.

struct SquareView: View {
  var position: CGPoint
  @State var isSelected = false
  
  var body: some View {
    RoundedRectangle(cornerRadius: 25.0, style: .continuous)
      .frame(width: 100, height: 100)
      .position(position)
      .foregroundStyle(isSelected ? .red : .blue)
      .gesture(
        DragGesture(minimumDistance: 0)
          .onChanged({ _ in isSelected = true })
          .onEnded({ _ in isSelected = false })
      )
  }
}

Next we need to square to scale up when selected. Again the obvious solution is to use the scaleEffect.

struct SquareView: View {
  var position: CGPoint
  @State var isSelected = false
  
  var body: some View {
    RoundedRectangle(cornerRadius: 25.0, style: .continuous)
      .frame(width: 100, height: 100)
      .position(position)
      .foregroundStyle(isSelected ? .red : .blue)
      .scaleEffect(isSelected ? 1.2 : 1)
      .gesture(
        DragGesture(minimumDistance: 0)
          .onChanged({ _ in isSelected = true })
          .onEnded({ _ in isSelected = false })
      )
  }
}

But this brings another problem. Notice how the squares are not centered when scaling up.

This is because the view tree in SwiftUI is inverted because each modifier creates a new View and wraps the invoking object as its child. So these two are equivalent:

Box()
 .firstModifier()
 .secondModifier()

SecondModifierView(
  FirstModifierView(
    Box()
  )
)

So back in our solution above the scaleEffect is applied first and then the position. This make the center to become off centered. The solution is to apply the position modifier after the scaleEffect.

struct SquareView: View {
  var position: CGPoint
  @State var isSelected = false
  
  var body: some View {
    RoundedRectangle(cornerRadius: 25.0, style: .continuous)
      .frame(width: 100, height: 100)
      .scaleEffect(isSelected ? 1.2 : 1)
      .position(position)
      .foregroundStyle(isSelected ? .red : .blue)
      .gesture(
        DragGesture(minimumDistance: 0)
          .onChanged({ _ in isSelected = true })
          .onEnded({ _ in isSelected = false })
      )
  }
}

And finally we want the square to move around with the finger. This part is simple since we already have drag gesture, we just need to update the position of the square.

struct SquareView: View {
  @State var position: CGPoint
  @State var isSelected = false
  
  var body: some View {
    RoundedRectangle(cornerRadius: 25.0, style: .continuous)
      .frame(width: 100, height: 100)
      .scaleEffect(isSelected ? 1.2 : 1)
      .position(position)
      .foregroundStyle(isSelected ? .red : .blue)
      .gesture(
        DragGesture(minimumDistance: 0)
          .onChanged({ value in
            isSelected = true
            position = value.location
          })
          .onEnded({ _ in isSelected = false })
      )
  }
}

Animations

For the next part we would like the transitions to animate. For this we can either use the withAnimation block

struct SquareView: View {
  @State var position: CGPoint
  @State var isSelected = false
  
  var body: some View {
    RoundedRectangle(cornerRadius: 25.0, style: .continuous)
      .frame(width: 100, height: 100)
      .scaleEffect(isSelected ? 1.2 : 1)
      .position(position)
      .foregroundStyle(isSelected ? .red : .blue)
      .gesture(
        DragGesture(minimumDistance: 0)
          .onChanged({ value in
            withAnimation {
              isSelected = true
            }
            position = value.location
          })
          .onEnded({ _ in
            withAnimation {
              isSelected = false
            }
          })
      )
  }
}

But look our favorite bug is back again. Notice how the squares are off centered when selected.

But now we know why this bug exists. We need to guarantee that the position is applied after the scaling. But since we are using the withAnimation block it sets some flag for the next draw pass to be done with animation. And that means all the changes are animated. But what we want is to have only have the scaling change as animated and everything else non animated.

To achieve this we can use the animation modifier. It does the same thing as withAnimation block but we can control where in the View hierarchy we want the animation to happen.

struct SquareView: View {
  @State var position: CGPoint
  @State var isSelected = false
  
  var body: some View {
    RoundedRectangle(cornerRadius: 25.0, style: .continuous)
      .scaleEffect(isSelected ? 1.2 : 1, anchor: .center)
      .animation(.easeOut, value: isSelected)
      .frame(width: 100, height: 100)
      .position(position)
      .foregroundStyle(isSelected ? .red : .blue)
      .gesture(
        DragGesture(minimumDistance: 0)
          .onChanged({ value in
            isSelected = true
            position = value.location
          })
          .onEnded({ _ in
            isSelected = false
          })
      )
  }
}

The solution is available on https://github.com/chunkyguy/MoveMe

References

Coordinating multiple gesture recognizers

2024-09-11T19:53:00+00:00

So how does one actually work with multiple gesture recognizers on same view?

Let’s recreate the MoveMe sample with UIGestureRecognizer. The idea is to have both UILongPressGestureRecognizer and UIPanGestureRecognizer play nicely with each other. With UILongPressGestureRecognizer responsible for detecting selection and UIPanGestureRecognizer responsible for dragging the selected squares.

Setup

We have a SquareView that can react to changes such as selection and change in position. The main updates happen in layoutSubviews. setNeedsLayout reschedules a update at next draw cycle and layoutIfNeeded requests an update immediately.

struct SquareViewProps {
  var color = UIColor.blue
  var scale: CGFloat = 1.0
  var position: CGPoint
}

class SquareView: UIView {
  
  private var props: SquareViewProps {
    didSet { setNeedsLayout() }
  }
  
  override init(frame: CGRect) {
    props = SquareViewProps(position: CGPoint(x: frame.midX, y: frame.midY))
    super.init(frame: frame)
  }
  
  override func layoutSubviews() {
    super.layoutSubviews()
    backgroundColor = props.color
    center = props.position
    transform = CGAffineTransform(scaleX: props.scale, y: props.scale)
  }
  
  private func resetProps(_ props: SquareViewProps) {
    self.props = props
    UIView.animate(withDuration: 0.3, delay: 0, options: [.beginFromCurrentState]) {
      self.layoutIfNeeded()
    }
  }
}

And then we can host the SquareView in some parent UIView or UIViewController

class ViewController: UIViewController {
  
  private var squareVws: [SquareView] = []
  
  override func viewDidLoad() {
    super.viewDidLoad()
    
    squareVws = (0..<3).map { idx in
      SquareView(
        frame: CGRect(
          x: view.bounds.midX - 50,
          y: CGFloat.lerp(
            start: (view.bounds.minY + 100),
            end: (view.bounds.maxY - 200),
            factor: CGFloat(idx) / 2
          ),
          width: 100, height: 100
        )
      )
    }
    
    squareVws.forEach { view.addSubview($0) }
  }  
}

Problem

Next we can add a UIPanGestureRecognizer on the ViewController and forward the gesture events to selected views.

enum GestureEvent {
  case began
  case changed(CGPoint)
  case ended
}

class SquareView: UIView {
    func handleGestureEvent(_ event: GestureEvent) {
    switch event {
    case .began:
      resetProps(SquareViewProps(
        color: .red,
        scale: 1.2,
        position: props.position
      ))
      
    case .changed(let translation):
      props.position = CGPoint.add(translation, props.position)
      
    case .ended:
      resetProps(SquareViewProps(position: props.position))
    }
  }

  // ...
}

class ViewController: UIViewController {
  
  private var squareVws: [SquareView] = []
  private var selectedVws: [SquareView] = []
  
  override func viewDidLoad() {
    // ...
    
    let dragGesture = UIPanGestureRecognizer(
      target: self,
      action: #selector(handleDrag)
    )
    
    view.addGestureRecognizer(dragGesture)
  }
  
  @objc func handleDrag(_ sender: UIPanGestureRecognizer) {
    switch sender.state {
    case .began:
      let pt = sender.location(in: view)
      selectedVws = squareVws.filter { $0.frame.contains(pt) }
      handleGestureEvent(.began)
      
    case .changed:
      let translation = sender.translation(in: view)
      handleGestureEvent(.changed(translation))
      sender.setTranslation(.zero, in: view)

    case .ended:
      handleGestureEvent(.ended)
      selectedVws = []
      
    default:
      break
    }
  }
  
  func handleGestureEvent(_ event: GestureEvent) {
    selectedVws.forEach { $0.handleGestureEvent(event) }
  }
}

So far so good but with this implementation we receive gesture events after the drag has started but we want to receive the .began as soon as the user touches the square. We can use the UITapGestureRecognizer but it only activates at touch up and not at touch down. So either we need to rollout our own gesture or ‘hack’ UILongPressGestureRecognizer

class ViewController: UIViewController {
  
  private var squareVws: [SquareView] = []
  private var selectedVws: [SquareView] = []
  
  override func viewDidLoad() {
    super.viewDidLoad()

    // ...
    
    let tapGesture = UILongPressGestureRecognizer(
      target: self,
      action: #selector(handleTap)
    )
    tapGesture.minimumPressDuration = 0.1
    
    let dragGesture = UIPanGestureRecognizer(
      target: self,
      action: #selector(handleDrag)
    )
    
    view.addGestureRecognizer(tapGesture)
    view.addGestureRecognizer(dragGesture)
  }
  
  @objc func handleTap(_ sender: UILongPressGestureRecognizer) {
      switch sender.state {
      case .began:
        let pt = sender.location(in: view)
        selectedVws = squareVws.filter { $0.frame.contains(pt) }
        handleGestureEvent(.began)

      case .ended:
        handleGestureEvent(.ended)
        selectedVws = []
        
      default:
        break
      }
  }
  
  @objc func handleDrag(_ sender: UIPanGestureRecognizer) {
    switch sender.state {
    case .changed:
      let translation = sender.translation(in: view)
      handleGestureEvent(.changed(translation))
      sender.setTranslation(.zero, in: view)

    default:
      break
    }
  }
  
  func handleGestureEvent(_ event: GestureEvent) {
    selectedVws.forEach { $0.handleGestureEvent(event) }
  }
}

But this poses another problem. On a UIView by default only one gesture recognizer is active at a time. So once the UILongPressGestureRecognizer is activated UIPanGestureRecognizer is ignored.

Solution

Gesture recognizers have a defined order of precedence. So if multiple gesture recognizers are attached to a view, the winner is decided by the default rules. But we can override the rules by implementing the UIGestureRecognizerDelegate. For our case since each gesture recognizer is listening to different states we can have both the gestures active at the same time

class ViewController: UIViewController {
  
  // ...    
  
  
  override func viewDidLoad() {
    super.viewDidLoad()

    let tapGesture = UILongPressGestureRecognizer()
    let dragGesture = UIPanGestureRecognizer()

    // ...    
    
    tapGesture.delegate = self
    dragGesture.delegate = self
  }
}

extension ViewController: UIGestureRecognizerDelegate {
  public func gestureRecognizer(
    _ gestureRecognizer: UIGestureRecognizer,
    shouldRecognizeSimultaneouslyWith otherGestureRecognizer: UIGestureRecognizer
  ) -> Bool {
    return gestureRecognizer is UILongPressGestureRecognizer
    && otherGestureRecognizer is UIPanGestureRecognizer
  }
}

The solution is available on https://github.com/chunkyguy/MoveMe

References

Hello ionic

2024-09-06T16:13:00+00:00

In the next series of how javascript is slowly taking over the tech let’s try Ionic.

On their home page Ionic Framework calls themselves as The Cross-Platform App Development Leader. Lets find out the truth in that.

I remember using Cordova back in 2010 and honestly the mobile landscape was very different back then. From what I’ve read so far, ionic was built on top of Cordova and angular.js but there is also an out-of-box template for react, which is what I’m probably going to use today. So let’s go!

Setup

First start the ionic cli.

npm install -g @ionic/cli native-run cordova-res

Running ionic start --list reveals the following list of templates:

Starters for @ionic/react (--type=react)

name         | description
--------------------------------------------------------------------------------------
blank        | A blank starter project
list         | A starting project with a list
my-first-app | A template for the "Build Your First App" tutorial
sidemenu     | A starting project with a side menu with navigation in the content area
tabs         | A starting project with a simple tabbed interface

So I’m obviously going to use the blank template:

ionic start photoapp blank --type=react --capacitor

And then few more installs:

npm install @capacitor/camera @capacitor/preferences @capacitor/filesystem

And then a few more:

npm install @ionic/pwa-elements

And then finally a few minutes later running ionic serve starts the good old familiar vite react app on the browser. Good, but I thought we are building a mobile app. So let’s fix that.

First we need to build the project.

ionic build
ionic cap add ios
ionic cap add android

Later in development if we wish to copy the web project into iOS, we need to run the ionic cap copy command. And need to sync after adding plugins we need to run the ionic cap sync command.

And then finally to run the project for iOS we need to run the ionic cap open ios command. This would open the Xcode project from where we can actually run the app in our favorite simulator.

Drawing UI

Very nice. Now let’s switch gears to rendering. Ionic provides a nice list of UI components to avoid lazy devs like me from writing the css. To make a 2 column grid of photos we can make use of IonGrid. IonGrid is made up of many IonRow, and IonRow is made up of many IonCol items.

So make a 2 column grid we can design our grid as:

type PhotoTileProps = {
  photo: Photo | null;
};

function PhotoTile(props: PhotoTileProps | null) {
  return (
    props?.photo && (
      <IonCol>
        <IonImg src={props.photo.thumbnailUrl} />
      </IonCol>
    )
  );
}

type PhotoRowProps = {
  left: Photo | null;
  right: Photo | null;
};

function PhotoRow(props: PhotoRowProps) {
  return (
    <IonRow>
      <PhotoTile photo={props.left} />
      <PhotoTile photo={props.right} />
    </IonRow>
  );
}

export default function PhotoList() {
  const [photoList, setPhotoList] = useState<Array<PhotoRowProps>>([]);

  async function fetchData() {
    const response = await fetch("https://jsonplaceholder.typicode.com/photos");
    const content = await response.json();
    const list = content as Photo[];
    let props: Array<PhotoRowProps> = [];
    for (let index = 0; index < list.length; index += 2) {
      const element = list[index];
      let row: PhotoRowProps = {
        left: list[index],
        right: list[index + 1],
      };
      props.push(row);
    }
    setPhotoList(props);
  }

  return (
    <IonGrid>
      {photoList.map((item, index) => (
        <PhotoRow key={index} left={item.left} right={item.right} />
      ))}
    </IonGrid>
  );
}

This should work for even numbered elements, but for odd numbered elements our grid would look weird, since the last element would occupy the entire width. I can reproduce this bug by only rendering 3 elements

An easy fix is to always draw the IonCol

function PhotoTile(props: PhotoTileProps) {
  return (
    <IonCol>
      <IonImg src={props.photo?.thumbnailUrl} />
    </IonCol>
  );
}

For details page we can build a UI similarly.:

type PhotoDetailProps = {
  id: string;
};

export default function PhotoDetail(props: PhotoDetailProps) {
  const [photo, setPhoto] = useState<Photo | undefined>(undefined);

  async function fetchData() {
    const response = await fetch(
      `https://jsonplaceholder.typicode.com/photos/${props.id}`
    );
    const content = await response.json();
    const photo = content as Photo;
    setPhoto(photo);
  }

  useEffect(() => {
    fetchData();
  }, []);

  return !photo ? (
    <IonSpinner />
  ) : (
    <PhotoTile
      photo={photo}
    />
  );
}

The boilerplate app already provides a router which looks very familiar because, no surprise, it’s a wrapper around react-router.

const App: React.FC = () => (
  <IonApp>
    <IonReactRouter>
      <IonRouterOutlet>
        <Route exact path="/home">
          <Home />
        </Route>
        <Route exact path="/">
          <Redirect to="/home" />
        </Route>
      </IonRouterOutlet>
    </IonReactRouter>
  </IonApp>
);

And to extend the router to show a details page with param we can add the usual react-router styled Route. So for our photo app our routes would look like:

const App: React.FC = () => (
  <IonApp>
    <IonReactRouter>
      <IonRouterOutlet>
        <Route path="/home" component={Home} />
        <Route path="/details/:id" component={Details} />
        <Redirect exact from="/" to="/home" />
      </IonRouterOutlet>
    </IonReactRouter>
  </IonApp>
);

To parse the path argument we can use the RouteComponentProps.

interface UserDetailPageProps
  extends RouteComponentProps<{
    id: string;
  }> {}

export default function Details(props: UserDetailPageProps) {
  return (
    <IonPage>
      <IonHeader>
        <IonToolbar>
          <IonTitle>Photo {props.match.params.id}</IonTitle>
        </IonToolbar>
      </IonHeader>
      <IonContent fullscreen>
        <PhotoDetail id={props.match.params.id} />
      </IonContent>
    </IonPage>
  );
}

Now to navigate between Home and Details we can use the routerLink that is provided with a lot of Ionic components, like the IonCard

type PhotoTileProps = {
  routerLink: string;
  photoUrl: string | undefined;
  photoTitle: string | undefined;
};

function createPhotoTileProps(photo: Photo): PhotoTileProps {
   return {
     routerLink: `/details/${photo.id}`,
     photoUrl: photo.thumbnailUrl,
     photoTitle: undefined,
   };
}

export default function PhotoTile(props: PhotoTileProps) {
  return (
    <IonCard routerLink={props.routerLink}>
      <IonCol>
        <IonImg src={props.photoUrl} />
        {props.photoTitle && <IonLabel>{props.photoTitle}</IonLabel>}
      </IonCol>
    </IonCard>
  );
}

And there you have it. The photo app with Ionic framework!

As a final step, let’s build and run the app using Xcode one more time. So running ionic build && ionic cap copy one more time. And then running the app from Xcode. Viola!

The details screen seems to be missing the back button. The fix is actually very simple, just add the IonBackButton

<IonToolbar>
  <IonButtons slot="start">
    <IonBackButton defaultHref="#"></IonBackButton>
  </IonButtons>
  <IonTitle>Photo {props.match.params.id}</IonTitle>
</IonToolbar>

Conclusion

I think Ionic is pretty solid framework for web developers. You can almost always tell that this is web UI, and I don’t think ionic is trying to hide that fact. But like with every thing software there are always trade-offs and the fact that Ionic is not limiting the web devs from using 100% of their expertise can be a huge win.

Like always the code from this experiment is available at https://github.com/chunkyguy/PhotoApp

References

React navigation basics

2024-09-01T13:37:00+00:00

I just realized that I’ve never made the photos app with react.js. So let’s do that today.

Setup

I’m going to use vite to build the app with javascript.

npm create vite@latest .
npm install
npm run dev

And we have our app up and running.

Fetch data

To fetch and display data in react is a three step process. First we need useState to hold the data:

const [photoList, setPhotoList] = useState([]);

Then we need a useEffect to fetch the data. One way is to use the promises:

  useEffect(() => {
    fetch("https://jsonplaceholder.typicode.com/photos")
      .then((response) => response.json())
      .then((content) => setPhotoList(content));
  }, []);

Another way is to create an async function and call it from useEffect:

  async function fetchData() {
    const response = await fetch("https://jsonplaceholder.typicode.com/photos");
    const content = await response.json();
    setPhotoList(content);
  }

  useEffect(() => {
    fetchData();
  }, []);

And then draw the UI.

Drawing content

To render the data we can simply use the html unordered list

return (
  <>
    {photoList.length === 0 ? (
      <p>Loading ...</p>
    ) : (
      <ul>
        {photoList.map(({ id, title, thumbnailUrl }) => {
          return (
            <li key={id}>
                <img src={thumbnailUrl} alt={title} />
            </li>
          );
        })}
      </ul>
    )}
  </>
);

In the true spirit of react we can probably move the li out as a reusable component and call it PhotoTile:

export function PhotoTile({ title, thumbnailUrl }) {
  return (
    <li className="photoTile">
      <img src={thumbnailUrl} alt={title} />
    </li>
  );
}

and reduce our App.jsx to

<ul className="photoList">
  {photoList.map(({ id, title, thumbnailUrl }) => (
    <PhotoTile key={id} title={title} thumbnailUrl={thumbnailUrl} />
  ))}
</ul>

Next, to make the list 2 columns we can use grid, flexbox or one of the infinite other methods out there, but my favorite is to simply use the column-count

<ul className="photoList"> 
  ...
</ul>


.photoList {
  column-count: 2;
}

And now the real deal. The react-router-dom. This changes everything. First we need to install the dependency obviously.

npm install react-router-dom

Then we need to update the main.jsx to use the router

const router = createBrowserRouter([
  {
    path: "/",
    element: <Home />,
  },
]);

createRoot(document.getElementById("root")).render(
  <StrictMode>
    <RouterProvider router={router} />
  </StrictMode>
);

To navigate to the details, we need to register the route with params:

const router = createBrowserRouter([
  {
    path: "/",
    element: <Home />,
  },
  {
    path: "/details/:id",
    element: <Details />,
  },
]);

Then in the Details we can get the param value with useParams() hook

export function Details() {
  const { id } = useParams();
  const [photo, setPhoto] = useState(null);

  async function fetchData(id) {
    const response = await fetch(
      `https://jsonplaceholder.typicode.com/photos/${id}`
    );
    const content = await response.json();
    setPhoto(content);
  }

  useEffect(() => {
    fetchData(id);
  }, [id]);

  return (
    <>
      {!photo ? (
        <Loading />
      ) : (
        <ul>
          <div className="photoDetails">
            <PhotoTile title={photo.title} url={photo.url} />
            <p>{photo.title}</p>
          </div>
        </ul>
      )}
    </>
  );
}

And then to navigate between screens we need to make use of the Link component:

export function PhotoTile({ title, url, path }) {
  return (
    <li className="photoTile">
      <Link to={path}>
        <img src={url} alt={title} />
      </Link>
    </li>
  );
}

And then construct the details path from Home screen like:

<PhotoTile
  key={id}
  title={title}
  url={thumbnailUrl}
  path={`/details/${id}`}
/>

And back to home from the Details screen:

<PhotoTile title={photo.title} url={photo.url} path={"/"} />

Conclusion

And there we have the basics of a React app with navigation. The react-router is always evolving, there were some new changes in the v6 which I tried to use. But looks good and works like charm.

The link from this experiment is available at https://github.com/chunkyguy/PhotoApp/tree/master/react.

References

Jetpack compose navigation

2024-08-16T23:20:00+00:00

It’s Friday night! And you know what that means right? It’s time to dig deeper into Jetpack Compose. And today I would like to try out the navigation between screens with Jetpack Compose.

How hard can it?

Setup

Installing dependencies is never fun in an Android project. First you need to find the libs.version.toml file and add these lines:

[version]
androidx-navigation = "2.7.7"
kotlinxSerializationJson = "1.6.3"

[libraries]
androidx-navigation-compose = { module = "androidx.navigation:navigation-compose", version.ref = "androidx-navigation" }
kotlinx-serialization-json = { module = "org.jetbrains.kotlinx:kotlinx-serialization-json", version.ref = "kotlinxSerializationJson" }

[plugins]
kotlin-serialization = { id = "org.jetbrains.kotlin.plugin.serialization", version.ref = "kotlin" }

Run gradle sync. Then open the build.gradle.kts within the app/ and apply the plugin and add the dependency

plugins {
  // ...
  alias(libs.plugins.kotlin.serialization)
}

dependencies {
  // ...
  implementation(libs.androidx.navigation.compose)
  implementation(libs.kotlinx.serialization.json)
}

And then do another round of gradle sync.

If all went fine so far, then you’re all set for writing the code. If not, delete your project and start from scratch.

Implementation

Navigation in Android works with the help of these 2 components:

NavController: Top level object to navigate between screens
NavHost: Container within which all routing happens.

So to make this work, we first need to inject the NavController at the root level of the app. Like say the MainActivity or the root composable like PhotoApp in our case.

fun PhotoApp(
  navController: NavHostController = rememberNavController()
) { .. }

And then simply setup all the available routes

NavHost(
  navController = navController,
  startDestination = "home"
) {
  composable("home") {
    HomeScreen(
      onSelectPhoto = { navController.navigate("photos/${it.id}") },
      modifier = Modifier.fillMaxSize()
    )
  }

  composable("photos/{id}") {
    DetailScreen(
      id = it.arguments?.getString("id") ?: "0",
      modifier = Modifier.fillMaxSize()
    )
  }
}

And that is all there to it.

Thoughts

Now of course, one can go crazy with typed routing with sealed classes and what not. But this is the gist of it.

Just like React Native, the path arguments are by default string types and if there’s more data to be passed between the screens we need to come up with our strategy.

The good thing is the the back button comes for free with Android OS. But for custom back button we again need to devise our own tooling.

So there is how you navigate between screens with Android. The code for this experiment is up there sitting in the cloud nicely with the rest of the PhotoApp.

https://github.com/chunkyguy/PhotoApp/tree/master/kotlin

References

Let's reanimate

2024-08-15T15:16:00+00:00

Drawing text and images is one thing but the real test of a UI framework is in how good is it with animating content.

And my test for animation is the classic MoveMe based on the Apple’s sample code.

The idea is to draw three boxes on the screen. When selected the box changes color and scales up and then can be moved around with the drag gesture and eventually restores back to original color and size when released.

Let’s build that sample using React Native’s Reanimated library.

Setup

I’m following the official docs but not using their template. So I’ve a basic project created with the blank template and installed the dependencies

npx create-expo-app moveme --template blank
npx expo install react-native-reanimated
npx expo install react-native-gesture-handler

Next, I added the plugin by editing babel.config.js to

module.exports = function (api) {
  api.cache(true);
  return {
    presets: ["babel-preset-expo"],
    plugins: ["react-native-reanimated/plugin"],
  };
};

And then draw 3 squares on screen:

import { StatusBar } from "expo-status-bar";
import { StyleSheet, View } from "react-native";
import Animated from "react-native-reanimated";

function Square() {
  return <Animated.View style={styles.square}></Animated.View>;
}

export default function App() {
  return (
    <View style={styles.container}>
      <StatusBar style="auto" />
      <Square />
      <Square />
      <Square />
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: "#fff",
    alignItems: "center",
    justifyContent: "space-evenly",
  },
  square: {
    width: 100,
    height: 100,
    backgroundColor: "blue",
  },
});

Add gesture handler

To add support for gesture handlers we first need to wrap the content within the GestureHandlerRootView

<GestureHandlerRootView style={styles.container}>
  <Square />
  <Square />
  <Square />
</GestureHandlerRootView>

And then wrap each Square within GestureDetector

function Square() {
  const gesture = Gesture.Pan();

  return (
    <GestureDetector gesture={gesture}>
      <Animated.View style={styles.square} />
    </GestureDetector>
  );
}

Handle gesture events

To handle gesture we first need to create a SharedValue which is like State but for animation states. For example, to change the background color when selected we need to listen to onBegin and onFinalize events and update the style:

function Square() {
  const isPressed = useSharedValue(false);
  const animStyle = useAnimatedStyle(() => {
    return {
      backgroundColor: isPressed.value ? "red" : "blue",
    };
  });

  const gesture = Gesture.Pan()
    .onBegin(() => {
      isPressed.value = true;
    })
    .onFinalize(() => {
      isPressed.value = false;
    });

  return (
    <GestureDetector gesture={gesture}>
      <Animated.View style={[styles.square, animStyle]} />
    </GestureDetector>
  );
}

Supporting drag is similar. We need to store start and current positions and then update the current position on onChange event. The onChange provides the delta change that we then need to add to the start position to calculate the final current position. And then, finally at the onFinalize event we can sync the start and current positions.

function Square() {
  const isPressed = useSharedValue(false);
  const startPos = useSharedValue({ x: 0, y: 0 });
  const pos = useSharedValue({ x: 0, y: 0 });
  const animStyle = useAnimatedStyle(() => {
    return {
      backgroundColor: isPressed.value ? "red" : "blue",
      transform: [
        { translateX: pos.value.x },
        { translateY: pos.value.y },
        { scale: withSpring(isPressed.value ? 1.2 : 1) },
      ],
    };
  });

  const gesture = Gesture.Pan()
    .onBegin(() => {
      isPressed.value = true;
    })
    .onChange((e) => {
      pos.value = {
        x: startPos.value.x + e.translationX,
        y: startPos.value.y + e.translationY,
      };
    })
    .onFinalize(() => {
      isPressed.value = false;
      startPos.value = {
        x: pos.value.x,
        y: pos.value.y,
      };
    });

  return (
    <GestureDetector gesture={gesture}>
      <Animated.View style={[styles.square, animStyle]} />
    </GestureDetector>
  );
}

And there you have it

The source code is available on https://github.com/chunkyguy/MoveMe/tree/main/reactnative

References

Dear expo, who are you?

2024-07-23T20:58:00+00:00

Let’s try expo.

The motivation behind this experiment is neither my eternal curiosity for exploring new technologies nor is this post sponsored by expo in any way. Rather it is the fact that the nice folks at React Native have killed our beloved React Native CLI. You don’t even see the instructions to create React Native apps using the CLI anymore, as if it never existed! So, without losing another tear on the past let’s take a sneak peek into the future.

Set up

The official command on React Native official docs to create a new project npx create-expo-app@latest generates a ton of boilerplate. It’s better to use the command they hand out at the official expo docs.

npx create-expo-app PhotoApp --template blank.

Which brings to first source of ambiguity - which docs are more recent? But continuing with our experiment step 1 is probably all you need to get started. Next, running npm run ios generates a nice UI

Looking at the project directory in details shows that there are way fewer files and folders:

.
├── App.js
├── app.json
├── assets
├── babel.config.js
├── node_modules
├── package-lock.json
└── package.json

Now compare this with the older files and folders:

.
├── App.jsx
├── Gemfile
├── Gemfile.lock
├── README.md
├── __tests__
├── android
├── app.json
├── babel.config.js
├── index.js
├── ios
├── jest.config.js
├── metro.config.js
├── node_modules
├── package-lock.json
├── package.json
├── tsconfig.json
└── vendor

Expo router

Since I don’t think a lot has changed in the UI and state management. I’m going to jump directly at the real deal - the expo router. And with the real React Native developer spirit, just copy this one liner and install these bunch of dependencies and see the time fly

npx expo install expo-router react-native-safe-area-context react-native-screens expo-linking expo-constants expo-status-bar

Next, update the entry point to expo-router

-  "main": "expo/AppEntry.js"
+  "main": "expo-router/entry"

And add scheme to app.json

+  "scheme": "your-app-scheme"

And then again ignoring all the rest of the steps, since we don’t care about the web. Voila we have switched to expo-router!

At first glance it seems the navigation is heavily inspired by next.js. Every screen is path based auto linked. So index.js links to the / path, aka the Home. And for details screen we can use the parameterized path, like /photos/[id] that would then magically navigate to the right Details screen. And finally to describe the container we use the special component called _layout.js

For our app then the folder structure looks like:

./app
├── _layout.js
├── index.js
└── photos
    └── [id].js
./components
├── photo_list.js
└── photo_tile.js

Since we want the navigation to be simple stack based, our _layout.js looks like:

export default function RootLayout() {
  return (
    <Stack>
      <Stack.Screen name="index" />
      <Stack.Screen name="photos/[id]" />
    </Stack>
  );
}

Then within the /index.js file is where we render a Home screen that renders a FlatList with each cell rendering a cell with an image and a title. And whenever the cell is tapped we invoke the router to take us to the photo/[id] path

<PhotoList
  photoList={photoList}
  onSelectPhoto={({ title, url }) => {
    router.push({
      pathname: "/photos/[id]",
      params: { title, url },
    });
   }
  }
/>

And later on in the /photos/[id].js we can read the passed params and draw the UI

export default function DetailsScreen() {
  const { title, url } = useLocalSearchParams();
  return (
    <SafeAreaView style={styles.container}>
      <Image style={styles.image} source={
        {uri: url }
      } />
      <Text style={styles.title}>{title}</Text>
    </SafeAreaView>
  );
}

Conclusion

And that’s all there is the learn. Expo looks neat. I like the path based navigation. Feels way better than other frameworks. And the best part is, like Steve Jobs would say, that it just works.

I also like that they cleaned up the project a lot. But that said, I don’t know if I’m going to miss having access to the dedicated ios and android folders. What if for some reason I have to add some data to Info.plist file or toggle some specific build setting. I hope there’s a easy way to make that work.

TLDR; I like expo and for my future React Native project I’m definitely going to use expo!

The code from this experiment is with the rest of the project at https://github.com/chunkyguy/PhotoApp

UIScrollView and Autolayout

2024-04-28T10:24:00+00:00

This a quick reference on how to make UIScrollView work with autolayout

Solution 1: Where the content has a fixed size

class ContentView: UIView {}

class ViewController: UIViewController {
  // ...
  override func viewDidLoad() {
    super.viewDidLoad()
    let contentVw = ContentView(frame: CGRect(
      x: 0, y: 0,
      width: 1024, 
      height: 1024
    ))
    let scrollVw = UIScrollView()
    
    VFL(view)
      .add(subview: scrollVw, name: "scrollVw")
      .applyConstraints(formats: [
        "H:|[scrollVw]|", "V:|[scrollVw]|"
      ])
    
    VFL(scrollVw)
      .addSubview(contentVw)
    
    scrollVw.backgroundColor = .red
    scrollVw.contentSize = contentVw.frame.size
  }
}

Solution 2: Where the content has an intrinsicContentSize

class ContentView: UIView {
  override var intrinsicContentSize: CGSize {
    CGSize(width: 1024, height: 1024)
  }
}

class ViewController: UIViewController {
  // ...
  override func viewDidLoad() {
    super.viewDidLoad()
    let contentVw = ContentView()
    let scrollVw = UIScrollView()

    VFL(view)
      .add(subview: scrollVw, name: "scrollVw")
      .applyConstraints(formats: [
        "H:|[scrollVw]|", "V:|[scrollVw]|"
      ])
    
    VFL(scrollVw)
      .add(subview: contentVw, name: "contentVw")
      .applyConstraints(formats: [
        "H:|[contentVw]|", "V:|[contentVw]|"
      ])
  }
}

Solution 3: Where the content has a flexible size

class ContentView: UIView {  
  weak var scrollVw: UIScrollView?
  
  override func layoutSubviews() {
    super.layoutSubviews()    
    scrollVw?.contentSize = bounds.size
  }
}

class ViewController: UIViewController {
  // ...
  override func viewDidLoad() {
    super.viewDidLoad()
    let contentVw = ContentView()
    let scrollVw = UIScrollView()

    VFL(view)
      .add(subview: scrollVw, name: "scrollVw")
      .applyConstraints(formats: [
        "H:|[scrollVw]|", "V:|[scrollVw]|"
      ])
    
    VFL(scrollVw)
      .add(subview: contentVw, name: "contentVw")
      .applyConstraints(formats: [
        "H:[contentVw]", "V:[contentVw]"
      ])

    // layout based on grandparent view    
    VFL(contentVw)
      .appendConstraints([
        contentVw.leadingAnchor.constraint(equalTo: view.leadingAnchor),
        contentVw.trailingAnchor.constraint(
            equalTo: view.trailingAnchor,
            constant: 1024
        ),
        contentVw.topAnchor.constraint(equalTo: view.topAnchor),
        contentVw.bottomAnchor.constraint(
            equalTo: view.bottomAnchor,
            constant: 1024
        ),
      ])
    
    contentVw.scrollVw = scrollVw
  }
}

References:

Let's build a calculator

2024-03-06T21:21:00+00:00

Let’s build a calculator!

I saw this challenge on the frontendmentor website and the very next day while traveling to work I was trying to figure out how would I construct a calculator. I was thinking more like in terms of a real mechanical calculator rather than a software and then trying to figure out a circuit diagram.

This is what I came up with:

Let me explain what is this mess.

The data goes through 5 different stages, starting from Input that the user provides with the user interface and then depending on the type of the input it might go to the Buffer or the Operations, both of which are string types. But any change to the Operations would trigger an update to the stored Result which is a number type and most likely a floating type. The result is computed using the last stored value and the value in the buffer. And finally, every input should eventually refresh the text on Display.

So for any numeric input we just update our buffer. The special case is with 0 since we don’t want multiple leading 0s. Finally we concatenate the buffer and send the output string for display.

let buf = ["0"];

function handleInput(key) {
  switch (key) {
    // ....

    default:
      if (!"0123456789".includes(key)) return undefined;
      // if the only digit in buffer is a 0 then replace it with the input
      if (buf.length === 1 && buf[0] === "0") {
        buf[0] = key;
      } else {
        buf.push(key);
      }
      return buf.join("");
  }
}

If the input is a command type (like +-*/=) then we compute the result with the value in buffer and the last result and the last cached command. Remember that + operation is actually performed after the user presses the = button. For example:

Input	Cache	Display
5		5
+	+	5
3	+	5
=	=	8

Another caveat is to avoid keeping a default result value like say a 0. As this might not work for some operations like * where then anything that multiplies with 0 becomes 0. It’s better to just keep it undefined initially.

let res = undefined;
let fn = undefined;

const add = (res, curr) => res + curr;
const sub = (res, curr) => res - curr;
const mul = (res, curr) => res * curr;
const div = (res, curr) => res / curr;
const eql = (res, curr) => res;

function computeResult(next) {
  let curr = parseFloat(buf.join(""));
  curr = isNaN(curr) ? 0 : curr;

  if (res === undefined) {
    res = curr;
  } else {
    res = fn(res, curr);
  }

  fn = next;

  return res.toString();
}

function handleInput(key) {
  switch (key) {
    case "+":
      return computeResult(add);

    case "-":
      return computeResult(sub);

    case "*":
      return computeResult(mul);

    case "/":
      return computeResult(div);

    case "=":
      return computeResult(eql);

    // ...
  }
}

Then there is the special case of handling . key. In this case we simply add the . to the buffer is it isn’t there already.

function handleInput(key) {
  switch (key) {
    case ".":
      if (!buf.includes(".")) {
        buf.push(".");
      }
      return buf.join("");

    // ...
  }
}

Similar buffer manipulations can be performed for other commands like when user presses the DEL button which just pops the buffer.

function handleInput(key) {
  switch (key) {
    case "Backspace":
      buf.pop();
      if (buf.length === 0) {
        buf = ["0"];
      }
      return buf.join("");

    // ...
  }
}

You must have realized that although internally we keep the computed result in res as number but we return back a string. This is to avoid dealing with the complexities that comes when dealing with floating point numbers. The drawing output to display is then simply the matter of string manipulation, and in my personal case since my calculator can not fit more than 13 digits I can simply not display more than 13 chars.

const outFld = document.querySelector("#output");

function draw(text) {
  if (text === undefined) return;
  outFld.innerHTML = text.slice(0, 13);
}

If you want you can play with the final result here or go play with the source code

Hello MAUI

2024-01-23T23:30:00+00:00

So another cross platform tool that I’ve been trying to poke for a very very long time now is .NET MAUI. Since I love making games with Unity and C# so I’ve always wondered what would it feel like to also make apps with C#. Also I’ve heard good things about .NET. So yes, lets dive into it.

Set up

The first struggle getting started with MAUI is that according to the official docs the first step is to Download and install Visual Studio 2022 for Mac but also recently they announced that Visual Studio for Mac is going away soon. The recommended route for the upcoming future is to use the Visual Studio Code with the official extensions, so this is what I’m also going to try.

So let’s install:

vscode extensions
dotnet
dotnet workload install maui

Next up, create the project using whatever they tell you to. And then after spending a weekend updating and installing the ‘correct’ version of macOS, Xcode, Simulator runtimes and whatnot we finally have our MAUI project building and running!

Maybe using Android as the base development target would had been easier, but who know

Let’s make the app

So the next struggle is to find good resources on learning .NET MAUI. There are very limited resources out there. From the official docs I was able to find a good tutorial on getting started with MAUI. The workshop is about building an app called Monkey Finder. Sounds great!

So again looking at our json data from jsonplaceholder/photos

[
  {
    "albumId": 1,
    "id": 1,
    "title": "accusamus beatae ad facilis cum similique qui sunt",
    "url": "https://via.placeholder.com/600/92c952",
    "thumbnailUrl": "https://via.placeholder.com/150/92c952"
  },
]

the first thing we need is a model object, conveniently called Photo

public class Photo
{
    public int albumId { get; set; }
    public int id { get; set; }
    public string title { get; set; }
    public string url { get; set; }
    public string thumbnailUrl { get; set; }
}

Next, we want to render this object in an element. With MAUI or .NET development in general it seems to be the standard practice to group classes under an various namespace grouping similar functionalities, like Models and Views. So the Photo type above would be under namespace PhotoApp.Models and all the views would be under namespace PhotoApp.Views.

Then in the xaml files the namespaces can be imported as:

xmlns:views="clr-namespace:PhotoApp.Views"

Another pattern is to use a local namespace for the entire App code and no more worrying about namespaces anymore.

xmlns:local="clr-namespace:PhotoApp"

To be honest I can’t make up my mind. I’ll try them both out and see whatever feels good.

The UI API is like any other old school xml based api. So for a list of items with each item having a image and text elements vertically laid out we can use a CollectionView

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:models="clr-namespace:PhotoApp.Models"
             x:Class="PhotoApp.Views.MainPage">
    <CollectionView>
        <CollectionView.ItemsSource>
            <x:Array Type="{x:Type models:Photo}">
                <models:Photo
                    albumId="1"
                    id="1"
                    title="accusamus beatae ad facilis cum similique qui sunt"
                    url="https://via.placeholder.com/600/92c952"
                    thumbnailUrl="https://via.placeholder.com/150/92c952" />
                <models:Photo 
                    albumId="1"
                    id="2"
                    title="reprehenderit est deserunt velit ipsam"
                    url="https://via.placeholder.com/600/771796"
                    thumbnailUrl="https://via.placeholder.com/150/771796" />
                <models:Photo 
                    albumId="1"
                    id="3"
                    title="officia porro iure quia iusto qui ipsa ut modi"
                    url="https://via.placeholder.com/600/24f355"
                    thumbnailUrl="https://via.placeholder.com/150/24f355"/>
            </x:Array>
        </CollectionView.ItemsSource>
        <CollectionView.ItemTemplate>
            <DataTemplate x:DataType="models:Photo">
                <VerticalStackLayout Padding="8">
                    <Image Source="{Binding thumbnailUrl}" />
                    <Label 
                        Text="{Binding title}" 
                        HorizontalOptions = "LayoutOptions.CenterAndExpand" />
                </VerticalStackLayout>
            </DataTemplate>
        </CollectionView.ItemTemplate>
    </CollectionView>
</ContentPage>

The interesting bit is that while prototyping we can hardcode that data right within xaml using CollectionView.ItemsSource.

Each element within the collection view needs a ItemTemplate and then within the ItemTemplate we can define the sort of function per data type with DataTemplate with the argument being passed in as Binding.

Mentally I think of this in code as:

CollectionView(
    itemsSource = Photo[] { ... },
    itemTemplate = {
        dataTemplate = (binding: Photo) => View { ... }
    }
)

And similarly for the details page we can do something like:

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
            xmlns:models="clr-namespace:PhotoApp.Models"
             x:Class="PhotoApp.Views.DetailsPage">
    <CollectionView>
        <CollectionView.ItemsSource>
            <x:Array Type="{x:Type models:Photo}">
                <models:Photo
                    albumId="1"
                    id="1"
                    title="accusamus beatae ad facilis cum similique qui sunt"
                    url="https://via.placeholder.com/600/92c952"
                    thumbnailUrl="https://via.placeholder.com/150/92c952" />
            </x:Array>
        </CollectionView.ItemsSource>
        <CollectionView.ItemTemplate>
            <DataTemplate x:DataType="models:Photo">
                <VerticalStackLayout Padding="8">
                    <Image Source="{Binding url}" />
                    <Label 
                        Text="{Binding title}" 
                        HorizontalOptions = "LayoutOptions.CenterAndExpand" />
                </VerticalStackLayout>
            </DataTemplate>
        </CollectionView.ItemTemplate>
    </CollectionView>
</ContentPage>

One of the cool things that I like about xaml is that we can use the shorthand or the long version of a tag. So these two are identical:

<Label FontSize="22" />

<Label>
    <Label.FontSize>
        22
    </Label.FontSize>
</Label>

So how about adding a transition between the screens. To achieve this there are quite a number of steps.

First we need to register a route. This is pretty simple in MAUI. There’s actually a pretty nice convenience way to avoid hardcoding "DetailsPage" by using the nameof expression.

public partial class AppShell : Shell
{
    public AppShell()
    {
        InitializeComponent();
        Routing.RegisterRoute(nameof(DetailsPage), typeof(DetailsPage));
    }
}

Next sticking with the MVC pattern we need to create a MainController class for our MainPage. The controller only has a single command which is to invoke the "DetailsPage" route

public partial class MainController : ObservableObject
{
    [RelayCommand]
    async Task Tap()
    {
        await Shell.Current.GoToAsync(nameof(DetailsPage));
    }
}

And next we need to inject the MainController as an dependency to the MainPage.

public partial class MainPage : ContentPage
{
    public MainPage(MainController controller)
    {
        InitializeComponent();
        BindingContext = controller;
    }
}

We need to set the BindingContext to the controller to have this available in the associated xaml file. And that is where we can add a TapGestureRecognizer to the Image

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:models="clr-namespace:PhotoApp.Models"
             xmlns:ctrls="clr-namespace:PhotoApp.Controllers"
             x:Class="PhotoApp.Views.MainPage"
             x:DataType="PhotoApp.Controllers.MainController">
    <CollectionView>
        <CollectionView.ItemsSource> ... </CollectionView.ItemsSource>
        <CollectionView.ItemTemplate>
            <DataTemplate x:DataType="models:Photo">
                <VerticalStackLayout Padding="8">
                    <Image Source="{Binding thumbnailUrl}">
                        <Image.GestureRecognizers>
                        <TapGestureRecognizer 
                            Command="{Binding Source={RelativeSource AncestorType={x:Type ctrls:MainController}}, Path=TapCommand}" />
                        </Image.GestureRecognizers>
                    </Image>
                    <Label 
                        Text="{Binding title}" 
                        HorizontalOptions = "LayoutOptions.CenterAndExpand" />
                </VerticalStackLayout>
            </DataTemplate>
        </CollectionView.ItemTemplate>
    </CollectionView>
</ContentPage>

The final missing piece is to make sure that the MainController is injected into our MainPage when constructed. This can be done in the MauiProgram

public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();
        // ...
        builder.Services.AddSingleton<MainPage>();
        builder.Services.AddSingleton<MainController>();
        // ...
        return builder.Build();
    }
}

This pattern prepares the builder factory to provide instances as a singleton or as transient whenever requested.

And with this in place we can finally go from MainPage to DetailsPage

To pop back we need to create and bind a DetailsController with DetailsPage and navigate back to parent with ..

public partial class DetailsController : ObservableObject
{
    [RelayCommand]
    async Task GoBack()
    {
        await Shell.Current.GoToAsync("..", true);
    }
}

// MainProgram.cs
builder.Services.AddTransient<DetailsPage>();
builder.Services.AddTransient<DetailsController>();

<!-- DetailsPage.xaml -->
<Shell.BackButtonBehavior>
    <BackButtonBehavior Command="{Binding GoBackCommand}" TextOverride="Back" />   
</Shell.BackButtonBehavior>

For some reason I’m unable to have the “Back” text on the navbar. But anyways when I tap on the empty space where the back button should’ve been otherwise I’m able to pop back. Is this a bug or feature it’s too early for me to say.

Fetching data

Next up is fetching data from the network. One easy way to get started is to have pull to refresh. This can be achieved by adding RefreshView to the MainPage

<RefreshView 
    IsRefreshing="{Binding IsRefreshing}"
    Command="{Binding GetPhotosCommand}">
    <CollectionView 
        ItemsSource="{Binding Photos}"
        SelectionMode="None" >
        <CollectionView.ItemTemplate>
            <DataTemplate x:DataType="local:Photo">
                <VerticalStackLayout Padding="8">
                    <Image Source="{Binding thumbnailUrl}" />
                    <Label 
                        Text="{Binding title}" 
                        HorizontalOptions = "LayoutOptions.CenterAndExpand" />
                </VerticalStackLayout>
            </DataTemplate>
        </CollectionView.ItemTemplate>
    </CollectionView>
</RefreshView>

Notice that we are now loading the data from a Photos collection from the context, and similarly we are sending the GetPhotosCommand to the context whenever the pull-to-refresh is triggered.

Next step is to actually implement the GetPhotosCommand in BindingContext aka the MainController

public partial class MainController : ObservableObject
{
    public ObservableCollection<Photo> Photos { get; } = new();
    PhotoService photoService;

    [ObservableProperty]
    bool isRefreshing;

    [ObservableProperty]
    string title;

    public MainController(PhotoService photoService)
    {
        this.photoService = photoService;
        Title = "Photos";
    }

    [RelayCommand]
    async Task GetPhotos()
    {
        try
        {
            var photos = await photoService.GetPhotos();
            Photos.Clear();
            // The default photos is a list of 5000 elements .. so we only load first 100
            for (int i = 0; i < photos.Count && i < 100; i++)
                Photos.Add(photos[i]);
        }
        catch (System.Exception ex)
        {
            // TODO: show error UI

        }
        finally
        {
            IsRefreshing = false;
        }
    }
}

Due to the .NET magic, GetPhotosCommand is mapped to GetPhotos method because it is annotated with RelayCommand. And thanks to the magic of ObservableCollection the UI will refresh automatically whenever the collection is updated. But this could have some performance implication, so I tried to only load a few photos.

The final missing piece is the PhotoService, which is also probably the least surprising, just some good old data fetching and json parsing.

public class PhotoService
{
    HttpClient httpClient;

    public PhotoService()
    {
        httpClient = new HttpClient();
    }

    public async Task<List<Photo>> GetPhotos()
    {
        var response = await httpClient.GetAsync("https://jsonplaceholder.typicode.com/photos");
        if (response.IsSuccessStatusCode)
        {
            return await response.Content.ReadFromJsonAsync(PhotoContext.Default.ListPhoto);
        }
        return new List<Photo>();
    }
}

PhotoContext is how cool kids provide a List<Photo> type

[JsonSerializable(typeof(List<Photo>))]
internal sealed partial class PhotoContext : JsonSerializerContext {}

And so we finally can get the data from network

Passing data between screens

And with that the last remaining item on the list is to pass the data between pages. So to keep things simple if we were to have the DetailsPage also make use of CollectionView but rather have an array of one element as data source, our DetailsController would look almost identical to MainController except that we also need to implement the IQueryAttributable to support receiving of data that we would send from the MainPage.

In our case we would be passing a Dictionary with single element in it as Photo

public partial class DetailsController : ObservableObject, IQueryAttributable
{
    public ObservableCollection<Photo> Photos { get; } = new();

    [ObservableProperty]
    string title;

    public DetailsController()
    {
        Title = "Details";
    }

    public void ApplyQueryAttributes(IDictionary<string, object> query)
    {
        var photo = query["Photo"] as Photo;
        Photos.Add(photo);
    }

    //...
}

Next in the MainController we need to update the TapCommand to take in a Photo as parameter that can be forwarded to the DetailsPage.

public partial class MainController : ObservableObject
{
    [RelayCommand]
    async Task Tap(Photo photo)
    {
        var navigationParameter = new Dictionary<string, object> { { "Photo", photo } };
        await Shell.Current.GoToAsync(nameof(DetailsPage), navigationParameter);
    }

    // ...
}

And finally, from the MainPage UI we need to fill in the Photo as CommandParameter

<DataTemplate x:DataType="local:Photo">
    <VerticalStackLayout>
        <Image Source="{Binding thumbnailUrl}">
            <Image.GestureRecognizers>
            <TapGestureRecognizer 
Command="{Binding Source={RelativeSource AncestorType={x:Type local:MainController}}, Path=TapCommand}" 
CommandParameter="{Binding .}" />
            </Image.GestureRecognizers>
        </Image>
    </VerticalStackLayout>
</DataTemplate>

Conclusion

This brings me to the end of this experiment for now. So how do I feel about MAUI? I think I’m sort of relieved that this experiment is done for now. I feel that MAUI needs a lot of work before it can actually be used for real. There are way too many bugs currently. And on macOS, which I guess is the main machine for most of the mobile devs, working on MAUI with Visual Studio Code was very painful. But I hope it would improve.

Said that, I do like the idea of having a nice language like C# for making apps. MAUI has all the potential to be the best cross-platform mobile development tool out there. Also building on top of .NET and other battle tested Microsoft tech sounds very promising and I was able to find a lot of help online for any question I had. So I would definitely be keeping an eye out for MAUI.

Next I would probably try MAUI from a Windows machine with Visual Studio, you know the way it’s supposed to be, and see if that actually improves the developer experience.

The code is available at github.com/chunkyguy/PhotoApp like always.

Hello React Native one more time

2024-01-15T20:59:00+00:00

I wanted to try React Native for quite some time now. But this time for real.

For context, I have tried building the https://github.com/chunkyguy/PhotoApp with React Native quite a while ago and it was fun but also scary because I had no clue what was happening. I was simply following some tutorial and copy pasting code from the internet to make things work. And yes, eventually I was able to fetch data and draw it on the screen but honestly I had no clue what just happened. The entire app was just this one file called App.js

import React, { Component } from 'react';
import { Text, View, FlatList, ActivityIndicator, Image } from 'react-native';

class ImageTile extends Component {
  render() {
    return <View>
      <Image source={{ uri: this.props.source }} style={{ width: 150, height: 150 }} />
      <Text>{this.props.title}</Text>
    </View>
  }
}

export default class PhotoApp extends Component {
  constructor(props) {
    super(props)
    this.state = { isLoading: true, title: 'Loading ...' };
  }

  componentDidMount() {
    return fetch('https://jsonplaceholder.typicode.com/photos')
      .then((response) => response.json())
      .then((responseJson) => {
        this.setState({
          isLoading: false,
          title: 'Photo App',
          dataSource: responseJson,
        }, function () {

        });
      })
      .catch((error) => {
        console.error(error);
      });
  }

  render() {
    if (this.state.isLoading) {
      return (
        <View style={{ flex: 1, padding: 20 }}>
          <ActivityIndicator />
        </View>
      );
    }

    return (
      <View style={{ padding: 100 }}>
        <Text style={{ fontSize: 32 }}>{this.state.title}</Text>
        <FlatList
          data={this.state.dataSource}
          renderItem={({ item }) => <ImageTile
            source={item.thumbnailUrl}
            title={item.title}
          />}
          keyExtractor={({ id }, index) => id}
        />
      </View>
    );
  }
}

So I decided to learn React Native for real. It took me almost a year. This is what happened:

Started learning React Native
Started learning javascript
Gave up learning javascript as it was too confusing for my brain and started learning typescript instead
typescript is awesome. Grasped enough to continue with my React Native journey
Still can’t figure out React Native as it assumes a lot of prior knowledge of React
Started learning React
Can’t learn React without learning html and css. So started learning html css
To make html css work with typescript I needed to understand how the build system work. So went deeper into web tech stuff like webpack, vite, babel, …
Finally can build static web pages with html, css and typescript
Took a brief detour to also learn express and mongoDB because most of React courses are MERN stack: mongoDB, express, react, node.js
More deep diving into CommonJS vs ES modules, aka const foo = require('foo') vs import foo from 'foo'
Finally can build full stack web app with MERN stack. Am I a full stack developer now?
Tried taking another stab at javascript because typescript assumes that you’re so good at javascript that you don’t even like it anymore
javascript makes total sense now. Maybe I like it even more than typescript. Wut?!?
Finally can now understand React Native
Today made the PhotoApp with React Native in just a few hours

Not bad right?

So from what I know today, this is how I made the PhotoApp using React Native.

Installing React Native

At this step you’d probably looking at the Setting up the development environment page. The first question on expo vs react-native CLI is actually pretty simple to answer. I’ve no clue what is expo and right now I’ve no intention of learning so I’ll use the react-native CLI thank you. This means install node and watchman

brew install node
brew install watchman

node provides the environment for javascript to execute outside of browser and watchman is a tool that listens to changes you make to re-triggers a build if necessary.

Create app

Next step is to create the app. This mean running this command:

npx react-native@latest init PhotoApp

So you might have heard of npm, the node package manager used for installing packages but what the heck is npx? No that isn’t a typo, npx is a tool that lets you download a package and run the command within the package. So this command would download the latest stable version of react-native and then run the init command on it with PhotoApp as the argument. This would then run a bunch of other stuff to eventually create a minimal react-native app for you.

The installer might ask to run pod install at the almost end of the set up.

Do you want to install CocoaPods now? Only needed if you run your project in Xcode directly › (y/N)

I would suggest to say N, because it never seemed to the right thing for me. But if you feel comfortable try with y.

When the npx is done creating the project, you should have a PhotoApp directory with following contents:

.
├── App.tsx
├── Gemfile
├── README.md
├── __tests__
├── android
├── app.json
├── babel.config.js
├── index.js
├── ios
├── jest.config.js
├── metro.config.js
├── node_modules
├── package-lock.json
├── package.json
└── tsconfig.json

If you said N for the pod install step above, now is the time to run it manually:

cd ios
bundle install
bundle exec pod install
cd ..

This would finally make the app ready to go.

First run

Running the app requires 2 steps.

npm start
npm run ios

To understand what this does take a look at package.json and you would see a scripts section like this:

"scripts": {
  "android": "react-native run-android",
  "ios": "react-native run-ios",
  "lint": "eslint .",
  "start": "react-native start",
  "test": "jest"
}

npm start is the shorthand for npm run start which runs react-native start which starts the Metro server.

npm run ios runs react-native run-ios which compiles and builds the ‘client’ app on the simulator.

When developing React apps it is a common strategy to run a dev server on localhost and a bundler tool that listens for any changes to the source code. So whenever you save a js or ts file the bundler tool does a few things like converting typescript code to javascript or converting javascript code to more awesome javascript code or move static resources to some build directory and then restart the dev server from that build directory. And finally update the client app or the browser. This save you from having to manually restart the server and refresh the browser for every change. Or in our case we would have to not build and run the app for every change.

If all goes fine, you should be looking at this screen:

App setup

Although the default template now generates typescript code because that is what most of the experienced developers actually use. But if you’re just getting started typescript might not be a good idea. Typescript adds type annotations to all of your code that helps with catching bugs at build time but most the older tutorials and sample codes out there might still be in javascript. Also, most of the typescript developers assume that you know at least some basic javascript and also since at runtime the code that is being run is actually going to be javascript. So I think it is a good idea to start with javascript and later switch to typescript when you feel confident with the code.

If you’re convinced to continue with javascript then rename the App.tsx to App.jsx, otherwise continue with typescript. All of the javascript code should also run with typescript.

Next, replace the App.jsx with following:

import React from 'react';
import {Text, View} from 'react-native';

export default function App() {
  return (
    <View>
      <Text>Hello React Native!</Text>
    </View>
  );
}

And you should have a minimal app running with the ‘Hello React Native’ text at top left behind the status bar.

Building UI

The way I like to structure the app is by splitting the views in screens and components. Think of screen as the full screen content and components as reusable fragments. Then each screen can be designed in isolation and components can be placed in a common components directory.

So, for our app has 2 screens:

HomeScreen: The 2 column list of photos
DetailsScreen: Single photo details

And 2 components:

PhotoTile: Single photo view
PhotoList: Grid view with 2 column list of PhotoTile

I also like to build the app UI inside out. What that means is to start with the individual components and then compose the screen from those components. In my head I like to think in terms of the UI tree and then starting with the leaf nodes first and later going upwards. This makes it clear with what data needs to be injected from the parent node and what events need to be propagated upwards - aka the FLIC model.

Now lets take a look the data that we are going to get from our API. It looks like an array of elements with each element describing a photo.

[
  {
    "albumId": 1,
    "id": 1,
    "title": "accusamus beatae ad facilis cum similique qui sunt",
    "url": "https://via.placeholder.com/600/92c952",
    "thumbnailUrl": "https://via.placeholder.com/150/92c952"
  },
  ...
]

Starting with PhotoTile, it takes in an element from the array and renders it within half of the screen width

/*
const photo = {
  albumId: 1,
  id: 1,
  title: 'accusamus beatae ad facilis cum similique qui sunt',
  url: 'https://via.placeholder.com/600/92c952',
  thumbnailUrl: 'https://via.placeholder.com/150/92c952',
};

<PhotoTile photo={photo} />
*/

export default function PhotoTile({photo}) {
  const {title, thumbnailUrl} = photo;

  return (
    <View style={styles.container}>
      <TouchableOpacity style={styles.content}>
        <Image style={styles.image} source={{uri: thumbnailUrl}} />
        <Text style={styles.title} numberOfLines={2}>
          {title}
        </Text>
      </TouchableOpacity>
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    width: Dimensions.get('window').width / 2,
    height: 220,
  },
  content: {
    backgroundColor: '#f2f2f2',
    alignItems: 'center',
    margin: 8,
  },
  image: {
    width: 150,
    height: 150,
  },
  title: {
    fontSize: 18,
    textAlign: 'center',
    paddingTop: 8,
  },
});

Next up, PhotoList takes in a list of photos and draws a grid of PhotoTile

/*
const photoList = [
  {
    albumId: 1,
    id: 1,
    title: 'accusamus beatae ad facilis cum similique qui sunt',
    url: 'https://via.placeholder.com/600/92c952',
    thumbnailUrl: 'https://via.placeholder.com/150/92c952',
  },
  ...
]

<PhotoList photoList={photoList} />
*/

export default function PhotoList({photoList}) {
  return (
    <FlatList
      data={photoList}
      renderItem={itemInfo => {
        const {item} = itemInfo;
        return <PhotoTile photo={item} />;
      }}
      keyExtractor={item => {
        const {id} = item;
        return id;
      }}
      horizontal={false}
      numColumns={2}
    />
  );
}

And then finally at the root level the HomeScreen builds the full screen UI using PhotoList within the available safe area

const photoList = [
  {
    albumId: 1,
    id: 1,
    title: 'accusamus beatae ad facilis cum similique qui sunt',
    url: 'https://via.placeholder.com/600/92c952',
    thumbnailUrl: 'https://via.placeholder.com/150/92c952',
  },
  {
    albumId: 1,
    id: 2,
    title: 'reprehenderit est deserunt velit ipsam',
    url: 'https://via.placeholder.com/600/771796',
    thumbnailUrl: 'https://via.placeholder.com/150/771796',
  },
  {
    albumId: 1,
    id: 3,
    title: 'officia porro iure quia iusto qui ipsa ut modi',
    url: 'https://via.placeholder.com/600/24f355',
    thumbnailUrl: 'https://via.placeholder.com/150/24f355',
  },
];

export default function HomeScreen() {
  return (
    <SafeAreaView style={styles.container}>
      <PhotoList photoList={photoList} />
    </SafeAreaView>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
  },
});

Notice, we are not actually making any real network calls but just using some fake data to build the UI. Also while designing we can make use of hot reloading by setting the App to draw the HomeScreen

export default function App() {
  return <HomeScreen />;
}

With this, our HomeScreen should look like

Next, similarly we can design the DetailsScreen

const photo = {
  albumId: 1,
  id: 1,
  title: 'accusamus beatae ad facilis cum similique qui sunt',
  url: 'https://via.placeholder.com/600/92c952',
  thumbnailUrl: 'https://via.placeholder.com/150/92c952',
};

export default function DetailsScreen() {
  const {title, url} = photo;
  return (
    <SafeAreaView style={styles.container}>
      <Image style={styles.image} source={{uri: url}} />
      <Text style={styles.title}>{title}</Text>
    </SafeAreaView>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    alignItems: 'center',
    justifyContent: 'center',
    padding: 8,
  },
  image: {
    width: 300,
    height: 300,
  },
  title: {
    fontSize: 18,
    textAlign: 'center',
    paddingTop: 8,
  },
});

That we can validate by updating the App to only draw the DetailsScreen

export default function App() {
  return <DetailsScreen />;
}

So now that we have 2 screens working in isolation. It’s time to add navigation. To have the native navigation we can use the @react-navigation package by installing these packages:

npm install @react-navigation/native
npm install @react-navigation/native-stack
npm install react-native-screens 
npm install react-native-safe-area-context

Some packages are actually wrappers around pods so it is a good idea to run pod install to update the internal Xcode project. I just use this one liner cd ios && bundle exec pod install && cd ... And if the npm package turns out to be indeed a wrapper around a pod then you might also have to run npm run ios to build the iOS app again.

So, to set up navigation we need to wrap the entire app within a NavigationContainer and then have a Navigator component with multiple named routes with each route having a 1:1 mapping to a screen component.

In code it looks like:

const Stack = createNativeStackNavigator();

export default function App() {
  return (
    <NavigationContainer>
      <Stack.Navigator>
        <Stack.Screen
          name="Home"
          component={HomeScreen}
          options={{title: 'Photo App'}}
        />
        <Stack.Screen
          name="Details"
          component={DetailsScreen}
          options={{title: 'Details'}}
        />
      </Stack.Navigator>
    </NavigationContainer>
  );
}

And then to actually go from the HomeScreen to the DetailsScreen we need to handle the tap gesture in the PhotoTile

export default function PhotoTile({photo, navigation}) {
  // ...

  const handleTap = () => {
    navigation.navigate('Details');
  };

  return (
    <View style={styles.container}>
      <TouchableOpacity style={styles.content} onPress={handleTap}>
        // ...
      </TouchableOpacity>
    </View>
  );
}

Also update the PhotoList and the HomeScreen to pass the navigation downwards

// PhotoList.jsx
export default function PhotoList({photoList, navigation}) {
  return (
    // ...
        <PhotoTile photo={item} navigation={navigation} />;
    // ...
  );
}

// HomeScreen.jsx
export default function HomeScreen({navigation}) {
  return (
    <SafeAreaView style={styles.container}>
      <PhotoList photoList={photoList} navigation={navigation} />
    </SafeAreaView>
  );
}

With this the app should have a working navigation

Passing data between screens

We want the photo data to be passed from the HomeScreen to the DetailsScreen. To achieve this we need to first pass the photo from the PhotoTile as part of event and then use that data to construct the DetailsScreen.

With react native this part is a piece of cake:

// PhotoTile.jsx

// ...
  const handleTap = () => {
    navigation.navigate('Details', { photo });
  };
// ...


// Details.jsx
export default function DetailsScreen({photo, navigation}) {
  // ...
}

The real glue is in the App.jsx where we need to update the routing from drawing static screen to a function that returns a dynamic screen

// App.jsx
export default function App() {
  return (
    <NavigationContainer>
      <Stack.Navigator>
        <Stack.Screen
          name="Home"
          component={HomeScreen}
          options={{title: 'Photo App'}}
        />
        <Stack.Screen name="Details">
          {props => {
            const {photo} = props.route.params;
            return <DetailsScreen photo={photo} />;
          }}
        </Stack.Screen>
      </Stack.Navigator>
    </NavigationContainer>
  );
}

Fetching data from the network

As a final piece we need to fetch the real data from the API. The javascript provides a fetch API for this. And then we need to use 2 hooks from react to consume that data.

useEffect: To start fetching data
useState: To store the state of the data

useEffect takes 2 arguments, a list of values that we need to observe for any changes and a function that is called when the changes are observed. For our case we just need to call fetch at first launch so we pass in an empty array. But if were to provide a refresh button of some sort this is where we would provide that.

useState is just a box to persist the data across different redraw of the component and also a function to trigger a redraw when value changes. Like for our when the fetch finishes.

// Home.jsx
export default function HomeScreen({navigation}) {
  const [isLoading, setLoading] = useState(true);
  const [photoList, setPhotoList] = useState([]);

  const fetchPhotos = async () => {
    try {
      setLoading(true);
      const res = await fetch('https://jsonplaceholder.typicode.com/photos');
      setPhotoList(await res.json());
    } catch (error) {
      console.error(error);
    } finally {
      setLoading(false);
    }
  };

  useEffect(() => {
    fetchPhotos();
  }, []);

  return (
    <SafeAreaView style={styles.container}>
      {isLoading ? (
        <ActivityIndicator />
      ) : (
        <PhotoList photoList={photoList} navigation={navigation} />
      )}
    </SafeAreaView>
  );
}

And with this change our app should be finally complete

Conclusion

So after spending more than a year learning all the web tech things and rebuilding the React Native app how do I feel?

I think the React framework for building web apps is pretty awesome because it builds on top of existing knowledge of html, css, javascript and whatever was out there already. But for React Native it seems like in order to bring React to the mobile they had to invent a sort of mini browser that lives inside your app and yet with all the mind blowing engineering that went in to make React Native work, with the current state of things it is still disappointing to both web devs moving to mobile and mobile devs moving to web.

The only devs who might really enjoy React Native are ones who have been tasked to build both the web frontend and the mobile apps.

But said that, I’ve heard there’s a new rendering engine being developed, let’s see how that changes the picture.

The code from this article is available at https://github.com/chunkyguy/PhotoApp

References

Grandpa's guide to autoresizingMask for modern UIKit developers

2023-09-25T19:19:00+00:00

So I wanted to write a quick tutorial on autoresizingMask. It’s quick because there isn’t a lot of talk about. Or is it?

Before constraints based layout became a thing there was frame based layout. You were supposed to do the math yourself and just pass in the frame property of the UIView to UIKit. And that was all there to it. Later if you wanted to support both landscape and portrait mode you could use autoresizingMask to avoid repeating the math.

The autoresizingMask is just an bunch of flags that you can mix together with the bitwise | operator.

typedef NS_OPTIONS(NSUInteger, UIViewAutoresizing) {
    UIViewAutoresizingNone                 = 0,
    UIViewAutoresizingFlexibleLeftMargin   = 1 << 0,
    UIViewAutoresizingFlexibleWidth        = 1 << 1,
    UIViewAutoresizingFlexibleRightMargin  = 1 << 2,
    UIViewAutoresizingFlexibleTopMargin    = 1 << 3,
    UIViewAutoresizingFlexibleHeight       = 1 << 4,
    UIViewAutoresizingFlexibleBottomMargin = 1 << 5
};

UIViewAutoresizing mask = (UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight);

In Swift, this gets exported as an OptionSet, that you can then use with the fancy array syntax.

struct AutoresizingMask : OptionSet {
    static var flexibleLeftMargin: UIView.AutoresizingMask
    static var flexibleWidth: UIView.AutoresizingMask
    static var flexibleRightMargin: UIView.AutoresizingMask
    static var flexibleTopMargin: UIView.AutoresizingMask
    static var flexibleHeight: UIView.AutoresizingMask
    static var flexibleBottomMargin: UIView.AutoresizingMask
}

let mask: UIViewAutoresizing = [.flexibleWidth, .flexibleHeight]

So what can you do with this mask thing? Not a lot actually. Remember you were supposed to do all the math yourself, and this was just a quick way to make sure your same layout works even when the orientation changes, if that makes sense. So to do such a math you would initially calculate the frame of a view based on the geometry of the superview. So whenever the orientation would change it would simply mean the outmost frame (UIWindow in this case) width and height values got swapped. So every subview would then adjust their frame accordingly. But in some cases you’d prefer to recalculate the frame based on the margin from the superview - autoresizingMask was the way to avoid doing that recalculation.

Conceptually autoresizingMask works with the idea of breaking down the layout in 3 components per direction. So [left, width, right] and [top, height, bottom]. And using autoresizingMask we could specify what components don’t have a fixed value.

To illustrate, let’s say we know we want a view with some exact offset values from the edges, we could build it like:

let bgFrame = view.bounds.insetBy(dx: 16, dy: 64)
let bgVw = UIView(frame: bgFrame)
bgVw.backgroundColor = .systemGray
view.addSubview(bgVw)

So far so good. But as soon as we rotate the device our view starts getting drawn outside of the device frame.

The fix for this is to set the autoresizingMask with flexible width and height to indicate that all the margins are fixed and so the width and height are flexible:

bgVw.autoresizingMask = [.flexibleWidth, .flexibleHeight]

Next, if we wanted to have 4 subviews all pinned to the corners of the bgVw, first we would have to do the math and then set the frames to the respective subviews.

let bgFrame = view.bounds.insetBy(dx: 16, dy: 64)
let cornerSize = CGSize(width: 16, height: 16)
let topLeftFrame = CGRect(
  origin: CGPoint(
    x: bgFrame.minX, 
    y: bgFrame.minY
  ), 
  size: cornerSize
)
let topRightFrame = CGRect(
  origin: CGPoint(
    x: bgFrame.maxX - cornerSize.width, 
    y: bgFrame.minY
  ), 
  size: cornerSize
)
let bottomLeftFrame = CGRect(
  origin: CGPoint(
    x: bgFrame.minX, 
    y: bgFrame.maxY - cornerSize.height
  ), 
  size: cornerSize
)
let bottomRightFrame = CGRect(
  origin: CGPoint(
    x: bgFrame.maxX - cornerSize.width, 
    y: bgFrame.maxY - cornerSize.height
  ), 
  size: cornerSize
)
 
let topLeftVw = UIView(frame: topLeftFrame)
topLeftVw.backgroundColor = .systemTeal
view.addSubview(topLeftVw)

let topRightVw = UIView(frame: topRightFrame)
topRightVw.backgroundColor = .systemYellow
view.addSubview(topRightVw)

let bottomLeftVw = UIView(frame: bottomLeftFrame)
bottomLeftVw.backgroundColor = .systemPink
view.addSubview(bottomLeftVw)

let bottomRightVw = UIView(frame: bottomRightFrame)
bottomRightVw.backgroundColor = .systemIndigo
view.addSubview(bottomRightVw)

And ta-da!

But then as soon as we tilt our device (or in my case the simulator), the UI is all weird looking

But not to worry, the autoresizingMask will save our day. This time we know that the size is fixed but the margins are flexible. So for example the view at top-left corner needs to have the left and top margins fixed or in other words the right and bottom margins are flexible. And similarly for all other corners:

topLeftVw.autoresizingMask = [.flexibleRightMargin, .flexibleBottomMargin]
topRightVw.autoresizingMask = [.flexibleLeftMargin, .flexibleBottomMargin]
bottomLeftVw.autoresizingMask = [.flexibleRightMargin, .flexibleTopMargin]
bottomRightVw.autoresizingMask = [.flexibleLeftMargin, .flexibleTopMargin]

And boom! We are all good again!

Next what if we wanted a subview that is always centered? The first part is again to just do the math

let centerFrame = CGRect(
  x: bgFrame.midX - (cornerSize.width * 0.5),
  y: bgFrame.midY - (cornerSize.height * 0.5),
  width: cornerSize.width,
  height:cornerSize.height
)
let centerVw = UIView(frame: centerFrame)
centerVw.backgroundColor = .black
view.addSubview(centerVw)

But as you could imagine as soon as we rotate the device the center view is gone

The solution this time is to have all the margins be flexible.

centerVw.autoresizingMask = [.flexibleTopMargin, .flexibleBottomMargin,
                             .flexibleLeftMargin, .flexibleRightMargin]

The good thing is that this is still using the auto layout based system. So you could add another subview using the regular constraints based layout if you wish. For example, if we wanted to add another subview but aligned to the centerVw

let centerOffsetVw = UIView()
view.addSubview(centerOffsetVw)
centerOffsetVw.backgroundColor = .systemOrange
centerOffsetVw.translatesAutoresizingMaskIntoConstraints = false
NSLayoutConstraint.activate([
    centerOffsetVw.heightAnchor.constraint(equalTo: centerVw.heightAnchor, multiplier: 1),
    centerOffsetVw.widthAnchor.constraint(equalTo: centerVw.widthAnchor, multiplier: 1),
    centerOffsetVw.leadingAnchor.constraint(equalTo: centerVw.leadingAnchor),
    centerOffsetVw.topAnchor.constraint(equalTo: centerVw.topAnchor, constant: cornerSize.height * 1.5),
])

But the bad thing is you can’t reliably add constraints to a view that is using autoresizingMask. If you try to you might get layout conflicts. You know the familiar giant wall of errors:

[LayoutConstraints] Unable to simultaneously satisfy constraints.
	Probably at least one of the constraints in the following list is one you don't want. 
	Try this: 
		(1) look at each constraint and try to figure out which you don't expect; 
		(2) find the code that added the unwanted constraint or constraints and fix it. 
	(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints) 
(
    "<NSAutoresizingMaskLayoutConstraint:0x600003e0de00 h=&-& v=&-& UIView:0x13db08780.minX == 0.500507*UIView:0x13d908cf0.width - 32.0324   (active)>",
    "<NSAutoresizingMaskLayoutConstraint:0x600003e0ddb0 h=--& v=--& UIView:0x13db08900.minX == 0   (active, names: '|':UIView:0x13d908cf0 )>",
    "<NSLayoutConstraint:0x600003e11630 UIView:0x13db08900.leading == UIView:0x13db08780.leading   (active)>",
    "<NSLayoutConstraint:0x600003e0d950 'UIView-Encapsulated-Layout-Width' UIView:0x13d908cf0.width == 393   (active)>"
)

Since now you know so much about autoresizingMask, maybe it’s time you should also be able to read this error message. Specially the secret code written after NSAutoresizingMaskLayoutConstraint. The part that might read like h=--& v=--& is nothing other than the autoresizingMask. The h and v are obviously horizontal and vertical directions and the next 3 characters are [LeftMargin][Width][RightMargin] and [TopMargin][Height][BottomMargin] with - for fixed values and & for flexible values. And since we only set the flexible values with autoresizingMask so that mean we only care about the values set to &.

So, for example h=--& v=--& means [.flexibleRightMargin, .flexibleBottomMargin].

So as a final task lets write a parser that could take input as autoresizingMask encoded as String and set the autoresizingMask just for fun.

extension UIView {
  // parse format like "h=--& v=--&"
  func setMask(format: String) {
    var autoresizingMask: AutoresizingMask = []
    let subformats = format.components(separatedBy: " ")
    for subformat in subformats {
      let comps = subformat.components(separatedBy: "=")
      if let axis = comps.first, let maskFormat = comps.last, maskFormat.count == 3 {
        let axisMask: [AutoresizingMask] = [
          .flexibleLeftMargin, .flexibleWidth, .flexibleRightMargin,
          .flexibleTopMargin, .flexibleHeight, .flexibleBottomMargin
        ]
        let offset = (axis == "v") ? 3 : 0
        for (idx, val) in maskFormat.enumerated() {
          if val == "&" {
            autoresizingMask.insert(axisMask[idx + offset])
          }
        }
      }
    }
    self.autoresizingMask = autoresizingMask
  }
}

And now we can also set the mask with bgVw.setMask(format: "h=-&- v=-&-").

FLIC - The holy grail of all GUI architectures

2023-08-03T20:50:00+00:00

After many years of search for the best way to build GUI softwares I think I’ve finally found the one true architecture to rule them all!

It is known by many names, some call it the Elm Architecture others call it Redux or Flux, but for simplicity I’ll just call it Feedback Loop Is Cool or FLIC.

At the core of FLIC is a 3 piece orchestra:

The Model that holds the state.
The View that draws the state.
And the Update that triggers the state change.

Another way to look at this architecture is in terms of scene graph. So any GUI application has a tree of Node where each node represents one piece of drawable on screen.

Some of these are simple drawable nodes, you give them some data to draw and they draw it, no questions asked. Like say the Label which takes in a String and draws it. While others are interactive nodes that can emit an event but don’t care who handles that event, like the Button. And finally there are some reactive parent nodes that listen to events emitted from their subtree. These nodes might also hold the state of the subtree and based on the event received they then update the state and trigger a redraw of the subtree below them or just let the event bubble up the tree to be handled by some other parent node. For example, in our case the Button might emit an event that is then caught by the Content and which then might pass a new piece of data to TextView to draw.

In other words FLIC says:

“data goes down and event goes up”.

And that’s it! This is all there is to learn about the architecture. The beauty of this simple pattern is that it is easy to wrap your head around, faster to develop because you’re focusing on only one thing at a time, could be just the drawing part or event handling and so is also easier to maintain. Also since this is such a simple pattern it can be easily applied to any other framework.

UIKit Implementation

On iOS currently we have two UI frameworks, UIKit and SwiftUI and both have a very different opinion on how UI layer should function. SwiftUI is already very close to FLIC and Apple has published quite a lot of articles and videos on how to manage Data and State.

Building FLIC on top of SwiftUI should be easy peasy, so let’s keep it for some other day. Today let’s tackle UIKit. Let’s try building an app and see it in action. Obviously we would be building the hello world of mobile apps, which is the Photo App where we have a loading screen, a success screen with a list of photos and an error screen. Also when we tap on a photo we get a details screen.

Infrastructure

First we need some classes and protocols for sending and catching events

/// Any event
public protocol ViewEvent {}

/// Any event handler
public protocol ViewEventHandler: AnyObject {
  func handle(event: ViewEvent, sender: UIView?)
}

/// Any view that can emit event via the event handler
open class EventView: UIView {
  public weak var eventHandler: ViewEventHandler? {
    didSet {
      subviews.forEach {
        ($0 as? EventView)?.eventHandler = eventHandler
      }
    }
  }
  
  public init(eventHandler: ViewEventHandler? = nil, frame: CGRect) {
    self.eventHandler = eventHandler
    super.init(frame: frame)
  }
  
  public required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
  }
  
  open override func didAddSubview(_ subview: UIView) {
    super.didAddSubview(subview)
    (subview as? EventView)?.eventHandler = eventHandler
  }
}

Next we need is a simple wrapper around UIView so that we won’t have to repeat the same code every time we create a new class.

/// Any view with a view model and an optional event handler
open class View<ViewModel>: EventView {
  public var viewModel: ViewModel {
    didSet {
      if isSetUp {
        viewModelDidUpdate()
      }
    }
  }
  
  public private(set) var isSetUp: Bool
  
  public init(viewModel: ViewModel, eventHandler: ViewEventHandler?, frame: CGRect? = nil) {
    self.viewModel = viewModel
    self.isSetUp = frame != nil
    super.init(eventHandler: eventHandler, frame: frame ?? .zero)
    if isSetUp {
      setUp()
    }
  }

  public convenience init(_ viewModel: ViewModel) {
    self.init(viewModel: viewModel, eventHandler: nil)
  }
  
  public required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
  }
  
  open override func layoutSubviews() {
    super.layoutSubviews()
    setUpIfNeeded()
  }
  
  private func setUpIfNeeded() {
    if !isSetUp {
      isSetUp = true
      setUp()
      viewModelDidUpdate()
    }
  }
  
  // Methods that subclass needs to override
  open func setUp() {}
  open func viewModelDidUpdate() {}
}

And last is an completely optional but handy wrapper to provide an interface to swap any arbitrary content with containerVw.view = SomeContentView(). Note I’m using VFL because it’s was lying around when I was typing this out.

private let contentViewBindableTag = Int.max

/// Any view type that if provides a contentView get a view that fills the content
public protocol ContentViewBindable: AnyObject {
  var contentView: UIView { get }
}

extension ContentViewBindable {
  /// When set replaces the content
  public var view: UIView? {
    get { contentView.viewWithTag(contentViewBindableTag) }  
    set {
      if let oldView = contentView.viewWithTag(contentViewBindableTag) {
        oldView.removeFromSuperview()
      }
      
      if let newView = newValue {
        VFL(contentView)
          .add(subview: newView, name: "view")
          .applyConstraints(formats: ["H:|[view]|", "V:|[view]|"])
        newView.tag = contentViewBindableTag
      }
    }
  }
}

And a bunch of classes that implement ContentViewBindable

open class ContainerView: UIView, ContentViewBindable {
  public var contentView: UIView { self }
}
open class TableViewCell: UITableViewCell, ContentViewBindable {}
open class TableViewHeaderFooterView: UITableViewHeaderFooterView, ContentViewBindable {}
open class CollectionCell: UICollectionViewCell, ContentViewBindable {}
open class CollectionReusableView: UICollectionReusableView, ContentViewBindable {
  public var contentView: UIView { self }
}

And we are done with the infrastructure.

Views

We definitely need an AsyncView to wrap the 3 states: loading, error and success

enum AsyncViewModel {
  case loading
  case success(UIView)
  case error(AppError)
}

class AsyncView: View<AsyncViewModel>, ContentViewBindable {
  var contentView: UIView { self }
  
  override func setUp() {
    super.setUp()
    backgroundColor = .white
  }
  
  override func viewModelDidUpdate() {
    super.viewModelDidUpdate()
    switch viewModel {
    case .loading:
      self.view = LoadingView(true)
    case .success(let view):
      self.view = view
    case .error(let error):
      self.view = ErrorView(error)      
    }
  }
}

LoadingView is simple because the ViewModel is a Bool

class LoadingView: View<Bool> {
  private let loadingVw = UIActivityIndicatorView(style: .large)

  override func setUp() {
    super.setUp()
    VFL(self)
      .add(subview: loadingVw, name: "loadingVw")
      .applyConstraints(constraints: [
        loadingVw.centerXAnchor.constraint(equalTo: centerXAnchor),
        loadingVw.centerYAnchor.constraint(equalTo: centerYAnchor)
      ])
    loadingVw.hidesWhenStopped = true
    loadingVw.tintColor = UIColor.black
  }
  
  override func viewModelDidUpdate() {
    super.viewModelDidUpdate()
    if viewModel {
      loadingVw.startAnimating()
    } else {
      loadingVw.stopAnimating()
    }
  }
}

The ErrorView on the other hand is interesting because apart from rendering the error message it also needs to emit event in case user taps on the retry button.

enum AppError: Error {
      // ...
}

enum AppViewEvent: ViewEvent {
  case retry
  // ...
}

class ErrorView: View<AppError> {
  override func setUp() {
    let label = UILabel()
    let button = UIButton(type: .roundedRect)
    super.setUp()
    VFL(self)
      .add(subview: label, name: "label")
      .add(subview: button, name: "button")
      .applyConstraints(formats: [
        "H:|[label]|",
        "H:[button(100)]",
        "V:[label]-16-[button(52)]"
      ])
      .appendConstraints([
        label.centerYAnchor.constraint(equalTo: centerYAnchor),
        button.centerXAnchor.constraint(equalTo: centerXAnchor)
      ])
    label.text = viewModel.localizedDescription
    label.numberOfLines = 0
    label.textAlignment = .center
    button.setTitleColor(.black, for: .normal)
    button.setTitle("Retry", for: .normal)
    button.addTarget(self, action: #selector(handleTap), for: .touchUpInside)
  }
  
  @objc func handleTap() {
    assert(eventHandler != nil)
    eventHandler?.handle(event: AppViewEvent.retry, sender: self)
  }
}

Event Handling

With all that in place we can use the rootViewController to hold the AsyncView and listen to any events and perform appropriate actions. Assume AppController is the real brain of the app and provides the data when requested to the UI.

class ViewController: UIViewController, ViewEventHandler {
  private let controller = AppController()
  private lazy var contentVw = AsyncView(viewModel: .loading, eventHandler: self)
  
  override func viewDidLoad() {
    super.viewDidLoad()
    VFL(view)
      .add(subview: contentVw, name: "contentVw")
      .applyConstraints(formats: [
        "H:|[contentVw]|", "V:|[contentVw]|"
      ])
    
    Task.detached { await self.reloadPhotos() }
  }
  
  @MainActor
  private func reloadPhotos() async {
    contentVw.viewModel = .loading
    let photos = await controller.fetchPhotos()
    switch photos {
    case .success(let photos):
      let photoListVw = PhotoListView(
        viewModel: PhotoListViewModel(title: "Photos", photos: photos),
        eventHandler: self,
        controller: controller
      )
      contentVw.viewModel = .success(photoListVw)
    case .failure(let err):
      contentVw.viewModel = .error(err)
    }
  }
  
  func handle(event: ViewEvent, sender: UIView?) {
    guard let event = event as? AppViewEvent else {
      assertionFailure("Unrecognized event \(event)")
      return
    }
    
    switch event {
    case .retry:
      Task.detached { await self.reloadPhotos() }
    case .showDetails(let photo):
      let photoVwCtrl = PhotoViewController(photo: photo, controller: controller)
      present(photoVwCtrl, animated: true)
    }
  }
}

The PhotoListView is the view that provides a tiles of all the photos.

struct PhotoListViewModel {
  var title: String
  var photos: [Photo]
}

class PhotoListView: View<PhotoListViewModel> {
  private static let cellId = "photo-list-cell"
  private static let headerId = "photo-list-header"
  
  private let controller: AppController
  
  init(
    viewModel: PhotoListViewModel,
    eventHandler: ViewEventHandler?,
    frame: CGRect? = nil,
    controller: AppController
  ) {
    self.controller = controller
    super.init(viewModel: viewModel, eventHandler: eventHandler, frame: frame)
  }
  
  required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
  }
  
  private let collectionVw = UICollectionView(
    frame: .zero,
    collectionViewLayout: UICollectionViewFlowLayout()
  )

  override func setUp() {
    super.setUp()

    VFL(self)
      .add(subview: collectionVw, name: "collectionVw")
      .applyConstraints(formats: [
        "H:|[collectionVw]|", "V:|[collectionVw]|"
      ])
    
    collectionVw.register(CollectionCell.self, forCellWithReuseIdentifier: Self.cellId)
    collectionVw.register(
      CollectionReusableView.self,
      forSupplementaryViewOfKind: UICollectionView.elementKindSectionHeader,
      withReuseIdentifier: Self.headerId
    )

    backgroundColor = .black
    collectionVw.backgroundColor = .black
    collectionVw.dataSource = self
    collectionVw.delegate = self
  }
  
  override func viewModelDidUpdate() {
    super.viewModelDidUpdate()
    collectionVw.reloadData()
  }
}

extension PhotoListView: UICollectionViewDataSource {
  func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int {
    return viewModel.photos.count
  }
  
  func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell {
    let cell = collectionView.dequeueReusableCell(withReuseIdentifier: Self.cellId, for: indexPath)
    if let collectionCell = cell as? CollectionCell {
      collectionCell.view = PhotoView(
        viewModel: viewModel.photos[indexPath.item].thumbnailUrl,
        eventHandler: eventHandler,
        controller: controller
      )
    }
    return cell
  }
  
  func collectionView(_ collectionView: UICollectionView, viewForSupplementaryElementOfKind kind: String, at indexPath: IndexPath) -> UICollectionReusableView {
      let supplementaryView = collectionView.dequeueReusableSupplementaryView(ofKind: kind, withReuseIdentifier: Self.headerId, for: indexPath)
      if let headerView = supplementaryView as? CollectionReusableView {
        headerView.view = TitleView(viewModel.title)
      }
      return supplementaryView
    }
}

// MARK: UICollectionViewDelegateFlowLayout
extension PhotoListView: UICollectionViewDelegateFlowLayout {

    func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, sizeForItemAt indexPath: IndexPath) -> CGSize {
      return CGSize(width: collectionView.bounds.width/2.0, height: 200
      )
    }

    func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, insetForSectionAt section: Int) -> UIEdgeInsets {
        return .zero
    }

    func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, minimumLineSpacingForSectionAt section: Int) -> CGFloat {
        return 0
    }

    func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, minimumInteritemSpacingForSectionAt section: Int) -> CGFloat {
        return 0
    }

    func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, referenceSizeForHeaderInSection section: Int) -> CGSize {
        return CGSize(width: collectionView.bounds.width, height: 128)
    }

    func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, referenceSizeForFooterInSection section: Int) -> CGSize {
        return .zero
    }
}

extension PhotoListView: UICollectionViewDelegate {
    func collectionView(_ collectionView: UICollectionView, didSelectItemAt indexPath: IndexPath) {
      assert(eventHandler != nil)
      eventHandler?.handle(event: AppViewEvent.showDetails(viewModel.photos[indexPath.item]), sender: self)
    }
}

extension PhotoListView {
  class TitleView: View<String> {
    override func setUp() {
      super.setUp()
      let titleLabel = UILabel()
      VFL(self)
        .add(subview: titleLabel, name: "titleLabel")
        .applyConstraints(formats: ["V:[titleLabel]-|", "H:|-[titleLabel]|"])
      
      titleLabel.backgroundColor = .black
      titleLabel.font = UIFont.boldSystemFont(ofSize: 48)
      titleLabel.textColor = .white
      titleLabel.text = viewModel
    }
  }
}

The most interesting view would be the PhotoView because it just gets a URL string and needs to asynchronously load that photo. So it can again go into 3 states: loading, error and success. But also it needs to be an EventHandler just to the retry loading the photo that failed to load otherwise forward the event up the tree.

typealias PhotoViewModel = String

class PhotoView: View<PhotoViewModel>, ViewEventHandler {
  private let controller: AppController
  private lazy var contentVw = AsyncView(viewModel: .loading, eventHandler: self)

  init(
    viewModel: PhotoViewModel,
    eventHandler: ViewEventHandler?,
    frame: CGRect? = nil,
    controller: AppController
  ) {
    self.controller = controller
    super.init(viewModel: viewModel, eventHandler: eventHandler, frame: frame)
  }
  
  required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
  }
  
  override func setUp() {
    super.setUp()
    VFL(self)
      .add(subview: contentVw, name: "contentVw")
      .applyConstraints(formats: ["V:|[contentVw]|", "H:|[contentVw]|"])
    
    Task.detached { await self.reloadPhoto() }
  }
  
  @MainActor
  private func reloadPhoto() async {
    contentVw.viewModel = .loading
    let photo = await controller.fetchImage(forURL: viewModel)
    switch photo {
    case .success(let image):
      let imageVw = UIImageView(image: image)
      imageVw.contentMode = .scaleAspectFit
      contentVw.viewModel = .success(imageVw)
    case .failure(let err):
      contentVw.viewModel = .error(err)
    }
  }
  
  func handle(event: ViewEvent, sender: UIView?) {
    guard let event = event as? AppViewEvent else {
      eventHandler?.handle(event: event, sender: sender)
      return
    }
    
    switch event {
    case .retry:
      Task.detached { await self.reloadPhoto() }
    default:
      eventHandler?.handle(event: event, sender: sender)
    }
  }
}

And that’s it! That is how it works!

If you made it so far down my experiment, here are some screenshots from this experiment with various stages:

And yes, the code is also available for your personal experimentation: https://github.com/chunkyguy/WLKit.

Until next time!

References

Autolayout and aligning subviews

2023-07-22T13:55:00+00:00

Quick question: How would you align all subviews horizontally while keeping their centers aligned using autolayout?

With visual formatting language that is quite easy. The method we are interested in looks like:

class func constraints(
    withVisualFormat format: String,
    options opts: NSLayoutConstraint.FormatOptions = [],
    metrics: [String : Any]?,
    views: [String : Any]
) -> [NSLayoutConstraint]

And we are interested in NSLayoutConstraint.FormatOptions:

// Align all specified interface elements using NSLayoutConstraint.Attribute.left on each.
static var alignAllLeft: NSLayoutConstraint.FormatOptions

// Align all specified interface elements using NSLayoutConstraint.Attribute.right on each.
static var alignAllRight: NSLayoutConstraint.FormatOptions

// Align all specified interface elements using NSLayoutConstraint.Attribute.top on each.
static var alignAllTop: NSLayoutConstraint.FormatOptions

// Align all specified interface elements using NSLayoutConstraint.Attribute.bottom on each.
static var alignAllBottom: NSLayoutConstraint.FormatOptions

// Align all specified interface elements using NSLayoutConstraint.Attribute.leading on each.
static var alignAllLeading: NSLayoutConstraint.FormatOptions

// Align all specified interface elements using NSLayoutConstraint.Attribute.trailing on each.
static var alignAllTrailing: NSLayoutConstraint.FormatOptions

// Align all specified interface elements using NSLayoutConstraint.Attribute.centerX on each.
static var alignAllCenterX: NSLayoutConstraint.FormatOptions

// Align all specified interface elements using NSLayoutConstraint.Attribute.centerY on each.
static var alignAllCenterY: NSLayoutConstraint.FormatOptions

// Align all specified interface elements using the last baseline of each one.
static var alignAllLastBaseline: NSLayoutConstraint.FormatOptions

Using the simple VFL wrapper, we can play around with these values. So, if we have three subviews of different sizes added to parent view:

let vfl = VFL()
vfl
    .setParent(self)
    .add(subview: VFLColorView(color: .random), name: "redVw")
    .add(subview: VFLColorView(color: .random), name: "blueVw")
    .add(subview: VFLColorView(color: .random), name: "greenVw")

We can create 2 set of constraints, one for horizontal layout and another for vertical layout

vfl
    .storeConstraints(
        formats: [
            "H:|[redVw(30)][blueVw(60)][greenVw(90)]",
            "V:|-(>=100)-[redVw(30)]",
            "V:|-(>=100)-[blueVw(60)]",
            "V:|-(>=100)-[greenVw(90)]"
        ],
        name: "h_layout"
    )
    .storeConstraints(
        formats: [
            "H:|-(>=100)-[redVw(30)]",
            "H:|-(>=100)-[blueVw(60)]",
            "H:|-(>=100)-[greenVw(90)]",
            "V:|[redVw(30)][blueVw(60)][greenVw(90)]"
        ],
        name: "v_layout"
    )

And then we can apply the constraints based on the alignment type:

let alignment: NSLayoutConstraint.FormatOptions
let vLayouts: NSLayoutConstraint.FormatOptions = [
    .alignAllLeft, .alignAllCenterX, .alignAllRight
]
let constraintsName = vLayouts.contains(alignment) ? "v_layout" : "h_layout"
      
vfl
    .removeAllConstraints()
    .removeAllOptions()
    .addOptions(alignment)
    .applyConstraints(name: constraintsName)

Here are the outputs for all various alignment types:

As an extra bonus, if we with to have the changes always animated all we need to add is:

vfl
    .removeAllConstraints()
    .removeAllOptions()
    .addOptions(alignment)
    .applyConstraints(name: constraintsName)
      
UIView.animate(withDuration: 0.2) {
    self.vfl.parentView?.layoutIfNeeded()
}

The full source code is available at: https://github.com/chunkyguy/VFL

Introducing VFL

2023-07-01T16:30:00+00:00

There are a plethora of wrappers around the AutoLayout engine. They all seem to provide convenience towards making the layout code look cleaner. In all fairness this is due to the fact that the first version of NSLayoutContraint API was very verbose. But I remember when Apple announced the constraint based layout they were equally excited about providing a what they referred to as ‘ascii based constraints’. The idea is to create constraints between siblings and parent UI elements in a string based format. They even provide a guide to “Visual Format Language” aka VFL.

The grammar of the syntax is very simple:

Symbol	Meaning
V	Vertical axis
H	Horizontal axis
-	System spacing
-16-	Constant value of 16
\|	Parent view
[view]	Child view
[view(==300)]	Exact size of 300
[view(>=300)]	Greater than or equal to size of 300
[view(<=300)]	Less than or equal to size of 300
[view(>=40,<=80)]	Size between 40 and 80
[label(textField)]	Set size of label equal to that of textField

As you can realize with this syntax you can build up pretty much a lot of the UI in very little code. To help with reducing the boilerplate code I wrote a simple library called VFL. I call it a library even though it’s just a single file called VFL.swift with a bunch of methods.

The minimal usage looks like:

let view = UIView(frame: .zero)
VFL(self)
    .add(subview: view, name: "view")
    .appendConstraints(formats: [
        "V:|[view]|", "H:|[view]|"
    ])

So if we have a VFLExampleView defined as:

class VFLExampleView: UIView {
  init() {
    super.init(frame: .zero)
    setUp()
  }
  
  required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
  }
  
  func setUp() {
    // override
  }
}

And a VFLColorView that generates a random background color

extension UIColor {
  static var random: UIColor {
    return UIColor(
      hue: CGFloat.random(in: 0...1),
      saturation: 0.8, brightness: 0.8, alpha: 1
    )
  }
}

class VFLColorView: UIView {
  init(color: UIColor = .random) {
    super.init(frame: .zero)
    backgroundColor = color
  }
  
  required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
  }
}

We can use VFL to layout some common scenario as:

// Pin subview to all edges
class VFLFullView: VFLExampleView {
  override func setUp() {
    super.setUp()
    VFL(self)
      .add(subview: VFLColorView(), name: "view")
      .appendConstraints(formats: [
         "H:|[view]|", "V:|[view]|"
      ])
  }
}

// Pin subview of size 100x100 to top-left corner with default spacing
class VFLFixView: VFLExampleView {
  override func setUp() {
    super.setUp()
    VFL(self)
      .add(subview: VFLColorView(), name: "view")
      .appendConstraints(formats: [
        "H:|-[view(100)]", "V:|-[view(100)]"
      ])
  }
}

// Add two subviews of equal width and same height as parent
class VFLHSplitView: VFLExampleView {
  override func setUp() {
    super.setUp()
    VFL(self)
      .add(subview: VFLColorView(), name: "leftVw")
      .add(subview: VFLColorView(), name: "rightVw")
      .appendConstraints(formats: [
        "H:|[leftVw(==rightVw)][rightVw]|",
        "V:|[leftVw]|", "V:|[rightVw]|"
      ])
  }
}

// Add two subviews of equal height and same width as parent
class VFLVSplitView: VFLExampleView {
  override func setUp() {
    super.setUp()
    VFL(self)
      .add(subview: VFLColorView(), name: "topVw")
      .add(subview: VFLColorView(), name: "bottomVw")
      .appendConstraints(formats: [
        "H:|[topVw]|", "H:|[bottomVw]|",
        "V:|[topVw(==bottomVw)][bottomVw]|"
      ])
  }
}

But VFL is not a replacement for NSLayoutContraint, rather an supplement. So we should be able to add constraints created via the system API. Here’s an example:

// Add a subview of size 320x480 and pinned to the center of parent
class VFLCenterView: VFLExampleView {
  override func setUp() {
    super.setUp()
    
    let view = VFLColorView()
    VFL(self)
      .add(subview: view, name: "view")
      .appendConstraints(formats: [
        "H:[view(320)]", "V:[view(480)]"
      ])
      .appendConstraints([
        NSLayoutConstraint(
          item: view, attribute: .centerX,
          relatedBy: .equal,
          toItem: self, attribute: .centerX,
          multiplier: 1, constant: 0
        ),
        NSLayoutConstraint(
          item: view, attribute: .centerY,
          relatedBy: .equal,
          toItem: self, attribute: .centerY,
          multiplier: 1, constant: 0
        )
      ])
  }
}

For more advanced cases, like supporting different layouts for landscape and portrait orientations we can simply add the subviews once and then define two set of constraints. Since these constraints need to replace the older constraints rather than append, we need to call replaceConstraints() instead of appendConstraints().

Here’s an example:

let vfl = VFL()

// add subviews
let headerVw = UIImageView(image: UIImage(named: "square"))
let borderVw = VFLColorView(color: .green)
let firstThumbVw = UIImageView(image: UIImage(named: "square"))
let secondThumbVw = UIImageView(image: UIImage(named: "square"))

vfl
    .setParent(self)
    .add(subview: headerVw, name: "headerVw")
    .add(subview: borderVw, name: "borderVw")
    .add(subview: firstThumbVw, name: "firstThumbVw")
    .add(subview: secondThumbVw, name: "secondThumbVw")

// detect the orientation and call appropriate method
override func layoutSubviews() {
    super.layoutSubviews()
    if bounds.width < bounds.height {
        layoutSubviewsPortrait()
    } else {
        layoutSubviewsLandscape()
    }
}

// portait layout
private func layoutSubviewsPortrait() {
    vfl.replaceConstraints(
        metrics: [
            "w": bounds.width,
            "hw": bounds.width / 2
          ],
        formats: [
            "H:|[headerVw]|",
            "H:|[borderVw]|",
            "H:|-[firstThumbVw(==secondThumbVw)]-[secondThumbVw]-|",
            "V:|[headerVw(w)][borderVw(40)]",
            "V:[firstThumbVw(hw)]|", "V:[secondThumbVw(hw)]|"
          ]
        )
}

// landscape layout
private func layoutSubviewsLandscape() {
    vfl.replaceConstraints(
        metrics: [
          "w": bounds.height,
          "hw": bounds.height / 2.0,
        ],
        formats: [
          "H:|[headerVw(w)][borderVw(40)]",
          "H:[firstThumbVw(hw)]|", "H:[secondThumbVw(hw)]|",
          "V:|[headerVw]|",
          "V:|[borderVw]|",
          "V:|-[firstThumbVw(==secondThumbVw)]-[secondThumbVw]-|",
        ]
      )
}

I think of VFL as a good candidate for simple fixed sort of layouts and use the regular NSLayoutContraint for more complicated usage, like for scenarios where constraints needs to be animated.

Checkout the source code: github.com/chunkyguy/VFL

References

Downloading system fonts on Apple platforms

2023-05-15T19:58:00+00:00

So it turns out apart from the fonts that come packaged with the Apple platforms you can also download a bunch of fonts at runtime There is a list that Apple has made available that you can find here https://developer.apple.com/fonts/system-fonts/.

So how do you actually download these fonts? It’s not as trivial as it could be. You need to dip your hands into CoreText. But no complains, it’s a beautiful C API that works across all Apple platforms and you can even easily mix it your other cross-platform projects.

And when I say API I mean just this one function:

bool CTFontDescriptorMatchFontDescriptorsWithProgressHandler(
    CFArrayRef descriptors,
    CFSetRef mandatoryAttributes,
    CTFontDescriptorProgressHandler progressBlock
);

There are only two steps before this function can be called:

Create an attributes dictionary
Create a font descriptor with the attributes dictionary

Here’s how it looks with Swift

// Create an attributes dictionary
let attrs = NSDictionary(
    object: fontName,  
    forKey: kCTFontNameAttribute as NSString
)
// Create font descriptor
let desc = CTFontDescriptorCreateWithAttributes(
    attrs as CFDictionary
)    
// Download font
CTFontDescriptorMatchFontDescriptorsWithProgressHandler(
    [desc] as CFArray, nil) { state, _ in
    if state == .didFinish {
        // Font probably downloaded!
        DispatchQueue.main.async { 
            // notify listeners
        }
    }
    return true
}

I’ve skipped a lot of other good things that can be done here, like error handling and tracking progress. But after a while the state would end up at .didFinish and by then if all went well a font would’ve been downloaded somewhere for our use.

So how do we get the said font? Simply like we get any other font:

let font = UIFont(name: fontName, size: size)

The only missing element is the value to pass in for fontName.

Turns out you can’t simply copy paste the Font Name from the link above. For example, if you pass "Apple Chancery" as the fontName, the font API might give you back is actually "Helvetica". What?!

The answer is hidden somewhere in the CTFontDescriptor.h. Take a look at the key we used when creating our attributes dictionary:

/*!
    @defined    kCTFontNameAttribute
    @abstract   The PostScript name.
    @discussion This is the key for retrieving the PostScript name from 
    the font descriptor. When matching, this is treated more generically:
     the system first tries to find fonts with this PostScript name. If 
     none is found, the system tries to find fonts with this family name, 
     and, finally, if still nothing, tries to find fonts with this display 
     name. The value associated with this key is a CFStringRef. If 
     unspecified, defaults to "Helvetica", if unavailable falls back to 
     global font cascade list.
*/
const CFStringRef kCTFontNameAttribute;

So two things: One the system returns "Helvetica" when it can’t find any better matching font, and second, the fontName has to be the PostScript name, whatever that means.

So where could you find the PostScript name? One good answer is the Font Book.app that comes with your Mac.

In the info pane you can see the PostScript name for any font.

So yes the correct value for fontName is "Apple-Chancery".

Conclusion

When does it make sense to use this API? I think for most apps that simply use a selected list of fonts it’s probably simpler to just bundle the custom font. For document based apps where you can’t possibly bundle many different fonts you can download them on demand. Also since this is not actually a font downloading service, but more like a font matching where the service finds you the best match for the provided attributes, it is probably sensible to assume that you won’t always get the exact font you requested for.

References

Inventing EnumArray

2023-01-27T19:30:00+00:00

So today I happened to need something which has an storage of an Array but can not grow. And instead of Int I need a named lookup, like a Dictionary. But then again I don’t want to deal with Optionals. I want the initial values to be populated during the init so that lookups can never be nil. Does such a thing already exists? In Swift I mean. I guess not, so obviously the next step is to make such a thing. I’m calling it EnumArray.

/// A sort of an array but also a dictionary with enum as key, and no optionals
struct EnumArray<K, V> where K: RawRepresentable, K: CaseIterable, K.RawValue == Int {
    private(set) var values: [V]

    private init(_ values: [V]) {
        self.values = values
        assert(values.count == K.allCases.count, "Corrupt data")
    }

    init(_ action: (K) -> V) {
        self.init(K.allCases.map(action))
    }

    subscript(key: K) -> V {
        get { values[key.rawValue] }
        mutating set { values[key.rawValue] = newValue }
    }
}

How do we use an EnumArray? Easy, first we create an enum backed by Int. Next we create our EnumArray. Then we use it.

enum Week: Int, CaseIterable {
    case mon = 0, tue, wed, thu, fri, sat, sun
}

typealias WeekPlan = EnumArray<Week, String>

var plan = WeekPlan { day in
    switch day {
    case .mon: return "Learn SwiftUI"
    case .tue: return "Learn SwiftUI"
    case .wed: return "Learn SwiftUI"
    case .thu: return "Learn SwiftUI"
    case .fri: return "Learn Jetpack Compose"
    case .sat: return "What am I doing?"
    case .sun: return "Learn SwiftUI"
    }
}

for day in Week.allCases {
    print("\(plan[day]) on Day \(day)")
}

And to update the only way is via a Dictionary like subscript based setter

func fixFriday() {
    plan[.fri] = "Learn SwiftUI"
}

So there, we get all the good things of all three worlds! Enjoy!

A minimal implementation of State and Binding with Swift

2022-12-27T20:10:00+00:00

One of my most favorite thing about SwiftUI is neither the declarative API nor the mystical fancy syntax but rather the philosophy of one directional flow of data and event. I’ve been trying to put that philosophy into practice for quite a while now with whatever framework I use.

The core concepts of the philosophy are basically thinking about who owns the data and who handles the events. And once you’ve figured out these decisions then the rest of the plumbing can be done with whatever tools you have handy. Could be RxSwift, Combine, completion handlers, notification center or even KVO. The cherry on the top could be fancy syntactic sugar with @propertyWrapper or @dynamicMemberLookup.

From SwiftUI I like the idea of using @State and @Binding to give a clear hint on who owns the data and who is just borrowing it. With that in mind I came up with this minimal State and Binding constructs:

@dynamicMemberLookup
class Variable<T> {
    var value: T {
        get { sub.value }
        set { sub.value = newValue }
    }
    
    var stream: AnyPublisher<T, Never> {
        return sub.eraseToAnyPublisher()
    }
    
    subscript<P>(dynamicMember keyPath: WritableKeyPath<T, P>) -> P {
        get { sub.value[keyPath: keyPath] }
        set { sub.value[keyPath: keyPath] = newValue }
    }
    
    fileprivate let sub: CurrentValueSubject<T, Never>
    
    init(_ sub: CurrentValueSubject<T, Never>) {
        self.sub = sub
    }
}

class State<T>: Variable<T> {
    var binding: Binding<T> {
        return Binding(self)
    }

    init(_ value: T) {
        super.init(CurrentValueSubject(value))
    }
}

class Binding<T>: Variable<T> {
    init(_ state: State<T>) {
        super.init(state.sub)
    }
}

The idea is that the State can be initialized with the data to indicate that it owns the data, while Binding can not. So the only way to create a Binding object is from a State. All the common functionality like reading and writing data is moved to a shared base class Variable which apart from exposing the value also provides a stream that be used to listen to changes and also supports dynamicMemberLookup to provide a shortcut to accessing properties of the wrapped type.

Here’s an example to illustrate the usage:

struct Story {
    var text: String?
}

class ViewController: UIViewController {
    // owns the data
    let story = State(Story())

    let label = UILabel(frame: .zero)
    var cancellables = Set<AnyCancellable>()

    override func viewDidLoad() {
        super.viewDidLoad()
        playground.run()
        view.addSubview(label)
        label.backgroundColor = .white
        label.textAlignment = .center
        view.backgroundColor = .gray

        // update the word count at every keystroke
        story.stream
            .map(\.text)
            .map { $0?.count ?? 0}
            .map { "Words: \($0)" }
            .assign(to: \.title, on: self)
            .store(in: &cancellables)
        
        navigationItem.rightBarButtonItem = UIBarButtonItem(barButtonSystemItem: .edit,
                                                            target: self,
                                                            action: #selector(onEdit))
    }
    
    override func viewDidLayoutSubviews() {
        super.viewDidLayoutSubviews()
        label.frame = CGRect(origin: .zero, size: CGSize(width: view.bounds.width - 40,
                                                         height: 100))
        label.center = view.center
    }
    
    override func viewDidAppear(_ animated: Bool) {
        super.viewDidAppear(animated)
        // update the content whenever view is displayed
        // notice that we're not using:
        //      label.text = story.value.text
        label.text = story.text
    }
    
    @objc func onEdit() {
        let textEditVwCtrl = TextEditViewController(story: story.binding)
        navigationController?.pushViewController(textEditVwCtrl, animated: true)
    }
}

class TextEditViewController: UIViewController, UITextViewDelegate {
    // borrows the data with a read-write access
    private let story: Binding<Story>

    init(story: Binding<Story>) {
        self.story = story
        super.init(nibName: nil, bundle: nil)
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    let textVw = UITextView(frame: .zero)

    override func viewDidLoad() {
        super.viewDidLoad()
        view.addSubview(textVw)
        textVw.text = story.text
        textVw.delegate = self
        title = "Story Editor"
        view.backgroundColor = .white
    }

    override func viewDidLayoutSubviews() {
        super.viewDidLayoutSubviews()
        textVw.frame = view.bounds
    }

    override func viewDidAppear(_ animated: Bool) {
        super.viewDidAppear(animated)
        textVw.becomeFirstResponder()
    }

    func textViewDidChange(_ textView: UITextView) {
        // notice that we're not using:
        //      story.value.text = textView.text
        story.text = textView.text
    }
}

I’ve a feeling the syntax could be made even fancier with the help of @propertyWrapper to look something like what SwiftUI does with @State var story = Story() and @Binding var storyCopy = $story but maybe I’ll leave that as the task for the reader.

Adapters in Swift

2022-12-24T13:10:00+00:00

Any professional software developer knows that the simplest solution in building software is sometimes just to wrap an existing solution with the expected client interface and be done with it. This pattern is so common they even gave it a name, Adapter Pattern.

In such a pattern there are mostly three pieces in play, the Adapter, Adaptee and the Client. With Adaptee being the existing solution out there that we wish to wrap and reuse, and Client being the user of the API, the only moving part in the equation is then the Adapter, which is the only thing in focus.

If you would like to do it the hard way, you can obviously painfully implement every piece of the interface in terms of the internal implementation details provided by the Adaptee.

To illustrate, if we wanted to wrap the CurrentValueSubject from Combine framework into something which we would like to call as Variable with the point being that we don’t want to bother our client with any Error type.

We could simply create our Adapter as:

class Variable<T> {
    private let subject: CurrentValueSubject<T, Never>
    
    var value: T {
        get { subject.value }
        set { subject.value = newValue }
    }
    
    var stream: AnyPublisher<T, Never> {
        return subject.eraseToAnyPublisher()
    }
    
    init(_ initValue: T) {
        self.subject = CurrentValueSubject(initValue)
    }
}

Here’s one usage of this Adapter

class Client {
    var cancellable: AnyCancellable?
    let variable = Variable(0)
    
    init() {
        cancellable = variable.stream.sink { 
            print("recv: \($0)") 
        }
    }

    func run() {
        print("before: \(variable.value)")
        variable.value = 10
        print("after: \(variable.value)")
    }
}

But this usage becomes verbose very easily when we start using more complex data structures, like:

struct User {
    var fullName: String {
        [firstName, lastName].joined(separator: " ")
    }
    var firstName = "Steve"
    var lastName = "Jobs"
}

class Client {
    var cancellable: AnyCancellable?
    let user = Variable(User())
    
    init() {
        cancellable = user.stream.sink { 
            print("recv: \($0.fullName)") 
        }
    }

    func run() {
        print("before: \(user.value.fullName)")
        user.value.lastName = "Carell"
        print("after: \(user.value.fullName)")
    }
}

Notice the verbosity with user.value.xxx usage. Wouldn’t it be nice if we could simply access the property with user.xxx

In Objective-C this pattern could be simplified by implementing with built-in runtime behavior like Message Forwarding. But even in Swift there’s another way to implement this pattern, using the @dynamicMemberLookup.

With @dynamicMemberLookup compiler can provide direct access to the properties of an object via KeyPath<Root, Value>, where Root is the receiver and Value is the property. So we can rewrite our Adapter as:

@dynamicMemberLookup
class Variable<T> {
    subscript<U>(dynamicMember keyPath: KeyPath<T, U>) -> U {
        return subject.value[keyPath: keyPath]
    }

    subscript<U>(dynamicMember keyPath: WritableKeyPath<T, U>) -> U {
        get { subject.value[keyPath: keyPath] }
        set { subject.value[keyPath: keyPath] = newValue }
    }
    
    var stream: AnyPublisher<T, Never> {
        return subject.eraseToAnyPublisher()
    }

    private let subject: CurrentValueSubject<T, Never>

    init(_ startValue: T) {
        self.subject = CurrentValueSubject(startValue)
    }
}

And with this our call site becomes a lot cleaner

class Client {
    var cancellable: AnyCancellable?
    let user = Variable(User())
    
    init() {
        cancellable = user.stream.sink { 
            print("recv: \($0.fullName)") 
        }
    }

    func run() {
        print("before: \(user.fullName)")
        user.lastName = "Carell"
        print("after: \(user.fullName)")
    }
}

If we further wish to make our call site even fancier, we can add support for @propertyWrapper

@dynamicMemberLookup @propertyWrapper
class Variable<T> {
    var wrappedValue: T {
        get { subject.value }
        set { subject.value = newValue }
    }
    
    subscript<U>(dynamicMember keyPath: KeyPath<T, U>) -> U {
        return subject.value[keyPath: keyPath]
    }

    subscript<U>(dynamicMember keyPath: WritableKeyPath<T, U>) -> U {
        get { subject.value[keyPath: keyPath] }
        set { subject.value[keyPath: keyPath] = newValue }
    }
    
    var stream: AnyPublisher<T, Never> {
        return subject.eraseToAnyPublisher()
    }
    
    private let subject: CurrentValueSubject<T, Never>
    
    init(wrappedValue value: T) {
        self.subject = CurrentValueSubject(value)
    }
}

There’s is lot of hidden magic here that only happens when you know the secret code. The code here is to provide a property called wrappedValue and an initializer called init(wrappedValue:). With that in place our call site looks even prettier.

class Client {
    @Variable var user: User = User()

    func run() {
        print("before: \(user.fullName)")
        user.lastName = "Carell"
        print("after: \(user.fullName)")
    }
}

To add back the support to the stream, we can use another secret code, that is providing a property called projectedValue

@dynamicMemberLookup @propertyWrapper
class Variable<T> {
    var projectedValue: AnyPublisher<T, Never> {
        return subject.eraseToAnyPublisher()
    }
    
    var wrappedValue: T {
        get { subject.value }
        set { subject.value = newValue }
    }
    
    subscript<U>(dynamicMember keyPath: KeyPath<T, U>) -> U {
        return subject.value[keyPath: keyPath]
    }

    subscript<U>(dynamicMember keyPath: WritableKeyPath<T, U>) -> U {
        get { subject.value[keyPath: keyPath] }
        set { subject.value[keyPath: keyPath] = newValue }
    }
    
    private let subject: CurrentValueSubject<T, Never>
    
    init(wrappedValue value: T) {
        self.subject = CurrentValueSubject(value)
    }
}

This can add another super power to our Adapter that can be accessed via the magical $ sign

class Client {
    var cancellable: AnyCancellable?
    @Variable var user: User = User()

    init() {
        cancellable = $user.sink { 
            print("recv: \($0.fullName)") 
        }
    }

    func run() {
        print("before: \(user.fullName)")
        user.lastName = "Carell"
        print("after: \(user.fullName)")
    }
}

Conclusion

As we just saw Swift has evolved long since the days of being strict compiled language with all rules being embeded within some contracts bounded by Protocol. There is a lot of magical stuff that can be achieved with things that you to must first learn from elsewhere, like the $ access via projectedValue or the magical KeyPath based access. But we can use this to simplify our APIs and make everyone a bit more happier.

Simple UIViewController Transitions

2022-12-14T16:00:00+00:00

When it comes to UIViewController transitions there are many articles and videos out there that talk more in depth about the sophisticated solutions provided by UIKit and that is probably for the good reason that those UIKit APIs are very complicated to understand. But UIKit also provides a simpler API for simpler needs. And I think nobody talks enough about it either because it is so simple that everyone assumes that everyone knows how it works or that it “just” works somehow that nobody cares about the details of how it’s intended to be used.

What API am I talking about? I’m talking about this one liner:

func transition(
    from fromViewController: UIViewController,
    to toViewController: UIViewController,
    duration: TimeInterval,
    options: UIView.AnimationOptions = [],
    animations: (() -> Void)?,
    completion: ((Bool) -> Void)? = nil
)

If used incorrectly it might either just emit a warning on the console:

Unbalanced calls to begin/end appearance transitions for <MyViewController>

Or throw an exception at runtime and crash your app:

Terminating app due to uncaught exception 'NSInvalidArgumentException', 
reason: 'Children view controllers <ViewController> and <ViewController>
must have a common parent view controller when calling 
-[UIViewController transitionFromViewController:toViewController:duration:options:animations:completion:]'

Let’s build a demo!

What we want to make is a simple container view controller that has a single child view controller that can be replaced with some basic transition. Let’s begin.

First let’s see how the ContainerViewController should be used. So if we have a so called ContainerViewController then we should be able to init it and assign the content to it.

For example, we could use a Timer to periodically cycle through a bunch of children.

let vwCtrls = (0..<5).map { SomeViewController(desc: "Child \($0)") }
let containerVwCtrl = ContainerViewController(contentViewController: vwCtrls[selectedIndex])
let timer = Timer.scheduledTimer(
    timeInterval: 3,
    target: self, selector: #selector(displayNext),
    userInfo: nil, repeats: true
)

@objc func displayNext() {
    selectedIndex = (selectedIndex + 1) % vwCtrls.count
    containerVwCtrl.contentViewController = vwCtrls[selectedIndex]
}

Or call the animated variant, one we are more interested in

@objc func displayNext() {
    selectedIndex = (selectedIndex + 1) % vwCtrls.count
    containerVwCtrl.set(contentViewController: vwCtrls[selectedIndex], animationDuration: 1.0)
}

The docs on creating our ContainerViewController are pretty clear. Comes even with a snippet, we can simply copy-paste them:

class ContainerViewController: UIViewController {
      private func add(viewController: UIViewController) {
        addChild(viewController)
        view.addSubview(viewController.view)
        view.addConstraints(to: viewController.view, insets: contentEdgeInsets)
        viewController.didMove(toParent: self)
    }

    private func remove(viewController: UIViewController) {
        viewController.willMove(toParent: nil)
        viewController.view.removeFromSuperview()
        viewController.removeFromParent()
    }
}

Now since we want our container to always start with a child what better place than to ask than in the init

class ContainerViewController: UIViewController {
    private var childVwCtrl: UIViewController

    init(contentViewController: UIViewController) {
        childVwCtrl = contentViewController
        super.init(nibName: nil, bundle: nil)
        add(viewController: contentViewController)
    }
  // ...
}

So far so good. Next we want to expose methods to be able to reset the child

class ContainerViewController: UIViewController {
      var contentViewController: UIViewController {
        get { childVwCtrl }
        set { set(contentViewController: newValue, animationDuration: nil) }
    }

    func set(contentViewController toVwCtrl: UIViewController, animationDuration: Double?) {
      // TODO: stuff goes here ...
      childVwCtrl = toVwCtrl
    }
}

Since we want to be able to change the child with or without animation. If the animationDuration is provided we assume the change is animated otherwise not. Filling the non-animated part is easy, we just remove the last child and add the new child

class ContainerViewController: UIViewController {
    func set(contentViewController toVwCtrl: UIViewController, animationDuration: Double?) {
        let fromVwCtrl = childVwCtrl

        guard let duration = animationDuration else {
            remove(viewController: fromVwCtrl)
            add(viewController: toVwCtrl)
            childVwCtrl = toVwCtrl
            return
        }
        // ...
    }
}

Coming to animated transition, we could use the API simply as:

class ContainerViewController: UIViewController {
    func set(contentViewController toVwCtrl: UIViewController, animationDuration: Double?) {
        let fromVwCtrl = childVwCtrl

        guard let duration = animationDuration else {
            remove(viewController: fromVwCtrl)
            add(viewController: toVwCtrl)
            childVwCtrl = toVwCtrl
            return
        }

        add(viewController: toVwCtrl)
        fromVwCtrl.view.alpha = 1.0
        toVwCtrl.view.alpha = 0.0
        transition(
            from: fromVwCtrl,
            to: toVwCtrl,
            duration: duration,
            options: [.curveEaseOut],
            animations: {
                fromVwCtrl.view.alpha = 0.0
                toVwCtrl.view.alpha = 1.0
            },
            completion: { _ in
                self.remove(viewController: fromVwCtrl)
                self.childVwCtrl = toVwCtrl
            }
        )
    }        
}

But this doesn’t work. When run it emits a warning to the console.

Unbalanced calls to begin/end appearance transitions for Child 1.

Let’s see what the docs have to say about it.

This method adds the second view controller’s view to the view hierarchy and then performs the animations defined in your animations block. After the animation completes, it removes the first view controller’s view from the view hierarchy.

Hmm, doesn’t seems to add much. Let’s also read the docs for NSViewController because why not

This method adds the view in the toViewController view controller to the superview of the view in the fromViewController view controller. Likewise, this method removes the fromViewController view from the parent view controller’s view hierarchy at the appropriate time. It is important to allow this method to add and remove these views.

Okay turns out this doc gives a bit more implementation detail. One interesting extra fact we learn here is that the view add and remove operations are called internally at the appropriate time (wonder when that might be). But now at least we know that we just need to add and remove the view controllers and let the API handle the add-remove of the views.

addChild(toVwCtrl)
toVwCtrl.didMove(toParent: self)

fromVwCtrl.view.alpha = 1.0
toVwCtrl.view.alpha = 0.0
transition(
    from: fromVwCtrl,
    to: toVwCtrl,
    duration: duration,
    options: [.curveEaseOut],
    animations: {
        fromVwCtrl.view.alpha = 0.0
        toVwCtrl.view.alpha = 1.0
    },
    completion: { _ in
        fromVwCtrl.willMove(toParent: nil)
        fromVwCtrl.removeFromParent()
        self.childVwCtrl = toVwCtrl
    }
)

So our warning is gone, but now the constraints are gone too! So the next child becomes full screen, or more specifically the size of the ContainerViewController

We can try adding the constraints back in the animation block.

addChild(toVwCtrl)
toVwCtrl.didMove(toParent: self)

fromVwCtrl.view.alpha = 1.0
toVwCtrl.view.alpha = 0.0
transition(
    from: fromVwCtrl,
    to: toVwCtrl,
    duration: duration,
    options: [.curveEaseOut],
    animations: {
        self.view.addConstraints( to: toVwCtrl.view, insets: self.contentEdgeInsets)
        fromVwCtrl.view.alpha = 0.0
        toVwCtrl.view.alpha = 1.0
    },
    completion: { _ in
        fromVwCtrl.willMove(toParent: nil)
        fromVwCtrl.removeFromParent()
        self.childVwCtrl = toVwCtrl
    }
)

This seems to work as expected.

But since we don’t have control over adding the view, we can’t be sure if this would work all the time. Let’s read up the more docs to see if we can find any more information.

addChild(_ childController: UIViewController)

This method creates a parent-child relationship between the current view controller and the object in the childController parameter. This relationship is necessary when embedding the child view controller’s view into the current view controller’s content. If the new child view controller is already the child of a container view controller, it is removed from that container before being added.

removeFromParent()

This method is only intended to be called by an implementation of a custom container view controller. If you override this method, you must call super in your implementation.

willMove(toParent parent: UIViewController?)

If you are implementing your own container view controller, it must call the willMove(toParent:) method of the child view controller before calling the removeFromParent() method, passing in a parent value of nil.

didMove(toParent parent: UIViewController?)

If you are implementing your own container view controller, it must call the didMove(toParent:) method of the child view controller after the transition to the new controller is complete or, if there is no transition, immediately after calling the addChild(_:) method.

It seems the only new thing here is that didMove(toParent:) has to be called after the transition. So the correct implementation should be following, although I don’t find any visual difference

addChild(toVwCtrl)
fromVwCtrl.willMove(toParent: nil)
fromVwCtrl.view.alpha = 1.0
toVwCtrl.view.alpha = 0.0
transition(
    from: fromVwCtrl,
    to: toVwCtrl,
    duration: duration,
    options: [.curveEaseOut],
    animations: {
        self.view.addConstraints( to: toVwCtrl.view, insets: self.contentEdgeInsets)
        fromVwCtrl.view.alpha = 0.0
        toVwCtrl.view.alpha = 1.0
    },
    completion: { _ in
        toVwCtrl.didMove(toParent: self)
        fromVwCtrl.removeFromParent()
        self.childVwCtrl = toVwCtrl
    }
)

Let’s get rid of AutoLayout

This API is pretty nice for simpler transitions and maybe excellent if you don’t have to bother with auto layout. Personally I find animating constraints always not so much fun.

For example making a slide in/out transition is pretty easy to build using just frame

func set(contentViewController toVwCtrl: UIViewController, animationDuration: Double?) {
    let fromVwCtrl = childVwCtrl

    guard let duration = animationDuration else {
        remove(viewController: fromVwCtrl)
        add(viewController: toVwCtrl)
        childVwCtrl = toVwCtrl
        return
    }

    addChild(toVwCtrl)
    toVwCtrl.view.frame = contentFrame
    fromVwCtrl.willMove(toParent: nil)
    beginAnimation(fromView: fromVwCtrl.view, toView: toVwCtrl.view)
    transition(
        from: fromVwCtrl,
        to: toVwCtrl,
        duration: duration,
        options: [.curveEaseOut],
        animations: {
            self.endAnimation(
                fromView: fromVwCtrl.view,
                toView: toVwCtrl.view
            )
        },
        completion: { _ in
            toVwCtrl.didMove(toParent: self)
            fromVwCtrl.removeFromParent()
            self.childVwCtrl = toVwCtrl
        }
    )
}

private func beginAnimation(fromView: UIView, toView: UIView) {
    fromView.transform = CGAffineTransform.identity
    toView.transform = CGAffineTransform(translationX: 500, y: 0)
}

private func endAnimation(fromView: UIView, toView: UIView) {
    fromView.transform = CGAffineTransform(translationX: -500, y: 0)
    toView.transform = CGAffineTransform.identity
}

Or even go crazy with some mind blowing 3D transformations

    private func transform(angle: Double) -> CATransform3D {
        let angleRads = angle * .pi / 180.0
        var transform = CATransform3DIdentity
        transform.m34 = 1.0 / -100
        transform = CATransform3DRotate(transform, angleRads, 1, 0, 0)
        transform = CATransform3DTranslate(transform, 0, 0, -10)
        return transform
    }

    private func beginAnimation(fromView: UIView, toView: UIView) {
        fromView.layer.transform = CATransform3DIdentity
        toView.layer.transform = transform(angle: -90)
    }

    private func endAnimation(fromView: UIView, toView: UIView) {
        fromView.layer.transform = transform(angle: 90)
        toView.layer.transform = CATransform3DIdentity
    }

If this seems interesting to you I wrote about 3D transformation in more details some time back, go check it out.

Source

The code for this experiment is available at: https://gist.github.com/chunkyguy/39a8e0c2151e0b13955141544627ec46

Data-Driven UI with UIKit

2022-12-12T20:06:00+00:00

Preserving the theme of simplicity let’s make use of one of my favorite method from UIKit - layoutSubviews and build a data driven UI system.

Every UI framework comes with three things:

A tree with several nodes.
A renderer that visits every node in that tree and calls draw() on them.
An infinite loop that keeps the renderer visiting the root node of the tree in a loop, preferably 60 times per second.

Although I haven’t seen the source code but I assume UIKit is probably no different. Now, eventually calling draw() becomes redundant if nothing has actually changed in that node since the last visit. So I imagine a sort of flag isDirty: Bool is kept per node which is then set whenever a node is required to be drawn.

If my assumptions are true than deep within UIKit there’s a draw() method that looks something like:

class Node {
  var isDirty = false
  
  func draw() {
    guard isDirty else { return }
    layoutSubviews()
    // do more stuff ...
    isDirty = false
  }
  
  func setNeedsLayout() {
    // will draw at next screen refresh
    isDirty = true
  }
  
  func layoutIfNeeded() {
    isDirty = true
    draw()
  }
  
  func layoutSubviews() {
    // to be subclassed
  }
}

This means that with proper use of setNeedsLayout, layoutIfNeeded and layoutSubviews we can come up with a decent data driven layout system. With that in mind let’s try to rebuild the classic MoveMe example.

MoveMe

If you’re not familiar with the exercise, MoveMe example is like the “hello world!” for UI frameworks. It requires placing a small card view with some default values. At finger down the color of the card changes and the card scales up a bit with animation. Then the card can be dragged around while the finger is still down. Some time later when the finger is lifted the color and the size of the card resets.

Layout System

The system we want to build is similar to the trend of these days, a data driven UI, where we only need to take care of updating the data and the view would automatically update. Our layout system is based on the idea that UIKit calls layoutSubviews whenever the UIView is marked as dirty. So if we have a struct model data in our UIView subclass, then we can use the didSet property observer to invoke setNeedsLayout whenever the model data changes. Then it would mean that at the next draw cycle our layoutSubviews would get invoked. So we can safely keep all of our UI updates in layoutSubviews

struct Colors {
  static var normal = UIColor.blue
  static var selected = UIColor.red
}

class MoveMeView: UIView {
    struct Model {
    var color = Colors.normal
    var scale: CGFloat
    var position = CGPoint.zero
  }

  private let cardView = UIView(frame: CGRect(origin: .zero, 
                                              size: CGSize(width: 100, height: 100)))

  private var model: Model! {
    didSet { setNeedsLayout() }
  }

  override func layoutSubviews() {
    super.layoutSubviews()
    if model == nil {
      model = Model(color: .blue, scale: 1.0, position: center)
    }
    
    cardView.backgroundColor = model.color
    cardView.center = model.position
    cardView.transform = CGAffineTransform(scaleX: model.scale, y: model.scale)
  }
}

Notice that we are initializing the model when the first time layoutSubviews is invoked, this is because the UIKit also calls layoutSubviews as part of building the internal render tree. And values like center of a UIView are not known at init time when using auto layout so we can build our initial data the first time layoutSubviews is invoked.

With that in place, any update to our model data would now trigger layoutSubviews at next draw cycle.

model.color = Colors.normal
model.scale = 1.2

So there we have our UI = f(data) pipeline. This would also work nicely for things where we get a continuous stream of events, like say a callback handler of a drag gesture

extension CGPoint {
  static func add(_ left: CGPoint, _ right: CGPoint) -> CGPoint {
    return CGPoint(x: left.x + right.x, y: left.y + right.y)
  }
}

let translation = panGestureRecognizer.translation(in: self)
model.position = CGPoint.add(translation, model.position)
panGestureRecognizer.setTranslation(.zero, in: self)

Animation is a bit tricky but if we update properties that are animatable within the UIView.animate block it should work, like the transform property in our case

model.scale = 1.2
UIView.animate(withDuration: 0.3) {
  self.layoutIfNeeded()
}

Another way to think about it is that UIKit provides a way to perform implicit animation for a lot of properties, we just need to provide a final value for them and UIKit does the rest.

This code above is equivalent to

let scale = 1.2
UIView.animate(withDuration: 0.3) {
  self.cardView.transform = CGAffineTransform(scaleX: scale, y: scale)
}

With that we can finish off by adding a UIPanGestureRecognizer to make the cardView move with user interaction complete with animations.

class MoveMeView: UIView {
  // ...

  override init(frame: CGRect) {
    super.init(frame: frame)
    addSubview(cardView)

    let dragGesture = UIPanGestureRecognizer(target: self, action: #selector(onDrag))
    addGestureRecognizer(dragGesture)
  }

  @objc func onDrag(_ panGestureRecognizer: UIPanGestureRecognizer) {
    switch panGestureRecognizer.state {
    case .began:
      model.color = Colors.normal
      model.scale = 1.2
      UIView.animate(withDuration: 0.3, delay: 0, options: [.beginFromCurrentState]) {
        self.layoutIfNeeded()
      }
      
    case .changed:
      model.color = Colors.selected
      let translation = panGestureRecognizer.translation(in: self)
      model.position = CGPoint.add(translation, model.position)
      panGestureRecognizer.setTranslation(.zero, in: self)
      
    case .ended:
      model.color = Colors.normal
      model.scale = 1.0
      UIView.animate(withDuration: 0.3, delay: 0, options: [.beginFromCurrentState]) {
        self.layoutIfNeeded()
      }

    default:
      model.color = Colors.normal
      model.scale = 1.0
    }
  }
}

Swift async-await vs closures

2022-12-06T09:09:00+00:00

Swift await works by capturing the context and suspending the execution until the called async method returns. Another thing that works similarly by capturing the surrounding context is an escaping closure. So async-await calls can be imagined as equivalent to escaping closure. Whenever you see a method with async mentally replace that method with a escaping completion handler.

func run() async
func run(_ completion: @escaping () -> Void)

Examples

A simple scenario with equivalent code

class Foo {
  func before() {}
  func after() {}

  func doStuff() async {}
  func doStuff(_ completion: @escaping () -> Void) {}
}

extension Foo {
  func run() async {
    before()
    await doStuff()
    after()
  }
}

extension Foo {
  func run(_ completion: @escaping () -> Void) {
    before()
    doStuff {
      self.after()
      completion()
    }
  }
}

And then it only makes sense how the return values work

func doStuff() async -> Int

let ret = await doStuff()
print("\(ret)")

func doStuff(_ completion: @escaping (Int) -> Void)

doStuff { ret in
    print("\(ret)")
}

Or the error propagation

func div(_ a: Int, _ b: Int) async throws -> Double {
  if b == 0 {
    throw FooError.divideByZero
  }
  return Double(a) / Double(b)
}

do {
  let ret = try await div(1, 0)
  print("\(ret)")
} catch {
  print("\(error)")
}

func div(_ a: Int, _ b: Int, _ completion: @escaping (Double) -> Void) throws {
  if b == 0 {
    throw FooError.divideByZero
  }
  completion(Double(a) / Double(b))
}

do {
  try div(1, 0) { ret in
    print("\(ret)")
  }
} catch {
  print("\(error)")
}

Converting async to sync

Notice how the async call naturally propagates to the callee. So a call to doStuff() async makes run() async as well. This also makes sense for completion handers in most cases. And if we wish to not propagate the asynchronous behavior, or in other words, we wish to convert an async method into a sync method, we need to use a Task which takes in a completion handler and is equivalent to wrapping within DispatchQueue.async { ... }

func run() {
  before()
  Task {
    await doStuff()
    after()
  }
}

func run() {
  before()
  DispatchQueue.global().async {
    self.doStuff {
      self.after()
    }
  }
}

Chaining calls

If we do wish to call async methods one after the other, the mental model remains the same

func doStuff() async {}
func doMoreStuff() async {}

before()
await doStuff()
await doMoreStuff()
after()

func doStuff(_ completion: @escaping () -> Void) {}
func doMoreStuff(_ completion: @escaping () -> Void) {}

before()
doStuff {
  self.doMoreStuff {
    self.after()
  }
}

But if the tasks need to be run in parallel the async-await provides a construct with async let

func run() async {
  before()
  async let task1: Void = doStuff()
  async let task2: Void = doMoreStuff()
  _ = await [task1, task2]
  after()
}

This is then equivalent to using DispatchGroup

func run(_ completion: @escaping () -> Void) {
  before()
  let group = DispatchGroup()
  group.enter()
  doStuff { group.leave() }
  group.enter()
  doMoreStuff { group.leave() }
  group.notify(queue: DispatchQueue.global()) {
    self.after()
    completion()
  }
}

Conclusion

Having a better mental model for async-await helps with appreciating what sort of pitfalls it saves us from, and also how to migrate from completion handlers to async await.

Introducing Simple Layout Engine

2022-11-27T16:00:00+00:00

Note: This is a Swift rewrite of the original article published in 2020

I love Auto Layout. It helps a lot when designing complex UI. But there are times when the UI is very simple and Auto Layout might feel a bit overkill, while other times the UI might be a bit too complex and Auto Layout actually starts affecting the app performance. Before auto layout there was another technique to creating UI, it’s called Springs and Struts (also known as Manual Layout to be in contrast with Auto Layout). I like Manual Layout a lot as well for its simplicity. Like with every other tool, there are trade-offs when selecting the best tool for the job, and it also applies when selecting Auto Layout vs Manual Layout.

The good thing is that, the Auto Layout has not been designed as an alternative to Manual Layout, rather more like an supplement. Where instead of us having to calculate the frame, we start with a CGRect.zero and let the Auto Layout fill in the frame value later. Most of the time it’s wonderful and doesn’t impact our flow. Other times we might have to wait for the layout pass run to read back the calculated frame values

// let Auto layout calculate the frame values
DispatchQueue.main.async {
  // start using the frame values for something else.
}

I often wish if the Auto Layout were not that tightly coupled with UIKit. In a sense I wish I could just run Auto Layout without a UIKit draw layout pass. This inspired me to take another take of building UIs without Auto Layout with something I’d like to call as Simple Manual Layout.

Inspiration

The inspiration is from how UIBarButtonItem works with UIToolbar or UINavigationBar. If we wanted to build a UI like

We would create a UIToolBar and add a bunch of UIBarButtonItem

  let toolbar = UIToolbar(frame: toolbarFrame)
  let playButton = UIBarButtonItem(systemItem: .play)
  let pauseButton = UIBarButtonItem(systemItem: .pause)
  let rewindButton = UIBarButtonItem(systemItem: .rewind)
  let forwardButton = UIBarButtonItem(systemItem: .fastForward)
  let spaceButton = UIBarButtonItem(systemItem: .flexibleSpace)
  toolbar.items = [
    spaceButton,
    rewindButton, spaceButton,
    playButton, spaceButton,
    pauseButton, spaceButton,
    forwardButton, spaceButton,
  ]

The interesting element here is .flexibleSpace. Which is documented as “Blank space to add between other items. The space is distributed equally between the other items.”. Similarly, there’s another one called .fixedSpace which is documented as “Blank space to add between other items. Only the width property is used when this value is set.”.

I think this approach could be used to build a layout engine which is very simple in terms of mental model but can be used to build as sophisticated layouts as we’d want.

Simple Layout Engine

With that design in mind we can build out layout engine. If there is a class Item which is a placeholder for a UIView and another class Layout that takes in one or more of these Item and immediately calculates the frame of the every Item. Then we can use the calculated frame value when constructing our UIView objects.

So to create a full screen subview we should be able to create as:

let layout = Layout(parentFrame: frame, direction: .column)
let mainItem = try layout.add(item: .flexible)
let redView = SLECreateView(try mainItem.frame(), .red)
addSubview(redView)

private func SLECreateView(_ frame: CGRect, _ color: UIColor) -> UIView {
  let view = UIView(frame: frame)
  view.backgroundColor = color
  return view
}

And a 2 subview layout, where the top is flexible and bottom is fixed

let layout = Layout(parentFrame: frame, direction: .column)
try layout.add(item: .flexible)
try layout.add(item: .height(200))

let topFrame = try layout.frame(at: 0)
let bottomFrame = try layout.frame(at: 1)

addSubview(SLECreateView(topFrame, .red))
addSubview(SLECreateView(bottomFrame, .blue))

A more interesting layout would be where we have a column that contains a row.

let mainLayout = Layout(parentFrame: frame, direction: .column)
try mainLayout.add(items: [.flexible, .height(44), .height(200)])

let headerFrame = try mainLayout.frame(at: 0)
let toolbarFrame = try mainLayout.frame(at: 1)
let footerFrame = try mainLayout.frame(at: 2)

addSubview(SLECreateView(headerFrame, .red))
addSubview(SLECreateView(toolbarFrame, .blue))
addSubview(SLECreateView(footerFrame, .yellow))

let contentLayout = Layout(parentFrame: footerFrame, direction: .row)
try contentLayout.add(items: [.flexible, .flexible])
let content1Frame = try contentLayout.frame(at: 0)
let content2Frame = try contentLayout.frame(at: 1)

addSubview(SLECreateView(content1Frame, .cyan))
addSubview(SLECreateView(content2Frame, .magenta))

Implementation details

The implementation of this layout engine turns out to be not as sophisticated. If we provide a Item which can have some properties fixed and others flexible.

public class Item {
    // no values fixed
    public static var flexible: Item { get }
    // partially fixed
    public static func width(_ value: CGFloat) -> Item
    public static func height(_ value: CGFloat) -> Item
    // all fixed
    public static func size(_ value: CGSize) -> Item
    // ...
}

So we can start with storing values as optional with flexible data as nil

public class Item {
  // ...

  public func frame() throws -> CGRect {
    return try rect.frame()
  }

  internal let originalWidth: CGFloat?
  internal let originalHeight: CGFloat?
  private let rect = Rect()

  private init(width: CGFloat?, height: CGFloat?) {
    originalWidth = width
    originalHeight = height
  }

  // called by layout engine
  func updateSize(value: CGFloat, 
                  in direction: Direction, 
                  parentSize: CGSize) { /* update rect */ }

  func updateOrigin(itemOrigin: CGPoint,
                    in direction: Direction, 
                    alignment: Alignment, 
                    parentFrame: CGRect) -> CGPoint { /* update rect */ }
}

And we can have the internal Rect as a bridge object which is read from Item and written by the Layout

private class Rect {
  internal private(set) var width: CGFloat?
  internal private(set) var height: CGFloat?
  private var x: CGFloat?
  private var y: CGFloat?

  // read back by Item
  func frame() throws -> CGRect {
    guard let originX = x, let originY = y, let width = width, let height = height else {
      throw LayoutError.itemIncomplete
    }
    return CGRect(x: originX, y: originY, width: width, height: height)
  }

  // set by layout engine
  func set(origin: CGPoint) {
    x = origin.x
    y = origin.y
  }

  // set by layout engine
  func set(size: CGSize) {
    width = size.width
    height = size.height
 }
}

Next, within Layout we have a mutable array that contains Item. And whenever a new item is added we recalculate the frames per item.

extension Layout {
  public func add(item: Item) throws {
    items.append(item)
    try updateFrames()
  }
}

If we calculate only for one direction, say vertical. The updateFrames might look something like:

private extension Layout {
  func updateFrames() throws {

    // calculate total flex height
    var totalFlexSpace = parentFrame.height
    var flexItems = 0
    for item in items {
      if let space = item.originalHeight {
        totalFlexSpace -= space
      } else {
        flexItems += 1
      }
    }

    // calculate height per flex item
    let itemSpace = totalFlexSpace / CGFloat(max(flexItems, 1))
    guard itemSpace >= 0 else {
      throw LayoutError.outOfSpace
    }

    // update final frames per item
    var itemOrigin = parentFrame.origin
    for item in items {
      item.updateSize(value: itemSpace,
                      in: .column,
                      parentSize: parentFrame.size)
      itemOrigin = item.updateOrigin(itemOrigin: itemOrigin,
                                     in: .column,
                                     alignment: alignment,
                                     parentFrame: parentFrame)
    }
  }
}

And similar calculations for width.

And now it doesn’t seem hard to imagine to support alignment for sub views (currently they are all set 0.0 or all aligned to .leading) with something like:

public enum Alignment {
  case leading
  case center
  case trailing
}

The Alignment value provides an offset while calculating the origin

private extension Alignment {
  func align(parent: CGFloat, item: CGFloat) -> CGFloat {
    switch self {
    case .leading: return 0
    case .trailing: return (parent - item)
    case .center: return (parent - item) / 2.0
    }
  }
}

So for example, vertically this would be

let offset = alignment.align(parent: parentFrame.height, item: rect.height)
y = parentFrame.origin.y + offset

References

Simple Layout Engine
There’s also an Objective-C implementation which I think has a much simpler implementation
And finally the original article

SwiftUI custom layout with Simple Layout Engine

2022-11-26T12:39:00+00:00

The maths required for SwiftUI custom layout reminds me of the days before AutoLayout and the constraints based system. The good thing is that Simple Layout Engine already provides a nice system to handle all the maths involved. To demonstrate I would use build the subset of the demo app from the WWDC session on this topic: Compose custom layouts with SwiftUI.

Problem

The idea is to have a container view similar to HStack where every child has the same width but with the exception that the width should be that of the maximum a child has. This is how HStack places the children by default

HStack {
    WLText("hi")
    WLText("!")
    WLText("beautiful")
    WLText("world")
}

Notice, all the children are have equal width but that isn’t the width of the max child but rather width = total width / number of children

What we actually want is to have something that looks like width = max(children.width), which would have all children having the width equal to whatever is the width of the beautiful text

BalancedHStack {
    WLText("hi")
    WLText("!")
    WLText("beautiful")
    WLText("world")
}

SwiftUI Layout System

SwiftUI provides a way to plug into the layout system to provide all the custom maths. For our case we can create a BalancedHStack that conforms to Layout protocol. The Layout protocol requires two methods:

sizeThatFits: To provide the total CGSize of the container to the system
placeSubviews: To update the positions of the children within the provided bounds

struct BalancedHStack: Layout {
  func sizeThatFits(proposal: ProposedViewSize,
                    subviews: Subviews,
                    cache: inout ()) -> CGSize {
    fatalError()
    // TODO
  }

  func placeSubviews(in bounds: CGRect,
                     proposal: ProposedViewSize,
                     subviews: Subviews,
                     cache: inout ()) {
    // TODO
  }
}

Other than that we also get an optional helper makeCache method to perform and store any layout math in a custom struct. We can use that to find the child with largest size and also store the distances between adjacent children (the gray spaces in the image above)

struct BalancedHStack: Layout {

  struct CacheData {
    let childSize: CGSize
    let distances: [CGFloat]
  }

  func makeCache(subviews: Subviews) -> CacheData {
    let subviewSizes = subviews.map { $0.sizeThatFits(.unspecified) }
    let width = subviewSizes.map { $0.width }.max() ?? 0
    let height = subviewSizes.map { $0.height }.max() ?? 0
    let distances: [CGFloat] = (0..<subviews.count).map { idx in
      guard idx < subviews.count - 1 else { return 0 }
      return subviews[idx].spacing.distance(to: subviews[idx + 1].spacing, along: .horizontal)
    }
    return CacheData(
      childSize: CGSize(width: width, height: height),
      distances: distances
    )
  }

  // ...
}

Calculating the total size of the container is easy. Every child is going to get the same width plus the total distance

  func sizeThatFits(proposal: ProposedViewSize,
                    subviews: Subviews,
                    cache: inout CacheData) -> CGSize {
    let totalDistance = cache.distances.reduce(0, +)
    return CGSize(
      width: cache.childSize.width * CGFloat(subviews.count) + totalDistance,
      height: cache.childSize.height
    )
  }

Next for layout, we can use the Simple Layout Engine to calculate the frames

  func placeSubviews(in bounds: CGRect,
                     proposal: ProposedViewSize,
                     subviews: Subviews,
                     cache: inout CacheData) {
    let layout = SLELayout(parentFrame: bounds, direction: .row, alignment: .center)
    do {
      var items: [SLEItem] = []
      for idx in 0..<subviews.count {
        items.append(try layout.add(item: .size(cache.childSize)))
        try layout.add(item: .width(cache.distances[idx]))
      }

      for (idx, subview) in subviews.enumerated() {
        subview.place(
          at: try items[idx].frame().origin,
          proposal: ProposedViewSize(cache.childSize)
        )
      }
    }
    catch { print("Unable to layout \(error)") }
  }

And we can even make it work along both axis by providing the direction with init

extension SLEDirection {
  var axis: Axis {
    switch self {
    case .row: return .horizontal
    case .column: return .vertical
    }
  }
}

struct BalancedStack: Layout {

  let direction: SLEDirection

  init(_ direction: SLEDirection) {
    self.direction = direction
  }

  struct CacheData {
    let childSize: CGSize
    let distances: [CGFloat]
  }

  func makeCache(subviews: Subviews) -> CacheData {
    let subviewSizes = subviews.map { $0.sizeThatFits(.unspecified) }
    let width = subviewSizes.map { $0.width }.max() ?? 0
    let height = subviewSizes.map { $0.height }.max() ?? 0
    let distances: [CGFloat] = (0..<subviews.count).map { idx in
      guard idx < subviews.count - 1 else { return 0 }
      return subviews[idx].spacing.distance(to: subviews[idx + 1].spacing, along: direction.axis)
    }
    return CacheData(
      childSize: CGSize(width: width, height: height),
      distances: distances
    )
  }

  func sizeThatFits(proposal: ProposedViewSize,
                    subviews: Subviews,
                    cache: inout CacheData) -> CGSize {
    let totalDistance = cache.distances.reduce(0, +)
    let containerWidth: CGFloat
    let containerHeight: CGFloat
    switch direction {
    case .row:
      containerWidth = cache.childSize.width * CGFloat(subviews.count) + totalDistance
      containerHeight = cache.childSize.height
    case .column:
      containerWidth = cache.childSize.width
      containerHeight = cache.childSize.height * CGFloat(subviews.count) + totalDistance
    }

    return CGSize(width: containerWidth, height: containerHeight)
  }

  func placeSubviews(in bounds: CGRect,
                     proposal: ProposedViewSize,
                     subviews: Subviews,
                     cache: inout CacheData) {
    let layout = SLELayout(parentFrame: bounds, direction: direction, alignment: .center)
    do {
      var items: [SLEItem] = []
      for idx in 0..<subviews.count {
        items.append(try layout.add(item: .size(cache.childSize)))
        try layout.add(item: .width(cache.distances[idx]))
      }

      for (idx, subview) in subviews.enumerated() {
        subview.place(
          at: try items[idx].frame().origin,
          proposal: ProposedViewSize(cache.childSize)
        )
      }
    }
    catch { print("Unable to layout \(error)") }
  }
}

This can then also be used do automatically adapt the layout based on the available size with ViewThatFits

struct TextList: View {
  var body: some View {
    WLText("hi")
    WLText("!")
    WLText("beautiful")
    WLText("world")
  }
}

ViewThatFits {
    BalancedStack(.row) {
        TextList()
    }

    BalancedStack(.column) {
        TextList()
    }
}

References

Using UnfairLock with Swift

2022-05-16T13:00:00+00:00

UnfairLock seems to be causing a lot of confusion for Swift developers. Every once in a while I run across some incorrect implementation that reads like:

var lock = os_unfair_lock_s()
os_unfair_lock_lock(&lock)

// code here ...

os_unfair_lock_unlock(&lock)

The confusion seems to arise from the fact that & is used to take address of a variable in C while it is used for in-out operation in Swift, which seem similar but are not. To make os_unfair_lock_lock work the lock location in memory needs to not move, which isn’t guaranteed by Swift. So the above code might or might not work as expected. To understand better we need to take a look at equivalent C code:

os_unfair_lock lock = OS_UNFAIR_LOCK_INIT;
os_unfair_lock_lock(&lock);

// code here ...

os_unfair_lock_unlock(&lock);

In C API os_unfair_lock is a struct defined as:

typedef struct os_unfair_lock_s { 
    // ...
} os_unfair_lock, *os_unfair_lock_t;

Since Swift does not provide a OS_UNFAIR_LOCK_INIT equivalent, we can not allocated os_unfair_lock in stack memory. Another alternative is to allocate in the heap memory

os_unfair_lock_t lock;
lock = malloc(sizeof(os_unfair_lock));
os_unfair_lock_lock(lock);

// code here ...

os_unfair_lock_unlock(lock);
free(lock);
lock = NULL;

The equivalent in Swift would be:

public typealias os_unfair_lock_t = UnsafeMutablePointer<os_unfair_lock_s>

var lock: os_unfair_lock_t // os_unfair_lock_t lock;
lock = UnsafeMutablePointer<os_unfair_lock_s>.allocate(capacity: 1) // lock = malloc(sizeof(os_unfair_lock));
lock.initialize(to: os_unfair_lock()) // memset(lock, 0, sizeof(os_unfair_lock));
os_unfair_lock_lock(lock)

// code here ...

os_unfair_lock_unlock(lock)
lock.deallocate() // free(lock);

Mixing Metal with UIScrollView

2021-05-16T13:00:00+00:00

About mixing UIScrollView with MTKView. This is the trick I learned from WWDC 2012 Enhancing User Experience with Scroll Views session that talks about mixing UIScrollView with OpenGL. The idea is to simply use the MTKView to render whatever metal content we would like and then use the UIScrollView to provide with the scrolling effect. The benefit of using UIScrollView is that we get exactly the same dragging and bounciness behavior that iOS users expect.

So, for example let’s say we have a MTKView that renders 3 cubes on screen and at any given time only of the cube is visible on screen. To prepare for scrolling we need to expose a CGPoint scrollOffset property that can scroll the content.

@interface CubeView : MTKView
@property (nonatomic) CGPoint scrollOffset;
@end

On top of it we also need to handle touch events for other things such as changing the background color at tap.

 - (void)touchesEnded:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event
{
  [self _randomizeColor];
}

Now since in our app, we only ever scroll horizontally, we can simply forward the x value to the Renderer

- (void)setScrollOffset:(CGPoint)scrollOffset
{
  _renderer.contentOffset = scrollOffset.x;
}

Then in the Renderer we can use this contentOffset value to calculate the view matrix

matrix_float4x4 modelMatrix = ...

float viewOffset = _contentOffset/view.bounds.size.width;
float viewX = (kMinX + viewOffset * (kMaxX - kMinX)) * -1;
matrix_float4x4 viewMatrix = matrix4x4_translation(viewX, 0.0, -8.0);

uniforms->modelViewMatrix = matrix_multiply(viewMatrix, modelMatrix);

We need to multiply with -1 because we need to move the content in the opposite direction of the scroll. Remember the contentOffset gives a increasing +ve value from 0 as we go towards right, while the content is actually moving left.

Next we need to actually add the UIScrollView. The simplest way could be to just add a UIScrollView on top of CubeView and use the UIScrollViewDelegate to forward the contentOffset.

- (void)viewDidLoad
{
  [super viewDidLoad];
  
  _cubeView = (CubeView *)self.view;

  CGRect cubeVwFrame = [_cubeView bounds];
  CGSize contentSize = CGSizeMake(CGRectGetWidth(cubeVwFrame) * 2, CGRectGetHeight(cubeVwFrame));
  UIScrollView *scrollView = [[UIScrollView alloc] initWithFrame:cubeVwFrame];
  scrollView.contentSize = contentSize;
  scrollView.showsHorizontalScrollIndicator = NO;
  scrollView.delegate = self;
  [self.view addSubview:scrollView];
}

- (void)scrollViewDidScroll:(UIScrollView *)scrollView
{
  _cubeView.scrollOffset = scrollView.contentOffset;
}

But remember we would like to handle the touch events on the CubeView for updating the background color. So this solution won’t work since UIScrollView is going to consume all the touch events. The solution then is to not let the UIScrollView be part of the responder chain but still be able to use the gesture recognizers of UIScrollView. One way to achieve this is by using a placeholder view.

 - (void)viewDidLoad
{
  [super viewDidLoad];
  
  _cubeView = (CubeView *)self.view;

  CGRect cubeVwFrame = [_cubeView bounds];
  CGSize contentSize = CGSizeMake(CGRectGetWidth(cubeVwFrame) * 2, CGRectGetHeight(cubeVwFrame));
  UIScrollView *scrollView = [[UIScrollView alloc] initWithFrame:cubeVwFrame];
  scrollView.contentSize = contentSize;
  scrollView.showsHorizontalScrollIndicator = NO;
  scrollView.delegate = self;
  scrollView.hidden = YES; // remove from responder chain
  [self.view addSubview:scrollView];

  UIView *dummyView = [[UIView alloc] initWithFrame:scrollView.frame];
  [dummyView addGestureRecognizer:scrollView.panGestureRecognizer];
  [self.view addSubview:dummyView];
}

With this in place, the UIScrollView would not be part of the responder chain but still provide us with the UIPanGestureRecognizer and the app should behave as we expect.

The code is available on github https://github.com/chunkyguy/MetalScroller.

C++ for Swift developers

2021-01-03T13:30:00+00:00

Swift in a sense is very much like C++, and when I say C++ I mean C++11 and beyond. One could also say that Swift is cleaner C++, or C++ without the backwards compatibility baggage from the 80s. To give an idea here’s a minimal modern C++ code:

#include <iostream>       // 1
using namespace std;      // 2
auto main() -> int {      // 3
  cout << "Hello world!"; // 4
  return 0;               // 5
}

Now lets break them down from Swift perspective.

#include <iostream> // 1

Swift equivalent would be import iostream. Frameworks usually come with an umbrella header as a single file, so typically we need to add only one include statement per framework like in Swift. But unlike Swift, we need to add include statements for every file we want to use from our own code.

#include <framework>      // external framework
#include "path/to/file.h" // local file

using namespace std; // 2

Unlike Swift, C++ has a proper support for namespaces. So if two types in different frameworks have same type name they can be resolved using their namespaces. For example fwkA::JSON and fwkB::JSON. To get a more Swift like behavior we can add using to indicate that the symbols do not need their namespace for every single usage.

auto main() -> int { // 3
  // ...
}

This is the modern way of writing functions in C++. In classic fashion this function could also be written as:

int main() {
  std::cout << "Hello world!";
  return 0;
}

cout << "Hello world!"; // 4

Like Swift we can also override operators in C++. In this case the iostream library provides cout which is an object of type ostream that outputs to standard output stream. iostream also provides overrides for operator << for many common types like for string that we’re using above. But it can also work for our custom types if we provide the operator << for our type. The Swift equivalent to this would be the CustomStringConvertible protocol.

return 0; // 5

And finally since our function requires a return type int we have to end our function with a return statement.

With a basic introduction, now let us take a look at C++ in a bit more detail from Swift perspective.

Variables
String
Array
Dictionary
Optional
Function
Closures
Classes
Error handling
Generics

Variables

Swift	C++
`var myVariable = 42 myVariable = 50 let myConstant = 42`	`auto myVariable = 42; myVariable = 50; const auto myConstant = 42;`

Just like in Swift types can be deduced by the compiler using auto, but if required we can always also provide the type information explicitly.

Swift	C++
`let myFloat: Float = 3.14`	`float myFloat = 3.14;`

Unlike Swift, type conversions can also occur implicitly in C++. This needs to be carefully watched out for to avoid hard to find bugs. For other cases we need to explicitly convert data from a type to another. For example int to string

Swift	C++
`let label = "The width is " let width = 94 let widthLabel = label + String(width)`	`auto label = "The width is "; auto width = 94; auto widthLabel = label + to_string(width);`

String

String interpolation in C++ isn’t as good as with Swift. But nonetheless we can construct string with either explicit string conversion, like we saw above

Swift C++

Swift	C++
`let apples = 3 let oranges = 5 let appleSummary = "I have \(apples) apples." let fruitSummary = "I have \(apples + oranges) pieces of fruit."`	`auto apples = 3; auto oranges = 5; auto appleSummary = "I have " + to_string(apples) + " apples."; auto fruitSummary = "I have " + to_string(apples + oranges) + " pieces of fruit.";`


let apples = 3
let oranges = 5
let appleSummary = "I have \(apples) apples."
let fruitSummary = "I have \(apples + oranges) pieces of fruit."


auto apples = 3;
auto oranges = 5;
auto appleSummary = "I have " + to_string(apples) + " apples.";
auto fruitSummary = "I have " + to_string(apples + oranges) + " pieces of fruit.";

Or using ostringstream which works just like cout and makes use of operator <<

auto apples = 3;
ostringstream ss;
ss << "I have " << apples << " apples.";
auto str = ss.str();

which can then further be reduced to:

auto str = (ostringstream()<<"I have "<<apples<<" apples.").str();

Swift C++

Swift	C++
`let apples = 3 let oranges = 5 let appleSummary = "I have \(apples) apples." let fruitSummary = "I have \(apples + oranges) pieces of fruit."`	`auto apples = 3; auto oranges = 5; auto appleSummary = (ostringstream()<< "I have "<<apples<<" apples.").str(); auto fruitSummary = (ostringstream()<<"I have "<<(apples + oranges)<<" pieces of fruit.").str();`


let apples = 3
let oranges = 5
let appleSummary = "I have \(apples) apples."
let fruitSummary = "I have \(apples + oranges) pieces of fruit."


auto apples = 3;
auto oranges = 5;
auto appleSummary = (ostringstream()<< "I have "<<apples<<" apples.").str();
auto fruitSummary = (ostringstream()<<"I have "<<(apples + oranges)<<" pieces of fruit.").str();

Array

Swift Array equivalent in C++ is vector. Here’s how you use it

Swift C++

Swift	C++
`var shoppingList = ["catfish", "water", "tulips"] shoppingList[1] = "bottle of water" shoppingList.append("blue paint")`	`auto shoppingList = vector<string>{"catfish", "water", "tulips"}; shoppingList[1] = "bottle of water"; shoppingList.push_back("blue paint");`


var shoppingList = ["catfish", "water", "tulips"]
shoppingList[1] = "bottle of water"
shoppingList.append("blue paint")


auto shoppingList = vector<string>{"catfish", "water", "tulips"};
shoppingList[1] = "bottle of water";
shoppingList.push_back("blue paint");

And this is how you iterate a vector

Swift	C++
`for item in shoppingList { print(item) }`	`for (auto & item : shoppingList) { cout << item << endl; }`

The & here means that we wish to use item as a reference. If we were to use auto item it would always create a new copy.

Dictionary

Swift Dictionary equivalent in C++ is map. Here’s how you use it

Swift C++

Swift	C++
`var occupations = [ "Malcolm": "Captain", "Kaylee": "Mechanic", ] occupations["Jayne"] = "Public Relations"`	`auto occupations = map<string, string> { {"Malcolm", "Captain"}, {"Kaylee", "Mechanic"}, }; occupations["Jayne"] = "Public Relations";`


var occupations = [
  "Malcolm": "Captain",
  "Kaylee": "Mechanic",
]
occupations["Jayne"] = "Public Relations"


auto occupations = map<string, string> {
  {"Malcolm", "Captain"},
  {"Kaylee", "Mechanic"},
};
occupations["Jayne"] = "Public Relations";

And this is how you iterate over a map

Swift	C++
`for (key, value) in occupations { print("\(key) : \(value)") }`	`for (auto& [key, value]: occupations) { cout << key << " : " << value << endl; }`

Optional

Swift developers love Optional types. Fortunately for us, C++ also got optional types starting c++17. Although not as fancy as with Swift, but the core idea is the same: A type that either has the value or not. Here’s an example:

Swift C++

Swift	C++
`func greeting(_ required: Bool) -> String? { return required ? Optional("Hello") : nil; } func main() -> Int { let s = greeting(false) ?? "Hi" print(s) // Hi if let str = greeting(true) { print(str) // Hello } return 0 }`	`auto greeting(bool required) -> optional<string> { return required ? optional{"Hello"} : nullopt; } auto main() -> int { auto s = greeting(false).value_or("Hi"); cout << s << endl; // Hi if (auto str = greeting(true)) { cout << *str << endl; // Hello } return 0; }`


func greeting(_ required: Bool) -> String? {
  return required ? Optional("Hello") : nil;
}

func main() -> Int {
  let s = greeting(false) ?? "Hi"
  print(s) // Hi

  if let str = greeting(true) {
    print(str) // Hello
  }

  return 0
}


auto greeting(bool required) -> optional<string> {
  return required ? optional{"Hello"} : nullopt;
}

auto main() -> int {
  auto s = greeting(false).value_or("Hi");
  cout << s << endl; // Hi

  if (auto str = greeting(true)) {
    cout << *str << endl; // Hello
  }

  return 0;
}

The *str can be thought of as force unwrapping in Swift, str!. And after dereferencing we can either use the . or the handy -> operator to access the variable.

(*str).size();
str->size();

Function

C++ functions do not have argument labels

Swift C++

Swift	C++
`func greet(_ person: String, on day: String) -> String { return "Hello \(person), today is \(day)." } greet("John", on: "Wednesday")`	`auto greetPersonOnDay(string person, string day) -> string { return (ostringstream()<<"Hello "<<person<<", today is "<<day<<".").str(); } greetPersonOnDay("John", "Wednesday")l`


func greet(_ person: String, on day: String) -> String {
    return "Hello \(person), today is \(day)."
}

greet("John", on: "Wednesday")


auto greetPersonOnDay(string person, string day) -> string {
  return (ostringstream()<<"Hello "<<person<<", today is "<<day<<".").str();
}

greetPersonOnDay("John", "Wednesday")l

But if you really miss having named arguments there are many tricks of all shapes and sizes out there. The simplest is to use a struct for arguments

struct Args { string person, day; };
auto greet(Args args) -> string {
  return (ostringstream()<<"Hello "<<args.person<<", today is "<<args.day<<".").str();
}

greet({.person = "John", .day = "Wednesday"})

Closures

C++ has a good support for closures. Here’s an example:

Swift C++

Swift	C++
`func hasAnyMatches(list: [Int], condition: (Int) -> Bool) -> Bool { for item in list { if condition(item) { return true } } return false } func lessThanTen(number: Int) -> Bool { return number < 10 } var numbers = [20, 19, 7, 12] hasAnyMatches(list: numbers, condition: lessThanTen)`	`auto hasAnyMatches(vector<int> list, function<bool(int)> condition) -> bool { for (auto item : list) { if (condition(item)) { return true; } } return false; } auto lessThanTen(int number) -> bool { return number < 10; } auto numbers = vector<int> {20, 19, 7, 12}; hasAnyMatches(numbers, lessThanTen);`


func hasAnyMatches(list: [Int], condition: (Int) -> Bool) -> Bool {
  for item in list {
    if condition(item) {
      return true
    }
  }
  return false
}

func lessThanTen(number: Int) -> Bool {
  return number < 10
}

var numbers = [20, 19, 7, 12]
hasAnyMatches(list: numbers, condition: lessThanTen)


auto hasAnyMatches(vector<int> list, function<bool(int)> condition) -> bool {
  for (auto item : list) {
    if (condition(item)) {
      return true;
    }
  }
  return false;
}

auto lessThanTen(int number) -> bool {
  return number < 10;
}

auto numbers = vector<int> {20, 19, 7, 12};
hasAnyMatches(numbers, lessThanTen);

That said, C++ still doesn’t has all the fancy functional operations like map, filter, ... that we get with Swift, but they’re coming soon with C++20 ranges. For now we can use transform as an equivalent to Swift map

Swift C++

Swift	C++
`numbers.map({ (number: Int) -> Int in let result = 3 * number return result })`	`transform(numbers.begin(), numbers.end(), numbers.begin(), [](auto number) -> auto { auto result = 3 * number; return result; });`


numbers.map({ (number: Int) -> Int in
  let result = 3 * number
  return result
})


transform(numbers.begin(), numbers.end(), numbers.begin(), [](auto number) -> auto {
  auto result = 3 * number;
  return result;
});

The C++ code here would actually mutate the numbers. If we want the truly Swift map equivalent we would have to create an empty vector and append data to it

auto mappedNumbers = vector<int> {};
transform(numbers.begin(), numbers.end(), back_inserter(mappedNumbers), [](auto n) { 
  return 3 * n; 
});

Classes

Unlike Swift in C++ there isn’t much difference between a struct and a class with the only difference being that a C++ struct has all members public by default whereas a class has all members as private by default. Whether the instance is mutable or not depends on how it is declared.

Swift C++

Swift	C++
`class Shape { func simpleDescription() -> String { return "A shape with \(numberOfSides) sides." } var numberOfSides = 0 } var shape = Shape() shape.numberOfSides = 7 var shapeDescription = shape.simpleDescription()`	`class Shape { public: auto simpleDescription() -> string { return (ostringstream()<<"A shape with "<<numberOfSides<<" sides.").str(); } int numberOfSides = 0; }; auto shape = Shape(); shape.numberOfSides = 7; auto shapeDescription = shape.simpleDescription();`


class Shape {

  func simpleDescription() -> String {
    return "A shape with \(numberOfSides) sides."
  }

  var numberOfSides = 0
}

var shape = Shape()
shape.numberOfSides = 7
var shapeDescription = shape.simpleDescription()


class Shape {
public:
  auto simpleDescription() -> string {
    return (ostringstream()<<"A shape with "<<numberOfSides<<" sides.").str();
  }

  int numberOfSides = 0;
};

auto shape = Shape();
shape.numberOfSides = 7;
auto shapeDescription = shape.simpleDescription();

Initializer (or constructor as they are called in C++) have a slightly different syntax

Swift C++

Swift	C++
`class Shape { init(name: String) { self.name = name } func simpleDescription() -> String { return "A shape with \(numberOfSides) sides." } var numberOfSides = 0 var name: String }`	`class Shape { public: Shape(string name) : name(name) { } auto simpleDescription() -> string { return (ostringstream()<<"A shape with "<<numberOfSides<<" sides.").str(); } int numberOfSides = 0; string name; };`


class Shape {

  init(name: String) {
    self.name = name
  }

  func simpleDescription() -> String {
    return "A shape with \(numberOfSides) sides."
  }

  var numberOfSides = 0
  var name: String
}


class Shape {
public:
  Shape(string name)
    : name(name) {
  }

  auto simpleDescription() -> string {
    return (ostringstream()<<"A shape with "<<numberOfSides<<" sides.").str();
  }

  int numberOfSides = 0;
  string name;
};

In C++ subclasses need to be more explicit than Swift.

Swift C++

Swift	C++
`class Square: Shape { init(sideLength: Double, name: String) { self.sideLength = sideLength super.init(name: name) numberOfSides = 4 } func area() -> Double { return sideLength * sideLength } override func simpleDescription() -> String { return "A square with sides of length \(sideLength)." } var sideLength: Double } let shape = Square(sideLength: 5.2, name: "My square")`	`class Square: public Shape { public: Square(double sideLength, string name) : sideLength(sideLength), Shape(name) { numberOfSides = 4; } auto area() -> double { return sideLength * sideLength; } auto simpleDescription() -> string { return (ostringstream()<<"A square with sides of length "<<sideLength).str(); } private: double sideLength; }; auto shape = Square(5.2, "My Square");`


class Square: Shape {

  init(sideLength: Double, name: String) {
    self.sideLength = sideLength
    super.init(name: name)
    numberOfSides = 4
  }

  func area() -> Double {
    return sideLength * sideLength
  }

  override func simpleDescription() -> String {
    return "A square with sides of length \(sideLength)."
  }

  var sideLength: Double
}

let shape = Square(sideLength: 5.2, name: "My square")


class Square: public Shape {
public:
  Square(double sideLength, string name)
    : sideLength(sideLength),
      Shape(name) {
      numberOfSides = 4;
  }

  auto area() -> double {
    return sideLength * sideLength;
  }

  auto simpleDescription() -> string {
    return (ostringstream()<<"A square with sides of length "<<sideLength).str();
  }
private:
  double sideLength;
};

auto shape = Square(5.2, "My Square");

In C++ methods are by default bound to the declared types. Lets look at an example to understand what I mean by that.

auto shape = make_shared<Shape>("My Shape");  // create new Shape
cout << shape->simpleDescription() << endl;   // prints: A shape with 0 sides.
shape.reset(new Square(5.2, "My Square"));    // release Shape and create new Square
cout << shape->simpleDescription() << endl;   // prints: A shape with 4 sides.

In this case since shape is originally declared as of type Shape, so even after we assign it to a Square type simpleDescription still invokes Shape::simpleDescription. To get the same behavior as Swift we would have to mark the base class simpleDescription() as virtual, so that if we assign a Square instance to Shape it would dynamically dispatch the Square::simpleDescription at runtime.

class Shape {
  virtual auto simpleDescription() -> string {
    return (ostringstream()<<"A shape with "<<numberOfSides<<" sides.").str();
  }
  // ...
};

class Square: public Shape {
  auto simpleDescription() -> string override {
    return (ostringstream()<<"A square with sides of length "<<sideLength).str();
  }
  // ...
};

auto shape = make_shared<Shape>("My Shape");  // create new Shape
cout << shape->simpleDescription() << endl;   // prints: A shape with 0 sides.
shape.reset(new Square(5.2, "My Square"));    // release Shape and create new Square
cout << shape->simpleDescription() << endl;   // prints: A square with sides of length 5.2

Reference counting

Swift has reference counting mechanism builtin. C++ also provides reference counting, but it isn’t builtin. In order to get the same behavior as Swift, we need to make use of shared_ptr and weak_ptr. Here’s how it looks in C++

class MyString {
public:
  MyString(string str) : str(str) {
    cout << "created" << endl;
  }

  ~MyString() {
    cout << "destroyed" << endl;
  }

  string str;
};

auto s0 = make_shared<MyString>("hello!");
cout << "first strong ref: " << s0->str << " refCount:" << s0.use_count() << endl;

auto w0 = weak_ptr<MyString>(s0);
cout << "first weak ref: " << s0->str << " refCount:" << s0.use_count() << endl;

auto s1 = s0;
cout << "second strong ref: " << s1->str << " refCount:" << s0.use_count() << endl;

And this is the output

created
first strong ref: hello! refCount:1
first weak ref: hello! refCount:1
second strong ref: hello! refCount:2
destroyed

No surprises here, as you can see only a single instance is ever created and both the instance refer to the same thing with just the reference count that gets incremented. Also weak reference doesn’t increment the reference count. And then finally when we’re done the instance gets automatically deallocated. Just like in swift.

Error handling

Error handling in C++ is a bit more involved than Swift. So if we want to see the C++ exception handling from the perspective of Swift error handling, it might look something like:

Swift C++

Swift	C++
`func send(job: Int, toPrinter printerName: String) throws -> String { if printerName == "BadPrinterr" { throw PrinterError.noToner } return "Job sent" } do { let printerResponse = try send(job: 1040, toPrinter: "BadPrinter") print(printerResponse) } catch let error { print(error.description) }`	`auto sendJobToPrinter(int job, string printerName) -> string { if (printerName == "BadPrinter") { throw PrinterError::noToner(); } return "Job sent"; } try { auto printerResponse = sendJobToPrinter(1040, "BadPrinter"); cout << printerResponse << endl; } catch (const exception & error) { cout << error.what() << endl; }`


func send(job: Int, toPrinter printerName: String) throws -> String {
  if printerName == "BadPrinterr" {
    throw PrinterError.noToner
  }
  return "Job sent"
}

do {
  let printerResponse = try send(job: 1040, toPrinter: "BadPrinter")
  print(printerResponse)
} catch let error {
  print(error.description)
}


auto sendJobToPrinter(int job, string printerName) -> string {
  if (printerName == "BadPrinter") {
    throw PrinterError::noToner();
  }
  return "Job sent";
}

try {
  auto printerResponse = sendJobToPrinter(1040, "BadPrinter");
  cout << printerResponse << endl;
} catch (const exception & error) {
  cout << error.what() << endl;
}

Unlike Swift, C++ functions are assumed to always throw. If they’re guaranteed to not throw at all then we can mark them as noexcept, in that case if any exception is thrown the app just crashes.

In Swift our PrinterError has to conform to Error, similarly in C++ our custom exception PrinterError has to subclass exception.

enum PrinterError: Error {
    case outOfPaper
    case noToner
    case onFire
}

Implementing the PrinterError type of exception is a bit more involved since C++ enums are not as awesome as Swift, but we can improvise.

class PrinterError: public exception {
public:
  static auto outOfPaper() -> PrinterError {
    return PrinterError(0, "out of paper");
  }
  static auto noToner() -> PrinterError {
    return PrinterError(1, "no toner");
  }
  static auto onFire() -> PrinterError {
    return PrinterError(2, "on fire");
  }

  PrinterError(int errorCode, const std::string &message) noexcept
  : errorCode(errorCode), message(message)
  {}

  auto what() const noexcept -> const  char * {
    return message.c_str();
  }

  int errorCode;
  string message;
};

Generics

If there’s one thing where C++ beats Swift hands down, it’s Generics. Here’s an example how a generic class might look in C++

template <typename Element>
class Stack {
public:

  auto push(Element e) {
    storage.push_back(e);
  }

  auto pop() -> optional<Element> {
    if (storage.empty()) {
      return nullopt;
    }
    auto lastEle = storage.back();
    storage.pop_back();
    return lastEle;
  }

private:
  vector<Element> storage;
};

When it comes to generics, C++ isn’t as as verbose as Swift.

Swift C++

Swift	C++
`func anyCommonElements<T: Sequence, U: Sequence>(_ lhs: T, _ rhs: U) -> Bool where T.Element: Equatable, T.Element == U.Element { for lhsItem in lhs { for rhsItem in rhs { if lhsItem == rhsItem { return true } } } return false } anyCommonElements([1, 2, 3], [3])`	`template <typename T, typename U> auto anyCommonElements(T lhs, U rhs) -> bool { for (auto lhsItem : lhs) { for (auto rhsItem : rhs) { if (lhsItem == rhsItem) { return true; } } } return false; } anyCommonElements(vector<int>{1, 2, 3}, vector<int>{3});`


func anyCommonElements<T: Sequence, U: Sequence>(_ lhs: T, _ rhs: U) -> Bool
  where T.Element: Equatable, T.Element == U.Element {
  for lhsItem in lhs {
    for rhsItem in rhs {
      if lhsItem == rhsItem {
        return true
      }
    }
  }
  return false
}

anyCommonElements([1, 2, 3], [3])


template <typename T, typename U> 
auto anyCommonElements(T lhs, U rhs) -> bool {
  for (auto lhsItem : lhs) {
    for (auto rhsItem : rhs) {
      if (lhsItem == rhsItem) {
        return true;
      }
    }
  }
  return false;
}

anyCommonElements(vector<int>{1, 2, 3}, vector<int>{3});

Notice no type constraints to Sequence or Equatable since the C++ compiler automatically takes care of that. In case the type constraints fail, for instance T.Element does not have == implemeted, the compiler throws errors that are generally hard to decipher. If you like that level of control c++20 has a proposal for constraints and concepts which is very close to where Swift is already at.

And finally, for a wrap up and to show how easy it is to work with C++ generics. Lets revisit our closure example from above where we tried to replicate the Swift map behavior with transfrom.

auto mappedNumbers = vector<int> {};
transform(numbers.begin(), numbers.end(), back_inserter(mappedNumbers), [](auto number) {
  return 3 * result;
});

We can easily make this a generic function in our custom namespace

namespace wl {
  template <typename Sequence, typename Func>
  Sequence map(const Sequence & seq, const Func & func) {
    Sequence output;
    transform(seq.begin(), seq.end(), back_inserter(output), func);
    return output;
  }
}

auto numbers = vector<int> {20, 19, 7, 12};
auto mappedNumbers = wl::map(numbers, [](auto number) { return 3 * number; });

Building UI without AutoLayout

2020-09-15T06:00:00+00:00

The good thing is that, the Auto Layout has not been designed as an alternative to Manual Layout, rather more like an complement. Where instead of us having to calculate the frame, we start with a CGRectZero and let the Auto Layout fill in the frame value later. Most of the time it’s wonderful and doesn’t impact our flow. Other times we might have to wait for the layout pass run to read back the calculated frame values

  // let Auto layout calculate the frame values
  dispatch_async(dispatch_get_main_queue(), ^{
    // start using the frame values for something else.
  });

I often wish if the Auto Layout were not that tightly coupled with UIKit. In a sense, if I could just run Auto Layout without a layout pass. This inspired me to take another take of building UIs without Auto Layout with something I’d like to call as Simple Manual Layout.

Inspiration

The inspiration is from how UIBarButtonItem works with UIToolbar or UINavigationBar. If we wanted to build a UI like

We would create a UIToolBar and add a bunch of UIBarButtonItem

UIToolbar *toolbar = [[UIToolbar alloc] initWithFrame:toolbarFrame];
UIBarButtonItem *playButton = [[UIBarButtonItem alloc]
                               initWithBarButtonSystemItem:UIBarButtonSystemItemPlay
                               target:self
                               action:@selector(playVideo)];
UIBarButtonItem *pauseButton = [[UIBarButtonItem alloc]
                                initWithBarButtonSystemItem:UIBarButtonSystemItemPause
                                target:self
                                action:@selector(pauseVideo)];
UIBarButtonItem *rewindButton = [[UIBarButtonItem alloc]
                                 initWithBarButtonSystemItem:UIBarButtonSystemItemRewind
                                 target:self
                                 action:@selector(rewindVideo)];
UIBarButtonItem *forwardButton = [[UIBarButtonItem alloc]
                                  initWithBarButtonSystemItem:UIBarButtonSystemItemFastForward
                                  target:self
                                  action:@selector(forwardVideo)];
UIBarButtonItem *spaceButton = [[UIBarButtonItem alloc]
                                initWithBarButtonSystemItem:UIBarButtonSystemItemFlexibleSpace
                                target:nil
                                action:nil];
[toolbar setItems:[NSArray arrayWithObjects:
                   spaceButton,
                   rewindButton,
                   spaceButton,
                   playButton,
                   spaceButton,
                   pauseButton,
                   spaceButton,
                   forwardButton,
                   spaceButton,
                   nil]];

The interesting element here is UIBarButtonSystemItemFlexibleSpace. Which is documented as “Blank space to add between other items. The space is distributed equally between the other items.”. Similarly, there’s another one called UIBarButtonSystemItemFixedSpace which is documented as “Blank space to add between other items. Only the width property is used when this value is set.”.

I think this approach could be used to build a layout engine which is very simple in terms of mental model but can be used to build as sophisticated layouts as we’d want.

Simple Manual Layout

With that design in mind we can build out layout engine. If there is a class SLELayoutItem which is a placeholder for a UIView and another class SLELayout that takes in one or more of these SLELayoutItem and immediately calculates the frame of the every SLELayoutItem. Then we can use the calculated frame value when constructing our UIView objects.

So to create a full screen subview we should be able to create as:

SLELayout *layout = [SLELayout layoutWithParentBounds:_rootFrame
                                            direction:SLELayoutDirectionColumn];
SLELayoutItem *mainItem = [SLELayoutItem flexItem];
[layout addItem:mainItem];

UIView *redView = SLECreateView(mainItem.frame, [UIColor redColor]);
[_rootView addSubview:redView];

UIView *SLECreateView(CGRect frame, UIColor *color)
{
  UIView *view = [[UIView alloc] initWithFrame:frame];
  view.backgroundColor = color;
  return [view autorelease];
}

And a 2 subview layout, where the top is flexible and bottom is fixed

  SLELayout *layout = [SLELayout layoutWithParentBounds:_rootFrame
                                              direction:SLELayoutDirectionColumn];
  [layout addItem:[SLELayoutItem flexItem]];
  [layout addItem:[SLELayoutItem itemWithHeight:200]];

  CGRect topFrame = [layout frameAtIndex:0];
  CGRect bottomFrame = [layout frameAtIndex:1];

  [_rootView addSubview:SLECreateView(topFrame, [UIColor redColor])];
  [_rootView addSubview:SLECreateView(bottomFrame, [UIColor blueColor])];

A more interesting layout would be where we have a column that contains a row.

  CGFloat contentHeight = 200.f;
  SLELayout *mainLayout = [SLELayout layoutWithParentBounds:_rootFrame
                                                  direction:SLELayoutDirectionColumn];
  [mainLayout addItem:[SLELayoutItem flexItem]];
  [mainLayout addItem:[SLELayoutItem itemWithHeight:44]];
  [mainLayout addItem:[SLELayoutItem itemWithHeight:contentHeight]];

  CGRect headerFrame = [mainLayout frameAtIndex:0];
  CGRect toolbarFrame = [mainLayout frameAtIndex:1];
  CGRect contentFrame = [mainLayout frameAtIndex:2];

  SLELayout *contentLayout = [SLELayout layoutWithParentBounds:contentFrame
                                                   direction:SLELayoutDirectionRow];
  [contentLayout addItem:[SLELayoutItem flexItem]];
  [contentLayout addItem:[SLELayoutItem itemWithWidth:contentHeight]];
  [contentLayout addItem:[SLELayoutItem flexItem]];
  [contentLayout addItem:[SLELayoutItem itemWithWidth:contentHeight]];
  [contentLayout addItem:[SLELayoutItem flexItem]];

  CGRect content1Frame = [contentLayout frameAtIndex:1];
  CGRect content2Frame = [contentLayout frameAtIndex:3];

  [_rootView addSubview:SLECreateView(headerFrame, [UIColor redColor])];
  [_rootView addSubview:SLECreateView(toolbarFrame, [UIColor blueColor])];
  UIView *contentView = SLECreateView(contentFrame, [UIColor yellowColor]);
  [_rootView addSubview:contentView];

  [contentView addSubview:SLECreateView(content1Frame, [UIColor cyanColor])];
  [contentView addSubview:SLECreateView(content2Frame, [UIColor magentaColor])];

Implementation details

The implementation of this layout engine turns out to be not as sophisticated. If we provide a SLELayoutItem which can have some properties fixed and others flexible.

SLELayoutItem.h
@interface SLELayoutItem : NSObject

// no values fixed
+ (instancetype)flexItem;

// partially fixed
+ (instancetype)itemWithWidth:(CGFloat)width;
+ (instancetype)itemWithHeight:(CGFloat)height;

// total fixed
+ (instancetype)itemWithSize:(CGSize)size;

// would be filled by the layout engine
@property (nonatomic, readonly) CGRect frame;

@end

So we can mark any flexible value as kSLELayoutValueUndefined which is -1 in our case.

// SLELayoutItem.m
@implementation SLELayoutItem
- (instancetype)initWithSize:(CGSize)size
{
  self = [super init];
  if (self) {
    // requested frame
    _originalFrame = (CGRect) {
      .origin = { .x = kSLELayoutValueUndefined, .y = kSLELayoutValueUndefined },
      .size = { .width = size.width, size.height }
    };
    // will be updated later
    _finalFrame = CGRectZero;
  }
  return self;
}

// called by layout engine
- (void)setOrigin:(CGPoint)origin
{
  _finalFrame.origin = origin;
}

- (void)setSize:(CGSize)size
{
  _finalFrame.size = size;
}

@end

And we can have an internal setter interface only visible to SLELayout

// SLELayoutItem+Internal.h
@interface SLELayoutItem ()

- (void)setOrigin:(CGPoint)origin;
- (void)setSize:(CGSize)size;

@property (nonatomic, readonly) CGRect originalFrame;

@end

Next, within SLELayout we have an mutable array that contains SLELayoutItem. And whenever a new item is added we recalculate the frames per item.

// SLELayout.m
@implementation SLELayout

// ... 

- (void)addItem:(SLELayoutItem *)item
{
  [_items addObject:item];
  [self updateFrames];
}
@end

If we calculate only for one direction, say vertical. The updateFrames might look something like:

// SLELayout.m
@implementation SLELayout

// ... 

- (void)updateFrames
{
  // calculate total fixed height
  CGFloat fixHeight = 0;
  NSInteger flexItems = 0;
  for (SLELayoutItem *item in _items) {
    CGFloat itemHeight = item.originalFrame.size.height;
    if (itemHeight == kSLELayoutValueUndefined) {
      flexItems += 1;
    } else {
      fixHeight += itemHeight;
    }
  }

  // calculate height per flex item
  CGFloat flexHeight = _parentSize.height - fixHeight;
  CGFloat flexItemHeight = flexHeight / (CGFloat)flexItems;

  // update final frames per item
  CGFloat offsetY = 0.f;
  for (SLELayoutItem *item in _items) {
    CGSize itemSize = item.originalFrame.size;
    CGFloat itemHeight = (itemSize.height == kSLELayoutValueUndefined)
      ? flexItemHeight
      : itemSize.height;
    itemSize = (CGSize) { .width = _parentSize.width, .height = itemHeight };

    [item setOrigin:CGPointMake(0.f, offsetY)];
    [item setSize:itemSize];

    offsetY += itemSize.height;
  }
}
@end

And similar calculations for width.

And now it doesn’t seem hard to imagine to support alignment for sub views (currently they are all set 0.0f or all aligned to start) with something like:

typedef NS_ENUM(NSUInteger, SLELayoutAlignment) {
  SLELayoutAlignmentStart,
  SLELayoutAlignmentCenter,
  SLELayoutAlignmentEnd
};

If I actually start using this code in real life, I might start supporting it. The code for the Simple Layout Engine is available at github.com/chunkyguy/SimpleLayoutEngine

Understanding Manual Retain Release in Objective-C

2020-08-24T05:00:00+00:00

You might often hear programmers claiming Automatic Reference Counting (ARC) is one of the best things that happened to Objective-C. It relieves you, the programmer, from typing out redundant code. It’s a convenience if you’ve ever written any Manual Retain Release (MRR) code. But if you joined the club later and haven’t actually every written any MRR code, you might get a wrong impression that MRR is verbosely spammed with calls to retain and release. One factor could be that people assume MRR code is equivalent to C style memory management, where you need to call malloc and free and then figure out complex ways to manage the ownership. Another factor could be because a lot of ARC vs MRR discussion overlook the fact that MRR already has reference counting, something equivalent of what was finally introduced in C++11 with smart pointers. Another confusion might have to do with the fact that ARC is not really clear on memory ownership rules. So some people might assume every assignment operation is either a transfer of ownership or claiming ownership, which isn’t entirely false, but not in the sense of how retain and release is designed to work.

I think every new Objective-C programmer should at least write some MRR code to understand what are the redundancies that ARC is trying to get rid of. Also if you look beyond ARC, you might realize the clear pattern of memory ownership, which honestly isn’t that complicated. The data isn’t randomly allocated or randomly transferred from an instance to another. There’s a very clear pattern of when that happens and MRR highlights them clearly.

In real life, a well architected code has a clean vision of memory ownership. There’s a concept of object graph which should ideally be an acyclic directed graph with clear parent child relationships. When, a parent claims the ownership then any reference to the data passed to the children can almost always assume that the data won’t get deallocated out of nowhere, since parent should always outlive the children. In all of these cases there’s no transfer of ownership, so all those reference could be a weak reference. In other cases where there’s a temporary factory class involved who’s only job is to allocated the data, the ownership has to be transferred at some point.

Then there is the amazing idea of autorelease pool, where the ownership of data is temporary transferred to the run loop, for data that can be disposed at the end of the run loop cycle or should be claimed by somebody before the end of the loop cycle.

And finally there are rules around transfer of ownership when working with an external library.

In almost all cases there are only a finite set of scenarios possible:

1. Transfer of ownership from client to library

In library calls, it might happen quite often that the library is designed such that it delegates the responsibility of memory allocation to the client and then transfer the ownership back to library. An example is NSArray

Foo *foo = [[Foo alloc] init];
[array addObject:foo]; // transfer of ownership
[foo release];

2. Transfer of ownership from library to client

In other scenarios the library might transfer the ownership to the client. Most of the class factory methods that wrap initializer with autorelease do this

@implementation Person

+ (instancetype)personWithName:(NSString *)name
{
  return [[[Person alloc] initWithName:name] autorelease]; // transfer ownership to autorelease pool
}

- (instancetype)initWithName:(NSString *)name
{
  // ...
}

Which is a way to say that for the time being the ownership has been transferred to the autorelease pool. Now it’s up to the client on how they wish to manage the memory. And depending on the usage, the clients can call [person retain] to claim the ownership otherwise the data would be deallocated at the end of the run loop cycle.

Person *tmpPerson = [Person personWithName:@"John"];
_person = [[Person personWithName:@"John"] retain]; // transfer of ownership

3. Dealing with asynchronous callbacks

In cases where an asynchronous calls are being made, there’s a chance that caller might get disposed by the time the callback happens. These scenarios have to be carefully designed for. Again, there’s no magic trick here, just make sure the listener object lives long enough to handle the callback.

4. Multiple owners of the data

Another situation is when multiple instanced deliberately want to acquire ownership of the same data. For example say multiple children want to work with same image data and the parent doesn’t want to claim ownership of the image data. In these scenarios, we can rely on the reference counting and every child can claim ownership. Later when the last child relinquishes the ownership the shared data would get deallocated.

@implementation Child

- (instancetype)initWithImage:(UIImage *)image
{
  self = [super init];
  if (self) {
    _image = [image retain];
  }
  return self;
}

- (void)dealloc
{
  [_image release];
  [super dealloc];
}

@end

Once you understand these basic rules and the complexities around them, you might think for yourself if you like ARC or not. Maybe you don’t like the magical aspect of ARC, or you don’t like how ARC interacts with plain C struct types which also relates to how ARC interacts with CoreFoundation. Also since ARC can be enabled and disabled per file basis, one might have it enabled for parts of code that are simpler and disabled for complex ones.

Multiple objects in single frame with Metal

2020-04-30T18:20:54+00:00

It’s been a long time since I touched Metal. Recently, I’ve been poking at Metal again. This brought me to an interesting challenge. So far I’ve been rendering single objects and when I try to render more than one item I face an interesting problem. Let’s see if I can fix that.

Problem

So, I’ve a teapot and a floor that I’m able to render independently.

Now I want to render them both together. Sounds simple right?

Take 1: A simple loop

This is how my shader types looks like, nothing fancy in there:

struct VertexIn {
  float4 position;
  float3 normal;
};

struct Uniforms {
  float4x4 mvMatrix;
  float3x3 nMatrix;
  float4x4 mvpMatrix;
};

vertex VertexOut vert_main(
  const device VertexIn *vertices [[buffer(0)]],
  constant Uniforms *uniforms [[buffer(1)]],
  uint vid [[vertex_id]]
) { ... }

And this is the pseudo algorithm:

// Renderer.m
- (void)renderScene
{
  for (WLActor *actor in scene.actors) {
    id<MTLCommandBuffer> cmdBuf; // set up
    id<MTLRenderCommandEncoder> command; // set up

    [actor render:command];

    [command endEncoding];
    [cmdBuf presentDrawable:drawable];
    [cmdBuf commit];
  }
}

// Actor.m
@interface WLActor ()
{
  id<MTLBuffer> _uniforms;
  id<MTLBuffer> _vertexBuffer;
  id<MTLBuffer> _indexBuffer;
}
@end

- (void)render:(id<MTLRenderCommandEncoder>)command
{
  // bind vertex, uniform, index data ...
  [command setVertexBuffer:_vertexBuffer offset:0 atIndex:0];
  [command setVertexBuffer:_uniforms offset:0 atIndex:1];
  [command drawIndexedPrimitives:MTLPrimitiveTypeTriangle
                      indexCount:[_indexBuffer length]/sizeof(WLInt16)
                       indexType:MTLIndexTypeUInt16
                     indexBuffer:_indexBuffer
               indexBufferOffset:0];
}

When running this, I get a strange flickering

Turns out with Metal you need to wait for the drawing to finish before you can submit a new draw command. In simpler terms, we can not draw multiple times in a simple for loop, we need a blocking mechanism. I’ve seen the sample code trying to do this with a semaphore. Let’s try that.

Take 2: Asynchronous drawing with semaphores

// Renderer.m
- (void)renderScene
{
  dispatch_semaphore_wait(_drawSemaphore, DISPATCH_TIME_FOREVER);
  _drawIndex = (_drawIndex + 1) % scene.actors.count;

  id<MTLCommandBuffer> cmdBuf = [_cmdQueue commandBuffer];
  __block dispatch_semaphore_t sema = _drawSemaphore;
  [cmdBuf addCompletedHandler:^(id<MTLCommandBuffer> buffer) {
    dispatch_semaphore_signal(sema);
  }];

  id<MTLRenderCommandEncoder> command; // set up
  [self configureRenderCommand:command];
  [command setRenderPipelineState:_pipeline];

  WLActor *actor = [scene.actors objectAtIndex:_drawIndex];
  [actor render:command camera:scene.camera];

  [command endEncoding];
  [cmdBuf presentDrawable:drawable];
  [cmdBuf commit];
}

Okay. The problem seems that every draw wipes the drawing surface clean. Can we try getting rid of that?

Take 3: Overlapped drawing

This is how I’m currently creating the render pass. The texture here is coming from the CAMetalDrawable, which is our screen.

- (MTLRenderPassDescriptor *)renderPassDescWithTexture:(id<MTLTexture>)texture
{
  MTLRenderPassDescriptor *passDesc = [MTLRenderPassDescriptor renderPassDescriptor];
  passDesc.colorAttachments[0].texture = texture;
  passDesc.colorAttachments[0].loadAction = MTLLoadActionClear;
  passDesc.colorAttachments[0].storeAction = MTLStoreActionStore;
  passDesc.colorAttachments[0].clearColor = MTLClearColorMake(0.1, 0.1, 0.1, 1);
  passDesc.depthAttachment.texture = _depthTexture;
  passDesc.depthAttachment.clearDepth = 1.0f;
  passDesc.depthAttachment.loadAction = MTLLoadActionClear;
  passDesc.depthAttachment.storeAction = MTLStoreActionDontCare;
  return passDesc;
}

Here if I change the loadAction to MTLLoadActionLoad, I guess it should preserve the last frame

passDesc.colorAttachments[0].loadAction = MTLLoadActionLoad;

Result:

This look better. Although I should mention that there’s still a flicker mainly in the beginning. But the bigger problem is the red color background. I guess that is because we never clear the screen, so whatever color is there originally stays there forever. Another problem appears when the teapot starts moving, since we are not clearing the screen, the images just keep adding up.

Can we fix this with the classic if first time do this, else do this flow? Let’s see.

Take 4: Clear and Draw

Since we need to clear the screen after all the objects have been drawn to avoid overlapping. We need something like:

  for (WLActor *actor in scene.actors) {
    [actor render];
  }
  clearScreen();

But this seems like a problematic already. These commands are executed one after the other. So if our last command is clear, it would wipe the entire screen clear. Thinking about it as how a painter would paint. First they would clear what ever is on the canvas, then draw the background and then the foreground. So, if our actors are in draw order we need something like:

  clearScreen();
  for (WLActor *actor in scene.actors) {
    [actor render];
  }

Also this reveals another interesting insight. A MTLCommandBuffer is designed to render multiple draw commands. So, looking at our target pseudo code, each [actor render] is basically just a draw command. So far we have been trying to redundantly waste resources and duplicate the work of MTLCommandBuffer with our semaphore, and probably even made the code unnecessarily complicated. What we actually need is to create a command buffer, add draw commands to it and submit.

- (void)render
{
  id<MTLCommandBuffer> cmdBuf = [_cmdQueue commandBuffer];
  for (NSInteger i = 0; i < N; ++i) {
    id<MTLRenderCommandEncoder> command = // make
    [command endEncoding];
  }
  [cmdBuf presentDrawable:drawable];
  [cmdBuf commit];
}

So let’s try implementing this. We can loop our draw command one extra step than the actors.count just for clearing the screen.

- (void)render
{
  id<MTLCommandBuffer> cmdBuf = [_cmdQueue commandBuffer];
  for (NSInteger i = 0; i < (scene.actors.count + 1); ++i) {

    MTLLoadAction loadAction = MTLLoadActionDontCare;
    WLActor *actor = nil;
    if (i == 0) {
      loadAction = MTLLoadActionClear;
    } else {
      actor = [scene.actors objectAtIndex:i - 1];
    }
    id<MTLRenderCommandEncoder> command = [self renderCommandWithTexture:texture
                                                              loadAction:loadAction
                                                                  cmdBuf:cmdBuf];
    [actor render:command camera:scene.camera];
    [command endEncoding];
  }
  [cmdBuf presentDrawable:drawable];
  [cmdBuf commit];
}

Result:

Now, thinking again, do we actually need an explicitly render command just for clearing the screen? We can also simply set the first draw with MTLLoadActionClear

for (NSInteger i = 0; i < scene.actors.count; ++i) {
    MTLLoadAction loadAction = (i == 0) ? MTLLoadActionClear: MTLLoadActionLoad;
    WLActor *actor = [scene.actors objectAtIndex:i];
    // draw ..
}

Recap

So what did we learn from this?

We need a MTLCommandBuffer for a render pass.
Each render pass can have as many MTLRenderCommandEncoder render commands.
The first render command should clear the screen with MTLLoadActionClear.
The following render command need to draw on top of existing image with MTLLoadActionLoad.
You don’t need semaphore based blocking unless your app is GPU bound.

This was a fun exercise. Let me know on twitter if you have any questions.

Objective-C Properties Problems

2020-03-12T21:00:00+00:00

Objective-C 2.0 introduced properties as syntactic sugar over getter and setter a very long time back. Properties are very convenient for most of the things but there are quite a few issues that I feel always with them. Today I would like to document them.

Dot syntax

In C there’s this idea of -> and . to access struct properties and it is simple to understand. For a given struct as:

typedef struct _Person {
  char name[1024];
  int age;
} Person;

We have . for values

Person setAge(Person p, int age)
{
  p.age = age;
  return p;
}

And we have -> for references

void setName(Person *p, const char *name)
{
  strcpy(p->name, name);
}

With Objective-C, all NSObject subclasses can only be used as reference types, like NSString *, so using the . on reference types breaks my brain every single time.

@interface Person : NSObject
@property (nonatomic, copy) NSString *name;
@end

void setName(Person *p, NSString *name)
{
  p.name = name;
}

I believe the intention was good, but they could be picked some clearly non-ambiguous operator, like say ~>. I know it would look unnatural to C programmers, that was one of the core design principle of Objective-C, to have a syntax that is clearly distinguishable from C. That is why we have things like [ ], @interface and -(void)foo:(Bar *)bar because they don’t look anything like C.

I’ve a conspiracy theory, that the . was used for property because Apple wanted the developers to adapt Swift syntax gradually, where . is the only way to access properties.

Error prone

Let’s say we want to implement a property chaining where the only storage is NSDate and everything is just a computed getters and setters on top of it

@interface DateWrapper : NSObject
@property (nonatomic, strong) NSDate *date;
@property (nonatomic, strong) NSDateComponents *dateComps;
@property (nonatomic, assign) NSInteger hour;
@end

@implementation DateWrapper

- (instancetype)init
{
  self = [super init];
  if (self) {
    _date = [NSDate dateWithTimeIntervalSince1970:0];
  }
  return self;
}

- (NSInteger)hour
{
  return self.dateComps.hour;
}

- (void)setHour:(NSInteger)hour
{
  self.dateComps.hour = hour;
}

- (NSDateComponents *)dateComps
{
  return [[NSCalendar currentCalendar] components:NSCalendarUnitHour 
                                         fromDate:self.date];
}

- (void)setDateComps:(NSDateComponents *)dateComps
{
  self.date = [[NSCalendar currentCalendar] dateFromComponents:dateComps];
}

@end

One could accidentally use the interface as:

- (void)run
{
  DateWrapper *dw = [[DateWrapper alloc] init];
  NSLog(@"BEF: %ld", dw.hour); // 1
  dw.hour += 1;
  NSLog(@"AFT: %ld", dw.hour); // 1 ❌
}

These bugs could happen again because of the C like dot syntax. Because we know this works in C

CGRect frame = CGRectZero;
frame.size.width += 10; // ✅

We might apply the same principles to Objective-C properties

self.dateComps.hour += hour; // ❌

If you haven’t figured it out yet. The bug is because self.dateComps call the getter and we update the hour on a temporary object. The right way would be

NSDateComponents *tmp = self.dateComps;
tmp.hour += hour;
self.dateComps = tmp;

The bug becomes more visible by switching to getters and setters because every operation is clear in terms of where are we reading the data and where are we writing it.

@interface DateWrapper : NSObject
{
  NSDate *_date;
}
@end

@implementation DateWrapper

- (instancetype)init
{
  self = [super init];
  if (self) {
    _date = [NSDate dateWithTimeIntervalSince1970:0];
  }
  return self;
}

- (NSInteger)hour
{
  return [[self dateComps] hour]; // read
}

- (void)setHour:(NSInteger)hour
{
  NSDateComponents *comps = [self dateComps]; // read
  [comps setHour:hour]; // write
  [self setDateComps:comps]; // write
}

- (NSDateComponents *)dateComps
{
  return [[NSCalendar currentCalendar] components:NSCalendarUnitHour 
                                         fromDate:_date]; // read
}

- (void)setDateComps:(NSDateComponents *)dateComps
{
  _date = [[NSCalendar currentCalendar] dateFromComponents:dateComps]; // write
}

@end

- (void)run
{
  DateWrapper *dw = [[DateWrapper alloc] init];
  NSLog(@"BEF: %ld", [dw hour]); // 1
  [dw setHour:[dw hour] + 1];
  NSLog(@"AFT: %ld", [dw hour]); // 2
}

Chaining Setters

One limitation of property is that the setter has to return a void which could be problematic if you want to design your interface to be chainable. Take this usage for example

- (Person *)updatePerson:(Person *)person
{
  person.firstName = @"Barney";
  person.lastName = @"Gumble";
  person.age = 40;
  return person;
}

If we drop the whole property requirement, we could return instancetype from every setter which would make the setters as chainable.

- (Person *)updatePerson:(Person *)person
{
    return [[[person setFirstName:@"Barney" ]
                      setLastName:@"Gumble" ]
                           setAge:40        ];
}

Ambiguous Attributes

Properties are ambiguous when we’re writing custom getter and setters. If we’ve a C function that encodes and decodes string to int, and we wish to provide a Objective-C wrapper.

int my_encrypt(const char *str);
const char *my_decrypt(int hash);

@interface StringWrapper : NSObject
{
  int _hash;
}
@end

@implementation StringWrapper
- (void)setString:(NSString *)string
{
  _hash = my_encrypt([string cStringUsingEncoding:NSUTF8StringEncoding]);
}

- (NSString *)string
{
  return [NSString stringWithCString:my_decrypt(_hash) 
                            encoding:NSUTF8StringEncoding];
}
@end

Next if we wish to expose string as a property, what should the attributes look like? We might use copy or retain, but that would be a lie, since we know we’re not copying or retaining anything.

@property (nonatomic, copy) NSString *string;

We might simply leave it unspecified, but again unspecified does mean the default attributes atomic, readwrite, which might again cause confusion.

@property NSString *string;

With plain getter and setter, the memory storage or threading intention is never leaked outside.

@interface StringWrapper : NSObject
- (NSString *)string;
- (void)setString:(NSString *)string;
@end

Good parts: MRR

The only good use of a property that I can imagine is when we’re working on a Manual Retain Release memory model, the retain and release calls could be error prone.

Take a look at the following example with a bug:

@interface Foo : NSObject
{
  Bar *_bar;
}
@end

@implementation Foo
- (instancetype)init
{
  self = [super init];
  if (self) {
    _bar = [[Bar alloc] init];
  }
  return self;
}

- (void)dealloc
{
  [_bar release];
  [super dealloc];
}

- (Bar *)bar
{
  return _bar;
}

- (void)setBar:(Bar *)bar
{
  [_bar release]; // ❌ might also release bar
  _bar = [bar retain];
}

@end

This might introduce a bug if the bar is same as _bar in setBar:. The first release would deallocated the object immediately and the retain in the next line would have no effect. The right way to implement a setter would be to call retain before release.

- (void)setBar:(Bar *)bar
{
  [bar retain];
  [_bar release];
  _bar = bar;
}

This is one of many consideration one has to look out for when using MRR model. So with MRR it’s usually better to just use property for retain or copy attributes and let the compiler generate the correct code

@interface Foo : NSObject
@property (nonatomic, retain) Bar *bar;
@end

@implementation Foo
- (instancetype)init
{
  self = [super init];
  if (self) {
    _bar = [[Bar alloc] init];
  }
  return self;
}

- (void)dealloc
{
  [_bar release];
  [super dealloc];
}
@end

Parting Thoughts

I do like the convenience of properties as a short hand for plain getter and setter. That means no property chaining and the intention is very clear. I also like using properties when working MRR memory model. Or when implementing a readonly property. But there are these few things I don’t like about properties that sometimes I deliberately avoid using them for sake of accidental bugs.

I would file Objective-C properties under the Apple Fuckups section. It could’ve been really brilliant if they had consulted the Objective-C language designers and not C/C++, and hopefully not Swift.

I’m probably not the first one to dislike Objective-C properties, and I know I’m not the last. I’m actually a bit glad that Apple has now shifted the gears to Swift, so finally I can write Objective-C that way I always wanted to.

Objective-C Subclass Factory Pattern

2020-03-09T21:30:54+00:00

It’s not an secret that creating instances in Objective-C can be very verbose. It doesn’t help that we don’t have default values and by default everything is initialized to zero. It gets even more verbose when you want to write a robust code and don’t want to expose properties as readwrite where they shouldn’t be. That said, a lot of times keeping them readwrite is better than wiring things around it. Remember that properties in Objective-C, unlike say C++, are just syntactic sugar over getters and setters.

Often times we need an object with all properties as readonly as they are not expected to be modified after the initialization.

@interface Foo : NSObject
@property (nonatomic, readonly) NSString *title;
@property (nonatomic, readonly) Bar *bar;
@end

Clean. But then comes the problem of initializing this class. There are a few options here.

Simple alloc/init

Let the clients deal with it by calling alloc, init and setting the property directly. This would mean that we need to keep the properties as readwrite

@interface Foo : NSObject
@property (nonatomic, copy) NSString *title;
@property (nonatomic, strong) Bar *bar;
@end

- (void)useFoo
{
  Foo *foo = [[Foo alloc] init];
  foo.title = @"hello";
  foo.bar = [[Bar alloc] init];

  NSLog(@"%@", foo.title);
  NSLog(@"%@", foo.bar);
}

This is probably the simplest solution out there, needs no extra care. But this would mean that anyone with access to the instance can update the properties anytime they like.

Custom Initializers

This is probably the most common way of creating instances with Objective-C. The idea is pretty simple, expose an initializer where clients can fill in all the properties, and all the properties at the interface are declared to be readonly

// Foo.h
@interface Foo : NSObject
- (instancetype)initWithTitle:(NSString *)title
                         bar:(Bar *)bar;
@property (nonatomic, readonly) NSString *title;
@property (nonatomic, readonly) Bar *bar;
@end

And provide a readwrite override in the implementation details.

// Foo.m
@interface Foo ()
@property (nonatomic, copy) NSString *title;
@property (nonatomic, strong) Bar *bar;
@end

@implementation Foo
- (instancetype)initWithTitle:(NSString *)title
                          bar:(Bar *)bar
{
  self = [super init];
  if (self) {
    _title = [title copy];
    _bar = bar;
  }
  return self;
}
@end

This solution is good for as long as not dealing with properties with default values. Imagine a initializer with a lot of properties and every time we have to call it, we have to provide the default values to properties. One standard solution is to provide telescope initializers, where an convenience initializer calls another initializer with some default value filled in until a designated initializer is invoked at the end of the pipeline which does the actual initialization

- (instancetype)initWithBar:(Bar *)bar;
{
  return [self initWithTitle:@"title" bar:bar];
}

- (instancetype)initWithTitle:(NSString *)title;
{
  return [self initWithTitle:title bar:[Bar bar]];
}

- (instancetype)initWithTitle:(NSString *)title
                          bar:(Bar *)bar 
{ 
  // usual stuff here ...
}

Again, works fine when the number of properties is not huge. These convenience initializers grow in size for every added property. And also sometimes it does not make clear sense which initializer to invoke, specially true if we need a selected subset of optional properties to be populated, we would need total initializers for every permutation.

Here’s chart of number of initializers we would need for a given number of properties

properties: 2, initializers: 3
properties: 3, initializers: 7
properties: 4, initializers: 15
properties: 5, initializers: 31
properties: 6, initializers: 63
properties: 7, initializers: 127
properties: 8, initializers: 255
properties: 9, initializers: 511
properties: 10, initializers: 1023

Woah! At first glance this does not really a scalable solution for sure! The good news is that usually we don’t need all of these initializers, since some properties only make sense together. Mostly we care to provide 2 or 3 initializers that are often used and let the client use the designated verbose one if case they need to have more control.

Subclass Factory Pattern

Going back to the first solution, I did like it a lot for the reason that it was pretty straightforward. The instance can set default values in the init and we explicitly override any properties we like

@interface Foo : NSObject
@property (nonatomic, copy) NSString *title;
@property (nonatomic, strong) Bar *bar;
@end

@implementation Foo
- (instancetype)init
{
  self = [super init];
  if (self) {
    _title = @"Default";
    _bar = [[Bar alloc] init];
  }
  return self;
}
@end

The only problem with this approach is that the properties remain readwrite forever. The technique I use is to have a factory subclass that has readwrite properties and the actual class only exposes the properties as readonly

@interface Foo : NSObject
@property (nonatomic, readonly) NSString *title;
@property (nonatomic, readonly) Bar *bar;
@end

@implementation Foo
@dynamic title;
@dynamic bar;
@end

The reason we set the properties to be dynamic because we don’t want the compiler to synthesize the properties.

// FooBuilder.h
@interface FooBuilder : Foo
@property (nonatomic, copy) NSString *title;
@property (nonatomic, strong) Bar *bar;
@end

// FooBuilder.m
@implementation FooBuilder 
{
  NSString *_title;
  Bar *_bar;
}

@synthesize title = _title;
@synthesize bar = _bar;

- (instancetype)init
{
  self = [super init];
  if (self) {
    _title = @"default";
    _bar = [[Bar alloc] init];
  }
  return self;
}
@end

We need to explicitly synthesize the properties otherwise the compiler will complain

Auto property synthesis will not synthesize property ‘title’ because it is ‘readwrite’ but it will be synthesized ‘readonly’ via another property

Finally, when creating the instance, we need to create the builder class first and override any properties we require.

FooBuilder *fooBuilder = [[FooBuilder alloc] init];
fooBuilder.title = @"hello";
// override properties here ...

Next we can implement the NSCopying for FooBuilder and provide a generate method to make things a little simpler:

@interface FooBuilder : Foo <NSCopying>
- (Foo *)generate;
@end

- (Foo *)generate
{
  return [self copy];
}

- (id)copyWithZone:(NSZone *)zone 
{
  FooBuilder *other = [[FooBuilder alloc] init];
  other.title = self.title;
  return other;
}

Here’s an usage example

- (void)useFoo
{
  FooBuilder *fooBuilder = [[FooBuilder alloc] init];
  fooBuilder.title = @"hello";

  Foo *foo = [fooBuilder generate];
  NSLog(@"%@", foo.title);
  NSLog(@"%@", foo.bar);
}

The important point to remember here is that any property that needs to be deep copied has to explicitly stated in the copyWithZone. For example, if we leave our implementation like:

- (id)copyWithZone:(nullable NSZone *)zone 
{
    return [[FooBuilder alloc] init];
}

We might get the default values for every generate

- (void)useFoo
{
  FooBuilder *fooBuilder = [[FooBuilder alloc] init];

  Foo *foo1 = [fooBuilder generate];
  NSLog(@"%@", foo1.title); // "default"
  NSLog(@"%@", foo1.bar); // <Bar: 0x6000019382b0>

  fooBuilder.title = @"hello";
  Foo *foo2 = [fooBuilder generate];
  NSLog(@"%@", foo2.title); // "default" <-- not "hello"
  NSLog(@"%@", foo2.bar); // <Bar: 0x6000019045c0>
}

Another thing to look out for is that Foo is now more like an abstract class with no implementation for properties, so we might crash at runtime if we try to initialize object directly like

Foo *foo = [[Foo alloc] init];
NSLog(@"%@", foo.title);

Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘-[Foo title]: unrecognized selector sent to instance 0x600000a941f0’

First solution that comes to mind is marking the init as NS_UNAVAILABLE to throw error ‘init’ is unavailable, but this would mean our factory subclass is also unavailable. This is another reason I do not the NS_UNAVAILABLE attribute which I believe was introduced without much thought but just for sake of making Objective-C interop with Swift.

The better solution would be to throw an exception

// Foo.m
- (instancetype)init;
{
  [NSException raise:NSInternalInconsistencyException format:@"Use [FooBuilder generate] instead"];
  return nil;
}

Although this would mean that the init is also not available to FooBuilder. One simple workaround could be provide an alternative designated initializer that is then only invoked from FooBuilder

// Foo.m
- (instancetype)initFromFactory
{
  return [super init];
}

// FooBuilder.m
- (instancetype)init
{
  self = [super initFromFactory];
  if (self) {
    _title = @"default";
    _bar = [[Bar alloc] init];
  }
  return self;
}

But this over engineering is only strictly optional, it saves nothing and makes code a little more complicated. The runtime should already raise an exception when trying to access any property from an instance directly created.

Objective-C safe downcasting

2020-02-23T12:34:00+00:00

Swift has this nice concept of optional chaining which is used in a lot of places. One really good use case is when down casting a type the operation becomes a no-op if casting to an incorrect sibling. To illustrate take a look at this Swift example code:

class FruitCompany {
  static var apple: FruitCompany { Apple() }
  static var orange: FruitCompany { Orange() }
}

class Apple: FruitCompany {
  func makeMoney() { print("💰") }
}

class Orange: FruitCompany {}

func makeMoney(with fruitCompany: FruitCompany) {
  (fruitCompany as? Apple)?.makeMoney()
}

func testOptional() {
  makeMoney(with: FruitCompany.apple) // Prints
  makeMoney(with: FruitCompany.orange) // Does nothing
}

Let’s see how this behaves in Objective-C

@interface Apple : FruitCompany
- (void)makeMoney;
@end

@interface Orange : FruitCompany
@end

@interface FruitCompany : NSObject
+ (instancetype)apple;
+ (instancetype)orange;
@end

@implementation FruitCompany
+ (instancetype)apple { return [Apple new]; }
+ (instancetype)orange { return [Orange new]; }
@end

@implementation Apple
- (void)makeMoney { NSLog(@"💰"); }
@end

@implementation Orange
@end

- (void)makeMoneyWithFruitCompany:(FruitCompany *)company
{
  [(Apple *)company makeMoney];
}

- (void)testOptional
{
  [self makeMoneyWithFruitCompany:[FruitCompany apple]]; // Prints
  [self makeMoneyWithFruitCompany:[FruitCompany orange]]; // Crash !!
}

A crash! This is the crash log

*** Terminating app due to uncaught exception 'NSInvalidArgumentException', 
    reason: '-[Orange makeMoney]: unrecognized selector sent to instance 0x6000024f8110'

Since Objective-C supports passing message to nil, so if we explicitly do a down casting to nil it works

- (void)makeMoneyWithFruitCompany:(FruitCompany *)company
{
  Apple *apple = [company isKindOfClass:[Apple class]] ? (Apple *)company : nil;
  [apple makeMoney];
}

So, how can we make this more aligned with Swift like. The first step would be to implement a Category on NSObject that does the casting magic.

@interface NSObject (WLSafeCast)
- (id)wl_safeCastToClass:(Class)aClass;
@end

@implementation NSObject (WLSafeCast)

- (id)wl_safeCastToClass:(Class)aClass;
{
  return [self isKindOfClass:aClass] ? self : nil;
}

@end

With this one can already start using it like

- (void)makeMoneyWithFruitCompany:(FruitCompany *)company
{
  Apple *apple = [company wl_safeCastToClass:[Apple class]];
  [apple makeMoney];
}

Next step we can implement the C MACRO

#define CAST_OR_NIL(v, T) [v wl_safeCastToClass:[T class]]

With that we can start using the Swift like down casting

- (void)makeMoneyWithFruitCompany:(FruitCompany *)company
{
  Apple *apple = CAST_OR_NIL(company, Apple);
  [apple makeMoney];
}

Or can even be reduced to one line

- (void)makeMoneyWithFruitCompany:(FruitCompany *)company
{
  [CAST_OR_NIL(company, Apple) makeMoney];
}

Do you know a better way? Please share your thought or let me know on twitter

Rx with Objective-C using NSInvocation

2020-02-21T17:00:00+00:00

I want to make a point that NSInvocation is a really powerful tool. If we do not care too much about a compiler type checking every single line of our code we can build a scalable Rx implementation using NSInvocation.

NSInvocation is an Objective-C message rendered as an object that can be passed around and invoked when required. Think of it as an old school closure which isn’t anonymous, rather opaque in nature and doesn’t implicitly captures any data, close to C++ lambda expressions. NSInvocation is just a simple wrapper around a function, function object would be the best term to describe it.

NSInvocation is very verbose. Here’s an example of an NSInvocation that captures the print: method:

NSInvocation *verbose = [NSInvocation invocationWithMethodSignature:
                                        [self methodSignatureForSelector:@selector(print:)]];
[verbose setTarget:self];
[verbose setSelector:@selector(print:)];

Since we are going to use NSInvocation quite a lot, it would be wise if we write a nice category to reduce verbosity a bit.

@implementation NSInvocation (RxConvenience)

+ (instancetype)invocationWithTarget:(id)target
                            selector:(SEL)selector
{
  NSInvocation *invoc = [NSInvocation invocationWithMethodSignature:
                         [target methodSignatureForSelector:selector]];
  [invoc setTarget:target];
  [invoc setSelector:selector];
  return invoc;
}

@end

With this change the same expression as above can now be written as:

NSInvocation *lessVerbose = [NSInvocation invocationWithTarget:self
                                            selector:@selector(print:)];

Rx

At the core of Rx is the idea of producers, consumers and events. A producer generates some events and a consumer listens to those events. Sometimes the data expected by the consumer is not exactly what the producer is emitting, in that case we need an operator that knows how to convert data from a form to another. Other times, a consumer needs to listen to events from more than one consumers, for that again we have an operator that can convert multiple data into a single data. As you can imagine these single purpose operators can be very powerful in building giant sophisticated systems for delivering events from producer to consumer. And this plumbing of many small components together to perform a bigger task is what makes Rx so great!

Observables

So, before we go on writing any code lets imagine how do wish our Rx API to look like from the client perspective. If we have a simple print: method as

- (void)print:(NSNumber *)num
{
  NSLog(@"%@", num);
}

We would like Rx to expose a way to create a producer and a way to consume the events, something like:

- (void)run
{
  RxObservable *stream = [RxObservable observableFromArray:@[@1, @2, @3]];
  NSInvocation *printInvoc = [NSInvocation invocationWithTarget:self
                                                selector:@selector(print:)];
  [stream subscribe:printInvoc];
}

As a initial step let’s define a base class called RxObservable that provides this interface. And since we don’t want to bloat this class with every spec implementation, let’s provide some factory methods to some internal implementation specific class.

@implementation RxObservable

+ (instancetype)observableFromArray:(NSArray *)array;
{
  return [RxArraySource createWithElements:array];
}

- (void)subscribe:(NSInvocation *)invocation;
{
    // Needs to be subclassed
}

@end

And then the actual implementation could look something like

@interface RxArraySource : RxObservable

+ (instancetype)createWithElements:(NSArray *)array;
- (void)subscribe:(NSInvocation *)invocation;

@end

@interface RxArraySource ()
@property (nonatomic, copy) NSArray *elements;
@end

@implementation RxArraySource

+ (instancetype)createWithElements:(NSArray *)elements;
{
  RxArraySource *instance = [RxArraySource new];
  instance.elements = elements;
  return instance;
}

- (void)subscribe:(NSInvocation *)invocation;
{
  for (id element in _elements) {
    [invocation setArgument:&element atIndex:2];
    [invocation invoke];
  }
}

@end

With that in place, our run method should be working as expected.

1
2
3

Operators

Next lets see how can we go about writing an Rx operator. One of the most commonly used Rx operator is the map operator which simply converts data from one type to another. Again, thinking upside down, how would we want our API to look like in the end.

If we have a standalone method like

- (NSNumber *)tenTimesOfNumber:(NSNumber *)num
{
  return [NSNumber numberWithInteger:[num integerValue] * 10];
}

We should be able to create a map operator which can then be plugged in with rest of the pipeline

- (void)run
{
  RxObservable *stream = [RxObservable observableFromArray:@[@1, @2, @3]];
  NSInvocation *printInvoc = [NSInvocation invocationWithTarget:self
                                            selector:@selector(print:)];
  NSInvocation *mapInvoc = [NSInvocation invocationWithTarget:self
                                 selector:@selector(tenTimesOfNumber:)];
  [[stream mapWithInvocation:mapInvoc] subscribe:printInvoc];
}

Lets extend our RxObservable to provide an interface for this, which again would be more like a factory method to an implementation specific class.

@implementation RxObservable

// ...

- (instancetype)mapWithInvocation:(NSInvocation *)invo
{
  return [RxMapOperator operatorFromStream:self withInvocation:invo];
}

@end

Notice since we are always passing RxObservable from our fat base class, we can easily chain RxObservables together. Now let’s go and write RxMapOperator

@interface RxMapOperator : RxObservable

+ (instancetype) operatorFromStream:(RxObservable *)stream
                     withInvocation:(NSInvocation *)invoc;

@end

The thing to realize with a map operator is that it knows not a lot about the actual types. It is provided with an actual implementation from the client that knows how to map types. So RxMapOperator only needs to chain two methods, take returned value from one and pass it down to the another.

@interface RxMapOperator ()
@property (nonatomic, strong) RxObservable *stream;
@property (nonatomic, strong) NSInvocation *invocUp;
@property (nonatomic, strong) NSInvocation *invocDown;
@end

@implementation RxMapOperator

+ (instancetype) operatorFromStream:(RxObservable *)stream
                     withInvocation:(NSInvocation *)invoc;
{
  RxMapOperator *instance = [RxMapOperator new];
  instance.stream = stream;
  instance.invocUp = invoc;
  return instance;
}

- (void)transform:(id)arg
{
  [self.invocUp setArgument:&arg atIndex:2];
  [self.invocUp invoke];

  id ret;
  [self.invocUp getReturnValue:&ret];

  [self.invocDown setArgument:&ret atIndex:2];
  [self.invocDown invoke];
}

- (void)subscribe:(NSInvocation *)invocation
{
  self.invocDown = invocation;
  [self.stream subscribe:[NSInvocation invocationWithTarget:self 
                                        selector:@selector(transform:)]];
}

@end

With that in place our run method should now print

10
20
30

Parting thoughts

This experiment was just to play around the idea of building something quick and dirty with NSInvocation. Obviously none of this code is production ready, but I think it can be expanded to cover all sort of building blocks for Rx patterns.

Here is the source code, feel free to checkout and play with it gist.github.com/chunkyguy/0f67f074c974aac7024d153011e5400e

Implementing enum with associated values in Objective-C

2020-02-16T12:14:00+00:00

Swift has this amazing thing called enum with associated value. Enums are traditionally used to represent a type system with finite set of values. But in real life each of those enum types sometimes have a need to associate some data. And the data of one enum type might be very different than the rest. Imagine writing a parser where each node is of type Node. We usually want to deal with Node as the type for doing things like passing Node around, or generate an array of Node. We might also have methods on Node, such as node.print() but Node can never be instantiated directly as n = Node().

Swift programming guide provides a good example of this pattern with Barcode that I’ve enhanced here a bit for readability:

// Barcode.swift
enum Barcode {
  case upc(
    numberSystem: Int,
    manufacturer: Int,
    product: Int,
    check: Int
  )

  case qrCode(productCode: String)

  func print() {
    switch self {
    case let .upc(numberSystem, manufacturer, product, check):
      Swift.print("UPC: \(numberSystem), \(manufacturer), \(product), \(check).")
    case let .qrCode(productCode):
      Swift.print("QR code: \(productCode).")
    }
  }
}

// Main.swift
func print(barcode: Barcode) {
  barcode.print()
}

func printBarcodes() {
  print(barcode: .upc(
    numberSystem: 10,
    manufacturer: 20,
    product: 30,
    check: 40
  ))

  print(barcode: .qrCode(productCode: "asdfa"))
}

How can we bring this pattern to Objective-C? This is how I think of the problem. Every use case of an enum with associated value can be represented as a subclass pattern, where every subclass is only a level deep. And the base class is an abstract class that can not be instantiated. The Barcode example from above might look something like:

With that in mind we can design our interface as:

// PLBarcode.h
@protocol PLBarcode <NSObject>
- (void)print;
@end

@interface PLBarcodeUPC : NSObject <PLBarcode>
+ (instancetype)barcodeWithNumberSystem:(NSInteger)numberSystem
                           manufacturer:(NSInteger)manufacturer
                                product:(NSInteger)product
                                  check:(NSInteger)check;
@end

 @interface PLBarcodeQR : NSObject <PLBarcode>
+ (instancetype)barcodeWithProductCode:(NSString *)productCode;
@end

Notice that we are not actually subclassing any implementation class from any common base PLBarcode class. This keeps every implementation class completely independent of each other with no shared hierarchy. We can use PLBarcode as the type that can easily pass around:

// Main.m
- (void)printBarcode:(id<PLBarcode>)barcode
{
  [barcode print];
}

- (void)printBarcodes
{
  [self printBarcode:[PLBarcodeUPC barcodeWithNumberSystem:10
                                              manufacturer:20
                                                   product:30
                                                     check:40]];
  [self printBarcode:[PLBarcodeQR barcodeWithProductCode:@"asfsdf"]];
}

Another advantage of enums is that we don’t have to deal with so many explicit types as we have here with PLBarcodeUPC and PLBarcodeQR. I can imagine adding more implementation types would require bombarding the clients of PLBarcode with many implementation types that they don’t actually care about. Thinking again, what we need is the following:

A way to instantiate PLBarcode with unrelated data.
Ability to send messages to PLBarcode which should be handled by the implementation type.

With that in mind, we can solve this problem by moving all the implementation subclasses internally to PLBarcode.m and expose only typeless class methods in PLBarcode.h, like a factory pattern

// PLBarcode.h
@protocol PLBarcode <NSObject>
- (void)print;
@end

@interface PLBarcode : NSObject
+ (id<PLBarcode>)barcodeWithNumberSystem:(NSInteger)numberSystem
                            manufacturer:(NSInteger)manufacturer
                                 product:(NSInteger)product
                                   check:(NSInteger)check;

+ (id<PLBarcode>)barcodeWithProductCode:(NSString *)productCode;
@end

// PLBarcode.m
@interface __PLBarcodeUPC : NSObject <PLBarcode>
+ (instancetype)barcodeWithNumberSystem:(NSInteger)numberSystem
                           manufacturer:(NSInteger)manufacturer
                                product:(NSInteger)product
                                  check:(NSInteger)check;
@end

@interface __PLBarcodeQR : NSObject <PLBarcode>
+ (instancetype)barcodeWithProductCode:(NSString *)productCode;
@end

@implementation PLBarcode

+ (id<PLBarcode>)barcodeWithNumberSystem:(NSInteger)numberSystem
                            manufacturer:(NSInteger)manufacturer
                                 product:(NSInteger)product
                                   check:(NSInteger)check;
{
  return [__PLBarcodeUPC barcodeWithNumberSystem:numberSystem
                                  manufacturer:manufacturer
                                       product:product
                                         check:check];
}

+ (id<PLBarcode>)barcodeWithProductCode:(NSString *)productCode;
{
  return [__PLBarcodeQR barcodeWithProductCode:productCode];
}
@end

With that change the call site looks much cleaner:

- (void)exampleBarcode
{
  [self printBarcode:[PLBarcode barcodeWithNumberSystem:10
                                           manufacturer:20
                                                product:30
                                                  check:40]];
  [self printBarcode:[PLBarcode barcodeWithProductCode:@"asfsdf"]];
}

Resources

Class Clusters Pattern • developer.apple.com

State of Meta Programming in 2020

2020-02-10T21:28:54+00:00

We all know what meta programming is. We all have tasted that medicine at some point in our lives. The basic idea is that first there is a level of coding we all are familiar with. Usually it is full of fun and excitement. Other times it becomes a bit repetitive, usually when we find ourselves copy pasting some code over and over again and we wish there were an another higher level of code that take over this job.

To help with meta programs we have designed a plethora of tools, both standalone and integrated deep within our every day text editors. Some programming languages even went a step further and integrated support for meta programming deep inside the language itself, others integrated meta programming support in the runtime.

Today I want to take a look at all the options available in programming languages I’m most familiar with. Hoping this would cover most of the programming languages out there.

Problem

Let’s say we had a simple clean sum function which was originally designed to take an array of integers and always returned a integer. Next, we want to have a almost the same function but for many other types, like floating points, string or even color which would sum the red, blue and green components such that an array of red, green and blue would return same value as of the color white.

External tools

Before we even go into any language specific solution, I think it is wise to mention that there are several templating tools that would love help with this job by simply generating source code from a template.

Here’s an sample of how a template might look like:

%{
supported_types = ['Color', 'String', 'Double', 'Float',
                 'Int', 'Int8', 'Int16', 'Int32', 'Int64',
                 'UInt', 'UInt8', 'UInt16', 'UInt32', 'UInt64']
}%

% for type in supported_types:
func sum(elements: [${type}]) -> Int {
  var s = 0
  for element in elements {
    s += element
  }
  return s
}
% end

Pros

These tools get the job done with minimal overhead.
Have a pretty good community support.

Cons

Hard to validate the output
There is a learning curve involved to learn the syntax expected by the templating engine.
The tools have to be constantly upgraded as the target language evolves.
Every change has to be done externally.

C

Here’s a very simple implementation of the sum function in C.

int sum(int *elements, int count) {
  int s = 0;
  for (int i = 0; i < count; ++i) {
    s += elements[i];
  }
  return s;
}

printf("%d\n", sum((int []){1,2,3,4}, 4)); // 10

C is pretty straightforward as far as meta programming is concerned. It doesn’t support any meta programming in the traditional sense. There is a bit of preprocessing one can do to achieve a bit of template like solution.

#define gen_sum(T) int sum_##T(T *elements, int count) { \
  int s = 0; \
  for (int i = 0; i < count; ++i) { \
    s += elements[i]; \
  } \
  return s; \
}

gen_sum(int)
gen_sum(float)

printf("%d\n", sum_int((int []){1,2,3,4}, 4)); // 10
printf("%d\n", sum_float((float []){1.0,2.0,3.0,4.0}, 4)); // 10

Things start getting a bit uglier for types that can not be automatically converted to int, like say a string.

typedef char * str;
gen_sum(str)

If we take a look inside, this is what the preprocessor generates:

int sum_str(char ** elements, int count) { 
  int s = 0; 
  for (int i = 0; i < count; ++i) { 
    s += elements[i]; // int + char*
  } 
  return s; 
}

The solution is to delegate the s += element[i] out of here. We want to make this behave as

s += atoi((char *)element[i])

The idea is to use a function pointer to serve as callback that takes in T and returns int. For basic fundamental types we can pass NULL which would then fallback to whatever we had.

#define gen_sum(T) int sum_##T(T *elements, int count, int(*f)(T)) { \
  int s = 0; \
  for (int i = 0; i < count; ++i) { \
    if (f == NULL) { s += elements[i]; } \
    else { s += f(elements[i]); } \
  } \
  return s; \
}

gen_sum(int)
gen_sum(float)

typedef char * str;
gen_sum(str)

printf("%d\n", sum_int((int []){1,2,3,4}, 4, NULL));
printf("%d\n", sum_float((float []){1.0,2.0,3.0,4.0}, 4, NULL));
printf("%d\n", sum_str((str []){"1", "2", "3", "4"}, 4, atoi));

Sweet! How about custom types?

typedef struct color_t {
  int r, g, b;
} color;

int color_value(color c) {
  return (c.r << 16) + (c.g << 8) + c.b;
}

gen_sum(color)

printf("%d\n", sum_color((color []){ {1, 0, 0}, {0, 1, 0}, {0, 0, 1} }, 3, color_value));

The compiler will complain about s += elements[i]; even though that line of code should never even execute at runtime as f is not NULL. The problem is because the compiler can not figure out how to generate code for int + color. The solution is to drop the fallback case and always pass in a function pointer.

#define gen_sum(T) int sum_##T(T *elements, int count, int(*f)(T)) { \
  int s = 0; \
  for (int i = 0; i < count; ++i) { \
    s += f(elements[i]); \
  } \
  return s; \
}

Now, for fundamental types we can create another template that just generates a direct mapping. Something like:

#define gen_convert(T) int to_##T(T x) { return x; }

gen_convert(int); // generates: int to_int(int x) { return x; };

With that we can call all sort of types:

printf("%d\n", sum_int((int []){1, 2, 3, 4}, 4, to_int));
printf("%d\n", sum_float((float []){1.0, 2.0, 3.0, 4.0}, 4, to_float));
printf("%d\n", sum_str((str []){"1", "2", "3", "4"}, 4, atoi));
printf("%d\n", sum_color((color []){ {1, 0, 0}, {0, 1, 0}, {0, 0, 1} }, 3, color_value));

This is the entire code:

#define gen_convert(T) int to_##T(T x) { return x; }

#define gen_sum(T) int sum_##T(T *elements, int count, int(*f)(T)) { \
  int s = 0; \
  for (int i = 0; i < count; ++i) { \
    s += f(elements[i]); \
  } \
  return s; \
}

gen_sum(int)
gen_convert(int)

gen_sum(float)
gen_convert(float)

typedef const char * str;
gen_sum(str)

typedef struct color_t {
  int r, g, b;
} color;

gen_sum(color)

int color_value(color c) {
  return (c.r << 16) + (c.g << 8) + c.b;
}

void test_sum() {
  printf("%d\n", sum_int((int []){1, 2, 3, 4}, 4, to_int));
  printf("%d\n", sum_float((float []){1.0, 2.0, 3.0, 4.0}, 4, to_float));
  printf("%d\n", sum_str((str []){"1", "2", "3", "4"}, 4, atoi));
  printf("%d\n", sum_color((color []){ {1, 0, 0}, {0, 1, 0}, {0, 0, 1} }, 3, color_value));
}

Pros

No need for an external build system.

Cons

Hard to read code

C++

C++ comes with all sort of meta programming goodies built in. People have been known to go crazy over how awesome the meta programming actually is. I’ve seen people making amazing thing with just the meta programming, for example a Tetris game at compile time!

So coming from C, building the solution in C++ should be a lot easier.

template <typename T>
int sum(const std::vector<T> &v) {
  int s = 0;
  for (const T element : v) {
    s += element;
  }
  return s;
}

std::vector<int> v1 = {1,2,3,4};
std::cout << "int: " << sum(v1) << std::endl; // 10

std::vector<float> v2 = {1.0,2.0,3.0,4.0};
std::cout << "float: " << sum(v2) << std::endl; // 10

The C++ solution is surprisingly very flexible. It might even inconveniently work for types we didn’t expect it to.

std::vector<char> v3 = {'a', 'b', 'c'};
std::cout << "char: " << sum(v3) << std::endl; // 294

std::vector<bool> v4 = {true, false};
std::cout << "bool: " << sum(v4) << std::endl; // 1

For thing where this might fail, like string, the C++ solution is to provide an overload

int sum(const std::vector<std::string> &v) {
  int s = 0;
  for (const std::string & element : v) {
    s += std::stoi(element);
  }
  return s;
}

std::vector<std::string> v5 = {"1", "2", "3", "4"};
std::cout << "string: " << sum(v5) << std::endl;

This exact solution also applies to any of our custom types

struct color {
  int r, g, b;

  int value() const {
    return (r << 16) + (g << 8) + b;
  }
};

int sum(const std::vector<color> &v) {
  int s = 0;
  for (const color & element : v) {
    s += element.value();
  }
  return s;
}

Pros

Flexibility
Amazing compiler support

Cons

Might accidentally work for non-supported types

Swift

I feel Swift is very heavily influenced by C++. So it shouldn’t come as any surprise that Swift supports very good meta programming with generics. If our simple sum looks something like:

func sum(elements: [Int]) -> Int {
  var s = 0;
  for element in elements {
    s += element
  }
  return s
}

print("\(sum(elements: [1, 2, 3, 4]))") // 10

The generic version is not very different:

func sum<T>(elements: [T]) -> Int {
  var s = 0;
  for element in elements {
    s += element
  }
  return s
}

But this is where things start diverging apart. Swift is very strict with it’s type checking. So strict that a few times it might even come out as annoying for simple use cases, at least simple inside our head. If we try to call this with Int we get an error:

print("\(sum(elements: [1, 2, 3, 4]))")

Cannot convert value of type ‘T’ to expected argument type ‘Int’

The problem above is with s += element. The compiler can not perform + between Int and T because unlike C++, Swift assumes nothing about T. So we need to provide exact information to the compiler of what T is capable of.

Simplest solution here could be to get rid of Int and provide a T: AdditiveArithmetic conformance. Since both Int and Double already conform to AdditiveArithmetic we won’t have to do anything more.

Another problem might be that s = 0 is not available for T, but we can workaround by providing that as an additional param.

func sum<T>(initial: T, elements: [T]) -> T where T: AdditiveArithmetic {
  var s = initial;
  for element in elements {
    s += element
  }
  return s
}

print("\(sum(initial: 0, elements: [1, 2, 3, 4]))") // 10
print("\(sum(initial: 0, elements: [1.0, 2.0, 3.0, 4.0]))") // 10

This is looking like close to the standard reduce function, and now we know why.

When we need to expand our sum function to non-trivial types, like say the String, we face another error:

print("\(sum(initial: "0", elements: ["1", "2", "3", "4"]))") 

Error: Argument type ‘String’ does not conform to expected type ‘AdditiveArithmetic’

We could continue by explicitly provide a conformance for String: AdditiveArithmetic. This could be a way to go if we knew that the sum function only needs to handle a limited types. Or if modifying sum was outside our control. Or we can simply rollback to our previous implementation and make that work.

Remember, our original solution was as simple as func sum<T>(elements: [T]) -> Int. How can we make this work for String? In the earlier solution the problem was with + not working for Int and T. How about providing a protocol that converts any type to Int?

protocol IntegerConvertible {
  var intValue: Int? { get }
}

Then our sum can be simplified back:

func sum<T>(elements: [T]) -> Int where T: IntegerConvertible {
  var s = 0;
  for element in elements {
    if let v = element.intValue {
      s += v
    }
  }
  return s
}

We need every type to provide their own way to implement intValue. Which is trivial for types we are covering so far

extension Int: IntegerConvertible {
  var intValue: Int? { return self }
}

extension Double: IntegerConvertible {
  var intValue: Int? { return Int(self) }
}

extension String: IntegerConvertible {
  var intValue: Int? { return Int(self) }
}

The beauty of this easy and flexible solution is that it’s really easy to extend to any new type.

extension CGColor: IntegerConvertible {
  var intValue: Int? {
    guard let comps = self.components else {
      return nil
    }
    // probably unsafe access!!
    let r = comps[0]
    let g = comps[1]
    let b = comps[2]
    return (Int(r * 255.0) << 16) + (Int(g * 255.0) << 8) + (Int(b * 255.0));
  }
}

Pros

Type checking from compiler

Cons

Very verbose

Objective-C

With Objective-C meta programming is actually more fun than with Swift or C++. Personally I feel like it’s a very different dimension of meta programming not available in other programming languages I know of.

Remember the basic idea behind meta programming is to first write a simple solution and later extend it to work any type. With that in mind, this is our basic Adder class for NSNumber types:

@interface Adder : NSObject
@property (nonatomic, copy) NSArray *elements;
@property (nonatomic, readonly) NSInteger sum;
+ (instancetype)adderWithElements:(NSArray *)elements;
@end

@implementation Adder

+ (instancetype)adderWithElements:(NSArray *)elements
{
  Adder *addr = [[Adder alloc] init];
  addr.elements = elements;
  return addr;
}

- (NSInteger)sum
{
  NSInteger s = 0;
  for (NSNumber *element in self.elements) {
    s += [element integerValue];
  }
  return s;
}
@end

NSLog(@"ints: %ld", [[Adder adderWithElements:@[@1, @2, @3, @4]] sum]);

Since Objective-C is not so strict at compile time, we need to make sure that every element in NSArray has implemented the integerValue method. One way to achieve this is

- (NSInteger)sum
{
  NSInteger s = 0;
  for (id element in self.elements) {
    if ([element respondsToSelector:@selector(integerValue)]) {
      s += [element integerValue];
    }
  }
  return s;
}

And that’s it! We are done! This works for every type you can imagine!

NSLog(@"ints: %ld", [[Adder adderWithElements:@[@1, @2, @3, @4]] sum]);
NSLog(@"floats: %ld", [[Adder adderWithElements:@[@1.0, @2.0, @3.0, @4.0]] sum]);
NSLog(@"strings: %ld", [[Adder adderWithElements:@[@"1", @"2", @"3", @"4"]] sum]);

But what for custom types that do not provide integerValue out of the box? The good news is that it won’t crash at runtime, but the bad news is that it won’t return anything meaningful either.

NSLog(@"colors: %ld",
       [[Adder adderWithElements:@[
        [UIColor redColor],
        [UIColor greenColor],
        [UIColor blueColor]]] sum]); // colors: 0

But it’s relatively easy to extend support for any custom type.

@interface UIColor (AdderSupport)
@end

@implementation UIColor (AdderSupport)
- (NSInteger)integerValue
{
  CGFloat r,g,b;
  [self getRed:&r green:&g blue:&b alpha:nil];
  return ((NSInteger)(r * 255.0) << 16) + ((NSInteger)(g * 255.0) << 8) + ((NSInteger)(b * 255.0));
}
@end

Pros

Very easy to work with.

Cons

Easy to run into unexpected situations at runtime

Final words

Every meta programming exercise starts out with a pretty simple problem, at least in our head. “I’ve this thing that works only for one specific case. How can I make this thing work for this other type as well?”. Several hours later we find ourselves in this labyrinth of generic types where there are things with the sole purpose of describing the constraint environment. Then there are few things that are not required to actually solve the problem but might serve as a guideline on how things are supposed to work, particularly useful if the solution ever needs an expansion, say a note for the future maintainer written in pure code and conveniently type checked by the compiler. And then finally there are things that actually solve the original problem.

This is a more true with Swift than with C++ where so many requirements we have to explicitly specified otherwise the compiler will get mad. On the other hand with C++, the compiler asks for nothing beforehand, but there are a few things one is somehow expected to know, otherwise the compiler will get mad.

I think the best strategy when going down the meta programming rabbit hole is to follow these steps:

The first draft should be very short, clean, concise and to the point. No wondering about cases that do not yet exists.
When expanding for another type avoid overthinking. Implement the algorithm that provides a solution for just the finite type subset required. So no over abstract protocols, no complex types. Focus is the key here. Remember we can always expand the code for more types when the requirement actually arrives.

Objective-C and parsing the unknown

2020-02-06T21:28:54+00:00

So there’s this pattern I encounter every now and then. There is a service that returns some json data. The json data has some polymorphic behavior built-in. What I mean by that is that there is a root node that describes the behavior of the contained child node, which could be different for every child. To provide an example, lets say we are building a sort of a design system where the components are going to be provided by the server. The client then needs to parse the components and render them on screen.

So there could be an Image component which looks like:

{
    "type": "Image",
    "props": {
        "image": "https://via.placeholder.com/300/09f/fff.png",
        "width": 300,
        "height": 300
    }
}

Similarly there could be Text component which looks like:

{
    "type": "Text",
    "props": {
        "text": "This is a text",
        "font-size": 12
    }
}

And many more components to come.

Swift solution

With Swift, the solution I’ve seen implemented in most of the places is to use a giant switch somewhere most like with cyclomatic complexity disabled for the linter. Something like this:

typealias JSON = [String: Any]

func parse(json: JSON) -> Component? {
  guard
    let type = json["type"] as? String,
    let props = json["props"] as? JSON else {
    return nil
  }

  switch type {
  case "Image": return ImageComponent.parse(props: props)
  case "Text": return TextComponent.parse(props: props)
  default: return nil
  }
}

We can try making this less error prone by hiding raw String behind an enum like:

guard 
  let type = (json["type"] as? String).flatMap(ComponentType.init),
  let props = json["props"] as? JSON else {
  return nil
}
switch type {
  case .image: return ImageComponent.parse(props: props)
  case .text: return TextComponent.parse(props: props)
  default: return nil
}

But still there’s no easy way to get rid of that switch statement.

The problem

What’s wrong with that switch statement anyways?

Turns out everything. Behind the scene a switch statement is just an if-else like conditional branching with some syntactic sugar. This sort of type based conditional branching is against everything Object Oriented Programming advocates.

One of the core ideas of OOP is to promote polymorphism over switch statements. In fact, most of the text books start out by an example where there’s a giant switch statement somewhere and clean it up by writing an abstract implementation that is then implemented by every type in its own ways.

You can find many interesting articles that describe this in great details.

Objective-C solution

With Objective-C this is an easy fix because we can parse the type and construct the class name at runtime. And then send the parse message to it.

- (id)parseComponentJSON:(NSDictionary *)componentDict
{
  NSString *type = [componentDict objectForKey:@"type"];
  NSString *componentName = [type stringByAppendingString:@"Component"];
  Class componentClass = NSClassFromString(componentName);
  if (componentClass == nil) {
    NSLog(@"%@ not found", componentName);
    return nil;
  }

  id component = [[componentClass alloc] init];
  if (![component respondsToSelector:@selector(parseJSON:)]) {
    return nil;
  }
  [component performSelector:@selector(parseJSON:)
                  withObject:[componentDict objectForKey:@"props"]];
  return component;
}

The components then can be implement as:

@interface ImageComponent : NSObject
@property (nonatomic, strong) NSURL* imageURL;
@property (nonatomic, assign) CGSize size;

- (void)parseJSON:(NSDictionary *)json;
@end

@implementation ImageComponent
- (void)parseJSON:(NSDictionary *)json;
{
  self.imageURL = [NSURL URLWithString:[json objectForKey:@"image"]];
  self.size = CGSizeMake([[json objectForKey:@"width"] doubleValue],
                         [[json objectForKey:@"height"] doubleValue]);
}

- (NSString *)description
{
  return [NSString stringWithFormat:@"%@, %@",
          self.imageURL,
          NSStringFromCGSize(self.size)];
}
@end

And another unrelated component

@interface TextComponent : NSObject
@property (nonatomic, strong) NSString* text;
@property (nonatomic, assign) double fontSize;

- (void)parseJSON:(NSDictionary *)json;
@end

@implementation TextComponent
- (void)parseJSON:(NSDictionary *)json
{
  self.text = [json objectForKey:@"text"];
  self.fontSize = [[json objectForKey:@"font-size"] doubleValue];
}

- (NSString *)description
{
  return [NSString stringWithFormat:@"%@, %.2f", self.text, self.fontSize];
}
@end

The beauty of this solution is that there is no giant switch statement anywhere. Whenever a new Component is introduced we only have to add another class that knows how to decode the props of that component.

If we want to make this more protocol oriented, we can have a proper Component type that provides an interface for how a Component should look like.

@interface Component : NSObject
- (void)parseJSON:(NSDictionary *)json;
@end

@implementation Component
- (void)parseJSON:(NSDictionary *)json;
{
  [NSException raise:@"AbstractMethod" format:@"Not implemented"];
}
@end

And if we’re that far, we can even make the signature is bit more clean to avoid having 2 steps; One for [[class alloc] init] and other for [instance parseJSON: json]

@interface Component : NSObject
+ (instancetype)componentWithJSON:(NSDictionary *)json;
@end

@implementation Component
+ (instancetype)componentWithJSON:(NSDictionary *)json;
{
  [NSException raise:@"AbstractMethod" format:@"Not implemented"];
  return nil;
}
@end

With that our parser simply looks like:

- (Component *)parseComponentJSON:(NSDictionary *)componentDict
{
  NSString *type = [componentDict objectForKey:@"type"];
  NSString *componentName = [type stringByAppendingString:@"Component"];
  Class componentClass = NSClassFromString(componentName);
  return [componentClass componentWithJSON:[componentDict objectForKey:@"props"]];
}

Now if you notice we’re not checking of any nil. That is because sending messages to nil is safe and very well documented behavior.

If the method returns an object, then a message sent to nil returns 0 (nil).

This means that we don’t have to check for intermediate nil if we our method is designed to return nil if parsing fails. So, we can even clean up further by removing all temporary variables in our parser

- (Component *)parseComponentJSON:(NSDictionary *)componentDict
{
  NSString *componentName = [[componentDict objectForKey:@"type"] stringByAppendingString:@"Component"];
  return [NSClassFromString(componentName) componentWithJSON:[componentDict objectForKey:@"props"]];
}

This is entire code:

@interface Component : NSObject
+ (instancetype)componentWithJSON:(NSDictionary *)json;
@end

@implementation Component
+ (instancetype)componentWithJSON:(NSDictionary *)json;
{
  [NSException raise:@"AbstractMethod" format:@"Not implemented"];
  return nil;
}
@end

@interface ImageComponent : Component
@property (nonatomic, strong) NSURL* imageURL;
@property (nonatomic, assign) CGSize size;

+ (instancetype)componentWithJSON:(NSDictionary *)json;
@end

@implementation ImageComponent
+ (instancetype)componentWithJSON:(NSDictionary *)json;
{
  ImageComponent *component = [[ImageComponent alloc] init];
  component.imageURL = [NSURL URLWithString:[json objectForKey:@"image"]];
  component.size = CGSizeMake([[json objectForKey:@"width"] doubleValue],
                         [[json objectForKey:@"height"] doubleValue]);
  return component;
}

- (NSString *)description
{
  return [NSString stringWithFormat:@"%@, %@",
          self.imageURL,
          NSStringFromCGSize(self.size)];
}
@end

@interface TextComponent : Component
@property (nonatomic, strong) NSString* text;
@property (nonatomic, assign) double fontSize;

+ (instancetype)componentWithJSON:(NSDictionary *)json;
@end

@implementation TextComponent
+ (instancetype)componentWithJSON:(NSDictionary *)json;
{
  TextComponent *component = [[TextComponent alloc] init];
  component.text = [json objectForKey:@"text"];
  component.fontSize = [[json objectForKey:@"font-size"] doubleValue];
  return component;
}

- (NSString *)description
{
  return [NSString stringWithFormat:@"%@, %.2f", self.text, self.fontSize];
}
@end

@interface ComponentParser : NSObject
- (NSArray *)parseComponentsWithData:(NSData *)data;
@end

@implementation ComponentParser

- (Component *)parseComponentJSON:(NSDictionary *)componentDict
{
  NSString *componentName = [[componentDict objectForKey:@"type"] stringByAppendingString:@"Component"];
  return [NSClassFromString(componentName) componentWithJSON:[componentDict objectForKey:@"props"]];
}

- (NSArray *)parseComponentsWithData:(NSData *)jsonData
{
  NSError *error = nil;
  NSDictionary *componentDict = [NSJSONSerialization JSONObjectWithData:jsonData
                                                            options:NSJSONReadingFragmentsAllowed
                                                              error:&error];
  NSAssert(error == nil, @"Parsing failure %@", [error localizedDescription]);

  NSArray *componentJSONs = [componentDict objectForKey:@"components"];
  NSMutableArray *components = [NSMutableArray arrayWithCapacity:[componentJSONs count]];
  for (NSDictionary *componentJSON in componentJSONs) {
    Component *component = [self parseComponentJSON:componentJSON];
    if (component != nil) {
      [components addObject:component];
    } else {
      NSLog(@"Unable to parse %@", componentJSON);
    }
  }
  return components;
}

@end

@interface Test : NSObject
- (void)run;
@end

@implementation Test

- (void)run
{
  NSError *error = nil;
  NSURL *path = [[NSBundle mainBundle] URLForResource:@"components" withExtension:@"json"];
  NSAssert(path != nil, @"No path");

  NSData *jsonData = [NSData dataWithContentsOfURL:path options:NSDataReadingMappedIfSafe error:&error];
  NSAssert(error == nil, @"File read failed %@ | %@", path, [error localizedDescription]);

  ComponentParser *parser = [[ComponentParser alloc] init];
  NSArray *components = [parser parseComponentsWithData:jsonData];

  NSLog(@"total components: %ld", [components count]);

  for (Component *component in components) {
    NSLog(@"%@", [component description]);
  }
}

@end

And a sample output with one component not implemented

Unable to parse {
    props =     {
        link = "https://whackylabs.com";
    };
    type = Web;
}
total components: 2
https://via.placeholder.com/300/09f/fff.png, {300, 300}
This is a text, 12.00

The more I think about it, I think very few languages provide a clean way to express OOP patterns. And in this case Objective-C seems to be cleaner implementation than Swift.

If you know of a better way to solve this problem in Swift like languages, please let me know on twitter

References

Implementing callback with NSInvocation

2020-01-02T21:28:54+00:00

Let’s say we wanted to write a callback with NSInvocation. Why would you need that? Maybe you do not like the block syntax, or maybe you do not like how blocks capturing works, or maybe you’re working with a really old codebase which can not use blocks.

Anatomy of a callback

Anyone who has been writing software for a while knows what a callback is. I struggled a bit when I first encountered the concept for the first time. In my novice head programs were simple chain of procedures that execute one after the other. Like, flowA -> flowB. I had never experienced a flow where a procedure would need to be interrupted for a while and then resume where it left. Like flow_begin -> interrupt -> flow_end.

I distinctly remember the day I first encountered the signal API.

void (*signal (int, void (*)(int))) (int);

If this is the first time you’re looking at the monstrosity, let me break it down in simpler words. signal is a function that takes in 2 arguments, a int signal value and a function pointer of type void (*)(int) and returns a function pointer of type void (*)(int). The function pointers here represent callbacks.

Another simpler example is of the C standard library quicksort:

void qsort( void *ptr, size_t count, size_t size,
            int (*comp)(const void *, const void *) );

The interesting thing here is that qsort takes in a comp as a callback. So the algorithm can simply work on some abstract level as long as a user provides the comparison function.

Callback with Delegation

All modern languages provide a simpler way to represent callbacks. Objective-C since 2011 supports blocks, which although looks very similar to C function pointer but is a lot more than just simple callbacks. A block also capture the current state of stack implicitly that helps a lot with sharing data between flow_begin, interrupt and flow_end.

Before blocks, there were some old school ways of handling callbacks in Objc. One the most used pattern was to use delegation, which went something like:

Define a protocol for the interrupt
Flow is injected with a instance that conforms to protocol, called a delegate
Whenever required the flow calls the delegate methods.

As an example, the qsort above might be written in Objc as:

@protocol PLComparison <NSObject>
- (int)compare:(void *)first to:(void *)second;
@end

@interface PLQSort : NSObject
- (void)qsortData:(void *)data count:(size_t)count
  compareDelegate:(id<PLComparison>)delegate;
@end

Callback with Block

These days blocks are the most accepted way of implementing a callback. This is even more true with swift. The idea is very simple.

Define a method signature

typedef void(^PLCalcAddCompletion)(NSInteger);

Define a method that implements the flow

@interface PLNonEscapingCalc : NSObject
- (void)add:(NSInteger)first
       with:(NSInteger)second
      block:(PLCalcAddCompletion)block;
@end

@implementation PLNonEscapingCalc
- (void)add:(NSInteger)first
       with:(NSInteger)second
      block:(PLCalcAddCompletion)block;
{
  NSInteger sum = first + second;
  block(sum);
}
@end

Call the flow and inject the callback

- (void)run
{
  PLNonEscapingCalc *calc = [[PLNonEscapingCalc alloc] init];
  [calc add:10 with:20 block:^(NSInteger sum) {
    [self print:sum];
  }];
  [calc release];
}

- (void)print:(NSInteger)sum
{
  NSLog(@"sum: %ld\n", sum);
}

With blocks the PLNonEscapingCalc has to know nothing about its caller, as all the type information it needs is available right there in the signature.

Callback with NSInvocation

With NSInvocation the flow is very much the same.

Define a method that implements the flow. But since this is Objc, let the runtime figure out the callback signature for later.

@interface PLNonEscapingCalc : NSObject
- (void)add:(NSInteger)first
       with:(NSInteger)second
 invocation:(NSInvocation *)invocation;
@end

@implementation PLNonEscapingCalc
- (void)add:(NSInteger)first
       with:(NSInteger)second
 invocation:(NSInvocation *)invocation;
{
  NSInteger sum = first + second;
  [invocation setArgument:&sum atIndex:2];
  [invocation invoke];
}
@end

Notice that we set the argument as index 2. This because in Objc index 0 and 1 are reserved for receiver and selector. We have to provide those values from the other end:

- (void)run
{
  PLNonEscapingCalc *calc = [[PLNonEscapingCalc alloc] init];
  NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:
                              [self methodSignatureForSelector:
                               @selector(print:)]];
  [invocation setTarget:self];
  [invocation setSelector:@selector(print:)];
  [calc add:30 with:40 invocation:invocation];
  [calc release];
}

With NSInvocation approach the PLNonEscapingCalc knows absolutely nothing about its caller. The only thing it cares about is to set data at index 2. So, we rely on a proper documentation on make sure the contract is valid.

Build a networking layer

For a final exercise, lets try to build a NSURLSession like API but based on NSInvocation instead of blocks.

First we need something to hold the NSInvocation and the NSData as the NSURLSessionDataDelegate might return partial data. From the doc:

This delegate method may be called more than once, and each call provides only data received since the previous call. The app is responsible for accumulating this data if needed.

@interface PLNetworkTask : NSObject
{
  NSURLSessionTask *_task;
  NSMutableData *_data;
  NSInvocation *_invocation;
}
@property (nonatomic, readonly) NSURLSessionTask *task;
@end

@implementation PLNetworkTask
+ (instancetype)futureWithTask:(NSURLSessionTask *)task
                    invocation:(NSInvocation *)invocation
{
  return [[[self alloc] initWithTask:task
                          invocation: invocation] autorelease];
}

- (instancetype)initWithTask:(NSURLSessionTask *)task
                  invocation:(NSInvocation *)invocation
{
  self = [super init];
  if (self) {
    _task = [task retain];
    _data = [[NSMutableData alloc] init];
    _invocation = [invocation retain];
  }
  return self;
}

- (void)dealloc
{
  [_invocation release];
  [_task release];
  [_data release];
  [super dealloc];
}

- (void)appendData:(NSData *)data
{
  [_data appendData:data];
}

- (void)completeWithError:(NSError *)error
{
  [_invocation setArgument:&_data atIndex:2];
  [_invocation setArgument:&error atIndex:3];
  [_invocation invoke];
}
@end

Next we need something like a NSURLSession than manages many PLNetworkTask.

@interface PLNetworkSession() <NSURLSessionDataDelegate>
{
  NSURLSession *_session;
  NSMutableArray *_tasks;
  NSOperationQueue *_sessionQueue;
}
@end

@implementation PLNetworkSession

- (instancetype)init
{
  self = [super init];
  if (self) {
    _sessionQueue = [[NSOperationQueue alloc] init];
    [_sessionQueue setMaxConcurrentOperationCount:1];
    _tasks = [[NSMutableArray alloc] init];
    _session = [[NSURLSession sessionWithConfiguration:
                 [NSURLSessionConfiguration defaultSessionConfiguration]
                                              delegate:self
                                         delegateQueue:_sessionQueue]
                retain];
  }
  return self;
}

- (void)dealloc
{
  [_sessionQueue release];
  [_tasks release];
  [_session release];
  [super dealloc];
}

- (void)dispatchRequest:(NSURLRequest *)request
             invocation:(NSInvocation *)invocation
{
  NSAssert([invocation target] != nil, @"Target should be set");
  NSAssert([invocation selector] != nil, @"Selector should be set");

  NSURLSessionDataTask *task = [_session dataTaskWithRequest:request];
  [_tasks addObject:[PLNetworkTask futureWithTask:task
                                       invocation: invocation]];
  [task resume];
}

- (PLNetworkTask *)futureWithTask:(NSURLSessionTask *)task
{
  for (PLNetworkTask *future in _tasks) {
    if ([future task] == task) {
      return future;
    }
  }
  return nil;
}

#pragma mark NSURLSessionDataDelegate
- (void)URLSession:(NSURLSession *)session
          dataTask:(NSURLSessionDataTask *)dataTask
    didReceiveData:(NSData *)data;
{
  [[self futureWithTask:dataTask] appendData:data];
}

#pragma mark NSURLSessionTaskDelegate
- (void)URLSession:(NSURLSession *)session
              task:(NSURLSessionTask *)task
didCompleteWithError:(nullable NSError *)error;
{
  PLNetworkTask *future = [self futureWithTask:task];
  [future completeWithError:error];
  [_tasks removeObject:future];
}

@end

And finally we can start using PLNetworkSession to schedule async tasks

- (void)handleData:(NSData *)data error:(NSError *)error
{
  if (!data) {
    return;
  }
  NSString *dataStr = [[NSString alloc] initWithData:data
                                            encoding:NSUTF8StringEncoding];
  NSLog(@"data %@", dataStr);
  [dataStr release];
}

- (void)runNetwork
{
  self.session = [[PLNetworkSession alloc] init];
  NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:
                              [self methodSignatureForSelector
                               :@selector(handleData:error:)]];
  [invocation setTarget:self];
  [invocation setSelector:@selector(handleData:error:)];
  NSURLRequest *request = [NSURLRequest requestWithURL:
                           [NSURL URLWithString:
                            @"https://jsonplaceholder.typicode.com/todos/1"]];
  [_session dispatchRequest:request invocation:invocation];
}

Output

data {
  "userId": 1,
  "id": 1,
  "title": "delectus aut autem",
  "completed": false
}

Afterwords

This was more or less just an demo on how NSInvocation can be used to build a callback pattern. Swift does not even exposes NSInvocation so one has to use some other mechanism when working with Swift. I personally have no favorites, like every other thing when writing softwares we have to be judicious when selecting the right tool for the job. If for example there is no data transfer, rather only control transfer among several procedures, NSInvocation could be a better fitting tool. Like say the libdispatch library.

Lost art of manual memory management

2019-12-27T19:16:00+00:00

Manually managing of memory is an art that is getting extinct at an alarming pace. If you started working with Objective-C after 2011 or with Swift there is a high chance you’d probably never worked with manual memory management aka Manual Retain Release (MRR). And if one never had an opportunity of first hand experiencing MMR, one might even think of it as some outrageous technique where the entire code is blathered with calls of retain and release all over the place. Even more so when its antagonist, the Automatic Reference Cycle (ARC) claims to solve a problem which was not as monstrous as ARC claims in the first place.

Myth: MRR is dead.

Fact: MRR is still pretty much in use. ARC does help with hiding some redundant information from our instant vision at cost of rare but hard to diagnose bugs, but internally the system still performs the same very classic reference counting.

Manual Retain Release (MRR)

Before we dive any deeper we would have to refresh some basic concepts.

Stack vs heap

From a certain perspective a program can be imagined as made up of many smaller procedures chained together. Think of a giant stack of procedures with following rules:

A procedure is just a group of instructions.
Every procedure is pushed to the stack with some data passed as arguments and some local memory space, lets call it as the stack space of the procedure.
A procedure can push another child procedure on the stack.
At any given moment only the stacks’s topmost procedure is executing and the rest of the procedures are frozen with their last states.
When a procedure is complete, it is popped and optionally some data is returned back to its parent procedure.
When popped, the stack space of the procedure just popped is cleared and any local data in that space is now invalid for access. Note that, access to any parent procedure’s stack space is always valid for access but may not be visible to child procedure.
The first procedure is called main() and is pushed with some predefined system arguments and returns some predefined system values.

So the only way for procedures to pass data among each other is via the arguments and return data. Sometimes we might need the data in a procedure’s stack space to have a longer lifespan than the procedure itself. For example a procedure might compute some expensive data that we wish to reuse. Then we can move this data to some global shared memory space called as the heap space.

Once some data has been moved to heap space it will live there as long as we explicitly do not clean it.

Reference counting

With languages like ObjC most of data is allocated in heap. In fact it is not even allowed to allocate pure ObjC objects in stack.

Smart people at ObjC team realized this problem very early on. So they built the entire system of reference counting. The way it works is by keeping a counter for every object allocated in heap. Every procedure that needs to keep that object alive increments the count by calling retain and decrement when done by calling release. As long as the retain count is more than zero the object is kept alive.

Of course not every object access has to be retained. For example, if we know for sure that the object passed as argument is retained by the parent’s stack space and we know that our access is short lived than the parent’s stack space we don’t need to retain it.

- (void)bindViewModel:(PAListItemViewModel *)viewModel;
{
    // No need to retain viewModel
    _imageView.image = viewModel.image;
}

Memory leaks vs corruption

With manually memory management there are mostly two kind of memory related errors.

Memory leaks happens when we forget to call release and some allocated memory is never released. This is not harmful immediately as it would not crash the app, but starts building the app for a later crash depending on how much memory is being leaked. But when the app does crash it’s really hard to debug the cause, since the crash could be unpredictable.

-(void)leakyMethod
{
  NSArray *arr = [[NSArray alloc] initWithObjects:@"hello", @"world", nil];
  // the arr was never released
  NSLog(@"arr: %lu",[arr count]);
}

Memory corruption happens when we call release on already released memory. Or if the pointer is holding some memory address which is invalid. This could happen with a dangling pointer. It usually is an immediate runtime crash and one of the more frequent reason for app crashes.

-(void)crashyMethod
{
  NSArray *arr = [[NSArray alloc] initWithObjects:@"hello", @"world", nil];
  [arr release];
  // arr is now dangling
  NSLog(@"arr: %lu",[arr count]);
}

Remember than in Objc it is always safe to send a message to nil. So above crash can be fixed by setting arr to nil.

-(void)nonCrashyMethod
{
  NSArray *arr = [[NSArray alloc] initWithObjects:@"hello", @"world", nil];
  [arr release];
  arr = nil;
  // arr is now safe
  NSLog(@"arr: %lu",[arr count]);
}

Autorelease pool

Another important concept is of autorelease pool. Let’s say we need to create an NSString and return it back to the caller and we implement it like this:

-(NSString *)getIdentifier
{
  NSString *str = [[NSString alloc] initWithData:_someData
                                        encoding:NSUTF8StringEncoding];
  [str release];
  return str;
}

Since the str is released before returning, by the time caller gets access to the NSString it is already pointing to a deallocated memory. Looks a memory corruption, guaranteed crash at runtime.

Easy fix could be to return an allocated NSString hoping the caller would release it after use

-(NSString *)makeIdentifier
{
  NSString *str = [[NSString alloc] initWithData:_someData
                                        encoding:NSUTF8StringEncoding];
  return str;
}

But this implies that every caller has to know about the ownership responsibility. And what if the caller has to again forward this NSString to its caller? We need a solution where the caller if free to retain if they need the object for a longer period, otherwise it just gets deallocated. This is where NSAutoreleasePool shines.

-(NSString *)getIdentifier
{
  NSString *str = [[NSString alloc] initWithData:_someData
                                        encoding:NSUTF8StringEncoding];
  return [str autorelease];
}

We mark the instance to be kept alive for a very short span by transferring the ownership to the autorelease pool. Next, the caller can directly use it if they know for sure that they only need access before it gets deallocated which happens at next event cycle. Or they can retain it.

Myth: We can not get reference cycles with MRR

Fact: It is true that with MRR every reference is weak unless explicitly retained, but still we can run into situations where Foo retains Bar while Bar retains Foo.

// Forward declaration
@class Bar;

@interface Foo : NSObject
{
  Bar *_bar;
}
@end

@implementation Foo

- (instancetype)init
{
  self = [super init];
  if (self) {
    NSLog(@"Init Foo");
    _bar = [[Bar alloc] init];
    _bar.foo = self;
  }
  return self;
}

- (void)dealloc
{
  NSLog(@"Deinit Foo");
  [_bar release];
  [super dealloc];
}

@end

@interface Bar : NSObject
@property (nonatomic, retain) Foo *foo;
@end

@implementation Bar

- (instancetype)init
{
  self = [super init];
  NSLog(@"Init Bar");
  return self;
}

- (void)dealloc
{
  NSLog(@"Deinit Bar");
  [super dealloc];
}

@end

When called as:

-(void)referenceCycle
{
  Foo *foo = [[Foo alloc] init];
  [foo release];
}

Prints:

Init Foo
Init Bar

Just as with ARC the fix is to simply make the backward reference as weak or assign in MRR.

@interface Bar : NSObject
@property (nonatomic, assign) Foo *foo;
@end

Prints:

Init Foo
Init Bar
Deinit Foo
Deinit Bar

Working with MRR in real life

With some basic concepts under our belt, lets take a look at some real world considerations when working with MRR.

Avoid `property` when possible

Try hard reasoning to avoid self when it comes to using class data. We don’t need every private data to be a property which is a norm when working with ARC. Think of property as ivar with convenience getter and setter, if there is a good reason for a getter or setter use property otherwise stick with ivar. In other words don’t use self.someProperty when _someProperty will suffice.

- (NSInteger)collectionView:(UICollectionView *)collectionView numberOfItemsInSection:(NSInteger)section
{
  return [_delegate totalItemsListViewController:self];
}

Whenever in doubt mentally replace the fancy . with the full message passing syntax.

self.image = other.image;

is same as

[self setImage:[other image]];

Always use ivars from `init` and `dealloc`

- (instancetype)init
{
  self = [super init];
  if (!self) {
    return nil;
  }

  _viewModel = [[PAListViewModel alloc] init];

  return self;
}

- (void)dealloc
{
  [_viewModel release];
  [super dealloc];
}

The reason is that we don’t usually want to invoke dynamic dispatch from these 2 special methods as the instance is partially initialized. Said that, it is not as problematic as in C++ or as in Swift where it is impossible (for good reasons).

Reuse retain setter

A good understanding of how the setter for retain is synthesized never hurts. The way to learn is by implementing one ourself even if just for the kicks.

- (void)setCount:(NSNumber *)newCount 
{
    // acquire
    [newCount retain];
    // dispose
    [_count release];
    // exchange
    _count = newCount;
}

Then try to always use this setter, even when rolling back to some default value or nil. This is probably one of the best cases where using a property is the best choice.

@property (nonatomic, retain) NSNumber *count;

Provide convenience initializers.

Convenience does not mean just for the sake of readability. Think more from the memory ownership perspective. Lets take a look at 2 similar looking NSString initializers:

+ (instancetype)stringWithContentsOfURL:(NSURL *)url 
                               encoding:(NSStringEncoding)enc 
                                  error:(NSError * _Nullable *)error;

- (instancetype)initWithContentsOfURL:(NSURL *)url 
                             encoding:(NSStringEncoding)enc 
                                error:(NSError * _Nullable *)error;

The class methods implies we do not own the instance, while the instance method means we own the ownership and would have to manage the memory ourself.

- (void)loadContentWithURL:(NSURL *)url
{
  NSString *s1 = [NSString stringWithContentsOfURL:url 
                                          encoding:NSUTF8StringEncoding
                                             error:NULL];
  NSString *s2 = [[NSString alloc] initWithContentsOfFile:url                 
                                                 encoding:NSUTF8StringEncoding
                                                    error:NULL];

  // .. do stuff

  [s2 release];
}

Understand ownership by external frameworks

We cannot manage the ownership everywhere. Check what the API looks like for the framework being used. Are they going to retain or simply keep a weak reference? For example this is what the interface for UIWindow looks like:

@interface UIWindow : UIView
@property(nonatomic, weak) UIWindowScene *windowScene;
@property(nonatomic, strong) UIViewController *rootViewController;
@end

This suggests that the windowScene has to retained by us somehow whereas the rootViewController can be released.

Some system frameworks use naming conventions to imply ownership. For example, an add implies ownership while set does not.

Blocks live on stack by default

The biggest change is in understanding how blocks behave with MRR. Blocks are stored on stack by default. In Swift terms every block is non-escaping and every block needs to be explicitly moved to heap if they’re expected to run in some later time, or in other words if they are escaping.

The way to do this is by calling Block_copy and Block_release.

- (void)getPhotoWithURL:(NSURL *)photoURL
             completion:(void (^)(UIImage *))completion
{
  Block_copy(completion);
  [self getDataWithRequest:[PAImageRequest requestWithURL:photoURL]
                completion:^(NSData *data) {
    if (data != nil) {
      completion([UIImage imageWithData:data]);
    } else {
      completion(nil);
    }
    Block_release(completion);
  }];
}

Resources

There are probably a billion articles still out there in the wild that discuss these topic in details. I would not link them here, any article before 2011 on ObjC is probably going to discuss MRR at some level. But I would link some official resources on working outside the comfort zone of ARC, or understanding on how ARC works.

ARC is good and all but like every other thing in computer science it is not a silver bullet that is going to solve all our problems. Most likely with ARC you would not have as many memory corruptions as everything is retained by default, but you might end up with more memory leak issues like with reference cycles.

Compared to C or classic C++ where we have to use very discipline in managing memory, I think ObjC with its reference counting and autorelease pool is already good enough to not run into a lot of issues C/C++ have.

I love C++ and ObjC, probably my all time favorite languages, but in their own pure ways. The more I think about it, it seems to me that ARC was designed by people who either never really understood or appreciated the core philosophies of ObjC. ARC feels like a language patch from people who love C++, and wanted the memory runtime behavior to be more in line of std::shared_ptr which MRR already did better.

Step by step guide towards type erasures in Swift

2019-12-13T09:15:00+00:00

There are 2 kind of programmers that you encounter in the wild. Ones those who really like types and the others those really don’t. Forget arguments over spaces vs tabs, this is the real debate. This is a big deal. Probably the first thing engineers think when starting on a new project. Perhaps even before they think about the real goal of the project itself. Like, “I need a weekend project where I can use python”. Type is a serious thing.

So, naturally when a group of expert C++ programmers got together to write a new language they came up with a language which is even more complex than C++ as long as the type system is concerned. Swift is very strictly typed, undeniably the most strongly typed language I’ve ever used. I mean even natural looking type conversions, say between Int and UInt, have to be explicitly declared.

When you’re dealing with such strongly typed system for solving real world problems there comes quite a few times a moment where you have a bunch of types that are not strictly the same but still you can group them by some shared functionality. And if you’re a Swift developer youself, you must be thinking ‘Ah protocol!’.

Problem

In Swift protocol can be used in 2 different paradigms.

First, abstract base class

protocol Beverage {
  var name: String { get }
}

struct Beer: Beverage {
  let name = "Duff"
}

Second, to represent a generic concept

protocol Alcoholic {
  associatedtype Drink: Beverage
  func gulp(drink: Drink)
}

struct Homer<B: Beverage>: Alcoholic {
  func gulp(drink: B) {
    print("Hmmm \(drink.name)")
  }
}

struct Barney<B: Beverage>: Alcoholic {
  func gulp(drink: B) {
    print("Yay \(drink.name)")
  }
}

If you’ve ever written any C++ you must be well aware of the fact that C++ does not provide any language construct for the second usage of protocol. So we end up having similar function signatures that are still checked by the compiler but not available as a documentation for users of the library. Like the size() member function of every collection type in the standard library. If you wish you write your own new collection type and want it to fit with the rest of the standard library, you just somehow have to know what methods to implement to keep the compiler from screaming.

With Swift protocols the most noticeable difference is when attempting to group various types under a common type.

// Abstract base class: Works!
func collect(beverages: [Beverage]) {}

// Concept: Fails!
// Protocol 'Alcoholic' can only be used as a generic constraint because it has Self or associated type requirements
func enterMoTavern(customers: [Alcoholic]) {}

The workaround for this second case is what type erasure is all about. This is my strategy.

Step 1: Interface

Create a dumb class that only needs to serve as the interface for our concept, or in other words an abstract base class.

class Interface<B: Beverage>: Alcoholic {
  func gulp(drink: B) {
    fatalError()
  }
}

Step 2: Implementation

Next, create a dumb implementation class. This class needs to be a subclass of the Interface as later we are going to use the famous PIMPL pattern

class Implementation: Interface<SomeAlcoholic.Drink> { }

let proxy: Interface = Implementation()

As far as the actual implementation goes, this class only needs to capture an concrete instance and forward all the calls to that. To make that happen we need to parametrize this class for a type conforming to the concept.

class Implementation<SomeAlcoholic: Alcoholic>: Interface<SomeAlcoholic.Drink> {

  private let concreteInstance: SomeAlcoholic

  init(_ concreteInstance: SomeAlcoholic) {
    self.concreteInstance = concreteInstance
  }

  override func gulp(drink: SomeAlcoholic.Drink) {
    concreteInstance.gulp(drink: drink)
  }
}

The rule to remember here is that Interface conforms to Alcoholic while Implementation does not. Implementation simply provides overridden implementations of Alcoholic.

Step 3: Wrap it up

The final step is to glue both Interface and Implementation together.

class AnyAlcoholic<B: Beverage>: Alcoholic {

  private let proxy: Interface<B>

  init<SomeAlcoholic: Alcoholic>(_ concreteInstance: SomeAlcoholic) where SomeAlcoholic.Drink == B {
    self.proxy = Implementation(concreteInstance)
  }

  func gulp(drink: B) {
    proxy.gulp(drink: drink)
  }
}

The point to note here is that we are templating on abstract base class Beverage and conforming to the concept Alcoholic magically. So that we can easily pass AnyAlcoholic as a complete type.

let homer: Homer<Beer> = Homer()
let barney: Barney<Beer> = Barney()
let customers: [AnyAlcoholic<Beer>] = [AnyAlcoholic(homer), AnyAlcoholic(barney)]

With this we can finally have a type that can be used to group every concept conforming type.

func enterMoesTavern(customers: [AnyAlcoholic<Beer>]) {
  let beer = Beer()
  customers.forEach { $0.gulp(drink: beer) }
}

enterMoesTavern(customers: [AnyAlcoholic(Homer()), AnyAlcoholic(Barney())])

Step 4: Clean up

To hide all the ugliness, we can make all of our boilerplate code as nested private classes.

class AnyAlcoholic<B: Beverage>: Alcoholic {

  private class Interface<B: Beverage>: Alcoholic {
    func gulp(drink: B) {
      fatalError()
    }
  }

  private class Implementation<SomeAlcoholic: Alcoholic>: Interface<SomeAlcoholic.Drink> {

    private let concreteInstance: SomeAlcoholic

    init(_ concreteInstance: SomeAlcoholic) {
      self.concreteInstance = concreteInstance
    }

    override func gulp(drink: SomeAlcoholic.Drink) {
      concreteInstance.gulp(drink: drink)
    }
  }

  private let proxy: Interface<B>

  init<SomeAlcoholic: Alcoholic>(_ concreteInstance: SomeAlcoholic) where SomeAlcoholic.Drink == B {
    self.proxy = Implementation(concreteInstance)
  }

  func gulp(drink: B) {
    proxy.gulp(drink: drink)
  }
}

So our exposed interface is like:

class AnyAlcoholic<B: Beverage> : Alcoholic {

  init<SomeAlcoholic : Alcoholic>(_ concreteInstance: SomeAlcoholic) where SomeAlcoholic.Drink == B

  func gulp(drink: B)
}

Closing notes

I think one of the reasons people love Swift is because it has a pretty nice exponential learning curve

What this means is that it is very easy to learn the basics of the language, which is great for beginners. While, the language complexity keeps increasing the more you get into it, which keeps experienced Swift developers entertained. Of course untill you hit the roof. That’s when you discover that the feature you badly need is still in proposal state of the evolution, which might help with keeping things interesting for a while.

Immutability - Swift vs C++

2019-11-28T17:12:00+00:00

Immutability awareness is on the rise. Especially when the codebase grows in size and complexity, the benefits of immutability for stability, readability and maintenance reasons is imminent.

If you’re dealing a function that receives immutable data as arguments, you don’t have to bother checking for any side effects. Or worrying about accidentally mutating the received data.

void process(const Page & page) {
    // ...
}

Similar benefits can be observed from the other side. If you don’t expect data to be mutated, you might prefer marking the entire method as immutable.

struct Page {
    bool print() const {
        // ...
        return true;
    }
};

void process(const Page &page) {
    bool status = page.print();
    // ...
}

But things get a bit complicated when you’re not dealing with the first hand data, rather a reference to the data. Since the reference is just a data holding the data. So depending on the intended design, either the data or the reference could be mutable, or both, or none.

As we can see, we are dealing with 2 things here each of which can then be in 2 states. So overall we are dealing with 4 cases:

Everything is mutable
Reference is mutable
Data is mutable
Everything is immutable

Everything is mutable

Let’s consider a simple C++ data structure

struct Foo {
    int x;
};

Marking everything as mutable is very easy. Do nothing special.

void update_all(Foo *f) {
    f->x = 10;
    f = nullptr;
}

With Swift we need to make the decision about mutability while designing the data structures. Since the data within a struct is always immutable and within a class may or may not be mutable. The mutability of reference depends on whether is a let or a var.

So, in case of a struct we would have to explicitly set the data and the reference to be var

struct A {
    var x = 0
}

func updateAllStruct() {
    var f = A()
    f.x = 10
    f = A()
}

Note that since A is struct type, so every mutating operation internally creates a new copy of the entire data structure.

The class behaves just like the C++ counterpart as long as keep both data and reference as var

class B {
    var x = 0
}

func updateAllClass() {
    var f = B()
    f.x = 10
    f = B()
}

Reference is mutable

If we only need a mutable reference but the data should remain immutable. With C++ we simply need to mark the pointed data as const. If we then accidentally try to mutate the data, the compiler would throw an error.

void update_ref(Foo const * f) {
    f->x = 10; // error: Cannot assign to variable 'f' with const-qualified type 'const Foo *'
    f = nullptr; // good
}

In Swift, if we wish the data to be immutable, we have to mark it as let while keeping the reference as var

struct C {
    let x = 0
}

class D {
    let x = 0
}

And then, if we accidentally try to mutate the via an mutable reference, the compiler would throw an error

func updateRefStruct() {
    var f = C()
    f.x = 10 // error: Cannot assign to property: 'x' is a 'let' constant
    f = C() // good
}

func updateRefClass() {
    var f = D()
    f.x = 10 // error: Cannot assign to property: 'x' is a 'let' constant
    f = D() // good
}

Data is mutable

With C++, marking the data as mutable while the reference remains immutable also seems quite straightforward. Simply mark the reference as const

void update_data(Foo * const f) {
    f->x = 10; // good
    f = nullptr; // error: Cannot assign to variable 'f' with const-qualified type 'Foo *const'
}

In Swift however, having a struct where reference is immutable while data as mutable is not possible. Because, as soon as you mark the reference as let, the internal storage becomes immutable as well, even if it was marked as var

func updateDataStruct() {
    let f = A()
    f.x = 10 // error: Cannot assign to property: 'f' is a 'let' constant
    f = A() // error: Cannot assign to value: 'f' is a 'let' constant
}

But, again we can use class type to get the same behavior as C++

func updateDataClass() {
    let f = B()
    f.x = 10 // good
    f = B() // error: Cannot assign to value: 'f' is a 'let' constant
}

Everything is immutable

Marking everything as immutable with C++ is definitely possible, but requires a lot of extra typing. You need to mark both the reference and the pointed data as const

void update_none(Foo const * const f) {
    f->x = 10; // error: Cannot assign to variable 'f' with const-qualified type 'const Foo *const'
    f = nullptr; // error: Cannot assign to variable 'f' with const-qualified type 'const Foo *const'
}

With Swift, if we mark both the reference and the data as let everything becomes immutable

func updateNoneStruct() {
    let f = C()
    f.x = 10 // error: Cannot assign to property: 'x' is a 'let' constant
    f = C() // error: Cannot assign to value: 'f' is a 'let' constant
}

func updateNoneClass() {
    let f = D()
    f.x = 10 // error: Cannot assign to property: 'x' is a 'let' constant
    f = D() // error: Cannot assign to value: 'f' is a 'let' constant
}

Opinions?

I personally like C++ way of dealing with mutability. It seems simpler to understand and offers more control to the user of the API. Compared to Swift where you need to look the implementation of the library to see if the type is a class or a struct.

Also from the author’s perspective, they only have to design the class intrinsic behavior for ‘const correctness’ by marking appropriate methods as only available when accessed via as const.

What’s even more interesting is the fact that the authors can even override methods for const to give even more flexible class interface

struct Foo {
    int increment() { return ++x; }
    int increment() const { return x + 1; }
    int x = 0;
};

void f() {
    const Foo f;
    int y = f.increment();
    printf("%d %d\n", y, f.x); // 1 0
}

void g() {
    Foo f;
    int y = f.increment();
    printf("%d %d\n", y, f.x); // 1 1
}

In fact, this technique is used by the std::map operator[]. It’s called const-overloading

The thing I like about Swift though is the immutable by default behavior in Swift, which makes code safer by default, unlike C++ where you have to discipline yourself to it. And some cases where having things as immutable is even frowned upon.

Concurrent read writes with libdispatch

2019-11-18T18:00:08+00:00

Lets write a thread-safe collection. Say a cache that provide a way to load and store values. And for simplicity, we only care about storing Int for a String key.

Basic Unsafe Read Writes

The simplest thing that comes to mind is a simple wrapper around mutating dictionary to provide a limiting interface.

class Cache {
    private var store: [String: Int] = [:]

    func get(key: String) -> Int? {
        return store[key]
    }

    func set(value: Int, key: String) {
        store[key] = value
    }
}

We need some driver code to use this cache from multiple threads. It’s very hard to test for concurrency bugs, so I’m trying to read write to same key multiple times from many different threads. This is my driver code:

func taskRunner() {
    let tasks = 20
    let jobs = 100000
    let cache = Cache()

    let startTime = CACurrentMediaTime()
    DispatchQueue.concurrentPerform(iterations: tasks) { task in
        for job in 0..<jobs {
            let currValue = cache.get(key: "shared-key") ?? 0
            cache.set(value: currValue + 1, key: "shared-key")
        }
    }
    let endTime = CACurrentMediaTime()
    print("finish \(endTime - startTime)")
}

When I run this code, I get a runtime exception at some point. Since, I’m running the code with Thread Sanitizer, the error is more readable:

WARNING: ThreadSanitizer: Swift access race (pid=34398)
  Read of size 8 at 0x7b080003aa50 by thread T2:
  Previous modifying access of Swift variable at 0x7b080003aa50 by thread T1:
  Location is heap block of size 24 at 0x7b080003aa40 allocated by main thread:
  Thread T2 (tid=455657, running) is a GCD worker thread
  Thread T1 (tid=455656, running) is a GCD worker thread
SUMMARY: ThreadSanitizer: Swift access race

Looks like we have a classic race condition, as expected. Let’s fix it.

Blocking Reads and Writes

An improvement could be to wrap all the reads and writes to the shared memory location in a serial queue.

class Cache {
    private let queue = DispatchQueue(label: "serial-queue")
    private var store: [String: Int] = [:]

    func get(key: String) -> Int? {
        return queue.sync {
            return store[key]
        }
    }

    func set(value: Int, key: String) {
        queue.sync {
            store[key] = value
        }
    }
}

Here’s the output, to confirm that this code does indeed work:

finish 26.025777226001082

It works, but it has a few problems. First, DispatchQueue.sync is deadlock prone. It’s very easy to dispatch sync on the same queue causing a deadlock. Second, since we are using a serial queue to synchronize all the read/writes, we are not actually achieving any parallelism. We can definitely improve the performance if we making the reads and writes in parallel.

Asynchronous Reads and Writes

The first solution could be to use a concurrent queue and dispatch every read write operation to that queue.

class Cache {
    private let queue = DispatchQueue(label: "concurrent-queue", attributes: .concurrent)
    private var store: [String: Int] = [:]

    func get(key: String, completion: @escaping (Int?) -> Void) {
        queue.async { [weak self] in
            completion(self?.store[key])
        }
    }

    func set(value: Int, key: String) {
        queue.async { [weak self] in
            self?.store[key] = value
        }
    }
}

But this has the same problems as our original solution. It is prone to race conditions when writing to store. Since the queue is concurrent, so multiple writes can be happening in parallel.

An improvement could be to use memory barriers to synchronize reads and writes.

class Cache {
    private let queue = DispatchQueue(label: "concurrent-queue", attributes: .concurrent)
    private var store: [String: Int] = [:]

    func get(key: String, completion: @escaping (Int?) -> Void) {
        queue.async(flags: .barrier) { [weak self] in
            completion(self?.store[key])
        }
    }

    func set(value: Int, key: String) {
        queue.async(flags: .barrier) { [weak self] in
            self?.store[key] = value
        }
    }
}

Although now our memory access should be again race free, but it might be making things works worse in reality. Due to the fact that barrier blocks the entire concurrent queue we might get even worse time than using a serial queue as we are using a concurrent queue as a serial queue.

Synchronous Reads Asynchronous Writes

An observation could be made from our above solution that maybe we do not need barrier for reading tasks. And which brings to another solution which might the best so far.

class Cache {
    private let queue = DispatchQueue(label: "concurrent-queue", attributes: .concurrent)
    private var store: [String: Int] = [:]

    func get(key: String) -> Int? {
        return queue.sync { 
            return store[key]
        }
    }

    func set(value: Int, key: String) {
        queue.async(flags: .barrier) { [weak self] in
            self?.store[key] = value
        }
    }
}

Beyond libdispatch

libdispatch is not a low level library. It is probably a bit lower level than NSOperation, but it’s not designed for performance, rather usage simplicity. If performance is the issue we can always go a bit more further by using few more tools provided by Foundation, like say NSLock to get more control over things.

class Cache {
    private let lock = NSLock()
    private var store: [String: Int] = [:]

    func get(key: String) -> Int? {
        lock.lock()
        let value = store[key]
        lock.unlock()
        return value
    }

    func set(value: Int, key: String) {
        lock.lock()
        store[key] = value
        lock.unlock()
    }
}

One of the best resources on GCD are:

Policy based design in Swift

2019-10-25T08:26:19+00:00

How about Policy based design in Swift?

It’s quite an interesting pattern in C++. I first read about it in the Modern C++ Design by Andrei Alexandrescu years ago. The idea is to replace inheritance madness by composition. If we could wrap every reusable functionality in a Policy then we can compose objects from those policies. One might think this is nothing new, but that is where things get interesting. The composition happens at compile time! Which obviously requires the language to have some generic programming support.

In C++ this magic works beautifully since the language allows multiple inheritance. So as long as the policies are free of any ambiguities, one can have as many permutations of policies as they want. In swift though, it’s a little challenge to implement as we do not have multiple inheritance, but we can workaround by having allocations per policy and can still achieve similar effect.

So, here’s my implementation of the Policy pattern in Swift:

import Foundation

protocol OutputPolicy {
    associatedtype Message
    func print(message: Message)
}

protocol LanguagePolicy {
    associatedtype Message
    var message: Message { get }
}

struct Printer<O: OutputPolicy, L: LanguagePolicy> where O.Message == L.Message {
    let output: O
    let language: L

    func run() {
        output.print(message: language.message)
    }
}

class OutputPolicyToConsole: OutputPolicy {
    func print(message: String) {
        Swift.print(message)
    }
}

class LanguagePolicyEnglish: LanguagePolicy {
    let message = "Hello World!"
}

class LanguagePolicyEmoji: LanguagePolicy {
    let message: String = "👋 🌏❗️"
}

let printerEnglish = Printer(
    output: OutputPolicyToConsole(), 
    language: LanguagePolicyEnglish()
)
let printerEmoji = Printer(
    output: OutputPolicyToConsole(), 
    language: LanguagePolicyEmoji()
)

printerEnglish.run()
printerEmoji.run()

For reference, this is based on the sample example in the wiki article for C++:

template <typename OutputPolicy, typename LanguagePolicy>
class Printer : private OutputPolicy, private LanguagePolicy
{
 public:
  void run() const {
    print(message());
  }

 private:
  using LanguagePolicy::message;
  using OutputPolicy::print;
};

class OutputPolicyWriteToCout
{
 protected:
  template <typename MessageType>
  void print(MessageType&& message) const {
    std::cout << message << std::endl;
  }
};

class LanguagePolicyEnglish
{
 protected:
  std::string message() const { return "Hello, World!"; }
};

class LanguagePolicyEmoji
{
 protected:
  std::string message() const { return "👋🌏!"; }
};

int main() {
    Printer<OutputPolicyWriteToCout, LanguagePolicyEnglish> printerEnglish;
    Printer<OutputPolicyWriteToCout, LanguagePolicyEmoji> printerEmoji;

    printerEnglish.run();
    printerEmoji.run();
}

Service Locator pattern with GameplayKit

2019-10-22T22:18:00+00:00

Service Locator Pattern
Entity Component System
Hello GameplayKit
Encapsulation
And more

Service Locator Pattern

In the beginning everything seems fine. You start a new project. Things talk to each other, and there are so few participants and so less information that has to be shared among them. Next arrives a situation where a resource has to be shared among several objects. The shared resource could be a service that stores some app data, or could be some collection of utility functions wrapped under a single blanket. We can think of these shared resources as dependencies that need to be injected from outside into every one of those objects as their lifespan is controlled on a different level.

As the code size increases, so does the problem of dependency injection. Bob needs to pass a dependency to Alice, but has no direct access to Alice. So, ends up handing over the dependencies to every thing in the chain of communication. And very soon a lot of objects has access to dependencies that do not need themselves.

A very common solution that I often come across is to use the Singleton Pattern. Implemented usually by providing a shared instance that can then easily be accessed from anywhere in your code. This pattern is very well covered by Apple too.

This indeed does the job but not without creating a mess. The mess is felt the most when trying to unit test a functionality where there is a need to mock a service, but can’t since there no clear way to inject the mock instance. Another place where the Singleton Pattern hurts the most is with initialization order, where 2 singleton instances can accidentally become dependent on each other and end up in a infinite loop.

class ServiceA {
     static let sharedInstance: ServiceA = {
        let instance = ServiceA(that: ServiceB.sharedInstance.that)
           return instance
       }()

    var this: String { return "this" }

    init(that: String) {}
}

class ServiceB {
    static let sharedInstance: ServiceB = {
        let instance = ServiceB(this: ServiceA.sharedInstance.this)
           return instance
       }()

    var that: String { return "that" }

    init(this: String) {}
}

Another good alternative to this pattern is to use what is commonly called as Service Locator Pattern. The basic idea is that there is this one instance that manages all the global services. When the system starts, we register all the services with this service locator, preferably during the initialization. Later, anyone who wishes to get the shared resource simply asks for the service from this service locator.

It’s not a golden solution to all your problems, but at least helps with unit testing where we can register our mock services before running the tests. And also since the service locator owns the dependencies, they are easier to manage. Including releasing a service when done. Which is hard (if not impossible) with Singleton Pattern.

Entity Component System

And now for something completely different, let’s talk about the Entity Component System. A design pattern held in high regards by many game developers big and small.

Most of the games need at least these three kinds of object types at some point of development cycle:

Render objects: Think of the background image that only needs to be rendered on screen.
Player objects: Every gameplay character. Needs to be rendered on screen and also interact with each other or the environment; So also need a physics body.
Trigger objects: Something that does not need any rendering, but still interacts with the rest of the physics bodies. Like the invisible bonus or when character drops out of screen.

One way to implement this could be have a classic object hierarchy that all inherit from something like a GameObject all the way down:

class GameObject { }

class RenderObject: GameObject {
    func draw() { }
}

class PhysicsObject: RenderObject {
    func update() { }
}

class PlayerObject: PhysicsObject {
    func collectCoins() { }
}

Then we create our instances as:

let background = RenderObject()
let hiddenBonus = PhysicsObject()
let mario = PlayerObject()

background.draw()

hiddenBonus.update()

mario.collectCoins()
mario.update()
mario.draw()

This would work fine except the fact that now hiddenBonus also has a draw() function, which does nothing. Also notice that every time we introduce another behavior, like say user interaction, we would have to come up with some strategy to update the inheritance hierarchy so that all the subclasses can get the behavior. This is a hard problem to solve. Harder if the game engine and the game live in entirely different layers.

A good flexible solution for this problem is Entity Component System. The basic idea is to wrap every possible reusable behavior in isolation and let’s call it a Component.

So, in our case above we could have 2 components:

class Component {}

class RenderComponent: Component {
    func draw() { }
}

class PhysicsComponent: Component {
    func update() { }
}

And next we can have something called as Entity. An Entity can be composed with several behavior components.

class Entity {
    private var components: [Component]

    init(components: [Component]) {
        self.components = components
    }

    func add(component: Component) { }

    func getComponent(ofType: Component.Type) -> Component? { }
}

And now we can create all the desired instances as:

let background = Entity(components: [RenderComponent()])
let hiddenBonus = Entity(components: [PhysicsComponent()])
let mario = Entity(components: [RenderComponent(), PhysicsComponent()])

Hello GameplayKit

Okay that sounds good. But how does it fit with our topic?

If you squint your eyes enough you would realize that this Entity Component System is a Service Locator Pattern in disguise. Where a service locator is Entity and the services are the Component registered with the Entity.

What’s even better, Apple already provides us a nice framework which implements the Entity Component System it’s called GameplayKit. GameplayKit provides all the boilerplate code we need. Although probably not originally designed for this task, but we can definitely build our Service Locator Pattern with this framework.

Let’s say we want to have a service that manages all the feature flags stored on the device. We can implement it as a GKComponent:

import GameplayKit

class FeatureFlagService: GKComponent {
    let store: UserDefaults

    init(userDefaults: UserDefaults = .standard) {
        self.store = userDefaults
        super.init()
    }

    func set(value: Bool, key: String) {
        store.set(value, forKey: key)
    }

    func value(key: String) -> Bool {
        return store.bool(forKey: key)
    }
}

Next we can implement our ServiceLocator wrapped around a GKEntity

class ServiceLocator {
    private let registry = GKEntity()

    func register(service: GKComponent) {
        registry.addComponent(service)
    }

    var featureFlagService: FeatureFlagService? {
        return registry.component(ofType: FeatureFlagService.self)
    }
}

And then we can simply use the ServiceLocator to find dependencies

// at booting time
let serviceLocator = ServiceLocator()
serviceLocator.register(service: FeatureFlagService())

// a few seconds later
serviceLocator.featureFlagService?.set(value: true, key: "show-alt-login")
print(String(describing: serviceLocator.featureFlagService?.value(key: "show-alt-login")))

Another GameplayKit functionality that we can exploit is for scenarios where we want to perform some action whenever the service is actually registered with the service locator, rather than at the allocation/initialization time. For example, we want to fetch the feature flag data from our server whenever the FeatureFlagService is actually registered with the ServiceLocator for a faster launch time. With GameplayKit we can achieve these tasks by overriding the didAddToEntity method of GKComponent

extension FeatureFlagService {
    override func didAddToEntity() {
        // TODO: fetch data and synchronize with local store
        store.synchronize()
    }
}

Encapsulation

If we do not want to expose the GameplayKit dependency outside. Or if you want to use “pure” swift classes, structs to represent a Component. We can add another level of indirection to hide the abstraction.

We can have a generic wrapper that wraps any service

private class ServiceWrapper<T>: GKComponent {
    let service: T

    init(service: T) {
        self.service = service
        super.init()
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

And then our ServiceLocator can perform one extra boxing/unboxing:

class ServiceLocator {
    private let registry = GKEntity()

    func register<T>(service: T) {
        registry.addComponent(ServiceWrapper(service: service))
    }

    func get<T>() -> T? {
        registry.component(ofType: ServiceWrapper<T>.self)?.service
    }

    var featureFlagService: FeatureFlagService? { return get() }
    var networkService: NetworkService? { return get() }
    var accessibilityService: AccessibilityService?  { return get() }
}

And more

And that is not all. There is much more available in GameplayKit that can be useful when implementing a Service Locator Pattern. Like the GKEntity.removeComponent(ofType:) or GKComponent.willRemoveFromEntity(). There is also a section in the GameplayKit programming guide that covers the Entity Component System I was talking about earlier.

Although initially GameplayKit does sounds like an unusual fit for the Service Locator problem. But rather than writing your own solution from scratch, or using anu external dependency, I find GameplayKit a better for the job. For one, it is one less thing to maintain, and second it is already there ready for use. So, the next time you are looking for a Service Locator Pattern, try GameplayKit.

Hello Boden the x-platform framework

2019-06-01T11:19:00+00:00

Today I wanna try boden to make a cross platform app. I saw the framework few days back and to be honest did not think too much about it. One of the main reasons being I’m already too deep into Flutter, and although not a day goes by when I wish Flutter exposed some other language than Dart but still I really believe that Flutter has everything we need to develop a real world cross platform mobile app.

So why do I wanna try Boden? First, I like trying new things. Second, I love C++. I think C++ is the one lanugage that can be used in many ways and people should stop writing new languages because almost everything you need from a programming language probably already exists in C++.

Set up

The set up is actually pretty straightforward, especially if you read the README. I skipped over the part where it expects you to have cmake installed on your machine and that alone ruined 20 minutes of my excitement.

After creating a new app with ./boden new -n DemoBoden, a Xcode project is generated which starts with clean app

Getting started

The first challenge I faced was that the window for some reasons was of size 320 x 480. By adding breakpoint at the point where the UIWindow was being created I saw that the UIKit is responding incorrect screen size:

(lldb) po [[UIScreen mainScreen] bounds]
(origin = (x = 0, y = 0), size = (width = 320, height = 480))

The fix is to use the Launch Screen storyboard, which for some reasons is not generated with the Xcode project.

And add the entry in the Info.plist, otherwise the Launch storyboard will be simply ignored.

If all goes well, you should see a nice full screen layout.

As confirmed by the lldb

(lldb) po [[UIScreen mainScreen] bounds]
(origin = (x = 0, y = 0), size = (width = 414, height = 896))

Layout

Boden uses the yoga layout engine internally which is wrapped by other platform targeted libraries like YogaKit for Swift. It is really hard to find a documentation that actually uses yoga in the raw from, I mean in C++. But conceptually it is based on the CSS flexbox model, and it feels a bit familiar even though you might struggle with the exact syntax for a while.

For Boden, in most of examples I saw the typical usage was to pass the layout information as json string. If that is the case the probably the best approach would be to use the yoga playground and use the generated code for ReactNative.

This is a sample code for a full screen UINavigationController

    auto navigationView = std::make_shared<ui::NavigationView>();
    navigationView->stylesheet = FlexJsonStringify({
        "direction" : "Column",
        "flexGrow" : 1.0,
        "flexShrink" : 1.0,
        "alignItems" : "Stretch"
    });

Table view

The concepts of Boden framework seems very similar to the UIKit, which is a good thing for me. So, for example, implementing a UITableView like layout comes with similar constructs.

Step 1: Add a ListView

Implement a view controller that returns a ListView as a std::shared_ptr<bdn::ui::View> ListViewController::view()

    std::shared_ptr<bdn::ui::ListView> _listView;

Which then is added a child to the root view, NavigationView in our case

    navigationView->pushView(_listViewController->view(), "Photo List");

Step 2: Add a Data Source

To feed data to the ListView we need a data source.

class PhotoListViewDataSource : public bdn::ui::ListViewDataSource {
};

And just like UITableViewCell we need to provide values for cells to be rendered.

size_t PhotoListViewDataSource::numberOfRows()
{
    return 10;
}

std::shared_ptr<ui::View> PhotoListViewDataSource::viewForRowIndex(size_t rowIndex, std::shared_ptr<ui::View> reusableView)
{
    auto cell = std::make_shared<PhotoCell>();
    cell->build();
    return cell;
}

float PhotoListViewDataSource::heightForRowIndex(size_t rowIndex)
{
    return 100.0;
}

This is how a PhotoCell looks like:

class PhotoCell : public bdn::ui::CoreLess<bdn::ui::ContainerView> {
    
public:
    void build();
};

void PhotoCell::build()
{
    stylesheet = FlexJsonStringify({
        "direction" : "Row",
        "flexGrow" : 1.0,
        "justifyContent" : "SpaceBetween",
        "alignItems" : "FlexStart",
        "padding" : {"all" : 2.5}
    });
    
    auto label = std::make_shared<ui::Label>();
    label->stylesheet = FlexJsonStringify({
        "alignSelf": "Center",
        "flexGrow" : 1.0
    });
    label->text = "Ho ho";
    addChildView(label);
}

Step 3: Reload

Even for reloading the data, the API is a thin wrapper of the UITableView.reloadData()

void ListViewController::reloadData()
{
    _listView->reloadData();
    _listView->refreshDone();
}

The cell reuse is pretty familiar

std::shared_ptr<ui::View> PhotoListViewDataSource::viewForRowIndex(size_t rowIndex, std::shared_ptr<ui::View> reusableView)
{
    std::shared_ptr<PhotoCell> cell;
    if (reusableView) {
        cell = std::dynamic_pointer_cast<PhotoCell>(reusableView);
    } else {
        cell = std::make_shared<PhotoCell>();
        cell->build();
    }
    
    cell->text = "Cell" + std::to_string(rowIndex);
    
    return cell;
}

Conclusion

So that is probably enough poking around Boden for today. I think I like the idea of Boden. It seems usable for an iOS developer who like C++ and get an Android app for free.

The thing I really enjoyed about Boden compared to Flutter was that, with Boden I could simply step into the C++ framework and see how things are tied together. I suspect if that would still be the case with Android. But for iOS it was amazing, especially when dealing with crazy runtime issues. Also, being C++ you get a much strict compile time safety as with Swift but better.

I would to play more with networking, unit testing and probably try to run on Android before deciding if I would ship any app with this. But so far, I’m impressed.

As usual, all the code from today is in the PhotoApp project github.com/chunkyguy/PhotoApp

Types sharing between Metal and App

2019-01-19T20:43:00+00:00

One of the best things about Metal is the Metal Shading Language which is a based on C++. What this means is that we can share data structures between the shader and app code. There are a few cases that we have to look out for though, which is what this post is about.

Using C++

Lets say we want to define a data structure that represents vertex data:

// common.h

#include <simd/simd.h>

typedef struct
{
    simd::float4 position;
    simd::float4 color;
} Vertex;

The first problem we would have to tackle is that even though the simd types are the same in both C++ code and the Metal code but in C++ the types are part of simd namespace.

One way to fix this issue is to add using namespace simd when calling from C++.

// common.h

#ifdef __METAL_VERSION__
#else
#include <simd/simd.h>
using namespace simd;
#endif

typedef struct
{
    float4 position;
    float4 color;
} Vertex;

Now we can reuse the data structure in our C++ code, which looks even better thanks to the C99 style member initialization.

// renderer.cpp

#include "common.h"

 Vertex data[] = {
    {
        .position = { 0.0f, 1.0f, 0.0f, 1.0f },
        .color = { 1.0f, 0.0f, 0.0f, 1.0f }
    },
    {
        .position = { -1.0f, -1.0f, 0.0f, 1.0f },
        .color = { 0.0f, 1.0f, 0.0f, 1.0f }
    },
    {
        .position = { 1.0f, -1.0f, 0.0f, 1.0f },
        .color = { 0.0f, 0.0f, 1.0f, 1.0f }
    }
};

And on the shading side

// shader.metal

#include <metal_stdlib>
#include "common.h"

using namespace metal;

vertex Vertex vertexShader(device Vertex *data [[buffer(0)]], uint vid [[vertex_id]])
{
    return data[vid];
}


fragment float4 fragShader(Vertex in [[stage_in]])
{
    return in.color;
}

This has a problem. Since we are returning a struct from the vertex shader function, we need to have an element with attribute [[position]]. From the official docs:

If the return type of a vertex function is not void, it must include the vertex position. If the vertex return type is float4, then it always refers to the vertex position, and the [[position]] attribute must not be specified. If the vertex return type is a struct, it must include an element declared with the [[position]] attribute.

The fix is actually pretty simple, we can simply add the missing attribute to the Vertex

// common.h

typedef struct
{
    float4 position [[position]];
    float4 color;
} Vertex;

This should solve most of the errors except that compiler might emit a warning when compiling the C++ code:

Unknown attribute ‘position’ ignored

This could again be fixed with our beautiful preprocessor check

// common.h

#ifdef __METAL_VERSION__
#define ATTRIB_POSITION [[position]]
#else
#include <simd/simd.h>
#define ATTRIB_POSITION
using namespace simd;
#endif

typedef struct
{
    float4 position ATTRIB_POSITION;
    float4 color;
} Vertex;

Not the prettiest looking code out there, but gets the job done.

Using Objective-C

With Objective-C, the same trick can be applied, since for all simd types a C variant is available.

// common.h

#ifdef __METAL_VERSION__
#define ATTRIB_POSITION [[position]]
#else
#define ATTRIB_POSITION
#endif

typedef struct _Vertex
{
    vector_float4 position ATTRIB_POSITION;
    vector_float4 color;
} Vertex;

Nothing changes on the Metal side.

Hello Metal one more time

2019-01-19T18:26:00+00:00

If I were to say that I’ve never poked the Metal API, I would be lying. I’ve probably poked at the Metal API several times now since it was launched.

My feelings for Metal has been nothing less than a roller coster ride. When I first heard of it, I did not like it. At that time I was too much into OpenGL and the idealistic idea of one API for all. Until I saw the point made by Apple about Metal, that with Metal Apple would provide us developers more control over the GPU which now Apple was manufacturing in house. And then I did like it a bit, and I decided to take a look at the API at least once, and if I do not like it, I’ll just ignore its exsistence and keeping using OpenGL.

That is when I realized that Metal was written in Objective C, and I was sad again. And it not due the fact that it was not in Swift which was not even a hype back then, I was sad that it was not in C or C++. Like I’ve said, I was very much in to the idea of one API rules for, so I was very much using C++ as much as possible for similar reasons.

Some time later Khronos people released Vulkan which would cover almost all non-Apple GPUs and the API was in C. I was super excited, more like a dream come true for me. The only issue was that I had zero devices where I could actually play with Vulkan.

Later I learned about this thing called Molten VK which would provide the Vulkan API on top of Metal. Good, finally I can try Vulkan on my macOS right? No, it was still under progress and even after it were done, it was supposed to be a not-for-free framework. Still interesting to keep and eye on.

Meanwhile, Vulkan people and the Metal people were still rolling out version updates and here I was still stuck with OpenGL. One day I picked up my MacBook and started rendering the first triangle with Metal and ObjC. To be honest, I did like API a lot. I would have continued diving deeper if it were at least in C++.

Some time later, I finally got a Windows machine at home. The first thing I did after unboxing was to set up Vulkan, yay! That API felt very much like Metal with a bit more verbosity, maybe a bit too much verbose, but okay.

Apple had already announced Metal for macOS and I had plans about making something for macOS for a long time, and I got one more time interested in Metal. And since I was using Swift exclusively at work and did not mind working with ObjC for personal projects. At least with ObjC you can interact with C++.

Coming to present time. I was exploring different UIKit alternatives and I came across two which got me interested in Metal one more time. These are ComponentKit and Flutter. ComponentKit inspired me try writing something entirely in ObjC++, which had never ever occured to me. Although, I’m still confused where would I set the boundary, but I definately wanna try it just to get the feel. Flutter got me interested in Metal because of this ticket: Flutter should use Metal instead of OpenGL on iOS.

It is not exactly this ticket, but more like the idea that a lot of people are actually avoiding Metal, because of the obvious reasons I did, but Metal as an API in itself is really amazing from what I remember, and it makes total sense from Apple perspective to own their own GPU API as it would give them total freedom, and on top of Metal being ObjC has an advantage that it can exposed to Swift with zero hiccups. I mean it all makes sense, and to be honest I feel a bit bad for the team working on the Metal API.

So, today I’ll try to render something on screen with Metal and get a feel of the API one more time. Here we go.

Set up

I’ll try to rewrite the hello metal one more time. I’ll use swift because I also wanna see how easy is it these days developing Metal apps with swift. I do remember that one of selling point of Metal was to share model data between the app code (in ObjC) and metal shaders by using simd C type struct. Don’t know how much of that would apply to swift.

Hello Triangle

To have a triangle on screen, these are the steps we need:

Get the GPU
Allocate some memory buffer on the GPU and copy the triangle vertex data there.
Write a shader to read the vertex data from step above.
Set up the render pipeline with the shader.
Set up a command queue to send draw commands to the GPU.
Set up a command buffer where the actual commands will live.
Set up a command encoder to append commands to the command buffer.
Render!

Set up device (GPU)

Getting the device is pretty simple actually.

func setUp() {
    self.device = MTLCreateSystemDefaultDevice()
}

Set up draw data

Metal supports two kind of resources: buffer and image data. Buffer is where we can put the vertex data and image data is where we can put the textures.

Writing this part of code with Swift is a bit awkward because of the ObjC bridge but still whatever works.

let vertexData: [Float] = [
    0.0, 1.0, 0.0,
    -1.0, -1.0, 0.0,
    1.0, -1.0, 0.0
]
let length = vertexData.count * MemoryLayout.size(ofValue: vertexData[0])
vertexBuffer = device?.makeBuffer(bytes: vertexData, length: length)

Write shader

Writing a metal shader is almost the same as GLSL. We need a vertex shader and fragment shader.

For our use case, our vertex shader is very simple. It just reads an array of float3 and returns a float4 for each vertex of the geometry.

vertex float4 vsh_flat(const device packed_float3 *vertexArray [[ buffer(0) ]], unsigned int vid [[ vertex_id ]]) {
    return float4(vertexArray[vid], 1.0);
}

The fragment shader is even simpler. We simply return a white color for each pixel.

fragment half4 fsh_flat() {
    return half4(1.0);
}

Set up pipeline

With Metal we can compile all our shaders at build time. All the compiled shaders then can be accessed from the library at runtime.

func setUp() {
    // ...
    let library = device?.makeDefaultLibrary()
    let vertShader = library?.makeFunction(name: "vsh_flat")
    let fragShader = library?.makeFunction(name: "fsh_flat")
    // ...
}

To create the render pipeline we just need to plug in the shaders and we are done.

func setUp() {
    // ...
    let pipelineDescriptor = MTLRenderPipelineDescriptor()
    pipelineDescriptor.vertexFunction = vertShader
    pipelineDescriptor.fragmentFunction = fragShader
    pipelineDescriptor.colorAttachments[0].pixelFormat = pixelFormat
    pipeline = device.flatMap { try? $0.makeRenderPipelineState(descriptor: pipelineDescriptor) }
    // ...
}

Set up command queue

Next, we get the command queue where we would submit all our command buffers.

private func setUp() {
    // ...
    commandQueue = device?.makeCommandQueue()
}

Set up Command buffer

Think of one command buffer as one drawing frame. Which could even have multiple render passes if required.

After a buffer is submitted to the queue, we can either wait for the GPU to finish rendering, or use a callback to get notification.

func render (/* ... */, drawable: MTLDrawable) {        
    let commandBuffer = commandQueue?.makeCommandBuffer()
    // ...
    commandBuffer?.present(drawable)
    commandBuffer?.commit()
    commandBuffer?.waitUntilCompleted()
}

Render pass

Metal way of making things like the render encoder is to use a descriptor object where all the configuration values can be set. This is very similar to Vulkan, but looks less verbose due to the C/C++ aggregate initialization, also one of the reasons why ComponentKit uses C++.

func render(drawableTexture: MTLTexture, /* ... */ ) {
    // ...
    let renderPassDescriptor = MTLRenderPassDescriptor()
    renderPassDescriptor.colorAttachments[0].texture = drawableTexture
    renderPassDescriptor.colorAttachments[0].loadAction = .clear
    renderPassDescriptor.colorAttachments[0].clearColor = MTLClearColor(red: 0.5, green: 0.5, blue: 0.5, alpha: 1.0)
    // ...
}

Commands can be submitted only via a command encoder. We need the MTLRenderCommandEncoder to encode draw commands. Only one encoder can be active at a time for a command buffer.

func render(drawableTexture: MTLTexture, /* ... */ ) {
    // ...
    let renderEncoder = commandBuffer?.makeRenderCommandEncoder(descriptor: renderPassDescriptor!)
    renderEncoder?.setRenderPipelineState(pipeline!)
    // ...
}

Next step is submit the actual draw calls and close the encoder.

func render(drawableTexture: MTLTexture) {
    // ...
    renderEncoder?.setVertexBuffer(vertexBuffer, offset: 0, index: 0)
    renderEncoder?.drawPrimitives(type: .triangle, vertexStart: 0, vertexCount: 3)
    renderEncoder?.endEncoding()
    // ...
}

Set up drawable

Final step is bind the renderer with a drawing surface, in our case a CAMetalLayer or a MTKView. Here we simply call the setUp on the RenderingEngine at appropriate times.

class Renderer {
    private let metalView: MTKView
    private let renderingEngine = RenderingEngine()
    
    init(metalView: MTKView) {
        self.metalView = metalView
    }
    
    func setUp() {
        renderingEngine.setUp()
        
        metalView.device = renderingEngine.device
        
        let metalLayer = metalView.layer as? CAMetalLayer
        assert(metalLayer != nil)
        
        metalLayer?.pixelFormat = renderingEngine.pixelFormat
        
        metalView.framebufferOnly = true
    }

    // ...    
}

class GameViewController: NSViewController {

    var renderer: Renderer?

    override func viewDidLoad() {
        super.viewDidLoad()
        
        let metalView = view as? MTKView
        assert(metalView != nil)
        
        renderer = Renderer(metalView: metalView!)
        assert(renderer != nil)
        
        renderer?.setUp()
    }

    // ...
}

Render

After everything is in place, we can call the render to see our beautiful triangle on screen.

class Renderer {

    // ...
    
    func render() {
        let metalLayer = metalView.layer as? CAMetalLayer
        assert(metalLayer != nil)

        let drawable = metalLayer?.nextDrawable()
        assert(drawable != nil)
        
        renderingEngine.render(drawableTexture: drawable!.texture, drawable: drawable!)
    }
}

class GameViewController: NSViewController {

    // ...

    override func viewDidAppear() {
        super.viewDidAppear()
        
        renderer?.render()
    }
}

Benefit?

The code is also available on Github github.com/chunkyguy/try-metal

Hello Flutter

2018-12-14T20:49:54+00:00

Another weekend another tool. The tool for today is Flutter.

Why Flutter?

I had known about Flutter for sometime now, but with the recent news of Flutter 1.0 being out, I got curious about it one more time. Then, recently at work someone ignited my real interest by informing me that Flutter does its own rendering from scratch. I had to try it out.

In the past, I used to wonder a lot that why is that when it comes to cross platform mobile developement, nobody has written a UIKit alternative from scratch or maybe on top of some existing widget library and make it work on all sort of mobile devices. I mean how hard could it be? Given that there are people writing game engines using OpenGL ES, Metal or Vulkan all the time, but why not a UI framework. And that is exactly what Flutter does.

For me it was a love at first sight.

I read a few articles on the official source to get a hang of it. To know more about the vision of the project. I knew this is a product from Google, so I wanted to be sure they’re not baised towards Android. When they’re investing in this tool, what are they getting out of it? Like my initial impression of Xamarin was that Microsoft wants developers to write cross platform apps with Xamarin, and also make a Windows mobile app as a side effect.

But, so far with Flutter this does not seems to be the case, even though they demo a lot with Material designs which looks a lot like Android UI, but then Flutter comes with a rendering engine of its own, and one can render whatever they feel like. There is even a UIKit like widget library which they call as Cupertino.

Then a few hours into making my first Flutter app it occured to me that maybe with Flutter the thing Google is selling is the Dart programming language. I think Google likes to see Dart as a lightweight programming language which is good for quickly iterating and building things as fast as possible. A good candidate for making web and mobile apps. And there is nothing wrong with that. From little experience I had with Dart, I found nothing unlikable about it. At least they did not pick Javascript.

I know most of Game Engines ship a core engine written with a high performance system language like C or C++, and a high level language for writing the actual game, like Lua. Which is also what Flutter does, the core engine is written in C++ and Dart is used to then write the app.

Set up

Whatever they say on the official instructions works out of the box. Although there are quite of bunch of things that have to be installed to get the thing running, but that is expected when installing a tool for cross platform development. The instructions come in 2 flavors, Android Studio and Visual Studio Code (again reflecting the fact that Google does not wants to be biased towards Android). I followed the instructions for Visual Studio Code and it just works.

First run

Okay, even before I get to the part of running the app. I would like acknowledge the fact that how awesome is Visual Studio Code. This is the first time I’m actually using it for anything and I really like it.

Being an iOS developer, I want to give iOS a try first. I created a new project and selected iPhone Simulator (which it magically discovered) And viola!

Next, I lets give Android a run. But can’t find a way to run the app on Android emulator. The drop down shown only the iOS simulator. The faq section says this about switching the target device, but they do nothing:

Clicking on the currently selected device in the status bar
Executing the Flutter: Change Device command
Pressing your custom key binding for the Flutter: Change Device command

Then I discovered, if Flutter can not find an Android emulator, try running it manually by launching the Android Studio > Tool > AVD Manager > Run emulator and then the Android emulator is visible in the status bar.

And now I think, if the main target device is Android, then maybe it is wise to set up the IDE as Android Studio. Anyways, after that part is taken care of, the app runs perfectly on Android emulator as well!

Make the real app

Now, since we have tested the tool and know for sure that the simulators are working perfectly, it’s time to dive a bit deeper and make a real app.

As always, I’ll try to make the Photo app that I try to make every now and then, but probably not today. There seems to be a lot of things that I’ve to learn before I get to that stage. The first stage would be render a list of things and navigate to a details screen when a cell is tapped. But no real networking or concurrency for this stage. I’ll be following the google codelabs part 1 and part 2

So, everything in Flutter is a Widget, which is again very common pattern with Game Engines to have everything as a Node and each node implements a update() and render() functions which are then called by the engine whenever required. In case of Flutter, there is only one function that has to be implemented which is the build() function.

Another concept at the core of Flutter is the react like philosopy, where data flows in one direction so every node or Widget is more or less a stateless entity. Think of it this way, in every UI systems like UIKit or every game engines, at the core there is this tree like data structure, some call it the scene graph other call it the view hierarchy. And then there is is the infinite loop that traverses the tree and updates each node of the tree.

void main()
{
  SceneGraph *rootNode = buildSceneGraph();
  Clock c;
  Event e;
  while(!e.isQuit()) 
  {
    e = nextEvent();
    rootNode->update(c.deltaTime());
    c.tick();
  }
}

So, traditionally each node in the tree had to maintain its own state, which has a tendency to getting messier over time. The react philosophy is more like to not let direct access to nodes, but instead only provide the factory methods which takes in some model data and returns a new node. The tree is the internally managed by the system, and whenever the data changes the factory method would be called to build the new node.

I’m personally a big fan of this philosophy. With this approach, one could freely optimize the tree manipulation as much as they like and on the other hand one could focus only on providing the factory methods. The only part that gets a bit messier is the animation which by definition can not be stateless.

Coming back to Flutter, the build() function is like the factory method that uses some model data and makes a Widget.

Another nice thing about Flutter is that it comes its own package manager. You just have to define the dependencies in the pubspec.yaml and then simply run flutter package get. Nice!

With all this basic understanding of the architecture, writing the first table view is pretty dead simple. I guess this piece of code is self explainatory:

class ListState extends State<Item> {
  final _list = <Item>[];
  Widget _buildWidget() {
    return new ListView.builder(
      padding: const EdgeInsets.all(16.0),
      itemBuilder: (BuildContext _context, int i) {
        if (_needsMoreItems(i)) {
          _data.addAll(_getMoreItems());
        }
        return _buildRow(_data[i]);
      }
    );
  }
}

Since everything is a Widget, it is a piece of cake to add decorations to a Widget

Icon
(
  isSaved ? Icons.favorite : Icons.favorite_border,
  color: isSaved ? Colors.red : null,
)

Another interesting fact is that Flutter builds a Xcode project internally which one can simply open and run. And if one looks close enough, one can find that there is just a single UIView that renders everything.

One question I still had was how does the one maintains a state if required. For example, if say we want to react on a touch interaction we need to use the StatefulWidget which then comes with a createState() function that can provide access to some internal data store where we can read and write data like so:

onTap: () {
  setState((){
    if (isSaved) {
      _saved.remove(word);
    } else {
      _saved.add(word);
    }
  });
}

If you think that is weird, see how the screen transitions are done:

void onDetails() {
  Navigator.of(context)
      .push(MaterialPageRoute<void>(builder: (BuildContext context) {
    final Iterable<ListTile> tiles = _saved.map((WordPair word) {
      return ListTile(title: Text(word.asPascalCase, style: _biggerFont));
    });

    final List<Widget> children =
        ListTile.divideTiles(context: context, tiles: tiles).toList();

    return Scaffold(
        appBar: AppBar(title: const Text('Favorites')),
        body: ListView(children: children));
  }));
}

Conclusion

If you can move out of your comfortable UIKit zone, I think Flutter is a pretty good tool. The performance so far was really nice (at least on the simulators). I can not say much anymore, I would have to complete my photo app to give any good opinion, but I can already say that so far with all the things I’ve tried with cross platform development, Flutter was the best.

The code can be found along with my other prototypes at https://github.com/chunkyguy/PhotoApp. Thansk for reading. See you again later!

Cross platform mobile development with Djinni

2018-11-23T22:54:00+00:00

Motivation

One of my last years goal was to make a Android app. It just occurred to me that even though I had been making app for such a long time, I had never made an Android. The app that I eventually made was far from being anything but glorious. It was just a empty with a label saying Hello World. Nonetheless, it was a milestone of my career. I should also mention, that being a Java illiterate I wrote that app in C++, so most my time was actually spent fighting with the JNI.

To continue the story, this year I want to make a cross platform app. Like one codebase that runs on both iOS and Android. I’ll be using C++ as much as I can. I’ve heard good things about the Djinni from Dropbox, so I’ll try that.

Hello Djinni

I’ve already seen the CppCon 2017 and CppCon 2014 videos already. I found this awesome tutorial which I would be following and see how it goes.

The first part is setting up. If you already have Android studio set up, good, otherwise be prepared to spend half a day setting up the system. But, on the bright side everything works as documented, no random issues. The real game begins when everything is setup.

For testing the water, I cloned the Djinni from the repo and tried running it for a simple interface:

photoapp = interface +c {
  static create(): photoapp;
  get_photoapp(): string;
}

With a simple command

../djinni/src/run \
   --java-out $java_out \
   --java-package $java_package \
   --ident-java-field mFooBar \
   --cpp-out $cpp_out \
   --cpp-namespace $namespace \
   --jni-out $jni_out \
   --ident-jni-class NativeFooBar \
   --ident-jni-file NativeFooBar \
   --objc-out $objc_out \
   --objc-type-prefix $objc_prefix \
   --objcpp-out $objc_out \
   --idl $djinni_file

And after downloading a bunch of more stuff, it chokes on some random Unresolved dependencies error. Retrying with sudo does not help either. From what I understand, the Djinni is build with Scala and there is this sbt that builds the projects. When running the packaged ./src/build, the installer hangs on some dependency issues. Next step could be try building directly with sbt with

$ brew install sbt@1

Next, I would try running the installer directly.

$ sbt

This, launches the interactive shell. After loading the setting for the current Djinni project, the shell waits for me provide inputs.

> help
  tasks                                   Lists the tasks defined for the current project.

This sounds promosing.

  compile          Compiles sources.
[success] Total time: 32 s, completed Nov 24, 2018 3:22:17 PM

Finally, the war with installing Djinni seems to be over. Next up making the actual app.

Setting up the structure

The first question I’ve is to figure out how the file system looks like with a cross platform app. This is how the example app seems to be laid out.

photoapp.djinni 	; Djinni input IDL file
generated-src/		; Djinni output
handwritten-src/	; Shared implementation
android/			; Android app
ios/				; iOS app

I like this, except I would like to wrap all common parts in one directory. Something like:

shared/photoapp.djinni 		; Djinni input IDL file
shared/generated-src/		; Djinni output
shared/handwritten-src/		; Shared implementation
android/					; Android app
ios/						; iOS app

After a simple run, the ls -R looks like:

shared

./shared:
generated-src   photoapp.djinni run_djinni.sh

./shared/generated-src:
cpp  java jni  objc

./shared/generated-src/cpp:
photoapp.hpp

./shared/generated-src/java:
com

./shared/generated-src/java/com:
whackylabs

./shared/generated-src/java/com/whackylabs:
photoapp

./shared/generated-src/java/com/whackylabs/photoapp:
Photoapp.java

./shared/generated-src/jni:
NativePhotoapp.cpp NativePhotoapp.hpp

./shared/generated-src/objc:
PAPhotoapp+Private.h  PAPhotoapp+Private.mm PAPhotoapp.h

My first struggle is what editor to open the files in. I know at some point I’m going to create a Xcode project, so I can do that right now. The problem I have with editing standalone files is that they do not get any Xcode magic, no autocompletion or even good syntax highlighting. It is almost same as editing in a Notepad. We can think of the codebase composed of 3 independent components:

PhotoAppLib: C++ library
PhotoApp iOS: iOS client
PhotoApp Android: Android client

With that in place, this is how the structure looks like:

shared/photoapp.djinni 		; Djinni input IDL file
shared/generated-src/		; Djinni output
shared/lib/					; Shared implementation
android/					; Android app
ios/						; iOS app

Setting up the iOS client

Tackling this part first since I’ve know all ins and outs of Xcode. Also I believe that with every cross platform development everyone has one favorite client, for me that is iOS and Android would be more or less a side product.

A way to set up the whole project could be to simply wrap the library in its own which comes bundled with a bunch of header files. Or another way could be to include all the files required by each clients. I personally like the latter to avoid dealing with link time issues. All the issues would be discovered at compile time and after the compiler is done the rest should sail smoothly.

With all the necessary files in the project, when I do a build I get the error DJICppWrapperCache+Private.h not found. And indeed when I look in my project I don’t find that file. Maybe there is something I missed somewhere, because I do see these files somewhere in the support-lib for Djinni source, but somehow these did not made into the autogenerated project. Could be that I was supposed to bring these in manually, so let’s do that.

Turns out that was indeed the missing puzzle. This is how the iOS project looks like

And here is the text on screen

Setting up the Android client

This would be even more interesting to set up, since I’ve almost 0 experience with Android Studio or even how Java build system and runtime works. But, it seems the out of the box for C++ from Android has greatly improved since the last time I experimented with it. Last time I had to download and install the NDK and it was so much painful as if the Android people did not want anyone to even write C++. This time the set up is almost as clean as in Xcode, you just simply tick the correct boxes and a hello world app template pops up. Nice!

And on top of it the build system is now a rather familiar Cmake. I really love this new Android development environment. This is my CmakeLists.txt:

cmake_minimum_required(VERSION 3.4.1)

# Add shared files
file(
        GLOB photoapp_sources
        ../../shared/support-lib/jni/*.cpp
        ../../shared/generated-src/jni/*.cpp
        ../../shared/src/*.cpp
)

# Provide include files
include_directories(
        ../../shared/support-lib/
        ../../shared/support-lib/jni/
        ../../shared/src/
        ../../shared/generated-src/cpp/
        ../../shared/generated-src/jni/
)

# Create library from the shared files
add_library(
        photoapplib
        SHARED
        ${photoapp_sources}
)

# Link library
target_link_libraries(photoapplib)

And then after reading the same string from the shared library and rendering it on a TextView we get

Thanks

So how do I feel about Djinni so far? I would say, I did like it a lot, if I would every have to do a cross platform mobile app, I would love to do it with Djinni. I also did love the fact that how much improvements have been made in the Android IDE to support C++.

I’ll probably expand this project further to the regular PhotoApp that I try to make with every toolkit that I try, which involves fetching some data, parsing it and rendering it on screen. I’ll also post my notes here on this blog.

The entire project is available for referencing.

Thanks for reading!

Experimenting with ComponentKit

2018-11-09T18:18:00+00:00

It’s a nice Friday afternoon and I just realized that I’ve never used ComponentKit.

One of the reasons that got me really interested in the project is that, I’ve been looking around alternatives to UIKit. Not that I’ve anything against UIKit, but I seen how things out of hands with UIKit pretty soon. And ComponentKit was on my radar for quite some time.

Also, I’m a huge fan of C++, but so far the only ObjectiveC++ I’ve written was just to glue ObjectiveC with C++, like I would start with an AppEngine.cpp and forward all the call from the AppDelegate to the AppEngine. ComponentKit on the other hand, seems to be making full use of C++ and ObjectiveC in the same space. Which sounds weird enough for me to at least try this thing out.

Building an App with ComponentKit

I will be building the PhotoApp that I try to build every now and then but this time with ComponentKit. What the PhotoApp does is that it starts with a loading screen while we fetch a list of photo and when we are done we render them on screen. Next, whenever a user taps on the cell, we display the details screen with the photo in more details and some text.

This is pretty simple app that touches many parts of most of the apps out there. Okay, let’s go!

Set up

The first step is to checkout the repository from github The recommended way is to use Carthage. It’s been a long time since I’ve used Carthage, personally I like to manage all my dependencies manually, which is know is not a popular opinion these days. So, let’s give Carthage a shot.

Following the instructions from https://github.com/Carthage/Carthage#quick-start, this is now my Cartfie looks like:

github "facebook/ComponentKit" ~> 0.24

Now, I can run ` carthage update`… and it does not work

*** Fetching ComponentKit
*** Checking out ComponentKit at "0.24"
*** xcodebuild output can be found in /var/folders/wv/x1yzd_351bbbwgyps66xgytw0000gn/T/carthage-xcodebuild.NGYTMn.log
*** Building scheme "ComponentKit" in ComponentKit.xcodeproj
Build Failed
	Task failed with exit code 65:
	/usr/bin/xcrun xcodebuild -project /Users/sid/Work/Personal/PhotoApp/component-kit/Carthage/Checkouts/ComponentKit/ComponentKit.xcodeproj -scheme ComponentKit -configuration Release -derivedDataPath /Users/sid/Library/Caches/org.carthage.CarthageKit/DerivedData/9.2_9C40b/ComponentKit/0.24 -sdk iphoneos ONLY_ACTIVE_ARCH=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES archive -archivePath /var/folders/wv/x1yzd_351bbbwgyps66xgytw0000gn/T/ComponentKit SKIP_INSTALL=YES GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=NO CLANG_ENABLE_CODE_COVERAGE=NO STRIP_INSTALLED_PRODUCT=NO (launched in /Users/sid/Work/Personal/PhotoApp/component-kit/Carthage/Checkouts/ComponentKit)

This usually indicates that project itself failed to compile. Please check the xcodebuild log for more details: /var/folders/wv/x1yzd_351bbbwgyps66xgytw0000gn/T/carthage-xcodebuild.NGYTMn.log

Life is too short to read a log message. Time for plan B; Manually building the workspace.

The very first thing one notices after the setup is that how much time it takes for the ComponentKit to compile. I’ve been using Swift mostly at work for past 4 years now, and there compile time is unacceptable, and that is why whenever I’m working on something on a Friday evening, I pick something blazing fast, which ObjectiveC is, but ObjectiveC++ is not.

Whenever I’m working on an ObjC project, the very first thing I do is to toggle the TREAT_WARNINGS_AS_ERRORS flag to YES. And I wish every other project does the same, specially a project as widely used as ComponentKit.

Getting started

Okay all code set up and ready to go, the first challenge is to figure out where to start. To be honest, I’ve no clue, so I’ll looking at the sample WildeGuess project. Like, WildeGuessCollectionViewController I’m also planning to start out with a UICollectionView, so that is a good thing.

The most important piece of the system when working with a UICollectionView based layout is CKCollectionViewDataSource. This object is who you talk to whenever the data updates. Probably the first piece of information we want to inform the data source is the number of section we intend to display. Unlike traditional UICollectionViewDataSource, we do not provide a integer value, rather, we provide the change set.

For our case, we already know at the load time that there is going to be one section, which contains the loading view. We need to provide that information as a change set, as the data source starts with zero sections.

    CKDataSourceChangeset *initialData = [[[CKDataSourceChangesetBuilder transactionalComponentDataSourceChangeset]
                                           withInsertedSections:[NSIndexSet indexSetWithIndex:0]]build];
    [_dataSource applyChangeset:initialData mode:CKUpdateModeAsynchronous userInfo:nil];

Before I get my hands dirty with building components, I would also like to plug in the other thing data source might be interested in. And that is a event callback for whenever a cell starts or ends displaying is invoked we want to update our data source with this information. In our case this is the willDisplayCell and didEndDisplayingCell of UICollectionViewDelegate

- (void)collectionView:(UICollectionView *)collectionView
       willDisplayCell:(UICollectionViewCell *)cell
    forItemAtIndexPath:(NSIndexPath *)indexPath
{
    [_dataSource announceWillDisplayCell:cell];
}

- (void)collectionView:(UICollectionView *)collectionView
  didEndDisplayingCell:(UICollectionViewCell *)cell
    forItemAtIndexPath:(NSIndexPath *)indexPath
{
    [_dataSource announceDidEndDisplayingCell:cell];
}

With our basic data source set up, we can now focus on providing the first view. Usually when we start our layout with a UICollectionView the first thing that comes to mind it to have a bunch of UICollectionViewCell and register them and later whenever UIKit needs to render them on screen, we paint them. With ComponentKit things are different, we probably only need to create a UICollectionView and leave the rest to ComponentKit. The starting point of the entire component system seems to be this CKComponentProvider which is a protocol with a class method, and the context is provided as an argument. Neat.

+ (CKComponent *)componentForModel:(id<NSObject>)model context:(id<NSObject>)context;

So, my first attempt would be insert a NSNull and render an PHLoadingComponent for that model

    NSDictionary<NSIndexPath *, NSObject *> *loadingItem = @{[NSIndexPath indexPathForRow:0 inSection:0]: [NSNull null]};
    CKDataSourceChangeset *loadingData = [[[CKDataSourceChangesetBuilder transactionalComponentDataSourceChangeset] withInsertedItems:loadingItem] build];
    [_dataSource applyChangeset:loadingData mode:CKUpdateModeAsynchronous userInfo:nil];

Creating first component

Creating a component does not seems as trivial if you have been writing apps for some time. I know I’m not creating a view from scratch because that is the job of ComponentKit, I probably have to only provide the data for the view. But what data? Let’s start with a prebaked component CKLabelComponent

@interface PHLoadingComponent : CKCompositeComponent
+ (instancetype)newWithTintColor:(UIColor *)color;
@end

@implementation PHLoadingComponent

+ (instancetype)newWithTintColor:(UIColor *)color
{
    return [super newWithComponent:[CKLabelComponent
                                    newWithLabelAttributes:{
                                        .string = @"Loading"
                                    }
                                    viewAttributes:{
                                        {@selector(setBackgroundColor:), color},
                                        {@selector(setUserInteractionEnabled:), @NO}
                                    }
                                    size:{}]];
}

@end

Not bad! So, by simply providing the text data I can get a view. How about making it full screen and replacing the text with a UIActivityIndicatorView.

To be honest the official documentation is outdated as I can not find anything about everything, for example CKFlexboxComponent is not there. So the only way out is to actually check the source code, which is probably even better than looking up the docs.

From what I’ve figured out, the way one creates components for views is by providing the Class type and a bunch of selectors to be invoked. Imagine it this way, if you were to create a custom view with a UIActivityIndicatorView, you might do it like:

-(UIActivityIndicatorView *) makeSpinnerWithColor: (UIColor *)color
{
    UIActivityIndicatorView *spinner = [[UIActivityIndicatorView alloc] initWithFrame:[UIScreen mainScreen].bounds];
    [spinner setColor:color];
    [spinner setActivityIndicatorViewStyle:UIActivityIndicatorViewStyleWhiteLarge];
    return spinner
}

With ComponentKit, you might do it like:

-(CKComponent *) makeSpinnerWithColor: (UIColor *)color
{
    return [CKComponent
            newWithView:{
                [UIActivityIndicatorView class],
                {
                    {@selector(setColor:), color},
                    {@selector(setActivityIndicatorViewStyle:), UIActivityIndicatorViewStyleWhiteLarge}
                }
            }
            size: CKComponentSize::fromCGSize([UIScreen mainScreen].bounds.size)];
}

With that in place, we have a loading screen.

Next step is to get the activity indicator start and stop animating. Which is pretty simple

{@selector(startAnimating), nil}

Rendering list of images

Next step, rendering a bunch of images. The first part is easy, making a network request and get a JSON payload containing a bunch of image URLs.

- (void)updateImages
{
    NSArray *images = _viewModel.list;
    NSUInteger count = images.count;
    NSMutableDictionary<NSIndexPath *, PAListItemViewModel *> *photoList = [NSMutableDictionary dictionaryWithCapacity:count];
    for (NSInteger idx = 0; idx < count; ++idx) {
        [photoList
         setObject:[_viewModel itemAtIndex:idx]
         forKey:[NSIndexPath indexPathForRow:idx inSection:0]];
    }

    CKDataSourceChangeset *loadingData = [[[CKDataSourceChangesetBuilder transactionalComponentDataSourceChangeset] withInsertedItems:photoList] build];
    [_dataSource applyChangeset:loadingData mode:CKUpdateModeAsynchronous userInfo:nil];
}

The tricky part is fetching the images. Normally we have to consider the fact that the user might be scrolling and the cell that started the network request could be out of view already, and we don’t want to render wrong images on wrong cells. So, there has to be a owner of the network callback, from what I’ve read so far that job is usually for the ComponentController, but then I also something called CKNetworkImageComponent.

To make that happen, first step is provide a concrete implementation of CKNetworkImageDownloading which is pretty close to what PANetworkService is doing already. Here is a naive implementation

- (id)downloadImageWithURL:(NSURL *)URL
                    caller:(id)caller
             callbackQueue:(dispatch_queue_t)callbackQueue
     downloadProgressBlock:(void (^)(CGFloat progress))downloadProgressBlock
                completion:(void (^)(CGImageRef image, NSError *error))completion;
{
    [PANetworkService getPhotoWithURL:URL completion:^(UIImage * _Nullable image) {
        dispatch_async(callbackQueue, ^{
            if (image == nil) {
                completion(nil, [NSError
                                 errorWithDomain:@"com.wl.error.image"
                                 code:0
                                 userInfo:nil]);
            } else {
                completion(image.CGImage, nil);
            }
        });
    }];
    return [URL absoluteString];
}

And the second step is then to create the component

@implementation PHPhotoComponent
+ (instancetype)newWithPhoto:(PAPhoto *)photo
             imageDownloader:(PAImageDownloader *)imageDownloader;
{
    UIImage *placeholderImage = [PAImageLoader placeholderImage];
    CKComponent *imageComponent = [CKNetworkImageComponent
                                   newWithURL:[photo imageURLWithResolution:ImageResolutionThumbnail]
                                   imageDownloader:imageDownloader
                                   size:CKComponentSize::fromCGSize(placeholderImage.size)
                                   options:{ .defaultImage = placeholderImage }
                                   attributes:{}];
    return [super newWithComponent:imageComponent];
}
@end

User interactions

Next we want the react on whenever a user taps on the cell, and here is where CKComponentTapGestureAttribute comes into the picture. After playing around for a while, this is what seems to be working

@implementation PHPhotoComponent
+ (instancetype)newWithPhoto:(PAPhoto *)photo
             imageDownloader:(PAImageDownloader *)imageDownloader;
{
    UIImage *placeholderImage = [PAImageLoader placeholderImage];
    CKComponentSize size = CKComponentSize::fromCGSize(placeholderImage.size);
    CKComponent *imageComponent = [CKNetworkImageComponent
                                   newWithURL:[photo imageURLWithResolution:ImageResolutionThumbnail]
                                   imageDownloader:imageDownloader
                                   size:size
                                   options:{ .defaultImage = placeholderImage }
                                   attributes:{}];

    CKComponent *centerYComponent = [CKCenterLayoutComponent
                                     newWithCenteringOptions:CKCenterLayoutComponentCenteringY
                                     sizingOptions:CKCenterLayoutComponentSizingOptionMinimumY
                                     child:imageComponent
                                     size:{}];

    CKComponent *containerComponent = [CKFlexboxComponent
                                       newWithView:{
                                           [UIView class],
                                           {CKComponentTapGestureAttribute(@selector(onTap))}
                                       }
                                       size:{}
                                       style:{}
                                       children:{
                                           {centerYComponent}
                                       }];

    return [super newWithComponent:containerComponent];
}

- (void)onTap
{
    NSLog(@"show details");
}
@end

Whats left is hooking a listener to the event. From what I’ve read about the components is that they should not be set as delegate, as they are by design short lived immutables. So I’m imagining them as being disposed off after a draw cycle. So the question is how do we handle the touch event? To understand let’s see what is CKComponentTapGestureAttribute?

CKComponentViewAttributeValue CKComponentTapGestureAttribute(CKAction<UIGestureRecognizer *> action);

So it a function that takes a CKAction and returns a CKComponentViewAttributeValue. The CKAction on the other hand is a simple wrapper around the target selector pair, maybe we can use that. Or even better if we could construct the CKAction and inject it from outside.

        CKAction<UIGestureRecognizer *>action = CKAction<UIGestureRecognizer *>::actionFromBlock(^(CKComponent *, UIGestureRecognizer *__strong) {
            NSLog(@"did tap");
        });
        
        return [PHPhotoComponent
                newWithPhoto:(PAPhoto *)model
                imageDownloader:(PAImageDownloader *)context
                action: action];

The tricky part is sending the invocation back to the view controller. This whole component creation lives in a class method so has no reference to the view controller. One way to fix this is by passing the view controller as context.

@interface PHRootComponentProvider : NSObject
@end

@implementation PHRootComponentProvider

+ (CKComponent *)componentForModel:(id<NSObject>)model context:(id<NSObject>)context;
{
    if ([model isKindOfClass:[NSNull class]]) {
        return [PHRootComponentProvider loadingComponent];
    } else if ([model isKindOfClass:[PAPhoto class]]) {
        return [PHRootComponentProvider
                componentForPhoto:(PAPhoto *)model
                sender:(PHViewController *)context];
    } else {
        NSAssert(NO, @"Should not happen");
        return nil;
    }
}

+ (CKComponent *)loadingComponent
{
    return [PHLoadingComponent newWithTintColor:[UIColor redColor]];
}

+ (CKComponent *)componentForPhoto:(PAPhoto *)photo sender:(PHViewController *)sender;
{
    CKAction<UIGestureRecognizer *>action = CKAction<UIGestureRecognizer *>::actionFromBlock(^(CKComponent *, UIGestureRecognizer *__strong) {
        [sender onTap:photo];
    });

    return [PHPhotoComponent
            newWithPhoto:photo
            imageDownloader:sender.imageDownloader
            action: action];

}

@end

And then in the view controller

    _dataSource = [[CKCollectionViewDataSource alloc]
                   initWithCollectionView:_collectionView
                   supplementaryViewDataSource:nil
                   configuration:[[CKDataSourceConfiguration alloc]
                                  initWithComponentProvider:[PHRootComponentProvider class]
                                  context:self
                                  sizeRange:[[CKComponentFlexibleSizeRangeProvider
                                              providerWithFlexibility:CKComponentSizeRangeFlexibleHeight]
                                             sizeRangeForBoundingSize:self.view.bounds.size]]];

I’m not sure if this is how the design is intended to be.

Filling up the rest

The rest should not be hard to do. We need another view that shows the details of the photo. We can either build it using the ComponentKit, or could simply have static UIViewController. I like the fact that if we build the detail UI with ComponentKit we would not have to worry about making the UI scrollable in future if it turns out that the UI does not fit one of those small screens. Also, the fact that we can reuse the components.

Although I’m still not sure whether the better design is to have only a single UIViewController and only update the data source or have multiple view controllers. If I were to make a bet, I think UIViewController would be a better choice, as then the view caching could take some benefits or maybe not. Another question is, even if I were to pull the entire thing off with a single view controller, would it make sense to twist my arm around to get the default navigation push/pop animation by writing a fake animator class that reloads the UICollectionView as if it were a push/pop animation.

Conclusion

So what do I think of ComponentKit. I think its a great proof of concept that one could easily write the one directional UI, but I would not force to write the entire app with ComponentKit, but maybe only the critical screens.

I would definetely like to poke around to see how easy it is to build static screens with ComponentKit, like the ones where I know I don’t need a UICollectionView and maybe also do some animation.

The entire code is available at github.com/chunkyguy/PhotoApp sitting along the pure swift and pure Objc implementations.

Raytracing with libdispatch

2018-02-04T12:35:00+00:00

Problem

So, I decided to make the ray tracer render frames faster. It was getting significantly painful to make some change, build and run and wait for several minutes before the rendering completed.

Before any performance improvements, I profiled the time, it was around 10 minutes per frame.

This was when using a single thread for all the processing.

Solution

The good thing about a ray tracer is that, it is actually very straightforward to make every ray being traced as purely reentrant which makes them ideal candidate for concurrency. The only thing that needs special consideration is the data structure holding the pixel information. As each ray can take different time to compute the final color value, we need a way to synchronize the ray coordinates with the final color value, to avoid any race conditions between 2 concurrent write operations.

To illustrate the problem, a ray which hits no objects will be much faster to compute the final value than the ray which hit multiple objects and bounces all over the place. The first solution to such a solution could be to guard the write operation to the image data with a mutex.

// data structure for pixel data
Film film;

for (int j = ny - 1; j >= 0; --j) {
    for (int i = 0; i < nx; ++i) {
        // spawn a new thread
        simd::float3 color = getColor(nx, ny, ns, i, j, camera, space);

        // write color value by acquiring a mutex lock
        film.updateColor(color, i, j);
        // release mutex
    }
}

The reason this implementation is just a pseudo-code is that this will never scale up, as this algorithm requires number of threads equal to number of pixels of the target image. Which as per Amdahl’s law might do more harm than good.

libdispatch

The first solution that I actually tried was using Apple’s libdispatch. Grand Centeral Dispatch (GCD) or libdispatch is a high level concurrency library which moves the concurrency problem from threads to tasks. At the core of libdispatch lies the concept of queues. A queue can then run N number of tasks in parallel. With libdispatch, each operation can be thought of as a unit of work that can then be dispatched to any queue. The only challenge left then is to design the queue architecture and work units or operations to be performed.

For our case, if we think of each rendering of a pixel as an independent task then we can then simply schedule the tasks on a parallel queue. At the end of each trace, we need to update the shared data structure with color information. And once all the tasks are complete we are done!

The first thing we need is a serial queue filmQueue which is responsible for synchronizing write operations on film, which is just the pixel data store.

dispatch_queue_t filmQueue = dispatch_queue_create("com.whackylabs.srt", DISPATCH_QUEUE_SERIAL);

Next we can either make our own concurrent queue, or simply use one of the few system global concurrent. Let us call this parallel queue rayQueue which is the concurrent queue and manages the parallel execution of all the rays in the scene. With this task based approach we won’t have to manage the thread pool ourselves.

dispatch_queue_t rayQueue = dispatch_get_global_queue(QOS_CLASS_BACKGROUND, 0);

Now we can already implement our algorithm:

for (int j = ny - 1; j >= 0; --j) {
    for (int i = 0; i < nx; ++i) {
        dispatch_async(rayQueue, ^{
            float3 color = getColor(nx, ny, ns, i, j, camera, space);
            dispatch_async(filmQueue, ^{
                film.updateColor(color, i, j);
            });
        });
    }
}

With that in place, we now need a mechanism to notify us when the all the rays have evaluated a color, so that we can start processing the collected pixel data.

This is the job best suited for dispatch groups. You can think of dispatch group as a high level semaphore which waits for N resources and signals when all resources are released. To acquire the resource we have to call dispatch_group_enter and to release dispatch_group_leave. The signal is implemented with dispatch_group_notify.

Here’s how this would look:

dispatch_group_t rayTask = dispatch_group_create();

for (int j = ny - 1; j >= 0; --j) {
    for (int i = 0; i < nx; ++i) {
        dispatch_group_enter(rayTask);
        dispatch_async(rayQueue, ^{
            float3 color = getColor(nx, ny, ns, i, j, camera, space);
            dispatch_async(filmQueue, ^{
                film.updateColor(color, i, j);
                dispatch_group_leave(rayTask);
            });
        });
    }
}

dispatch_group_notify(rayTask, filmQueue, ^{
    film.process();
});

If you run this code as is, the program would exit even before the first ray has returned. The reason being that our main program runs on the main thread, and there is nothing holding our main thread from finishing. We could either use the main queue which is a serial queue around the main thread as our filmQueue. But I don’t like the idea, if we decide to have some better UI around our ray tracer, like a loading indicator or a progress bar, we would need the main thread for that.

For our current needs what we simply need is this one line at the end:

dispatch_main();

And that should keep the main thread busy forever. Which means our program never exits. That is also not very good. The fastest way around is then to explicitly exit the program when the image has been processed.

film.process();
dispatch_async(mainQueue, ^{
    exit(0);
});

With this change, I was able to reduce the run time from 10 minutes to 7 minutes 30 seconds. Not bad!

But this is not all, remember when we created the rayQueue we passed in the QOS_CLASS_BACKGROUND. This flag dictates the quality of service class, which gives the system a hint on what kind of operations is the queue going to perform. Here I picked background, which isn’t entirely true. By simply changing the quality of service class to QOS_CLASS_USER_INITIATED, the runtime goes down to around 4 minutes! Awesome!

Finally since we are mutating the film within filmQueue, we need to capture the reference. The way it’s done blocks is with the use of __block keyword.

__block Film film(nx, ny);

Conclusion

Although the free lunch is definitely over, but still it is amazing to realize how much performance gain can be achieved by simply using easy to use concurrency libraries such as libdispatch.

Maybe I’ll give the C++ standard thread library a shot. I would like to benchmark the gain of using std::async someday, but I doubt if they would be as much given the fact that concurrency is much more about what lies in the implementation, which I don’t think Apple cares for C++ standard as much as for their libdispatch.

The entire code is available at github.com/chunkyguy/SimpleRayTracer

Building command line tool without leaving Xcode

2018-01-06T10:59:00+00:00

Why Xcode?

I know a lot of people don’t like Xcode, or as it seems from my twitter feed. But I think Xcode is probably the best IDE out there for macOS. I’ve used it for probably 10 years now, and it has evolved pretty amazingly over time. As a matter of fact, this article is also being written with Xcode 9, since it has such a good markdown support now.

Although everyone has their personal good things about Xcode, my top 5 are:

Code autocompletion which works pretty flawlessly.
Jumping to function definition
Quick switching between header and implementation.
Clean interface
Integration with git

What a lot of people don’t realize is that Xcode is also a pretty awesome editor if you wish to make a command line executable with languages it supports, like C, C++, Objective-C, Swift and many more. The ugly part is the Xcode build system which takes a while to twist around to your preferred setting.

Lets make command line app with Xcode

I’ll walkthrough on how to set up Xcode to generate a command line tool with C++ without getting too distracted.

Create a new project

Set project settings

Let’s make a random texture generator.

Build and run

If all goes well you should see following in your console.

Hello, World!
Program ended with exit code: 0

Write some code

Let’s write some code to draw a ppm image.

void generateImage(const int nx, const int ny)
{
    std::cout << "P3" << std::endl;
    std::cout << nx << " " << ny << std::endl;
    std::cout << "255" << std::endl;
    
    for (int j = 0; j < ny; ++j) {
        for (int i = 0; i < nx; ++i) {
            float r = float(i)/float(nx);
            float g = float(j)/float(ny);
            float b = 0.2f;
            int rr = int(ceil(255.0f * r));
            int gg = int(ceil(255.0f * g));
            int bb = int(ceil(255.0f * b));
            std::cout << rr << " " << gg << " " << bb << std::endl;
        }
    }
}

int main(int argc, const char * argv[]) {
    int nx = 200, ny = 100;
    generateImage(nx, ny);
    return 0;
}

Generate image

Okay so the code compiles and runs fine, but where is the output? If we were to use direct command line, you could compile your code and usually the compiler would generate a a.out in your default directory. Xcode does similar, but instead of a.out it generates the <ProjectName>, in our case ImageGenerator somewhere in the build directory which is hidden far away from the source code directory.

One way to find the default build directory is to look in the Xcode preferences.

For my machine, the ImageGenerator is located in

/Users/sidharth/Library/Developer/Xcode/DerivedData/ImageGenerator-aaslasxqipptbbfaxzgbtanvywyt/Build/Products/Debug

If you open terminal, and switch to that directory, you can finally generate the output image with

./ImageGenerator > ~/Desktop/out.ppm

Next, if you open the ~/Desktop/out.ppm with Preview.app, you can finally see your masterpiece.

Automate process

As you can already feel, this system is very tiresome. For every change you make in your code, you need to take following steps to see the output:

Build and run
Switch to Terminal
Go to the build directory (as it is not guaranteed to be the same every build).
Execute the build
Switch to Preview.app, assuming the output path is always the same ~/Desktop/out.ppm

One of the first steps we can take is to write a shell script that does the steps above for you. And this is the job for a Xcode Build phase.

Next, add a Run Script phase

And add to the script

### copy output
cp $BUILD_DIR/Debug/ImageGenerator $SRCROOT/ImageGenerator.out
### generate image
$SRCROOT/ImageGenerator.out > ~/Desktop/out.ppm

Next when we update of generateImage() function to

void generateImage(const int nx, const int ny)
{
    std::cout << "P3" << std::endl;
    std::cout << nx << " " << ny << std::endl;
    std::cout << "255" << std::endl;
    
    for (int j = 0; j < ny; ++j) {
        for (int i = 0; i < nx; ++i) {
            float r = 0.2f;
            float g = float(i)/float(nx);
            float b = float(j)/float(ny);
            int rr = int(ceil(255.0f * r));
            int gg = int(ceil(255.0f * g));
            int bb = int(ceil(255.0f * b));
            std::cout << rr << " " << gg << " " << bb << std::endl;
        }
    }
}

We can simply do a CMD+B from Xcode and it should run the script as well. And if all goes well, by end the output image should be updated.

This script works fine, but it has flaw in it. The output is generated after the entire Build Phase is run, which happens after this script, as this script is also the part of Build Phase. So, every time we run the script, we are actually copying and executing the last executable generated from the last build. So, you would need to run CMD+B two times to see the output from the latest build.

You can also see it as follwing steps happening over time:

Build ImageGenerator001 begins
    Compile code version 001
    Copy ImageGenerator000 to source directory
    Generate image.ppm from ImageGenerator000
Build ImageGenerator001 ends
Create ImageGenerator001

Build ImageGenerator002 begins
    Compile code version 002
    Copy ImageGenerator001 to source directory
    Generate image.ppm from ImageGenerator001
Build ImageGenerator002 ends
Create ImageGenerator002

This might not be a problem if you Compile Phase takes little time. But, if your codebase is significant, running build twice might be too much.

Aggregate Target

One solution for this problem is to use Aggregate target. Go ahead and add an Aggregate target to your project.

Let’s call it ImageGeneratorOutput. Similar to our main ImageGenerator target, lets add a Run Script phase here. The only job of this target is to run the script. So, move the run phase into this script.

### copy output
cp $BUILD_DIR/Debug/ImageGenerator $SRCROOT/ImageGenerator.out
### generate image
$SRCROOT/ImageGenerator.out > ~/Desktop/out.ppm

And out script in the Build Phase of ImageGenerator can now be safely removed.

The last thing you need is to add Target Dependency in ImageGeneratorOutput to ImageGenerator. This will make sure that every time we build ImageGeneratorOutput, the ImageGenerator is built as an dependency.

Now, if all goes well and run CMD+B again with ImageGeneratorOutput scheme selected, the latest output image should be generated. To, understand what changed, lets take a look at our updated flow

Build ImageGeneratorOutput001 begins
    Build ImageGenerator001 begins
        Compile code version 001
    Build ImageGenerator001 ends
    Create ImageGenerator001
    Copy ImageGenerator001 to source directory
    Generate image.ppm from ImageGenerator001
Build ImageGeneratorOutput001 ends

Thanks

I hope this article inspires you into using Xcode more for your command line apps. The source code for the project we built here can be found at github.com/chunkyguy/demo-ImageGenerator

Enjoy and happy coding!

Writing first ray tracer

2017-12-30T11:02:00+00:00

One of the many goals I had for 2017 were:

Writing a ray tracer.
Restarting the blog.

Writing a ray tracer

Sometime when the trees were starting to shed their leaves for the winters, I was worried that I was falling behind my goals for the year. I finally decided to order the book I wanted to read for many years now. The following day I placed an order for Physically Based Rendering, which arrived within a long and sleepless month.

As I was close to finishing the first chapter, I realized I had never written a ray tracer. Although, many people tend to claim that writing a ray tracer is the most natural and natural first step in the beautiful world of computer graphics, or like how easy it is to write a ray tracing algorithm, as it requires no prior knowledge of any graphics API or how the graphics pipeline functions, for that matter. Still, I had never written it.

The closest I had ever been to understanding a ray tracer was when following the dissection of the mysterious and amusing ray tracer on a business card. As a follow up, I started following the articles on https://www.scratchapixel.com about ray tracing, to get a more in depth understanding of how would one go in order to write a ray tracer from scratch.

Although, these blogs were tempting enough for me to start diving into writing my first ray tracer, but still I was too busy (read lazy) to actually do it. Then, one day I ran across the minibook Ray tracing in one weekend. Although the book was probably designed to be finished within a weekend, and rightfully so, still I took it really slow and maybe finished in about a month.

For every chapter, I used to do my own side research as well. For example, when working on the camera, I would often go side track and read about the innards of a real life camera. How do things like appertures, depth of field are supposed to work? What is the role of a lens in camera, and so on. Also, while coding, I tried to write a bit modern-ish C++ and explore the Apple simd.h library for all my math needs, which interestingly has no or very less online presence. For example, there is no proper documentation except for the header files, and searching any thing with keywords simd would return results from anything related to the SSE instruction sets to the architecture itself.

Eventually, today, just when the year is about to end, I was able to render the final target image from the book!

https://github.com/chunkyguy/SimpleRayTracer

Restarting the blog

Another thing I had planned to do for a very long time was restarting this blog. The death of this blog started with some miscommunication between me and my hosting service Yahoo Small business India. Unfortunately my service renew date coincided with their transition to Aabaco. So every time I tried to renew my service I received a generic and unhelpful try again later error. At the same time, I was also moving continents, literally speaking. Later when I was finally settled and tried to renew the service again to my horror I received the message from them that due my failure to renew they had wiped my data from the server.

Eventually, I transferred the domain name and built the blog up from whatever scrap I could find. This entire process had left me a bit wretched to say the least. Also, at the same time I was having hard time finding something interesting to focus on that I could write about.

Finally, it was the goal of 2017 to restart the blog again, and if this post is published before the dawn of 2018 I believe 2017 was a great year after all for me!

I hope you had a great year too! Let’s carry the positive spirit to 2018!

Generic Programming: The Concept

2015-06-27T17:58:54+00:00

Problem

Say, we have a type Animal which is at this time just an idea, so a protocol.

protocol Animal {
    func say()
}

Next, say we want a generic function that works with Animal.

func greet<T: Animal>(animal: T) {
    animal.say()
}

Looks good. Now let’s create our concrete types.

class Mammal: Animal {
    func say() {
        println("Hello! I'm a mammal!")
    }
}

class Reptile: Animal {
    func say() {
        println("Hello! I'm a replite")
    }
}

And bring it to use

let m = Mammal()
let r = Reptile()
let animals: [Animal] = [m, r]

for animal in animals {
    greet(animal)

}

Oh o! Unfortunately this code won’t compile. This is the error the compiler might throw on your machine.

error: generic parameter 'T' cannot be bound to non-@objc protocol type 'Animal'

Let’s rewrite our implementation in C++ and see what sort of error we get.

class Animal {
public:
    virtual void Say() const = 0;
};

template <typename T>
void Greet(const T &t) {
    t.Say();
}

class Mammal: public Animal {
public:
    void Say() const {
        std::cout << "Hello! I'm a mammal." << std::endl;
    }
};

class Reptile: public Animal {
public:
    void Say() const {
        std::cout << "Hello! I'm a reptile." << std::endl;
    }
};

int main() {
    Mammal m;
    Reptile r;
    std::vector<Animal> animals = {m, r};
    std::for_each(animals.begin(), animals.end(), [](const Animal &animal) {
        animal.Say();
    });
    return 0;
}

If you compile this with your C++11 compiler clang++ -std=c++11 -stdlib=libc++ code.cpp, you might get an error such as:

error: allocating an object of abstract class type 'Animal'

But, we are never allocating the instance of type Animal right? This is time to get our understanding of Generic Programming better.

Terminology

Generic Programming works around these main terminologies:

Concept
Model
Refinement
Type Constraint

Concept is the core design or interface. Model is what conforms to the Concept and provides a implementation of the Concept. Refinement is like inheriting a Concept and adding more things to it. And finally Type Constraint deals with specifying what and what not a Type that wishes to use the Concept is allowed to do.

In C++, we can have a pure virtual base class, where the base class provides no implementation for any member function. Swift hipster might know this idea as a protocol.

Along with that we have something in Swift that C++ programmers are not used to. It’s the use of protocol for Type Constraint. With C++, the compiler implicitly adds the Type Constraint for us.

Let’s take a look at some examples.

This is a Concept:

class Animal {
    public:
    virtual void Say() const = 0;
};

This is a Model:

class Mammal: public Animal { ... }

This is Refinement:

class WalkingAnimal: public Animal {
    public:
    virtual void Walk() const = 0;
};

This is a Type Constraint:

protocol Equatable {
    func ==(lhs: Self, rhs: Self) -> Bool
}

In Swift we use the term protocol for both Concept and Type Constraint, and this could be a source of confusion to many. Whereas, in C++ we don’t have any way to design Type Constraint, which helps when writing code, but when the code fails to compile for some reaons it might get hard to understand why.

First let us try to understand the relationship between a Model and a Type Constraint. Let’s say we have a Model named Student as:

struct Student: Equatable {
    let studentId: Int
}

func ==(lhs: Student, rhs: Student) -> Bool {
    return lhs.studentId == rhs.studentId
}

Here Student conforms to the Type Constraint. So any function that is designed to with types Equatable can work with Student. But, we have to keep in mind that the Student is not a Model of Concept named Equatable.

Next let us explore the relationship between a Model and a Concept. If we have a generic stack implementation:

class Stack<T> {
    private var store: [T] = []

    func push(item: T) {
        store.append(item)
    }

    func pop() -> T? {
        if store.isEmpty {
            return nil
        }
        return store.removeLast()
    }
}

What could be the core Concept of a stack? If we take a look at it, we might say a stack is a data structure where you push items and later on pop them back. So, we can say the Concept of stack can be written as:

protocol Stack {
    typealias Item
    func push(item: Item)
    func pop() -> Item?
}

Now, we can Model an Array backed stack on this Concept as:

class ArrayStack<T>: Stack {
    private var store: [T] = []

    func push(item: T) {
        store.append(item)
    }

    func pop() -> T? {
        if store.isEmpty {
            return nil
        }
        return store.removeLast()
    }
}

Or, we can go crazy and write a weird stack, where you pop data filtered by some epoch timestamp that we provide at runtime.

class TimeStack<T>: Stack {
    private var store: [CFTimeInterval: T] = [:]
    var epoch = CACurrentMediaTime()

    func push(item: T) {
        store[CACurrentMediaTime()] = item
    }

    func pop() -> T? {
        for (time, value) in store {
            if time < epoch {
                return value
            }
        }

        return nil
    }
}

Solution

With our basics now clear, we can take a look again at the original problem. What was wrong with our Animal example at the top?

The problem is with both the implementations.

In the Swift implementation, we’ve designed our Animal as a Type Constraint, as can be observed with the func greet<T: Animal>, but then later we are trying to use it as Concept by doing things like class Mammal: Animal. And this is what compiler is complaining about.

With our C++ implementation, as our dear clang compiler was trying to inform us, the Animal is actually a Concept, but we are trying to use it as Type Constraint by doing things like std::vector<Animal>.

And hence both the usages are invalid.

That’s all for today. We shall explore the other Generic Programming terminologies later someday.

Have a nice day!

Changing the gears to Generic Programming

2015-06-20T06:02:54+00:00

Practical usage of generic programming can be narrowed down to two forms:

Writing top level generic functions
Writing generic custom types

Generic Functions

Writing top level generic functions is easier. Its more of like you write a normal function and later on you realize that this function is not restricted to any type, rather it is just an abstract algorithm that can be used by many types, you upgrade it to generic type. For example,

bool isEqual(int x, int y) {
    return x == y;
}

can be easily abstracted out to a generic form such as

template <typename T>
bool isEqual(T x, T y) {
    return x == y;
}

This generic form would work as long as T supports a == operation. Which brings us to the term you will often find with generic programming, Type Constraints.

So, the above example would work fine with all types that support == operation. Such as:

std::cout << (isEqual(10, 10) ? "Y" : "N") << std::endl;
std::cout << (isEqual(10.5, 10.5) ? "Y" : "N") << std::endl;
std::cout << (isEqual("hello", "hello") ? "Y" : "N") << std::endl;

But would easily break down when used like:

struct Vector2 {
    float x, y;
    Vector2(float xx, float yy) : x(xx), y(yy) {}
};

std::cout << (isEqual(Vector2(10, 10), Vector2(10, 10)) ? "Y" : "N") << std::endl; // output compilation failure

And the reason being, that the Type Constraint has been violated. The type Vector2 does not provides an == operation. The fix is simple, satisfy the Type Constraint

bool operator == (const Vector2 &lhs, const Vector2 &rhs) {
    return (lhs.x == rhs.x) && (lhs.y == rhs.y);
}

Another type of error that could arise with generic functions is, where the constraints are not violated syntactically, by are logically broken. For example:

const char w1[] = "world";
const char w2[] = "world";
std::cout << (isEqual(w1, w2) ? "Y" : "N") << std::endl; // output N

Here, our isEqual() sees that the types are const char * and the compiler knows how to compare two pointers. But the result might or might not be what we were expecting. If you were expecting a string comparison, you’ve to tell the compiler how to do that.

For our specific case, it can be achieved by providing an overloaded implementation that just takes const char *

bool isEqual(const char *x, const char *y) {
    return strcmp(x, y) == 0;
}

Generic Types

The main power of generic programming lies when working with generic types. Just as generic functions abstract the algorithm to a type-free level, generic types abstract our design to type free level.

Think of generic types as if us providing the type information for the compiler, and passing the responsibility of creating the actual types to the compiler.

To get an quick overview, the Vector2 type that we wrote above for float types can easily be rewritten as a generic type

template <typename T>
struct Vector2 {
    T x, y;
    Vector2(T xx, T yy) : x(xx), y(yy) {}
};

And the == implementation should just fit with the change:

template <typename T>
bool operator == (const Vector2<T> &lhs, const Vector2<T> &rhs) {
    return (lhs.x == rhs.x) && (lhs.y == rhs.y);
}

Now, where should we actually use the generic types in real world? To address this question, you’ve to switch you mindset from run-time polymorphism to compile-time polymorphism. Let’s consider an example where you have designed your types in the classical object-oriented fashion, that is using inheritence

class Shape {
public:
    virtual ~Shape() {}
    void PrintArea() {
        std::cout << "area = " << Area() << std::endl;
    }

private:
    virtual float Area() const = 0;
};

class Rectangle: public Shape {
public:
    Rectangle(float w, float h) : width(w), height(h) {}

private:
    float Area() const {
        return width * height;
    }

    float width, height;
};

class Circle: public Shape {
public:
    Circle(float r) : radius(r) {}

private:
    float Area() const {
        return 3.14 * (radius * radius);
    }

    float radius;
};

int main() {
    Rectangle *r = new Rectangle(10, 20);
    Circle *c = new Circle(5);

    std::vector<Shape *> shapes;

    shapes.push_back(r);
    shapes.push_back(c);

    std::for_each(shapes.begin(), shapes.end(), [](Shape *s) {
        s->PrintArea();
    });

    delete r;
    delete c;

    return 0;
}

Here, we have a base Shape class that does provides the public interface and leaves the actual implementation details to the subclasses. In this case the actual calculation of the area. Internally, we’re calling the Area() function on Shape and let the run-time do the actual look-up for the implementation by looking at the type information.

In another words, what we are actually doing is that delegating some part of the implementation of our Shape class to subclasses. Another way of achieving the same results is by not depending on subclasses for overrides, but delegating the implementation to some external classes.

struct ShapeImpl {
    virtual float Area() const = 0;
};

class RectangleImpl: public ShapeImpl {
public:
    RectangleImpl(float w, float h) : width(w), height(h) {}

private:
    float Area() const {
        return width * height;
    }

    float width, height;
};

class CircleImpl: public ShapeImpl {
public:
    CircleImpl(float r) : radius(r) {}

private:
    float Area() const {
        return 3.14 * (radius * radius);
    }

    float radius;
};

class Shape {
public:
    Shape(const ShapeImpl *impl) : implementation(impl) {}

    void PrintArea() const {
        std::cout << "area = " << implementation->Area() << std::endl;
    }

private:
    const ShapeImpl *implementation;
};

int main() {
    RectangleImpl *r = new RectangleImpl(10, 20);
    CircleImpl *c = new CircleImpl(5);

    std::vector<Shape> shapes;

    shapes.push_back(Shape(r));
    shapes.push_back(Shape(c));

    std::for_each(shapes.begin(), shapes.end(), [](const Shape &s) {
        s.PrintArea();
    });

    delete r;
    delete c;

    return 0;
}

I don’t know if we’ve achieved any actual improvement over the earlier implementation with this or not. But, this gives you an idea that the implementation can be dragged out of the core class while keeping the visible interface of the Shape intact.

If we can achieve this, we can even go a step further and actually provide the implementation at compile time. In other words, we can simply make the Shape class generic, and let the compiler plug-in the implementation details at compile-time.

template <typename Impl>
class Shape {
public:
    Shape(const Impl impl) : implementation(impl) {}

    void PrintArea() const {
        std::cout << "area = " << implementation.Area() << std::endl;
    }

private:
    const Impl implementation;
};

Now, we can create and use our generic shape instances as:

    Shape<RectangleImpl> rect(RectangleImpl(10, 20));
    Shape<CircleImpl> circle(CircleImpl(5));

    rect.PrintArea();
    circle.PrintArea();

The only type constraints on the RectangleImpl and CircleImpl is that they need to have a Area() function.

class RectangleImpl {
public:
    RectangleImpl(float w, float h) : width(w), height(h) {}

    float Area() const {
        return width * height;
    }

private:
    float width, height;
};

class CircleImpl {
public:
    CircleImpl(float r) : radius(r) {}

    float Area() const {
        return 3.14 * (radius * radius);
    }

private:
    float radius;
};

The C++ compiler is smart enough to see the constraints are not violated by any new delegate class. For example if we introduce a TriangleImpl as:

class TriangleImpl {
public:
    TriangleImpl(float b, float h) : base(b), height(h) {}

private:
    float base, height;
};

Shape<TriangleImpl> triangle(TriangleImpl(10, 5));
triangle.PrintArea();

The compiler will immediately throw error messages, unless you fix your implementation by providing the Area() function.

class TriangleImpl {

public:
    TriangleImpl(float b, float h) : base(b), height(h) {}

    float Area() const {
        return 0.5 * base * height;
    }

private:
    float base, height;
};

Now, if you notice that we are not using an std::vector anymore, that is because we don’t have a Shape type anymore. And if you find yourself thinking in this direction, you need to get out of the run-time polymorphic mindset. When using compile-time polymorphism you’ve to keep in mind the fact that now you’re not in control of creating the custom types, rather you’ve passed on that authority to the compiler.

So, Shape<TriangleImpl> and Shape<CircleImpl> are entirely different types with no common ancestor or anything.

When designing with compile time polymorphism you need to keep in mind that your generic type should be a leaf node or a final class in the entire type system. You should not have to subclass your generic type, rather plug-in a delegate class that provides the implementation that you would rather provide by sub-classing.

To summarize, here’s a quick list of good and bad of generic type system:

Pro

Robust: No run time exceptions.
Efficient: No run time lookups

Cons

Not a good candidate for base class
Hard to read and debug.

Now, moving on to using generics with Swift. Swift provides the same good old C++ way of writing generic code with some extra type constraint system. Where in C++ the compiler would do the type constraint checking when you actually compile the code, Swift actually makes the constraint system more explicit, such that you have to provide the constraint information with a protocol.

protocol ShapeImplementable {
    var area: Double { get }
}

struct Shape<Impl: ShapeImplementable> {
    private let implementation: ShapeImplementable

    init(impl: ShapeImplementable) {
        implementation = impl
    }

    func printArea() {
        println("area = \(implementation.area)")
    }
}

And then you can implement your delegate class as

struct RectangleImpl: ShapeImplementable {
    var area: Double {
        return width * height
    }

    init(w: Double, h: Double) {
        width = w
        height = h
    }

    private let width: Double
    private let height: Double
}

And finally use them the same way you would with C++.

let rect = Shape<RectangleImpl>(impl: RectangleImpl(w: 10, h: 20))

The entire code for this article is also available at github.com/chunkyguy/GenericsDemo

Goodbye and have a nice day!

Subclassing UILabel in 2015

2015-05-16T06:23:54+00:00

UILabel is one the most smart view in UIKit family. It knows a lot about itself. If you constraint it to a certain width, the UILabel can calculate the height for itself. Another smart thing about UILabel is that is saves you machine cycles by not redrawing its content unless something is actually modified. And if you use NSAttributedString, you can in fact draw a more sophisticated text content.

Given so many good things with a UILabel, it is very tempting to subclass a UILabel to render our custom text content. Say if you’re working on a game or app, say a chat messenger, you may like to have a view where you render you text and have some decorations around it, like a speech bubble with an optional image. And, if you’ve ever worked on such a task, you know how painful it actually is!.

A UILabel is the perfect fit whenever you’ve a need to render some text on screen. Recently had to undergo such a job of subclassing UILabel, and it surprisingly hard to find a good source of information that shows how to properly subclass UILabel. It might work for the text data you have right now, but there are so many screen sizes and edge cases possible. If you’re one of those person, I don’t want you to discover this knowledge the hard way like I did, I’ll share the knowledge I’ve acquired from my adventure.

Even if you’re not directly using UILabel but rendering your content on an OpenGL canvas using Freetype library or something, the knowledge of how UILabel works should be really helpful in designing your own view. But, you can take my word for it, that rendering text is one of the most challenging things in the UI problem domains. You have to render all sort of glyphs, in all sort of writing directions with a lot of kerning, ligatures and other text attributes. If you’re one of those adventure seeker, you should definitely try building your own text rendering system. Just for the inspiration, these are from the days when I was building one:

Fixing font rendering the long way pic.twitter.com/hJtCBKLqBN
— Sidharth Juyal (@chunkyguy) June 26, 2013

One day work = FreeType font rendering pic.twitter.com/FJMrcPPu
— Sidharth Juyal (@chunkyguy) February 6, 2013

Someday, I should probably also share my experiences with building a UILabel-like view from scratch, I mean on top of freetype. But, today we just extend over the work UILabel already does for us. Let’s begin with creating a new project.

We simply create a new project with a single view and add a RoundedRectLabel class. Next, we write our basic code to render the label on screen.

class RoundedRectLabel: UILabel {
}

class ViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .lightGrayColor()
        let chatBubbleLabel = RoundedRectLabel()
        chatBubbleLabel.text = "No one expects the Spanish Inquisition! Our chief weapon is surprise. Fear and surprise. Two chief weapons, fear, surprise, and ruthless efficiency! Er, among our chief weapons are: fear, surprise, ruthless efficiency, and near fanatical devotion to the Pope! Um, I'll come in again."
        chatBubbleLabel.textColor = .blackColor()
        chatBubbleLabel.backgroundColor = .cyanColor()
        chatBubbleLabel.numberOfLines = 0
        chatBubbleLabel.textAlignment = .Justified
        view.addSubview(chatBubbleLabel)
        chatBubbleLabel.setTranslatesAutoresizingMaskIntoConstraints(false)
        view.addConstraint(NSLayoutConstraint(item: chatBubbleLabel, attribute: .CenterY, relatedBy: .Equal, toItem: view, attribute: .CenterY, multiplier: 1.0, constant: 0.0))
        view.addConstraints(NSLayoutConstraint.constraintsWithVisualFormat("H:|-[chatBubbleLabel]-|", options: NSLayoutFormatOptions(0), metrics: nil, views: ["chatBubbleLabel": chatBubbleLabel]))
    }

    override func prefersStatusBarHidden() -> Bool {
        return true
    }
}

Now the two important methods to subclass within a UILabel are:

func textRectForBounds(bounds: CGRect, limitedToNumberOfLines numberOfLines: Int) -> CGRect
func drawTextInRect(rect: CGRect)

The textRectForBounds(_:limitedToNumberOfLines:) provides us an opportunity to update the drawing area of the text within the UILabel. And the drawTextInRect() is for you to do you custom drawing within the view.

If you notice, this is a little different than your usual UIView subclassing, where you typically draw you content in drawRect(). Another thing to keep in mind is that you typically also don’t want to modify the intrinsicContentSize(). Overriding these two methods will do whatever you want to do with you custom UILabel.

For sake of getting a deeper understanding, let’s print out the order of execution.

class RoundedRectLabel: UILabel {
   override func textRectForBounds(bounds: CGRect, limitedToNumberOfLines numberOfLines: Int) -> CGRect {
        let textRect = super.textRectForBounds(bounds, limitedToNumberOfLines: numberOfLines)
        println("\(__FUNCTION__): \(textRect)")
        return textRect
    }

    override func drawTextInRect(rect: CGRect) {
        super.drawTextInRect(rect)
        println("\(__FUNCTION__): \(rect)")
    }

    override func intrinsicContentSize() -> CGSize {
        let size = super.intrinsicContentSize()
        println("\(__FUNCTION__): \(size)")
        return size
    }
}

Here’s the output:

textRectForBounds(_:limitedToNumberOfLines:): (0.0, 0.0, 2122.5, 20.5)
intrinsicContentSize(): (2122.5, 20.5)
textRectForBounds(_:limitedToNumberOfLines:): (0.0, 0.0, 342.5, 142.0)
intrinsicContentSize(): (342.5, 142.0)
drawTextInRect: (0.0, 0.0, 343.0, 142.0)

The interesting thing to notice here is that whatever is calculated from the super.textRectForBounds(_:limitedToNumberOfLines:) is also passed on to the intrinsicContentSize(). Another interesting thing is that, the methods are called multiple times. First time with some estimated values by UIKit and second time after the values have been evaluated accurately enough.

Not implementing the intrinsicContentSize() also means that, you don’t need to invalidateIntrinsicContentSize() yourself. Since, the default drawing mode of UILabel is UIViewContentMode.Redraw, the content is redrawn automatically whenever the content updates. To confirm, if you update the text after a while, you can see the drawing methods being invoked again.

class ViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .lightGrayColor()
        let chatBubbleLabel = RoundedRectLabel()
        chatBubbleLabel.text = "No one expects the Spanish Inquisition! Our chief weapon is surprise. Fear and surprise. Two chief weapons, fear, surprise, and ruthless efficiency! Er, among our chief weapons are: fear, surprise, ruthless efficiency, and near fanatical devotion to the Pope! Um, I'll come in again."
        chatBubbleLabel.textColor = .blackColor()
        chatBubbleLabel.backgroundColor = .cyanColor()
        chatBubbleLabel.numberOfLines = 0
        chatBubbleLabel.textAlignment = .Justified
        view.addSubview(chatBubbleLabel)

        chatBubbleLabel.setTranslatesAutoresizingMaskIntoConstraints(false)
        view.addConstraint(NSLayoutConstraint(item: chatBubbleLabel, attribute: .CenterY, relatedBy: .Equal, toItem: view, attribute: .CenterY, multiplier: 1.0, constant: 0.0))
        view.addConstraints(NSLayoutConstraint.constraintsWithVisualFormat("H:|-[chatBubbleLabel]-|", options: NSLayoutFormatOptions(0), metrics: nil, views: ["chatBubbleLabel": chatBubbleLabel]))

        dispatch_after(dispatch_time(DISPATCH_TIME_NOW, Int64(NSEC_PER_SEC * 3)), dispatch_get_main_queue()) { () -> Void in
            println("---------")
            chatBubbleLabel.text = "All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, the fresh-water system, and public health, what have the Romans ever done for us?"
        }
    }

    override func prefersStatusBarHidden() -> Bool {
        return true
    }
}

Output:

textRectForBounds(_:limitedToNumberOfLines:): (0.0, 0.0, 2122.5, 20.5)
intrinsicContentSize(): (2122.5, 20.5)
textRectForBounds(_:limitedToNumberOfLines:): (0.0, 0.0, 342.5, 142.0)
intrinsicContentSize(): (342.5, 142.0)
drawTextInRect: (0.0, 0.0, 343.0, 142.0)
---------
textRectForBounds(_:limitedToNumberOfLines:): (0.0, 0.0, 1403.0, 20.5)
intrinsicContentSize(): (1403.0, 20.5)
textRectForBounds(_:limitedToNumberOfLines:): (0.0, 0.0, 323.5, 101.5)
intrinsicContentSize(): (323.5, 101.5)
drawTextInRect: (0.0, 0.0, 343.0, 101.5)

This is good, because it means if you’re subclassing a UILabel, you need to focus on just these two methods and the UILabel will take care of the rest. So, lets focus first on the drawTextInRect().

The first thing is to calculate the edge insets or padding you wish to give your label.

let edgeInsets = UIEdgeInsets(top: 10, left: 20, bottom: 10, right: 20)

override func drawTextInRect(rect: CGRect) {
    let textRect = UIEdgeInsetsInsetRect(rect, edgeInsets)
    super.drawTextInRect(textRect)
}

As you can see, we’ve the required padding from all edges as we wanted, but the text is truncated at the end. This is because the UILabel currently is trying to draw the text within the original frame it had calculated. So the next task is to provide the new drawing frame to UILabel. This is done within textRectForBounds(_:limitedToNumberOfLines:). The important question is how do we calculate what frame size do we need to draw the entire text content?

The NSString has a handy extension that does this calculations. The method we’re particularly interested in is

func boundingRectWithSize(size: CGSize, options: NSStringDrawingOptions, attributes: [NSObject : AnyObject]!, context: NSStringDrawingContext!) -> CGRect

We just need to provide this method our estimated size of drawing area and other rendering attributes, and it will return the actual frame we need to render this text. This brings us to the part II of the problem: How do we calculate the estimated size of the drawing area?

Let’s see, we know the width that we wish to draw in.

let estimatedWidth = CGRectGetWidth(textRect) - (edgeInsets.left + edgeInsets.right)

But, UILabel passes the same original width to textRectForBounds(_:limitedToNumberOfLines:) and drawTextInRect(). So, this means if the original width of the UILabel is 100 pts and we wish to have a padding of 10 pts from all edges. If NSString API calculates the required height for width = 80, is lets say it’s 200. The size passed down to drawTextInRect() is 100×200, where we again shrink the size down to 80×180. In order to compensate for this second clipping, we must calculate the height for an 2 times smaller width.

let estimatedWidth = CGRectGetWidth(rect) - (2 * (edgeInsets.left + edgeInsets.right))

But what about the height? Don’t worry, this is just an estimated height, we can provide a very high value, and hope for the best.

let estimatedWidth = CGRectGetWidth(rect) - (2 * (edgeInsets.left + edgeInsets.right))
let estimatedHeight = CGFloat.max
let calculatedFrame = NSString(string: text).boundingRectWithSize(CGSize(width: estimatedWidth, height: estimatedHeight), options: .UsesLineFragmentOrigin, attributes: [NSFontAttributeName: font], context: nil)

Next, remember, the boundingRectWithSize(...) will try to wrap our text in as less space as possible, because that is the default behavior. So, we need to explicitly provide the extra top and bottom padding to the size calculated.

let calculatedWidth = ceil(CGRectGetWidth(calculatedFrame))
let calculatedHeight = ceil(CGRectGetHeight(calculatedFrame))
let finalHeight = (calculatedHeight + edgeInsets.top + edgeInsets.bottom)
rect.size = CGSize(width: calculatedWidth, height: finalHeight)

The ceil() should raise fractional mathematical value to a renderable screen value. The entire code is below.

class RoundedRectLabel: UILabel {
    let edgeInsets = UIEdgeInsets(top: 10, left: 20, bottom: 10, right: 20)

    override func textRectForBounds(bounds: CGRect, limitedToNumberOfLines numberOfLines: Int) -> CGRect {
        var rect = super.textRectForBounds(bounds, limitedToNumberOfLines: numberOfLines)
        if let text = text {
            let estimatedWidth = CGRectGetWidth(rect) - (2 * (edgeInsets.left + edgeInsets.right))
            let estimatedHeight = CGFloat.max
            let calculatedFrame = NSString(string: text).boundingRectWithSize(CGSize(width: estimatedWidth, height: estimatedHeight), options: .UsesLineFragmentOrigin, attributes: [NSFontAttributeName: font], context: nil)
            let calculatedWidth = ceil(CGRectGetWidth(calculatedFrame))
            let calculatedHeight = ceil(CGRectGetHeight(calculatedFrame))
            let finalHeight = (calculatedHeight + edgeInsets.top + edgeInsets.bottom)
            rect.size = CGSize(width: calculatedWidth, height: finalHeight)
        }

        return rect
    }

    override func drawTextInRect(rect: CGRect) {
        let textRect = UIEdgeInsetsInsetRect(rect, edgeInsets)
        super.drawTextInRect(textRect)
    }
}

To finish it off, we just need some custom drawing code. Feel free to draw whatever you like.

override func drawTextInRect(rect: CGRect) {
    UIColor.cyanColor().setFill()
    UIColor.blackColor().setStroke()

    let edgePath = UIBezierPath(roundedRect: rect, cornerRadius: 50)
    edgePath.lineWidth = 5.0
    edgePath.lineJoinStyle = kCGLineJoinRound
    edgePath.fill()
    edgePath.stroke()

    let textRect = UIEdgeInsetsInsetRect(rect, edgeInsets)
    super.drawTextInRect(textRect)
}

The entire code is also available at github.

Curious case of Generics Specialization with Swift

2015-01-20T06:24:54+00:00

Today, I want to talk about a curious case I discovered while playing with generic programming with Swift.

To illustrate, let’s start by writing a simple function.

func Min(x:Int, y:Int) -> Int {
    println("Using Min<Int>")
    return (x < y) ? x : y
}

let a = Min(-1, 1) // Using Min<Int>

And now let’s make it generic.

func Min<T:Comparable>(x:T, y:T) -> T {
    println("Using Min<T>")
    return (x < y) ? x : y
}

let a = Min(-1, 1) // Using Min<T>

What if we’ve both the implementations? The compiler automatically picks the specialized version.

func Min<T:Comparable>(x:T, y:T) -> T {
    println("Using Min<T>")
    return (x < y) ? x : y
}

func Min(x:Int, y:Int) -> Int {
    println("Using Min<Int>")
    return (x < y) ? x : y
}

let a = Min(-1, 1) // Using Min<Int>

The swift standard library already provides a min and max functions.

func min<T : Comparable>(x: T, y: T) -> T

Suppose we use that as the generic version and override our specialized one for Int? The compiler still picks the specialized one.

func min(x:Int, y:Int) -> Int {
    println("Using Min<Int>")
    return (x < y) ? x : y
}

let a = min(-1, 1) // Using min<Int>

This is really convenient, isn’t it? Let’s expand our example to something you might face in real life. Let’s work with a Vector2 type.

struct Vector2 {
    var x : Float = 0.0
    var y : Float = 0.0

    init(x:Float = 0,y:Float = 0) {
        self.x = x
        self.y = y
    }
}

How about making use of standard min and max functions with Vector2?

let lowerBound = Vector2(x: -1, y: -1)
let upperBound = Vector2(x: 1, y: 1)

let a = min(lowerBound, upperBound)

This is going to throw an error, as the standard min and max functions need the type to conform to the comparable protocol. So let’s do that first.

func ==(lhs: Vector2, rhs: Vector2) -> Bool {
   return (lhs.x == rhs.x) && (lhs.y == rhs.y)
}

func < (lhs: Vector2, rhs: Vector2) -> Bool {
    return (lhs.x < rhs.x) && (lhs.y < rhs.y)
}

extension Vector2 : Comparable {}

let lowerBound = Vector2(x: -1, y: -1)
let upperBound = Vector2(x: 1, y: 1)

let a = min(lowerBound, upperBound)

This works as expected. This is a great feature, in my opinion, one of the best things to switch from Objective-C to Swift. Moving forward, let’s write a generic clamp function.

func clamp<T:Comparable>(value:T, lowerBound:T, upperBound:T) -> T {
    return min(max(lowerBound, value), upperBound)
}

let b = clamp(10, -1, 1) // prints 1

This is awesome! Let’s try our clamp function with Vector2.

let lowerBound = Vector2(x: -100, y: -100)
let upperBound = Vector2(x: 100, y: 100)

let test1 = clamp(Vector2(x: 200, y: 200), lowerBound, upperBound) // {x:100, y:100}
let test2 = clamp(Vector2(x: -200, y: -200), lowerBound, upperBound) // {x:-100, y:-100}
let test3 = clamp(Vector2(x: -10, y: -134), lowerBound, upperBound) // {x:-10, y:-134}
let test4 = clamp(Vector2(x: 10, y: 134), lowerBound, upperBound) // {x:10, y:134}

At first this might look bad, because the test3 and test4 are not correct. But, this is not the compiler’s fault. The standard min and max use the overloaded comparison operators and they are not correct. We can test this with

let test5 = min(Vector2(x: -10, y: -134), lowerBound) // {x:-10, y:-134}
let test6 = max(Vector2(x: 10, y: 134), upperBound) // {x:10, y:134}

Let’s fix them by providing our own specialized versions.

func min(lhs: Vector2, rhs: Vector2) -> Vector2 {
    return Vector2(x: min(lhs.x, rhs.x), y: min(lhs.y, rhs.y))
}

func max(lhs: Vector2, rhs: Vector2) -> Vector2 {
    return Vector2(x: max(lhs.x, rhs.x), y: max(lhs.y, rhs.y))
}

let test5 = min(Vector2(x: -10, y: -134), lowerBound) // {x:-100, y:-134}
let test6 = max(Vector2(x: 10, y: 134), upperBound) // {x:100, y:134}

This looks better in the sense that the min and max is calculated per component. But, something is still wrong with our clamp tests, as they still print the same old value. Turns out the min and max within clamp function still use the standard generic function, rather than our provided specialized version.

The only way to make this work is if I provide a specialized clamp function for Vector2.

func clamp(value:Vector2, lowerBound:Vector2, upperBound:Vector2) -> Vector2 {
    return min(max(lowerBound, value), upperBound)
}

let test1 = clamp(Vector2(x: 200, y: 200), lowerBound, upperBound) // {x:100, y:100}
let test2 = clamp(Vector2(x: -200, y: -200), lowerBound, upperBound) // {x:-100, y:-100}
let test3 = clamp(Vector2(x: -10, y: -134), lowerBound, upperBound) // {x:-10, y:-100}
let test4 = clamp(Vector2(x: 10, y: 134), lowerBound, upperBound) // {x:10, y:100}

Note that the specialized clamp implementation for Vector2 is exactly the same as the generic one. And this is not good, as now if we want the compiler to automatically pick the right version, we have to implement the entire chain down to every function. So, it comes down to either using the generic functions all the way up or implementing the entire chain.

To compare, here’s a C++ version of the same functionality that works great with a single clamp generic implementation.

#include <iostream>

struct Vector2 {
    float x;
    float y;

    Vector2(float x = 0, float y = 0) {
        this->x = x;
        this->y = y;
    }
};

template <typename T>
T min(T a, T b) {
    return a < b ? a : b;
}

template <>
Vector2 min(Vector2 a, Vector2 b) {
    return Vector2(min(a.x, b.x), min(a.y, b.y));
}

template <typename T>
T max(T a, T b) {
    return a > b ? a : b;
}

template <>
Vector2 max(Vector2 a, Vector2 b) {
    return Vector2(max(a.x, b.x), max(a.y, b.y));
}

template <typename T>
T clamp(T value, T lowerBound, T upperBound) {
    return min(max(lowerBound, value), upperBound);
}

std::ostream &operator<<(std::ostream &os, const Vector2 &v) {
    os << v.x << ", " << v.y;
    return os;
}

int main() {
    Vector2 lowerBound(-100, -100);
    Vector2 upperBound(100, 100);

    std::cout << clamp(Vector2(200, 200), lowerBound, upperBound) << std::endl;
    std::cout <<  clamp(Vector2(-200, -200), lowerBound, upperBound) << std::endl;
    std::cout << clamp(Vector2(-10, -134), lowerBound, upperBound) << std::endl;
    std::cout <<  clamp(Vector2(10, 134), lowerBound, upperBound) << std::endl;

    std::cout <<  min(Vector2(-10, -134), lowerBound) << std::endl;
    std::cout <<  max(Vector2(10, 134), upperBound) << std::endl;
}

In conclusion, generic programming with Swift is great and definitely a step forward than Objective-C, but somebody coming from C++ would be a little disappointed. The bright side is that the Swift language is rapidly evolving and maybe this would get improved in the future version.

The entire code for this rant is available at C++ and Swift.

Concurrency: Atomics

2014-11-01T05:58:54+00:00

I think we have covered most of the core concurrency concepts. With the current knowledge we are good enough to tackle all real world concurrency related problems. But this doesn’t means that we’ve covered everything the thread libraries have to offer. And by thread libraries I mean just the C++ standard thread library and libdispatch. For example, we’re yet to see std::future, std::promise, std::packaged_task, dispatch_barier, dispatch_source in action.

Today let’s focus on the low level of the libraries, atomics. Atomics are the lowest level that we can work with a thread library. Atomic operations provide the lowest level guarantee of ordering of operations. An operation is atomic if there is a guarantee that the operation would be never be left by any thread in an indeterminate state.

To make sure that the operation is atomic, internally the runtime could be either not switch the thread while an atomic operation is underway or maybe it simply uses a lock or whatever innovation the technology has to offer. As a user of the library, you just get the guarantee that atomic operation are indivisible.

To facilitate atomicity the C++ standard library offers a few atomic types. All the types offer a is_lock_free() function to test if the operation is done really not using any locks. Only exception is std::atomic_flag which is the always lock free.

Atomic Types

C++ provides a lot of atomic types. You can say that for almost all the fundamental types have an atomic equivalent. (And by fundamental types I mean bool and integers, no floating points, as you’ll see in a moment why). You can use them directly or as std::atomic<> template specialization. Here’s an example

std::atomic_bool b1;
std::atomic<bool> b2;

This same pattern is applied to all other fundamental types. Although, you can use them as your usual fundamental types, there are few operations that are not allowed. First striking constraint disallowed is copy and assign operation. This code won’t compile

void TryCopy()
{
    std::atomic<bool> b1(false);
    std::atomic<bool> b2 = b1;
}

Then how do we use these atomic types? This brings us to load() and store() operations. All atomic types except atomic_flag offer load(), store(), exchange(), compare_exchange_weak() and compare_exchange_strong() operations. Let’s take a look at what do they do.

load and store

If you’ve ever done a bit of assembly, you must be familiar with load and store operations. Load retrieves the data while store saves the data.

void DoLoad()
{
    std::atomic<int> i(10);
    std::atomic<int> j(i.load());
    std::cout << j << std::endl; // prints 10
}

void DoStore(const int n)
{
    std::atomic<int> i(0);
    i.store(n);
    std::cout << i << std::endl; // prints whatever n is
}

exchange

Apart from the basic load and store, you also get a bunch of exchange operations. An exchange operation does exactly what you’d expect, store a new value and return the old value.

void DoExchange(const int n)
{
    std::atomic<int> i(50);
    int j = i.exchange(n);
    std::cout << i << " " << j << std::endl; // j = i; i = n;
}

An exchange operation is basically a 3 step operation. First it loads the data, second it updates the data with new data, and third it stores the new data back. And this should explain why floating points are left out from fundamental types. Floating point types are not deterministic at comparison.

And since we’re dealing with the lowest level of concurrency operations. Sometimes you want a greater control over the execution. Maybe you need a stronger guarantee that the 3 step exchange was indeed done successfully before the running thread’s just ran out of time.

For such grained control the C++ standard library offers two more exchange operations. compare_exchange_weak() and compare_exchange_strong().

The compare_exchange_weak() returns false, if the exchange wasn’t successful. This could be because if the running thread’s time just ran out and was kicked out by the scheduler before it could finish the steps. This is called as spurious failure.

void DoExchangeWeak(const int desired)
{
    int expected = 50;
    std::atomic<int> i(expected);
    bool success = i.compare_exchange_weak(expected, desired);
    std::cout << std::boolalpha << success << " " << desired << " "
                << i << " " << expected << std::endl; // true 100 100 50
}

So if you want the exchange to run successfully every time, you probably need to put this operation under a loop. So that whenever the operation fails, you keep trying until it succeeds.

while (i.compare_exchange_weak(expected, desired) != true) {
}

Or, you can simply use compare_exchange_strong() which is guaranteed to eliminate all spurious failures.

bool success = i.compare_exchange_strong(expected, desired);

Both of these functions return false whenever the expected value is not same as the stored value. That is, whenever the comparison fails, and in that case the expected updates to whatever was the actual value. For example:

void DoExchangeWeak(const int desired)
{
    int expected = 0;
    std::atomic<int> i(5);
    bool success = i.compare_exchange_weak(expected, desired);
    std::cout << std::boolalpha << success << " "
    << desired << " " << i << " " << expected << std::endl;
    // false 1 5 5
}

For all fundamental types that support +=, -+, |=, &=, and ^=, the atomic types have equivalent fetch_add, fetch_sub, fetch_or, fetch_and, fetch_xor operation available.

void DoFetchAdd(const int n)
{
    std::atomic<int> i(100);
    int j = i.fetch_add(n);
    std::cout << i << " " << j << std::endl;
    //for n = 50; output: 150, 100 => j = i; i += n;
}

Finally, if you want your custom type to work as an atomic type, you can do that guaranteed that your custom type don’t do anything fancy. What that means in practical world is that your type should work with memcpy() and memcmp(). That is plain C types, no virtual table lookups. Here’s trivial example:

struct MyType {
    int a;
    int b;
};

std::ostream &operator<<(std::ostream &os, const MyType &t)
{
    os << "{" << t.a << ", " << t.b << "}";
    return os;
}

void DoCustomExchange()
{
    std::atomic<MyType> a;
    a.store({10, 20});

    MyType b = {11, 21};
    MyType c = a.exchange(b);

    std::cout << "a: " << a << std::endl; // a: {11, 21}
    std::cout << "b: " << b << std::endl; // b: {11, 21}
    std::cout << "c: " << c << std::endl; // c: {10, 20}
}

There’s big part dealing with memory ordering that we’ve simply skipped for now, but we shall come back to it later. Let’s now focus on the most important atomic type atomic_flag.

atomic_flag

Forget whatever that has been said about atomic types so far. None of that applies to std::atomic_flag. std::atomic_flag is different. You can say that std::atomic_flag is the core of the threading library. Its like the atom of the universe. Let’s start exploring std::atomic_flag.

Let’s consider scenario. On your social network you get a lot of LOL text that you just can’t understand. So, you decide to write a program to convert that text either into a full uppercase or full lower case.

class UnLOLText {

public:
    UnLOLText(const std::string &name) :
    username_(name),
    modify_(0)
    {
        srand((unsigned int)time(0));
    }

    void ToUpper()
    {
        while (modify_ < username_.size()) {
            username_[modify_] = toupper(username_[modify_]);
            modify_++;
        }
    }

    void ToLower()
    {
        while (modify_ < username_.size()) {
            username_[modify_] = tolower(username_[modify_]);
            modify_++;
        }
    }

    void Reset()
    {
        modify_ = 0;
    }

    friend std::ostream &operator<<(std::ostream &os, const UnLOLText &txt);

private:
    std::size_t modify_;
    std::string username_;
};

std::ostream &operator<<(std::ostream &os, const UnLOLText &txt)
{
    os << txt.username_;
    return os;
}

void Scene1()
{
    UnLOLText txt("hEy How aRe yoU dOinG!");
    txt.ToUpper();
    std::cout << "Serial upper: " << txt << std::endl;
    txt.Reset();
    txt.ToLower();
    std::cout << "Serial lower: " << txt << std::endl;
    txt.Reset();

}

Output:

Serial upper: HEY HOW ARE YOU DOING!
Serial lower: hey how are you doing!

The amount of such LOL text you receive is huge. So obviously you want to unLOL the the text concurrently.

class UnLOLText {
public:
    UnLOLText(const std::string &name) :
    username_(name),
    modify_(0),
    flag(ATOMIC_FLAG_INIT)
    {
        srand((unsigned int)time(0));
    }

    void ToUpper()
    {
        while(flag.test_and_set(std::memory_order_seq_cst)) {
        }

        while (modify_ < username_.size()) {
            username_[modify_] = toupper(username_[modify_]);
            modify_++;
            thread_sleep();
        }
        flag.clear(std::memory_order_release);
    }

    void ToLower()
    {
        while(flag.test_and_set(std::memory_order_seq_cst)) {
        }

        while (modify_ < username_.size()) {
            username_[modify_] = tolower(username_[modify_]);
            modify_++;
            thread_sleep();
        }
        flag.clear(std::memory_order_release);
    }

    void Reset()
    {
        modify_ = 0;
    }

    friend std::ostream &operator<<(std::ostream &os, const UnLOLText &txt);

private:
    void thread_sleep()
    {
        std::this_thread::sleep_for(std::chrono::microseconds(rand()%5+1));
    }

    size_t modify_;
    std::string username_;
    std::atomic_flag flag;
};

void Scene2()
{
    UnLOLText txt("hEy How aRe yoU dOinG!");

    std::thread tab1(&UnLOLText::ToUpper, &txt);
    std::thread tab2(&UnLOLText::ToLower, &txt);

    tab1.join();
    tab2.join();

    std::cout << "Concurrent random: " << txt << std::endl;

    txt.Reset();
}

Using the std::atomic_flag you can set the flag as soon as one of the threads select a routine and then clear it only after the entire modification is done. So, using std::atomic_flag you’re randomly selecting a thread and blocking all the rest.

This almost sounds like what std::mutex does right? In fact, using std::atomic_flag you can implement your own mutex object.

class CustomMutex {
public:
    CustomMutex() :
    flag(ATOMIC_FLAG_INIT)
    {}

    void lock()
    {
        while(flag.test_and_set(std::memory_order_seq_cst)) {
        }
    }

    void unlock()
    {
        flag.clear(std::memory_order_release);
    }

private:
    std::atomic_flag flag;
};

class UnLOLText {
public:
    UnLOLText(const std::string &name) :
    username_(name),
    modify_(0)
    {
        srand((unsigned int)time(0));
    }

    void ToUpper()
    {
        mutex_.lock();

        while (modify_ < username_.size()) {
            username_[modify_] = toupper(username_[modify_]);
            modify_++;
            thread_sleep();
        }

        mutex_.unlock();
    }

    void ToLower()
    {
        mutex_.lock();

        while (modify_ < username_.size()) {
            username_[modify_] = tolower(username_[modify_]);
            modify_++;
            thread_sleep();
        }

        mutex_.unlock();
    }

    void Reset()
    {
        modify_ = 0;
    }

    friend std::ostream &operator<<(std::ostream &os, const UnLOLText &txt);

private:

    void thread_sleep()
    {
        std::this_thread::sleep_for(std::chrono::microseconds(rand()%5+1));
    }

    size_t modify_;
    std::string username_;
    CustomMutex mutex_;
};

And since you’re so far, you can even just reap the benefits of std::lock_guard for locking and unlocking the mutex for you. Remember, std::lock_guard is based on RAII principles, so you get a exception-safe guarantee that no matter what the rest of the code does (except deadlock) your mutex will get unlocked.

class UnLOLText {
public:

    UnLOLText(const std::string &name) :
    username_(name),
    modify_(0)
    {
        srand((unsigned int)time(0));
    }

    void ToUpper()
    {
        std::lock_guard<CustomMutex> lock(mutex_);
        while (modify_ < username_.size()) {
            username_[modify_] = toupper(username_[modify_]);
            modify_++;
            thread_sleep();
        }
    }

    void ToLower()
    {
        std::lock_guard<CustomMutex> lock(mutex_);
        while (modify_ < username_.size()) {
            username_[modify_] = tolower(username_[modify_]);
            modify_++;
            thread_sleep();
        }
    }

    void Reset()
    {
        modify_ = 0;
    }

    friend std::ostream &operator<<(std::ostream &os, const UnLOLText &txt);

private:
    void thread_sleep()
    {
        std::this_thread::sleep_for(std::chrono::microseconds(rand()%5+1));
    }

    size_t modify_;
    std::string username_;
    CustomMutex mutex_;
};

Big deal, right? We just reinvented something that is already provided by the C++ standard library. And I guarantee they’ve a better implementation of the mutex. So, what can we extra out of working at such low level?

With std::atomic_flag you must’ve noticed we use std::memory_order_seq_cst and std::memory_order_release, what are they? They specify the memory ordering of operations. Let take the red pill and follow down the memory ordering hole.

Memory ordering

This is probably the weirdest topic you’ll encounter as a programmer, as this will put some doubts over your knowledge of how you thought instructions execute at the lower level.

First lets take a look at all types of memory orderings possible. Memory orderings are classified for 3 major classes of operations

Store : seq_cst, release and relaxed
Load : seq_cst, acquire, consume and relaxed
Exchange : seq_cst, acq_rel, acquire, release, consume, relaxed

If we think in terms of different memory models available, we can classify these operations as:

Default : seq_cst
Unordered : relaxed
Lock based : acquire, consume, release and acq_rel

You’re already familiar with sequentially consistent (seq_cst) for this is what you’ve been doing all your life. You see a piece of code and you follows through the lines of code top to bottom, because that’s how the execution works, right? Let’s see.

Let’s say there’s new trend that every awesome software company is following. They have placed a coffee machine and a fedora hat machine at the entrance lobby. And they require every employee to have a fedora hat on their heads or a cup of coffee in their hands to enter the office. They certainly like whe the employee gets both the items. According to a survey this allegedly increases the hip level of the employee and brings more energy and productivity in the office. Say each of these items increment the employee’s hip level by 1.

So company A tries to implement this with the default memory model. They noticed that some employees prefer wearing the hat first and then holding the coffee, while other hold the coffee first and then wear the hat. So they have two security systems, one that waits until employee wears a hat and then it checks if the employee also has a coffee. The second one does completely opposite, it first waits for the employee to hold the coffee and then checks if the employee also has a hat on. After both the security systems have reported back, the doors decides whether to grant entry or not.

namespace defult {
    std::atomic<bool> hasHat;
    std::atomic<bool> hasCoffee;
    std::atomic<int> hipLevel;
    
    void WearHat()
    {
        std::this_thread::sleep_for(std::chrono::seconds(rand()%3+1));
        hasHat.store(true, std::memory_order_seq_cst);
    }

    void HoldCoffee()
    {
        std::this_thread::sleep_for(std::chrono::seconds(rand()%3+1));
        hasCoffee.store(true, std::memory_order_seq_cst);
    }

    void CheckHatAndCoffee()
    {
        while (!hasHat.load(std::memory_order_seq_cst)) {
            /* wait till employee gets a hat */
        }

        if (hasCoffee.load(std::memory_order_seq_cst)) {
            hipLevel++;
        }
    }

    void CheckCoffeeAndHat()
    {
        while (!hasCoffee.load(std::memory_order_seq_cst)) {
            /* wait till employee gets a coffee */
        }

        if (hasHat.load(std::memory_order_seq_cst)) {
            hipLevel++;
        }
    }

    void EmployeeEnter()
    {
        hasHat = false;
        hasCoffee = false;
        hipLevel = 0;

        std::thread a(WearHat);
        std::thread b(HoldCoffee);
        std::thread c(CheckHatAndCoffee);
        std::thread d(CheckCoffeeAndHat);

        a.join();
        b.join();
        c.join();
        d.join();

        if (hipLevel == 0) {
            std::cout << "Entry denied" << std::endl;
        } else {
            std::cout << "Entry granted with hip level: " << hipLevel << std::endl;
        }
    }
}

If you follow the code, you’ll notice that there is no way an employee can be denied an entry. No matter how long an employee takes to get a coffee or a hat, as soon as he does one thing the observing security personnel will check the other item, if they have it good, otherwise whenever they get the other item the second security will activate and this time employee will definitely pass the test, as they already have the first item.

Company B follows the unordered memory model.

namespace unordered {
    std::atomic<bool> hasHat;
    std::atomic<bool> hasCoffee;
    std::atomic<int> hipLevel;

    void GetThings()
    {
        hasHat.store(true, std::memory_order_relaxed);
        hasCoffee.store(true, std::memory_order_relaxed);
    }

    void CheckCoffeeAndHat()
    {
        while (!hasCoffee.load(std::memory_order_relaxed)) {
            /* wait till employee gets a coffee */
        }

        if (hasHat.load(std::memory_order_relaxed)) {
            hipLevel++;
        }
    }

    void EmployeeEnter()
    {
        hasHat = false;
        hasCoffee = false;
        hipLevel = 0;

        std::thread a(GetThings);
        std::thread b(CheckCoffeeAndHat);

        a.join();
        b.join();

        if (hipLevel == 0) {
            std::cout << "Entry denied" << std::endl;
        } else {
            std::cout << "Entry granted with hip level: " << hipLevel << std::endl;
        }
    }

}

They came up with the idea that they don’t really need two security personnels. What they instead do is that they instruct their employees to wear a hat and get coffee. So, the security system has to only test for the coffee, because the employee must already have the hat by then. But this can procedure can fail, some of the employees can be denied entry. This is because the operations aren’t sequentially consistent anymore. When an employee is instructed to GetThings(), the employee sees it as there are 2 tasks they have to complete in relaxed manner, that is, perform whatever seems convenient. The employee has no idea if any other thread is monitoring its activities. It just cares enough that by the time it has to exit GetThings() it need to have executed both the tasks. So, in case the employee feels like getting the coffee first and then the hat, there’s nobody stopping them. While, the security system is under false impression that whenever a employee has a coffee in their hands they must also have a hat on their heads. So every once in a while the security system can encounter an employee that has a coffee in his hands but not hat yet, but the security system doesn’t waits for the employee to get the hat and instead immediately runs them through the door, which obviously denies them the entry. And it’s all due to the misunderstood relaxed memory ordering.

Company C learns the lessons from both companies A and B, and wants to get the best of both worlds. So it adopts the lock based memory model.

namespace lock {
    std::atomic<bool> hasHat;
    std::atomic<bool> hasCoffee;
    std::atomic<int> hipLevel;

    void GetThings()
    {
        hasHat.store(true, std::memory_order_relaxed);
        hasCoffee.store(true, std::memory_order_release);
    }

    void CheckCoffeeAndHat()
    {
        while (!hasCoffee.load(std::memory_order_acquire)) {
            /* wait till employee gets a coffee */
        }

        if (hasHat.load(std::memory_order_relaxed)) {
            hipLevel++;
        }
    }

    void EmployeeEnter()
    {
        hasHat = false;
        hasCoffee = false;
        hipLevel = 0;

        std::thread a(GetThings);
        std::thread b(CheckCoffeeAndHat);

        a.join();
        b.join();

        if (hipLevel == 0) {
            std::cout << "Entry denied" << std::endl;
        } else {
            std::cout << "Entry granted with hip level: " << hipLevel << std::endl;
        }
    }
}

Here the all the tasks are still relaxed, except for the check on coffee. The test on coffee is set as the synchronization point. Here hasCoffee serves as a token that both the employee and the security agrees on. The employee is free to do whatever it wishes to do in whatever order if they agree to perform the store on hasCoffee at the exact point as they’re expected to. It serves as a kind of checkpoint. Whenever an employee gets a coffee, it means that they have done all the prior tasks in whatever order that seems fit, nobody cares. So whenever the security system sees an employee has a coffee in their hands, it is guaranteed that all the tasks before it have been completed. So, now the check for the hat can be successfully executed.

Company D took a slightly different approach than company C.

namespace lock2 {
    std::atomic<bool> hasHat;
    std::atomic<bool> hasCoffee;
    std::atomic<int> hipLevel;

    void GetThings()
    {
        std::this_thread::sleep_for(std::chrono::seconds(rand()%3+1));
        hasHat.store(true, std::memory_order_relaxed);
        hasCoffee.store(true, std::memory_order_release);
    }

    void CheckCoffeeAndHat()
    {
        int naps_taken = 0;
        while (!hasCoffee.load(std::memory_order_consume)) {
            /* nap for a while */
            naps_taken++;
            std::this_thread::sleep_for(std::chrono::seconds(rand()%2+1));
        }

        std::cout << "Naps: " << naps_taken << std::endl;

        if (hasHat.load(std::memory_order_relaxed)) {
            hipLevel++;
        }
    }

    void EmployeeEnter()
    {
        hasHat = false;
        hasCoffee = false;
        hipLevel = 0;

        std::thread a(GetThings);
        std::thread b(CheckCoffeeAndHat);

        a.join();
        b.join();

        if (hipLevel == 0) {
            std::cout << "Entry denied" << std::endl;
        } else {
            std::cout << "Entry granted with hip level: " << hipLevel << std::endl;
        }
    }
}

It still uses lock based memory model, but instead of asking the security system to use acquire based loop they use consume based loop. What this means is that instead of constantly monitoring employees, the security system can take a nap once in a while and whenever they wake up they just assume that the employee has a coffee in their hands, if not it can go back to sleep. This approach works good when you have a somewhat predictable data on how long does an average employee takes to GetThings().

Atomics and Objecitve-C

Coming over to Objective-C, atomicity is simplified. All the properties are by default atomic. This is good news because if you’re using multiple threads to update the same property, you will always have a valid value for that property. But this doesn’t means that the entire object will be valid.

Let’s consider a employee record example:

@interface Employee : NSObject

@property (copy) NSString *firstName;
@property (copy) NSString *lastName;
@property int coffeeConsumed; // in litres

- (NSString *)description;
@end

@implementation Employee
- (id)init
{
    self = [super init];
    if (!self) {
        return nil;
    }

    _firstName = [@"Monty" copy];
    _lastName = [@"Burns" copy];
    _coffeeConsumed = 9235;

    return self;
}

- (void)dealloc

{

    self.firstName = nil;

    self.lastName = nil;

    [super dealloc];

}

- (NSString *)description;

{

    return [NSString stringWithFormat:@"%@ %@: %@ L",

            _firstName,

            _lastName,

            @(_coffeeConsumed)];

}

@end

We simply create a employee with some default values. Now suppose we try to update a single record concurrently

void updateRecord()

{
    dispatch_group_t wait = dispatch_group_create();
    dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

    Employee *emp = [[Employee alloc] init];

    dispatch_group_enter(wait);
    dispatch_async(queue, ^{
        [NSThread sleepForTimeInterval:rand()/(NSTimeInterval)RAND_MAX];
        emp.firstName = @"Homer";
        [NSThread sleepForTimeInterval:rand()/(NSTimeInterval)RAND_MAX];
        emp.lastName = @"Simpson";
        [NSThread sleepForTimeInterval:rand()/(NSTimeInterval)RAND_MAX];
        emp.coffeeConsumed = 2045;
        dispatch_group_leave(wait);
    });

    dispatch_group_enter(wait);
    dispatch_async(queue, ^{
        [NSThread sleepForTimeInterval:rand()/(NSTimeInterval)RAND_MAX];
        emp.firstName = @"Lenny";
        [NSThread sleepForTimeInterval:rand()/(NSTimeInterval)RAND_MAX];
        emp.lastName = @"Leonard";
        [NSThread sleepForTimeInterval:rand()/(NSTimeInterval)RAND_MAX];
        emp.coffeeConsumed = 127;
        dispatch_group_leave(wait);
    });

    dispatch_group_enter(wait);
    dispatch_async(queue, ^{
        [NSThread sleepForTimeInterval:rand()/(NSTimeInterval)RAND_MAX];
        emp.firstName = @"Carl";
        [NSThread sleepForTimeInterval:rand()/(NSTimeInterval)RAND_MAX];
        emp.lastName = @"Carlson";
        [NSThread sleepForTimeInterval:rand()/(NSTimeInterval)RAND_MAX];
        emp.coffeeConsumed = 598;
        dispatch_group_leave(wait);
    });

    dispatch_group_enter(wait);
    dispatch_async(queue, ^{
        [NSThread sleepForTimeInterval:rand()/(NSTimeInterval)RAND_MAX];
        NSLog(@"%@", emp);
        dispatch_group_leave(wait);
    });

    dispatch_group_wait(wait, DISPATCH_TIME_FOREVER);
    [emp release];
}

int main(int argc, char * argv[]) {
    @autoreleasepool {
        for (int i = 0; i < 3; ++i) {
            srand(time(0));
            updateRecord();
        }
        NSLog(@"Done");
    }
    return 0;
}

Output

2014-11-01 16:11:41.496 a.out[19307:1403] Carl Simpson: 9235 L
2014-11-01 16:11:43.314 a.out[19307:1a03] Homer Burns: 9235 L
2014-11-01 16:11:46.732 a.out[19307:1a03] Lenny Simpson: 2045 L
2014-11-01 16:11:47.558 a.out[19307:507] Done

You can see that even though the emp object is absurd every time, but yet all of its atomic properties have valid values all the time.

As far as I’m aware of nothing is known about atomicity and Swift, but I’m guessing it would be close to the Objective-C model.

As usual the code for today’s experiment is available at github.com/chunkyguy/ConcurrencyExperiments.

Have fun!