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.

Picture1

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.
  1. 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.

  1. 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.

build-process_2x

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.

  1. 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.

Picture2

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 🙂

Advertisements

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.
    mobile-owasp

    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.

Pernyataan Jokowi soal “panggil programmer 2 minggu selesai” buat kalangan programmer melek dengan e-gov negeri sendiri

well, banyak sekali sisi positif gara-gara statement Jokowi “e-gov, panggil programmer 2 minggu selesai” di debat capres tempo hari. Di kaskus, facebook, twitter, berkumpul dan berdiskusi soal e-gov. Nama “programmer” pun jadi makin dikenal.

Namun, ada banyak gap yg terjadi di kalangan profesional TI, apalagi di kalangan fanatisme kedua kubu capres, akibat dari pernyataan Jokowi tersebut.

Sebagian kalangan mengkritik itu hanya bualan atau kalimat berlebihan dr seorang capres, krn sejatinya membangun sebuah aplikasi tidak hanya terkait programmer dan codingannya, tetapi ada metodologi dan tahapan pengembangan softwarenya, ditambah regulasi dan birokrasi dengan pihak pemerintah.

Namun sebagian kalangan menganggap ini tantangan besar buat indonesia, mereka menyadari bahwa e-gov tidak dikembangkan dalam satu malam, tp bertahun-tahun. Semua sudah jelas, apalagi untuk kalangan IT.

Korea saja misalnya, dr kuliah online pakar e-gov dengan judul “Ten Lessons from Korean Experiences of e-Government”, Professor Sang W. KIM, Ph.D. bilang kalau Pemerintah Korea telah melaksanakan secara berdampingan berbagai master plan, program dan proyek untuk menerapkan “masyarakat berorientasi informasi” secara nasional selama 20 tahun terakhir. Banyak project, dimulai dari 1987 (NBCN) sampai dengan e-gov nya mereka (2001-sekarang)

Di Indonesia sendiri, bbrp informasi yg sy dpt dr berbagai surat kabar online, menyebutkan sudah ada e-gov yang berhasil di beberapa daerah, di Jawa Timur (http://www.surabayapagi.com/index.php?read~Jawa-Timur-Terbaik-Kedua-di-Pemeringkatan-e-Gov-Indonesia). Berhasil di sini maksudnya sudah diuji secara teknis (aplikasi dan jaringan) dan tanggapan masyarakat.

Dan polemik di sini adalah e-gov yang sudah sukses tersebut tidak disosialisasikan oleh pemerintah pusat agar diterapkan di berbagai pemerintah daerah. Pemerintah tidak menjalankannya secara utuh. Alhasil, saat ini yang terjadi adalah tidak ada transparansi di kalangan pemerintah ke masyarakat. (mungkin ini yg dikhawatirkan bbrp elit politik, biar tidak ketahuan belangnya..makanya e-gov tdk dijalankan)

Kalo pak Jokowi memang pernah terlibat dlm pengembangan e-gov dan bilang “panggil programmer, 2 minggu selesai”, maka mungkin sebaiknya perlu diklarifikasi “selesai” di sini utk tahap apanya?  Karena beliau menyebut “programmer” bukan “vendor TI” maka mungkin bisa diasumsikan ini maksudnya “development-nya” (LOL) Drpd para simpatisan debat kusir dan para programmer berasumsi yg rumit-rumit.

Dan kembali lg ke topik yang disampaikan prof. Sang W. KIM, Ph.D, kalau Sistem Informasi tidak dibuat sekaligus, tapi bertahap. Dan suksesnya sebuah sistem informasi itu tidak ditentukan oleh ouput dari Sistem Informasi tersebut, tetapi hasilnya dapat dirasakan dan bermanfaat oleh pengguna. Manajemen data untuk mengelola atribut dalam e-gov harus lebih baik (Membangun Data Warehouse dari OLTP ke OLAP). Dan ini juga dipengaruhi bbrp domain sosial seperti Kepemimpinan (leadership), Strategi (strategi), Hukum & Peraturan (law & regulation) di pemerintah tersebut.

Optimisasi database SQLite dalam mobile programming

Mampu gak sih aplikasi mobile (ntah iOS, Android, BB) menangani database SQLite berukuran besar (misal, seperti kasus yang baru saya tangani untuk al-qur’an terjemahan beserta kajian tematiknya, yang lebih dari 10000 records)

Pengaruh kah dengan performance?

Jawabannya, iya, mampu, tapi jika tidak dioptimisasi, akan sangat lambat sekali melakukan query, bahkan dapat menyebabkan aplikasi crash.

Ada beberapa trik meningkatkan performa yang dapat dilakukan :

  1. Gunakan BEGIN TRANSACTION dan END TRANSACTION.
    Contoh :

    String query = “SELECT _id, terjemah, tema, ortu, urutan FROM tema_utama_hadits WHERE ortu=\””+ id + “\” ORDER BY urutan ASC”;
    db.beginTransaction();
    try {
    menuslidetematik = db.rawQuery(query, null);
    db.setTransactionSuccessful();
    } finally {
    db.endTransaction();
    }

    Keuntungan : speedup dan meningkatkan performa query dari database
    Kerugian : Tidak bisa rollback database.

  2. Indexing semua field dari tabel yang dibutuhkan
    Contoh :

    CREATE INDEX idx_temautamahadits ON tema_utama_hadits (_id, terjemah, tema, ortu, urutan);


    Keuntungan
    :  Waktu yang dibutuhkan untuk query pencarian (SELECT) untuk setiap record menjadi lebih singkat.
    Kerugian : Butuh extra space untuk temp table.

  3. Biarkan database selalu terbuka (open() ) dan jangan sering open() dan close() database SQLite.
    Selama masih ada query yang berjalan ketika membuka halaman tersebut dari aplikasi, biarkan saja db.open(), jangan sering menggunakan open() dan close() setiap melakukan query.
    Contoh :

    SQLiteDatabase db = dbHelper.getReadableDatabase(); //tanpa db.close() di bagian akhir query.

    Keuntungan : lebih efisien
    Kerugian : dalam beberapa hal membiarkan terbuka database, dapat menyebabkan koneksi menjadi berjalan ganda sekaligus. (bloating cursor)

Semoga bermanfaat 🙂

Pentingkah melanjutkan kuliah di TI?

Bagi temen-temen yang dari SMA sudah kuat di dunia komputer, dan tertarik untuk menggali lebih dalam ilmu di dunia komputer, kemudian bertemu di kondisi “resah” apakah memang penting kuliah di bidang teknologi informasi atau cukup belajar otodidak saja terus ambil kuliah jurusan lain? khawatir nanti kuliah TI malah sia-sia saja, mending saya ambil kursus daripada buang duit untuk kuliah TI.

pemikiran seperti itu wajar terjadi, mengingat, belajar komputer juga sekarang cukup mudah, ditambah pola pikir anak SMA belum begitu matang.

Hanya dengan bermodal buku bacaan, dibeli dari toko buku, kemudian dibaca dan dipraktekan di depan komputer. Dalam periode waktu kurang dari 6 bulan sudah bisa mahir menguasai satu ilmu TI, ntah hacking, ntah programming, ntah jaringan, ntah sistem operasi. Dan bahkan dari situ mereka bisa menghasilkan uang dan bekerja di perusahaan-perusahaan besar.

Ada diskusi menarik yg sy dapat di perkuliahan S2 antara dosen dan mahasiswa mungkin bisa memberi gambaran mengapa kuliah TI itu penting
(* diskusi ini saya tidak ingat 100% isi percakapannya, namun saya masih bisa tangkap apa yang didiskusikan. Diskusi ini juga didapat dari 2 peristiwa. Init dosen : TBA dan EN. Mohon maaf bila tidak ingat sepenuhnya 😀 memory terbatas hehe )

dosen : *sambil nunjuk* masnya ambil S2 alasannya apa?”
mhs1 : “buat belajar TI lebih dalam, pak!”
dosen : “kalau boleh tau, ilmu apa yang anda dapat lebih dalam di S2?”
mhs1 : “sampai saat ini saya belajar lebih dalam dari berbagai studi kasus yang diberikan dosen, pak”
dosen : “apa yang bisa anda dapatkan dari situ?”
mhs1 : *terdiam sejenak* “penyelesaian masalah dan mencari solusi efektif dan efisien, pak”
dosen : “bukan itu, atau….” *sambil nunjuk yg lain* “…ya coba masnya yg dipojok itu, mengapa alasan ambil S2?”
mhs2 : “sy setelah lulus S1, jd programmer, pak, ingin mendalami lebih dalam soal programming dan software development, pak”
dosen : “jadi, anda ingin mendalami dunia software developmentnya ya mas? cukup bagus goal-nya. Tapi apakah anda bisa menjamin bahasa pemrograman yang anda kuasai itu masih ada 10 tahun yang akan datang? tidak bisa kan?”

kemudian…. dosenpun bercerita yang isinya kira-kira begini :

“saya akan bercerita soal kejadian saya menanyakan hal ini ke mahasiswa saya di akhir mereka kuliah, di awal saya bertanya ini juga, begitu mereka selesai bimbingan thesis dengan saya, saya tanyakan lagi.
saya bertanya ke mahasiswa : “apa yang sudah anda dapatkan dari S2 ini, mas?”
mahasiswa : “banyak sekali, pak. Saya bisa lebih mendalami masalah TI dalam lingkup yang lebih pasti dan terarah. Karena dunia TI begitu luas, jika kita mampu memosisikan diri kita di dunia kerja dengan pasti, tentunya karir kita akan lebih baik. Satu hal yang saya dapat dari pelajaran yang bapak beri..bahwa memang benar, pak. Di S2 ini, pola pikir saya lebih kuat, lebih terorganisir sebagai seorang profesional TI

Yang membedakan kita, S1, S2, D3, STM di dunia TI.. adalah “pola pikir” atau mindset.

Saya quote salah satu note dari seorang dosen (LEN) :
“kalau anda seorang programmer yang terbiasa bekerja pada level implementasi dan suatu saat harus belajar tentang matematika diskret, bersiaplah untuk meninggalkan mindset operasional untuk berpindah ke mindset dengan tingkat abstraksi yang lebih tinggi. Memikirkan topik-topik semacam logika, teori himpunan, dsb. pada level programming jelas tidak akan efektif.”

Dan itu jadi salah satu alasan, mengapa di S1 kita tidak belajar programming melulu, malah sampai ada teman-teman yang bertanya : “saya bingung kita belajar S1 ini hasilnya dapet apa? saya juga programming gak jago, dunia kerja ntar bingung mau jadi apa…lowongan banyak yang programmer dan staff TI, tapi tetep butuh skill programming dan RPL”

Dunia TI begitu luas, tidak hanya programming, tidak hanya software development, jaringan komputer, dan lain-lain. Kalau kita melihat lebih luas, di mana teknologi yang berkembang saat ini, seperti di smartphone, di traffic light yang bisa merekam plat nomor kendaraan yang melanggar lalu lintas, kemudian teknologi yang sekarang sudah diterapkan di restoran-restoran dan surat kabar dengan QRCode, mengambil keputusan di dunia bisnis, dan lain-lain. Itu juga hasil dari dunia TI. Ada Computer Vision, Soft-Computing, Data Mining, Pervasive-computing, dan lain-lain.

Dan dari perkuliahan itulah mereka dapatkan ilmu di bidang TI secara sistemik dan utuh. Kurikulum yang didapat juga jelas, dan diakhir semester kita diarahkan di mana kita harus memilih lagi, bidang/cluster/minat studi apa yang kita tekuni dan sukai dari dunia TI tersebut.
Dari situ juga mahasiswa berkembang, belajar dari umum ke spesifik. Namun hal tersebut, tidak hanya di dapat dari dalam lingkungan kuliah saja, tetapi dari luar kuliah juga. Di mana masalah di luar lingkungan kuliah tentu lebih beragam. Dan tentunya, mahasiswa dituntut untuk memiliki kemandirian dalam menuntut ilmu.

Mari kita lihat kasus nyata baru-baru ini, di mana seorang (yang mengaku) hacker yang berakun anon_indonesia, berdebat panjang lebar dengan para twitter lain, dia mengaku kalau level tertinggi dari hacking adalah deface. Konon katanya seorang bolang 😀
Sudah bisa menangkap apa yang membedakan dengan kita yang sudah kuliah TI? 😀
Ya, yang dia tau ya level hacking cuma deface website saja, yang bisa dengan mudah mengandalkan google, mencari file dengan nama dan atau extensi tertentu, misal aspx, php, dll. Kemudian ia coba masuki dengan beberapa cara, sehingga bisa meng-upload file-file lain dari local komputernya, kemudian file index.html/index.php, dll direplace seakan-akan dibajak?!:P 😀
Padahal jelas yang seperti itu bagi anak jarkom, tentu dianggap mainan anak sekolahan. Dan tentunya tindakan itu bukan main-main, karena memang merupakan salah satu hal kriminal.
Ketika ditanyain istilah-istilah jaringan, ah, jangankan jaringan, istilah kecil seperti back-end, sysadmin, dan sejenisnya, orang seperti itu belum tentu mengetahuinya.
Lantas dari mana bisa mengetahui seperti itu? 😀 tidak dari buku, tidak juga dari belajar otodidak, tapi dari perkuliahan, di mana…seperti yang saya tulis di atas tadi : “Di perkuliahan, mahasiswa dibiasakan untuk berpikir secara sistemik dan utuh tentang TI”

Ada contoh lain :
Seorang yang tidak kuliah TI, dia mahir programming Visual Basic 6 dengan otodidak, kemudian VB6 tidak laku lagi, programming baru datang, .NET. Dia bisa mengikuti perkembangan hal tersebut dengan belajar otodidak lagi, tapi begitu .NET berakhir, tentu ia mau tidak mau dituntut untuk belajar yang baru lagi, namun hal tersebut akan berakhir di situ-situ saja. Dan begitu mendapatkan persoalan yang baru, ia akan kebingungan.

Ada seorang STM yang mahir TI, dia sudah menduduki jabatan yang bagus di salah satu perusahaan telekomunikasi asing, kemudian dihadapkan dengan massive problem, dari hal infrastruktur TI, jaringan, sistem yang sudah tertanam dan sistem yang akan dikembangkan. Menuntut dia harus belajar lebih giat lagi. Namun, dia menjadi kesulitan : “aku harus mulai belajar dari mana dulu? nanti aku mesti ngapain?” karena tidak tau arah dan belajarnyapun tidak berurut. Membuatnya menjadi tersesat.
Alhasil, posisi dia tidak naik ke level berikutnya, dan masih di posisi sebelumnya. Dan pada akhirnya, membuat keputusannya berubah : “sepertinya saya harus mengambil kuliah S1 TI, biar lebih paham lagi”

Tiap jenjang strata, mindset yang terbentukpun berbeda levelnya. Dan perlu diketahui, di S2 TI, ilmu-ilmu S1 TI masih bertemu lagi. Hanya saja, kerangka persoalan di S2 itu lebih ke level abstrak yang biasa dihadapi oleh mereka yang bekerja pada posisi manajerial, bukan hal teknis atau operasional lagi. Mahasiswa dituntut mampu menyelesaikan persoalan dengan solusi yang efektif (tepat sasaran) dan efisien (tepat guna).

Dan dari beberapa hal di atas sudah bisa disimpulkan bahwa kuliah TI bukanlah hal sia-sia.
Dengan kuliah TI :

  1. kita mampu berperan aktif sebagai profesional TI yang memiliki pola pikir terarah dan sistematik.
  2. atmosfer lingkungan kampus sangat mendukung bagi kita untuk belajar lebih giat lagi tentang TI, di situ juga ada kelompok/forum diskus/belajar bersama, dan juga organisasi kemahasiswaaan. yang tentu menambah tantangan dan pengalaman. Selain itu, dengan kelompok tersebut mahasiswa dituntut untuk bisa untuk bisa bekerjasama.
  3. kita dibimbing oleh dosen yang tentu ahli dalam bidangnya.
  4. kesempatan untuk dipandang oleh orang lain di dunia kerja juga akan tinggi. Bahkan oleh lingkungan sekitar, orang yang berpendidikan sarjana akan dianggap ahli dan pintar oleh lingkungan. Tentu membanggakan orangtuanya.
  5. membentuk pribadi yang memiliki passion, percaya diri, kesabaran dan soft-skill yang tinggi di bidang TI, dengan visi dan misi yang jelas untuk masa depannya.
  6. mungkin ada yang mau menambahkan lagi? 😀

Harga pengembangan aplikasi mobile yang dipasang, kemahalan atau kemurahan kah?

Mari kita berhitung harga aplikasi mobile. 🙂 Bila ada yg beranggapan harga 4-7jt itu kemahalan untuk membuat aplikasi bisnis berbasis mobile (android, iOS, BB) artinya temen-temen perlu membaca ini.

Ini dikerjakan secara profesional, bukan dikerjakan oleh mahasiswa tingkat akhir yang dipekerjakan (sadis, gan!) :p

Dan jangan dianggap, karena aplikasi yang dikembangkan itu cuma seukuran layar HP dan lebih kecil “keliatannya” tampilan daripada di website, bukan berarti harganya pasti lebih murah daripada mengembangkan versi web. Itu salah kaprah. Karena, bisa jadi kerumitannya lebih rumit daripada pengembangan website. Dan bisa jadi lebih mahal daripada pengembangan versi websitenya. Walau tampilannya keliatan kecil, tetapi di situ ada banyak kerumitan dalam hal UI, fungsionalitas, pemodelan, user-behavior aspect/user experience design, resources, dll. Hampir mirip saat mengembangkan website.

Dari hasil diskusi saya dengan beberapa teman project TI yang sudah 2 tahun mendalami pengembangan aplikasi mobile dan project TI di bidang mobile apps. Dan pengalaman pribadi yang mendalami project programming Android di beberapa tempat sejak memiliki HP Android di juni 2010.

Dan ini berlaku hampir di semua client dan client/perusahaan pun rata-rata mematok harga segitu.

Ok, kebanyakan aplikasi mobile itu faktanya, dikembangkan dalam jangka waktu paling tidak 6 bulan, dengan jam kerja full-time (mengikuti jam kerja) dan berkisar di harga 10 sampai 50 juta.

Eits, tetapi tidak serta merta semua begitu, mari kita buat lebih spesifik. Pertama, perlu kita perhatikan adalah tipe aplikasi yang akan dikembangkan. Kita berhadapan dengan klien, ngobrol panjang lebar dengan orangnya apa yang ia inginkan (user stories) dan mencatatnya untuk dianalisa setiap kebutuhan supaya menjadi milestone pekerjaan (per task, per man-days, per man-power, per period) dalam jangka waktu (timeline) yang sudah disepakati.

Kita bagi dalam dahulu menjadi 2 kategori :

A. Untuk digunakan konsumen (umum)

  1. Aplikasi dasar, yang memiliki fungsi-fungsi dasar android. Sekedar menampilkan teks, diinputkan, diproses ditampilkan secara sederhana. Seperti : aplikasi maps sederhana yang menampilkan petunjuk jalan lokasi penjualan produk, aplikasi alarm, jam, dsb..yang tidak menampilkan fitur-fitur selain itu.
  2. Aplikasi Native, yang menyediakan berbagai tipe konten (gambar, tulisan, suara, dll), dengan logika matematika yang kompleks dan arsitektur software yang terdiri dari beberapa level. Dan biasanya menggunakan framework tertentu atau library tertentu, dan database tertentu (mysql, sqlite, sql server, dsb)
  3. Games, dari berbagai info saja, aplikasi games Angry Birds seharga $125k-180k hanya untuk biaya coding saja. Dan games sama saja mencakup beberapa hal, seperti : rendering 2d/3d graphics, logika ilmu matematika, ilmu fisika, dll. Belum lagi nanti ada sound artist, artwork design, dll. Makin mahal.

B. Untuk digunakan perusahaan (bisnis/internal)

  1. Aplikasi enterprise kecil
  2. Aplikasi enterprise sedang
  3. Aplikasi enterpise besar

Mengenai kecil, sedang, dan besarnya ditentukan dari banyaknya scope-pekerjaan, timeline yang diberikan, dan kompleksitas masalah (apakah nanti cross-platform kah? artinya perlu menyediakan web-services, database-support library, Share Capabilities  dengan apps lain, dsb)

Ok, soal harga, berapa?

Menentukan harga itu harus ditambahkan juga dengan biaya penyediaan resources (tools/software/IDE) dan biaya produksi (publishing) jika memang semua diusahakan oleh pihak pengembang.

Begini, ketika kita akan mengembangkan apps. games dengan menggunakan Game Maker Studio seharga $299 dolar, artinya itu masuk hitungan nilai investasi kita, kecuali sudah disediakan oleh pihak client, kalau tidak? masa’ kita yang membeli sendiri? Kalau sudah punyapun, harus dihitung lagi. Karena secara profesional, semuanya disediakan oleh client, kecuali ada hitam di atas putih yang menyatakan kita ikhlas menyediakannya [yaoming.jpg] 🙂

Jika menggunakan tools yang gratisan ya jangan hehe..

Begitu juga biaya publishing ke PlayStore ataupun AppsStore, itu ya biaya pendaftaran akun untuk publishing-nya ya dihitung juga.

Dan untuk masalah harga yang berlaku, bisa dicek di sini :

  1. Aplikasi dasar seperti pada poin A.1 di atas : berkisar 2-5jt (di luar sana berkisar $1,000)
  2. Aplikasi native, seperti pada poin A.2 di atas : berkisar 6-50jt (di luar sana berkisar $8,000-$50,000)
  3. Aplikasi games, seperti pada poin A.3 di atas : berkisar 8-150jt (di luar sana berkisar $10,000-$250,000)
  1. Enterprise kecil, seperti pada poin B.1 di atas : berkisar 20jt (sekedar ekstrak data dari database, kemudian ditampilkan)
  2. Enterprise sedang, seperti pada poin B.2 di atas : berkisar 20-50jt (sudah mencakup masalah seperti : client-server apps, cache data, penggunaan library native, hardware support)
  3. Enterprise besar, seperti pada poin B.3 di atas : berkisar 80-300jt (full-scale enterprise, office automation, enterprise financial monitoring, mobile apps. banking, dsb)

Apalagi akan ada continuing cost setelah masa development, guarantee, maintenance, dll.

Harap diperhatikan juga, besar kecilnya harga yang ditawarkan itu bisa bergeser karena dipengaruhi banyak faktor. Ketersediaan SDM, Ide, Waktu, Budget, Fungsionalitas, Layout Design, dan negosiasi.  🙂

Apakah harga segitu wajar?

Jelas wajar, dilihat dari lifecycle development-nya, benefit dari pemanfaatan aplikasi mobile kepada user (yang jelas lebih mudah dipakai di manapun, kapanpun, tanpa perlu membawa laptop), promosi (iklan) produk dan monitoring (untuk keperluan survey statistik penggunaan) juga dapat dimanfaatkan dengan mudah melalui apps yang dikembangkan dan di-publish, demi memperhatikan konsumen dan mencari aspek penting buat menentukan kebijakan perusahaan. Dengan rata-rata per sekali publish, dalam seminggu bisa sampai 100-500 yang downloads, tentunya akan meningkatkan keuntungan bagi pihak client. Apalagi trend sekarang ini adalah mobile apps.

NB : tulisan ini mix teori (minim) dan hasil praktek, bukan money-oriented tanpa dasar, tetapi supaya kita juga paham memasang harga pengembangan aplikasi biar tidak dirugikan. :p Newbie belajar nulis.

Referensi Buku seputar Android

Buku yang bagus untuk belajar Android ada banyak, namun saya coba memberi beberapa rekomendasi buku yang membahas Android.

  • Untuk mengenai pengenalan OS android dari sejarah sampai memanfaatkan Android OS ada di buku Android for Work Productivity for Professionals (oleh Marziah Karch, penerbit Apress)
  • Untuk development aplikasi Android (basic-advanced-pro) :
    • Android Application Development for Dummies (by Donn Felker, penerbit Wiley),
    • Hello Android (by Ed Burnette, penerbit Pragmatic Programmers) &
    • Professional Android App. Development (by Reto Meier, Oreilly)
  • Seputar Testing dan bug fixing app. Android : Android App. Testing Guide (by Diego Torres Milano)
  • Seputar Design UI Android : Android UI Fundamentals (by Jason Ostrander)

Adapun referensi online, bisa bergabung di : http://www.anddev.org, http://xda-developers.com, dan http://d.android.com. Tanya jawab bisa di forum tersebut atau di http://www.stackoverflow.com