Travel Companion App

A Travel Companion App quickly becomes more complex than a simple list. Users do not only save one destination; they create trips, add several destinations to each trip, write notes, attach photos, and plan activities for different days. A common mistake is storing everything in one flat array and trying to connect records by position or by loose text values. This may work with demo data, but it becomes fragile as soon as users edit a trip title, delete a destination, or add multiple notes to the same place.

The safest approach is to design the data model before building the screens. A trip should be the top-level container. Destinations should belong to a trip. Notes and images should belong either to a destination or to a specific trip day. This gives the app a stable hierarchy and makes navigation easier because every screen can load the correct data by ID instead of guessing from visible text.

This also helps with future features. If you later add daily itinerary views, map markers, budget tracking, packing lists, or offline sync, a clear data model will make those features easier to add. Without it, every new feature becomes a patch on top of an unclear structure.

Problematic approach:

          type TravelItem = {
            id: string;
            title: string;
            note?: string;
            imageUri?: string;
            tripName?: string;
            destinationName?: string;
          };

          const travelItems: TravelItem[] = [
            {
              id: "1",
              title: "Paris",
              note: "Visit the Louvre",
              tripName: "Europe Trip"
            }
          ];

This structure mixes trips, destinations, and notes into one object type. The app cannot clearly tell whether an item is a trip, a destination, or a note.

Better approach:

          type Trip = {
            id: string;
            title: string;
            startDate: string;
            endDate: string;
            destinationIds: string[];
            createdAt: string;
          };

          type Destination = {
            id: string;
            tripId: string;
            name: string;
            country?: string;
            plannedDate?: string;
            noteIds: string[];
            imageIds: string[];
          };

          type TravelNote = {
            id: string;
            destinationId: string;
            text: string;
            createdAt: string;
            updatedAt: string;
          };

          type TravelImage = {
            id: string;
            destinationId: string;
            uri: string;
            createdAt: string;
          };

Updating nested data safely:

          function addDestinationToTrip(
            trip: Trip,
            destination: Destination
          ): Trip {
            return {
              ...trip,
              destinationIds: [
                ...trip.destinationIds,
                destination.id
              ]
            };
          }

Pay attention to: Do not let all travel data become one mixed list. Model trips, destinations, notes, and images as separate but connected entities. This keeps the app easier to update, persist, and navigate.

Navigation between trip lists, destination details, note screens, and image screens is one of the most important parts of this project. A common mistake is passing large objects through navigation params because it feels convenient. For example, the trip list passes the whole destination object to the detail screen, and the detail screen stores it locally. This creates stale data problems: if the destination is edited somewhere else, the detail screen may still display the old version.

Navigation params should usually identify what the screen should load, not become the main storage layer. For a Travel Companion App, it is cleaner to pass IDs such as tripId and destinationId. The destination detail screen can then select the latest destination from state or storage. This keeps all screens consistent and avoids duplicating the same destination data in multiple places.

This becomes even more important when images and notes are involved. A destination may receive a new note, a changed planned date, or a deleted image. If screens rely on old objects passed through navigation, the UI can show outdated trip plans until the user restarts the app or navigates back manually.

Problematic navigation:

          navigation.navigate("DestinationDetails", {
            destination: {
              id: "destination_1",
              name: "Rome",
              notes: ["Visit Colosseum"]
            }
          });

Problematic detail screen:

          function DestinationDetailsScreen({ route }) {
            const { destination } = route.params;

            return (
              <View>
                <Text>{destination.name}</Text>
                <Text>{destination.notes.length} notes</Text>
              </View>
            );
          }

This screen depends on whatever object was passed during navigation. It does not automatically reflect later updates.

Better navigation:

          navigation.navigate("DestinationDetails", {
            tripId: trip.id,
            destinationId: destination.id
          });

Better detail screen:

          function DestinationDetailsScreen({ route }) {
            const { destinationId } = route.params;

            const destination = useTravelStore((state) => {
              return state.destinations[destinationId];
            });

            const notes = useTravelStore((state) => {
              return destination.noteIds.map((noteId) => state.notes[noteId]);
            });

            if (!destination) {
              return <EmptyState title="Destination not found" />;
            }

            return (
              <View>
                <Text>{destination.name}</Text>
                <Text>{notes.length} notes</Text>
              </View>
            );
          }

Pay attention to: Pass IDs through navigation, not full mutable objects. Screens should read the latest data from one source of truth so trip details, destination notes, and images stay synchronized.

Image upload is one of the features that makes a Travel Companion App feel real, but it also introduces mobile-specific problems. Images are not like short notes. They can be large, temporary, permission-dependent, and device-specific. A common mistake is storing image data directly inside the destination object, especially as base64 strings. This makes local storage heavy, slows down app startup, and can make the whole destination record difficult to update.

A better approach is to store image metadata and a local URI. The image file itself should stay in the device file system or media storage, while your app stores a stable reference to it. This makes the data model lighter and keeps destinations easier to render. You should also handle permission denial and image-picking cancellation as normal user flows, not as unexpected errors.

The app should also avoid showing huge original photos directly in long lists. Use thumbnails or smaller previews in destination cards, and open full-size images only in a detail view. This improves performance and makes the travel list feel smoother on real devices.

Problematic approach:

          type Destination = {
            id: string;
            name: string;
            imageBase64: string;
          };

          async function addImage(destinationId: string) {
            const image = await ImagePicker.launchImageLibraryAsync({
              base64: true
            });

            updateDestination(destinationId, {
              imageBase64: image.assets[0].base64
            });
          }

This stores large image content inside the destination record. It can make persistence slow and cause memory issues as users add more travel photos.

Better image model:

          type TravelImage = {
            id: string;
            destinationId: string;
            uri: string;
            width?: number;
            height?: number;
            createdAt: string;
          };

Safer image picker flow:

          async function pickDestinationImage(
            destinationId: string
          ): Promise<TravelImage | null> {
            const permission = await ImagePicker.requestMediaLibraryPermissionsAsync();

            if (!permission.granted) {
              Alert.alert(
                "Permission needed",
                "Allow photo access to attach images to your destination."
              );

              return null;
            }

            const result = await ImagePicker.launchImageLibraryAsync({
              mediaTypes: ImagePicker.MediaTypeOptions.Images,
              quality: 0.7
            });

            if (result.canceled) {
              return null;
            }

            const asset = result.assets[0];

            return {
              id: crypto.randomUUID(),
              destinationId,
              uri: asset.uri,
              width: asset.width,
              height: asset.height,
              createdAt: new Date().toISOString()
            };
          }

Rendering a preview:

          function DestinationImagePreview({ image }: { image: TravelImage }) {
            return (
              <Image
                source={{ uri: image.uri }}
                style={{
                  width: 96,
                  height: 96,
                  borderRadius: 12
                }}
                resizeMode="cover"
              />
            );
          }

Pay attention to: Store image references, not heavy image content. Handle permissions, cancellation, preview sizing, and missing files. Mobile image handling should be designed for real device constraints.

Local persistence is useful because travelers may open the app without internet access. But local storage should not be treated as always valid. Users can keep a travel app installed for months, and your data model may change during development. Maybe an old version stored destinations directly inside trips, while the new version stores destination IDs. If you load old data without validation, the app may crash when users open a trip.

A travel app also stores more complicated data than a simple checklist: dates, notes, image URIs, nested IDs, and optional fields. This means validation is not just a nice extra. It protects the app from corrupted JSON, incomplete records, missing image references, and outdated structures. You should load data through a small persistence layer that can validate, repair, or migrate saved records before the UI receives them.

The app should also have a hydration state. Until saved trips are loaded, do not show the final empty state. Otherwise users may briefly see “No trips yet” and think their plans disappeared. Show a loading screen first, then render the real empty state only after storage has been checked.

Problematic approach:

          const [trips, setTrips] = useState<Trip[]>([]);

          useEffect(() => {
            async function loadTrips() {
              const savedTrips = await AsyncStorage.getItem("trips");

              if (savedTrips) {
                setTrips(JSON.parse(savedTrips));
              }
            }

            loadTrips();
          }, []);

This assumes stored data always matches the current model. It also has no loading state and no fallback if JSON parsing fails.

Better storage state:

          type TravelStorageState =
            | { status: "loading" }
            | { status: "ready"; data: TravelData }
            | { status: "error"; message: string };

          type TravelData = {
            trips: Record<string, Trip>;
            destinations: Record<string, Destination>;
            notes: Record<string, TravelNote>;
            images: Record<string, TravelImage>;
            version: number;
          };

Validation example:

          function isTrip(value: unknown): value is Trip {
            if (!value || typeof value !== "object") {
              return false;
            }

            const trip = value as Record<string, unknown>;

            return (
              typeof trip.id === "string" &&
              typeof trip.title === "string" &&
              typeof trip.startDate === "string" &&
              typeof trip.endDate === "string" &&
              Array.isArray(trip.destinationIds)
            );
          }

          async function loadTravelData(): Promise<TravelStorageState> {
            try {
              const saved = await AsyncStorage.getItem("travelData");

              if (!saved) {
                return {
                  status: "ready",
                  data: createEmptyTravelData()
                };
              }

              const parsed: unknown = JSON.parse(saved);
              const migrated = migrateTravelData(parsed);

              return {
                status: "ready",
                data: migrated
              };
            } catch {
              return {
                status: "error",
                message: "Travel data could not be loaded."
              };
            }
          }

Safe rendering:

          if (storageState.status === "loading") {
            return <LoadingTripsScreen />;
          }

          if (storageState.status === "error") {
            return (
              <ErrorState
                title="Could not load your trips"
                description={storageState.message}
              />
            );
          }

          if (!Object.keys(storageState.data.trips).length) {
            return <EmptyTripsState />;
          }

Pay attention to: Treat local data like external data. Validate it, support migrations, and show the empty state only after storage has finished loading.

A Travel Companion App is often used in stressful or low-connectivity situations: at an airport, on a train, in a hotel lobby, or while walking through an unfamiliar city. If the app assumes perfect internet, precise GPS, and unlimited attention, it will not feel reliable. Even if your project does not include a backend, the UI should still be designed around travel reality.

The most important travel details should be available offline: trip dates, destination names, notes, saved images, daily plans, and personal reminders. If location features are included, permission denial and unavailable GPS should not block the whole app. Users should still be able to manually add a destination or write a note. Travel planning should not depend entirely on maps or automatic location detection.

This also affects screen hierarchy. The app should not hide daily plans three screens deep. Users should be able to open a trip and quickly see where they are going, what is planned today, and which notes or images belong to the current destination. A beautiful travel UI is less useful if the navigation flow makes users lose context.

Problematic flow:

          async function createDestinationFromCurrentLocation() {
            const location = await Location.getCurrentPositionAsync();
            const address = await reverseGeocode(location.coords);

            createDestination({
              name: address.city,
              latitude: location.coords.latitude,
              longitude: location.coords.longitude
            });
          }

This assumes location permission, GPS availability, and successful reverse geocoding. If any step fails, the user cannot create the destination.

Better fallback-first flow:

          async function createDestination(input: {
            name: string;
            tripId: string;
            coordinates?: {
              latitude: number;
              longitude: number;
            };
          }): Promise<Destination> {
            return {
              id: crypto.randomUUID(),
              tripId: input.tripId,
              name: input.name,
              coordinates: input.coordinates,
              noteIds: [],
              imageIds: []
            };
          }

          async function tryAttachCurrentLocation(destinationId: string): Promise<void> {
            try {
              const permission = await Location.requestForegroundPermissionsAsync();

              if (!permission.granted) {
                return;
              }

              const location = await Location.getCurrentPositionAsync();

              updateDestination(destinationId, {
                coordinates: {
                  latitude: location.coords.latitude,
                  longitude: location.coords.longitude
                }
              });
            } catch {
              showMessage("Destination saved without location.");
            }
          }

Useful offline-first screen priority:

          type TripOverviewData = {
            tripTitle: string;
            dateRange: string;
            todayPlans: TravelNote[];
            destinations: Destination[];
            savedImagesCount: number;
          };

Pay attention to: Design for real travel conditions. Manual entry should work even if GPS, maps, image upload, or network-based features fail. The app should remain useful offline and keep key trip information easy to reach.

Travel apps can grow quickly. A user may create multiple trips, each with destinations, notes, reminders, and many images. If you render every trip, every destination, and every photo inside a single ScrollView, the app may feel fine with demo data but slow down with real travel history. This is especially noticeable on older Android devices or when image previews are large.

For growing lists, use FlatList or section-based list components. For photo-heavy screens, render thumbnails, avoid unnecessary re-renders, and keep stable keys. If a destination card includes images, show one preview or a small count rather than rendering the whole gallery inside the list item. Full galleries should open in a dedicated screen where the app can manage image loading more carefully.

Performance planning also applies to derived data. Avoid recalculating every trip summary on every render if only one note changed. Use memoized selectors or normalized data so the app can update only the affected parts. This keeps navigation smooth and makes the app feel more professional.

Problematic rendering:

          function TripsScreen({ trips }) {
            return (
              <ScrollView>
                {trips.map((trip) => (
                  <TripCard key={trip.id} trip={trip} />
                ))}
              </ScrollView>
            );
          }

This renders every trip card at once. If each card contains destinations and images, the screen can become expensive to mount.

Better list rendering:

          function TripsScreen({ trips }) {
            return (
              <FlatList
                data={trips}
                keyExtractor={(trip) => trip.id}
                renderItem={({ item }) => (
                  <TripCard trip={item} />
                )}
                initialNumToRender={8}
                windowSize={7}
                removeClippedSubviews
              />
            );
          }

Photo preview strategy:

          function DestinationCard({ destination, images }) {
            const firstImage = images[0];

            return (
              <Pressable>
                {firstImage ? (
                  <Image
                    source={{ uri: firstImage.uri }}
                    style={styles.thumbnail}
                    resizeMode="cover"
                  />
                ) : (
                  <PlaceholderImage />
                )}

                <Text>{destination.name}</Text>
                <Text>{images.length} saved photos</Text>
              </Pressable>
            );
          }

Pay attention to: Use virtualized lists for trips, destinations, and galleries. Render small previews in lists, open heavy details on separate screens, and test with realistic travel data instead of only two demo destinations.