Contoh Surat Perjanjian Kontrak Software Developer

PR besar selain skill coding seorang Software Developer adalah kemampuan menulis. Baik itu menulis surat cinta buat calon istri #eh, menulis surat penawaran, menulis list tugas-tugas dan skup pekerjaan, menulis percakapan yang baik dan mudah dipahami klien (baik itu yang awam maupun yang pro), dan menulis dokumentasi.

Di kesempatan ini saya coba menulis Surat Perjanjian Kontrak (SPK) Software Developer yang mungkin berguna, khususnya buat saya sendiri maupun temen-temen yang berprofesi sebagai software developer. Sudah disesuaikan berdasarkan pengalaman-pengalaman lampau sehingga, insya’ Allah tidak merugikan kedua belah pihak, khususnya si Software Developer.

Mungkin di kesempatan lain saya akan menulis contoh-contoh surat yang lain di dunia manajemen proyek. Tapi menunggu ada waktunya dulu hahaha.

Berikut ini contohnya: download di SINI

Perlu diingat bahwa Surat Kontrak Kerja tidak berdiri sendiri di saat membuat kesepakatan dengan klien, harus disertakan juga PO (Purchase Order) yang berisi pekerjaan yang diminta dan harganya, kemudian FSD (Fuctional Spesification Document) yang berisi list skup pekerjaan beserta detailnya, kemudian NDA (Non-disclosure agreement) yang berisi kesepakatan kerahasiaan pekerjaan.

 

Pentingnya memahami penamaan “assets” di dalam desain

Apa itu “aset desain” atau Design Assets ?
Aset desain adalah resources tertentu di dalam UI/UX yang digunakan ke dalam proses pengembangan perangkat lunak atau aplikasi.

Apa saja yang termasuk “aset desain”?

Yang termasuk di dalam UI aset desain adalah color palettes(codes/hexa/rgb), styles (tema), icons (icon yang akan dipasang), fonts (font yang digunakan), images (gambar, baik itu background komponen desain, background halaman, banner, gambar header, footer, dsb), animation (animasi transisi halaman), audio (suara ketika klik tombol, dsb), video (video panduan penggunaan software, video iklan) dan setiap elemen yang digunakan untuk memvisualisasikan aplikasi atau software.

Dalam pembahasan kali ini difokuskan mengenai masalah penamaan file, karena ada beberapa kasus di mana designer tidak memberikan nama yang pas untuk assets desain yang ia desain. Alhasil, untuk tracing assets design (misal: icon) ataupun memanggil assetsnya di codingan menjadi membingungkan.

Ditambah lagi, ada beberapa assets design yang nama filenya sama dengan assets design yang lain. Tentu ini akan membuat frustasi developer yang menggunakannya.

Penamaan file di dalam assets design itu sangat penting, itu akan memudahkan designer maupun developer yang akan memindahkan desain ke dalam codingan.

Umumnya, penamaan assets design itu menggunakan prefix, sama halnya dengan penamaan tabel di database, menggunakan prefix atau suffix:
Contoh
ic_email => menandakan ini icon untuk email.
bg_email => menandakan ini background untuk halaman email.
ic_email_selected => menandakan ini icon email ketika dipilih.
ic_email_pressed => menandakan ini icon email ketika ditekan.

Ya, menggunakan prefix ic_ untuk icon, bg_ untuk background, suffix _selected untuk icon yg dipilih, suffix _pressed untuk icon yang ditekan, dan lain sebagainya.

Dan ada pula yang ditaruh ke dalam sub folder tertentu untuk background di dalam folder tersendiri, untuk icon di dalam folder tersendiri, dan lain-lain.

Dengan begitu, manajemen assets design jadi tertata dengan baik 

5 cara menambahkan event listener pada pemrograman Android

1. Member Class

public class main extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        //attach an instance of HandleClick to the Button
        findViewById(R.id.button1).setOnClickListener(new HandleClick());
    }    
    private class HandleClick implements OnClickListener{
        public void onClick(View arg0) {
            Button btn = (Button)arg0;  //cast view to a button
            // get a reference to the TextView
            TextView tv = (TextView) findViewById(R.id.textview1);
            // update the TextView text
            tv.setText("You pressed " + btn.getText());
        }
    }
}

2. Interface Type

public class main extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        //use the handleClick variable to attach the event listener
        findViewById(R.id.button1).setOnClickListener(handleClick);
    }    
    private OnClickListener handleClick = new OnClickListener(){
        public void onClick(View arg0) {
            Button btn = (Button)arg0;
            TextView tv = (TextView) findViewById(R.id.textview1);
            tv.setText("You pressed " + btn.getText());
        }
    };
}

3. Anonymous Inner Class

public class main extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        findViewById(R.id.button1).setOnClickListener(new OnClickListener(){
            public void onClick(View arg0) {
            Button btn = (Button)arg0;
            TextView tv = (TextView) findViewById(R.id.textview1);
            tv.setText("You pressed " + btn.getText());
            }
        });
    }     
}

4. Implementation in Activity

public class main extends Activity implements OnClickListener{
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        findViewById(R.id.button1).setOnClickListener(this);
    }    
    public void onClick(View arg0) {
        Button btn = (Button)arg0;
        TextView tv = (TextView) findViewById(R.id.textview1);
        tv.setText("You pressed " + btn.getText());
    }
}

5. Attribute in View Layout for OnClick Events

public class main extends Activity{
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
    }    
    public void HandleClick(View arg0) {
        Button btn = (Button)arg0;
        TextView tv = (TextView) findViewById(R.id.textview1);
        tv.setText("You pressed " + btn.getText());
    }
}

Dan cara memanfaatkannya, cukup menambahkan parameter onClick seperti di xml berikut:

<Button android:id="@+id/button1"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Button 1"
        android:onClick="HandleClick"/>

Proses Pengembangan Aplikasi Android

Banyak dari kita yang dari developer backend ataupun frontend web dan desktop beralih menjadi developer frontend mobile, sebagai pembahasan kali ini adalah menjadi developer Android.

Di sini saya mencoba menulis hal-hal yang patut diperhatikan oleh developer “peralihan” tersebut, agar nantinya lebih matang lagi mendalami dunia mobile application development. Dan juga bagi Anda yang hendak mencari dan bekerjasama dengan developer mobile Android untuk produk Anda ataupun studi kasus/penelitian Anda, agar memahami bagaimana proses pengembangan aplikasi Android dari awal hingga menerbitkannya di PlayStore, bagian mana yang membuatnya menjadi panjang prosesnya, dan tahap apa saja di dalam pengembangan aplikasi mobile Android itu sendiri.

Pembahasan kali ini mencakup tahapan dari proses pengembangan Aplikasi Android yang sedikit berbeda dengan platform lain seperti Web ataupun Desktop.

Berikut ini gambaran singkat mengenai proses pengembangan aplikasi Android dari memulai menemukan ide, perancangan sampai dengan menerbitkannya di Google Play Store.

Gambar 1. Proses Manajemen Proyek Pengembangan Aplikasi Android.

Dari gambar di atas, saya coba jabarkan secara singkat satu per satu:

1. Dimulai dari mendefinisikan ide dan persyaratan aplikasi

Apabila Anda hendak mengembangkan sebuah aplikasi, yang patut anda lakukan pertama kali adalah mendefinisikan ide Anda ke dalam sebuah tulisan, kemudian dari ide tersebut berkembang menjadi sebuah masalah. Dari masalah tersebut, tugas Anda selanjutnya adalah berusaha memecahkan permasalahan menjadi solusi. Di antara tahap mencari solusi di dalam sebuah masalah, tentu ada uraian-uraian proses pemecahan masalah, nah, dari situ kita dapat menentukan kebutuhan apa saja di dalam aplikasi yang hendak dibuat.

Untuk persyaratan (requirements) aplikasi, ada banyak poin di dalamnya, requirement  aplikasi ini sangat penting sebagai dasar untuk mendefinisikan dan mengelola scope  pekerjaan atau scope produk. Untuk mendefinisikan requirements ini ada banyak teknik yang dapat dilakukan, diantaranya:

• brainstorming ataupun mindmapping
  berdiskusi dengan anggota grup tentang ide produk aplikasi yang hendak dibuat, dan mengupayakan pencarian solusi dari permasalahan yang ada sehingga menjadi ide yang matang dari berbagai anggota grup, di sini masing-masing anggota mencoba mem-breakdown masalah agar nantinya masalah tersebut dapat diselesaikan dengan pendekatan aplikasi.
  
• interview
  mewawancarai orang yang ahli dalam bidangnya atau orang yang memiliki informasi yang dapat memberikan masukkan terkait requirement aplikasi yang hendak Anda buat sehingga Anda menjadi tahu detail permasalahan yang dihadapi dari ahli tersebut, dan tentunya berupaya mencapai solusi dengan pendekatan aplikasi,
• kuesioner
  apabila Anda masih belum yakin apakah ide Anda akan laku di pasaran, langkah yang bisa Anda ambil adalah membuat kuisoner dan menyebarkannya ke target pengguna aplikasi, Anda dapat membuat sejumlah pertanyaan dan ditujukan kepada responden dalam jumlah yang banyak dan bervariasi sehingga didapat akumulasi informasi dengan cepat,
• observasi
  teknik melihat dan mengamati secara langsung orang-orang dilingkungannya, pekerjaannya dan proses-nya. Observasi dikenal juga dengan nama “job shadowing”.
• prototype
  Anda dapat membuat prototype aplikasi yang hanya berupa tampilan atau model kerja dari Aplikasi yang hendak dikembangkan. Prototype ini dapat Anda promosikan ke pengguna ataupun penanam modal, yang nantinya diharapkan Anda mendapatkan feedback atau bekal requirement untuk aplikasi yang hendak dibuat.

2. Wireframing atau protoyping tampilan antarmuka (UI) aplikasi

Untuk dapat mengembangkan aplikasi, Anda harus mempunyai gambaran jelas seperti apa nantinya tampilan antarmuka aplikasi Anda. Dan dari tahap wireframing inilah Anda dapat mengetahui apakah penempatan fitur atau menu ini sudah sesuai layoutnya atau belum, apakah desainnya sudah sesuai pattern OS Android atau belum, apakah tampilannya sudah kelihatan nyaman dipandang atau belum, dan apakah desain yang diterapkan sudah sesuai User Experience atau belum.

Ada banyak tools prototyping yang akan membantu anda mendesign dengan cepat. Diantaranya Adobe Photoshop (Win/Mac), Sketch (Mac), Gravit Design (Win/Mac/Linux), Invision Studio (web), Zeplin.io (web), Figma.com (web), dan app.studio.design (web).

Ketika anda telah membuat wireframing tampilan antarmuka aplikasinya, selanjutnya adalah membuat desain antarmukanya menggunakan tools di atas, agar nantinya ketika Anda telah memasuki masa pengembangan aplikasi, Anda tinggal memindahkan desain tersebut ke layout Android.

Layout Android dikembangkan dengan menggunakan bahasa pemrograman XML, dan ditaruh di dalam folder resource (res) layout Android.

Dan perlu diingat, ponsel dan tablet Android itu memiliki beragam jenis layar dan ukuran, pentingnya menyiapkan desain yang adaptive, yang mendukung beragam jenis layar tersebut (heterokapabilitas). Pembahasan Adaptive Design pernah dibahas di artikel berikut ini.

3. Pengembangan dan pengujian aplikasi

Pengembangan aplikasi Android secara native dapat menggunakan bahasa Pemrograman Java ataupun Kotlin. Keduanya mempunyai ciri khas masing-masing. Dan keduanya didukung penuh oleh Android SDK. Namun, apabila Anda tertarik mengembangkan aplikasi Android secara hybrid, Anda dapat menggunakan berbagai bahasa pemrograman yang sudah ada, misal dengan javascript nodejs/angularjs (react-native, ionic), menggunakan html5 (phonegap), atau .NET (xamarin/visualstudiocode).

Baik native maupun hybrid memiliki keunggulan dan kelemahan masing-masing. Untuk native sendiri karena sudah didukung penuh oleh Google Android, tentunya semua fasilitas di dalam SDK sudah pasti paling cepat mendapatkan layanan. Sedangkan hybrid, sangat mengandalkan komunitas developernya.

Dan dalam tahap pengembangan aplikasi Android, seorang developer tidak hanya fokus menulis code dalam bahasa pemrograman Java/Kotlin, namun Anda juga harus mampu menulis code untuk resource antarmuka pengguna dalam bahasa pemrograman XML dan juga mampu menguji aplikasi yang Anda buat.

Untuk pengujian Aplikasi, ada banyak tools yang dapat dipakai, salah satunya TestFairy (web), Firebase Reporting (web), ataupun Fabric.io (web). Dan yang terpenting adalah Anda dituntut untuk mampu membaca Log di Logcat Android (DDMS/Android Studio) ketika aplikasi berjalan, dan juga pentingnya skill debugging dan bugs fixing code Android.

Selain itu, pengaturan aplikasi di manifests penting untuk diperhatikan, misalnya, permission apa saja yang Anda cantumkan di manifests yang nantinya diminta kepada pengguna. Sudah sesuaikan permission yang Anda definisikan di manifests, jangan sampai Anda menambahkan permission yang tidak dibutuhkan Aplikasi apalagi yang berbahaya bagi pengguna aplikasi Anda. Dan juga bagaimana pengaturan tema masing-masing halaman aplikasi Anda, semua diatur di manifests ini. Pengaturan lainnya seperti background service dan broadcast (SMS ataupun push notification), penggunaan memory dan jenis ukuran layar yang didukung oleh Aplikasi Anda. Semua itu diatur di manifests file ini.

Dan tidak lupa juga pengaturan build configuration di gradle, apakah Anda telah menggunakan library versi terbaru atau yang stable (minim masalah bugs), dan apakah target OSnya sudah sesuai dengan OS terbaru, dan sebagainya. Itu semua harus dipersiapkan oleh Anda sebagai developer.

Berikut ini rincian bagaimana source code yang telah Anda kerjakan di-“build” menjadi sebuah APK (installer) aplikasi Android.

Gambar 2. Proses sourcecode yang digodok menjadi sebuah installer (APK)

Semua proses, dari sebuah sourcecode mentah, menjadi sebuah Android Package Kit (APK) alias installer yang nanti digunakan oleh pengguna (user) Anda, dimulai dari proses compiling source code tersebut. Compiler yang digunakan di Android Studio adalah Dalvik. Compiler tersebut mengonversi source code yang Anda kerjakan menjadi file DEX (Dalvik Executable) dan resources yang compiled, yang menyertakan bytecode yang berjalan pada perangkat Android. Dan setelah DEX tersebut dibuat, proses selanjutnya adalah mengubah DEX file dan lainnya tersebut menjadi sebuah APK, dan ini ditandai dengan kunci (Keystore) ntah versi debug ataukah versi release. Dan semua proses itu, dari menentukan kunci mana yang dipakai, menentukan library module dan plugins mana yang akan dipakai, library versi berapa, OS target versi berapa dan sebagainya, semua itu diatur melalui Gradle. Detailnya dapat dibaca dari sini.

4. Penerbitan aplikasi ke PlayStore

Aplikasi yang telah dikembangkan dan sudah teruji dengan baik, selanjutnya diterbitkan ke PlayStore. Untuk penerbitan ini Google memiliki syarat standar yang harus dipenuhi. Selain membayar biaya sebesar 25 USD untuk seumur hidup, Anda juga harus mempersiapkan APK yang telah memiliki status ditandatangani (signed) dengan kunci keamanan (KeyStore) versi release yang valid milik Anda. Seperti yang Anda lihat di gambar sebelumnya (no.3), source code yang anda kerjakan, akan di-compile dan ditandai dengan Keystore. Nah, untuk lebih detailnya bagaimana proses penandatanganan aplikasi oleh Keystore tersebut, perhatikan gambar berikut.

Gambar 3. Proses menandatangani APK yang telah di-build di Android Studio

Saat menggunakan penandatanganan Aplikasi Google Play, jika Anda kehilangan kunci unggahan, atau ada risiko keamanan, Anda bisa menghubungi Google untuk mencabut kunci unggahan lama dan membuat kunci baru. Karena kunci penandatanganan aplikasi dilindungi oleh Google, Anda bisa terus mengunggah versi baru aplikasi sebagai pembaruan ke aplikasi asli, meskipun Anda mengubah kunci unggahan. Namun, daripada Anda repot dengan proses pengembalian kunci yang lama, sebaiknya Keystore yang sudah Anda buat dan pakai untuk penandatanganan APK tersebut jangan sampai hilang (bisa dibackup di google drive ataupun dropbox). Dan jangan lupa Keystore tersebut dilindungi oleh password Anda, jangan sampai lupa yah 😉

Untuk informasi lengkapnya dapat mengunjungi tautan berikut: https://developer.android.com/studio/publish/app-signing.html?hl=id

Selain syarat di atas, Anda juga harus mempersiapkan nama aplikasi, deskripsi yang “menjual” agar orang lain tertarik untuk mencoba aplikasi Anda, screenshots aplikasi, kata kunci, kategori produk, dan kontak yang dapat dihubungi.

Untuk pasca pengembangan ini, Anda dituntut dapat menjadi mitra konsumen/pengguna aplikasi yang telah Anda buat. Mengapa? karena nantinya Anda akan menerima review (baik berupa kritikan, saran, dan hal-hal lain terkait aplikasi Anda) dan rating. Nantinya, review dan rating ini menjadi bahan evaluasi bagi Anda apakah yang perlu diperbaiki dan ditingkatkan dari fitur atau layanan yang ada di Aplikasi Anda. Ini tentunya penting bagi anda yang hendak mengukur apakah aplikasi yang Anda terbitkan ini sukses di pasaran. Jika tidak, mulailah mengevaluasi dari kritikan-kritikan di halaman review aplikasi Anda di Playstore, kemudian coba kontak beberapa pengguna, bagaimana tingkat kepuasan pemakaian aplikasi yang Anda buat.

Dan paling penting, jaga kerahasiaan data dan privasi pengguna Anda, jangan sampai disalahgunakan oleh siapapun. Untuk itulah mengapa di kebanyakan app sekarang diminta mencantumkan menu dan halaman “terms of services” atau “terms and conditions” dan “privacy policies“. Detailnya bisa dibaca di sini.

Semoga materi singkat ini dapat bermanfaat 🙂

Native vs Hybrid App. Programming. Pilih yang mana?

Sebelum saya membahas lebih jauh, saya ingin menjelaskan secara singkat pengertian apa itu Native dan apa itu Hybrid di dalam pengembangan aplikasi mobile (Android dan iOS pada khususnya).

Native app: build 1 app, hanya bisa di-deploy di single platform.

Hybrid app: build 1 app, bisa di-deploy multi platform (makanya ada jargon “build once, deploy anywhere“)

Aplikasi Android ditulis dengan menggunakan bahasa pemrograman Java (dan yang terbaru dengan Kotlin), dan Aplikasi iOS (iPhone/iPad/Watch) ditulis dengan Objective-C (dan yang terbaru dengan Swift), dan tidak ada cara keduanya dapat dicampur dengan bahasa pemrograman lain. Itulah native.

Sedangkan Aplikasi Hybrid mengizinkan kita untuk mengeksekusi platform web (misal Javascript) agar dapat berjalan pada  “native wrapper” (Apa itu native wrapper? sebuah subroutine di dalam lapisan Aplikasi, yang berfungsi sebagai penyedia akses menuju API di Sistem Operasi perangkat). Sistem arsitektur aplikasi Hybrid bisa dilihat di gambar berikut:

Di awal 2017, bahasa pemrograman Hybrid sudah diramaikan dengan adanya “react-native” yang basednya Javascript. Dan berdasarkan penelusuran saya di Github, Javascript sekarang sedang “naik daun”, dengan node.js, vue.js, dan react-nya

most popular programming languages on Github

React-native ini sendiri membutuhkan node, watchman dan react-cli. Dan sampai tanggal 29 November 2017 ini, react-native masih dalam tahap beta, belum ada versi stable. Namun, bukan berarti lambat berkembang, sampai saat ini sudah banyak framework yang telah dikembangkan dan dapat digunakan oleh para developer secara bebas, di antaranya Ignite. Ignite mempermudah pengembangan aplikasi dengan basis react-native, apalagi semua komponen, UI, theme, dll..sudah tersedia, tinggal pakai.

Ok, saya tidak akan membahas react-native lebih jauh soal ini. Mungkin akan saya bahas di lain kesempatan.

Pembahasan kali ini adalah menjawab 2 pertanyaan:

1. “manakah yang lebih baik? hybrid kah atau native kah?”
2. “Dan dalam kondisi seperti apa kita mesti menggunakan bahasa pemrograman native atau hybrid di dalam mengembangkan sebuah aplikasi?”

Ok, mari kita jawab satu persatu.

Bila ditanya mana yang lebih baik? saya bilang, tergantung kondisi. “Mengapa?” karena masing-masing ada keunggulan dan kekurangannya. “Loh, native ada kekurangannya toh?” sabar..sabar.. kekurangan di sini bukan ditinjau dari segi teknis pengembangan saja, tetapi juga dari harga dan waktu. Tentu pertimbangan ini penting bagi perusahaan di dalam menentukan produk mereka nanti mau dikembangkan secara hybrid atau native.

Secara singkat, ketika perusahaan memilih Programming Hybrid, maka yang harus dipertimbangkan adalah:

• Membutuhkan human-resource(s) (SDM) yang menguasai teknologi web, seperti CSS, Javascript, HTML5, dan atau AngularJS.
• Tampilan UI/UX cenderung statis, bisa dikustomisasi, namun effortnya lumayan.
• Performance di beberapa kasus sama baiknya dengan native, tapi ketika melibatkan hardware, misal push notification, akses audio, sensor GPS/Kompas/Accelerometer, tidak sebaik native. Namun perkembangannya terus membaik.
• Lack of documentation, developer dituntut tidak kaku dalam membaca dokumentasi, ada banyak sekali dokumentasi terkait hybrid programming dan sayangnya tidak di satu tempat, harus punya wawasan lebih dalam bereksplorasi teknologi hybrid. Berbeda dengan Android/iOS dengan menggunakan native, dokumentasi tersusun rapi dan sangat lengkap di masing-masing website resminya.
• Membutuhkan tenaga konsultan di dalam mempertimbangkan module atau library apa yang hendak dipakai yang sesuai dengan spesifikasi aplikasi. Mengapa? karena belum tentu tersedia (akan tetapi sejenis react sekarang sudah banyak sekali library dan sudah lumayan lengkap) atau bagaimana effort-nya di dalam pengembangan.

Di lain pihak, native programming, ada yang harus diperhatikan juga, diantaranya:

• Biaya pengembangan tinggi, dibandingkan dengan hybrid. “Kok bisa?” Jikalau perusahaan menginginkan aplikasi mobile di platform Android dan iOS, tentu ia harus menyediakan setidaknya dua human-resources (SDM) developer mobile android (dengan spesifikasi Java-Android atau Kotlin) dan iOS (dengan spesifikasi obj-C atau Swift), dan ini berjalan paralel agar tidak memakan banyak waktu. Sudah tentu biayanya tidak murah, apalagi kalau kompleks dan berbasis online, mesti harus menyediakan developer backend+API (agar aplikasi dapat berkomunikasi dengan server) juga. Jadi jangan heran “kok aplikasi seukuran Hape, kecil gitu, mahal banget ngalahin bikin website?” ya iyalah, kecil-kecil gitu, pengembangannya lumayan banyak yang harus dikerjakan.
  Sebagai contoh: aplikasi facebook. Aplikasi tersebut dikembangkan bertahap dan berlangsung sudah lama sekali. Awal rilis, fiturnya sedikit, lama-lama kompleks, selain menghindari lack-of-technology, tentu membuat pengguna juga jadi mudah beradaptasi dengan antarmuka-nya (ada hubungannya dengan User Experience), coba misalkan aplikasi facebook langsung kompleks kayak sekarang pas awal launch 2004 lalu, tentu ditinggalkan pengguna.
• Yang pasti membutuhkan pengetahuan seputar bahasa pemrograman masing-masing platform (iOS dan Android) untuk masing-masing personel dalam tim, ntah itu Project Manager-nya, System Analyst-nya dan juga Desainer Antarmuka-nya. Jadi, jangan menggunakan designer web ya, akan jadi gak nyambung, karena spesifikasinya agak sedikit berbeda.
• Source code terpisah masing-masing platform. Ada hal yang harus dipertimbangkan di dalam menjaga source-code tersebut, di antaranya, tentu platform Android dan iOS diletakkan di dalam repository berbeda di source control/versioning, semisal git (apalagi nanti misalkan fiturnya banyak, versinya banyak, kudu buat branch management), tapi ada juga yang monolitik. Selain itu punya keystore/cert yang berbeda untuk masing-masing platform, dan ini tidak boleh hilang. Selain itu menggunakan IDE dan tools berbeda untuk pengembangan, pengujian dan penerbitan untuk masing-masing platform tersebut.

Keuntungannya? mari kita bahas satu per satu

Dari hybrid programming, di antaranya:

• Murah, cukup menyediakan satu developer, bisa bikin dua platform aplikasi Android dan iOS (dan untuk iOS membutuhkan sistem operasi macOS dan xcode, karena Apple hanya mengizinkan melalui itu di dalam mengembangkan aplikasi iOS)
• Target pasar cukup besar, sekarang banyak sekali aplikasi yang dikembangkan secara hybrid, sebut saja facebook, instagram, airbnb, tesla, dan lain-lain. Ada yang dikembangkan dengan react-native, ionic, atau cordova. Dan ada juga kombinasi antara ionic/react-native dengan cordova (phonegap). Selain itu komunitas developernya cukup besar.
• Low Barrier to Entry. Tidak perlu pesimis jika kita awalnya developer web, kemudian terjun ke dunia mobile apps. “Mengapa?”, karena untuk terjun ke sana, pembatasnya sangat sedikit, adaptasinya pun tidak lama, dalam hitungan waktu sebulan kita dapat menyesuaikan diri dengan platform hybrid dan frameworknya.
• Source code cenderung ramping, dan kemampuan mendukung heterokapabilitas perangkat mobile.
• Mudah di dalam menerbitkan aplikasi, dapat langsung terintegrasi dengan PlayStore dan AppStore.
• Untuk beberapa kasus, mudah untuk di-maintain. Tetapi terkadang merepotkan, apalagi jika ada banyak library yang di-update (tapi bisa diantisipasi dengan mematikan auto-update beberapa library)
• Sangat cepat di dalam mempersiapkan prototype. Butuh menyediakan prototype untuk presentasi dengan calon investor dalam waktu dekat? maka pilihan hybrid begitu tepat.
• Banyak contoh script ataupun library JavaScript yang sudah tersedia di internet, ya karena didukung komunitas yang sangat besar, makanya sangat banyak.

Dari Native Programming, di antaranya:

• Best end-user experiences. Tampilan antarmuka (UI) berdasarkan SDK masing-masing platform (Android ataupun iOS). Di hybrid framework, tampilan aplikasi bisa dibuat 1 tampilan yang kembar identik antara Android dan iOS, namun bisa juga dipisah dengan tampilan berbeda sesuai design pattern masing-masing. Namun, di hybrid framework, tampilan UInya kaku. Kalau di native, tampilan UI mampu mengikuti UI framework bawaan masing-masing platform. Misal, Handphone Xperia dengan Handphone Galaxy mempunyai UI framework berbeda kan? nah, jika kita mengembangkan aplikasi native, aplikasi secara otomatis menyesuaikan dengan UI framework masing-masing OS, atau mengikuti standar SDK dari OS yang terinstall di handphone. Sedangkan hybrid, tampilannya statis, UXnya sedikit berbeda dengan UI di OS yang terinstall di handphone tersebut.
  Berikut ini saya sertakan contoh mengapa hybrid agak kurang dalam urusan UX, terutama dari sisi UInya identik antar platform. (Namun di sisi lain, mempercepat pengembangan).

  

  Perbandingan tampilan web (browser), ios dan android di hybrid yang hampir tidak ada bedanya.

• Highest ceiling for performance. Performa lebih baik. Secara jujur saya bilang, performa native dan hybrid tidak begitu signifikan bedanya. Saya belum pernah melihat ada delay terlalu jauh antara keduanya. Namun, untuk masalah yang melibatkan hardware, performa aplikasi yang dikembangkan secara native lebih baik, response load dan event-nya lebih cepat beberapa detik. Salah satu contohnya bisa dilihat di artikel berikut. Beberapa kendala yang ditemui juga untuk hybrid ketika melakukan push-notification, masih harus dua arah, dalam artian, masih harus melibatkan code secara native dikombinasikan dengan hybrid itu sendiri, makanya jadi agak bermasalah di performa. Sedangkan native, untuk persoalan tersebut tidak jadi masalah.
• Natural look and feel. Masih berhubungan dengan poin pertama, tampilannya lebih natural mengikuti OS yang terinstall di perangkat Android/iOS.
• Dan masih berhubungan dengan poin kedua, karena native, tentu akses layanan ataupun API SDK tentu lebih mudah dan cepat (bisa dibandingkan dengan gambar sistem arsitektur hybrid yang saya cantumkan di atas).
  Atau langsung melihat di gambar perbandingan berikut:

  

  hybrid-native-web comparison

• IDE (Android menggunakan Android Studio dan iOS menggunakan xcode), Development tools dan Dokumentasi tersusun rapih, lengkap dan jelas untuk masing-masing platform Android dan iOS. Untuk Android dapat mengunjungi website https://developer.android.com  dan untuk iOS dapat mengunjungi website https://developer.apple.com.
• Lebih mudah untuk melakukan debug aplikasi di masing-masing IDE.
• Paling sesuai dengan target pasar. Dengan native, kita dapat menyediakan aplikasi yang sesuai dengan masing-masing OS yang digunakan end-user. Toh sampai detik ini masih banyak pengguna yang menggunakan OS Gingerbread, Jellybean dan belum tentu menggunakan OS terbaru (Oreo). Apalagi terdapat back-compatibility dengan perangkat OS yang lama. Dan sudah tentu desainnyapun mengikuti OS masing-masing tersebut. Sedangkan native ya statis seperti saya bilang sebelumnya tadi.
• Keamanan aplikasi lebih baik. Pengembangan aplikasi secara native dibandingkan hybrid dianggap lebih aman, dengan fakta bahwa aplikasi native memanfaatkan fitur keamanan terintegrasi khusus dengan platform OS. Berbeda dengan hybrid, yang menempel pada webview, tentu beberapa pihak berpandangan bahwa hybrid rentan akan serangan injeksi ketika mengakses API tertentu di server.
  
  
  Beberapa kejadian serangan ke aplikasi mobile adalah seorang hacker melakukan reverse-engineering aplikasi untuk memperoleh akses resource (seperti source-code, gambar, file database, dll) dan juga menggunakan aplikasi malicious yang berjalan secara background untuk mencuri/menyadap data pengguna. Beberapa waktu lalu, saya pernah membahas masalah keamanan aplikasi ini, di tulisan berikut.

Kesimpulan dari artikel ini….

Sekarang sih tidak jadi persoalan yang rumit lagi,  mau menentukan pilihan ke hybrid ataukah ke native.  Tergantung kebutuhan saja. Pertimbangannya seperti yang saya tuliskan di atas. Semoga menjawab kedua pertanyaan tersebut.

Beberapa perusahaan memilih native karena ingin menghindari masalah-masalah pasca deployment, apalagi pass mass-production, kekhawatiran di perangkat pengguna tidak berjalan sebagaimana mestinya. Namun, ada pula perusahaan yang memilih dengan hybrid, karena ingin cepat launch, target waktu mepet, mungkin faktor bisnis atau faktor budget (biasanya sih yang seperti ini startup). Beberapa kasus yang terjadi, beberapa startup ingin mengembangkan sebuah aplikasi, saya tanya alasannya, karena uang dari investor sudah dikucurkan, namun si investor memberikan target waktu, waktunya mepet, maka dipilih hybrid. Di satu sisi juga menguntungkan si startup ini, karena cost lebih hemat, mampu membuat 2 platform sekaligus (android dan ios). Apalagi perusahaan yang model seperti ini tidak mempermasalahkan pasca-production “yang penting ada dulu produknya, urusan testing dan perbaikan bisa sambil jalan”.

Monggo yang mau berdiskusi, tanya-jawab dipersilahkan, toh saya juga masih newbie yang masih harus banyak belajar.

Quick Android Review Kit

Linkedin punya repo yang menarik hati: https://github.com/linkedin/qark

serupa dengan mobile top 10 security vulnerabilities via owasp yang pernah saya bahas di tulisan sebelumnya.

Kali ini, saya mencoba sebuah tool bernama “QARK” (Quick Android Review Kit) yang terdapat di repo punya linkedin. Tool ini dikembangkan menggunakan python dan tool ini mampu menganalisis dengan mudah celah keamanan di aplikasi Android yang kita kembangkan.

Tanpa perlu memeriksa satu per satu, hanya dengan mengetik satu baris perintah (bisa dipakai untuk memeriksa apk ataupun sourcecode), dan output dari tool ini adalah memberitahukan persentase celah keamanan dan juga apa saja yang berbahaya dan harus dihindari.

Baru saja saya coba di laptop saya, dan sebagai bahan percobaan, saya mencoba salah satu sourcecode aplikasi project saya sebelumnya. Dan di screenshot di bawah ini, ada beberapa celah keamanan yang diperlihatkan dengan persentase. Setelah semua dicek satu per satu, di bawahnya dibahas satu per satu, apa saja yang menjadi celah agar dapat diperbaiki segera oleh developer.

Persentase tingkat celah keamanan di aplikasi yang dikembangkan

Beberapa “suggest” yang diberikan QARK ini agar saya bisa memperhatikan dan memperbaiki celah keamanan tersebut

Anda memerlukan Python terinstall di OS laptop/PC untuk mencoba Qark ini. Silahkan download python di sini. Setelah selesai download python. Bisa dicoba install qark melalui terminal dengan cara, download terlebih dahulu sourcecode qark tersebut dari github. Kemudian jalankan terminal, arahkan terminal ke folder tempat sourcecode qark tersebut disimpan di harddisk anda. Lalu ketikkan perintah berikut di terminal:

$ python qarkMain.py [enter]

Setelah berhasil, sebuah jendela qark akan muncul di layar, dan tinggal dipilih deh apa yang mau dilakukan dengan tool kit ini. Selamat mencoba.

Memperkuat keamanan di sisi aplikasi mobile Android

Saat saya menerima hasil audit tahap pertama, saya kaget, ternyata aplikasi yang saya buat, datanya “telanjang”, kelihatan semua. Loh? padahal sudah saya enkripsi dengan RSA public-key, tapi kok URLnya keliatan, data yang di-POST keliatan, dan tidak rusak sama sekali datanya, padahal sudah pakai koneksi https (SSL). Saat itu ternyata masih belum cukup. Saya menerima hasil audit tersebut dan melihat software apa yang dipakai oleh IT Security Engineer-nya: ternyata yang dipakai adalah tool Burp Suite (https://portswigger.net/burp), Nmap, Charles proxy, dan beberapa baris script yang dijalankan di bash di HP rooted. Sama seperti tool security testing atau pentest (penetration test) lainnya seperti Wireshark, OWASP (Open Web Application Security Project) dan Back Track . Tools yang dipakai bertujuan untuk menguji beberapa standar pengujian di aplikasi mobile. Bisa dicek di web berikut ini dari M1 sampai dengan M10.

Beberapa aspek yang diuji yang menjadi mobile risk base line adalah:

• improper platform usage (M1),
• insucure data storage (M2),
• insecure communication (M3),
• insecure authentication (M4),
• insufficient cryptography (M5),
• insecure authorization (M6),
• client code quality(M7),
• code temparing (M8),
• reverse engineering (M9),
• dan extraneous functionality (M10)

Mari kita bahas satu per satu dengan singkat (saya sertakan link pelengkap di setiap bahasan agar bisa dijelajah lebih jauh)…

Untuk mengatasi issue M1, platform yang digunakan harus jelas, codingan yang kita gunakan juga harus terstandar sesuai dengan guideliness di SDK Android. Ini untuk meminimalisir improper platform usage.

Untuk M2, biasanya penyakit ini terjadi kalau developer menyimpan atau menampilkan data di Log, mungkin maksudnya biar mudah untuk debugging, tapi yang kayak gini biasanya akan jadi masalah ketika ada user yang test aplikasi kemudian membaca lognya dari tools seperti adb logcat atau ddms. Atau dia menyimpan data pengguna di db sqlite yang bisa di-extract dari APKnya dan dibaca pakai tools SQlite browser. Atau menyimpan ke dalam flat file XML yang ternyata itu data penting. Jadi, sebaiknya hal tersebut dihindari. Bagaimana caranya log tersebut hilang pada saat kita build APK tanpa perlu capek remove atau comment satu per satu line by line di source code. Tenaaang..di Android kan ada proguard, bisa matiin log pakai proguard tersebut dengan cara menambahkan line berikut di file proguard:

-assumenosideeffects class android.util.Log {
    public static boolean isLoggable(java.lang.String, int);
    public static int d(...);
    public static int w(...);
    public static int v(...);
    public static int i(...);
}

Atau lebih jelasnya cek di laman berikut.

Untuk kasus M3, insecure connection biasanya terjadi ketika kita menggunakan koneksi http (port 80), bukan https (port 443). Emang apa bedanya? jika masih belum paham bisa main ke web ini. Selain itu yang menjadi concern ialah koneksi https tidak sepenuhnya aman, karena bisa dinetralisir dengan menggunakan proxy atau vpn yang insecure. Jadi ketika aplikasi hit ke server, sebelum sampai ke server, datanya melalui proxy dulu atau vpn dulu, tidak langsung ke server. Ya kena tangkap deh datanya terbaca jelas. Apalagi kalau tidak dilengkapi dengan trusted SSL. Tambah ketahuan. Tadi saya mengira dengan saya menguji sendiri aplikasi yang saya kembangkan dengan menggunakan Charles Proxy di MacOS, saya install cert dari Charles, kemudian jalankan aplikasi di Android. Tadaa..saya senang ternyata datanya sudah tidak terbaca, tapi begitu teman bilang “jangan lupa SSLProxy-nya disetting, mas”, pas saya setting untuk host server yang digunakan di aplikasi, kemudian tekan OK, kemudian jalankan kembali aplikasi yang saya buat. “loh???? kok datanya terbaca 100% tidak ada yang kacau..waduh”. Ternyata masih ada celah. Untuk mengantisipasi hal tersebut, di Android sudah ada standar pinning SSL, bisa dilihat di web berikut. Jadi, ketika koneksi tersebut untrusted SSL, aplikasi dapat memutuskan hubungan koneksi sehingga tidak terhubung ke jaringan yang tidak aman. Bagaimana cara mengakali VPN atau proxy. Di android bisa diantisipasi dengan cara mem-bypass proxy. Caranya seperti ini:

try {
    conn = (HttpsURLConnection) url.openConnection(Proxy.NO_PROXY);
    try {
        sf = new SSLSocketFactory(ksTrust);
        sf.setHostnameVerifier(SSLSocketFactory.STRICT_HOSTNAME_VERIFIER);
    } catch (NoSuchAlgorithmException e) {
        e.printStackTrace();
    } catch (KeyManagementException e) {
        e.printStackTrace();
    } catch (KeyStoreException e) {
        e.printStackTrace();
    } catch (UnrecoverableKeyException e) {
        e.printStackTrace();
    }

} catch (SocketTimeoutException | java.net.ProtocolException e) {
    e.printStackTrace();
} catch (ConnectException e) {
    e.printStackTrace();
} catch (IOException e) {
    e.printStackTrace();
}finally{
    conn.disconnect();
}

Dari contoh code di atas, koneksi HTTPS tersebut diset parameter NO_PROXY untuk mem-bypass proxy di device Android ketika aplikasi terhubung internet. Selain itu terdapat SSLSocketFactory dengan menggunakan KTrust (ini contoh variable dari Keystore yang digenerate dari file certificated trusted SSL). Dengan begini ketika koneksi untrusted otomatis koneksi tersebut terputus (conn.disconnect() di bagian finally). Selain itu bisa juga koneksi tersebut diset DIRECT Connection dengan cara seperti ini. Tujuan bypass proxy ini juga agar tools pengujian penetrasi di atas semacam Charles Proxy dan SandroProxy tidak dapat bekerja dengan baik (karena kedua tools tersebut menggunakan proxy). Bacaan tambahan soal Socket Proxy.

Untuk kasus M4, insucure authentication, bisa diantisipasi dengan 2-step-verification, makanya saat ini standar di aplikasi Android seperti itu, dengan menggunakan PIN via SMS atu telepon, atau dengan menggunakan biometrik touchID (sidik jari). Selain itu perlunya memberitahukan pengguna soal level kuat tidaknya password yang ia gunakan. Makanya di form pendaftaran biasanya di bagian password dicantumkan level kekuatan password : very weak, weak, medium, strong, very strong. Dan jangan lupa, dihimbau agar jangan membuat fitur untuk menyimpan mpin atau password ke database local atau di-sharedPreferences. Bila ingin membuat fitur “remember password” ya perlu dibuat ada expirednya di kedua sisi (backend dan aplikasi mobile).

Untuk kasus M5, insuffienct cryptography.. rendahnya tingkat kriptografi membuat data yang terenkripsi dengan mudah didekripsi. Di aplikasi dapat ditambahkan mekanisme enkripsi dua arah (server dan aplikasi), jadi server mengirimkan public key atau bisa juga bikin API untuk generate userAPIKey yang akan digunakan aplikasi untuk enkripsi RSA, bisa menggunakan base64 atau yang lain. Contohnya banyak di stackoverflow, atau bisa lihat di sini. Ada juga yang sudah dalam bentuk lib yang bisa langsung dipakai di sini (saya rekomendasikan yang ini, karena sering saya pakai untuk beberapa aplikasi Android). Umumnya biar aman, publicKey dan userAPIKey digenerate dari server, tinggal user request via aplikasi ntah itu ketika splash screen atau ketika di landing screen (berjalan secara background ya..jangan ditampilin). Ketika userAPIKey dan publicKey diperoleh, aplikasi tinggal memakai publicKey, ditambah dengan deviceID, module, dan exponent untuk enkripsi dengan RSA, bisa dipakai untuk enkripsi pin, password, atau data penting lainnya. Cara mendapatkan value module dan exponent bisa berkunjung ke web berikut.

Untuk kasus M6, pernah tau gak kalau kita mau install aplikasi, akan dicantumkan popup permission? nah, di situ aplikasi memiliki otorisasi untuk mengakses beberapa komponen dari OS device kita. Contoh, ketika kamu install aplikasi kamera, maka ketika install dan jalankan akan muncul popup meminta permisi untuk mengakses kamera (camera permission), atau aplikasi sticky notes, ketika kita install dan jalankan, akan muncul pop-up meminta izin mengakses storage, dll. Nah, pentingnya bagi pengguna untuk waspada, aplikasi apa yang kita install dan izin apa saja yang kita berikan. Jangan sampai kita menginstall aplikasi senter, ternyata permissions yang diminta banyak: minta izin akses akun google, minta izin akses lokasi, dll…kan jadi aneh. Nah, dari sisi development, permission ini dicantumkan di manifest aplikasi. Dan ketika aplikasi hendak menjalankan suatu metode yang berhubungan dengan device, biasanya permission ini ikut triggered. Jangan sampai kita menambahkan permission yang tidak ada hubungannya dengan tujuan aplikasi tersebut.

Untuk kasus M7, pernah liat codingan orang lain yang acak-acakan? atau gak perlu jauh-jauh, cek aja codingan sendiri 5 tahun yang lalu, mesti masih berantakan..hehe. Nah, code yang jelek seperti ini akan jadi masalah, rawan bug, rawan celah keamanan. Maka berlatihlah menulis code dengan baik dan benar hehe. Apalagi sekarang sudah ada beberapa standar atau pattern di dalam penulisan code Android. Dulu kenal MVC -> Model, View, Controller? nah di Android, selain MVC, ada juga pattern MVVM dan MVP. Dengan menerapkan pattern tersebut, otomatis kita sudah membiasakan codingan yang lebih rapih dan baik.

Untuk kasus M8, pernah liat atau pernah melakukan install APK mod sebuah games yang duit/emerald/koinnya bisa 99999999. Mungkin pernah main Candy Crush atau game lain yang koinnya 999999 (unlimited)? nah, APK tersebut adalah apk yang sudah dimodifikasi alias sudah ditambahkan code lain yang tidak resmi. Biasanya, APK itu di-build tanpa obfuscated. Jadi, ketika APK didecompile, ya codenya terbaca jelas. Ya sudah, akhirnya si penyusup dapat menambahkan code lain-lain yang berbahaya, tinggal compile ulang dan sebarkan. Nah, bahayanya, ketika kita sebagai pengguna tidak tau kalau APK tersebut disisipi code berbahaya, ntah itu mengambil data akun kita (facebook, dll), atau merekam aktivitas kita di HP. Untuk mengantisipasi agar ketika APK di-decompile, codenya rusak (obfuscated), bisa menggunakan ProGuard dan aktifkan minify APK dari gradle. Selain itu di sisi server juga ditambahkan pengecekan apakah APK tersebut original ataukah mod, bisa dengan generate appID setiap update, jadi ketika versinya outdated atau appID tidak valid, maka tidak dapat terhubung ke server. Atau mekanisme pengecekan apakah APK rooted ataukah resmi. Pernah lihat kan? gak bisa install apk tertentu (misal netflix), karena HP/device Android kamu rooted? nah itulah bagusnya sisi keamanan app. tersebut.

Reverse engineering (M9), sudah pernah install aplikasi android “Show Java” ? coba deh install di PlayStore, atau klik tautan ini. Aplikasi tersebut memungkinkan aplikasi yang terinstall di device Android untuk di-decompile. Jadi, inputnya APK, outputnya jadi source-code Java (di-reverse engineering). Nah, kalau tidak di-obfuscate, codingan kamu ya akan terbaca jelas semua melalui aplikasi reverse engineering tersebut. Jadi source-code java, xml, dan lain-lain dari aplikasi tersebut dapat dilihat, dipelajari dan bahkan bisa dicari celah keamanannya. Bahayanya, jika kamu menaruh API_KEY atau hal-hal lain yang mestinya bersifat rahasia, jadi ketahuan deh. Cara antisipasi ini ya dengan di obfuscate melalui proguard dan atau..dengan minifyEnabled diset “true” di gradle app. aplikasi kamu (di bagian buildTypes>release). Selain cara menggunakan app “show java” di atas, apk kamu sebenarnya bisa dengan mudah di-reverse engineering dengan mengganti extensi apk menjadi zip atau tar. Misal, nama filenya: app-release.apk, coba deh ganti jadi app-release.zip, terus extract… Tadaaa… keliatan semua tuh folder dan file java beserta xmlnya. Makanya perlu diantisipasi dengan obfuscate itu tadi. Cara modding apk yang banyak dilakukan cracker untuk beberapa games ya dengan cara inject file atau replace file yang ada di dalam package apk tersebut (diubah jadi ext .zip terlebih dahulu) dengan file yang sudah dimodifikasi. Nah ini dia celahnya, jadinya ya APKnya sudah tidak signed lagi. Makanya penting menginstall apk yang sudah signed. Di PlayStore juga kalau mau publish apk mesti signed menggunakan keystore. Jangan install apk sembarangan ya.

Extraneous Functionality (M10), hal yang fatal yang sering ditulis developer di code aplikasinya adalah mengakses API dengan menaruh parameternya pada URL (dengan method GET), yang terkadang, bila si cracker mampu melakukan debug aplikasi, kemudian membaca URL APInya, kemudian membuat “backdoor“, mencobanya di browser, tadaa..ternyata berhasil diakses. Nah, dari sisi backend semestinya hal ini bisa dihindari. Jangan sampai API bisa diakses via url. Dan di Android sendiri sudah ada cara yang aman, misal menggunakan retrofit atau okhttp, dengan method POST dan tentunya seperti yang dibahas sebelumnya, parameternya di-enkripsi. Selain itu, matikan semua debug atau Log yang dipasang di app agar tidak ada data di background yang terbaca oleh orang yang tidak seharusnya. Periksa semua API endpoint yang diakses dari mobile app, apakah sudah tertulis dengan benar dan periksa semua log statement di source-code, jangan sampai ada sesuatu dari backend terbaca jelas di log (walaupun tujuannya sekedar buat debugging, tapi yang seperti ini bisa jadi celah).

Sekian pembahasan dari saya. Semoga bermanfaat bagi semua, dan mampu membuat code yang well-written, dan ini juga menjadi pengingat bagi diri saya pribadi yang masih perlu banyak belajar.

 

 

Cara mudah install/update gradle di Mac

Mungkin masih ada yang bingung bagaimana cara mengupdate gradle secara manual, atau terlalu pusing dengan banyaknya step di internet. Nah, di mac ada cara mudah dan cepat untuk meng-install atau meng-update gradle. Lakukanlah langkah-langkah berikut.

Di mac, buka terminal, kemudian ketik perintah berikut untuk menginstall SDKMan:

curl -s https://get.sdkman.io | bash

Setelah selesai, lanjut ketikkan perintah berikut:

$ sdk install gradle 3.5

Setelah selesai install gradle, cek di Android Studio apakah gradlenya sudah versi 3.5 atau belum, dengan cara masuk ke Terminal-nya Android Studio, kemudian ketik perintah berikut:

Gradle --version

Jika berhasil, maka hasilnya seperti pada gambar di bawah ini:

Selesai 😀

Mempercepat proses gradle build

Masalah yang sering dihadapi seorang developer Android adalah berhadapan dengan IDE Android Studio. IDE ini memang dikenal memakan banyak resource RAM dan harddisk, bahkan RAM yang disarankan cukup besar 8 GB. Jika di bawah itu ya, siap-siap saja menunggu lama compile aplikasi sambil ditinggal tidur, ngopi dan makan.

Jika sudah memenuhi spesifikasi install Android Studio, namun dirasa masih cukup lambat, terutama ketika melakukan “build” aplikasi menggunakan gradle, ada baiknya mencoba tips berikut:

1. Update versi gradle ke versi terbaru. Saat ini (April 2017) versi terbarunya adalah versi 3.5 (https://docs.gradle.org/current/release-notes.html)
   Cara updatenya bisa ikuti di tutorial berikut: https://gradle.org/install
2. Buat file baru dengan nama gradle.properties, taruh di lokasi berikut:

   /home/<username>/.gradle/ (Linux)
   /Users/<username>/.gradle/ (Mac)
   C:\Users\<username>\.gradle (Windows)

   Setelah itu copas teks berikut ke gradle.properties:

   org.gradle.daemon=true
   org.gradle.parallel=true
   org.gradle.jvmargs=-Xmx2048M   

   Untuk org.gradle.jvmargs, apabila RAM yang dimiliki sekitar 4 GB, cukup set di angka 2048M, namun jika lebih ya lebih bagus, bisa diset di angka 8192 bagi yang memiliki RAM sekitar 16 GB.
   Jika sudah, save, dan lanjut ke bagian android Studio. Buka Preferences/Settings Android Studio, masuk ke bagian “Build, Execution, Deployment”, pilih “Gradle” dan beri centang pada “Offline Work” seperti pada gambar di bawah ini, dan set directory-nya ke lokasi gradle.properties yang sudah dibuat tadi.
   

3. Beri parameter –offline pada Compiler seperti pada gambar di bawah ini:
   
4. Masuk ke Aplikasi yang sedang dibuat di Android Studio, klik build.gradle.
   Setelah itu tambahkan line berikut di dalam tag android:
   

   dexOptions {
       incremental true
       javaMaxHeapSize "4g"
   }

   beri angka “4g” apabila RAM yang dimiliki 4GB, dan beri angka 8g bila RAM yang dimiliki 8GB. Dokumentasinya ada di sini: google.github.io/android-gradle-dsl/current/

5. Perbesar heapsize untuk mempercepat build di gradle.properties dengan menambahkan parameter berikut:

   # Specifies the JVM arguments used for the daemon process.
   # The setting is particularly useful for tweaking memory settings.
   # Default value: -Xmx10248m -XX:MaxPermSize=256m
   org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

   *peringatan: memperbesar heapsize beresiko membuat software lain yang dibuka menjadi lambat. Karena RAM akan terfokus ke gradle Android Studio.

6. Done, selamat mencoba 😀

Testing app di Android Studio menggunakan device Android via Wifi

Bagi yang ribet menggunakan kabel untuk melakukan pengujian aplikasi ke device/hardware Android, anda dapat mengikuti cara mudah berikut ini. Di artikel ini diberikan 2 opsi melakukan pengujian aplikasi dari Android Studio ke device Android dengan perantara nirkabel/wifi.

Metode Pertama.

• Nyalakan debugging mode di Pengaturan HP/device Android.
• Koneksikan kabel usb dari laptop/PC ke HP Android (ini untuk inisialisasi saja, seterusnya tidak diperlukan lagi)
• Gunakan command prompt/terminal yang sudah bisa menggunakan perintah “adb” (atau ya kalau belum paham, tinggal arahkan saja ke path lokasi SDK Android dan masuk ke directory sdk/platform-tools/ di dalamnya ada batch file adb)
• Ketik:
  adb tcpip 5555[enter]
• setelah itu cek IP Address HP/device Android dengan cara ketik:
  adb shell netcfg
• Setelah anda mengetahui IP Address dari device/HP anda, dicatat/diingat, kemudian ketikkan perintah dengan format berikut:
  adb connect [IP_Address_device]:5555
  Contoh: adb connect 192.168.1.6:5555[enter]
  nanti akan muncul response:

  “connected to 192.168.1.6:5555” (ini tidak perlu diketik ya..ini akan muncul kalau anda berhasil menghubungkan HP/device android ke laptop via IPaddress secara wireless)

• Setelah itu lepas kabel usb dari HP/device Android dan laptop/PC anda.
• Dan selamat menikmati, Android Studio anda sudah bisa melakukan testing ke device/HP Android tanpa terhubung dengan kabel usb.
• Bila anda sudah selesai melakukan testing aplikasi, anda dapat menutup koneksi wireless dari HP ke laptop anda dengan perintah berikut:
  adb -s [IP_address_device]:5555 usb [enter]

Cukup ribet ya cara di atas? atau masih ada yang gagal mencoba? Move-on dong..mari coba metode ke-dua.

Metode Kedua.

1. Dari Android Studio kamu, masuk ke Preferences, dengan cara:
   Android Studio: Preferences/Settings->Plugins->Browse Repositories
2. Install Plugins dengan mengetikkan: “Android WiFi ADB” dan pilih install sesuai petunjuk di layar.
3. Setelah selesai Install, apabila diminta restart, pilih “restart”
4. Selamat, plugins Android WiFi ADB berhasil diinstall. Sekarang bagaimana cara menggunakannya ya? Lanjut ke step ke-5.
5. Mau testing di device Android, tentu jangan lupa nyalakan DEBUGGING mode (pokoknya wajib, masih belum ngerti? bisa bertanya atau cari diinternet, seharusnya developer Android tau langkah mudah mengaktifkan debugging mode ini)
6.  

   Cari opsi “DEBUG OVER TCP/NETWORK” di dalam Menu Pengaturan/Settings device/HP android kamu>Developer Options.

7.  

   Pasang kabel USB dari HP ke Laptop/PC, dan pastikan keduanya (PC dan HP) menggunakan jaringan internet yang sama (ntah hotspot ataupun wifi)

8.  

   Pilih icon ANDROID Wifi ADB di Android Studio.

9.  

   Setelah itu, device/hp kamu akan terdeteksi di situ, dan siap digunakan untuk testing (jangan lupa cabut kabel USBnya yah pas menggunakan plugins Android Wifi ADB ini)

Selamat mencoba.