Umożliwienie użytkownikom przesyłania zdjęć w aplikacji zbudowanej przez AI (bez awarii)

Dodanie przesyłania zdjęć w aplikacji zbudowanej przez AI oznacza przechowywanie plików w dedykowanym magazynie plików (nie w bazie danych), ustawienie limitu rozmiaru i typu pliku, np. 10 MB, oraz generowanie małej miniatury podglądu — podstawowe instrukcje, które warto przekazać swojemu builderowi.

W momencie, gdy Twoja aplikacja przestaje być tylko tekstem i zaczyna pozwalać ludziom przesyłać zdjęcia, coś się zmienia. Dodanie przesyłania obrazów i plików oznacza umożliwienie użytkownikowi wysłania zdjęcia, paragonu lub dokumentu z jego urządzenia do aplikacji, która zapisuje go i pokazuje później — zdjęcie profilowe, paragon, zdjęcie uszkodzonej paczki, kontrakt w PDF. To jedna z tych funkcji, która wygląda jak pojedynczy checkbox, a pod spodem kryje kilka ostrych krawędzi. Żadna z nich nie jest trudna. Ale te, przed którymi nikt Cię nie ostrzega, to te, które pojawiają się trzy tygodnie po starcie — zwykle za sprawą Twojego najbardziej entuzjastycznego użytkownika.

To przegląd tego, co naprawdę dzieje się, gdy ktoś kliknie „prześlij”, trzech błędów, które mszczą się później, oraz dokładnych rzeczy, o które warto poprosić swojego buildera, żeby ich uniknąć.

Co właściwie dzieje się, gdy przesyłasz zdjęcie do aplikacji?

Przesłanie zdjęcia uruchamia cztery kroki po kolei: telefon przekazuje plik do aplikacji, aplikacja wysyła go do osobnego magazynu plików (nie do bazy danych), aplikacja zapisuje link do tego pliku obok rekordu, a później pobiera plik za pomocą tego linku, ilekroć ktoś przegląda rekord.

Oto jak to wygląda krok po kroku:

  1. Telefon przekazuje aplikacji plik. Nowoczesne zdjęcie z telefonu to często 4 do 12 megabajtów. To nie jest mało.
  2. Twoja aplikacja wysyła ten plik gdzieś do przechowania — nie do bazy danych aplikacji, ale do osobnego magazynu przeznaczonego na pliki.
  3. Twoja aplikacja zapisuje link do tego pliku w bazie danych, obok reszty rekordu (ten paragon należy do tego wydatku).
  4. Później, gdy ktoś przegląda rekord, aplikacja pobiera plik z magazynu za pomocą tego linku i go wyświetla.

Część, którą ludzie robią źle, to kroki 2 i 3. Wyobrażają sobie, że zdjęcie zostaje „zapisane w aplikacji”. Nie zostaje, i nie powinno. Pliki żyją w magazynie; baza danych po prostu pamięta, gdzie. Jeśli dobrze to rozdzielisz, wszystko dalej idzie łatwiej.

Czy powinieneś przechowywać przesłane zdjęcia bezpośrednio w bazie danych?

Nie — i to najczęstszy błąd przy przesyłaniu plików, który buildery AI czasem popełniają domyślnie, jeśli nie jesteś konkretny. Wpychanie zdjęcia o rozmiarze 10 MB bezpośrednio do bazy danych to jak trzymanie mebli w portfelu. Baza danych jest zbudowana do małych, uporządkowanych rzeczy — imion, dat, cen. Wlej do niej zdjęcia, a zwolni, kopie zapasowe napęcznieją, i pewnego dnia strona, która wcześniej ładowała się natychmiast, zajmie sześć sekund, bo ciągnie za sobą setkę zdjęć w pełnej rozdzielczości.

Zamiast tego chcesz, żeby plik trafiał do magazynu plików (Twój builder może nazywać to „storage bucket” albo „blob storage”), a baza danych przechowywała tylko link. Poproś o to wprost:

„Przechowuj przesłane obrazy w magazynie plików, nie w bazie danych. W rekordzie zapisuj tylko URL pliku.”

Jak zapobiec przesyłaniu przez użytkowników złego typu pliku lub ogromnego pliku?

Ustalasz z góry, co jest dozwolone — typ pliku, limit rozmiaru i jasny komunikat błędu — i mówisz o tym wprost swojemu builderowi, ponieważ bez tych reguł Twoja aplikacja zaakceptuje wszystko, łącznie z plikami, które całkowicie zawieszą przesyłanie. Dwa prawdziwe scenariusze pokazują dlaczego, oba z aplikacji, które działały świetnie podczas testów:

Kobieta prowadzi małą firmę cateringową i zbudowała aplikację, w której klienci przesyłają zdjęcia tortów, które im się podobają. Działało świetnie, dopóki klientka nie przesłała zdjęcia o rozmiarze 47 MB prosto z profesjonalnego aparatu. Przesyłanie się zawiesiło, klientka się poddała, a właścicielka usłyszała o tym jako „Twoja aplikacja jest zepsuta”. Nie była zepsuta — po prostu nigdy nie ustawiono limitu rozmiaru, więc aplikacja w nieskończoność próbowała połknąć ogromny plik.

Drugi przykład: freelancer zbudował portal klienta, gdzie ludzie przesyłają „swoje logo”. Jeden klient przesłał plik .zip. Inny przesłał 90-stronicowy PDF. Aplikacja przyjęła wszystko, bo nikt nie powiedział jej, czym właściwie ma być logo.

Ustal z góry te trzy rzeczy:

  • Jakie typy plików? Tylko zdjęcia? Wtedy akceptuj JPG i PNG, a resztę odrzucaj z przyjaznym komunikatem.
  • Jak duże? Rozsądny limit dla zdjęcia to około 5 do 10 MB. Dość duży dla prawdziwego zdjęcia z telefonu, dość mały, żeby powstrzymać zrzut z aparatu.
  • Co jeśli plik jest niewłaściwy? Aplikacja powinna powiedzieć o tym uprzejmie — „Prześlij JPG lub PNG poniżej 10 MB” — a nie po prostu się zawiesić.

Powiedz swojemu builderowi:

„Zezwalaj tylko na obrazy JPG i PNG do 10 MB. Jeśli ktoś prześle coś innego lub za duży plik, pokaż jasny komunikat zamiast ciszej awarii.”

Dlaczego Twoja aplikacja wydaje się wolna, gdy ma dużo zdjęć?

Ponieważ każdy widz za każdym razem pobiera pełnowymiarowy oryginał, a nie pomniejszoną kopię — na swoim telefonie, na swoim planie danych, za każdym razem, gdy ktoś otwiera rekord. Powiedzmy, że ktoś przesyła ostre zdjęcie o rozmiarze 8 MB i samo w sobie działa dobrze. Pomnóż to przez galerię dwudziestu zdjęć, a Twoja szybka, mała aplikacja zacznie się wlec.

Rozwiązanie ma nazwę wartą znajomości, bo Twój builder ją rozpozna: miniatura, czyli wersja w zmniejszonym rozmiarze. Chodzi o to, żeby zachować oryginał, ale też stworzyć małą, przyjazną dla sieci kopię, i pokazywać tę małą kopię w listach i podglądach. Pełna wersja ładuje się dopiero wtedy, gdy ktoś naprawdę chce ją zobaczyć w dużym rozmiarze.

„Gdy obraz zostanie przesłany, stwórz też mniejszą, przeskalowaną wersję do podglądów i list. Pokazuj domyślnie małą wersję i ładuj pełny obraz tylko wtedy, gdy ktoś kliknie, żeby go zobaczyć.”

Nie musisz rozumieć, jak to jest zrobione. Musisz wiedzieć, że to istnieje, żebyś mógł o to poprosić, zanim Twoja aplikacja zacznie działać wolno, a nie po fakcie.

Kilka cichszych rzeczy wartych ustalenia

Te trzy decyzje nie zepsują Twojej aplikacji, jeśli je pominiesz, ale taniej jest podjąć je teraz niż wdrażać później: kto może zobaczyć plik, co się z nim dzieje, gdy rekord zostaje usunięty, i czy przesyłanie działa na telefonie.

  • Kto może zobaczyć plik? Zdjęcie profilowe może przeglądać każdy. Zeskanowany dowód osobisty albo podpisany kontrakt — już nie. Jeśli plik jest prywatny, powiedz swojemu builderowi, że link powinien wymagać zalogowania, a nie być publicznym URL-em, który każdy może otworzyć. To jedna rzecz, na którą naciskałbym najmocniej, jeśli chodzi o cokolwiek wrażliwego.
  • Co się dzieje, gdy rekord zostaje usunięty? Jeśli ktoś usuwa wydatek, czy zdjęcie paragonu też powinno zostać wyczyszczone? W przeciwnym razie powoli gromadzisz osierocone pliki, za których przechowywanie płacisz i o których zapomniałeś.
  • Czy działa to na telefonie? Większość przesyłań odbywa się na telefonach, a telefony oferują zarówno „zrób zdjęcie teraz”, jak i „wybierz z biblioteki”. Przetestuj oba na prawdziwym telefonie, nie tylko na laptopie, gdzie zawsze po prostu przeciągasz plik.

Przetestuj to jak obcy człowiek

Przetestuj, celowo próbując to zepsuć w taki sposób, w jaki przypadkowo zrobi to prawdziwy użytkownik — zwykłe zdjęcie, zbyt duży plik, zły typ pliku, przesyłanie na żywo z aparatu telefonu i usunięcie — zanim uznasz to za gotowe:

  • Prześlij zwykłe zdjęcie z telefonu. Czy się pojawia i czy podgląd jest szybki?
  • Prześlij coś ogromnego. Czy aplikacja zatrzymuje Cię jasnym komunikatem, czy po prostu się zawiesza?
  • Prześlij zły typ — PDF tam, gdzie spodziewane jest zdjęcie. Czy wyjaśnia zasadę?
  • Otwórz aplikację na telefonie i prześlij zdjęcie bezpośrednio z aparatu.
  • Usuń rekord i sprawdź, czy jego plik jest obsługiwany w sposób, który ustaliłeś.

Jeśli wszystkie pięć zachowuje się poprawnie, oznacza to, że poradziłeś sobie z krawędziami, które łapią większość ludzi.

Przesyłanie plików to jedna z tych funkcji, gdzie przepaść między „działa w demo” a „działa dla obcego człowieka w pociągu ze zdjęciem kota o rozmiarze 12 MB” to dokładnie zestaw decyzji opisanych powyżej. Żadna z nich nie jest trudna. Po prostu łatwo je pominąć — a o wiele łatwiej o nie poprosić teraz, niż naprawiać później.

Jeśli odkładałeś dodanie przesyłania plików, bo wydawało się to dużym technicznym skokiem — nie jest. Otwórz swojego buildera, poproś o magazyn obrazów z limitem rozmiaru i miniaturą, i zobacz, co dostaniesz. Potem spróbuj to zepsuć na swoim telefonie — to prawdziwy test i zajmuje pięć minut.