Forem: Edvinas Bartkus

Translucent Sidebar with React Native for MacOS

Edvinas Bartkus — Mon, 08 Jun 2020 19:54:34 +0000

Since there was news about React Native for MacOS being supported by Microsoft engineers I was excited to try it out. When thinking of a potential MacOS app there is one common pattern to have Sidebar in your main window.

The Sidebar is well documented in Human Interface Guidelines. Usually, it has a semi-transparent background slightly blurred. More accurately, it's a translucent window.

I was interested, is it possible to get this effect in React Native. Half an hour later, I got it working, and here are my notes on how to achieve it.

Key thing is that the effect is part of Cocoa API. There is no problem to use it for React Native MacOS. Simply include #import <Cocoa/Cocoa.h> and you can use NSVisualEffectView that will get you this effect.

NSVisualEffectView can be simply a block that can be placed anywhere and you can add child views inside of it. Following Native Modules guidelines it's very straightforward.

SidebarView.h

#import <Cocoa/Cocoa.h>

@interface SidebarView : NSView
@end

SidebarView.m

#import "SidebarView.h"

@implementation SidebarView

- (instancetype)initWithFrame:(NSRect)frame
{
  if (NSClassFromString(@"NSVisualEffectView")) {
    self = [[NSClassFromString(@"NSVisualEffectView") alloc] initWithFrame:frame];
  } else {
    self = [super initWithFrame:frame];
  }

  return self;
}

@end

SidebarViewManager.h

#import <React/RCTViewManager.h>

@interface SidebarViewManager : RCTViewManager
@end

SidebarViewManager.m

#import "SidebarViewManager.h"
#import "SidebarView.h"
#import <React/RCTBridge.h>

@implementation SidebarViewManager

RCT_EXPORT_MODULE();

@synthesize bridge = _bridge;

- (NSView *)view
{
  return [[SidebarView alloc] init];
}

@end

On JavaScript side:

SidebarView.macos.js

import {requireNativeComponent} from 'react-native';

const SidebarBackgroundView = requireNativeComponent('SidebarView');

export default SidebarBackgroundView;

App.js

import React from 'react';
import {StyleSheet, View} from 'react-native';
import SidebarView from './SidebarView';

const App = () => {
  return (
    <View style={styles.container}>
      <SidebarView style={styles.sidebar} />
      <View style={styles.main} />
    </View>
  );
};

const styles = StyleSheet.create({
  container: {
    flex: 1,
    flexDirection: 'row',
  },
  sidebar: {
    flex: 1,
  },
  main: {
    flex: 2,
  },
});

export default App;

And here is the result:

Full code example: https://github.com/edvinasbartkus/react-native-macos-translucent-sidebar

If you need any help, reach me at @edvinasbartkus

AWS DataStore with shared codebase for React Native and Web

Edvinas Bartkus — Mon, 17 Feb 2020 18:23:57 +0000

Last week I saw a tweet from the AWS Amplify team about publishing the preview of DataStore for React Native. Since I have experimented with Amplify before and was rather impressed by the capabilities, I wanted to experiment with it more and to test if this is something I would choose for my next project instrumentation.

DataStore component in Amplify tooling provides the capability to work with your data structure offline and use AppSync backend to sync your remote backend. This provides full offline experience, where you can create content and it will be persisted when it is possible.

Often it's misleading when we talk about GraphQL offline possibilities. You can retrieve data, cache it and use the cache when you are offline. But what about all the mutations, merge conflicts, etc. DataStore is the project to get your project full offline support.

The previous project where I have experimented with Amplify tools was built with monorepo structure, having web and react-native projects with the fully shared codebase. You can follow @brunolemos's article to get the identical setup. Such setup provides a great case to test Amplify on both web and mobile at the same time.

I used important bits from @Ashish-Nanda post on Github about the preview of DataStore for React Native. I did not follow his steps but tried to do what's needed for my existing project. While debugging things, I did create a sample app with monorepo setup where I got DataStore fully working on mobile and web. I have published the sample project on Github so anyone can use it to get their setups working too: https://github.com/edvinasbartkus/aws-amplify-datastore-blueprint

Setup

packages/components is where we have all the shared codebase for web and mobile. In this package I have installed preview packages for Amplify:

    "@aws-amplify/datastore": "1.0.7-rn-datastore.3",
    "aws-amplify": "2.2.5-rn-datastore.3"

Next, it is important to configure Amplify app:

// Amplify
import Amplify from 'aws-amplify'
import config from '../aws-exports'
Amplify.configure(config)

aws-exports.js file is generated when you do amplify api add and amplify push. Alternatively, you can go to your Amplify Console, find AppSync and get configuration file manually.

When you create GraphQL Schema for your project, you have to annotate your models with @versioned. Versioning of the models is important to make DataStore work. With that in mind I used sample schema for my demo project:

type Blog @model @versioned {
  id: ID!
  name: String!
  posts: [Post] @connection(name: "BlogPosts")
}
type Post @model @versioned {
  id: ID!
  title: String!
  blog: Blog @connection(name: "BlogPosts")
  comments: [Comment] @connection(name: "PostComments")
}
type Comment @model @versioned {
  id: ID!
  content: String
  post: Post @connection(name: "PostComments")
}

When you have your schema configured on AppSync, run the following command to generate models for DataStore:

amplify codegen models

This will create model files that you can use to query and save data. With the models created in packages/components/models you can create code to query data. It's rather straightforward:

import { DataStore } from '@aws-amplify/datastore'
import { Blog } from './models'

const blogs = await DataStore.query(Blog)

To save data:

import { DataStore } from '@aws-amplify/datastore'
import { Blog } from './models'

const save = await DataStore.save(
  new Blog({
    name
  })
)

You can also observe changes. In my sample, I simply refresh the list when there are changes. With this, when iOS and web projects are running, when I create an object on one platform it will immediately appear on the other:

DataStore
  .observe(Blog)
  .subscribe(() => refresh())

Eventually, running the project you should be able to see the following demo working:

Ed

@edvinasbartkus

Late-night playing and experimenting with DataStore. Got iOS and Web reuse the same codebase and persist the records: twitter.com/AWSAmplify/sta…

18:17 PM - 17 Feb 2020

AWS Amplify @AWSAmplify
Amplify DataStore React Native Pre-Release Get started with the newest and most robust real-time / offline Amplify SDK, now available for testing in React Native https://t.co/WZALh0URBG https://t.co/QNpFAqGFvA

0 0

For more information how to take all the advantage of DataStore, follow their official documentation:
https://aws-amplify.github.io/docs/js/datastore

Running React Native Detox tests for iOS and Android on Github Actions

Edvinas Bartkus — Fri, 24 Jan 2020 20:39:00 +0000

If you are developing iOS and Android applications with React Native you might have encountered Detox. It's end-to-end testing and automation toolbox written and maintained by the Wix company. You can find some articles on dev.to about writing tests with Detox:

React Native End to End Testing with Detox by Spencer Carli https://dev.to/spencercarli/react-native-end-to-end-testing-with-detox-56bk
End-to-end testing in React Native with Detox by Brian Neville-O'Neill https://dev.to/bnevilleoneill/end-to-end-testing-in-react-native-with-detox-5736

When I start a new react-native project I want to have a test environment ready. You are more likely to test your code or your product if it's easy to write and run tests. I wanted to document how to setup Detox tests for React Native. Moreover, how to set up a workflow that on every push to Github I would get test runner within Github Actions.

Starter Shell Repository

I have created a starter shell repository with the empty react-native project (with a single test) that has a Detox package installed.

https://github.com/edvinasbartkus/react-native-detox-github-actions

The project includes two workflows: iOS and Android. Both workflows are using macOS-latest environments to run the tests. Important to know, every second spent on MacOS machines is equal to 10 seconds on Linux. As of right now, Github provides 2000 minutes for free every month. That translates to 200 free minutes on MacOS machines.

I tried to get sdkmanager and adkmanager to Linux environment. However, that does not seem to be so easy. Emulators are not that easy to launch and run as you can imagine. If someone gets to set up Android emulators on Github CI Linux machines, I am more than welcome to get tips on how to do that.

Steps

I go through all the steps to describe what's being done and why some options matter. The steps are based on iOS workflow: https://github.com/edvinasbartkus/react-native-detox-github-actions/blob/master/.github/workflows/ios.yml

Simple name with a definition of hook - I want to run tests on every push.

    name: iOS    
    on: [push]

Build environment: run tests on MacOS latest and if the tests don't finish in 15 minutes - kill it. I had a few problems in my side projects where tests would hung up and would spend hours not doing anything just wasting valuable minutes.

    jobs:
      build:
      runs-on: macos-latest
      timeout-minutes: 15

It's worth to have DEVELOPER_DIR defined pointing to an active installation of XCode. This changes with new versions of XCode. From time to time you have to go and look it up what's the directory for the latest version of XCode. Here is the page at Github Actions Help where all environment details are listed out: https://help.github.com/en/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners

     env:
       DEVELOPER_DIR: /Applications/Xcode_11.2.app

First actionable thing, let's get our source code of the project. We will not work with history so it's worth to checkout only the head of the repository.

     steps:
       - name: Checkout
         uses: actions/checkout@v1
         with:
           fetch-depth: 1

We need Node to get npm packages installed.

     - name: Node
       uses: actions/setup-node@v1

I do cache node_modules/. While the project is young and empty, there is not much time saved with cached modules. As the project grows you will start to see bigger time wins because of caching.

     - name: Cache node modules
       uses: actions/cache@v1
       id: cache
         with:
         path: node_modules
         key: node-modules-${{ hashFiles('**/yarn.lock') }}

When we restore node modules from the cache, we need to rebuild the Detox Framework. Otherwise, we might get an error that the Detox Framework is missing when we want to run tests.

     - name: Rebuild detox
       if: steps.cache.outputs.cache-hit == 'true'
       run: detox clean-framework-cache && detox build-framework-cache

In case if there is no cache we run regular yarn install.

     - name: Install Dependencies
       if: steps.cache.outputs.cache-hit != 'true'
       run: yarn install

Since we cache node_modules/, it's worth to cache pods directory. It's the next big thing that has to be installed every time we prepare the environment for testing.

     - name: Cache Pods
       uses: actions/cache@v1
       id: podcache
       with:
         path: ios/Pods
         key: pods-${{ hashFiles('**/Podfile.lock') }}

This could be avoided since we restore pods from the cache but it's rather a fast operation if pods are already in place.

     - name: Update Pods
       run: |
         gem update cocoapods xcodeproj
         cd ios && pod install && cd ..

Finally, we install applesumutils (a requirement by detox) and we run tests.

     - run: brew tap wix/brew
     - run: brew install applesimutils
     - run: yarn detox build e2e --configuration ios.sim.release
     - run: yarn detox test e2e --configuration ios.sim.release --cleanup --debug-synchronization 200

Android Differences

In Android workflow, we follow the same sequence. There is only few steps that are specific to Android:
https://github.com/edvinasbartkus/react-native-detox-github-actions/blob/master/.github/workflows/android.yml

We use an action to set up Java in MacOS environment.

    - name: Use specific Java version for sdkmanager to work
      uses: joschi/setup-jdk@v1
      with:
        java-version: 'openjdk8'
        architecture: 'x64'

Next, we download Android Emulator and we create an instance of emulator that is called emu

    - name: Download Android Emulator Image
      run: |
        echo "y" | $ANDROID_HOME/tools/bin/sdkmanager --install "system-images;android-29;google_apis;x86"
        echo "no" | $ANDROID_HOME/tools/bin/avdmanager create avd --force --name emu --device "Nexus 5X" -k 'system-images;android-29;google_apis;x86'
        $ANDROID_HOME/emulator/emulator -list-avds

We launch the emulator and wait until it is started

    - name: Android Emulator
      timeout-minutes: 10
      continue-on-error: true
      run: |
        echo "Starting emulator"
        nohup $ANDROID_HOME/emulator/emulator -avd emu -no-audio -no-snapshot -no-window &
        $ANDROID_HOME/platform-tools/adb wait-for-device shell 'while [[ -z $(getprop sys.boot_completed | tr -d '\r') ]]; do sleep 1; done; input keyevent 82'
        $ANDROID_HOME/platform-tools/adb devices
        echo "Emulator started"

Finally, we launch webpack server and run the tests

    - name: Android Detox
      run: yarn start & detox test -c android.emu.debug

In packcage.json we have the following configuration for Android:

  "detox": {
    "configurations": {
      "android.emu.debug": {
        "binaryPath": "android/app/build/outputs/apk/debug/app-debug.apk",
        "build":
        "cd android && ./gradlew assembleDebug assembleAndroidTest -DtestBuildType=debug && cd ..",
        "type": "android.emulator",
        "name": "emu"
      }
    },
    "test-runner": "jest"
  }

Here we specify where our .apk file is placed and tell Detox what is the name of our emulator (it's emu).

Feel free to use the repo as a reference to set up the tests. If you see where it can be improved I would love to get pull requests and improve the workflows.