Beranda > Blackberry > Issue-issue permasalahan seputar mobile application development

Issue-issue permasalahan seputar mobile application development

Problem in Blackberry Software DevelopmentMinggu-minggu ini, saya berada pada akhir masa development sebuah aplikasi On Device Portal. Sebentar, kita lihat dulu definisi On Device Portal:

On-Device Portals (ODPs) allow mobile phone users to easily browse, purchase and use mobile content and services. An ODP platform enables operators to provide a consistent and branded on-device experience across their broadening portfolio of services and typically provides on-device catalogs of content for purchase, deep links to WAP portals, customer care functionality and rich media services such as full track music, TV and video. (Wikipedia)

Kata-kata yang dicetak tebal adalah titik-titik berat pada aplikasi yang sedang saya bangun. Ya-ya-ya, memang tidak 100% match dengan definisi itu, tapi setidaknya lebih mudah untuk dipahami.

Baik, saya bicarakan dulu apa sih yang saat ini sedang saya buat. Ini juga yang membuat blog saya tidak aktif selama 1 bulan. Dari latar belakangnya dulu deh. Sebulan yang lalu (atau lebih), seorang pembaca blog ini bertanya kepada saya apakah saya bisa bikin software Blackberry. Saya jawab saja, “Ya bisa saja. Tapi yang bagaimana dulu?” Kemudian beliau memberikan sebuah link. Rupanya rekan saya ini sudah membuat sebuah web loader untuk alamat web yang memang dicostumize untuk tampil cantik di ponsel atau lebih khususnya device Blackberry. Rupanya masalah bandwidth cukup berpengaruh juga, nampaknya meskipun sudah dibuat tampilan seminim mungkin, tetap URL tersebut masih tergolong agak lambat diakses. Setidaknya dari modem 3G saya. Beliau ingin software dengan tampilan sederhana seperti milik Domikado atau Detik.

Setelah saya cek kedua software tersebut, saya agak heran juga kenapa disebut sederhana? Buat saya sih Domikado indah banget. Hanya sayangnya retrieve data-nya agak sering gagal (pada beberapa percobaan terakhir). Mungkin karena banyaknya penggunanya. Kemudian saya lihat Detik. Ya, memang yang ini agak lebih sederhana. Saya sendiri belum terpikirkan bagaimana membuatnya. Yang jelas saat itu adalah, saya bisa membuatkan aplikasi client server, dari software Blackberry menarik content dari server web. Dan tentu saja, modal semangat juang yang lumayan lah. Bisa nggak niru tampilan Domikado? Justru itu tantangannya. Saya bilang ke si boss, kalau yang seperti itu butuh waktu. Akhirnya setelah diriset barang seminggu, bisa juga meskipun masih dibilang seikit kalah dari segi tampilan.

Pembicaraan kemudian mulai menghangat, hingga menyebut fitur-fitur apakah bisa begini dan bisa begitu? Pada umumnya sih langsung saya jawab bisa, karena memang nampak sangat memungkinkan. Nah, meskipun fitur-fitur yang diajukan di awal tidak begitu banyak, tetapi kenyataannya terhitung ada 52 fungsi. Nah lo. Di awal sih kelihatannya agak sederhana, ketika si boss menunjukkan desain layout yang diinginkan, di sana hanya ada sekitar 7 atau 8 menu item dengan tambahan beberapa background process. Makanya, semula saya optimis ini software bakal selesai awal Oktober. Kenyataannya, setelah melihat ke-52 fungsi, dengan URL script server side yang berbeda-beda, juga parameternya, akhir minggu ini baru software bakal bisa ditest. Masih belum sempurnya? Pastinya, semua software juga begitu.

Nah, sekarang saya akan ceritakan beberapa kendala yang saya hadapi.

  1. Time management
  2. Kendala teknis
  3. Code signing
  4. Keterbatasan komunikasi

Time Management

Berbeda dengan di 2 kantor sebelumnya (sebelumnya saya mengajar di salah satu perguruang tinggi kedinasan, kemudian pindah ke sebuah perusahaan penyedia layanan pembayaran elektronik ternama), kegiatan di kantor saya saat ini benar-benar jauh berbeda. Sibuk sekali. Meeting resmi bisa 2 atau 3 kali seminggu. Bukan meeting yang sekedar haha hihi saja, ini meeting serius yang melibatkan data, progress report dan data development. Tapi memang, saya menikmati karena saya jadi mulai lebih paham tentang project management dan sofware testing (bukan cuman teori seperti waktu mengajar dulu).

Jadi waktu efektif saya bisa riset maupun coding hanya seputar jam istirahat, setelah jam kerja dan setelah sampai di rumah. Itu juga harus menunggu anak sulung saya tidur, kalau tidak, saya harus berebut laptop dengan anak itu karena dia pasti pengen main Warcraft. Diantara ketiga waktu itu, tak bisa saya pungkiri, yang kedua adalah yang paling produktif, karena:

  1. Saya dalam keadaan on fire (semangat dan daya kreatifitas tinggi)
  2. Lepas tekanan dari pekerjaan rutin
  3. Tidak perlu cemas diganggu si bocah kecil

Setiap hari-nya, ketika hari kerja, saya baru bisa mengerjakan 2 hingga 4 fungsi. Artinya, secara kasar kita bisa hitung saja 52 fungsi / 3 per hari = 17 hari lebih. Ini di luar waktu risetnya. Artinya 2 s/d 4 fungsi tersebut tinggal diketik, karena teknologi sudah dikuasai, tinggal copy paste dari fungsi sebelumnya, kemudian diubah parameter, URL dan beberapa hal lain yang sifatnya minor.

Katanya 17 hari, kok kenyataannya sampai sebulan? Nah ini dia. Ada beberapa hal teknis yang harus dipelajari dulu untuk bisa implementasi dengan baik. Detilnya akan saya sampaikan nanti di bagian kendala teknis. Intinya, saya memerlukan waktu hampir 2 minggu untuk melakukan riset dan penyempurnaan teknik.

Sisanya, adalah waktu pending karena job stopper. Job stopper? Ada kendala di luar kemampuan yang memang mengharuskan proses development harus berhenti sementara. Apa sih misalnya? Kegiatan keluarga seperti bezuk teman yang habis melahirkan, mengantar anak imunisasi, dan terpaksa istirahat karena capek begadang.

Solusi: Selesaikan masalah-masalah yang mudah segera. Selesaikan pekerjaan kantor secepatnya (tanpa mengurangi kualitas). Limpahkan permasalahan yang tidak terpecahkan (karena memang bukan kapabilitas kita, misalnya membetulkan server script PHP milik customer) kepada orang yang berkompeten dan menyiapkan alerter/alarm bagi kita untuk mengeceknya di lain waktu.

Kendala Teknis

Secara umum kendala teknis terjadi karena kita belum menguasai teknologi yang digunakan. Ada beberapa issue teknis yang terjadi selama pengerjaan software ini:

  1. Koneksi HTTP dari Blackberry ke server yang maintainable, bukan sekali pakai
  2. Menangkap gambar dari kamera Blackberry
  3. Menulis source code untuk upload image dari software Blackberry ke server
  4. Membuat code 1 list item yang bisa menampilkan 2 atau 3 row (bukan list yang terdiri atas 2 row), ini bukan kemampuan default class ListField
  5. Parsing JSON (untung sudah dikuasai sebelumnya)
  6. Menggunakan Bouncy Castle untuk menghindari perlunya code signing jika menggunakan class-class kriptografi bawaan Blackberry (walaupun akhirnya terpaksa tetap code signing)
  7. Membuat selected list item menjadi warna lain (bukan biru seperti bawaan default)
  8. Membuat script untuk menampilkan loading image ketika software sedang mengambil data dari server, kemudian mengupdate list ketika data sudah didapat dari server, kemudian meyembunyikan loading image
  9. Masalah navigasi aplikasi

Yayaya, saya tahu kelihatannya tidak sesulit itu. Tapi coba saja sendiri. Selain itu ada juga masalah integrasi, ini lebih sulit dibandingkan membuatnya terpisah-pisah.

Solusi: Nah, karena issue-issue teknis di atas saya rasa cukup sulit, saya harus mendokumentasikannya. Atau ada cara yang lebih baik, yaitu mengumpulkan teknik-teknik yang sering dipakai dalam development aplikasi Blackberry, atau yang bisa juga digunakan untuk ponsel lain seperti Nokia, Motorola, Sony Ericsson, bahkan Android ke dalam suatu framework. Diharapkan dengan framework semacam ini, kode program bisa lebih bersih dan bisa juga memotong development time.

Code Signing

Beberapa rekan bertanya kepada saya, apakah jika menulis software Blackberry kita harus signing? Jawabannya tidak. Tapi mari saya jelaskan. Blackberry menerapkan Controlled API. Saya tidak tahu sebabnya, tapi mungkin salah satunya adalah security. Untuk project kali ini semula saya berniat menghindari code signing dengan cara menghilangkan penggunaan Controlled API. Semula software ini memiliki Menu Item. Menu Item adalah item menu tambahan yang muncul ketika kita tekan tombol logo Blackberry. Ini saya hilangkan karena Menu Item termasuk Controlled API. Yang kedua, saya juga mengganti penggunaan Blackberry Crypto API dengan Bouncy Castle. Saya menggunakannya untuk fitur login yang memerlukan MD5.

Kedua pendekatan di atas memang sudah menghilangkan penggunaan API-nya, tetapi setelah ditelusuri, ternyata masih banyak yang terlewatkan:

  1. net.rim.device.api.system.Bitmap
    Dipakai untuk menampilkan gambar, misalnya logo Shop, member Icon dan foto review.
  2. net.rim.device.api.syste.Characters
    Digunakan untuk memfilter input dari karakter enter, dll.
  3. net.rim.device.api.syste.KeyPadListener
    Digunakan untuk menangkap event dari KeyPad dan touch screen
  4. net.rim.device.api.syste.Display
    Digunakan untuk mendapatkan hitungan ukuran layar, agar software fit di berbagai seri device BB.
  5. net.rim.device.api.system.DeviceInfo
    Digunakan untuk mendapatkan BBPIN.
  6. net.rim.device.api.system.Application
    Digunakan untuk mengontrol masing-masing layar dari main program.

Nah lo, ternyata penggunaan Controlled API sebenarnya tak terelakkan, kecuali kita membuat program HelloWorld saja untuk Getting Started into Blackberry Programming. Hahaha.

Solusi: Beli private key untuk code signing (thanks to boss Darman dan boss Willy yang sudah meng-handle permasalahan ini dengan cantik). Atau berbagi pakai dengan pemilik private key (nampaknya agak sulit, kecuali dalam satu perusahaan, tapi katanya bisa saja dan masuk akal).

Keterbatasan Komunikasi

Masalah komunikasi agak menggemaskan juga. Kendala untuk saya adalah karena saya tidak bisa online chatting seharian, karena chatting dilarang di kantor saya. Banyak masalah yang memerlukan tanggapan dari orang lain segera. Sebenarnya chatting adalah solusi yang sangat tepat, murah dan cepat. Dengan chatting kita bisa terhindar dari salah paham dan bisa mendapat jawaban yang akurat.

Saya menggunakan wahana email. Keuntungannya adalah komunikasi terdokumentasi dengan baik by default. Tetapi kerugiannya adalah respon time-nya lambat dan bergantung seberapa sering lawan komunikasi kita membuka email.

Telepon? Bagi saya saat ini, telepon jelas harus saya hilangkan dari daftar. Mengganggu. Dengan frekuensi meeting bersama boss di kantor, jelas datangnya telepon dari luar bisa mengganggu meeting (juga karir mungkin). Meskipun sudah di silent, tetap saja menerima telepon ketika meeting, atau sekedar berbincang dengan kolega terrasa tidak sopan. Akibatnya, kita tidak nyaman, komunikasi tidak maksimal (hanya diserap 40% nya saja).

Solusi: Chatting via ponsel. Mungkin Blackberry atau ponsel lain yang kapasitas baterainya besar. Ponsel saya sebelumnya, setelah dipakai chatting 1 jam saja langsung low bat. Makanya, memang perlu ponsel untuk keperluan kolaborasi, seperti Push Mail atau Chatting.

  1. Dev's
    November 2, 2009 pukul 9:06 pm

    Waah, nampaknya kesibukan tak menjadi kendala…
    semangat ya pak… ^^

  1. No trackbacks yet.

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

%d blogger menyukai ini: