14 hal yang harus diketahui pengembang iOS

Dengan izin penulis, saya memposting terjemahan artikel oleh Norberto Gil Vasconcelos "14 harus tahu untuk pengembang iOS" ( tautan ke yang asli ). Pada saat publikasi artikel, versi Swift 3 relevan.

Sebagai pengembang iOS (saat ini sangat tergantung pada Swift), saya membuat aplikasi dari awal, mendukung aplikasi, dan bekerja di berbagai tim. Selama saya bekerja di industri ini, saya sering mendengar ungkapan: "Anda tidak bisa menjelaskan, maka Anda tidak mengerti." Jadi, dalam upaya untuk memahami apa yang sebenarnya saya lakukan setiap hari, saya membuat daftar apa yang, menurut pendapat saya, penting untuk setiap pengembang iOS. Saya akan mencoba menjelaskan setiap momen sejelas mungkin. [Silakan koreksi saya, ungkapkan pendapat Anda, atau sarankan penambahan Anda ke daftar ini.]


Topik: [ kontrol versi | pola arsitektur | Objective-C vs Swift | Bereaksi | manajer ketergantungan | penyimpanan informasi | CollectionViews & TableViews | UI | protokol | sirkuit pendek | skema | tes | geolokasi | string yang dapat dilokalisasi ]


Ini daftar saya, tanpa basa-basi lagi, dalam urutan acak.

1 - Kontrol versi


Selamat, Anda diterima! Ekstrak kode dari repositori dan mulai bekerja. Hentikan apa?

Kontrol versi diperlukan untuk proyek apa pun, bahkan jika Anda hanya seorang pengembang. Sistem yang paling umum digunakan adalah Git dan SVN.

SVN didasarkan pada sistem kontrol versi terpusat. Ini adalah repositori tempat copy pekerjaan dibuat, dan untuk mengaksesnya Anda memerlukan koneksi jaringan. Otorisasi perubahan dilakukan dengan cara tertentu; sistem memonitor perubahan dengan mendaftarkan setiap file, sejarah penuh perubahan hanya dapat dilihat di repositori. Salinan kerja hanya berisi versi terbaru.

Gitmenggunakan sistem kontrol versi terdistribusi. Anda akan memiliki repositori lokal tempat Anda dapat bekerja, koneksi jaringan hanya diperlukan untuk sinkronisasi. Ketika copy pekerjaan diubah, keadaan seluruh direktori disimpan, tetapi hanya perubahan yang dibuat dicatat; Baik repositori dan copy pekerjaan memiliki riwayat perubahan lengkap.

2 - Pola arsitektur


Jari-jari Anda bergetar dengan kegembiraan, Anda tahu kontrol versi! Atau karena kopi? Sudahlah! Anda berada di ambang, dan saatnya telah tiba untuk pemrograman! Nggak. Apa lagi yang harus ditunggu?
Sebelum Anda duduk di keyboard, Anda harus memilih pola arsitektur yang akan Anda patuhi. Jika Anda belum memulai proyek, Anda harus cocok dengan pola yang ada.
Ada berbagai pola yang digunakan dalam pengembangan aplikasi seluler (MVC, MVP, MVVM, VIPER, dll.). Saya akan memberikan gambaran singkat tentang yang paling sering digunakan dalam pengembangan untuk iOS:

  • MVC — Model, View, Controller. Controller Model View, . View Controller , Controller . ? , View, (ViewController) . , MVC. MVC . ( !), , , Model, , . MVC , , iOS .


    MVC –
  • MVVMModel, View, ViewModel. ( ) View ViewModel, ViewModel , ViewModel, View - . ViewModel View, , .


    MVVM –


Untuk pemahaman dan informasi lebih lanjut tentang pola-pola lain, saya sarankan membaca artikel berikut .

Ini mungkin tidak tampak seperti itu, tetapi kode yang terstruktur dan terorganisir dengan baik dapat mencegah banyak sakit kepala. Kesalahan besar yang dilakukan oleh setiap pengembang pada satu titik adalah semata-mata untuk mendapatkan hasil yang diinginkan dan menolak untuk mengatur kode, secara keliru percaya bahwa ini menghemat waktu. Jika Anda tidak setuju, dengarkan Benji tua:
Setiap menit yang Anda habiskan untuk mengatur bisnis Anda menghemat satu jam

- Benjamin Franklin

Tujuan kami adalah untuk mendapatkan kode yang intuitif dan mudah dibaca yang akan mudah digunakan dan dipelihara.

3 - Objective-C vs Swift


Saat memutuskan dalam bahasa pemrograman mana untuk menulis aplikasi Anda, Anda harus tahu kemampuan apa yang dimiliki masing-masing. Jika memungkinkan, saya lebih suka menggunakan Swift. Mengapa? Sejujurnya, Objective-C memiliki sedikit keunggulan dibandingkan Swift. Sebagian besar contoh dan tutorial ditulis dalam Objective-C, dan Swift membuat penyesuaian terhadap paradigma dengan setiap pembaruan, yang bisa membuat kita sedih. Namun, masalah ini pada akhirnya akan hilang.

Dibandingkan dengan Objective-C, Swift membuat lompatan dalam banyak hal. Mudah dibaca, sepertinya bahasa Inggris alami, dan karena tidak dibangun di atas C, ini memungkinkan Anda untuk meninggalkan konvensi tradisional. Bagi mereka yang tahu Objective-C, ini berarti tidak ada lagi titik koma, dan pemanggilan metode dan kondisi ekspresi tidak perlu dimasukkan dalam tanda kurung. Juga lebih mudah untuk mempertahankan kode Anda: Swift hanya membutuhkan file .swift daripada file .h dan .m, karena Xcode dan kompiler LLVM dapat mendeteksi dependensi dan melakukan penambahan secara otomatis. Secara umum, Anda tidak perlu terlalu khawatir membuat kode standar, dan Anda akan menemukan bahwa Anda dapat mencapai hasil yang sama dengan lebih sedikit baris.

Masih ragu? Swift lebih aman, lebih cepat, dan menangani manajemen memori (sebagian besar!). Apakah Anda tahu apa yang terjadi di Objective-C ketika Anda memanggil metode dengan variabel pointer tidak diinisialisasi? Tidak ada. Ekspresi menjadi tidak aktif dan dilewati. Kedengarannya hebat, karena tidak menyebabkan crash aplikasi, tetapi menyebabkan sejumlah bug dan perilaku tidak stabil, karena itu Anda akan ingin berpikir tentang mengubah profesi Anda. Serius. Gagasan menjadi dog walker profesional berkilau dengan warna-warna baru. Pada saat yang sama, penghitung Swift bekerja dengan nilai opsional. Anda tidak hanya akan mendapatkan ide yang lebih baik tentang nil apa yang bisa dan mengatur kondisi untuk mencegah penggunaan nilai nil, tetapi juga mendapatkan crash runtime jika nil opsional masih digunakan, yang akan menyederhanakan debugging.ARC (penghitungan referensi otomatis) membantu Anda mengelola memori dengan lebih baik di Swift. Di Objective-C, ARC tidak bekerja dengan prosedural C atau dengan API seperti Core Graphics.

4 - Bereaksi atau tidak Bereaksi? (itu pertanyaannya)


Pemrograman reaktif fungsional (FRP) adalah hit baru. Ini dimaksudkan untuk menyederhanakan kompilasi operasi asinkron dan stream peristiwa / data. Untuk Swift, ini adalah abstraksi umum dari komputasi yang diekspresikan melalui antarmuka yang dapat diobservasi.

Cara termudah untuk menggambarkan ini adalah dengan kode kecil. Katakanlah bayi Timmy dan saudara perempuannya Jenny ingin membeli konsol game baru. Timmy menerima 5 euro dari orang tuanya setiap minggu, hal yang sama berlaku untuk Jenny. Namun, Jenny menghasilkan 5 euro lagi dengan mengirimkan surat kabar pada akhir pekan. Jika keduanya menghemat setiap sen, kami dapat memeriksa setiap minggu apakah konsol tersedia! Setiap kali nilai tabungan mereka berubah, nilai agregatnya dihitung. Jika ini cukup, pesan disimpan dalam variabel isConsoleAttainable. Kapan saja, kami dapat memeriksa pesan dengan berlangganan.

// 
let timmySavings = Variable(5)
let jennySavings = Variable(10)

var isConsoleAttainable =
Observable
.combineLatest(timmy.asObservable(), jenny.asObservable()) { $0 + $1 }
.filter { $0 >= 300 }
.map { "\($0)    !" }

//  
timmySavings.value = 10
jennySavings.value = 20
isConsoleAttainable
   .subscribe(onNext: { print($0) }) //   

//  
timmySavings.value = 100
jennySavings.value = 200
isConsoleAttainable
   .subscribe(onNext: { print($0) }) // 300    !

Ini hanyalah contoh dari apa yang dapat dilakukan dengan FRP, setelah Anda menguasainya, itu akan membuka dunia baru yang penuh kemungkinan, sampai mengadopsi arsitektur selain MVC ... Ya, ya! MVVM!
Anda dapat melihat dua pelamar utama untuk gelar ketua Swift FRP:


5 - Manajer ketergantungan


CocoaPods dan Carthage adalah manajer dependensi yang paling umum untuk proyek Cocoa Swift dan Objective-C. Mereka menyederhanakan proses penerapan perpustakaan dan menjaganya agar tetap terkini.

CocoaPods memiliki banyak perpustakaan yang dibangun menggunakan Ruby dan dapat diinstal menggunakan perintah berikut:

$ sudo gem install cocoapods

Setelah instalasi, Anda ingin membuat Podfile untuk proyek Anda. Anda dapat menjalankan perintah berikut:

$ pod install

atau buat Podfile khusus dengan struktur ini:

platform :ios, '8.0'
use_frameworks!

target 'MyApp' do
pod 'AFNetworking', '~> 2.6'
pod 'ORStackView', '~> 3.0'
pod 'SwiftyJSON', '~> 2.3'
end

Setelah dibuat, saatnya untuk menginstal modul baru Anda:

$ pod install

Sekarang Anda dapat membuka .xcworkspace proyek Anda, jangan lupa untuk mengimpor dependensi Anda.

Carthage adalah manajer ketergantungan yang terdesentralisasi, tidak seperti CocoaPods. Kerugiannya adalah semakin sulit bagi pengguna untuk menemukan perpustakaan yang ada. Di sisi lain, pendekatan ini membutuhkan lebih sedikit kerja dukungan dan menghindari gangguan karena penyimpanan terpusat.

Untuk informasi lebih lanjut tentang instalasi dan penggunaan, lihat proyek GitHub .

6 - Penyimpanan data


Mari kita mulai dengan cara termudah untuk menyimpan data untuk aplikasi Anda. NSUserDefaults , dinamakan demikian karena biasanya digunakan untuk menyimpan data pengguna default yang ditampilkan saat aplikasi pertama kali dimuat. Untuk alasan ini, ia dibuat sederhana dan mudah digunakan, tetapi ini juga menyiratkan beberapa keterbatasan. Salah satunya adalah jenis objek yang menerima metode ini. Perilakunya sangat mirip dengan Daftar Properti (Plist) , yang memiliki batasan yang sama. Berikut adalah enam jenis objek yang dapat mereka simpan:

  • NSData
  • NSDate
  • NSNumber
  • NSDictionary
  • Nsstring
  • NSArray

Untuk kompatibilitas dengan Swift, NSNumber dapat menerima jenis berikut:

  • UInt
  • Int
  • Mengapung
  • Dua kali lipat
  • Bool

Objek dapat disimpan di NSUserDefaults sebagai berikut (Pertama buat konstanta yang akan menyimpan kunci untuk objek yang disimpan):

let keyConstant = "objectKey"

let defaults = NSUserDefaults.standardsUserDefaults()
defaults.setObject("Object to save", objectKey: keyConstant)

Untuk membaca objek dari NSUserDefaults, kita dapat melakukan hal berikut:

if let name = defaults.stringForKey(keyConstant) {
   print(name)
}

Ada beberapa metode yang nyaman untuk membaca dan menulis ke NSUserDefaults yang menerima objek tertentu, bukan dari AnyObject.

Keychain adalah sistem manajemen kata sandi dan dapat berisi kata sandi, sertifikat, kunci pribadi atau catatan pribadi. Keychain memiliki dua tingkat enkripsi perangkat. Tingkat pertama menggunakan kode kunci layar kunci sebagai kunci enkripsi. Tingkat kedua menggunakan kunci yang dibuat dan disimpan di perangkat.

Apa artinya? Ini tidak sepenuhnya super aman, terutama jika Anda tidak menggunakan kata sandi pada layar kunci. Ada juga cara untuk mengakses kunci yang digunakan di tingkat kedua, karena disimpan di perangkat.

Solusi terbaik adalah dengan menggunakan enkripsi Anda sendiri. (Jangan menyimpan kunci pada perangkat)

CoreData- Ini adalah kerangka kerja yang dikembangkan oleh Apple sehingga aplikasi Anda berinteraksi dengan database secara berorientasi objek. Ini menyederhanakan proses dengan mengurangi jumlah kode dan menghilangkan kebutuhan untuk menguji bagian ini.

Anda harus menggunakan CoreData jika aplikasi Anda membutuhkan data persisten, ini sangat menyederhanakan proses menyimpannya dan memungkinkan Anda untuk tidak membuat / menguji cara Anda sendiri berkomunikasi dengan database.

7 - CollectionViews & TableViews


Hampir setiap aplikasi memiliki satu atau lebih CollectionViews dan / atau TableViews. Mengetahui cara kerjanya dan kapan menggunakan satu atau yang lain akan mencegah perubahan kompleks pada aplikasi Anda di masa mendatang.

TableViews menampilkan daftar item dalam satu kolom secara vertikal dan hanya dibatasi oleh pengguliran vertikal. Setiap item diwakili oleh UITableViewCell, yang dapat sepenuhnya dikustomisasi. Mereka dapat diurutkan berdasarkan bagian dan baris.

CollectionViews juga menampilkan daftar item, tetapi mereka dapat memiliki beberapa kolom dan baris (misalnya, kisi). Mereka dapat digulir secara horizontal dan / atau vertikal, dan setiap elemen diwakili oleh UICollectionViewCell. Seperti UITableViewCells, mereka dapat dikustomisasi sesuai keinginan dan diurutkan berdasarkan bagian dan baris.

Keduanya memiliki fungsi yang sama dan menggunakan sel yang dapat digunakan kembali untuk meningkatkan mobilitas. Pilihan yang Anda butuhkan tergantung pada kerumitan yang ingin Anda miliki dalam daftar. CollectionView dapat digunakan untuk mewakili daftar apa pun dan, menurut pendapat saya, selalu merupakan pilihan terbaik. Bayangkan Anda ingin mengirimkan daftar kontak. Daftarnya sederhana, Anda dapat menerapkannya dengan satu kolom, sehingga Anda memilih UITableView. Semuanya berfungsi! Setelah beberapa bulan, perancang Anda akan memutuskan bahwa kontak harus ditampilkan dalam format kisi, bukan daftar. Satu-satunya cara untuk melakukan ini adalah mengubah implementasi UITableView menjadi implementasi UICollectionView. Saya mencoba mengatakan bahwa walaupun daftar Anda mungkin sederhana dan UITableView mungkin cukup jika ada kemungkinan besar perubahan desain, mungkinyang terbaik adalah menerapkan daftar ini menggunakan UICollectionView.

Apa pun pilihan yang Anda buat, adalah ide bagus untuk membuat TableView / CollectionView generik. Ini memfasilitasi implementasi dan memungkinkan penggunaan kembali sejumlah besar kode.

8 - Storyboard VS Xibs VS UI yang dapat diprogram


Masing-masing metode ini dapat digunakan secara terpisah untuk membuat antarmuka pengguna, tetapi tidak ada yang mencegah Anda menggabungkannya.

Storyboard memberikan pandangan yang lebih luas tentang proyek yang akan disukai para desainer, memungkinkan Anda untuk melihat aliran aplikasi serta jendelanya. Kerugiannya adalah bahwa dengan penambahan lebih banyak jendela, koneksi menjadi lebih membingungkan dan waktu memuat Storyboard meningkat. Masalah penggabungan jauh lebih umum karena seluruh antarmuka pengguna dalam satu file. Mereka juga menjadi jauh lebih sulit untuk dipecahkan.

Xibsmemberikan tampilan visual jendela atau bagian jendela. Keuntungannya adalah kemudahan digunakan kembali, konflik penggabungan lebih sedikit daripada Storyboards, dan kemudahan melihat konten setiap jendela.

Memprogram antarmuka pengguna memberi Anda lebih banyak kontrol terhadapnya, mengurangi frekuensi konflik gabungan, jika muncul, konflik itu lebih mudah dihapus. Kerugiannya adalah kurang visualisasi dan waktu tambahan yang diperlukan untuk menulis.

Pendekatan di atas untuk membuat antarmuka pengguna sangat bervariasi. Tetapi, menurut pendapat subjektif saya, pilihan terbaik adalah kombinasi dari ketiganya. Beberapa Storyboard (sekarang kita dapat beralih di antara Storyboards!), Dengan Xibs untuk objek visual apa pun yang bukan jendela utama, dan, akhirnya, sedikit pemrograman untuk kontrol tambahan, sehingga diperlukan dalam situasi tertentu.

9 - Protokol!


Dalam kehidupan sehari-hari, ada protokol sehingga dalam situasi tertentu kita tahu bagaimana merespons. Misalkan Anda seorang pemadam kebakaran, dan keadaan darurat telah terjadi. Setiap petugas pemadam kebakaran harus mengikuti protokol yang menetapkan persyaratan untuk respons yang berhasil. Hal yang sama berlaku untuk protokol di Swift / Objective-C.

Protokol mendefinisikan sketsa metode, properti, dan persyaratan lain untuk fungsi yang ditentukan. Ini dapat diadopsi oleh kelas, struktur, atau enumerasi, yang kemudian akan memiliki implementasi aktual dari persyaratan ini.

Berikut ini adalah contoh membuat dan menggunakan protokol:

Sebagai contoh saya, saya akan membutuhkan enumerasi yang berisi daftar berbagai jenis bahan yang digunakan untuk memadamkan api.

enum ExtinguisherType: String {

   case water, foam, sand

}

Selanjutnya saya akan membuat protokol tanggap darurat.

protocol RespondEmergencyProtocol {

   func putOutFire(with material: ExtinguisherType)

}

Sekarang saya akan membuat kelas pemadam kebakaran yang mematuhi protokol.

class Fireman: RespondEmergencyProtocol {

    func putOutFire(with material: ExtinguisherType) {

       print("Fire was put out using \(material.rawValue).")

    }

}

Baik! Dan sekarang kita menggunakan pemadam kebakaran kita.

var fireman: Fireman = Fireman()

fireman.putOutFire(with: .foam)

Hasilnya harus sebagai berikut: "Api dipadamkan menggunakan busa."

Protokol juga digunakan dalam Delegasi. Ini memungkinkan kelas atau struktur untuk mendelegasikan fungsi tertentu ke instance dari tipe lain. Protokol dibuat dengan tanggung jawab yang didelegasikan untuk memastikan bahwa fungsinya sesuai dengan jenisnya.
Contoh kecil!

protocol FireStationDelegate: AnyObject {

func handleEmergency()

}

Petugas pemadam kebakaran mendelegasikan tindakan tanggap darurat petugas pemadam kebakaran.

class FireStation {
   weak var delegate: FireStationDelegate?

   func emergencyCallReceived() {
      delegate?.handleEmergency()
   }
}

Ini berarti bahwa petugas pemadam kebakaran juga harus mematuhi protokol FireStationDelegate.

class Fireman: RespondEmergencyProtocol, FireStationDelegate {

   func putOutFire(with material: ExtinguisherType) {
      print("Fire was put out using \(material.rawValue).")
   }

   func handleEmergency() {
      putOutFire(with: .water)
   }

}

Semua yang perlu dilakukan adalah agar petugas pemadam kebakaran yang dipanggil ditunjuk sebagai delegasi ke stasiun pemadam kebakaran, dan ia akan menangani panggilan darurat yang diterima.

let firestation: FireStation = FireStation()
firestation.delegate = fireman
firestation.emergencyCallReceived()

Hasilnya, kita mendapatkan: "Api dipadamkan dengan menggunakan air."

10 - Sirkuit pendek


Ini hanya tentang penutupan Swift. Mereka terutama digunakan untuk mengembalikan blok trailing atau dengan fungsi orde tinggi. Blok akhir digunakan, seperti namanya, untuk mengeksekusi blok kode setelah tugas selesai.
Penutupan di Swift mirip dengan blok di C dan Objective-C.

Penutupan adalah objek kelas pertama *, sehingga dapat disarangkan dan dilewati (seperti blok di Objective-C).

Dalam Swift, fungsi adalah kasus penutupan khusus.

Sumber - fuckingswiftblocksyntax.com **

Sumber daya ini adalah tempat yang bagus untuk mempelajari sintaksis penutupan.

* Objek kelas satu - objek yang dapat digunakan tanpa batasan: tetapkan ke variabel, lewati / kembali dari suatu fungsi, buat / hancurkan selama eksekusi program, dll. Lebih detail . (selanjutnya - sekitar penerjemah)
** Situs tidak berfungsi, tetapi masih ada gambar di waybackmachine, contohnya .


sebelas - Skema


Singkatnya, sirkuit adalah cara mudah untuk beralih antar konfigurasi. Mari kita mulai dengan informasi dasar. Ruang kerja berisi berbagai proyek terkait. Suatu proyek dapat memiliki berbagai target - target menentukan produk yang akan dirakit dan metode perakitannya. Juga, suatu proyek dapat memiliki berbagai konfigurasi. Skema di Xcode mendefinisikan kumpulan target untuk perakitan, konfigurasi yang digunakan selama perakitan, dan pengumpulan tes untuk dieksekusi.

Ungu menunjukkan satu kemungkinan pola.

12 - Tes


Jika Anda meluangkan waktu untuk menguji aplikasi Anda, Anda berada di jalur yang benar. Ini, tentu saja, bukan obat mujarab, Anda tidak dapat memperbaiki setiap bug, Anda juga tidak dapat menjamin bahwa aplikasi Anda akan bebas dari masalah apa pun; namun saya pikir pro lebih besar daripada yang kontra.

Mari kita mulai dengan kelemahan pengujian unit:

  • Peningkatan waktu pengembangan;
  • Tambah jumlah kode.

Pro :

  • Kebutuhan untuk membuat kode modular (untuk menyederhanakan pengujian);
  • Jelas mendeteksi sebagian besar bug sebelum rilis;
  • Penyederhanaan dukungan.

Dalam kombinasi dengan utilitas Tools , Anda akan memiliki segalanya untuk membuat aplikasi fleksibel dan berfungsi tanpa kesalahan dan kerusakan.

Ada banyak alat yang dapat Anda gunakan untuk menguji aplikasi Anda. Tergantung pada apa yang ingin Anda lacak, Anda dapat memilih satu atau lebih dari itu. Mungkin alat yang paling umum digunakan adalah Kebocoran , Time Profiler, dan Alokasi .

13 - Geolokasi


Dalam banyak aplikasi, beberapa fungsi memerlukan pencarian pengguna. Jadi alangkah baiknya jika memiliki gambaran umum tentang bagaimana lokasi itu bekerja untuk iOS.

Ada kerangka kerja yang disebut Core Location, yang memungkinkan Anda untuk mengakses semua yang Anda butuhkan:

Kerangka Lokasi Inti memungkinkan Anda untuk menentukan lokasi saat ini atau arah pergerakan suatu perangkat. Kerangka kerja menggunakan perangkat keras yang tersedia untuk menentukan posisi dan arah pengguna. Anda dapat menggunakan kelas dan protokol kerangka kerja ini untuk mengonfigurasi dan menjadwalkan acara yang terkait dengan lokasi dan arah. Anda juga dapat menggunakan Lokasi Inti untuk melacak perpindahan lintas wilayah geografis. Di iOS, Anda juga dapat menentukan jarak ke suar Bluetooth *.

* Seperti yang saya pahami, ini tentang teknologi iBeacon

Keren bukan? Lihatlah dokumentasi Apple dan contohnya di sana untuk lebih memahami kemampuan kerangka kerja.

14 - String yang dapat dilokalisasi


Apa yang harus diimplementasikan dalam aplikasi apa pun. Ini memungkinkan Anda untuk mengubah bahasa tergantung pada wilayah di mana perangkat berada. Meskipun aplikasi Anda hanya dalam satu bahasa, mungkin perlu menambahkan yang baru di masa mendatang. Jika semua teks dimasukkan menggunakan string yang dapat dilokalisasi, yang harus Anda lakukan adalah menambahkan versi terjemahan dari file Localizable.strings untuk bahasa baru.

Sumber daya dapat ditambahkan ke bahasa melalui inspektur file. Untuk mendapatkan string dengan NSLocalizedString, Anda perlu menulis yang berikut ini:

NSLocalizedString(key:, comment:)

Sayangnya, untuk menambahkan baris baru ke file yang dapat dilokalkan, ini harus dilakukan secara manual. Berikut adalah contoh struktur:

{
"APP_NAME" = "MyApp"
"LOGIN_LBL" = "Login"
...
}

Sekarang bahasa lain (Portugis), file yang dilokalkan:

{
"APP_NAME" = "MinhaApp"
"LOGIN_LBL" = "Entrar"
...
}

Bahkan ada cara untuk mengimplementasikan jamak.

Selalu bagikan apa yang telah Anda pelajari.

- Tuan Yoda

Semoga artikel ini bermanfaat!

All Articles