Anda mungkin ingin memodulasi aplikasi iOS Anda, namun dalam beberapa kasus, segala sesuatunya bisa menjadi rumit. Dalam postingan ini saya akan menyajikan masalah paling umum yang saya alami saat memodulasi aplikasi iOS besar yang sudah ada, dan apa yang saya lakukan untuk menyelesaikan atau menghindarinya masalahnya.
Artikel ini sebagian besar akan membahas enkapsulasi, dependensi melingkar, gambar (paket), pbxproj dan ekstraksi dari bagian aplikasi yang sudah ada ke suatu kerangka kerja.
“Oke, jadi di mana aku akan membuat ini?”
Saat Anda memiliki kerangka kerja di aplikasi Anda, pertanyaan pertama yang mungkin muncul di benak Anda adalah “Di mana Anda akan menulis kode untuk fitur selanjutnya ini?”.
Seperti yang saya katakan di postingan sebelumnya tentang kerangka kerja, Anda harus mengkategorikan kerangka kerja Anda. Anda dapat memiliki satu kerangka kerja Inti, beberapa kerangka kerja fitur khusus, dan beberapa kerangka kerja teknis lainnya.
Jika fitur baru Anda atau apa pun yang akan Anda kembangkan tidak termasuk dalam kerangka kerja yang sudah ada apa pun, Anda mungkin ingin membuat kerangka kerja baru .
Tentukan pilihan Anda hati-hati karena pasti akan berdampak nantinya jika Anda ingin berubah atau berinteraksi dengan fitur baru ini .
“Publik, internal, pribadi ?”
Anda akan melihat ini muncul di depan hidung Anda! Ini karena Anda perlu mendeklarasikan kelas/struct Anda atau apa pun yang Anda definisikan dalam modul Anda dan ingin mengakses dari luar sebagai publik .
Saat mengembangkan aplikasi tanpa kerangka kerja, Anda biasanya tidak terlalu memperhatikan visibilitas atau kontrol akses karena semua yang ada di Swift secara default adalah internal. Internal berarti Anda dapat mengaksesnya di modul saat ini. Saat Anda mengembangkan sebuah modul, Anda perlu secara eksplisit mendefinisikan kelas yang ingin Anda gunakan dari luar sebagai publik.
Hal ini juga memaksa Anda untuk memiliki enkapsulasi kode yang lebih baik dan mendefinisikan struktur aplikasi Anda dengan lebih baik. Anda sebaiknya hanya menandai sebagai publik jenis yang ingin Anda dapat diakses dari luar kerangka kerja. Segala sesuatu yang lain setidaknya harus bersifat internal, atau bahkan pribadi jika ditujukan untuk penggunaan lokal.
Jadi jika Anda ingin membungkam kesalahan Xcode, cukup tandai kelas Anda sebagai publik.
“Mari kita impor kerangka kerja ini ke mana pun kita membutuhkannya!”
Ya tapi ! Saat bekerja dengan kerangka kerja Anda harus berhati-hati atau Anda akan menghadapi ketergantungan melingkar dan banyak sakit kepala. Di dalam kerangka kerja Anda, Anda tidak dapat mengimpor kerangka kerja kedua yang sudah mengimpor kerangka kerja pertama, secara langsung atau tidak langsung.
Selain itu, Anda mungkin menghadapi situasi ketika kerangka fitur (misalnya Akun) ingin mengetahui sesuatu tentang kerangka kerja lain (Pemesanan) untuk membuat tautan. Misalnya Anda ingin meluncurkan pencarian pemesanan berdasarkan preferensi Anda di bagian akun. Dari kerangka akun Anda ingin meluncurkan pencarian sehingga Anda mungkin ingin mengimpor kerangka kerja Pemesanan, namun hal tersebut salah karena akan mempertanyakan pemisahan kedua kerangka kerja ini.
Jadi bagaimana cara menangani tautan antara dua kerangka kerja yang tidak boleh saling mengimpor? Kasus ini merupakan pertanyaan yang menarik dan salah satu solusi adalah membuat jembatan antara kedua kerangka kerja, menggunakan pola yang dikenal sebagai POP (Pemrograman Berorientasi Protokol).
Solusi ini memerlukan postingan yang panjang untuk dijelaskan, jadi saya tidak akan membahasnya di sini tetapi pasti akan membahasnya di artikel lain.
“Aplikasi saya mogok saat memuat gambar!”
Hal ini akan menimbulkan masalah jika Anda mengekstraksi bagian yang sudah ada dari aplikasi Anda yang berisi banyak gambar. Setiap kerangka kerja memiliki paket sendiri, yang berarti jika Anda memasukkan gambar Anda ke dalam framework.xcassets dan memuat gambar Anda secara normal, di .xib atau .storyboard atau bahkan menggunakan #imageLiteral, pada akhirnya Anda akan mengalami crash seperti di bawah ini :
Aplikasi mogok karena paket yang digunakan oleh xibs, storyboards, atau imageLiterals adalah paket utama. Karena Anda mengembangkan kerangka kerja yang memiliki paketnya sendiri, sistem mencari aset gambar di paket yang salah.
Untuk mengatasi masalah ini, Anda harus menentukan paket untuk setiap gambar yang Anda gunakan dalam kerangka kerja ini. Berikut ini contoh yang dapat Anda lakukan:
Di sini Anda membuat kelas di dalam modul, hanya untuk menunjukkan ke Bundel init pada baris 6 bahwa Anda ingin menggunakan bundle dari kelas tersebut, yang merupakan paket kerangka kerja. Dengan mendefinisikan ekstensi Bundel ini, Anda dapat membuat gambar yang terletak di bundel kerangka kerja dengan menentukan dengan sangat mudah.
Mengenai xibs dan storyboard, saya pikir Anda harus mengatur sumber gambar di kode, karena lebih aman.
Jika Anda membuat modul baru dan belum memiliki gambar apa pun, jangan lupa untuk menentukan paket untuk gambar baru Anda.
“Saya ingin mengekspor sebagian aplikasi saya tetapi ketergantungannya terlalu kuat”
Saat saya mulai memodulasi bagian aplikasi yang sedang saya kerjakan, saya menemui dinding. Saya mencoba mengekspor sedikit layanan, yang sebenarnya menggunakan layanan lain, yang bergantung pada layanan lain… dan seterusnya.
Tidak mungkin mengekspor semua layanan ini ke kerangka kerja baru saya karena ketergantungan. Itu terlalu terikat dengan aplikasi utama, seperti jika Anda mencoba mengeluarkan mie dari piring mie, tetapi akhirnya mengangkat semuanya.
Jadi saya harus mencari tahu cara mengekspor layanan pertama saya tanpa mengambil seluruh hidangan mie.
Saya akan menjelaskan secara detail bagaimana saya berhasil melakukan ini di postingan lain, karena memerlukan penjelasan yang jelas, dan mungkin agak terlalu panjang untuk postingan ini.
“Konflik di pbxproj… sakit di leher!”
Ya itu ! Jika Anda adalah beberapa pengembang yang mengerjakan proyek, Anda akan dihadapkan pada neraka ini. Sayangnya, saya tidak punya solusi ajaib untuk masalah ini.
Setiap kali Anda membuat kerangka kerja baru atau memindahkan file ke target lain, atau pada dasarnya setiap Anda menyentuh
Namun, ada alat bernama XcodeGen yang dapat menjadi solusi untuk masalah ini. Anda dapat membaca lebih lanjut tentangnya di sini.
Sebagai kesimpulan, saya tidak punya solusi nyata untuk masalah ini namun perlu diingat bahwa jumlah konflik pada file ini hanya penting di awal pembuatan struktur kerangka kerja Anda. Setelah kerangka ditentukan Anda, semuanya akan berfungsi baik dan Anda tidak akan lagi mengalami mimpi buruk ini!
Anda dapat memeriksa proyek GitHub, yang menampilkan aplikasi iOS termodulasi, masalah dasar yang saya temukan di postingan ini, dan cara menanganinya (gambar dan paket misalnya).
Saya harap postingan ini dapat memberi Anda ikhtisar tentang masalah utama yang mungkin Anda temui saat memodulasi aplikasi iOS. Semua masalah ini dapat diatasi jadi lanjutkanlah! ;)
