In the past two weeks, I’ve been working on a BLE solution as part of a joint effort team in Israel, for the ministry of health.
During those two weeks, I witnessed enormous efforts of technology companies, universities, and technology enthusiasts all trying to stop the COVID-19 epidemic spreading.

I decided to create a list of projects I came across. If you know (or own) any other projects you are more then welcome to PM me on twitter > @gran33

Hamagen

Israel’s Ministry of Health’s COVID-19 Exposure Prevention

Source: https://github.com/MohGovIL/hamagen-react-native
Made By: Israeli Ministry of Health (official)
Discussion: React Native app for iOS and Android. In its roadmap to integrate BLE integration for improving exposure and accuracy.

DP-3T

Decentralized Privacy-Preserving Proximity Tracing

Source: https://github.com/DP-3T
Made By: Switzerland
Discussion: Include SDKs for iOS and Android with demo apps and backend SDK. They’re working to be forward-compatible with the upcoming solution by Apple and Goggle.

OpenTrace (BlueTrace)

Privacy-Preserving Cross-BorderContact Tracing

Source: https://github.com/opentrace-community
Made By: Singapore (official)
Discussion: Using BlueTrace protocol. Includes iOS and Android apps and a device calibration solution.

COVID19CZ

A joint activity of Czech technology companies and IT enthusiasts

Source: https://github.com/covid19cz
Made By: Czechia (Czech Republic) technology companies and IT enthusiasts
Discussion: A list of projects include iOS and Android apps to fight against viral infection

RN-Contact-Tracing

React Native library with dedicated BLE usage to manage contact tracing

Source: https://github.com/wix-incubator/rn-contact-tracing
Made By: Wix (Israel)
Discussion: This library is under WIP (work-in-progress). Include React-Native library (native module) with specific functionality to manage contact tracing.

PrivateTracer

Enabling the tracing of interactions between citizens, while preserving privacy.

Source: https://gitlab.com/PrivateTracer
Made By: Netherlands
Discussion: Native iOS and Android apps with Python backend. Using DP3T solution.

SafePathes

Slow the spread without giving up privacy

Source: https://github.com/tripleblindmarket/covid-safe-paths
Made By: MIT (Massachusetts, United States)
Discussion: Using new PrivateKit framework (by MIT)

CovidSafe

Slow the spread without giving up privacy

Source: https://github.com/COVIDSAFE
Made By: University of Washington (Seattle, United States)
Discussion: React Native app on iOS and native Android app.

COVID Watch

Reduce the spread of COVID-19 without increasing the spread of surveillance

Source: https://github.com/covid19risk
Made By: United States (in collaboration with Stanford University)
Discussion: List of projects includes native iOS and Android apps and server (Python).

Covid Community Alert

World-level Open-Source Anonymous Protocol

Source: https://github.com/Coronavirus-Outbreak-Control
Made By: Italy
Discussion: iOS and Android native apps.

Covid World

Fighting Covid Together

Source: https://github.com/CovidWorld
Made By: Slovakia
Discussion: Native iOS and Android apps with C# backend. Using iBeacon signals.

Pandoa

Stopping the infected chain by tracking contacts

Source: https://github.com/wirewirewirewire/pandoa
Made By: WirVsVirus hackathon (Germany)
Discussion: React native (expo) app for iOS and Android. Unmaintained.

ito

Track infections, not people!

Source: https://github.com/ito-org
Made By: WirVsVirus hackathon (Germany)
Discussion: React Native apps for iOS and Android, backend (Python).

TrackCOVID

By tracking the spread of the virus, we can flatten the curve.

Source: https://github.com/tyleryasaka/TrackCOVID
Made By: Tyler M Yasaka (United States)
Discussion: Simulation web app, React native app, using Covid Watch. Unmaintained.

CoEpi

Community Epidemiology in Action

Source: https://github.com/Co-Epi
Made By: A small group of individuals with diverse and relevant skills
Discussion: A list of iOS, Android and backend projects.

CX

Privacy-compatible distributed contact tracing

Source: https://github.com/ipxe/cx
Made By: iPXE
Discussion: Low-level solution includes an Android demo app.

Conclusion

Israel, Italy, United States, Czechia, Singapore, Germany, Slovakia, Stanford, MIT, UW, all these countries, universities and hackathons did an amazing isolated effort in order to avoid the epidemic spreading by using mobile devices Bluetooth abilities.
All of the above countries/institutions did more or less the same:

• iOS and Android code using advertise and scanning Bluetooth service.
• Save to local database to gain users privacy as much as possible
• Wrote some level of encryption in order to keep its etymology reliable
• Blocked by the fact that iOS devices can’t be back to the background by any Bluetooth functionality

In 2020 we have many worldwide unify efforts in order to achieve a goal, unfortunately, panic and stress lead the development processes and we got to this challenge one by one trying to solve the exact same problem.

I wish that in the next worldwide challenges we all be better in solving the shared challenge by less identical projects.

Stay safe and healthy!
❤

“The ratio of time spent reading (code) versus writing is well over 10 to 1 … (therefore) making it easy to read makes it easier to write.” — Robert C. Martin

The naming convention is a very contentious topic. Everyone has their own style when it comes to naming variables, functions, classes, and even documentation.

There is no single or standard way to name your code parts.

Definition

“Naming convention is a set of rules for choosing the character sequence to be used for identifiers which denote variables, types, functions, and other entities in source code and documentation” — Wikipedia

The Challenge

“The hardest thing about choosing good names is that it requires good descriptive skills and a shared cultural background. This is a teaching issue rather than a technical, business or management issue.”

We’re all different and from different backgrounds. One can describe a thing completely different for others. More than that, people from different cultures can describe the same things differently.
Selecting the proper name for a function or a variable requires experience and many hours of code reading. This challenge is not a technical or management challenge, it’s a skill that requires much practice.

Rule #1 — Consistency

Pick One Word per Concept — Use the same concept across the codebase

fetchData() {...}

getData() {...}

retrieveData() {...}

All 3 names of the above methods are the same and can be interpreted as the same operation. It doesn’t matter which one we actually pick, but it’s important that we’re consistent throughout the code. If we decide that fetch will request data remotely, we should stick with that convention for fetchPermissions and fetchUserDetails for instance.

Rule #2 — Meaningful

Characters are cheap, confusion is expensive

😳 const users;     😎 const numberOfUsers;
😳 const friends;   😎 const friendsOfCurrentUser;

We write code with a 100% mindset of that feature or context. We forget that the next reader might come with a different mindset, so we should make sure we avoid ambiguity.
For instance, in function scope, we wrote users but we actually meant numberOfUsers, which can be misleading. Or if we wanted to create a variable with all the current user’s friends, we should name it friendsOfCurrentUserrather than friends.

Rule #3 — Meaningful Distinctions

Use the same word for the same purpose

Two different things in the same scope? You might be tempted to change one name 😡

What is these functions’ return? 😕

getUserDetails() {...}
getUserInfo() {...}
getUserData() {...}

What’s the difference between details/info/data anyway?!

If we have 2 definitions for “not that different” object/class/variable we should consider aggregating its content differently. Or changing one of the names dramatically.

Another use-case:

// Function in Class A
function add(x, y) {
  return x + y;
}

// Function in Class B
function add(x) {
  this.items.add(x);
}

In class A, the add(x, y) function adding 2 numbers and in class B add(x) is insert element to the collection. Both functions' names are correct, but without deep-dive to their implementations, you won’t be able to understand and use them.
A better name will be:

add(x, y) -> addNumbers(x, y)

add(x) -> insertElement(x)

Rule #4 — Avoid Encodings

Avoid unnecessary encodings of data-types along with the variable name

string urlString;
int numberOfMembersInt;
Array<string> namesArray;

It might look good and be a useful practice, but in order to scale, this ambiguity will be annoying and hard to maintain.
The name should be a higher abstraction level of the implementation details of the actual variable type.

Rule #5— Use Pronounceable Names

Nobody wants a tongue twister or a non-searchable words

const lblFName; //first name label
const nowTsMs; //now date timestemp since 1970 in milliseconds

These kinds of variables names are hard to pronounce and no one will be able to remember them, aside from the writer themself.

Moreover, our code should be able to be searchable. When the project becomes bigger and bigger we will search more and more. Better naming make scaling easier.

Rule #6 — Don’t Be Offensive/Cute

Don’t be a serial killer behind your code

function killThemAll();
function whack();
function giveSomeLove()

Some projects are open-source, some are cross-cultural. The name you pick for your function will be read by a variety of people. The same thing can be interpreted differently between different people.

Naming convention should be generic, and as professional as possible, and should not include any cultural slang.

Rule #7 — Be Positive

shouldNotShowIfDisabledIsFalse ✌️

isDisabled should become isEnabled

isUndefined should become isDefined

shouldNotShowScreen should become shouldShowScreen

avoidBroadcast should become doBroadcast

broadcastNotArrived() should become broadcastArrived({})

As humans, we have a better understanding of the positive approach (besides the new-age approach 😎) so we should use them in the names we pick.

Rule #8 — Helper to the Manager with some Utils 🙄

NetworkHelper
RequestManager
HttpUtils

These names above are just a way to ignore the challenges of select a descriptive name to that piece of code. No one really understands what has inside these files (or classes) or what does it do.

We better avoid these names, by avoiding that we’ll arrange our code better and won’t give life to these god objects.

Rule #9— Awareness 🤖

Characters are cheap, confusion is expansive

A few general bullets to keep in mind while we coding:

• We are NOT the only ones who read our code
• Our mood is NOT related to the code we’re writing
• Humans read our code, not computers
• Read your code after you write it

Summary

Naming is hard. Naming depends on your current mood and vibe. You can’t beat that.
More often than not, we’ll re-read the names we picked, the more readable the code will be.
The main focus of this article is raising awareness. Keep that in mind that you’re writing code for humans. Keep that in mind that someone needs to read what you wrote and actually understand it.

Hope you liked it! If so, don’t be shy to 👏 and share.

Awareness Naming ✌️ #goodlife

Words Don’t Come Easy

Naming Convention — 8 Basic Rules for any Piece of Code was originally published in Wix Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Technologies used for mobile apps development can pretty much be divided into 3 major categories:

• Native - Java/Kotlin for Android and Objective-C and Swift for iOS
• Hybrid - Single code base in one language
• WebView based - Loads HTML + CSS + JavaScript pages

I’ll mainly focus on Hybrid, and more specifically on React Native.

For the past 3 years, I’ve been using React Native for most of my mobile applications needs. Prior to that, I was all about native. In between, I published a couple of native apps (Java for Android and Objective-C for iOS) and even had thought about what I’d like to do next and what tech I’d use.

When I think of mobile applications technologies, I think of these topics:

• Velocity - How fast is the development?
• Performance - How smooth the app will be?
• Scaling - Can I grow to 10x developers and features?

Velocity

Writing code once instead of twice is a key velocity factor when you pick cross-platform technology.

This means that the mobile development team can be half size. This also means that each team member can do any task, without any relations or dependency on his background or platform.

React Native covers most iOS and Android APIs, which in most cases, eliminates having to deal with platform-specific code and logic. And if we will have something missing, we will probably find it in one of the open sources libraries with are offered and supported by the incredibly friendly React Native community. I strongly suggest you dive into it, it’s a well-established community and very helpful.

Usually, we have to deal with bugs, even when we sincerely think that our code is properly written and, in our hearts, are sure that is also functional. In this case, we write the code once, meaning we decrease the number of bug fixes we have to cover, rather than fixing the same bug twice, once in each platform.

React Native takes all the JavaScript code and bundles it into a single bundle file. Technologies, like Code Push, even offer to load this bundle file remotely in order to fix bugs without publishing any new binary files to the stores.

Since we write JavaScript code in React Native, we can also use test frameworks in order to test the code like Jest and Jasmine.

Performance

If we think CPUs, multiple cores, and advanced graphics, mobile devices nowadays are like computers. Mobile applications are super responsive and full of complex animations and gravity effects.

We can’t afford our next mobile application to have less than that, and under deliver. We can’t compromise on a low or non-responsive application.

React Native includes many challenges in the performance perspective, for instance:

• When the user presses a simple button, many messages are sent back and forth between the Native side and the JavaScript side. This might lead to frames dropping and laggy behavior.
• React Native ListViews experiencing hard to perform when dealing with long lists.
• Interactive animations are hard to achieve.

These are only a few of the many challenges we need to deal with when it comes to performance in React Native.

Most of our efforts will go to these kinds of tasks, and performance issues might lead to mediocre user experience.

In some cases, might even lead to writing platform-specific code, like complex grid views with complex animation, or animation while scrolling.

Scaling

React Native opens the door to JavaScript developers to write mobile applications. JavaScript is a dynamic-type language. JavaScript only interprets on runtime and doesn’t compile.

Tools like TypeScript and Flow try to soften the problem and offer great typing like tools which are supported by the vast majority of the IDEs (VSCode, WebStorm, Atom).

In order to have 10x more developers, you need to have strong testing methodologies, unit tests, E2E test, and integration tests. Without that, it will be hard to scale and will be hard to release the next application version.

Scaling also means that your app will do more. JavaScript is a single-threaded language, and when you do more, it means that the JavaScript thread will be busier by UI tasks, network requests, heavy computing and processing messages from the Native site to JavaScript side and vice versa.

When the JavaScript thread is busy, things start to have a delay and wait on the JavaScript events bus, meaning the application starts to lag.

At this point, you must examine the project architecture that was chosen. When the application loading time is greater than 10 seconds you have to deal with timeouts in the code and eager approach, instead of lazy loading approach.

But there is nothing special to React Native technology here, only the fact that you are getting punished earlier when you make wrong decisions because of the single-threaded limitation.

React Native is a new framework (~4 years) and the APIs still aren’t stable and break from version to version. Upgrading to the latest React Native version is hard and painful.

Conclusion

React Native is awesome! Though it comes with a price.

You won’t pay this price if you bootstrap your application, have a POC or want an application that doesn’t do much. But if you want more than that, you’ll deal with performance and scale challenges.

React Native is getting better, its super strong community and big companies like Facebook, Wix, and Pinterest choose this framework and are constantly improving it. Making the React Native choice is a smart choice, yet a risky and challenging one nonetheless.

It’s all about setting expectations.
For a simple application, containing just lists and simple pages with images and some text -React Native is perfect. But, if your application is a more complex, like a game with graphics and other visual effects, than React Native might not be the right fit.

Velocity, Performance, Scaling - 3 Questions I ask before I pick React-Native over Native was originally published in Wix Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

I am a React Native developer. During my day-to-day work, I found these most useful terminal tricks to be super time savers for me, so I’m sharing. Enjoy!

This list is mine .zshrc related to react-native development

General

• Open WebStorm from the current directory

alias ws=”open -a /Applications/WebStorm.app .

• Print all scripts section in package.json (jq is required)

alias scripts=”cat package.json | jq -r ‘.scripts’”

• Edit README.md (using MacDown)

alias editReadme=”open -a /Applications/MacDown.app README.md”

• Search command or part of it in the history

alias hgrep=”history | grep $1"

iTerm

• Open .zschrc quickly

alias openzshrc=”open -a <MY_FAVOURITE_TEXT_EDITOR> ~/.zshrc”

• Load .zschrc quickly

alias loadzshrc=”source ~/.zshrc”

React Native

• Start the packager

alias rns=”adb reverse tcp:8081 tcp:8081 && watchman watch-del-all && react-native start”

• Build and Launch iOS (on iPhone X)

alias rnrios="react-native run-ios --simulator='iPhone X'"

• Build and Launch Android on the currently open emulator

alias rnrandroid="react-native run-android"

NPM | Yarn

• Reset npm (delete node_modules and reinstall)

alias resetnpm=”rm package-lock.json && rm -rf node_modules && npm i”

• Reset yarn (delete node_modules and reinstall)

alias resetyarn=”rm yarn.lock && rm -rf node_modules && yarn”

• Switch between private and public npm

alias npmpublic=”npm config set registry https://registry.npmjs.org/"

alias npmprivate=”npm config set registry http://my-private-npm.com"

• Show remote dist-tags

alias npmd="npm view $1 dist-tags"

alias yarnd="yarn info $1 dist-tags"

Android

• Android adb reverse port 8081

alias rvrs=”adb reverse tcp:8081 tcp:8081"

• Launch big screen Android emulator (for instance, Nexus 5X; the emulator should be preliminary installed)

alias android_big=”cd ~/Library/Android/sdk/tools/; ./emulator -avd Nexus_5X_API_25"

• Launch small screen Android emulator (for instance, Nexus S, the emulator should be preliminary installed)

alias android_small=”cd ~/Library/Android/sdk/tools/; ./emulator -avd Nexus_S_API_25"

• Open Android Studio from root react native app (the root should include android folder)

alias as=’open -a /Applications/Android\ Studio.app ./android’

• Reload Android Simulator

alias rr="adb shell am broadcast -a react.native.RELOAD"

Git

• If you use zsh you can use all Git commands that are embedded in your terminal — see all commands here
• Open repo page in a browser

alias gh=’git config — get remote.origin.url | xargs open’

• Reset HEAD (hard)

alias gitresethard=’git add . | echo “all added” | git reset — hard’

• Fetch and rebase

alias gfpr=”git fetch && git pull — rebase”

• Open SourceTree from the current directory (should include .git/)

alias stree=”/Applications/SourceTree.app/Contents/Resources/stree .”

Here is the complete list of the aliases. Copy it to your .zshrc file and remember to adjust to your application installation locations

1. alias ws="open -a /Applications/WebStorm.app ."
2. alias scripts="cat package.json | jq -r ‘.scripts’"
3. alias editReadme="open -a /Applications/MacDown.app README.md"
4. alias hgrep="history | grep $1"
5. alias openzshrc="open -a <MY_FAVOURITE_TEXT_EDITOR> ~/.zshrc"
6. alias loadzshrc="source ~/.zshrc"
7. alias rns="watchman watch-del-all && react-native start"
8. alias rnrios="react-native run-ios --simulator='iPhone X'"
9. alias rnrandroid="react-native run-android"
10. alias resetnpm="rm package-lock.json && rm -rf node_modules && npm i"
11. alias resetyarn="rm yarn.lock && rm -rf node_modules && yarn"
12. alias npmpublic="npm config set registry https://registry.npmjs.org/"
13. alias npmprivate="npm config set registry http://my-private-npm.com"
14. alias npmd="npm view $1 dist-tags"
15. alias yarnd="yarn info $1 dist-tags"
16. alias rvrs="adb reverse tcp:8081 tcp:8081"
17. alias android_big="cd ~/Library/Android/sdk/tools/; ./emulator -avd Nexus_5X_API_25"
18. alias android_small="cd ~/Library/Android/sdk/tools/; ./emulator -avd Nexus_S_API_25"
19. alias as="open -a /Applications/Android\ Studio.app ./android"
20. alias rr="adb shell am broadcast -a react.native.RELOAD"
21. alias gh="git config — get remote.origin.url | xargs open"
22. alias gitresethard="git add . | echo "resetting hard" | git reset —- hard"
23. alias gfpr="git fetch && git pull — rebase"
24. alias tree="/Applications/SourceTree.app/Contents/Resources/stree ."

Does it feel like you can add something to this list?
More then welcome to contact me on twitter @gran33

Like it? please 👏 and share 😍

React Native Developers - Save your Time with these 24 Terminal Tricks was originally published in Wix Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Have you ever thought about how navigation really works under the hood? Have you ever thought about actually writing your own one?

So, let’s do it! it’s not that hard.

First, let’s define what basic navigation is for us.
Think of a super simple navigation as a stack of screen with basic functionality

• push screen on top
• pop top screen by pressing the back button (or by any predefined action)
• pass data between screens

In my example, I’ll use WelcomeView and EmojisView.

Let’s start from the beginning

The “router” or the “navigator” will be in charge of screens switching. In the very first screen, the one that index will render initially, the render function will be:

render() {
  return (
    <View style={{flex: 1}}>
      {this._renderInternalView()}
    </View>
  );
}

As you can see in the code snippet, it’s a simple View which renders an internal element inside.
And _renderInternalView function returns the actual content View which will decide which view to show when the state changed:

import EmojisView from './EmojisView';
import WelcomeView from './WelcomeView';
...

renderInternalView() {
  let PresentedView;
  let pushScreen = '';

  switch(this.state.presentedView) {
    case Views.EmojisView:
      PresentedView = EmojisView;
      break;

    case Views.WelcomeView:
      PresentedView = WelcomeView;
      break;

    default:
      return null;
  }

  return (
    <PresentedView
      changeView={this._changeView}
    />
  )
}

Defining the case for each state for example:

case Views.WelcomeView:
      PresentedView = WelcomeView;
      break;

Actually, that’s it, we need to add an action button in WelcomeView and we are about to push our new screen 🤗 .

So the WelcomeView will be:

_onPress = () => {
  this.props.changeView(Views.EmijisView);
};

render() {
  return (
    <View style={styles.container}>
      <Button
        title={'Push'}
        onPress={this._onPress}
        style={styles.welcome}
      />
    </View>
  );
}

As you can see, WelcomeView holds a Button with onPress method that will trigger this.props.changeView with the Views.EmojisView.

Ok, but what is this.props.changeView 😱 ?

changeView is a predefined function we set in PresentedView in our router, and it looks like this:

_changeView = (presentedView) => {
  this.setState({presentedView});
};

It’s a simple function that changes the router internal state with the wanted View.

The router at this step looks like this:

export default class Router extends Component {

  constructor(props) {
    super(props);
    this.state = {
      presentedView: Views.WelcomeView,
    }
  }

  _changeView = (presentedView) => {
    this.setState({presentedView});
  };

  _renderInternalView() {
    let PresentedView;

    switch(this.state.presentedView) {
      
      case Views.EmojisView:
        PresentedView = Views.EmojisView;
        break;

      case Views.WelcomeView:
        PresentedView = Views.WelcomeView;
        break;

      default:
        return null;
    }

    return (
      <PresentedView
        changeView={this._changeView}
      />
    );
  }

  render() {
    return (
      <View>
        {this._renderInternalView()}
      </View>
    );
  }
}

Pop

For the pop functionality, in _renderInternalView function, we need to add a back button in order to perform back/pop. This way we mimic the native-like back button. Let’s modify _renderInternalView, instead of rendering only the PresentedView now it will return button+ PresentedView:

_renderInternalView() {
  let PresentedView;
  let backScreen;

  switch(this.state.presentedView) {
    case Views.EmojisView:
      PresentedView = Views.EmojisView;
      backScreen = Views.WelcomeView;
      break;

    case Views.WelcomeView:
      PresentedView = Views.WelcomeView;
      break;

    default:
      return null;
  }
  return (
    <View style={{flex: 1}}>

       // Back Button  
       <Button
         title={'< Pop'}
         onPress={() => this.setState({presentedView: backScreen})}
       />

       // Content View
       <PresentedView
         changeView={this._changeView}
       />

    </View>
  );
}

The new Button we just added, on onPress prop it will change presentedView screen state to the relevant backScreen we defined:

onPress={() => this.setState({presentedView: backScreen})}

Now we set all of our goals, we have push and pop and we can use these functionalities wherever we want, much like regular navigation stack.

Pass Data Between Screens

Each screen isn’t a standalone screen, it’s part of a flow, and each screen has to be some part of this flow.
In order to achieve this flow, we must be able to pass the data between screens.

Remember the function _changeView? The function that changed the screen state and its trig render which renders the new view. Let’s add one more parameter to this function, passProps

_changeView = (presentedView, passProps) => {
  this.setState({presentedView, passProps});
};

And we will add the passProps to the this.state in the screen state, so it will looks like this:

constructor(props) {
  super(props);
  this.state = {
    presentedView: Views.WelcomeView,
    passProps: {}
  }
}

Now, we need to pass this passProps object to the presentedView. In order to do so, we need to modify the view render function _renderInternalView , and it will return something like this:

return (
  <View style={{flex: 1, flexDirection: 'column'}}>
    {this._renderBackButton(backScreen)}
    <PresentedView
      changeView={this._changeView}
      passProps={this.state.passProps} //This is the addition
    />
  </View>
)

Now that we can pass data between views, let’s pass some data though 😎. For instance, let’s pass a message from WelcomeView to EmojisView. In WelcomeView let’s add the message when we call to this.props.changeView :

_onPress = () => {
  const passProps = {message: 'Hi from Welcome View'};
  this.props.changeView(Views.EmojisView, passProps);
};

render() {
  return (
    <View style={styles.container}>
      ...
      <Button title={'Push'}
              onPress={this._onPress}
      />
      ...
   </View>
  );
}

Last thing, now let’s get the passProps in EmojisView:

render() {
  return (
    <View style={styles.container}>
      ...
      {this.props.passProps.message && //if message exist -> show it
      <Text style={styles.welcome}>
        {this.props.passProps.message}
      </Text>}
      ...
    </View>
  );
}

That’s it! 🙌 Look what we just added to the Emojis screen:

Animate Transitions

Our screens transition is kind of flicking. We can do better by adding animations to push and pop actions in order to have smoother transitions between screens.

We do it with an awesome React Native api LayoutAnimation.
The transition we will demonstrate here is a simple fade animation by changing the presentedView style={{opacity: 1}} style value.

Push Screen Transition:
In _renderInternalView function, we will add style={{opacity: this.state.aniamteOpacityValue}} to the root view:

constructor(props){
  ...
  this.state = {
    animateOpacityValue = 1
  }

_renderInternalView() {
  let PresentedView = this.state.presentedView;
  ...

  return (
    <View style={{... opacity: this.state.animateOpacityValue}}>
      {this._renderBackButton(backScreen)},
      <PresentedView
        ...
      />
    </View>
  )
}

Now that we have the ground to actually perform the animation we will add the LayoutAnimation.easeInEaseOut() right before we setState(...) with the changing view :

_changeView = (presentedView, passProps) => {
  LayoutAnimation.easeInEaseOut();
  this.setState({presentedView, passProps, animateLeft: 0});
};

Notice that since we wrap all screens with root view, this behaviour will apply for all transitions and we don’t need to do it for each view.

Pop screen transition:
This is easier, our back Botton onPress code currently looks like this:

onPress={() => this.setState({presentedView: backScreen})

Instead of changing the state without the LayoutAnimation simply let’s call to _changeView which is already applying the animation, so our new onPress will be:

onPress={() => this._changeView(backScreen)}

Now, our push/pop transitions will look sweeter:

Full working application can be found on GitHub:

gran33/BuildYourOwnNavigationInReactNative

If you like it, you are more then welcome to share and claps. Feel free to comment and give feedback 🙏 .

Small Disclaimer

This simple navigation is a conceptual example which demonstrates how to be able to build your own navigation.
Out there, there are many awesome implementations like react-native-navigation which is native implementation for Bottom Bar (Tab Bar), Top Tab (Navigation Bar), Modals , screens stack and many more.

This example isn’t a production ready framework or library, I wanted to show and simplify the navigation challenge.

Many required features still need to be added here to make this concept available and really usable.

In Wix, we are using react-native-navigation in our mobile application. I am one of the core contributors in that awesome native implementation for the navigation challenge.