React Native has a Share module to use the platform share functionality, but in this case we want to send the link to the user’s contacts so that’s not what we want to use. App platforms provide the primitives needed to build this experience but there is still a lot of work involved to build the UI and tie it all together.

Let’s get to work

Here’s the flow we’re looking to build.

• Ask permissions to access contacts.
• Fetch all contacts.
• Use SectionList to group contacts alphabetically. Also some contacts might appear more than once if they contain multiple emails or phone numbers.
• Open the email composer with selected email contacts.
• Open the SMS composer with selected phone number contacts.

We won’t bother too much with UI here, as your app probably has its own design system.

JavaScript Ninja

Like any great JS dev let’s look at what exists on NPM to be able to accomplish this. First, we need contacts, and the first thing that pops up is react-native-contacts, which actually looks great: 1k stars, recent commits, we’re in business. But then comes the fun part…

iOS has something called MFMailComposeViewController and MFMessageComposeViewController which allow sending emails or text without leaving the app. This means we cannot just use Linking.openURL('mailto:') since it would open the mail app and lead to worse UX.

So back to Google, but this time there’s nothing that looks particularly great until…

Right! Turns out Expo has modules for all these things and they also work in regular React Native apps thanks to Unimodules.

Expo to the rescue

Unimodules is a recent effort by Expo to make their native modules universal (you get the name now?). Universal means they can be used even if you are not using Expo. They can even be used with other frameworks like Flutter (but who cares 😜). Just follow the instructions in the readme to set it up for your project.

Let’s install the modules that we will need (using yarn cuz we kewl)

yarn add expo-permissions expo-contacts expo-sms expo-mail-composer

Ok, show me some code

First we need to start by fetching contacts. Here’s a hook to do this.

This part is relatively straightforward. Permissions handling is not perfect, but I wanted to keep this code snippet sample. For production code permissions are stored as persisted global state (redux).

Next we need to transform this data into the format expected by SectionList. There’s probably a more beautiful and performant way to do this but here we go anyway:

We’re using the useMemo hook to avoid recomputing the section data on every render. This also does a few things:

• Use Array.reduce to create one RowItem object for each contact’s phone number and email.
• Group these objects by the first letter of the contact’s name using lodash/groupBy.
• Use Object.entries to go back to an array of objects with key and data. This is what is expected by SectionList.

Now that we can display the contacts we need to be able to select them. I won’t go through this code since it’s pretty simple. The last thing is we need a button that when clicked triggers the email and sms send composers:

We split our contacts in 2 groups, one for emails and one for SMS. We then show the composers one after the other if they have at least one contact of their type. We can also check the result to know if the user cancelled or actually sent a message.

Suspicious blueberries

You can play with the full code in this snack (note that the composers do not work on the simulator, so you should open the snack in the Expo client on your physical device to try it out). The production version of this will also be available in the Th3rd Wave app soon.

Follow our brilliantly clever (and just brilliant) guest-blogger, Janic, here on Medium, on Twitter, and on Github, for more gems like these!

Help your users share their love for your app with React Native was originally published in Exposition on Medium, where people are continuing the conversation by highlighting and responding to this story.

How assets work within the Expo client

1. When publishing your experience, Metro (the React Native packager) generates a map of all assets used by the app. They are then uploaded to the Expo CDN using the asset hash has its key.
2. Using some magic in React Native asset resolution, we can change the URI field to its path on the Expo CDN instead of the local file.

// React Native asset object
{ uri: "file:///selfie.png", ... }
// Changes to ⬇️⬇️⬇️
{ uri: "https://cdn.expo.io/<assetHash>" }

This works really well with the Expo client where we can’t include assets inside the app bundle. It also works perfectly with over-the-air (OTA) updates and has somewhat limited offline support through caching.

The main problem arises when trying to load the app from the first time when offline.

Introducing asset bundling

Since SDK 24, Expo supports asset bundling for better offline support with the assetBundlePatterns key in app.json .

It looks like this:

{
  "expo": {
    ...
    "assetBundlePatterns": [
      "assets/images/*"
    ],
  }
}

It uses an array of glob patterns and all assets that match it in the project will be bundled when building. We’re also working on support for ExpoKit so that should be available soon.

Here’s an overview of how it works:

1. During the publish phase we can save data about all the assets we want to bundle with the app; let’s call it the “Asset Manifest”.
2. When building the Standalone App, we download the assets included in the Asset Manifest from the Expo CDN and copy them inside the app IPA or APK.
3. At runtime we know which asset are bundled with the app and can change the path to the local asset in the bundle instead of the CDN URL.

It still works great with OTA updates since the asset hash will change if the asset was modified and we will download it from the network instead.

Check out the Expo docs for more details, and make sure to update your app and the exp CLI to the latest version to try it out!

Curious for more? Follow our guest-blogger and developer-partner extraordinaire, Janic, on Github and Twitter.

Under the Hood: Offline Assets in Expo was originally published in Exposition on Medium, where people are continuing the conversation by highlighting and responding to this story.

Note that I will be using Relay in my example but something similar could very well be implemented for any other GraphQL client or even for REST APIs. It is mostly just a small wrapper around data fetching components.

Problem One: Stale Data

One thing that usually happens because of the way navigation works on mobile is that you end up with screens that never get unmounted unless the app is killed and leads to old data being displayed. On native iOS one could use viewWillAppear to refetch data but you might not want to do it that often.

So let’s start our new component that will be a wrapper around Relay’s QueryRenderer component and add some logic to refetch the data when the app comes to the foreground. As a bonus we also want to limit the refetch happen at most once per 5 minutes.

Using the AppState module from React Native we can detect when the app comes to the foreground and refetch the query. Sadly there is no documented way to do that currently with Relay so we resort to using a private API.

Problem Two: Sane Defaults for Loading States and Error Handling

Every screen that fetches data from the network will need display some sort of loading state and handle network (and even programmer) errors in a graceful way. Instead of repeating this logic over and over we can add this to our custom QueryRenderer. If the behaviour needs to be customized we can pass a `renderLoading` and/or `renderError` prop to override the defaults.

Let’s see how that would look with the component we created in the previous step.

We can leverage default props to provide the Loading and Error component and simplify the render function to only be called when data is available, the other cases can be handled by the defaults since it will almost always be the same. Killing boilerplate code one prop at a time!

Problem Three: Make UI/UX Designers Happy

Wouldn’t it be cool if the data faded in smoothly after finishing loading instead of having it appear suddenly. Now that we have our fancy custom QueryRenderer adding this feature to every screen that loads data should be pretty simple!

Here we use a little `setTimeout` hack to make sure we don’t fade in the data if it loaded too fast (usually from a disk or memory cache). This creates a much smoother loading experience.

Problem Four Thousand, Six Hundred Seventy-One: … ???

At this point our RelayUtils.js file is pretty big but it does handle a lot of things and all centralized at a single place! This make developing screens a breeze and leaves error prone code out of product code. We also get consistent handling of complex app behaviour across the app.

There are a lot more things we can build into our Renderer component but won’t cover them all here. I will share a gist at the end with some of what I have built and hopefully it can be of some use.

Here are some thoughts and things I experimented with:

• Handling of the Relay environment, nice to avoid having to pass it around all the time.
• Memory / Disk Cache, after hacking around a bit I found a decent way to do this in Relay (disclaimer: still somewhat experimental).
• Reloading data on connectivity change, very similar to the app state change one.
• Offline UI, we could display a banner over the content.
• Allow to render stale props, QueryRenderer shows the loading state if it receive new props it doesn’t have data for, we can customize this behaviour to make it render its old content while fetching the new one instead (This was actually implemented by forking QueryRenderer and could be interesting to upstream to Relay).
• `componentDidCatch` + error reporting.
• Integration with the authentication state, something like a prop that tells if the user must be authenticated to do the query. It could render a login screen in the case the user is not logged yet.
• Display the iOS status bar network indicator on network requests (this is better implemented at the network layer).

The main idea is to build small app specific libraries around open source libraries to provide app specific defaults and handle common cases instead of trying to handle everything in an ad-hoc kind of way.

Show Some Code now!

I tried to extract what was not too app specific but it might not be usable as is. Also please note that it is, at the time of the writing, based on Relay 1.5.0-rc.1.

Final code gist 👌

This is inspired heavily by a screen I had to make when working on the Th3rdwave app. Here is the final result.

You can also try it on Expo with this link and check out the source on Github.

Please note that to keep the code samples brief I’ll omit some parts and mark it with `[…]`, you can check the source for the missing parts.

Initial structure

First let’s create the view hierarchy that we will need. Basically this is just a ListView with some padding equals to the navbar height and the navbar is displayed on top of it using absolute positioning. This allows translating the navbar using transforms when scrolling the ListView.

Adding some Animated values

Next let’s create some Animated values. We will create 3 different Animated values:

• scrollAnim, this is simply the current scroll y position of the ListView
• offsetAnim, this will be used to move the navbar programmatically when needed. This will be useful when we want to fully reveal or hide the navbar at the end of a scroll gesture. We don’t want to animate the scrollAnim directly since as soon as scrolling happens it’s value will be reset to the scroll position and cause some weird behavior.
• clampedScroll, this is the value used to animate the navbar. We also save it in the state to avoid recreating it on each render. It is created by adding together scrollAnim and offsetAnim and then using Animated.diffClamp. I’ll explain what diffClamp does in details in the next section. It also does an interpolation on scrollAnim to avoid issues with the bounce effect on iOS.

Animated.diffClamp

This was added to animated recently to be able to represent the animation we want to do here. Basically we can’t simply use Animated.interpolate with extrapolate: clamp since we want the navbar to start showing up again as soon as we start scrolling back up. This is where diffClamp is useful, what it does is calculate the difference between the current value and the last and then clamp that value. For example for Animated.diffClamp(input, 0, 10) here is a table of the input and output values.

Attaching the Animated values

Now we need to attach these values to the views and add some interpolations to map them to the opacity of the title text and the translation of the navbar view. I won’t explain these in details so if you are not familiar with Animated and useNativeDriver I suggest checking my first article and my blog post on native animations.

At this point our example is pretty functional but one detail is missing. When you stop scrolling and the navbar is half collapsed it would be nice to animate it back to either it’s fully displayed or hidden state. This is where we will use the offsetAnim value we created earlier.

The hack

Now let’s add some code to detect when scrolling is over. Sadly I don’t know of a solution that works properly with both momentum and normal scroll. Here is the order events are called for a normal scroll:

• onScrollEndDrag

And a momentum scroll:

• onScrollEndDrag
• onMomentumScrollBegin
• onMomentumScrollEnd

What we do is start a short timer in onScrollEndDrag and clear it in onMomentumScrollBegin. In the case of a normal scroll, our method that handles animating the navbar will get called after a small delay by the timer and in the case of a momentum scroll, the timer will get cleared and our method will get called in onMomentumScrollEnd.

The final animation

The last thing we need is to know whether we should hide the navbar or show it. For that we need to know the value of the different Animated values used. To do that we can add listeners to the values and save it in an instance variable to access it in the _onMomentumScrollEnd method. One caveat here is that the value returned from Animated.diffClamp doesn’t support adding listeners to it (there is a PR to support that, but it isn’t merged yet) so we have to do the same calculations that diffClamp does manually.

Now that we have synchronous access to these values we can implement the logic to show or hide the navbar.

Here we want to animate the offset. If we add to its current value it will cause the navbar to hide (like if the user scrolled down) and if we subtract from it, it will cause the navbar to show. What we do is simply check the clamped scroll value and check if it has passed the half of the navbar. We also want to make sure we don’t hide the navbar if we haven’t scrolled enough yet or it will show a blank space where the navbar is supposed to be.

Well that was something…

Implementing these advanced UI behaviors is definitely tricky, either natively or with React Native (with the exception of Android that has developed a nice library to deal with this). Ideally we’d have some abstractions to avoid having to implementing this when developing an app.

See the final code here

React Native collapsible navbar was originally published in App & Flow on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here’s a walkthrough that shows how to build a header that is animated with the scroll position of a ScrollView. I had to build something similar for an app and found out that it was really easy to do in React Native using the Animated API.

Here’s the final result:

You can also try it on Expo here and find the final source on github.

How does it work?

The idea is to render a header over the ScrollView using position: ‘absolute’ and adding a margin to the top of the ScrollView to offset for the header. Then we can simply animate the header height using the ScrollView scroll position.

Time for some code!

Let’s start by creating a ScrollView with some content and import everything we will need for the next steps.

Next we need to create the header View and add a margin to the ScrollView content so it’s content is not under the header. We will also add a title for the header. Let’s add the following View after the ScrollView. We will use an Animated.View since it is going to be animated eventually.

And the following styles:

We will also define some constants for the header sizes that will be used to interpolate the scroll position value.

Now we should have the desired initial layout and everything ready for the next step.

Animation time

React Native has a very powerful declarative animation API that allows to animate a value but also bind it’s value to an event. In this case we will want to bind an animated value to the ScrollView Y scroll position. To do so, we use an Animated.event with the ScrollView onScroll prop.

First we create an Animated.Value which is a simple value that can be animated using the Animated API.

Then we bind the animated value to the ScrollView scroll position. To do that we use an Animated.event with a mapping to the event object property that we want to bind to the animated value. In this case it is <eventObject>.nativeEvent.contentOffset.y.

Then we use the interpolate method of the Animated.Value to map the scroll position to the desired header height. What we want is that when the scroll position is at 0, the header is at HEADER_MAX_HEIGHT and when the scroll position has moved to the difference between HEADER_MAX_HEIGHT and HEADER_MIN_HEIGHT, the header is at HEADER_MIN_HEIGHT.

Finally we just set the height to the animated value for the header view. We also set the scrollEventThrottle prop to 16 so events are sent often enough to have a smooth animation.

At this point the header will move with the scroll position and using the same technique we can animate pretty much anything we want in the header while the user is scrolling. Time to use your creativity :)

More animations

Now this header is a bit boring let’s add our favorite cat picture with a parallax effect to make it nicer. To do this let’s add two new interpolated animated values and an Image component.

We use the same initial interpolation values but here we want to output an opacity value and a translation of the image to create the parallax effect. We also animate the opacity a bit differently by adding a 3rd breakpoint in the middle. This way the opacity will only start to decay when the header has scrolled halfway.

Now all that is missing is scaling / translating the header title a bit but I’ll leave that as an exercise.

Wrapping up

The Animated API makes it very easy to create very complex animations by interpolating a value in multiple different ways. It also allows to keep the state super simple. Everything is based on one value, all the animation complexity is handled in the render function with the interpolations.

React Native ScrollView animated header was originally published in App & Flow on Medium, where people are continuing the conversation by highlighting and responding to this story.