Jika Anda seorang pengembang aplikasi seluler, mungkin Anda memimpikan fleksibilitas pengembangan online untuk membuat perubahan tata letak dan logika dengan cepat dan kemampuan untuk menjalankan uji hipotesis dalam hitungan detik dan memproses hasil lebih cepat?

Pengembang seluler diajari untuk percaya bahwa kecepatan aplikasi dirilis dan diperbarui secara langsung berkaitan dengan seberapa cepat mereka sampai ke pengguna. Waktu moderasi App Store bisa sangat lama. Membangun Software Development Kit (SDK) akan lebih lambat karena Anda harus menyesuaikan kebutuhan Anda dengan siklus pengembangan dan rilis produk orang lain. Ini bisa menjadi alasan yang baik untuk tidak menguji hipotesis sama sekali.

Dalam posting blog ini, kami akan membahas topik dan memandu Anda melalui langkah-langkah Pengembangan Berbasis Backend, menjelaskan bagaimana itu digunakan untuk memecahkan masalah tertentu dan apa manfaatnya bagi kami. Bahan untuk posting ini diambil dari sumber pada contoh MoviePay. Penulis teks aslinya adalah Rodrigo Maximo.

Apa itu Pengembangan Berbasis Backend?

Pengembangan berbasis backend (atau Pengembangan Berbasis Backend, atau UI Berbasis Backend, atau UI Berbasis Server) adalah konsep pengembangan aplikasi front-end berdasarkan respons server. Layar dan aliran berubah berdasarkan respons server.

Sebagian besar pekerjaan membuat aplikasi seluler biasanya dikaitkan dengan membangun antarmuka pengguna: menempatkan elemen yang berinteraksi dengan pengguna di layar sehingga ia dapat dengan cepat melakukan satu atau lain tindakan. Beberapa komponen ini diisi dengan muatan API: biasanya JSON dengan tipe primitif (bilangan bulat, boolean, string) atau proses bisnis aplikasi.

Pendekatan tradisional untuk mengimplementasikan layar memiliki kelemahan tertentu, karena mungkin ada banyak logika bisnis di sisi aplikasi, dan kode menjadi lebih sulit untuk dipelihara:

  • Perlu kode yang sama untuk banyak platform (Android, iOS, Web, dll.). Pendekatan ini mempersulit pemeliharaan kompatibilitas lintas platform, yang meningkatkan kemungkinan bug dan ketidakcocokan;
  • Setiap pembaruan atau modifikasi aplikasi seluler menyiratkan kebutuhan untuk mengubah kode, yang mengarah pada rilis aplikasi yang diperpanjang di App Store;
  • Dalam digital, pengujian A/B lebih sulit. Lebih menantang untuk menguji konsep dan mengumpulkan data dari pengguna untuk memahami informasi produk yang penting;
  • Karena sebagian besar logika bisnis ada di sisi aplikasi, kode lebih menantang untuk dipelihara dan dipelihara.

Pengembangan berorientasi backend telah tiba untuk memecahkan masalah ini.

Pertimbangkan skenario berikut (yang didasarkan pada contoh aplikasi iOS tetapi dapat dengan mudah diterjemahkan ke proyek front-end lainnya):

Scenario for backend driven development

 {
    "pageTitle" : "Judul Demonstratif" ,
    "kotak" : [
        {
            "ketik ": "Biru Besar" ,
            “judul” : “Kotak yang bagus” ,
            “subtitle” : “Subtitle kotak} ,
        {
            "ketik ": "merah kecil" ,
            “title” : “Kotak yang bagus”
        } ,
        {
            "ketik ": "persegi panjangHijau" ,
            “title” : “Kotak yang luar biasa” ,
            “subjudul” : “Subjudul kotak,
            “angka” : 10
        }
    ]
}

Semua logika bisnis untuk menampilkan bidang dan menampilkan teks dan informasi visual dikonsolidasikan dan diabstraksikan di sisi server, menghilangkan kebutuhan akan banyak antarmuka untuk memproses API ini. Server kemudian menerapkan logika bisnis dan menggunakan hasilnya untuk menghasilkan respons API dalam format JSON.

Dalam contoh, untuk menampilkan blok di layar ("BigBlue", "smallRed" dan "rectangleGreen"), informasi tambahan dari setiap bidang digunakan. Menariknya, variabel "kotak" memungkinkan backend untuk memproses blok sebanyak yang diberikan server.

Apakah Anda mungkin sudah menebak bagaimana Anda dapat melakukan pengujian A / B dalam situasi ini? Server dapat memilih pengguna tertentu untuk hanya melihat blok "BigBlue", sementara yang lain dapat melihat ketiga jenis blok tersebut. Selain itu, Anda dapat melakukan pengujian A / B yang mengubah urutan tampilan blok di layar.

Kasus penggunaan lain untuk Pengembangan Berbasis Server adalah membuat perubahan pada antarmuka aplikasi. Misalnya, jika kita perlu mengubah header dalam aplikasi, cukup dengan mengubah respons server. Urutan tampilan subtitle dan blok juga mudah diubah. Dalam hal ini, Anda tidak perlu mempublikasikan rilis aplikasi baru di AppStore.

Making changes to the interface in backend driven development

 {
    "pageTitle" : "Judul Demonstratif" ,
    "kotak" : [
        {
            "ketik ": "persegi panjangHijau" ,
            “judul” : “Judul lain” ,
            “subjudul” : “Subjudul lain” ,
            “angka” : 100
        } ,
        {
            "ketik ": "merah kecil" ,
            “judul” : “Judul yang berbeda”
        }
        {
            "ketik ": "Biru Besar" ,
            “title” : “Didorong oleh Backend” ,
            “subjudul” : “Pengembangan”
        }
    ]
}

Berpikir dua kali

Ada beberapa hal yang perlu diingat saat menggunakan pendekatan Pengembangan Berbasis Backend. Pertama, tingkat fleksibilitas apa yang Anda butuhkan?

Berdasarkan pengalaman dan penelitian, kami menganggap fleksibilitas menengah sebagai yang optimal.

Anda tidak boleh terburu-buru dari satu ekstrem ke ekstrem lainnya. Sejumlah besar kebebasan dapat berdampak negatif pada pengembalian perkembangan Anda. Anda tidak dapat memperkirakan semuanya, terutama karena spesifikasi perangkat atau ukuran layar berada di luar kendali Anda. Akhirnya, Anda berakhir dengan logika presentasi sisi aplikasi yang sangat membingungkan dan kelebihan beban. Selain itu, Anda tidak dapat mengantisipasi semua yang mungkin ingin dilakukan tim desain Anda di masa mendatang. Jadi, Anda masih harus membuat perubahan pada kode aplikasi, dan, selama pengujian, banyak rute kompleks untuk mencapai tujuan akan ditemukan.

Jadi, kesimpulannya, Anda tidak memerlukan fleksibilitas yang dimiliki HTML di sebagian besar kasus. Oleh karena itu, sebelum mengembangkan solusi layar dan server yang menggunakan gagasan Pengembangan Berbasis Backend, kami menyarankan Anda untuk memikirkan semua opsi yang memungkinkan.

Pembuatan Aplikasi Super, Kasing Teknologi Bergerak

Anda mungkin akrab dengan konsep aplikasi super dan pernah mendengar tentang aplikasi seperti WeChat. WeChat adalah platform perpesanan seluler dan jejaring sosial yang dikembangkan di Tiongkok dan telah menjadi sangat populer di seluruh dunia.

Aplikasi semacam itu bertujuan untuk mengumpulkan beberapa layanan berulang di satu tempat dan menawarkan pengguna satu titik akses ke sebagian besar pertanyaan online dari kehidupan sehari-hari mereka. Ini adalah cawan suci pengembangan perangkat lunak: menyatukan banyak fungsi untuk membuat semuanya terlihat seperti die, menawarkan pengguna jawaban sederhana untuk pertanyaan kompleks dan solusi untuk masalah besar.

Di masa lalu, MovilePay telah terlibat dalam pengembangan aplikasi super, proses pengembangan versi yang lebih baik dijelaskan dalam artikel ini. Itu seharusnya menjadi pusat pengujian dan validasi di mana tim dapat menguji layanan baru dan menemukan kesamaan dalam penggunaannya.

MobilePay mengalami masalah saat membuat aplikasi yang dapat dengan cepat mengubah kode. Untuk itu diperlukan pengujian banyak layanan dan layanan dan melakukan penelitian tentang perilaku pengguna berdasarkan informasi yang ditampilkan dan pengujian hipotesis. MobilePay ingin dapat mengaktifkan dan menonaktifkan fitur dengan cepat. Dalam kondisi seperti itu, tidak mungkin menggunakan pendekatan tradisional dengan rilis untuk setiap perubahan. Mempertimbangkan semua poin ini dan skenario yang kompleks, diputuskan untuk menerapkan Pengembangan Berbasis Backend.

MobilePay membuat layar beranda berbasis kategori untuk mengatasi masalah ini. Setiap bagian memiliki kumpulan itemnya sendiri yang disebut widget. Bagian menampilkan titik masuk untuk layanan yang sudah diterapkan dalam urutan apa pun dan widget individual yang disorot.

Terkadang hanya satu layanan yang ditampilkan. Lain kali ada tiga, tergantung pada apa yang sedang diuji. MobilePay menyerahkan pilihan ke server daripada mengkodekan aturan apa pun ke dalam aplikasi. Akibatnya, aplikasi hanya mengetahui definisi titik masuk layanan dan cara merender setiap gaya tertentu. Server mereka memberi tahu layanan mana yang harus dibuat dan dalam urutan apa. Berikut beberapa widget yang dapat ditampilkan oleh aplikasi MobilePay.

Widgets that the MovilePay application

Widgets in MovilePay application

Widgets in MovilePay application

Widgets in MovilePay application

Jadi, untuk membuat layar beranda yang sangat mudah beradaptasi, kami harus mendapatkan respons dari backend dengan daftar bagian, masing-masing berisi daftar widget. Berikut ini adalah contoh respon JSON yang harus diurai oleh aplikasi MovilePay dan membuat home screen seperti contoh di bawah ini.

Parsing and creating a home screen

 [
    {
        "judul" : "Bagian 1" ,
        "widget" : [
            {
                "pengidentifikasi" : "COLLECTION_WIDGET" ,
                "isi" : [
                    {
                        "judul" : "Judul A" ,
                        "gambar" : "A" ,
                        "warna" : "kuning"
                    } ,
                    {
                        "judul" : "Judul B" ,
                        "gambar" : "B" ,
                        "warna" : "biru"
                    } ,
                    {
                        "judul" : "Judul C" ,
                        "gambar" : "C" ,
                        "warna" : "merah"
                    } ,
                    {
                        "judul" : "Judul D" ,
                        "gambar" : "D" ,
                        "warna" : "ungu"
                    } ,
                    {
                        "judul" : "Judul E" ,
                        "gambar" : "E" ,
                        "warna" : "hijau"
                    }
                ]
            } ,
            {
                "pengidentifikasi" : "IMAGES_WIDGET" ,
                "isi" : [
                    {
                        "gambar" : "Gambar" ,
                        "warna" : "hijau"
                    } ,
                    {
                        "gambar" : "Gambar" ,
                        "warna" : "biru"
                    } ,
                    {
                        "gambar" : "Gambar" ,
                        "warna" : "oranye"
                    }
                ]
            } ,
            {
                "pengidentifikasi" : "COLLECTION_WIDGET" ,
                "isi" : [
                    {"title" : "Judul E" , "gambar" : "E" , "warna" : "hijau" } , { "judul" : "Judul F" , "gambar" : "F" , "warna" : "ungu " } , { "judul" : "Judul G" , "gambar" : "G" , "warna" : "merah" } , { "judul" : "Judul H" , "gambar" : "H" , "warna " : "biru" } , { "judul" : "Judul H" , "gambar" : "H" , "warna" : "kuning" } ] } ] } , { "judul" : "Bagian 2" , "widget " : [ { "identifier" : "CELLS_WIDGET" , "content" : [ { "title" : "Cell 1" , "color" : "red" } , { "title" : "Sel 2" , "color" : "ungu" } , { "judul" : "Sel 3" , "warna" : "kuning" } , { "judul" : "Sel 4" , "warna" : "biru" } , { "judul" : "Sel 5" , "warna" : "hijau tua" } ] } ] } ]

Kami juga akan membahas beberapa layar yang mungkin dibuat menggunakan pengembangan berbasis backend.

Home screens in backend-driven development

Navigasi yang fleksibel

Aplikasi Super yang dikembangkan oleh MovielePay telah mencapai tujuan yang dimaksudkan untuk menjadi inovatif. MobilePay telah belajar banyak dari pengujian hipotesis, tetapi satu hal yang sangat mereka kuasai adalah pemrosesan pembayaran atau proses pembayaran untuk berbagai layanan dan produk. Mereka memiliki aplikasi pembayaran yang dapat memproses pembayaran untuk layanan apa pun yang mereka berikan. Kemampuan untuk mengelola transaksi pembayaran merupakan keuntungan yang signifikan, karena MobilePay dapat menurunkan harga dengan memproses beberapa transaksi dan memperoleh wawasan berharga tentang perilaku konsumen.

MobilePay memutuskan untuk mengembangkan SDK pembayaran berdasarkan model Google Pay, Apple Pay, atau VisaCheckout yang dapat diintegrasikan dengan aplikasi lain.

Namun, karena bekerja pada SDK menyiratkan sangat sedikit kemampuan untuk menguji menggunakan pola pengembangan yang khas, otomatisasi diperlukan.

Karena MobilePay menangani pembayaran, transformasi aliran menjadi sangat penting. MovilePay tidak bisa kehilangan penggunanya pada tahap corong konversi mana pun. Oleh karena itu, perlu mengoptimalkan seluruh proses bisnis — mulai dari pendaftaran pengguna hingga penambahan kartu dan pembayaran. Di sinilah Backend-Driven Development berguna lagi, mengubah server menjadi "navigator" aplikasi.

Optimizing the business process with BDD

Tak satu pun dari layar aplikasi MobilePay tahu layar mana yang berikutnya. Setelah layar sebelumnya menyelesaikan tugasnya, server bertanggung jawab untuk mengembalikan layar mana yang harus ditampilkan berikutnya.

Rute adalah tindakan yang dapat dikenali dan ditanggapi oleh aplikasi melalui struktur yang dikenal sebagai Router. Mekanisme login mencakup dua cabang tindakan terpisah: satu untuk judul halaman dan satu untuk elemen lain (seperti perubahan nama pengguna atau kata sandi baru) yang ditemukan di pohon tindakan. Router memprosesnya dengan mengirimkannya ke server, yang kemudian menginterpretasikan tindakannya dan menentukan interpretasi mana yang harus ditampilkan di layar berikutnya.

Pergeseran sederhana dalam strategi ini memungkinkan perampingan. MobilePay mencoba berbagai cara untuk menampilkan formulir pendaftaran. Itu mungkin untuk menguji apakah lebih baik untuk menampilkan layar checkout sebelum atau setelah menambahkan kartu. Misalnya, ini adalah salah satu alasan mengapa MovilePay mampu meningkatkan tingkat konversinya sebesar 30% dibandingkan dengan opsi pembayaran lainnya.

Contoh lain adalah bagaimana MovilePay menggunakan Pengembangan Berbasis Backend untuk menyelesaikan masalahnya. Kami pikir Anda luar biasaering bagaimana menerapkan pendekatan ini dalam praktek. Mari saya tunjukkan betapa mudahnya.

Ada banyak metode alternatif untuk mencapai tujuan yang sama. Kami akan menunjukkan kepada Anda bagaimana MobilePay melakukannya untuk iOS. Jika diinginkan, konsep ini dapat diterapkan ke platform front-end lainnya.

Ketika MovilePay mengimplementasikannya, mereka mempertimbangkan persyaratan seperti kemudahan menambahkan widget tambahan, keterbacaan kode, dan tanggung jawab tunggal. Untuk membuat segalanya lebih sederhana dan lebih asli, MovilePay memutuskan untuk menggunakan Codable API untuk serialisasi.

Widget (iOS)

Dalam hal fleksibilitas, MovilePay merasa bahwa solusi terbaik adalah dengan menggeneralisasi widget yang perlu diurai dengan protokol. MovilePay juga menetapkan enum untuk menentukan struktur widget mana yang akan mengurai data.

 Widget protokol : Dapat didekodekan { }

enum WidgetIdentifier : String , Dapat Diuraikan {
    spanduk kasus = "BANNER"
    koleksi kasus = "KOLEKSI"
    daftar kasus = "DAFTAR"

    var metatype : Widget . Ketik {
        beralih sendiri {
        kasus . spanduk :
            kembali BannerWidget . diri sendiri
        kasus . koleksi :
            kembali CollectionWidget . diri sendiri
        kasus . daftar :
            kembali ListWidget . diri sendiri
        }
    }
}

Mereka memanfaatkan Codable API melalui protokol Decodable yang diterapkan oleh protokol Widget. Di bawah ini adalah contoh pendefinisian struktur widget.

 struct BannerWidget : Widget {
    biarkan pribadi imageURLString : String
}

struct CollectionWidget : Widget {

    struct Item : Dapat Didekode {
        biarkan imageURLString : String
        biarkan judul : String
        biarkan subtitle : String
    }

    let sectionTitle : String
    biarkan daftar : [ Item ]
}

struct ListWidget : Widget {

    struct Item : Dapat Didekode {
        biarkan imageURLString : String
        biarkan teks : String
    }

    let sectionTitle : String
    biarkan daftar : [ Item ]
}

Akhirnya, itu didefinisikan sebagai penghapusan tipe, yang menafsirkan widget apa pun dengan metode inisialisasi yang diperlukan, ketika seseorang perlu mengubah inisialisasi khusus yang diberikan oleh Decodable.

 kelas akhir AnyWidget : Dapat Didekode {

    enum pribadi CodingKeys : CodingKey {
        pengenal kasus
    }

    biarkan widget : Widget ?

    init yang dibutuhkan ( dari decoder : Decoder ) throws {
        lakukan {
            biarkan wadah = coba dekoder . wadah ( keyedBy : CodingKeys . self )
            biarkan ketik = coba wadah . decode ( WidgetIdentifier . self , forKey : . identifier )
            diri . widget = coba ketik . metatipe . init ( dari : dekoder )
        } tangkap {
            diri . widget = nihil
        }
    }
}

Jenis penghapusan ini digunakan untuk mendekripsi pengidentifikasi Widget dan properti "tipe meta" untuk menentukan struktur widget mana yang harus digunakan untuk mengurai sisa data Widget yang diurai.

Semua ini menghasilkan struktur di bawah yang dapat mengurai respons yang berisi semua informasi tentang widget. Ini memiliki fitur unik: serangkaian jenis protokol Widget dan dapat mendekripsi setiap Widget menggunakan jenis penghapusan yang ditentukan di atas.

 struct HomeResponse : Dapat Didekode {

    enum pribadi CodingKeys : CodingKey {
        widget kasus
    }

    biarkan widget : [ Widget ]

    init ( dari decoder : Decoder ) melempar {
        biarkan wadah = coba dekoder . wadah ( keyedBy : CodingKeys . self )
        diri . widgets = coba wadah . decode ( [ AnyWidget ] . self , forKey : . widgetsss="tanda baca token">) . compactMap {$ 0. widget } } init ( widgets : [ Widget ] ) { self . widget = widget } }

MovilePay dapat memilih opsi lain, seperti tidak menggunakan protokol dan mengandalkan backend untuk mengembalikan larik dari setiap widget yang didukung untuk penguraian. Namun, kami menemukan bahwa pilihan protokol kami adalah pilihan terbaik untuk pemeliharaan dan keterbacaan. Pendekatan ini cukup untuk membuat struktur baru dan menambahkan kasus ke enum setiap kali diperlukan widget baru untuk dibuat. Dengan sistem yang berbeda dalam situasi yang sama, desain HomeResponse harus diubah.

Di bawah ini adalah kemungkinan respons JSON API yang akan diurai oleh model ini.

 {
    "widget" : [
        {
            "pengidentifikasi" : "BANNER" ,
            "imageURLString" : "url_image_to_be_downloaded"
        } ,
        {
            "pengidentifikasi" : "KOLEKSI" ,
            "sectionTitle" : "Judul Bagian" ,
            "daftar" : [
                {
                    "imageURLString" : "url_image_to_be_downloaded" ,
                    "title" : "Title item 1" ,
                    "subjudul" : "Subjudul item 1"
                } ,
                {
                    "imageURLString" : "url_image_to_be_downloaded" ,
                    "title" : "Title item 2" ,
                    "subjudul" : "Subjudul butir 2"
                } ,
                {
                    "imageURLString" : "url_image_to_be_downloaded" ,
                    "title" : "Title item 3" ,
                    "subjudul" : "Subjudul butir 3"
                }
            ]
        } ,
        {
            "pengidentifikasi" : "DAFTAR" ,
            "sectionTitle" : "Judul Bagian" ,
            "daftar" : [
                {
                    "imageURLString" : "url_image_to_be_downloaded" ,
                    "teks" : "Item teks 1"
                } ,
                {
                    "imageURLString" : "url_image_to_be_downloaded" ,
                    "teks" : "Item teks 2"
                } ,
                {
                    "imageURLString" : "url_image_to_be_downloaded" ,
                    "teks" : "Item teks 3"
                }
            ]
        } ,
        {
            "pengidentifikasi" : "BANNER" ,
            "imageURLString" : "url_image_to_be_downloaded"
        }
    ]
}

Pendekatan ini sangat mirip dengan pengembangan Super App, yang memungkinkan MovilePay untuk menyajikan layanan yang berbeda kepada pengguna yang berbeda, menguji banyak opsi tampilan, menyusun hipotesis, dan menentukan widget mana yang akan digunakan untuk layanan mana. Perubahan penyortiran layar dan pengelompokan layanan hampir sama dengan apa yang telah dilakukan MovielePay sebelumnya.

Navigasi (iOS)

Setelah memperbaiki masalah widget, MobilePay mencoba meningkatkan navigasi dengan cara yang sama. Mereka menciptakan protokol Action, yang identik dengan protokol Widget.

Tindakan adalah objek terstruktur yang dikembalikan dalam respons JSON dari beberapa API MobilePay, dengan ID dan parameter apa pun yang harus ditampilkan dalam adegan yang diwakilinya. Akibatnya, protokol Action bertanggung jawab untuk membantu mendekonstruksi objek terstruktur.

 Protokol Tindakan : Dapat Didekode {
    func scene ( ) - > UIViewController
}

enum ActionIdentifier : String , Dapat Diuraikan {
    kasus rumah = "HOME"
    kasus screenOne = "SCREEN_ONE"
    kasus screenTwo = "SCREEN_TWO"

    var metatipe : Tindakan . Ketik {
        beralih sendiri {
        kasus . rumah :
            kembali HomeAction . diri sendiri
        kasus . layarSatuoken operator">: kembalikan ScreenOneAction . self case . screenTwo : kembalikan ScreenTwoAction . self } } } lihat mentah

Satu-satunya perbedaan antara protokol Action dan protokol Widget adalah bahwa kami menyediakan metode yang mengembalikan adegan yang sesuai untuk setiap Action dalam definisi Action. Sebagai contoh, lihat bagaimana tindakan ini diterapkan.

 struct HomeAction : Tindakan {
    func adegan ( ) - > UIViewController {
        kembali HomeCoordinator . adegan ( )
    }
}

struct ScreenOneAction : Tindakan {
    biarkan judul : String

    func adegan ( ) - > UIViewController {
        kembali ScreenOneCoordinator . adegan ( title : self . title )
    }
}

struct ScreenTwoAction : Tindakan {
    biarkan judul : String
    biarkan subtitle : String

    func adegan ( ) - > UIViewController {
        kembali ScreenTwoCoordinator . adegan ( title : self . title , subtitle : self . subtitle )
    }
}

Contoh di atas menunjukkan bahwa, ketika dibuat, Actions harus berisi semua properti yang diperlukan untuk menginisialisasi adegannya dan untuk memanggil metode Coordinators untuk membuat instance UIViewController. Koordinator adalah struktur yang menyediakan UIViewController. Berikut adalah sesuatu untuk disebutkan: MovilePay menggunakan pola desain dalam struct Coordinators, yang diwakili oleh metode static scene() yang bertugas menghasilkan instance UIViewController untuk setiap tahap.

 Kelas akhir HomeCoordinator : Koordinator {
    adegan fungsi statis ( ) - > UIViewController {
        // Buat ViewController dan semua komponen arsitektur adegan ini...
        kembalikan ViewController yang dibuat
    }
}

kelas akhir ScreenOneCoordinator : Koordinator {
    adegan fungsi statis ( ) - > UIViewController {
        // Buat ViewController dan semua komponen arsitektur adegan ini...
        kembalikan ViewController yang dibuat
    }
}

kelas akhir ScreenTwoCoordinator : Koordinator {
    adegan fungsi statis ( ) - > UIViewController {
        // Buat ViewController dan semua komponen arsitektur adegan ini...
        kembalikan ViewController yang dibuat
    }
}

Perlu juga dicatat bahwa, terlepas dari pola desain arsitektur yang dipilih (MVC, MVP, MVVM-C, VIPER-C, VIP, atau arsitektur lain yang menggunakan koordinator untuk membuat adegan dan berpindah dari satu adegan ke adegan lainnya), implementasi menggunakan Action and Backend-Driven Development cukup tepat.

Untuk konteks Actions MoviePay, kami menggunakan jenis penghapusan yang sama seperti untuk widget, dengan sedikit adaptasi.

 kelas akhir AnyAction : Dapat Didekode {

    enum pribadi CodingKeys : CodingKey {
        pengenal kasus
    }

    biarkan tindakan : Tindakan ?

    init yang dibutuhkan ( dari decoder : Decoder ) throws {
        lakukan {
            biarkan wadah = coba dekoder . wadah ( keyedBy : CodingKeys . self )
            biarkan ketik = coba wadah . decode ( ActionIdentifier . self , forKey : . identifier )
            diri . tindakan = coba ketik . metatipe . init ( dari : dekoder )
        } tangkap {
            diri . aksi = nihil
        }
    }
}

Catatan penting di sini adalah bahwa MovilePay dapat menggunakan pola desain Generik untuk menghindari duplikasi kode penghapusan tipe. Namun, mereka memilih untuk tidak melakukannya. Berikut ini adalah contoh struktur yang berisi Action.

 struct ResponseModelForActions : Dapat Didekode {
    Enum pribadi CodingKeys"token operator">: CodingKey { case action , text } let action : Action ? let text : String init ( from decoder : Decoder ) throws { let container = try decoder . container ( keyedBy : CodingKeys . self ) self . teks = coba wadah . decode ( String . self , forKey : . text ) let anyAction = try ? wadah . decode ( AnyAction . self , forKey : . action ) self . tindakan = anyAction ?. tindakan } }

Ini bisa berupa JSON yang disediakan oleh API, misalnya, untuk membuat UIButton di layar. Objek tindakan yang ditangani setelah pengguna mengetuk tombol ini dapat melakukan tindakan yang disediakan, menyebabkan aplikasi menampilkan layar beranda.

 {
    "teks" : "Teks demonstratif" ,
    "aksi" : {
        "pengidentifikasi" : "HOME_SCREEN"
    }
}

Itu mudah dicapai dengan memperluas protokol Koordinator untuk memungkinkan semua koordinator mendapatkan adegan baru melalui objek Actions.

Ini memungkinkan koordinator untuk bertindak, yaitu, menghasilkan instance UIViewController berikutnya untuk tindakan itu dan kemudian menampilkannya.

 Koordinator ekstensi {
    func scene ( menggunakan action : Action ) - > UIViewController {
        tindakan kembali . adegan ( )
    }
}

Petunjuk tentang implementasi server

Anda mungkin bertanya-tanya seperti apa semua ini di sisi server. Bagaimana tidak membingungkan layanan dan kemampuan inti Anda dengan informasi eksternal? Rahasia sukses dalam pengembangan perangkat lunak adalah bekerja berlapis-lapis.

Jadi, selain semua layanan inti yang kompleks, MovilePay menambahkan lapisan lain ke server, yang, dengan mengabstraksi semua layanan lain dan menerapkan semua logika aplikasi, mengubah data menjadi respons yang diharapkan oleh frontend. Lapisan ini disebut BFF, atau Backend For Frontend adalah lapisan yang menyediakan komunikasi antara dua ujung sistem yang terpisah dan tidak berhubungan. Di sinilah string, gambar, aliran, dan variasi gaya dikonfigurasi dan diterapkan ke data yang mendasarinya sebelum mengirimnya ke aplikasi.

Kesimpulan

Menggunakan pendekatan Backend-Driven memiliki beberapa keuntungan, yang telah kami coba jelaskan di seluruh artikel. Namun, ini hanyalah templat solusi lain. Ini bukan pil ajaib untuk pengembangan aplikasi. Selain itu, konteks di mana aplikasi akan digunakan harus dipertimbangkan. Apakah Anda perlu membuat aplikasi untuk banyak platform? Jenis pengujian apa yang ingin Anda lakukan? Apakah Anda memerlukan kontrol penuh atas semua layar? Seberapa besar muatan Anda? Apakah Anda memiliki sumber daya yang cukup untuk melaksanakan proyek ini, termasuk tim pengembangan yang mampu menangani tugas-tugas ini?

Di atas segalanya, Anda harus selalu berhati-hati tentang tingkat fleksibilitas yang Anda butuhkan. Membuat komponen UI yang sangat serbaguna atau menggunakan font dan margin non-standar dapat membuat basis kode menjadi sangat kompleks, yang mengarah ke pengalaman pengguna yang lebih buruk.

Sebagian besar proyek tidak membutuhkan fleksibilitas semacam ini. Saat memilih pendekatan Berbasis Backend, penting untuk mempertimbangkan apakah Anda memiliki sumber daya dalam bentuk keuangan dan tim pengembangan untuk mengembangkan dan memelihara proyek semacam itu dan apakah Anda dapat menghitung muatan aplikasi Anda dengan benar.