{"id":"l-rn-2-3","courseId":"react-native-apps","lang":"en","kind":"lesson","summary":"Make Trailhead’s screens fit any phone with useWindowDimensions and safe-area insets, and write platform-specific code with Platform.select or per-platform files only where the platforms really differ.","html":"

The phones your users carry range from small Android devices around 360 points wide to large iPhones over 430, plus tablets, foldables that change width mid-session, and landscape. On top of that, the screen isn’t a clean rectangle: there’s a notch or Dynamic Island, rounded corners, a home indicator, and on Android, status and navigation bars that your app now draws behind. Three tools make Trailhead fit all of that.

\n

Reading the screen size the right way

\n

useWindowDimensions() returns the window’s width, height, scale and fontScale, and re-renders your component whenever they change:

\n
TSX
import { useWindowDimensions } from 'react-native';\n\nexport function PhotoGrid({ photos }: { photos: string[] }) {\n  const { width } = useWindowDimensions();\n  const columns = width >= 700 ? 4 : 2;\n  // …render photos in `columns` columns\n}
\n

You’ll find older code calling Dimensions.get('window') at module level. That reads the size once, when the file loads, and never again: rotate the phone, open the app in iPad split view, or unfold a foldable, and the layout keeps using the old width. Use the hook inside components.

\n

Prefer flex over measurements when you can. Most layouts never need the width at all; reach for useWindowDimensions when the structure changes with size (two columns become four), not to compute pixel values flexbox already handles.

\n\n

Safe areas on both platforms

\n

The safe area is the part of the screen not covered by hardware cutouts or system UI. Navigation headers and tab bars from Expo Router already respect it. Screens without them, like a full-screen map or an onboarding page, must handle it themselves.

\n

The library for this is react-native-safe-area-context. Expo Router already includes it and provides the SafeAreaProvider at the root, so you can use the hook straight away:

\n
src/app/track.tsx
import { StyleSheet, Text, View } from 'react-native';\nimport { useSafeAreaInsets } from 'react-native-safe-area-context';\n\nexport default function TrackScreen() {\n  const insets = useSafeAreaInsets();\n\n  return (\n    <View style={styles.screen}>\n      {/* the map fills the whole screen, edge to edge */}\n      <View style={[styles.topBar, { top: insets.top + 8 }]}>\n        <Text style={styles.timer}>01:24:10</Text>\n      </View>\n      <View style={[styles.bottomBar, { paddingBottom: insets.bottom + 12 }]}>\n        <Text>Stop and save</Text>\n      </View>\n    </View>\n  );\n}\n\nconst styles = StyleSheet.create({\n  screen: { flex: 1 },\n  topBar: { position: 'absolute', left: 16, right: 16, alignItems: 'center' },\n  timer: { fontSize: 20, fontWeight: '700' },\n  bottomBar: { position: 'absolute', left: 0, right: 0, bottom: 0, paddingTop: 12, alignItems: 'center' },\n});
\n

The map can draw under the status bar, which looks good, while the controls sit exactly below the unsafe area. insets has top, bottom, left and right, so landscape works too. The library also exports a SafeAreaView component that applies padding for you, which is handy for simple screens.

\n\n

When the platforms differ

\n

React Native shares code across iOS and Android, but the platforms aren’t identical, and pretending they are produces an app that feels foreign on both. Platform gives you the current OS:

\n
TSX
import { Platform, StyleSheet } from 'react-native';\n\nconst styles = StyleSheet.create({\n  title: {\n    fontSize: 17,\n    fontWeight: Platform.OS === 'ios' ? '600' : '500',\n  },\n  card: Platform.select({\n    ios: { boxShadow: '0 2px 8px rgba(0, 0, 0, 0.12)' },\n    android: { elevation: 3 },\n    default: {},\n  }),\n});
\n

Platform.select returns the value for the current platform, falling back to default. It’s the right tool for small differences: a font weight, a shadow, a hit slop.

\n

When a whole component differs, split it into files. Create DatePicker.ios.tsx and DatePicker.android.tsx, then import ./DatePicker with no extension; Metro picks the right file per platform. The same works with .native.tsx and .web.tsx if Trailhead ever runs on the web.

\n

Where do the platforms really differ? Navigation conventions (iOS swipes back from the left edge; Android has a system back gesture), pickers and date inputs, typography defaults, haptics, and permission flows. Where they don’t, such as your hike list, your forms and your business logic, share everything.

\n

A tablet-friendly grid

\n

Putting the pieces together: the photo grid should show as many columns as fit, with a minimum card width, consistent gaps and screen padding. That’s a small calculation, run every time the width changes, and it’s exactly the kind of pure function worth getting right once. You’ll write it in the exercise below.

\n

Next up: lists. Trailhead will soon hold hundreds of hikes, and rendering them all at once is the fastest way to make a phone feel slow.

\n","toc":[{"id":"sec-1","text":"Reading the screen size the right way","level":2},{"id":"sec-2","text":"Safe areas on both platforms","level":2},{"id":"sec-3","text":"When the platforms differ","level":2},{"id":"sec-4","text":"A tablet-friendly grid","level":2}],"takeaways":["useWindowDimensions() re-renders on rotation and resizing; Dimensions.get() is a one-time snapshot that goes stale.","Screens without a navigation header or tab bar must pad themselves with safe-area insets from react-native-safe-area-context.","Android draws apps edge to edge behind the system bars, so insets matter on Android as much as on iOS.","Use Platform.select for small differences and .ios.tsx / .android.tsx files when a whole component differs."],"further":[{"title":"Safe areas","url":"https://docs.expo.dev/develop/user-interface/safe-areas/"},{"title":"useWindowDimensions","url":"https://reactnative.dev/docs/usewindowdimensions"},{"title":"Platform-Specific Code","url":"https://reactnative.dev/docs/platform-specific-code"}],"quiz":[{"q":"

Trailhead’s photo grid computes its columns once with Dimensions.get('window').width at the top of the file. What breaks?

","options":[{"text":"Nothing; screen width never changes while an app runs.","why":"It changes on rotation, in iPad split view and on foldables, and the stored value doesn’t update."},{"text":"The grid keeps its old column count after the user rotates the phone or unfolds a foldable.","why":"Correct. Read size with useWindowDimensions() inside the component so it re-renders with the new width."},{"text":"It crashes on Android because Dimensions is iOS-only.","why":"Dimensions works on both platforms. The problem is that the value is read once and never refreshed."}],"answer":1},{"q":"

Trailhead’s full-screen map has no header. Its top buttons sit under the iPhone’s Dynamic Island. What’s the right fix?

","options":[{"text":"Add paddingTop: 50 to the screen.","why":"The right amount differs by device, orientation and platform. A magic number is wrong on most phones."},{"text":"Wrap the screen in SafeAreaView imported from react-native.","why":"That component is deprecated, works only on iOS, and doesn’t handle Android’s edge-to-edge layout."},{"text":"Hide the status bar so nothing overlaps.","why":"The Dynamic Island and rounded corners are hardware; hiding the status bar doesn’t move them."},{"text":"Read useSafeAreaInsets() and apply insets.top to the buttons’ container.","why":"Correct. Insets are the exact size of the unsafe area on this device, right now, on both platforms."}],"answer":3},{"q":"

Trailhead’s date picker needs completely different components on iOS and Android, while the rest of the form is shared. What’s the cleanest structure?

","options":[{"text":"Two files, DatePicker.ios.tsx and DatePicker.android.tsx, imported as ./DatePicker.","why":"Correct. The bundler picks the right file per platform, and each file stays simple and readable."},{"text":"One component with if (Platform.OS === 'ios') around every line that differs.","why":"That works for a line or two, but a whole component full of branches is hard to read and easy to break."},{"text":"Two separate apps, one per platform.","why":"That throws away the shared form logic, the main reason to use React Native."}],"answer":0}],"exercise":{"kind":"web","mode":"js","starter":{"js":"// Work out how many photo cards fit across the screen, and how wide each one is.\nfunction gridLayout(screenWidth, { minCardWidth = 160, gap = 12, padding = 16 } = {}) {\n const columns = Math.floor(screenWidth / minCardWidth);\n const cardWidth = screenWidth / columns;\n return { columns, cardWidth };\n}\n\nconsole.log(gridLayout(390)); // iPhone in portrait\nconsole.log(gridLayout(820)); // iPad in portrait\n"},"solution":{"js":"function gridLayout(screenWidth, { minCardWidth = 160, gap = 12, padding = 16 } = {}) {\n const available = screenWidth - padding * 2;\n const columns = Math.max(1, Math.floor((available + gap) / (minCardWidth + gap)));\n const cardWidth = Math.floor((available - gap * (columns - 1)) / columns);\n return { columns, cardWidth };\n}\n\nconsole.log(gridLayout(390)); // iPhone in portrait\nconsole.log(gridLayout(820)); // iPad in portrait\n"},"checks":[{"id":"phone","test":"return typeof gridLayout === 'function' && (() => { const r = gridLayout(390); return r && r.columns === 2 && r.cardWidth === 173; })();"},{"id":"small-phone","test":"return (() => { const r = gridLayout(320); return r && r.columns === 1 && r.cardWidth === 288; })();"},{"id":"tablet","test":"return (() => { const r = gridLayout(820); return r && r.columns === 4 && r.cardWidth === 188; })();"},{"id":"options","test":"return (() => { const r = gridLayout(400, { minCardWidth: 100, gap: 8, padding: 20 }); return r && r.columns === 3 && r.cardWidth === 114; })();"},{"id":"never-zero","test":"return (() => { const r = gridLayout(200, { minCardWidth: 300 }); return r && r.columns === 1 && r.cardWidth === 168; })();"}],"title":"Fit the photo grid to any screen","prompt":"

Trailhead’s photo grid calls gridLayout(width) with the value from useWindowDimensions(). Fix gridLayout(screenWidth, options) so it returns { columns, cardWidth } where:

\n\n

Defaults: minCardWidth = 160, gap = 12, padding = 16. For example, a 390-point iPhone gives { columns: 2, cardWidth: 173 }.

\n","hints":["Start with the space you can actually use: screenWidth - padding * 2.","n cards need n widths and n - 1 gaps. So n cards fit when n * minCardWidth + (n - 1) * gap <= available, which rearranges to n <= (available + gap) / (minCardWidth + gap).","Then cardWidth = Math.floor((available - gap * (columns - 1)) / columns), and wrap the column count in Math.max(1, …)."],"explanation":"

The starter ignored padding and gaps, so cards overflowed the screen, and it could return zero columns on a narrow screen (dividing by zero gives Infinity). The fix starts from the usable width, counts how many card-plus-gap units fit (with one fewer gap than cards), guarantees at least one column, and shares the leftover width equally. Because it’s a pure function of the width, the grid updates correctly on rotation and on foldables as soon as useWindowDimensions reports a new size.

\n","checkLabels":{"phone":"A 390-point phone gets 2 columns of 173","small-phone":"A 320-point phone gets 1 column of 288","tablet":"An 820-point tablet gets 4 columns of 188","options":"Custom minCardWidth, gap and padding are respected","never-zero":"A screen narrower than one card still gets 1 column"}},"words":642,"readMinutes":3}