BAB II TINJAUAN PUSTAKA
2.1 Mobile Learning Dengan peningkatan teknologi mobile di masyarakat dan bisnis, banyak individu dan organisasi yang secara serius mempertimbangkan penggunaan perangkat mobile untuk pembelajaran dan pelatihan. Mobile learning atau m-learning sering didefinisikan sebagai e-learning melalui perangkat komputasi mobile. Ally (2004) mendefinisikan m-learning sebagai pengantaran bahan pembelajaran elektronik pada alat komputasi mobile untuk dapat diakses dari mana saja dan kapan saja[1]. Secara umum perangkat mobile dimaksudkan dengan PDA dan telepon seluler digital, tetapi secara lebih umum kita dapat menganggapnya sebagai perangkat apapun yang cukup kecil, dapat bekerja sendiri, yang dapat menemani kita di setiap waktu dalam kehidupan kita sehari-hari, dan yang dapat digunakan untuk beberapa bentuk pembelajaran. Perangkat kecil ini dapat dilihat sebagai alat untuk mengakses konten, baik disimpan secara lokal pada device maupun dapat dijangkau melalui interkoneksi. Perangkat juga dapat menjadi alat untuk berinteraksi dengan orang lain, melalui suara dan melalui pertukaran pesan tertulis, gambar diam dan gambar bergerak.
2.1.1
Perbedaan E-Learning dan M-Learning
Ada banyak hal yang ditemukan berbeda ketika dibandingkan antara mobile device dengan desktop PC (media yang biasa digunakan untuk menyampaikan e-learning) dan perbedaan-perbedaan itu mencakup fitur, fungsi, dan bahkan kenyamanan pada setiap device. Beberapa dari perbedaan tersebut antara lain keluaran (yaitu ukuran dan kemampuan resolusi layar, dan lain-lain); masukan (yaitu keypad, touch-screen, input suara); kemampuan pemrosesan dan memori; aplikasi yang didukung dan jenis media. Ketika dicoba untuk memindahkan layanan yang disediakan oleh platform elearning ke dalam layanan di platform m-learning dapat terlihat bahwa beberapa hal harus berubah untuk memenuhi keterbatasan perangkat kecil, dan beberapa tidak 6
dapat disampaikan dalam batasan konteks tertentu, tetapi di sisi lain layanan baru juga dapat dimunculkan, yang dipicu oleh mobilitas dari perangkat mobile. Di luar keterbatasan yang dimiliki oleh m-learning, sistem ini memiliki beberapa kelebihan dibandingkan dengan sistem e-learning, yaitu: ¾ Portabilitas: perangkat mobile lebih mudah dibawa-bawa dan lebih mudah dipakai untuk membuat catatan atau memasukkan data di mana pun. ¾ Mendukung pembelajar: generasi yang ada saat ini lebih menyukai perangkat mobile seperti PDA, telepon seluler, dan perangkat handheld games. ¾ Meningkatkan motivasi: kepemilikan terhadap perangkat mobile cenderung meningkatkan komitmen untuk memakai dan mempelajarinya. ¾ Jangkauan lebih luas: perangkat mobile cenderung lebih murah sehingga dapat terjangkau oleh masyarakat secara lebih luas. ¾ Pembelajaran tepat waktu: meningkatkan performance kerja / pembelajaran sesuai dengan kebutuhan pembelajar. Dari sisi konektivitas, berbeda dengan e-learning, yang dianggap memiliki koneksi yang selalu terhubung, m-learning dapat disampaikan melalui tiga cara, yang secara skematik dapat disebut “koneksi murni”, “mobilitas murni”, dan gabungan dari keduanya. “Koneksi murni” adalah ketika perangkat mobile dapat selalu terhubung ke internet. Saat ini ada cukup banyak cara teknologi untuk perangkat mobile dapat terhubung ke jaringan internet, yaitu melalui WAP, GPRS, UMTS, Bluetooth, dan lain-lain. Sementara itu, “mobilitas murni” adalah ketika tidak ada koneksi tersedia sehingga semua data yang dibutuhkan aplikasi harus diupload terlebih dahulu di dalam perangkat dan digunakan secara offline. Dalam kasus telepon seluler saat ini, yang cenderung masih memiliki memori terbatas, hal ini sulit. Namun, situasi berubah dengan cepat dan ponsel generasi baru memiliki kemampuan pemrosesan, memori, dan embedded software yang lebih besar. Perbedaan yang paling besar antara e-learning dan m-learning adalah dalam hal karakteristik hardware / software perangkat. Akses ke web melalui perangkat mobile, dengan ukuran layar kecilnya, telah menjadi masalah yang menarik bagi banyak 7
peneliti. Hampir semua halaman web yang ada saat ini didisain untuk ditampilkan pada komputer desktop dengan monitor warna yang memiliki minimal resolusi 800x600. Perangkat mobile yang umumnya memiliki resolusi yang tidak lebih dari setengah resolusi tersebut, membuat tampilan langsung dari halaman-halaman web tersebut pada perangkat kecil tidak nyaman untuk dilihat secara estetika, sulit dinavigasi, dan dalam kasus yang terburuk, sama sekali tidak dapat digunakan. Bergantung pada perangkat yang digunakan, format penyampaian dan transformasi yang diperlukan dapat berbeda-beda pula. Karena faktor mobilitas dari perangkat yang digunakan dalam skenario m-learning, dapat dilibatkan data konteks baru untuk dipertimbangkan, yaitu lokasi. Layanan yang melibatkan location-awareness misalnya siswa atau guru menerima arahan bagaimana mencapai ruang tertentu atau pengingat untuk seminar atau kuliah yang dapat dipicu ketika mempertimbangkan posisi saat ini dan waktu yang diperlukan untuk mencapai aula yang diperlukan, dan lain-lain.
2.1.2
Manfaat M-learning
Berdasarkan penelitian yang dilakukan oleh suatu proyek m-learning di Inggris, Italia, dan Swedia[2], didapatkan mengenai beberapa manfaat dari m-learning, yaitu: ¾ memberikan pembelajaran yang benar-benar dimanapun, kapanpun, dan terpersonalisasi; ¾ dapat digunakan untuk menghidupkan, atau menambahkan variasi pada, pembelajaran konvensional; ¾ dapat digunakan untuk menghilangkan beberapa formalitas yang dianggap pembelajar non-tradisional tidak menarik atau menakutkan, dan dapat membuat pelajaran menjadi lebih menarik; ¾ dapat membantu memberikan dan mendukung pembelajaran literasi, numerasi dan bahasa; ¾ memfasilitasi pengalaman belajar baik secara individu maupun kolaboratif; ¾ dapat membantu melawan penolakan terhadap penggunaan ICT dengan menyediakan jembatan antara buta teknologi telepon seluler dan PC; 8
¾ telah diamati dapat membantu pembelajar muda untuk tetap lebih fokus untuk waktu yang lebih lama; ¾ dapat membantu meningkatkan percaya diri dan penliaian diri dalam pendidikan.
2.1.3
Perancangan dan Klasifikasi M-learning
Gambar 2.1 Technology Selection Roadmap[2] Dari penelitian yang sama, diperoleh juga Technology Selection Roadmap untuk membantu proses pemilihan alat pengembangan dan teknologi yang akan digunakan untuk membangun suatu sistem m-learning. Proses roadmapping ini dibagi menjadi lima kategori besar dari teknologi yang dispesifikasi, yaitu teknologi transportasi, platform, penyampaian, media dan bahasa pengembangan (Gambar 2.1). Dalam proses pemilihan teknologi tersebut juga dipakai sembilan kriteria sebagai pertimbangan, yaitu kegunaan dari fitur yang ditawarkan teknologi tersebut, masalah biaya, ketersediaan teknologi di suatu negara dan pola ketersediaannya (misalnya suatu layanan mungkin hanya ada di daerah perkotaan), reliabilitas, robustness, kemudahan penggunaan (bagi pengguna dan pengembang), standardisasi, perkiraan ketahanan di pasar, dan perkiraan popularitas. 9
Gambar 2.2 Klasifikasi Umum Sistem M-Learning[4] Berbagai jenis m-learning juga memiliki penggunaannya masing-masing. Misalnya beberapa sistem hanya dapat digunakan di lingkungan universitas atau perusahaan, dan di saat yang bersamaan sistem lain dapat digunakan dengan lebih luas di luar institusi pendidikan. Oleh karena itu, diperlukan juga adanya klasifikasi sistem mlearning untuk memudahkan pemilihan sistem m-learning yang akan digunakan oleh suatu pihak. Georgieva, et.al.[4] membuat suatu klasifikasi umum terhadap sistem mlearning yang dibagi berdasarkan indikator-indikator sebagai berikut: ¾ jenis perangkat mobile yang didukung: notebook, Tablet PC, PDA, smart phone, atau telepon seluler; ¾ jenis komunikasi nirkabel yang digunakan untuk mengakses bahan pembelajaran dan informasi administratif: GPRS, GSM, IEEE 802.11, Bluetooth, IrDA; ¾ dukungan edukasi secara sinkron dan/atau asinkron, apakah pengguna dapat berkomunikasi secara sinkron (chat, komunikasi suara) atau asinkron (e-mail, SMS) dengan pengajar; ¾ dukungan terhadap standar e-learning; ¾ ketersediaan terhadap koneksi internet yang permanen antara sistem m-learning dengan pengguna; ¾ lokasi pengguna; dan 10
¾ akses ke materi pembelajaran dan/atau layanan administratif.
2.2 BREW Binary Runtime Environment for Wireless, atau disingkat menjadi BREW, adalah sebuah teknologi baru yang dikembangkan oleh perusahaan raksasa teknologi nirkabel, Qualcomm. Berawal dari library internal yang mereka buat untuk mengembangkan perangkat lunak pada perangkat keras handset mereka sendiri, Qualcomm kini telah merilis BREW ke seluruh dunia. BREW memiliki dua sisi teknologi, yaitu teknologi perangkat lunak dan teknologi distribusi. Sebagai teknologi perangkat lunak, BREW bertindak sebagai suatu set API (Application Programming Interface) yang bekerja terhubung dengan bahasa pemrograman C/C++ untuk mengembangkan aplikasi nirkabel. Sebagai teknologi distribusi, aplikasi-aplikasi BREW disediakan untuk pembuat handset dan operator nirkabel melalui suatu tempat penyimpanan terpusat yang mengatur distribusi untuk setiap aplikasi. BREW juga merupakan suatu Applications Execution Environment (AEE) yang kecil dan efisien yang didisain secara spesifik untuk perangkat nirkabel. Dengan menyediakan dasar umum yang banyak dibutuhkan untuk pengembangan dan eksekusi aplikasi data nirkabel, platform BREW tersedia sebagai suatu katalis untuk keseluruhan industri. Pengembang dapat menulis aplikasi dengan cepat, memperoleh akses ke pasar luas dan mendapatkan kepastian pembayaran. Pembuat handset (OEM) dapat memperkenalkan perangkat baru dengan lebih cepat, dengan tugas pengembangan dan integrasi aplikasi internal yang jauh lebih sedikit. Operator dapat memperoleh penghasilan baru dan keuntungan yang kompetitif dengan menawarkan berbagai aplikasi, konten, dan layanan yang bermanfaat. Konsumen sendiri dapat memilih dan mengunduh perangkat lunak nirkabel yang sesuai dengan keinginan mereka masing-masing. Dengan cara ini, konsumen akan menggerakkan pasar untuk memberikan layanan dan aplikasi data nirkabel yang baru. BREW SDK (Software Development Kit) membuat pengembang dapat bekerja dalam lingkungan yang familiar dan bertingkat tinggi (menggunakan tools berbasis 11
Windows dan C/C++) dan menguji aplikasi mereka di bawah Windows menggunakan perangkat teremulasi. Hal ini membuat pengembang pihak ketiga tidak perlu lagi membangun hubungan dengan OEM nirkabel atau memiliki prototipe handset secara fisik untuk mulai menulis aplikasi. Dengan memanfaatkan kemampuan dari chipset yang ada, BREW memberikan kemampuan pada pengembang untuk mengakses tempat penyimpanan dan pemrosesan lokal serta ekstensi multimedia yang sudah terpasang, fitur konektivitas, informasi lokasi dan posisi dan banyak lagi untuk menciptakan aplikasi yang bagus dan menarik. BREW juga membebaskan pengembang untuk berurusan dengan fungsi perteleponan yang kompleks.
Gambar 2.3 BREW di Layer Software[12] Gambar di atas menunjukkan layer software dari sebuah perangkat. Dengan posisi BREW di antara layer software tersebut, aplikasi BREW dapat dijalankan di semua handset yang mendukung fungsi aplikasi tersebut. Misalnya, tidak semua handset memiliki GPS (Global Positioning System), tetapi semua handset yang memiliki GPS dapat menjalankan aplikasi BREW yang menggunakannya. Karena aplikasi BREW ada di tingkat atas, pengembang dapat menyimpan sejumlah besar waktu dan tenaga tanpa perlu menyesuaikan setiap aplikasi untuk setiap jenis perangkat mobile.
12
2.2.1
BREW dan J2ME
J2ME atau Java 2 Platform, Micro Edition adalah sebuah set API dari Java Platform miliki Sun Microsystems untuk pengembangan perangkat lunak untuk perangkat yang kecil dan memiliki kemampuan terbatas seperti telepon seluler, PDA, dan settop boxes. Banyak aplikasi untuk perangkat nirkabel saat ini yang dibuat dengan J2ME. Sementara J2ME telah terbukti memiliki ketahanan yang lebih baik terhadap crash dibandingkan dengan BREW dari sudut pandang pengembangan game, BREW memiliki beberapa kelebihan dibandingkan dengan J2ME, yaitu: ¾ API yang dimiliki BREW lebih memiliki standar yang jelas untuk telepontelepon yang mendukungnya dibandingkan dengan API dari J2ME, yang dapat sangat berbeda tergantung pada jenis teleponnya. ¾ API BREW lebih baik dari J2ME, dan banyak dari perubahan-perubahan API yang telah dilakukan membuat BREW lebih baik sebagai game. ¾ Trik-trik grafis lebih mudah dilakukan, terutama dengan BREW 2.0 dan akses langsungnya ke buffer layar. ¾ Telepon J2ME seringkali memiliki batasan buatan terhadap ukuran binernya (umumnya 128KB) yang tidak dimiliki oleh BREW. ¾ Aplikasi BREW yang diunduh ke dalam suatu perangkat memiliki ID yang unik untuk setiap perangkat sehingga tidak dapat dibajak. Di samping itu, BREW juga memiliki beberapa kelemahan jika dibandingkan dengan J2ME: ¾ Dalam J2ME, seluruh source file dan file-file resource tambahannya telah terkompres secara
default, sedangkan untuk mengompres file resource dan
source code dengan BREW, pengembang harus mencari metoda sendiri. ¾ Profiler yang komersil untuk C/C++ memiliki harga yang tinggi, sementara lingkungan J2ME sudah menyediakan sebuah profiler sendiri. Namun, profiler C/C++ open source yang gratis untuk Linux sudah tersedia. ¾ BREW tidak memiliki aplikasi pendukung untuk IDE (Integrated Development Environment) seperti Eclipse atau Netbeans, yang telah membuat perancangan aplikasi J2ME lebih mudah dengan hanya sedikit atau bahkan tanpa 13
pemrograman. ¾ Ada cukup banyak inkompatibilitas di dalam handset BREW, misalnya buku alamat terimplementasi dengan sangat berbeda di dalam telepon yang berbeda pembuatnya sehingga pendekatan khusus diperlukan untuk membedakan antara buku alamat yang berdasarkan pada kriteria dan yang berdasarkan pada isinya. ¾ Implementasi BREW pada handset Motorola dan Nokia terkadang harus bekerja bersama sistem operasi yang sudah ada, yang menghasilkan performa yang buruk.
2.2.2
Struktur Aplikasi BREW
Dasar dari sebuah aplikasi BREW terdiri dari tiga komponen, yaitu file MIF (Module Information File), file biner, dan file resource. File MIF memberikan titik masuk aplikasi dan juga digunakan untuk menjelaskan aplikasi dengan menyimpan icon dan ClassID yang unik, serta memberikan informasi tentang library eksternal yang diperlukan untuk menjalankan aplikasi. File biner merupakan file Win32.dll dari Windows yang dibangun dalam lingkungan pengembangan. File resource merupakan file terkompilasi yang memiliki informasi tentang sumber daya yang digunakan oleh aplikasi. Setiap aplikasi BREW memiliki ClassID yang unik. ClassID merupakan bagian penting untuk menjalankan aplikasi dan untuk keamanan. Semua aplikasi BREW yang dibuat harus memiliki suatu ID yang unik di mana pun di dunia. ID ini berupa angka heksadesimal 32-bit yang disediakan oleh BREW ClassID Generator yang ada di BREW Extranet. Gambar X menunjukkan hubungan antara setiap komponen dalam suatu aplikasi BREW. MIF Editor yang ada dalam SDK digunakan untuk menciptakan file MIF, yang memiliki informasi icon dan ClassID dari aplikasi. Icon ditampilkan ke user sebagai suatu perwakilan aplikasi berupa gambar dan ClassID digunakan untuk mengidentifikasi aplikasi yang akan dijalankan. ClassID yang disimpan dalam file .bid dideklarasikan di dalam source code melalui pernyataan #define sesuai dengan nama ClassID yang digunakan, sama dengan yang ada di dalam file MIF. Pernyataan #include juga digunakan untuk memasukkan ClassID ke dalam file yang executable ketika aplikasi di-compile. Ketika aplikasi diinstall, 14
ClassID dari aplikasi tersebut didaftarkan pada BREW runtime dan iconnya dimunculkan. Jadi, ketika pengguna memilih icon yang bersangkutan pada Simulator atau pada perangkat, lingkungan runtime mencocokkan ClassID dari MIF dengan aplikasi dan kemudian menjalankan aplikasi. Proses yang sama dilakukan dengan ketergantungan eksternal, seperti ketika suatu aplikasi memanggil suatu ekstensi atau aplikasi lainnya.
Gambar 2.4 Hubungan ClassID dengan Komponen BREW Lainnya[12] Aplikasi BREW memiliki struktur direktori yang terdiri dari direktori applet dan direktori MIF. Direktori applet didefinisikan sebagai direktori parent dari aplikasi BREW, dengan setiap aplikasi disimpan dalam subdirektori yang berada di bawah direktori parent ini. Setiap aplikasi berada di dalam subdirektori meliputi file biner aplikasi dan file-file pendukungnya, seperti file teks, gambar, atau data yang dipakai oleh aplikasi. Perlu diperhatikan bahwa aplikasi dan subdirektori aplikasi harus memiliki nama yang sama. Direktori MIF berada pada direktori yang sama dengan direktori applet untuk BREW sebelum versi 3. Setiap file MIF aplikasi juga harus memiliki nama yang sama dengan nama aplikasi dan nama subdirektori aplikasi. 15
Penamaan ini merupakan hal yang sangat mendasar di dalam BREW.
Gambar 2.5 Struktur Direktori BREW Sebelum Versi 3.x[12]
Gambar 2.6 Struktur Direktori BREW 3.x[12]
16
2.2.3
Pemrograman BREW
BREW menyediakan berbagai fungsi dan layanan tingkat sistem untuk memfasilitasi pengembangan applet untuk perangkat yang mendukung BREW. Modul-modul yang ada dalam BREW dapat memiliki satu atau lebih applet atau kelas. Kelas-kelas ini ditampilkan oleh suatu modul pada runtime dan dibuka atau ditutup sesuai dengan kebutuhan. AEE yang dimiliki oleh BREW menawarkan sejumlah kategori layanan yang
jelas.
Layanan-layanan
yang
diberikan,
dan
nama
interface
yang
mengimplementasikan layanan tersebut, antara lain dijabarkan dalam Tabel di bawah ini. Tabel 2.1 Interface yang Dimiliki BREW[12] Layanan Sistem Tampilan dan Gambar Kelas Dasar Applet Jaringan Sistem File Kontrol (Menu, Tanggal, Waktu, Teks, Hypertext) Manajemen Database Manajemen Database OEM Tones dan Suara Kontrol Dialog Notifikasi Penggambaran Citra dan Animasi Akses web Enkripsi Data Hashing Membaca Data Lokasi Geografis Fungsi Library C Standar
Interface IShell* IDisplay* IBase* IApplet* IDNS, INetMgr*, ISocket*, ISSL IFileMgr*, IFile* IMenuCtl*, IDateCtl, ITimeCtl, ITextCtl*, IStatic, IHtmlViewer IDBMgr*, IDatabase*, IDBRecord IAddrBook, IAddrRec, IRingerMgr ISound*, ISoundPlayer* IDialog INotifier IBitmap, IDIB, IImage, ISprite IWeb*, IWebResp*, IWebUtil IRSA, ICipher IHash ISource*, ISourceUtil, IPeek, IGetLine IPosDet AEE Helper Functions
IShell merupakan interface yang paling mendasar dalam BREW. Sesuai dengan namanya, interface ini berlaku sebagai interface inti dari BREW dan memberikan jangkauan layanan yang luas. Setiap modul dan applet memperoleh akses ke semua layanan eksternal menggunakan interface yang diperoleh dari interface IShell yang 17
paling mendasar. Interface modul ini dilewatkan untuk membuka suatu fungsi dan menginisialisasinya sebagai fungsi dari modul yang bersangkutan. Dengan interface IShell, applet dan modul dapat meminta pointer ke semua interface yang mereka butuhkan. Sebagai tambahan, IShell berlaku sebagai interface kontrol aplikasi standar, yang bertanggung jawab untuk memanggil dan menutup aplikasi, menjaga keberadaan aplikasi yang ada, dan menyediakan komunikasi antar aplikasi. IShell juga memberikan akses ke resource eksternal, baik yang ada dalam file .bar yang dihasilkan oleh BREW Resource Editor maupun dari file yang disimpan di dalam device. Selain itu, IShell juga memberikan layanan-layanan seperti notifikasi, alarm, timer, dialog, dan fungsi-fungsi lainnya (misalnya beep). Untuk menggunakan interface yang terdapat di BREW, setiap library dari interface yang ada harus dibuka terlebih dahulu, karena BREW sangat padat-memori sehingga interface yang akan digunakan perlu diinisialisasi terlebih dahulu dan memori hanya dipakai ketika interface tersebut dibutuhkan. Untuk membuka library yang akan digunakan, digunakan metode CreateInstance dari IShell. Prototipe fungsinya yaitu: int ISHELL_CreateInstance(IShell * pIShell, AEECLSID cls, void ** ppobj);
Dalam contoh di atas, argumen pIShell merupakan pointer yang valid ke interface IShell dan hal ini berlaku untuk semua applet yang berjalan. Argumen cls merupakan ClassID dari kelas yang diinginkan, misalnya AEECLSID_HTML untuk interface IHtmlViewer. Terakhir, variabel ppobj merupakan pointer ke pointer, untuk diisi dengan alamat dari kelas yang diinstansiasi ketika pemanggilan berhasil dilakukan. Ketika suatu interface tidak lagi digunakan, interface tersebut dapat dilepaskan (atau ditutup) untuk membebaskan resources yang digunakan untuk interface tersebut. Hal ini berlawanan dengan fungsi ISHELL_CreateInstance. Untuk melepas suatu interface, fungsi Release() dari interface yang bersangkutan harus dipanggil. Misalnya untuk melepas interface grafik, fungsi yang dipanggil adalah IGRAPHICS_Release().
18
Berikut ini merupakan struktur dasar dari sebuah source code aplikasi BREW: /*========================================================================== = FILE: myapp.c ===========================================================================* / /*========================================================================== == INCLUDES AND VARIABLE DEFINITIONS =========================================================================== */ #include "AEEModGen.h" // Module interface definitions #include "AEEAppGen.h" // Applet interface definitions #include "AEEShell.h" // Shell interface definitions #include "myapp.bid" /*------------------------------------------------------------------Applet structure. All variables in here are reference via "pMe->" -------------------------------------------------------------------*/ // create an applet structure that's passed around. All variables in // here will be able to be referenced as static. typedef struct _myapp { AEEApplet a ; // First element of this structure must be AEEApplet AEEDeviceInfo DeviceInfo; // always have access to the hardware device information // add your own variables here... } myapp; /*------------------------------------------------------------------Function Prototypes -------------------------------------------------------------------*/ static boolean myapp_HandleEvent(myapp* pMe, AEEEvent eCode, uint16 wParam, uint32 dwParam); boolean myapp_InitAppData(myapp* pMe); void myapp_FreeAppData(myapp* pMe); /*========================================================================== = FUNCTION DEFINITIONS ========================================================================== */ /*========================================================================== = FUNCTION: AEEClsCreateInstance DESCRIPTION This function is invoked while the app is being loaded. All Modules must provide this function. Ensure to retain the same name and parameters for this function. In here, the module must verify the ClassID and then invoke the AEEApplet_New() function that has been provided in AEEAppGen.c. After invoking AEEApplet_New(), this function can do app specific initialization. In this example, a generic structure is provided so that app developers need not change app specific initialization section every time except for a call to IDisplay_InitAppData(). This is done as follows: InitAppData() is called to initialize AppletData instance. It is app developers responsibility to fill-in app data initialization code of
19
InitAppData(). App developer is also responsible to release memory allocated for data contained in AppletData -this can be done in IDisplay_FreeAppData(). PROTOTYPE: int AEEClsCreateInstance(AEECLSID po,void ** ppObj)
ClsId,IShell
*
pIShell,IModule
*
PARAMETERS: clsID: [in]: Specifies the ClassID of the applet which is being loaded pIShell: [in]: Contains pointer to the IShell object. pIModule: pin]: Contains pointer to the IModule object to the current module to which this app belongs ppObj: [out]: On return, *ppObj must point to a valid IApplet structure. Allocation of memory for this structure and initializing the base data members is done by AEEApplet_New(). DEPENDENCIES none RETURN VALUE AEE_SUCCESS: If the app needs to be loaded and if AEEApplet_New() invocation was successful EFAILED: If the app does not need to be loaded or if errors occurred in AEEApplet_New(). If this function returns FALSE, the app will not be loaded. SIDE EFFECTS none ===========================================================================* / int AEEClsCreateInstance(AEECLSID ClsId, IShell *pIShell, IModule *po, void **ppObj) { *ppObj = NULL; if( ClsId == AEECLSID_MYAPP ) { // Create the applet and make room for the applet structure if( AEEApplet_New(sizeof(myapp), ClsId, pIShell, po, (IApplet**)ppObj, (AEEHANDLER)myapp_HandleEvent, (PFNFREEAPPDATA)myapp_FreeAppData) ) // the FreeAppData function is called after sending EVT_APP_STOP to the HandleEvent function { //Initialize applet data, this is called before sending EVT_APP_START // to the HandleEvent function if(myapp_InitAppData((myapp*)*ppObj)) { //Data initialized successfully return(AEE_SUCCESS); } else { //Release the applet. This will free the memory // allocated for the applet when // AEEApplet_New was called. IAPPLET_Release((IApplet*)*ppObj); return EFAILED; } } // end AEEApplet_New
20
} return(EFAILED); } /*========================================================================== = FUNCTION SampleAppWizard_HandleEvent DESCRIPTION This is the EventHandler for this app. All events to this app are handled in this function. All APPs must supply an Event Handler. PROTOTYPE: boolean SampleAppWizard_HandleEvent(IApplet uint16 wParam, uint32 dwParam)
*
pi,
AEEEvent
eCode,
PARAMETERS: pi: Pointer to the AEEApplet structure. This structure contains information specific to this applet. It was initialized during the AEEClsCreateInstance() function. ecode: Specifies the Event sent to this applet wParam, dwParam: Event specific data. DEPENDENCIES none RETURN VALUE TRUE: If the app has processed the event FALSE: If the app did not process the event SIDE EFFECTS none ===========================================================================* / static boolean myapp_HandleEvent(myapp* pMe, AEEEvent eCode, uint16 wParam, uint32 dwParam) { switch (eCode) { // App is told it is starting up case EVT_APP_START: // Add your code here... return(TRUE); // App is told it is exiting case EVT_APP_STOP: // Add your code here... return(TRUE); // App is being suspended case EVT_APP_SUSPEND: // Add your code here... return(TRUE); // App is being resumed case EVT_APP_RESUME: // Add your code here... return(TRUE); // An SMS message has arrived for this app. Message is in the dwParam // above as (char *) sender simply uses this format // "//BREW:ClassId:Message", example //BREW:0x00000001:Hello World case EVT_APP_MESSAGE: // Add your code here...
21
return(TRUE); // A key was pressed. Look at the wParam above to see which key was // pressed. The key codes are in AEEVCodes.h. Example "AVK_1" means that // the "1" key was pressed. case EVT_KEY: // Add your code here... return(TRUE); // If nothing fits up to this point then we'll just break out default: break; } return FALSE; } // this function is called when your application is starting up boolean myapp_InitAppData(myapp* pMe) { // Get the device information for this handset. // Reference all the data by looking at the pMe->DeviceInfo structure // Check the API reference guide for all the handy device info you can get pMe->DeviceInfo.wStructSize = sizeof(pMe->DeviceInfo); ISHELL_GetDeviceInfo(pMe->a.m_pIShell,&pMe->DeviceInfo); // Insert your code here for initializing or allocating resources... // if there have been no failures up to this point then return success return TRUE; } // this function is called when your application is exiting void myapp_FreeAppData(myapp* pMe) { // insert your code here for freeing any resources you have allocated... // // // // // trying // //
example to use for releasing each interface: if ( pMe->pIMenuCtl != NULL ) // check for NULL first { IMENUCTL_Release(pMe->pIMenuCtl) // release the interface pMe->pIMenuCtl = NULL; // set to NULL so no problems to free later }
}
2.2.4
BREW Compressed Image
BREW memiliki suatu format gambar yang disebut dengan BREW Compressed Image (BCI). BCI merupakan sebuat format file terkompres yang memfasilitasi decoding dan menampilkan gambar secara cepat pada perangkat handheld. Kompresi dan dekompresi gambar dilakukan dengan menggunakan teknik inflate / deflate. Format ini dioptimasi untuk lingkungan handset BREW dan dengan BCI Authoring 22
Tool yang ada dalam SDK, gambar dari berbagai macam sumber dapat diubah dan dikompres dengan rasio yang cukup tinggi, sehingga dapat meningkatkan efisiensi untuk mengunduh dan menampilkan gambar sambil tetap menjaga kualitas gambar yang tinggi. Selain kompresi, BCI juga mendukung animasi dasar yang juga dapat dibuat dengan BCI Authoring Tool dengan cara menambahkan urutan gambar dan frame rate-nya.
2.3 Requirements Analysis Dalam sistem dan rekayasa perangkat lunak, requirements analysis meliputi tugastugas untuk menentukan kebutuhan terhadap suatu sistem yang baru, dengan memperhitungkan kebutuhan-kebutuhan yang mungkin dari berbagai pemegang peran dalam sistem, termasuk pengguna. Requirements analysis sangat penting untuk kesuksesan suatu proyek. Requirements analysis yang sistematik juga dikenal dengan istilah requirements engineering. Zave mendefinisikan requirements engineering sebagai salah satu cabang rekayasa perangkat lunak yang berhubungan dengan tujuan di dunia nyata sebagai fungsi dan batasan dari suatu sistem perangkat lunak, dan juga berhubungan dengan hubungan antara setiap faktor yang ada untuk memastikan spesifikasi dari perilaku perangkat lunak dan evolusinya seiring dengan waktu dan di antara perangkat lunak lainnya[7]. Definisi tersebut menekankan pentingnya “tujuan di dunia nyata” yang memotivasi pengembangan suatu sistem perangkat lunak. Hal ini mewakili ‘mengapa’ dan juga ‘apa’ dari sistem. Definisi di atas juga menyebutkan tentang “memastikan spesifikasi”, yang merupakan dasar untuk menganalisis kebutuhan, meyakinkan bahwa kebutuhan tersebut benar-benar yang dibutuhkan oleh pemegang peran, menjelaskan apa yang harus dibangun oleh pengembang, dan mencocokkan bahwa pengembang telah melakukan hal yang tepat. Di akhir, definisi di atas menyebutkan “evolusinya seiring dengan waktu dan di antara perangkat lunak lainnya”, menekankan kenyataan mengenai dunia yang akan berubah dan adanya kebutuhan untuk menggunakan kembali sebagian dari spesifikasi yang ada. 23
2.3.1
Volere Requirements Specification Template[9]
Perusahaan Atlantic System Guild membuat Volere Requirements Specification Template untuk dapat digunakan oleh software engineer sebagai dasar untuk spesifikasi kebutuhan. Template ini memberikan bagian-bagian untuk setiap jenis kebutuhan yang sesuatu dengan sistem perangkat lunak saat ini. Template ini meliputi kriteria-kriteria sebagai berikut: 1. The Purpose of the Project 1a. The User Business or Background of the Project Effort Deskripsi singkat tentang proyek yang dilakukan, konteksnya, dan situasi yang melatarbelakangi usaha pengembangan. 1b. Goals of the Project Tujuan dan alasan utama mengapa produk ini dikembangkan. 2. The Client, the Customer, and Other Stakeholders 2a. The Client Menyebutkan klien-klien, yaitu pihak-pihak yang harus merasa puas terhadap produk ini. 2b. The Customer Menyebutkan pelanggan, yaitu pihak-pihak yang ditargetkan untuk membeli produk ini. 2c. Other Stakeholders Pihak-pihak lain yang memegang peran terhadap produk atau yang masukannya diperlukan untuk membuat produk ini. 3. Users of the Product 3a. The Hands-On Users of the Product Daftar dari pengguna potensial untuk produk ini. 3b. Priorities Assigned to Users Kategori prioritas untuk setiap pengguna yang menunjukkan kepentingan dan prioritas pengguna 3c. User Participation Bila diperlukan, dijelaskan mengenai partisipasi pengguna yang diperlukan untuk mengetahui kebutuhan. 24
3d. Maintenance Users and Service Technician Pengguna khusus yang ditargetkan untuk memelihara dan mengubah produk. 4. Mandated Constraints 4a. Solution Constraints Batasan cara-cara berupa teknologi atau solusi untuk memecahkan masalah. 4b. Implementation Environment of the Current System Lingkungan teknologi dan fisik tempat pemasangan produk. 4c. Partner or Collaborative Applications Aplikasi yang bukan bagian dari produk tetapi berkolaborasi dengan produk. 4d. Off-the-shelf Software Software yang harus digunakan untuk mengimplementasikan beberapa kebutuhan produk. 4e. Anticipated Workplace Environment Tempat kerja yang digunakan pengguna untuk memakai produk. 4f. Schedule Constraints Batasan waktu untuk produk. 4g. Budget Constraints Budget untuk produk ini. 5. Naming Conventions and Definitions 5a. Definitions of All Terms, Including Acronyms, Used in the Project Daftar istilah dan artinya yang digunakan dalam spesifikasi kebutuhan. 5b. Data Dictionary for Any Included Models Definisi kamus dari setiap informasi yang digunakan dalam model. 6. Relevant Facts and Assumptions 6a. Facts Faktor-faktor yang memiliki pengaruh terhadap produk, tetapi bukan batasan persyaratan yang mutlak. 6b. Assumption 25
Asumsi-asumsi yang dibuat oleh pengembang yang berhubungan dengan produk. 7. The Scope of the Work 7a. The Current Situation Analisis proses bisnis yang sudah ada. 7b. The Context of the Work Pekerjaan yang harus diperiksa untuk dapat membuat produk. 7c. Work Partitioning Event bisnis yang berhubungan dengan pembuatan proyek. 8. The Scope of the Product 8a. Product Boundary Batasan antara produk dengan pengguna. 9. Functional and Data Requirements 9a. Functional Requirements Spesifikasi kebutuhan fungsional. 9b. Data Requirements Spesifikasi subyek yang diperlukan. 10. Look and Feel Requirements 10a. Appearance Requirements Kebutuhan tampilan dari produk. 10b. Style Requirements Kebutuhan gaya dari produk yang akan mempengaruhi pandangan pengguna terhadap produk. 11. Usability and Humanity Requirements 11a. Ease of Use Requirements Kemudahan pengguna untuk menggunakan produk. 11b. Personalization and Internationalization Requirements Kebutuhan dan pilihan tiap-tiap pengguna yang dapat diubah-ubah pada produk. 11c. Learning Requirements Seberapa mudah produk dapat digunakan oleh pengguna. 26
11d. Understandability and Politeness Requirements Kebutuhan produk untuk dapat dimengerti oleh pengguna. 11e. Accessibility Requirements Seberapa mudah produk dapat digunakan oleh orang-orang cacat. 12. Performance Requirements 12a. Speed and Latency Requirements Respon waktu yang dibutuhkan untuk melakukan suatu tugas. 12b. Safety-Critical Requirements Perhitungan resiko pada manusia, properti, dan lingkungan. 12c. Precision or Accuracy Requirements Perhitungan akurasi yang diinginkan dari hasil yang diberikan produk. 12d. Reliability and Availability Requirements Perhitungan reliabilitas yang diperlukan untuk produk. 12e. Robustness or Fault-Tolerance Requirements Kemampuan produk untuk dapat tetap berfungsi dalam keadaan abnormal. 12f. Capacity Requirements Besarnya ukuran produk yang dapat ditangani dan besar data yang dapat disimpan oleh produk. 12g. Scalability or Extensibility Requirements Penambahan ukuran yang dapat ditangani oleh produk. 12h. Longevity Requirements Usia yang diperkirakan dari produk. 13. Operational and Environmental Requirements 13a. Expected Physical Environment Lingkungan fisik di mana produk dapat bekerja. 13b. Requirements for Interfacing with Adjacent Systems Kebutuhan antarmuka dengan aplikasi lain dan/atau device yang diperlukan oleh produk untuk dapat bekerja. 13c. Productization Requirements Kebutuhan yang diperlukan untuk membuat produk dapat dijual. 27
13d. Release Requirements Siklus rilis produk yang diinginkan dan bentuknya. 14. Maintainability and Support Requirements 14a. Maintenance Requirements Banyaknya waktu yang dibutuhkan untuk membuat perubahan tertentu pada produk. 14b. Supportability Requirements Tingkat dukungan yang diperlukan oleh produk, baik berupa layanan pelanggan maupun dukungan di dalam software itu sendiri. 14c. Adaptability Requirements Penjelasan platform atau lingkungan lain di mana produk harus di-port. 15. Security Requirements 15a. Access Requirements Siapa saja yang memiliki akses terotorisasi pada produk (fungsi dan data), dalam keadaan apa akses diberikan, dan akses terhadap bagian mana dari produk yang diijinkan. 15b. Integrity Requirements Integritas yang dibutuhkan terhadap database atau file-file lainnya, dan terhadap produk itu sendiri. 15c. Privacy Requirements Jaminan terhadap hal pribadi seseorang yang disimpan oleh produk. 15d. Audit Requirements Hal yang harus diberikan produk untuk memberikan informasi yang dibutuhkan untuk pemeriksaan audit. 15e. Immunity Requirements Kebutuhan produk untuk melindungi diri terhadap serangan software yang tidak diinginkan. 16. Cultural and Political Requirements 16a. Cultural Requirements Kebutuhan
yang
berhubungan
dengan
mempengaruhi penerimaan terhadap produk. 28
faktor
sosiologis
yang
16b. Political Requirements Kebutuhan yang berhubungan dengan faktor politis yang mempengaruhi penerimaan terhadap produk. 17. Legal Requirements 17a. Compliance Requirements Kebutuhan hukum dari sistem ini. 17b. Standards Requirements Standar yang dapat diterapkan pada produk dan deskripsi dari standar yang bersangkutan.
29
