Geekly articles weekly

ICD Mobile Banking: Sejarah Pengembangan

Oleg Ivanov, Kepala Pusat Kompetensi Saluran Layanan Jarak Jauh, Departemen Pengembangan TI, Direktorat Teknologi Informasi, Moscow Credit Bank (ICD)

Bagi kami, pengembangan aplikasi seluler dimulai dari awal, jadi dalam artikel ini kita akan mulai dari awal: dengan menentukan apa itu dan fungsi apa yang seharusnya dimilikinya. Dan kemudian kita akan melangkah jauh - dari membeli gadget baru untuk menguji aplikasi hingga meluncurkannya. Kami akan menceritakan kisah pengembangan aplikasi kami dengan indentasi teknologi. Mari kita jelaskan masalah apa yang kami temui. Sayangnya, kami tidak akan dapat mencakup semua pendekatan, prinsip, dan solusi teknologi yang digunakan dalam pengembangan dalam artikel ulasan ini, tetapi kami akan membahas poin yang paling menarik.

Selanjutnya akan ada penekanan pada pengembangan untuk iOS. Sebelum Anda mulai, mari kita putuskan apa itu Mobile Bank.

Bank seluler adalah pengelolaan rekening bank yang menggunakan aplikasi bank pada telepon pintar (iPhone, dll.), Komputer tablet (iPad, Samsung Galaxy Tab, dll.). Untuk operasi perbankan, konfirmasi dua langkah diperlukan menggunakan kode satu kali melalui pesan SMS.

Operasi perbankan utama dari Mobile Bank:

  • penggunaan produk bank (rekening, kartu, deposito, pinjaman, paket layanan, dll.)
  • lihat saldo akun
  • pernyataan
  • pembayaran tagihan untuk layanan seluler
  • pembayaran layanan perumahan
  • transfer dana dari kartu ke kartu
  • pembayaran reguler
  • pembayaran kembali pinjaman
  • transfer dana ke deposito
  • kunci kartu pembayaran
  • dan lainnya.

Aplikasi mobile banking adalah aplikasi perbankan Internet yang disesuaikan untuk layar kecil smartphone dan untuk sistem operasi (Apple iOS, Google Android) yang diinstal pada perangkat mobile. Perlu dicatat bahwa rentang model perangkat yang menjalankan sistem operasi Android sangat luas: Samsung, LG, Xiaomi, Huawei, dll., Yang mempersulit pengembangan dan dukungan aplikasi untuk Android.

Sumber - MKBMobile 1.0


Proyek aplikasi Bank Seluler dipindahkan ke tim kami dari perusahaan pihak ketiga, ditulis dalam Objective C.

Ini adalah bagaimana proyek melihat melalui mata pengguna:





Proyek ini telah menjadi awal dan ujian bagi kemampuan kami. Tim kami memiliki beberapa pengalaman pengembangan untuk platform seluler iOS, tetapi kami dengan berani mengambil proyek tersebut.

Di mana untuk memulai? Ketika kami berpikir tentang pengembangan untuk iOS, hal pertama yang kami butuhkan:

1. Butuh iMac


Apple terkenal dengan harga produknya yang tinggi. Tetapi menabung tidak sepadan - ini adalah kecepatan perkembangan Anda!

Perkiraan, konfigurasi optimal yang sesuai dengan kami:

  • Prosesor Intel Core i5 generasi ketujuh dengan kecepatan clock 3,8 GHz (Turbo Boost hingga 4,2 GHz)
  • 32 GB DDR4 2400 MHz
  • 2 Drive Fusion TB
  • GPU Radeon Pro 580 dengan VRAM 8GB

Perkiraan biaya mesin tersebut adalah 190.000 rubel.

Ada pendapat - untuk Programmer perlu iMac Pro. Ini sangat :) Tapi harga untuk mereka menggigit, dan jika perusahaan Anda siap untuk membelinya, ini akan meningkatkan kecepatan perkembangan Anda, dan tentu saja, meningkatkan level estetika kantor Anda.

2. Membutuhkan perangkat iOS


"Berapa banyak dan yang mana?" - pertanyaan pertama muncul. Itu semua tergantung pada aplikasi Anda.
Jika aplikasi Anda hanya mendukung iPhone, setidaknya 2 ukuran berbeda kecil (mis. IPhone SE) dan besar (mis. IPhone 8 Plus).

Jika aplikasi Anda juga mendukung iPad, Anda memerlukan satu iPad.

Selanjutnya adalah sistem operasi - versinya. Jika aplikasi Anda mendukung versi minimum, misalnya, dimulai dengan iOS 8.0, Anda perlu menyimpan pada perangkat dengan setiap nomor seri iOS dan ingat untuk "mempertahankan" (jangan perbarui) versi ini pada perangkat dan memantau tampilan versi baru iOS, tidak lupa untuk memilih satu set untuk itu. perangkat.

Tentu saja, untuk pertama kalinya, Anda dapat bertahan dengan simulator Xcode, tetapi perangkat fisik memaksakan tabrakan mereka sendiri yang tidak muncul pada simulator.

Jika Anda tidak ingin memiliki tambak perangkat Anda sendiri, Anda dapat melihat ke pihak-pihak dari perusahaan yang menawarkan layanan ini: AWS Device Farm, Xamarin Test Cloud, dll.

Seperti yang telah disebutkan, aplikasi kami didukung untuk iPhone dan iPad. Pada saat penulisan, Farm (!) Kami sendiri adalah sekitar 30 perangkat dari berbagai jenis dan versi OS.

3. Anda perlu memutuskan pendekatan pengembangan untuk iOS (asli atau alternatif).


Kami mencoba opsi pengembangan alternatif berikut untuk iOS:

Phonegap / Cordova

PhoneGap pada awalnya dibuat oleh Nitobi. Pada 2011, Adobe mengakuisisi Nitobi dan merek PhoneGap. Adobe kemudian mentransfer satu versi PhoneGap, menyebutnya Cordova, ke Yayasan Apache, meninggalkan merek PhoneGap dan produk itu sendiri. Akibatnya, Cordova dapat dilihat sebagai mesin di bawah kap PhoneGap (serta beberapa kerangka kerja hybrid lainnya). PhoneGap, pada gilirannya, menambahkan fitur tambahannya sendiri pada kemampuan Cordova.

PhoneGap dalam banyak hal sangat mirip dengan Ionic. Ini juga memberi pengembang kemampuan untuk membuat aplikasi lintas platform menggunakan teknologi web, dan juga dibangun berdasarkan Apache Codova. Namun, PhoneGap tidak terikat pada kerangka Javascript tertentu, sehingga pengembang memiliki lebih banyak pilihan tentang apa dan bagaimana mereka akan membuat aplikasi mereka.

Sayangnya, PhoneGap menggunakan WebView (yang sangat lambat di iOS), sehingga hal-hal tidak selalu brilian dengan kecepatan aplikasi yang dibangun berdasarkan kerangka kerja ini.

Xamarin

Didirikan pada 2011, Xamarin, keluarga produk Xamarin, diakuisisi oleh Microsoft setelah lima tahun berdiri. Saat ini, produk Xamarin menghadirkan pendekatan yang sangat menarik untuk mengembangkan aplikasi mobile lintas platform di pasar: aplikasi ditulis dalam C #, kemudian Xamarin mengkompilasinya menjadi aplikasi asli untuk iOS atau Android, sedangkan Xamarin menggunakan Mono sebagai teknologi yang mendasarinya, dan bukan lintas platform. dan disediakan. Pengembang Xamarin mengatakan bahwa aplikasi yang dihasilkan menggunakan platform API asli untuk mana aplikasi dikompilasi, sehingga perilaku aplikasi yang dihasilkan tidak berbeda dari perilaku aplikasi lain pada platform yang sama. Pengembangan, omong-omong, dapat dilakukan dengan menggunakan Visual Studio (yang tidak mengejutkan).

Terlepas dari kenyataan bahwa sebagian besar kode proyek dapat digunakan tanpa perubahan pada setiap platform seluler yang didukung, namun, beberapa fragmen perlu ditulis secara khusus untuk versi aplikasi untuk iOS dan Android.

Tetapi pendekatan semacam itu memberikan apa yang disebut aplikasi "hibrid".

Plus dari opsi alternatif:

  • cross-platform (setelah membuat satu aplikasi, dapat diekspor untuk OS apa saja);
  • waktu pengembangan kurang dari asli.

Kontra dari alternatif:

  • bekerja lebih lambat dari aplikasi asli;
  • tidak memiliki akses penuh ke kemampuan teknis perangkat;
  • seringkali plugin yang ada sudah tidak digunakan lagi, jadi terkadang Anda harus menulis sendiri;
  • antarmuka pengguna divisualisasikan menggunakan browser bawaan, dan ini menciptakan kesulitan dalam memperoleh umpan balik dibandingkan dengan aplikasi asli;
  • tidak semua kontrol diterapkan.

Dan kami memutuskan untuk melanjutkan pengembangan "asli" proyek kami.

Cara Asli Apple

4. Pertama-tama, kita memerlukan alat untuk mengembangkan dan menulis kode - kita memerlukan IDE Xcode


Xcode adalah lingkungan pengembangan perangkat lunak terpadu (IDE) untuk platform macOS, iOS, watchOS, dan tvOS yang dikembangkan oleh Apple. Versi pertama diluncurkan pada tahun 2001. Versi stabil didistribusikan secara gratis melalui Mac App Store. Pengembang terdaftar juga memiliki akses ke versi beta melalui situs web Pengembang Apple.

Beginilah cara membuat dan bekerja pada aplikasi sederhana seperti Aplikasi Tampilan Tunggal di Xcode terlihat seperti:





Beberapa poin menarik tentang Xcode:

Xcode menawarkan toolkit yang sangat nyaman untuk membuat UI (antarmuka pengguna) - Storyboard.





Tetapi sebagian besar proyek (aplikasi) untuk iOS dilayani bukan oleh satu pengembang, tetapi oleh beberapa (tim pengembangan), dan ketika menggunakan satu Storyboard untuk semua layar aplikasi saat menggunakan sistem kontrol versi terdistribusi (SVN, Mercurial, GIT, dll.), Penggabungan perkembangan berubah menjadi neraka nyata.

Tim kami menyetujui pendekatan: satu Storyboard - satu ViewController .
Dengan pendekatan ini, masalah yang dijelaskan di atas menghilang, karena biasanya satu pengembang mengimplementasikan satu fitur, yaitu, semua layar dari fitur ini.

Untuk mengurangi beban di Storyboard saat menggunakan Segue, Anda dapat menggunakan fungsi 'Refactor to storyboard' . Refactoring storyboard ini menciptakan tautan di Storyboard induk, yang mengarah ke Storyboard baru yang terpisah, tempat ViewController yang diinginkan diimplementasikan.

Yang juga perlu diperhatikan adalah alat debugging dari Xcode - Breakpoint .
Breakpoint adalah alat debugging yang memungkinkan Anda untuk menghentikan sementara eksekusi program hingga titik tertentu. Itu akan memungkinkan kita untuk memeriksa kode program (mencari tahu nilai-nilai variabel saat ini, membuat beberapa perhitungan, dll.) Untuk mencari tahu di mana kesalahan terjadi.



Alat ini cerdas: kami memiliki tombol kontrol akses (Step Over, Step Into), memanipulasi yang kami navigasikan melalui kode kami. Kami juga memiliki akses untuk menganalisis nilai-nilai variabel dan bekerja dengan log di output konsol.
Ketika Kontrol-klik pada breakpoint indikator menampilkan menu perintah. Di sini Anda dapat mengatur kondisi tambahan untuk memicu breakpoint, menambahkan tindakan, dll.
Misalnya, kami menetapkan kondisi pemicu untuk breakpoint: langkah variabel akan mengambil nilai 4. Dan setelah aplikasi dimulai, program akan menghentikan eksekusi di breakpoint ini hanya ketika variabel langkah mengambil nilai 4 dan tidak lebih awal.



Kami dapat menambahkan Ekspresi tambahan (properti dan bahkan perhitungan!).

5. Anda harus memutuskan bahasa pemrograman Objective-C atau Swift baru


Proyek yang kami dapatkan ditulis dalam Objective-C, tetapi bahasa pemrograman Swift yang baru sudah ada di cakrawala.

Apa bahasa pemrograman ini?

Objective-C adalah kompilasi, bahasa pemrograman berorientasi objek yang digunakan oleh Apple, dibangun berdasarkan bahasa C dan paradigma Smalltalk. Secara khusus, model objek dibangun dalam gaya Smalltalk - yaitu, pesan dikirim ke objek.

Bahasa Objective-C ada sejak 1989, terakhir kali diperbarui pada 2006, lebih
10 tahun yang lalu. Popularitas iOS terus meningkat, yang membutuhkan peningkatan kualitas aplikasi. Untuk bekerja dengan Objective-C, diperlukan pengembang yang sangat terampil.

Semua ini menjadi prasyarat untuk penciptaan bahasa pemrograman Swift.

Apple mulai mengembangkan Swift pada 2010. Pada 2 Juni 2014, bahasa ini secara resmi diluncurkan di Apple Worldwide Developer Conference (WWDC). Panduan 500 halaman gratis untuk menggunakannya tersedia di iBook Store.

Swift 1.0 dirilis pada 9 September 2014 bersama dengan Gold Master versi Xcode 6.0 untuk iOS.
Pada 8 Juni 2015, Apple merilis versi baru Swift 2.0 dengan peningkatan kinerja dan API penanganan kesalahan baru. Sintaks bahasa telah meningkat, fungsi untuk memeriksa ketersediaan fungsi Swift untuk OS target telah muncul.

Pada 3 Desember 2015, versi beta dari Swift 3.0 dirilis dengan dukungan untuk OS X, iOS, dan Linux, dilisensikan di bawah lisensi open source Apache 2.0.

Pada 19 September 2017, Swift 4.0 dirilis.

Pada bulan September 2018, bersama dengan versi baru iOS 12, versi stabil baru bahasa Swift 4.2 dirilis, dan versi beta Swift 5.0 muncul. Versi 5.0 akhirnya mengumumkan operasi stabil ABI dengan perpustakaan standar (Swift Dynamic Library), dukungan untuk ekspresi reguler dan solusi kelas satu untuk pemrosesan data paralel dengan mode pemrosesan async / menunggu.

Berdasarkan hal tersebut di atas, kami memutuskan untuk hanya menggunakan Swift dalam bentuk baru, untuk mendukung bentuk lama, secara bertahap menulis ulang.

6. Selanjutnya, Anda perlu memahami arsitektur proyek - kami memutuskan untuk meninggalkan arsitektur MVC dari Apple


Model-View-Controller (MVC) memberikan satu dari tiga peran ke objek dalam aplikasi: model, view, atau controller. Arsitektur tidak hanya menentukan peran yang dimainkan objek dalam aplikasi, tetapi juga cara objek berinteraksi satu sama lain. Masing-masing dari tiga jenis objek dipisahkan dari yang lain oleh perbatasan abstrak dan berinteraksi dengan objek dari jenis lain melalui perbatasan ini (https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html).



Namun, dengan menerapkan pendekatan ini, kami menghadapi masalah berikut, yang hanya dapat kami selesaikan dengan beralih ke arsitektur baru di MKBMobile 3.0:

  • MVC tidak memberikan instruksi yang jelas tentang entitas dan kelas mana yang perlu Anda buat dan yang tidak. Struktur dan arsitektur model, serta interaksinya dengan pengontrol, tetap sepenuhnya pada hati nurani dan imajinasi pengembang.
  • Pemahaman yang buruk tentang area domain. Yaitu ketika pengembang menambahkan fungsionalitas baru, alih-alih membuat entitas baru dan refactoring arsitektur yang ada, fungsionalitas baru ditambahkan ke ViewController. Yang menyebabkan masalah berikut: Massive View Controller - banyak kode di dalam ViewController.

7. Dan yang paling manis adalah iOS SDK (https://developer.apple.com/documentation/)


IOS SDK menyediakan sejumlah besar Kerangka.

Kami menggunakan daftar kerangka kerja berikut dengan antusiasme khusus dalam aplikasi perbankan:

  • PushKit dan UserNotification untuk bekerja dengan pemberitahuan push;
  • PassKit untuk bekerja dengan Apple Pay;
  • CallKit (bersama dengan WebRTC) untuk bekerja dengan layanan VoIP;
  • AVFoundation untuk bekerja dengan sumber daya audio;
  • Kontak untuk mendapatkan akses ke kontak pengguna;
  • CommonCrypto untuk bekerja dengan fungsi kriptografi.

Jadi, kami telah memutuskan yang diperlukan, kami ditagih dan siap untuk pencapaian ...

Untuk beberapa waktu, fitur-fitur baru (fungsi - transfer baru, pembayaran, produk bank (kartu, pinjaman, dll.) Dibangun dengan baik ke dalam aplikasi.

Tetapi kemudian aplikasi menjadi rumit dan tidak nyaman .

Jadi proyek MKBMobile 2.0 muncul dengan ide antarmuka yang berani - Trello Pages.

Pendekatan Halaman Trello, pada kenyataannya, adalah papan yang terpasang di bagian atas layar, dalam versi kami, ke bilah navigasi atas. Pendekatan ini memungkinkan Anda membuat navigasi cepat antar papan (halaman).




Keuntungan dari pendekatan ini:

  • skalabilitas, ruang tak terbatas kiri / kanan dan bawah;
  • keterpisahan, setiap jenis fungsi ditempatkan pada halaman terpisah;
  • Sempurna untuk iPad dan iPhone.

Tetapi ada beberapa kelemahan dari ide ini:

  • Item menu navigasi teratas sulit diakses;
  • pemberitahuan push masuk dan pemberitahuan SMS menciptakan kesulitan tambahan dalam bekerja dengan menu navigasi atas;
  • pendekatan ini tidak sesuai dengan Panduan Antarmuka Manusia Apple.

Jadi versi terbaru dari mobile bank ICD, MKBMobile 3.0, lahir.

Dalam versi ini, kami telah mengadopsi model navigasi klasik dari Apple HIG (Human Interface Guidelines) TabBar bawah.





Pindah ke versi ini, kami telah memperoleh banyak pengalaman negatif menggunakan arsitektur MVC klasik Apple.

Tim kami tumbuh, dan kami membutuhkan ambang rendah bagi karyawan baru untuk memasuki proyek.
Plus, satu hal lagi yang tidak mengganggu kita: pengujian unit terhadap perilaku elemen grafik, yang pengujiannya digunakan melalui Xcode UI Test, yang merupakan proses panjang meluncurkan aplikasi pada emulator (perangkat) dengan emulasi tindakan pengguna.

Semua persyaratan ini menghasilkan penggunaan pendekatan arsitektur baru - VIPER.
Model VIPER klasik:



Tetapi, setelah melihat banyak pendekatan dalam mengimplementasikan VIPER untuk iOS, kami memutuskan pada solusi Rambler & Co dengan penyimpangan kami.

Sebagai dasar kami menempatkan buku dari Rambler & Co.



Tugas utama yang membantu VIPER kami pecahkan:

  • partisi kelas besar (Pengendali Tampilan Masif) dengan batas tanggung jawab yang kurang lebih jelas;
  • penerapan prinsip-prinsip SOLID dalam semua kemuliaan mereka;
  • ambang rendah untuk karyawan baru yang memasuki proyek;
  • Pengujian unit UI.

Penting untuk segera dicatat bahwa VIPER tidak berarti seperangkat template dan aturan yang ketat. Sebaliknya, ini adalah daftar rekomendasi, berikut ini Anda dapat membangun arsitektur aplikasi seluler yang fleksibel dan dapat digunakan kembali.

Seperti apa proyek kami mulai terlihat:



Struktur modul VIPER dalam implementasi kami:

1. Yang paling "utama" adalah kelas Modul, ia tahu segalanya tentang semua orang, menciptakan objek layanan yang diperlukan untuk Interactor, tahu cara menghubungkan semua bagian di antara itu sendiri. Lihat, Router, Presenter, dll.



Ini juga menyediakan komunikasi dengan VIPER-modul lainnya melalui protokol input dan output ModuleInput dan ModuleOutput.

Protokol input dan output yang serupa memiliki semua bagian modul VIPER (View, Router, Presenter, dll.).

Kami sepakat: jika tidak perlu protokol atau bagian modul VIPER, kami tidak menggunakannya dan tidak menyediakan kelas kosong untuknya.

2. Interactors (Interactor) - menyembunyikan logika bisnis.

Kami telah memperkenalkan lapisan layanan tambahan. Layanan - objek yang bertanggung jawab untuk bekerja dengan tipe data spesifiknya. Misalnya, layanan sistem bantuan bertanggung jawab untuk direktori (file perjanjian, perincian, dll.)

3. Presenter – View Router, Interactor, Interactor, View .

4. Router – .

5. View – Presenter . , , Presenter.

.

VIPER-. , : , , , .

– API , . (Parent View), (View) .





iOS . .




:

  • SwiftLint, Realm Swift-;
  • CI fastlane;
  • Instruments Xcode(Allocations, Leaks, Zombies . .)

! !

Source: https://habr.com/ru/post/id467057/

More articles:


All Articles