Flutter ilə mobil tətbiq hazırlığı ekran maketindən əvvəl istifadəçinin işini anlamaqla başlayır. Tətbiq kim üçün olacaq, nə vaxt açılacaq və hansı işi tamamlamalıdır? Bir müştəri tətbiqi ilə əməkdaşın sahədə istifadə etdiyi proqram fərqli məlumat və bağlantı şəraiti tələb edə bilər.
Mobil tətbiq hazırlanması zamanı platforma seçimi yalnız texnologiya zövqü deyil. Mövcud backend, cihaz imkanları, istifadə tezliyi və tətbiqin yayımlanma qaydası birlikdə qiymətləndirilməlidir. Hər biznes üçün eyni ilk versiya yoxdur.
Əsas istifadə ssenarisini tamamlayın
İlk versiyanın məqsədi mümkün qədər çox ekran yaratmaq deyil. İstifadəçinin bir işi əvvəlindən sonuna qədər görə bilməsi daha faydalıdır. Məsələn, iş siyahısına baxmaq, uyğun işi açmaq və nəticəni göndərmək bir tamamlanmış ssenari ola bilər. Bu, izahlı nümunədir.
Giriş, məlumat yüklənməsi, boş siyahı və səhv vəziyyəti də həmin ssenarinin hissəsidir. Yalnız ideal məlumatla çəkilmiş gözəl ekran gündəlik istifadənin bütün suallarını cavablandırmır. İstifadəçi bağlantı olmadıqda növbəti addımını anlamalıdır.
Mobil tətbiq və backend ayrılığı
Biznes qaydalarının hansı hissəsinin serverdə icra olunacağı müəyyən edilməlidir. Tətbiq bütün məlumatı özü qərarlaşdıran və serverə yalnız nəticə göndərən qara qutu olmamalıdır. İcazə, məlumat bütövlüyü və təşkilat sərhədləri backend tərəfindən də qorunur.
PHP/Laravel API planlamasında sorğu-cavab müqaviləsi, validation və əməliyyat qaydaları izah edilir. Tətbiq komandası bu müqaviləni biləndə gözlənilən və səhv cavablar üçün daha aydın interfeys qura bilir.
Zəif bağlantı və təkrar əməliyyat
Mobil istifadəçi həmişə sabit internetdə olmur. Göndərmə düyməsi basıldıqdan sonra əlaqə kəsilə bilər. Sorğunun qəbul olunub-olunmadığı bilinməyəndə təkrar eyni işi yarada bilər. Buna görə gözləmə, təkrar və təsdiq vəziyyətləri əvvəl planlaşdırılır.
- Əvvəl yüklənmiş məlumatın köhnəlməsi necə görünür?
- Göndərilməmiş dəyişiklik cihazda saxlanacaqmı?
- İki cihaz eyni qeydi dəyişəndə hansı qayda işləyir?
- İstifadəçi hesabdan çıxanda yerli məlumat nə olur?
- Server cavabı gec gələndə əməliyyat necə tamamlanır?
Bildirişlər və cihaz imkanları
Bildirişin məqsədi dəqiq olmalıdır: hansı hadisə, hansı istifadəçi və hansı keçid? Hər dəyişiklik üçün bildiriş göndərmək faydanı azalda bilər. Bildirişə toxunanda istifadəçinin artıq bağlanmış işə və ya icazəsi olmayan məlumata keçməsi kimi hallar nəzərdən keçirilməlidir.
Kamera, fayl, məkan və digər cihaz imkanları yalnız iş ssenarisində lazım olduqda seçilir. İcazə verilməməsi tətbiqi anlaşılmaz vəziyyətdə qoymamalıdır. İstifadəçi funksiyanın nə üçün tələb edildiyini və alternativ yolunu görməlidir.
Platforma seçimi və ümumi kod
Flutter müxtəlif platformalara tətbiq hazırlamaq imkanları verir, lakin bütün cihaz və sistem davranışlarının eyni olduğunu fərz etmək olmaz. Platformaya uyğun test və əlavə iş ehtiyacı layihənin konkret funksiyalarından asılıdır. Flutter-in rəsmi platforma izahı veb istifadənin tətbiq yönümlü ssenarilərini ayrıca göstərir.
İctimai məzmun saytı ilə mobil iş tətbiqinin ehtiyacı fərqlidirsə, onları eyni interfeysə məcbur etmək lazım deyil. Bu qərar Flutter və veb tətbiq müqayisəsində daha ətraflı nəzərdən keçirilir.
Qəbul sınaqları və yayım
- Real cihaz ölçüləri və əsas istifadə axını.
- İlk giriş, təkrar giriş və hesabdan çıxış.
- Zəif bağlantı və yarımçıq göndərmə.
- Cihaz icazəsinin rədd edilməsi.
- Bildirişdən uyğun qeydə keçid.
- Köhnə tətbiq versiyası ilə backend cavabının uyğunluğu.
Yayım ayrıca mərhələdir: tətbiq hesabları, yayım materialları, test versiyası və yeniləmə qaydası əvvəl müəyyən edilməlidir. Tərəfdaş platformanın yoxlama qərarları proqramçının tam nəzarətində olmaya bilər. Buna görə konkret qəbul vaxtına əsassız zəmanət vermək olmaz.
Nümunə: nəticə yazılıb, amma göndərilməyib
Sahədə işləyən əməkdaş formu doldurur və bağlantı kəsilir. Bu şərti ssenaridə məlumatın cihazda qalıb-qalmadığı və işin serverdə tamamlanıb-tamamlanmadığı fərqlidir. İstifadəçi «göndərildi» ilə «göndərilməyi gözləyir» vəziyyətini aydın görməlidir.
Proqram bağlanıb yenidən açılanda formun taleyi yoxlanılır. Sonradan başqa hesaba giriş olarsa, əvvəlki şəxsin qeydləri yanlış istifadəçiyə görünməməlidir. Təkrar göndərmə eyni nəticəni ikinci dəfə yaratmamalıdır. Bu, ayrıca qəbul edilən məlumat qaydasıdır.
- Formun doldurulmasını bağlantısız sınayın.
- Proqram yenidən açıldıqdan sonra vəziyyəti yoxlayın.
- Başqa hesaba keçəndə məlumat ayrılığını müqayisə edin.
- Bağlantı bərpa olunanda təkrarın nəticəsinə baxın.
Bu nümunə offline funksiyasının bir düymə olmadığını göstərir. Hazırlıq əhatəsi yalnız hansı məlumatın hansı şəraitdə saxlanması və serverlə necə uyğunlaşdırılması müəyyən ediləndə aydınlaşır.
Tez verilən suallar
Mövcud saytın API-si istifadə oluna bilərmi?
Məlumat, giriş və mobil ssenarilər uyğun gəlirsə mümkündür. Sadəcə API-nin mövcudluğu kifayət deyil; müqavilə yoxlanmalıdır.
İlk versiya internetsiz işləməlidirmi?
Bu biznes tələbidir. Tam offline iş əlavə sinxronizasiya və münaqişə qaydaları tələb edə bilər.
Finex kimi biznes platformalarının iş axınları mobil interfeys ehtiyacını müzakirə etmək üçün kontekst yaradır. Öz tətbiqiniz üçün əvvəl bir ssenari yazın, sonra API əlaqəsini və mobil hazırlıq əhatəsini dəqiqləşdirin.
