Pengembang seluler harus memiliki keterampilan yang jelas. Anda perlu membicarakannya dalam konteks tugas spesifik yang muncul selama pembuatan dan publikasi aplikasi. Arthur Antonov bekerja sebagai pengembang iOS di departemen terjemahan mesin Yandex. Dalam laporannya untuk siswa dan pemula, Arthur menjelaskan apa yang harus dapat dilakukan pengembang untuk membuat perangkat lunak seluler modern.- Ada dua aplikasi seluler di departemen kami: Yandex.Translate dan Yandex.Keyboard. Di Translator kami memiliki banyak teknologi canggih, misalnya input suara, pengenalan teks dengan foto, terjemahan teks menggunakan jaringan saraf. Tantangan terpisah adalah mempertahankan fungsi ini secara offline. Artinya, fungsi ini akan bekerja untuk Anda bahkan tanpa internet.
Keyboard adalah kelas aplikasi yang terpisah, ada persyaratan terpisah untuk kecepatan dan kualitas aplikasi itu sendiri. Koreksi otomatis dalam bahasa Rusia berfungsi untuk kami: membantu pengguna, tetapi tidak mengganggunya. Input suara, geser input.
Fitur keren yang terpisah adalah grid dinamis: ia mencoba untuk memprediksi huruf berikutnya dan, tergantung pada ini, mengubah tabson. Artinya, lebih mudah masuk ke surat yang lebih mungkin.
Di sekolah saya terlibat dalam pemrograman olahraga. Tetapi ketika saya memasuki universitas, bagi saya terasa agak membosankan, saya ingin mengembangkan program untuk orang-orang biasa, dan diharapkan bahwa mereka selalu tersedia dan di mana-mana. Jadi saya memutuskan untuk memilih pengembangan ponsel. Tetapi aplikasi seluler memiliki banyak segi, dan pertanyaan terbesar yang muncul sebelum saya adalah dari mana harus memulai.Internet sekarang penuh dengan kursus online, tutorial, buku tentang berbagai topik, dan kepala meledak begitu saja. Tidak jelas harus mulai dari mana. Karenanya, dalam laporan saya, saya ingin membantu Anda membangun jalur pembelajaran untuk menjadi pengembang seluler. Apa yang layak dipelajari di awal, studi tentang apa yang bisa ditunda.
Setelah menganalisis pekerjaan saya selama beberapa tahun, saya mengidentifikasi beberapa keterampilan utama yang diperlukan untuk menyelesaikan sebagian besar masalah. Ini adalah keterampilan mendasar dan keterampilan kotak alat. Mereka tidak diperlukan saat mengembangkan aplikasi mobile, tetapi jika Anda memilikinya, maka hidup Anda akan menjadi lebih mudah, dan kualitas aplikasi Anda akan jauh lebih baik.Karena teori tanpa praktik sudah mati, kami akan mempelajari keterampilan menggunakan contoh versi Yandex.Translator yang disederhanakan. Ketika Anda telah menyelesaikan proyek, yang Anda lihat hanyalah layar putih.Mari kita menghidupkan kembali aplikasi kita menggunakan UI.
Ada dua cara klasik untuk membuat antarmuka - editor grafis dan kode. Ini adalah salah satu topik hollywood mereka dalam pengembangan ponsel. Ada penganut perkembangan dalam editor grafis, dan seseorang tidak mengenali apa pun kecuali kode. Tetapi saya menyarankan Anda untuk mencoba kedua metode ini. Anda pasti akan menemukan mereka, dan di samping itu, tidak ada yang melarang Anda untuk menggabungkan pendekatan, misalnya, hal-hal sederhana yang harus dilakukan dalam editor grafis, dan yang kompleks sudah ada dalam kode.
Dan baru-baru ini, pengembang iOS memiliki kerangka kerja SwiftUI baru yang mencoba menggabungkan kedua pendekatan ini. Artinya, ketika mengubah editor grafis, kode Anda berubah dan sebaliknya. Mungkin ketika kerangka kerja ini meluas, semua perselisihan akan terlupakan.Sayangnya, SwiftUI hanya tersedia mulai dengan iOS 13, sehingga tidak dapat digunakan dalam proyek besar sejauh ini.
Editor grafis memiliki antarmuka yang sangat sederhana. Kami mengambil komponen yang sudah jadi, menyeretnya ke layar virtual dan segera melihat apa yang kami dapatkan. Untuk alasan ini, sangat cepat untuk membuat komponen UI sederhana. Kami juga dapat mengubah ukuran layar virtual untuk berbagai perangkat dan menguji antarmuka kami tanpa meluncurkan aplikasi.
Di sisi lain, kami memiliki desain antarmuka dalam kode. Saat mengembangkan antarmuka dalam kode Anda, perpustakaan UIKit akan berguna, dan Anda akan menggunakan blok bangunan kecil dari itu yang disebut UIView. Objek UIView kurang lebih sesuai dengan komponen apa yang telah Anda tampilkan di layar. Dan seperti dalam editor grafis, Anda memiliki subclass siap pakai untuk komponen yang umum digunakan, seperti tombol dan teks.Ketika mengembangkan kode, sangat penting untuk memahami bahwa UIViews lain dapat membuat UIView dalam diri mereka sendiri, yaitu, Anda dapat membangun antarmuka dengan kompleksitas apa pun. Akibatnya, Anda mendapatkan apa yang disebut pohon. Lebih mudah untuk memodifikasi dari kode. Artinya, jika Anda memiliki antarmuka pengguna yang sangat dinamis, maka mungkin ada baiknya menuliskannya dalam kode dan akan lebih mudah bagi Anda untuk memodifikasinya nanti.
Mari kita lihat kode apa yang bisa ditulis untuk penerjemah kami.Pertama-tama kita mengatur warna latar belakang menjadi kuning. Kemudian kami menambahkan bidang input tempat pengguna memasukkan teks dalam bahasa Inggris. Selanjutnya, kami menambahkan pemisah untuk kecantikan dan, akhirnya, menambahkan bidang output, sambil melarang pengguna mengeditnya.Kami memiliki antarmuka pengguna yang siap, tetapi aplikasi ini masih agak tidak berguna. Itu tidak menyelesaikan tugas utama pengguna - terjemahan teks.Mari kita tambahkan fungsi ini. Kemampuan platform SDK akan membantu kami.
Platform SDK adalah seperangkat alat dan perpustakaan untuk membuat aplikasi seluler yang disediakan untuk kami oleh Apple dan, karenanya, Google.Saat ini, SDK memiliki banyak perpustakaan tingkat rendah untuk berinteraksi dengan sistem operasi, dan Anda dapat menerapkan hampir semua gagasan aplikasi seluler tanpa banyak usaha.Perpustakaan mana yang akan Anda gunakan tergantung pada spesifikasi aplikasi Anda. Misalnya, jika kami ingin membuat kamera, maka kemungkinan besar Anda akan membutuhkan dua perpustakaan: AVFoundation untuk bekerja dengan kamera dan CoreImage untuk pemrosesan gambar.Oleh karena itu, pada tahap ini tidak perlu untuk menghafal semua perpustakaan, itu tidak mungkin. Lebih penting adalah kemampuan untuk menemukan alat yang tepat. Dan sayangnya, dokumentasi resmi tidak selalu sepenuhnya mendokumentasikan fitur. Terkadang Anda menemukan beberapa hal menarik, misalnya, di blog atau di twitter pengembang lain. Layak mengikuti bidang informasi.Jadi, apa yang kita butuhkan dari SDK untuk penerjemah kita?
Penerjemah kami adalah aplikasi klien-server klasik: kami membuat permintaan ke server dan mendapat tanggapan. Lalu kami entah bagaimana mengubahnya dan menunjukkannya kepada pengguna. Kerangka kerja Yayasan akan membantu kita untuk tugas ini. Ini berisi abstraksi yang mudah digunakan untuk menyelesaikan tugas sehari-hari.Kami akan mengambil kelas URLSession darinya, ini adalah kelas untuk bekerja dengan server menggunakan protokol http, dan JSONSerialisasi, ini adalah kelas yang membantu kami mengonversi objek dari format JSON.
Jadi, mari kita lihat kode apa yang perlu kita tulis untuk fungsi ini. Di sebelah kiri adalah metode yang dijalankan setiap kali input pengguna diubah. Kami pertama-tama membuat URL dengan alamat server penerjemah dan membuat permintaan. Selanjutnya, setelah kami menerima jawabannya, kami mem-parsing dari format JSON, kami mendapatkan teks yang diinginkan darinya, yaitu teks terjemahan. Dan langkah terakhir - kita katakan bahwa di bidang input Anda perlu mengatur jawaban yang diterima.Mari kita lihat apa yang kita dapat. Pengguna memasukkan hello dan "hello" muncul:
Tapi "halo" muncul entah bagaimana untuk waktu yang lama, sepertinya jaringan tidak tertinggal. Untuk keandalan, mari kita bandingkan dengan kakak laki-laki:Di kedua aplikasi, kami memasukkan teks halo dan melihat bahwa terjemahan sudah muncul beberapa kali pada penerjemah asli. Pada penerjemah kami, terjemahan muncul dengan hang besar.Untuk memperbaiki masalah ini, kita perlu berkenalan dengan model multithreading dalam aplikasi mobile.Sama seperti desktop, aplikasi seluler dijalankan di lingkungan multi-utas. Tetapi ada batasan penting. Aplikasi seluler memiliki utas utama atau yang disebut utas UI. Dan operasi apa pun dengan UI, setiap perubahan di UI harus terjadi di utas utama ini. Jika Anda ingin mengubah warna tombol atau memindahkannya - semuanya harus berada dalam aliran UI.Di sisi lain, semua interaksi pengguna juga mendatangi kami di utas utama. Artinya, pengguna mengklik tombol - kami menerima pesan di utas utama. Mengubah teks, seperti dalam kasus kami - kami juga mendapatkannya di utas utama. Karena hanya ada satu aliran dan semua tindakan dengan UI terjadi di dalamnya, sangat penting untuk menjaganya dan melakukan perhitungan sesedikit mungkin, jika tidak Anda berisiko berada dalam situasi di mana Anda memproses tindakan pengguna untuk waktu yang lama dan Anda memiliki antrian dari tindakan pengguna lain. Kemudian semuanya mulai membeku.Karena alasan ini, banyak pustaka sistem secara default berjalan pada aliran latar belakang. Misalnya, perjalanan ke jaringan membutuhkan rata-rata 100 hingga 500 milidetik. Ini adalah operasi yang cukup mahal untuk aliran utama, sehingga semua interaksi dengan jaringan berlangsung pada aliran latar belakang.Dan lagi, ini menciptakan masalah bagi kita, karena jika kita secara tidak sengaja menggunakan hasil yang diperoleh dari server segera untuk mengubah antarmuka pengguna, ini dapat menyebabkan crash atau crash.Ingat baris terakhir kami:self.textOutputView.text = translation
Di dalamnya, kami mengambil hasil dari server dan mengaturnya di bidang output. Jadi, kami melanggar aturan pertama - kami mengubah UI bukan dari utas utama. Perpustakaan standar Grand Central Dispatch akan membantu memperbaikinya. Ini cukup mudah membantu kita beralih ke utas utama dan melakukan tindakan ini pada utas utama.DispatchQueue.main.async {
self.textOutputView.text = translation
}
Mari kita lihat apa yang kita dapatkan dengan aplikasi pada akhirnya.
Pengguna memasukkan teks, dan kami melihat bahwa terjemahan terjadi hampir secara instan. Hore! Kami mengalahkan masalah ini. Tapi, sebelum merilis aplikasi, mari kita bicara tentang topik penting lainnya - arsitektur.Sayangnya, pada proyek saat ini saya tidak akan dapat menunjukkan pentingnya arsitektur untuk Anda, masih sangat kecil.
Tapi, saya jamin, arsitektur tidak muncul dari kehidupan yang lebih baik, bukan dari kenyataan bahwa pengembang tidak ada hubungannya dan mereka menulis abstraksi sehingga mereka tidak dipecat. Arsitektur adalah jawaban terhadap tantangan pengembangan ponsel.Masalah utama ini adalah skalabilitas. Ketika aplikasi Anda menjadi terlalu besar dan memiliki fungsi yang berbeda, penting untuk mudah dipahami, dikembangkan, didebug. Jika tidak, penambahan fitur apa pun akan mengubah semua yang lama. Dan risiko kita mengalami peningkatan bug.Jangan tunggu sampai aplikasi Anda tumbuh. Sudah pada tahap awal, Anda dapat mempelajari praktik dasar membangun perangkat lunak yang juga berfungsi untuk aplikasi seluler, seperti SOLID, pola empat geng.Arsitektur aplikasi seluler memiliki spesifiknya sendiri: komponen global atau besarnya dibangun sesuai dengan pola arsitektur yang mengatakan pada tingkat tinggi objek mana yang harus dimiliki lapisan mana. Yang paling populer adalah MVC, MVP, dan MVVM.Dan jangan lupa bahwa pada kenyataannya arsitektur bukanlah peluru perak. Penting untuk mempertimbangkan secara spesifik proyek. Jika Anda menarik semacam arsitektur ke proyek Anda dengan air mata berlinang, mungkin ada yang salah.Ketika Anda mempelajari teori, itu akan tampak sangat rumit bagi Anda. Tetapi pada kenyataannya, ketika Anda bekerja dalam sebuah proyek dengan arsitektur yang baik, Anda akan senang karena menjadi lebih mudah bagi Anda untuk menulis kode. Anda tahu apa dan di mana menambahkan sehingga Anda memiliki fitur. Oleh karena itu, pada tahap ini, untuk mengenal arsitektur dengan baik, saya menyarankan Anda untuk bekerja atau magang dalam proyek besar. Jika Anda tidak memiliki kesempatan seperti itu, maka sekarang banyak perusahaan memasukkan proyek mereka ke sumber terbuka: Wikipedia, Firefox. Dan tidak ada yang melarang Anda untuk pergi ke GitHub dan melihat di sana.Jadi, aplikasi kita sudah siap. Mari kita letakkan di domain publik sehingga pengguna dapat mengunduhnya.
Dalam kebanyakan kasus, pengguna mendapatkan aplikasi dari Google Play dan App Store. Tetapi sebelum menambahkan aplikasi ke Store, kita harus menandatanganinya. Ini disebabkan oleh fakta bahwa sistem operasi menjalankan aplikasi hanya dari pengembang tepercaya. Dengan demikian, pada platform seluler, kami memiliki aplikasi dan virus yang jauh lebih sedikit berbahaya, karena hanya pengembang tepercaya yang dapat mengakses perangkat seluler.Untuk melakukan ini, Anda perlu mengeluarkan sertifikat pengembang. Ini sebenarnya adalah birokrasi kecil dan, untungnya, ini otomatis di versi terbaru Xcode.Anda juga perlu mengambil tangkapan layar untuk aplikasi dan deskripsi Anda. Dua langkah terakhir tidak boleh diabaikan, karena halaman aplikasi Anda adalah iklannya. Jika tidak cerah, maka kemungkinan besar semua pengembangan kami sia-sia, karena tidak ada yang akan mengunduh aplikasi.Aplikasi telah diunggah, sekarang mari kita bicara tentang beberapa keterampilan tambahan yang dapat menyederhanakan hidup Anda dan meningkatkan kualitas aplikasi.Skill yang paling sering Anda gunakan adalah debugging.
Metode debugging utama adalah console.log atau printf tua yang baik. Ini memiliki banyak nama, tetapi artinya sama. Ketika terjadi kesalahan, kami menambahkan logging, mencetak variabel. Namun sayangnya, metode ini juga memiliki kelemahan kritis.Kelemahan pertama adalah mengubah kode sumber. Ada bug yang hilang saat Anda menambahkan printf. Dan Anda menghapus printf - timbul kembali. Bug ini bahkan memiliki nama yang terpisah - heisenbug.Konsekuensi kedua adalah Anda harus mengkompilasi ulang aplikasi Anda dan menjalankannya kembali. Dalam proyek besar, ini bisa memakan waktu beberapa menit, dan jika Anda perlu menunggu sebentar ketika menambahkan setiap log baru, maka secara total Anda akan menghabiskan banyak waktu.Dan kelemahan printf terakhir, yang paling kritis - sayangnya, itu tidak membantu semua bug.Contoh dari praktik pribadi. Saat mengembangkan papan tombol, hal-hal berikut terjadi:
Di papan tombol sistem di bawah, alih-alih globe sistem dan ikon mikrofon, beberapa pengidentifikasi muncul. Debugging bug ini, saya merasa seperti ini:
Bagaimana aplikasi dapat merusak keyboard sistem ?! Ternyata itu bisa.
Saat menyelidiki bug, pengetahuan debugger sangat membantu saya. Secara khusus, pengaturan breakpoint untuk memanggil fungsi tertentu. Lihat Debugger, tempat kami dapat melihat antarmuka pengguna kami dan melihat siapa yang memiliki kelas apa dan status apa.Ketika saya memanfaatkan dua poin pertama ini, ternyata masalahnya ada di perpustakaan UIKit. Pengembang iOS akrab dengannya dan tahu bahwa ia tidak memiliki kode sumber terbuka. Tetapi ketika Anda tahu assembler, perpustakaan mana pun menjadi sumber terbuka untuk Anda, jadi dasar-dasar assembler kecil mungkin berguna.Ada juga yang disebut keterampilan reverse engineering. Terkadang itu bisa sangat membosankan, terkadang menarik - kisah detektif di mana Anda menyelidiki bagaimana satu komponen terhubung ke yang lain, bagaimana semuanya dilakukan di dalam perpustakaan. Akibatnya, ternyata masalahnya ada di runtime bahasa Objective-C.Keterampilan penting berikutnya adalah mengoptimalkan aplikasi kita.
Perangkat seluler memiliki sumber daya yang terbatas, sehingga sering kali ada masalah kinerja. Ketika berkembang, kita perlu memikirkan hal-hal seperti konsumsi CPU. Paling sering, ini adalah kompleksitas kode yang Anda tulis. Kecepatan rendering, memori, dan lalu lintas jaringan, karena sebagian besar pengguna lebih cenderung menggunakan aplikasi Anda pada lalu lintas seluler. Mari kita hormati para pengguna dan mungkin itu akan saling menguntungkan.Titik kelima adalah baterai, ini mengikuti dari empat pertama.Yang paling penting ketika mengoptimalkan aplikasi adalah mengidentifikasi area masalah. Jika Anda hanya mengandalkan asumsi, maka kemungkinan Anda akan kehilangan banyak waktu, dan Anda tidak akan mendapatkan terlalu banyak keuntungan. Ini akan membantu alat platform. Mereka termasuk profiler - program yang menunjukkan Anda di mana dalam kode Anda program menghabiskan waktu paling banyak. Artinya, Anda akan melihat metode di mana program Anda paling sering hang, dan kemungkinan besar Anda akan menemukan alasan pembekuan.Mengetahui algoritma dan struktur data akan membantu Anda menemukan solusi yang lebih efisien. Juga, pengetahuan multithreading dapat membantu di sini. Ada prosesor multi-core pada perangkat seluler sekarang, dan dengan memparalelkan masalah di beberapa utas, Anda mendapatkan sedikit peningkatan kinerja n-lipat.Kadang-kadang terjadi bahwa dua poin pertama, sayangnya, tidak membantu. Maka Anda akan terbantu dengan memahami cara kerja sistem operasi, dan pengetahuan tentang panggilan sistem, seperti peta memori (mmap). Dalam kasus kami, keyboard iOS pihak ketiga memiliki batasan pada konsumsi RAM - 52 megabita. Artinya, kami ingin menambahkan fitur, membuat antarmuka pengguna yang indah, tetapi dibatasi hingga 52 megabita. Apa yang harus dilakukan dengan ini tidak jelas.Ketika menambahkan fitur lain, ini terjadi. Kami sering mulai melampaui batas ini dan tidak tahu apa yang harus dilakukan dengannya. Akibatnya, panggilan sistem peta memori datang untuk menyelamatkan. Kami mengambil file dengan kamus, dari mana kami mendapatkan semua petunjuk, dan mulai memanggil peta memori. Dengan demikian, kami bekerja dengan sebagian file tanpa memuatnya sepenuhnya ke dalam RAM.Masalah yang paling sering ditemui terakhir adalah waktu mulai. Di sini saya dapat menyarankan Anda untuk membaca apa yang terjadi sebelum kode Anda mulai berfungsi. Khususnya, tentang tautan statis dan dinamis.
Keahlian terakhir yang bermanfaat adalah Integrasi Terus-menerus atau otomatisasi tugas-tugas yang membosankan.Tidak ada yang suka melakukan tugas yang membosankan, jadi kami hanya mengotomatiskannya. Paling sering, hal paling sederhana adalah membangun aplikasi untuk setiap komit yang Anda buat, dan semakin sering Anda membangun aplikasi, semakin cepat Anda dapat menemukan masalahnya. Jika Anda memiliki tes, jalankan juga.Seperti yang saya katakan, publikasi dikaitkan dengan birokrasi kecil, sehingga juga sangat otomatis, dan Anda dapat melepaskan perakitan ke toko beta untuk setiap permintaan kumpulan sehingga penguji dapat mengujinya. Anda juga dapat mengotomatiskan pembuatan tangkapan layar untuk App Store, agar tidak melakukannya secara manual.Untuk semua keterampilan yang terdaftar, saya mengumpulkan materi yang bermanfaat.itu akan membantu dalam pelajaran mereka. Ini juga berisi kode sumber untuk versi Translator yang disederhanakan. Terima kasih atas perhatian Anda, saya harap Anda memiliki sedikit lebih jelas apa yang harus dipelajari untuk memulai perjalanan Anda.