Transisi Dari Seorang Developer iOS Menjadi Developer Android

“Beda bahasa pemrograman, beda tampilan, namun mempunyai prinsip dasar yang sama. Para developer yang sebelumnya hanya menguasai satu platform akan bisa beralih ke platform yang lain dengan tetap berpegang pada prinsip platform yang sudah dikuasai sebelumnya”

– catatan editor –

Artikel asli dalam Bahasa Inggris Oleh: Tom Redman

Ditranslasikan ke dalam Bahasa Indonesia Oleh: Edy Kesuma

Dicek dan ditinjau ulang oleh: Reopan editor

Awal Mula

Di Buffer, kami membangun sebuah sistem yang membantu para penerbit menjadwalkan postingan mereka di media sosial dan mendapatkan analisis yang lebih mendalam tentang postingan yang diunggah. Pada saat yang sama, tujuan kami adalah menetapkan standar tinggi bagi customer service, pekerja remote, dan transparansi dalam bisnis. Silahkan kunjungi, dan tweet hi pada kami!

Dan bagi saya, jujur saya menyadari bahwa saya memang ingin bekerja di Buffer setelah membaca blog terbuka mereka dan sangat tertarik tentang bagaimana perusahaan ini bekerja. Mereka menarik dan tidak konvensional, dan secara alami saya merasa selaras dengan nilai-nilai perusahaan. Dan beruntungnya saya, mereka sedang membuka lowongan.

Setelah menyelesaikan pengembangan iOS selama setahun, posisi sebagai iOS Hacker terasa wajar untuk saya tempati. Saya pun mengajukan lamaran, kemudian diwawancara, dan jauh dari idealnya, saya ditawari posisi bootcamp Buffer!

Ada satu perasaan keberatan.

Ini adalah apa yang CTO Sunil katakan kepada saya ketika dia menawarkan posisi ini:

Saya tahu anda pernah menyinggung bahwa anda mungkin menyukai kesempatan untuk dapat bekerja lebih dengan Android, walaupun pengalaman yang anda miliki sebagian besar berbasis iOS (saya menyukainya!). Kami benar-benar memerlukan bantuan seseorang untuk membantu kami pada aplikasi Android, jadi kami berpikir untuk merekrut anda untuk membantu kami menyelesaikan masalah ini.”

Tidak mungkin saya menolak tawaran ini. Hanya satu yang menjadi masalah yaitu saya tidak terlalu mengetahui seluk beluk tentang Android.

Saya hanya memiliki sedikit gambaran dimana sebelumnya berkutat sebagai developer iOS dan secara yakin belum merasa sebagai Developer Android profesional. Sebenarnya, saya tidak yakin tentang apakah saya dapat melakukannya, namun saya merasa nyaman dengan kepercayaan Sunil bahwa saya mampu melakukannya (dia sebelumnya adalah orang pertama dibalik Android Buffer) dan membuka kesempatan untuk belajar dan berkembang sebagai seorang developer.

Dibawah ini adalah apa saja yang telah saya pelajari selama empat bulan terakhir, bekerja pada proyek Buffer Android berhari-hari. Saya berharap pengalaman transisi ini dapat membantu orang-orang yang memiliki kemiripan situasi dengan saya, atau mungkin secara sederhana memberikan gambaran tentang bagaimana tampaknya “sisi yang lain.” Sedikit bocoran: Ini sangat menarik.

Dua Kacang Dalam Satu Mangkok

– UIViewController dan Activities –

Di iOS terdapat konsep yang disebut UIViewContoller. Secara umum, suatu UIViewController adalah komponen inti di setiap aplikasi iOS. Komponen ini memanajemen kumpulan subview dan menangani siklus hidup aplikasi yang mungkin menggunakan subview tersebut. Ini merupakan pengendali pola dari Model-View-Controller. Dimana memetakan koordinat antara objek model dengan subview-nya, dan kerapkali mengintersep sentuhan agar bereaksi pada mereka. UIViewController “membuat hal ini bisa terjadi” di dunia iOS. Sebagian besar aplikasi memilikinya, beberapa komponen UIViewController yang menjalankan pertunjukannya. Tanyakan saja kepada Andy, iOS Buffer paling ulung.

Di hari pertama saya di Buffer, saya mengeksplorasi kode Android Buffer, dan tampaknya Android memiliki fitur UIViewController juga! Hore untuk sesuatu yang saya kenali! Terkecuali mereka tidak disebut dengan UIViewController, mereka disebut dengan Activities. Mereka hampir sama, tapi tidak sepenuhnya.

Activities dan UIViewController menjalankan banyak fungsi yang sama, namun karena perbedaan bagaimana Android menangani siklus hidup aksi, terdapat beberapa perbedaan kunci. Meskipun demikian, saya cukup senang menemukan sesuatu yang tampaknya familiar.

Di Android, Activites bertanggung jawab membuat dan memanipulasi subview mereka (atau komponen UI yang dipakai ulang yang disebut Fragments – suatu bagian yang sangat penting dari pengembangan Android modern) dan menangani aksi sentuhan. Namun, Activities sering lebih bersifat “atomic” (saya menggunakan kata non istilah komputer) daripda UIViewController karena mereka dapat didesain untuk berjalan terisolasi lepas satu sama lain.

Sebuah aplikasi Android adalah benar-benar kumpulan dari Activites yang dapat berbicara satu sama lain, namun tidak selalu diperlukan.

Sebagai contoh, ketika anda menjalankan Buffer untuk Android, ada MainActivity yang berjalan. Ketika anda menyentuh tombol biru “Compose”, kita sebenarnya membuat sebuah objek Activity baru dari jenis ComposerActivity dan menanyakan kepada MainActivity untuk menampilkannya dengan sebuah transisi slide. Hal ini hampir identik dengan bagaimana UIViewController bekerja satu sama lain. Tetapi disini terdapat sebuah perbedaan kunci platform antara iOS dan Android. ComposerActivity dapat dipanggil secara independen darimana saja di dalam sistem operasi. Contoh yang paling umum dapat bersama-sama dibagikan aplikasi pihak ketiga. Sebagai contoh, jika anda menekan tombol “Share” kemudian “Add to Buffer” dari aplikasi Twitter, sistem operasi akan memberi contoh dan menampilkan sebuah ComposerActivity, tanpa MainActivity. Dia akan berjalan sendiri, seperti sihir! Fitur yang terdapat pada platform ini begitu luar biasa dan telah menjadi pembeda paling mendasar sejak awalnya.

Catatan lain yang juga penting adalah Android tidak henti-hentinya menghapus dan membuat ulang Activities setiap waktu saat mereka tidak tampil pada layar, jadi kondisi ini harus disimpan dan Activity merekonstruksinya pada poin tertentu. Hal ini bisa diperoleh melalui sebuah variasi metode pemanggilan ulang dan dengan pasti membawa satu bit dari suatu alur kajian. Dan saya harus mempelajarinya dengan cepat, karena saat perangkat berrotasi semua Activities akan terhapus dan dibuat ulang. Perbedaan pada iOS dan Android juga memerlukan beberapa penyesuaian, sebagaimana membuat ulang Activites yang lengkap dan tepat dapat menjadi hal yang rumit (misalnya men-scroll sebuah ListView untuk mengimbangi pra-rotasi nya). Sistem operasi menangani banyak kondisi pembuatan ulang, tapi tidak semuanya.

Terdapat banyak perbedaan yang jelas dan yang kurang jelas antara UIViewController dengan Activities, namun memadai mengatakan bahwa saya cukup lega dengan semua prinsip-prinsip kemiripannya. Beda bahasa pemrograman, beda tampilan, dan dasar yang sama. Ini adalah hal yang sangat bagus.

– Delegate dan Adapter –

Pola delegate secara luas digunakan di iOS untuk membongkar tugas spesifik ke kelas spesifik (protokol adalah mekanisme Objective-C yang digunakan untuk mencapai hal ini). Di iOS, mereka biasanya disebut sebagai delegate protocol (atau data source protocol pada beberapa kasus), dan di Android mereka biasanya disebut sebagai adapter. Delegate dan adapter menunjukkan pola yang sama dan dengan efektif menjalankan fungsi yang sama.

Sebagai contoh, di iOS sebuah unit UITableView akan menetapkan suatu delegate (dan datasource-nya jika menjadi lebih spesifik) untuk memberitahukan berapa banyak baris yang dimiliki, untuk mengirimkan tampilan dari masing-masing baris yang spesifik, untuk memberikan tinggi dari masing-masing baris, dan lain sebagainya.

Tugas dari delegate adalah untuk memberikan UITableView semua yang dibutuhkan demi menterjemahkan daftar dengan tepat pada layar. Ini merupakan prinsip dasar dari pemrograman berbasis objek untuk menjaga beberapa hal bisa dilonggarkan dan delegate berarti satu untuk hal ini.

Ketika sebuah UITableView meminta delegate-nya menampilkan sebuah baris, dia akan memberikan kita jumlah baris yang diminta, yang mana akan kita gunakan untuk mendapatkan data baris yang spesifik, membangun bentuk tampilannya, dan akhirnya mengembalikannya kembali ke UITableView yang memintanya sebelumnya.

Jadi setelah setahun menggunakan metode iOS ini untuk melakukan hal tersebut:

– (UITableViewCell *)tableView: (UITableView *)tableView

cellForRowAtIndexPath:(NSIndexPath *)indexPath

Anda dapat membayangkan kelegaan saya ketika saya menemukan kode adapter Android ListView dan saya melihat metodenya:

public View getView (int position, View convertView, ViewGroup parent)

Metode ini ternyata efektif adalah identik: Sebuah jenis daftar yang menanyakan view untuk suatu baris terindentifikasi dalam indexPath atau position, berturut-turut. Maka dari itu, baris dibawah ini adalah hasil kode dengan fungsionalitas yang sama:

[self.table setDelegate:myTableViewDelegate];

this.table.setAdapter(myTableViewAdapter);

Pertama UIViewController dan Activities, sekarang delegate dan adapter juga? Proses perpindahan langsung diantara paradigma platform, kemenangan lain bagi seorang developer iOS yang berbalik menjadi developer Android! Semakin terlihat bahwa sebenarnya iOS dan Android tidak terlalu berbeda seperti yang pertama kali saya perkirakan. Dan saya sangat senang dengan kenyataaan ini.

– Tata Letak dan Antar Muka –

Dalam pengalaman saya, tata letak dan antarmuka adalah perbedaan utama platform yang nyata untuk dilihat. iOS dan Android mengambil pendekatan yang berbeda dari awal, dan tentu untuk banyak alasan yang bagus.

Android menggunakan rancangan XML, hampir sama dengan XIB, kecuali mereka bersifat lebih bisa dibaca (dan lebih baik lagi, bisa ditulis). Secara pribadi saya mengetahui bahwa dengan membuat rancangan di Android adalah suatu proses yang cukup cepat, dan ketika editor visual menyediakan pendekatan yang luar biasa untuk berbagai ukuran layar, saya tidak akan terganggu menggunakannya ketika benar-benar membuat rancangan. Segala hal yang tidak biasa paling bagus dibuat dalam file XML.

Sistem layout Android hampir keseluruhannya adalah relatif, yang membuat perancangan tampilan untuk berbagai resolusi layar dapat berjalan dengan lancar. Sebagai perbandingan, autolayout pada sistem iOS terasa sangat berat dijalankan.

Meskipun begitu, ketika membahas tentang animasi, sistem layout Android umumnya jauh dibawah iOS (walaupun hal ini telah mengalami perubahan besar pada Android L). Sebagaimana yang saya pahami, kompleksifitas perbedaan antara layout framework adalah relatif dekat terhadap kealamian penganimasian dari setiap komponen dalam layout.

Apple selalu fokus pada bentuk animasi yang luar biasa, rumit dan halus, dan hal inilah memberikan nilai tambah bagi platform mereka. Pendekatan ini secara luas memungkinkan jika menerapkan kendali total pada hardware, dimana pada setiap perangkat iOS dijamin dikapalkan dengan sebuah unit GPU. Kontras kebalikannya, Google membuat pilihan untuk menjaga harga tetap terjangkau, proses perakitan perangkat Android tidak diharuskan dilengkapi dengan GPU. Saat ini, saya tidak memiliki bukti kecuali kue pudingnya, tapi menurut pendapat saya, hasil dengan animasi yang melimpah menjadi prioritas yang lebih rendah sejak pengalaman penggunaan tidak bisa konsisten dalam perangkat lintas platform, dan sampai bahasa Material Design dikembangkan, kualitas animasi yang tinggi dan kompleks tidak menjadi lebih berkembang, dimana merupakan titik pusat dari platform.

Saya menyukai animasi dengan penyetelan yang tepat dalam suatu aplikasi, jadi keterbatasan ini membuat Android sulit mencapai polesan animasi yang membuat aplikasi iOS begitu memuaskan. Masih ada banyak pilihan untuk penganimasian, namun tidak satupun terasa selengkap atau terkontrol seperti yang mereka lakukan di iOS. Saya sudah tidak sabar menunggu Android L dan rencana untuk mencoba semua animasi API baru yang tersedia. Serius, suatu hari nanti akan mengagumkan.

– Perbedaan Praktek –

Struktur Proyek 
Struktur proyek pada Xcode adalah longgar: membuat folder dan file dimanapun dan mereferensikannya pada saat yang sama. Diperlukan sedikit bentuk penamaan pada situasi tertentu, seperti icon aplikasi, grafik @2x/@3x dan kelas kategori, namun itu masih hal kecil dari keseluruhannya.

Sebaliknya, struktur dari proyek Android sangatlah kaku. Terdapat banyak bentuk penamaan untuk ditambahkan pada folder resource, folder style, folder source, dan lain sebagainya. Ini dikarenakan, diatas sumber struktur diperlukan ruang penamaan Java yang baik, sebuah aplikasi Android akan memiliki beberapa buah densitas layar untuk mendukung layar dengan densitas yang berbeda-beda.

Sebagai contoh, Nexus 5 merupakan perangkat dengan rekomendasi perangkat extra-extra-high-dpi, jadi struktur Android ini akan mampu menarik sumber yang spesifik yang foldernya disebut res/drawable-xxhdpi. Sedangkan untuk Nexus 4 memiliki rekomendasi extra-high-dpi dan akan mampu menarik sumber dari folder yang disebut res/drawable-xhdpi. Anda tidak dapat mengumpulkan folder ini semuanya, dan jangan pernah berpikir untuk menggunakan huruf kapital (Huruf besar semua) di penamaan file sumber. Sisi baiknya, sejak Android menggunakan Java, strukturnya menggunakan penamaan dan pengemasan yang baik. Jadi anda tidak perlu khawatir tentang menambahkan awalan di semua class yang anda gunakan (dimana selalu saya temukan menjadi patokan setengah penasaran).

– Simulator dan Emulator –

Satu hal yang membuat saya begitu terkejut adalah perbedaan antara simulator iOS dengan emulator Android. Simulator iOS lebih ringan dan cepat dibandingkan dengan emulator Android. Namun demikian, ini adalah dengan alasan yang bagus dan terdapat suatu metode dibelakang kegilaan emulator Android.

Simulator iOS memang benar sangat cepat saat proses boot, reset dan memulai aplikasi baru. Tapi simulator ini gagal menyediakan akurasi representasi yang tepat dari sebuah perangkat iOS. Ini dikarenakan menggunakan CPU dan memori komputer, yang membuat dampak besar pada performa aplikasi. Ini berarti aplikasi akan berjalan lebih cepat di simulator dibandingkan pada sebuah perangkat, terutama pada perangkat yang lebih lama, menyembunyikan relatifitas masalah performa. Pengetesan perangkat pada dunia Aplle merupakan sebuah keharusan.

Emulator Android pada sisi lain, merupakan mesin virtual yang menjalankan virtualisasi CPU dan memori yang dibatasi. Ini merupakan pendekatan yang mendekati kenyataan suatu perangkat. Dan ketika menghadapi fragmentasi Android, emulator adalah pilihan yang alami sebagaimana anda dapat memperjelas permutasi dari spesifikasi perangkat untuk pengembangan dan pengetesan. Dan tentu lebih percaya diri bahwa sistem yang digunakan memang benar-benar akurat. Namun demikian, pengetesan perangkat tetaplah keharusan! Tapi mungkin tidak dibutuhkan terlalu banyak.

Meskipun pada Android, saya tetap menyarankan penggunaan perangkat asli untuk pengembangan, yang mana benar-benar sepadan dengan kecepatan pada pengetesan perangkat iOS. (Setelah berpikir kembali: Genymotion memiliki berbagai keunggulan pada ruang emulator Android. Saya sangat merekomendasikan untuk mencobanya juga).

– Perbedaan Bahasa Pemrograman –

Seseorang (bukan saya) dapat menulis sebuah buku tentang perbedaan antara Java, Objective-C, atau dua bahasa pemrograman lain. Dan pada perbandingan yang lebih mendalam (sedikit keluar dari topik tulisan ini), adalah sepadan pergi sedikit lebih jauh untuk mendapatkan penemuan-penemuan penting lainnya.

Ketika mengembangkan sistem dengan Java, coba cek objek Null. Objective-C – menjalankan objek kosong dengan anggun – adalah legal mengirimkan sebuah pesan pada objek kosong – tapi Java akan melempartkan sebuah NullPointerException sesegera ketika anda mencoba memanggil sebuah metode pada objek kosong. Terdapat diskusi tingkat tinggi yang membahas Null di Java, tapi pada penerapannya, anda sederhananya akan mengecek suatu null.. bahkan sering.

Saya juga merasa kehilangan sifat khusus dari Objective-C. Di Java, tidak ada pengambil dan pengatur otomatis. Anda harus menuliskan (dihasilkan dari IDE) getA() dan setA(Object A) dan menggunakannya secara jelas jika anda menginginkannya. Saya menemukan petunjuk ini mengarah ke banyak kode panas, tapi mungkin sekali lagi saya dimanjakan Objective-C ketika semua hal terpisahkan itu pergi.

Hal akhir yang membuat saya tertarik pada Java adalah karena metode over-loading. Metode ini memberikan kenyamanan! Saya sangat merekomendasikan untuk mempelajari tentang dan mengambil kesempatan dari fitur asli bahasa pemrograman yang lain.

– Memori dan Kumpulan Sampah –

Manajemen memori adalah topik yang besar, khususnya di Objective-C yang ada pada ARC, manajemen memori ditangani secara nyata oleh para developer. Saat diselesaikan dengan baik, aplikasi akan memiliki keefisienan memori yang bagus. Namun demikian ini adalah apa yang disebut dengan konsep yang sulit dan akan menuntunnya kepada banyak kesalahan saat praktek. Sejak ARC, manajemen memori menjadi semakin mudah, namum masih tetap menjadi aspek penting dan kritis dalam pengembangan perangkat mobile.

Ketika saya berpindah ke Android, saya membuat kesalahan dengan mengasumsikan kumpulan sampah runtime akan membebaskan saya dari setiap tanggung jawab manajemen memori (tentu saja dengan suatu alasan). Ternyata saya salah. Bahkan di Android, para developer perlu menyadari penggunaan memori dari aplikasi mereka: gambar yang besar, terlalu banyak gambaran atau terlalu banyak penarikan mungkin akan mendatangkan OutOfMemoryErrors. Bitmap secara khusus dapat menjadi rumit karena jika anda menempatkan sebuah bitmap pada folder sumber yang salah, Android akan mengukurnya dengan densitas yang benar, yang mana hasilnya berupa bitmap yang sangat besar dan cukup membuat sakit kepala.

Saya sering menemukan masalah ini ketika membuat sebuah alur pengenalan baru untuk Buffer. Saya salah menempatkan sebuah gambar yang beresolusi 1080×1920 di folder res/drawable-mdpi tanpa menyadari hal ini akan diperbesar menjadi 3X di layar perangkat xxhdpi, seperti Nexus 5 yang resolusi aslinya 1080×1920. Ketika saya menampilkan gambarnya, dengan segera muncul OutOfMemoryError karena bitmap yang dihasilkan berukuran 3240×5670 dan memerlukan memori 9X lebih besar untuk menampilkan grafis aslinya. Saya dengan cepat menyadari bahwa menyesuaikan ukuran dan mengatur bitmap sesuai densitas adalah langkah yang sangat penting untuk memastikan anda menggunakan sedikit memori sesuai yang diperlukan.

Kumpulan LinearLayout adalah kecerobohan lain yang saya lakukan, kecuali saya baru menyadarinya sedikit terlambat dari awal mulai.

Tugas pertama saya di Buffer adalah mendesain ulang aplikasi untuk menyesuaikan dengan bahasa pendesainan yang baru, yang secara mengejutkan berjalan sangat halus. Kecuali saat sebelum kami akan mengenalkan versi baru kepada dunia, saya memutuskan mencobanya pada perangkat lama Android 2.3, dimana secara resmi kami masih mendukung aplikasinya.

Aplikasi mengalami kerusakan dan crash, sehari sebelum kami merencanakan perilisan updatenya. Ini semua adalah kesalahan saya karena tidak mencoba pada perangkat yang lebih lama sebelumnya. Saya mengambil pelajaran dari hal ini dan akan selalu mengingatnya dalam hati.

Saya selalu mengalami StackOverflowError di hampir semua tempat. Tampaknya selama saya mendesain ulang saya mengumpulkan layout tidak sepenuha hati, tidak memperdulikan akibat berkelanjutan yang terjadi pada susunan. Mengumpulkan LinearLayout secara khusus memberikan beban sesuai dengan jumlah perulangan yang diperlukan untuk menghitung subviewnya. Saya harus menulis ulang sebagian besar kode layout agar menjadi lebih rata, dan kemudian hanya mengumpulkan apa yang memang diperlukan dan menggunakan RelativeLayout untuk semua hal yang bisa diterapkan (yang mana lebih powerful). Semakin banyak penelitian dan dari hari ke hari, aplikasi ini berjalan semakin lancar di berbagai perangkat yang kami dukung. Tambahan pelajaran yang akan selalu saya ingat.

Kesimpulan

Keseluruhan, perpindahan saya ke Android berjalan dengan lancar. Terdapat beberapa alur pembelajaran spesifik pada platform ini – seperti tidak perlu mengumpulkan LinearLayout – Namun akhirnya saya bisa menyelaminya dan menyelesaikannya pada suatu hari berdasarkan pengetahuan saya tentang perkembangan bidang mobile secara umum.

Saya menyadari setelah mengembangkan sebuah platform mobile, terdapat begitu banyak pengetahuan nyata dibandingkan dengan framework API dan bahasa pemrograman yang spesifik. Sebagian besar yang saya tahu tentang pentranslasian satu platform (secara langsung) ke dalam bentuk yang lain, hanyalah belajar pada detailnya.

Kedua platform memiliki kemiripan dasar yang sangat banyak. Jangan malu mencobanya sendiri di salah satu atau kedua platform tersebut. Tidak peduli apapun latar belakang yang anda miliki.