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 obfuscatedJadi, 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.

 

 

Advertisements

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.

 

Project Hunter wanna be

Kemarin ada teman yang berdiskusi mengenai proyek, teman saya ini dari pegawai kantoran yang akhirnya berhenti dan memilih membangun usaha sendiri dan menjadi project-hunter.
Diskusi panjang lebar.. hingga 2 hari tetap dilanjut dari chat sampai telpon.
Dari diskusi ini saya mendapati beberapa yang mesti dikoreksi, dan smoga menjadi pelajaran bersama..

  1. Jangan pernah membawa perkara teknis pengembangan ke klien (apalagi kalau kliennya gaptek). Cukuplah internal saja yang mengetahui perkara teknisnya bagaimana. Kecuali, si klien memang punya tim engineer yang bakal turut campur di dalam proyek ini, dan mereka harus mengetahui hal tersebut atau emang si klien mengerti soal teknologi dan ingin mengetahui teknologi apa yang nantinya diterapkan di produk software yang ia minta, dan biasanya si klien duluan yang buka omongan teknis, ya kita sebagai vendor TI menjawab pertanyaan tersebut dengan baik dan benar.
    Terkadang salahnya di sini, pas meeting, kita yang merasa sudah jago develop aplikasi. malah menyampaikan hal-hal teknis dari A sampai Z di software yang ingin ia bangun, kalau yang seperti ini yang ada klien cm “angguk-angguk” padahal ya bingung (masuk kuping kanan keluar kuping kiri). Kesan ke kliennya tidak kita dapatkan sama sekali, malahan maksud hati ingin meyakinkan klien dengan cara menjelaskan teknis pengembangan, mulai dari bikin flow diagram/flowchart, bikin pake framework apa, codenya seperti apa, versi berapa, terus nanti pakai web service apa, dan lain-lain, eh malah tidak berkesan.
    Ada baiknya sampaikan presentasi yang bagus dalam bentuk gambar, flow aplikasinya sudah dlm bentuk tampilan antarmuka software, dan kita jelaskan tiap step-nya dari login sampe logout di gambar tampilan antarmuka tersebut, sehingga si klien sudah dapat gambaran, seperti apa nantinya tampilan software tersebut, dan ini lebih meyakinkan daripada kita bawa-bawa hal teknis pengembangan. Dan di situ juga diharapkan klien memberi feedback, kira-kira dari gambar yang disajikan adakah yang kurang pas menurut pengguna, misal warna, susunan menu, dan sebagainya. Atau syukur-syukur kita sudah punya contoh dari prototype/portofolio yang kita punya.
  2. Kebanyakan klien tidak mengetahui apa yang mereka butuhkan, mereka mengikuti trend atau dari apa yang ia ketahui saja. Misal : dia tau Windows itu mudah dipakai, karena memang ia taunya cuma OS itu, dan belum coba Linux atau OSX. Ketika dikasih lihat Linux, mereka bingung, belum terbiasa. Nah sama kasusnya ketika disuruh memilih server, kita menyarankan menggunakan Linux CentOS, si klien lebih memilih OS Windows 10, padahal kebutuhannya si klien ini tidak cocok diimplementasikan di OS tersebut. (ini cuma contoh kecil, ada banyak lagi contoh lain, seperti keinginan klien supaya tampilan softwarenya seperti Facebook, ingin akses message-nya secepat Whatsapp/telegram, padahal si klien belum memahami kebutuhannya seperti apa, ketersediaan resourcenya bagaimana, budgetnya seberapa, jatuhnya kebanyakan keinginan yang tidak tepat sasaran)
    Maka dari itu, coba tawarkan solusi alternatif, misal ketika kita mendapat order membuat aplikasi mobile. untuk broadcast SMS, coba tawarkan alternatif, tulis di proposal dan ketika meeting, sampaikan yg anda tawarkan tersebut yg mungkin bisa menjadi solusi bagi klien: “pak, bagaimana kalo broadcastnya mirip bbm/wa, ntar muncul di smartphone konsumen, promonya apa aja..kalo sms takutnya regulasinya panjang, apalagi sekali broadcast terbatas, dan mungkin ada kendala delay”..syukur-syukur klien angkut dua tawaran yang kita sampaikan, proyek sms broadcast dapet, ditambah proyek messanger jg dapet.
  3. Buang sedikit ego, ketika harga proyek ditawar klien terlalu menyakitkan, cobalah sedikit tenang, berpikir apa yang bisa kita coba agar tetap goal mendapatkan proyek tersebut.
    Dengan berpikir tenang, kita coba koreksi apa saja bagian yang bisa kita kurangi standarnya (tanpa mengurangi esensi pemenuhan kebutuhan klien), misal harga desainnya dikurangi, nego lagi dengan designer, kira-kira apabila harga dikurangi segini bakal dapet seperti apa, dan sebagainya..atau ditambah waktunya, biasanya semakin tipis timeline, harga tentu semakin tinggi, karena jam kerja/hari tentu menjadi tinggi, mungkin dengan melebarkan timeline (misal ditawarkan waktu pengerjaan 3 bulan, kita tawarkan menjadi 5 bulan), mengurangi “beban” kerja dan tentu harganya bisa dikurangi. Atau tawarkan alternatif harga modular : “bapak, silahkan dilihat list harga dari kami, ini kami pasang per module : “Bapak bisa cek untuk kebutuhan yang bapak minta standar harganya segini, namun karena bapak meminta kami mengerjakan bagian X, Y, Z, saya coba tawarkan harganya per module, sehingga bapak bisa pilih yang mana yang akan bapak ambil saat ini dan yang mana bapak pending. Dan apabila nanti ingin melanjutkan kerjasama ini, siapa tau ke depannya, bapak meminta kami mengembangkan modul-modul yang bapak belum kesampean karena terbatasnya budget di penawaran berikutnya.”

Kira-kira seperti itu tips hari ini.
Sekian dan terima kasih 🙂

HTML5 atau Native?

Kemarin baru saja membaca perkembangan aplikasi facebook di Android maupun iOS. Awalnya facebook menerapkan html5 di aplikasi mobilenya, kemudian akhirnya beralih ke native. Pada tahun 2011 lalu, facebook masih memakai html5, karena banyak keluhan dari pengguna, mendapatkan rating bintang 1 & 2. Akhirnya beralih ke native sampai dengan tahun ini. Hasilnya, pengguna meningkat 200%.

Konsep “build once, deploy everywhere” tidak selalu menjadi solusi untuk menghasilkan produk yang cepat dan tepat. Tentunya beda Sistem Operasi, beda pula pattern UInya (kecuali jenis games), tampilan yang dihasilkan terkadang nampak asing di sisi pengguna masing-masing platform. Pada waktu pengguna smartphone Android mencoba aplikasinya : “loh kok tampilannya mirip di iOS?”, padahal experience pengguna di iOS dengan di Android itu berbeda.

Pelajaran yang diambil adalah terapkan teknologi sesuai desain, bukan membuat design sesuai teknologi. Buatlah design untuk berbagai jenis platform terlebih dahulu, kemudian lihat apakah bisa diterapkan dengan model “build once, deploy everywhere”
Kalau tidak bisa ya, perlakukan dengan native.

Jangan pernah melakukan : “ah, yang penting cepet jadi aplikasinya, sesuai keinginan kita” ternyata malah fatal di belakang karena ego kita tersebut. Perlu riset lebih dalam bagaimana konsep desain masing-masing platform, perilaku pengguna, biaya dan waktu agar pengembangan aplikasi tersebut benar-benar siap dan terarah.

Fighting Spirit mahasiswa sekarang lemah!

Pelajaran yg saya dapatkan hari ini dari pak Lukito dari ngobrol di plurk.

mungkin banyak orang bisa berbagi ilmu, tp belum mampu mengajarkan mereka untuk mandiri, menyadari hak dan kewajibannya. Hanya fokus pada hal membagi, tidak mengajarkan..
Alhasil, kebanyakan mahasiswa itu fighting spiritnya lemah, kurang menghargai orang lain, menunggu dijemput, bukan datang mencari, dan terlalu fokus pada hal yang ada.

Karena ini lagi musim ributin capres, saya coba berikan analoginya, seperti calon pemerintah yang punya visi : “menaikan tunjangan 3x lipat”, tp tanpa menjabarkan misinya hal-hal yang bisa membuat rakyatnya mandiri, mengajarkan mereka buat lebih berkualitas. Jatuhnya, ketika pemerintah memberikan apa yang rakyatnya inginkan, selanjutnya rakyat nanti akan banyak menuntut pemerintah (manja).

Dan ini ada beberapa contoh yang dihadapi :

“maaf, mas kuota internet sy gk cukup, boleh copy gk mas, kita ketemuan, mas”

“maaf/maklum masih newbie, mas, ajarin dong dr dasar”

“saya googling ga nemu, mas”

“mas ada tutorial bahasa indonesia gk? sy gk bisa baca yg bhs inggris”

“mas, sy pake cara ini, tp gagal, bisa dicekin gk mas, errornya?”

“mas, sy bikin aplikasi kyk gini, itu rasanya kok jd panjang bgt, ada cara singkat gk mas?”

kadang saya gk suka dengan orang yg apa adanya… ujung2nya ada apanya… gk mw usaha lebih keras..
malah bbrp message FB saya diamkan saja pas lagi sibuk ataupun karena terlalu sering mendapatkan seperti itu. Kurang sabarnya saya.

Jaman sekarang, internet murah, hdd murah, jaman sy kuliah, flashdisk max. 128 MB, itupun mahal, duit jg ngepas dikirimnya, internetpun mesti di warnet, krn blm ada model modem dan provider internet murah. Apalagi zaman dosen-dosen kita? 
Yang sewajarnya, mencari informasi itu lebih mudah di zaman sekarang.

Bila tidak bisa bahasa inggris, ya belajar, masih sempat belajar, daripada waktu banyak habis buat ngegame dan berjejaring.

Lalu bagaimana etikanya?
Ini masalah yg saya hadapi dengan panitia sebuah workshop, saya berkeluh kesah di plurk, dan pak Lukito memberikan tanggapan :
“Bilang saja klo anda tdk suka diperlakukan dmk. Tunjukkan bhw apa yg mrk lakukan itu tdk menghargai pembicara..Ttg jadwal, ttg HR, ttg pemberitahuan yg mepet. bbrp panitia mhs sptnya perlu diberitahu ttg adab terkait pembicara, jd ajarilah mrk. Kalau saya, saya ga akan mau disuruh menemui panitia atau mengunduhkan file2 yg diperlukan utk demo..Bukan apa2, tp justru utk ngajarin mrk ttg hak dan kewajiban masing2. Sptnya mhs panitianya blm pengalaman mengadakan acara2 gini ya”

dan ini membawa hikmah ke yang lain, bahwa pentingnya membagi pengetahuan ke yang lain tapi juga mengajarkan, ya mengajarkan mereka tentang hak dan kewajiban.

Jadi, ketika orang bertanya, coba jawab, tp jangan abaikan untuk beritahukan ia bahwa alur belajarnya yg benar ttg ilmu tsb seperti ini.

Dengan memberikan mereka : arah yg benar, cara yang baik dalam belajar, dan juga mengajarkan mereka buat semangat belajar (dengan memotivasi dengan arah yang kita beri tersebut), insya’ Allah, mereka bisa mandiri mencari informasi sendiri.
Karena, mereka tentu tersesat dalam belajar, bingung harus belajar apa dulu. Saya juga dulu mengalami demikian.

Terus ajarkan mereka, “mas, kalo bertanya, sebaiknya spesifik, ke kasus yg dihadapi, jangan minta ajari dari awal, kasian saya nantinya mas, membagi banyak waktu buat mas, padahal saya ada hak dan kewajiban.. Jadi coba aja dulu, pelan-pelan, pelajari dari berbagai sumber..ini saya kasih link-link yang bagus, terus coba bikin aplikasi sederhana, seperti mengganti background, rumus menghitung luas misalnya, atau deteksi lokasi sederhana, baru kalo kesulitan, bertanyalah ke pokok masalah. Jangan dateng-dateng langsung nanya, dan minta ajarin bikin aplikasi yang lebih besar.”

Tp jangan takut juga bertanya, bila mengasyikan, malah terkadang orang yang kita tanyai itu ikut2an belajar dari situ. Apalagi mereka bisa mengakrabkan diri dengan baik. Datang bawa masalah, tentu harus diceritakan kronologinya, sedang buat aplikasi apa, errornya muncul apa, terus input-outputnya apa… jangan datang-datang, copas sourcecode, dan minta carikan errornya 

Semoga ini bisa memberikan pelajaran bersama, khususnya bagi diri saya pribadi. 🙂

Mohon maaf bila menyinggung, semoga tidak dinilai negatif  😀

UI Automation di Android (bagian dari unit testing)

pernah melakukan Unit Testing di sebuah aplikasi?

Nah, berikut ini adalah contoh Automation test di Android. UI Automation Test merupakan bagian dari Unit testing yang bertujuan membiasakan tester terhadap komponen UI (termasuk view dan control) dari aplikasi yang ditargetkan.
Selain itu, kita bisa menganalisa aplikasi orang lain untuk mengetahui komponen apa saja yang digunakan di aplikasi tersebut.
Output yang dihasilkan berupa screenshot UI dan komponen-komponen penyusun UI secara hirarki dari parent to child (seperti halnya di XML layout)

untuk menganalisa komponen-komponen UI dari sebuah aplikasi, dapat dilakukan via Android SDK, yaitu via terminal (arahkan ke <android-sdk>/tools/), ketik :

$ uiautomatorviewer [enter]

Tampilannya seperti berikut :

Image

Lengkapnya dapat dilihat di : http://developer.android.com/tools/testing/testing_ui.html

6 pelajaran hidup yang dapat kita pelajari dari seni pemrograman

  1. Flow Chart sederhana adalah segalanya
    Sama halnya seperti seorang programmer, ketika kita dihadapi masalah besar, sebisa mungkin dipecahkan menjadi bagian-bagian terkecil, Baru dengan mudah kita dapat mengambil keputusan atas masalah tersebut.
  2. Setiap hal ada tempatnya.
    Selalu, ktika kita men-develop aplikasi, tentu di tahap awal kita menempatkan variable2 yang ingin kita pakai beserta tipe datanya (inisialisasi), begitu jg hal lain, slalu ada tempatnya, semua ada aturannya.
    Sama seperti kehidupan nyata, di mana letak tempat menaruh peralatan kerja, menaruh makanan, menaruh permasalahan kantor ya di kantor, bukan di rumah, dan sebagainya.
  3. Re-use/menggunakan kembali module yang sudah ada untuk menghemat waktu
    Setiap programmer yg baik akhirnya belajar bahwa ketika sudah membuat sebuah function ataupun module, dapat digunakan kembali untuk pengembangan aplikasi yang lain/berikutnya. Jadi menghemat waktu tentunya
    Henry Ford pernah berkata tentang Model T, “Setiap pelanggan dapat memiliki mobil dicat warna apa saja yang dia inginkan, asalkan itu hitam.”
    Alasan ini yang dipake Ford untuk merakit mobil dan membuat produk-produknya keluar pintu lebih cepat jika ia bisa menggunakan kembali peralatan yang sama (cat warna yg sama) tanpa harus menciptakan proses setiap kali mobil baru dibuat.
  4. Dokumen(tasi) adalah segalanya
    Kalo programmer yang “khilaf” 😐 dokumentasi itu malah diabaikan, atau malah dikerjakan pas aplikasi selesai 😐 sama aja boong :)) keasikan ngoding sih jadinya males, malah terkadang dianggap repot 😐 “gak ah, mending ngoding aja, ntar jg gampang diinget-inget, gak taunya mesti tracing code lagi”
    Sebenernya dokumentasi itu penting, dengan adanya dokumentasi, kita mencatat setiap hal yg kita perbuat dengan aplikasi itu, apa kesalahan dan perbaikannya, apa fungsi-fungsinya, dan tau tata letaknya, jadi mempermudah developer lain (berikutnya) untuk mengembangkan, dan bahkan bagi user.
    Sama seperti sehari-hari, terkadang jadwal penting, rutinitas sehari-hari, dan apa saja yang mesti dilakukan perlu dicatat di dalam sebuah catatan/agenda, memudahkan anda mengingat dan tidak tertinggal satu halpun.
  5. Jangan terjebak di satu situasi yang buruk.
    Ketika aplikasi mengalami looping gk berujung, process CPU jadi tinggi, dan tentunya si programmer harus mencari alternatif cara agar aplikasi berjalan lancar. Begitu jg dengan kehidupan nyata, ketika sudah merencanakan sesuatu, tau2 datang hal yg tidak diprediksi, satu2nya cara adalah menyiapkan “skenario terburuk” dari rencana itu, jadi tidak stuck di situ saja.
  6. Free Up Memory ketika kamu selesai.
    Kalo buat aplikasi, misal aplikasi Android, terapin masalah service, yang jelas setiap execute dalam durasi beberapa waktu, butuh free-up memory, agar app.tersebut tetap efisien ketika berjalan. Jika tidak, bakal makan banyak memory.
    Di kehidupan sehari-hari, sama juga, abis kerja, abis makan, cepetan diberesin dan dibersiin ruangannya, jangan sampe numpuk sampah, peralatan kerja berserakan, dsb. Malah buat aktifitas berikutnya jadi lambat.