Gears - API Architecture

Pada aplikasi offline-enabled, ada beberapa masalah yang perlu dipertimbangkan, yaitu:

• Mengisolasi layar data
• Memutuskan fitur mana yang di-offline-kan (strategi koneksi)
• Memutuskan cara aplikasi melakukan sesuatu
• Menerapkan sinkronisasi data.
  

Mengisolasi Layar Data
Pada kebanyakan aplikasi web tidak ada layar data yang sebenarnya.

AJAX memanggil originate melalui kode, tanpa satupun layar komunikasi yang kosong. Ini biasanya, aman-aman aja buat aplikasi AJAX, karena hanya ada satu data source: server. Dampaknya, API dimana server men-expose ke AJAX bertindak sebagai layar data.

Arsitektur dengan layar data
Secara umum, mengisolasi layar data merupakan langkah awal yang bagus.

Ketika anda menambahkan sebuah penyimpanan data lokal pada aplikasi anda, anda akan mendapatkan sebuah tempat dimana semua penyimpanan data dan request yang diterima dilewatkan. Contohnya, jika aplikasi AJAX mengeluarkan sebuah JSON(JavaScript Object Notation) untuk me-request secara langsung ke server untuk mendapatkan semua account untuk satu user, anda mungkin menggantinya dengan meminta objek intermediate untuk mendapatkan semua account untuk user tersebut. Objek ini kemudian dapat memutuskan apakah mengambil data dari server, penyimpanan lokal, atau kombinasi keduanya. Hampir mirip, ketika aplikasi ingin men-update account user, aplikasi melakukan hal yang sama dengan memanggil objek intermediate. Objek intermediate dapat memutuskan kemudian, apakah menuliskan data secara lokal, apakah mengirimkan data ke server dan mensikronisasikannya.

Anda dapat menganggap objek intermediate ini sebagai sebuah layar pertukaran data yang mengimplementasikan interface yang sama seperti layar data. Sebagai langkah pertama, anda dapat membuat penukar data(data switch) meneruskan semua panggilan ke layar data yang berinteraksi dengan server. Langkah ini sangat berguna karena ini merupakan jalan kode yang diikuti ketika gears tidak diinstal atau bahkan user tidak mengizinkan aplikasi bekerja secara offline. Sebagai catatan, data switch tidak terlalu diperlukan( contohnya GearPad tidak memiliki layar data switch).

Langkah selanjutnya, seperti pada diagram di bawah, adalah membuat layar data yang menggunakan database gears dari pada mengambil data dari web server. Hal ini akan menjadi lebih sederhana jika layar data ini memiliki interface yang sama dengan layar data yang ada, yang digunakan untuk berkomunikasi dengan server. Jika interface-nya berbeda maka perlu dilakukan penerjemahan dan mungkin anda melakukan hal itu pada layar data ini. Untuk menguji langkah ini, anda dapat mengatur layar data switch untuk berkomunikasi dengan layar data(lokal) yang baru ini. Anda mungkin perlu terlebih dahulu mengisi database untuk mempermudah pengujian.

Arsitektur tanpa layar data

Jika aplikasi tidak distruktur dengan layar data dan penambahan layar data bukan suatu pilihan, masih memungkinkan untuk mengisolasi layar data dengan menangkap semua panggilan ke web server, sebelum dikirimkan. Contohnya, anda dapat menangkap form submit(pada saat submit) dan memutuskan apakah aplikasi menggunakan penyimpanan lokal data atau data di server.

Penerapan ini melibatkan pencarian semua fungsi dan method yang mengirimkan request ke server, dan mengubah alurnya. Letak tantangannya adalah method ini memerlukan banyak usaha, seperti melewatka URL, membuat form menghasilkan hasil yang sama server. Dalam pelaksanaannya, anda tidak lagi mengimplementasikan kembali bagian besar dari web server pada sisi client. Bagaimanapun juga, hal ini dapat mengaktifkan pilihan untuk aplikasi AJAX yang ada, yang tidak dapat diarsiteturkan kembali.

Feature Availability Offline

Untuk beberapa alasan tertentu, setiap fitur pada aplikasi tidak memungkinkan available untuk offline. Anda perlu memilih fitur yang anda inginkan untuk mendukung secara lokal dan mengimplementasikan logic yang memutuskan kapan menggunakan penyimpanan lokal dan kapan dapat terhubung ke server. Kita dapat menyebutnya “Connection Strategy”.

Anda mungkin mengira bahwa anda akan selalu melakukan penyimpanan data secara loakal karena lebih cepat. Meskipun begitu, ada banyak alasan tertentu mengapa anda membutuhkan akses data ke server. Contohnya:

• Data sangat transient(penyimpanan sementara) sehingga sangat tidak masuk akal untuk mendapatkannya. Misalnya: aplikasi yang menyediakan real-time stock quotes
• Beberapa data aplikasi yang hanya ada ketika online. Misalnya: instant messaging
• Aplikasi mungkin memilih untuk menyimpan data hanya untuk data yang paling sering diakses. Misalnya, jika user dapat menge-set preference pada sebuah aplikasi.

Perhitungan atau requirement disk disk space, membuatnya tidak mungkin membuat fitur online. Misalnya, fitur ini membutuhkan banyak data.Khususnya, solusi utama adalah menggunakan penyimpanan lokal sebanyak mungkin, karena hal itu lebih cepat dibandingkan remote connection.

Akan tetapi, akan semakin banyak pekerjaan yang dilakukan oleh aplikasi secara lokal, akan semakin banyak kode yang diperlukan untuk mengimplementasikan fitur secara lokal dan mensinkronisasi data. Ada banyak keuntungan dan kerugian yang perlu dipertimbangkan, dan beberapa fitur yang mungkin tidak mendukung secara lokal.

Modality(Cara kerja)
Pertanyaan mendasar tentang semua aplikasi yang membolehkan offline, harus menjawab mengenai “cara kerjanya”:

• Cara kerja aplikasi harus dibedakan antara mode offline dengan mode online, biasanya diindikasi melalui beberapa perubahan pada user interface. User berhati-hati pada state dan berpartisipasi mengganti state.
• Cara kerja aplikasi tidak mengharuskan user turut campur mengubah state, karena aplikasi tersebut dapat merubah state offline dan online nya sendiri.

Modal
Dalam cara kerja aplikasi, ketika aplikasi online, aplikasi berkomunikasi dengan server. Ketika aplikasi offline aplikasi menggunakan penyimpanan lokal. Data harus disinkronisasi ketika aplikasi berubah mode.

Keuntungan modal application adalah sederhana untuk diimplementasikan dan mengusahakan sendiri agar aplikasi berfungsi saat offline.

Kerugiannya yaitu:

• User harus ingat untuk mengganti mode. Jika user lupa, maka mereka tidak akan mendapatkan data yang mereka butuhkan baik ketika offline, maupun saat online akan tetapi koneksi terputus di tengah jalan.
• Jika koneksi terputus-putus, user harus memilih salah satu pengaturan, atau terus menerus mengganti koneksi ketika putus-sambung.
• Karena penyimpanan lokal tidak selalu up-to-date, hal ini dapat menyebabkan memperlambat applikasi ketika terhubung ke server.

Modeless

Dalam aplikasi modeless, aplikasi berkerja dengan mengansumsikan aplikasi dalam keadaan offline, atau kapan saja dapat kehilangan koneksi. Oleh sebab itu applikasi haruse menyediakan penyimpanan data lokal sebanyak mungkin, dan terus menerus, data kecil akan disinkronisasi di bagian background ketika server available. Sehingga data dapat tersinkronisasi ketika kembali online.

Keuntungan aplikasi modales yaitu:

• Meningkatkan kepuasan user. User tidak harus mewaspadai koneksi internet atau merubah state.
• Aplikasi dapat berjalan dengan smooth bahkan dengan koneksi yang terputus-putus
• Karena penyimpanan lokal tetap dijaga up-to-date, sehingga dapat mengoptimisasi koneksi server

Kerugiannya yaitu:

• Hal ini sangat sulit untuk diimplementasikan
• Kekhawatiran terbesar adalah ketika membiarkan sinkronisai pada bagian background, hal ini dapat meyebabkan konsumsi banyak resource dan membuat aplikasi menjadi lambat.
• Menguji aplikasi akan semakin sulit, karena logic sinkronisasi terjadi di bagian background dan tidak pada reaksi tertentu dari user.

Contoh aplikasi modeless dapat dilihat dari gearpad. Database akan selalu dirubah, dan secara bebas mensinkronisasikan perubahan ke server.Google reader merupakan salah satu contoh aplikasi modal.

Sinkronisasi data

Tidak masalah strategi koneksi dan modality apa yang digunakan, data dalam database lokal akan disinkronisasikan dengan data server.

Contoh, kapan sinkronisasi data lokal dan data server:

1. User membuat perubahan ketika offline
2. Data di-shared dan dapat diganti oleh pihak lain.
3. Data datang dari sumber luar, seperti sebuah penyuplai(penyedia)

Untuk memcahkan masalah ini adalah dengan menggunakan sinkronisasi. Banyak upaya sinkronisasi dan tak satupun yang sempurna untu semua kondisi. Solusinya terletak pada kustomisasi pada bagian tertentu dari aplikasi. Berikut ini ada 2 tipe sinkronisasi.

Sinkronisasi Manual
Ini adalah sinkronisasi yang paling mudah. Disebut manual karena user yang memutuskan kapan dilakukan sinkronisasi. Hal ini dapat dilakukan dengan cara sederhana, dengan meng-upload semua data lama ke server, dan meng-copy data baru dari server sebelum offline.

Sinkronisasi manual dapat dilakukan dengan syarat:

• Jumlah data cukup kecil untuk di-download dalam waktu yang masuk akal
• User secara eksplisit mengindikasikan kapan dia akan offline, biasanya melalui tombol pada aplikasi

Masalah dari pengimplementasian metode ini dan ketika membuat mode offline, yaitu:

• User tidak selalu tahu state dari koneksi internet mereka. Koneksi internet bisa saja terputus ataupun putus-sambung, seperti bis.
• User lupa mensinkronisasi sebelum offline.

Sinkronisasi manual merupakan cara yang bagus untuk memulai karena cukup mudah dalam mengiplementasikannya. Akan tetapi, membutuhkan kewaspadaan dan turut campur user dalam proses sinkronisasi.

Sinkronisasi di background

Dengan sinkronisasi ini, aplikasi terus menerus mensinkronisasi data antara data lokal dan data server. Hal ini dapat dilakukan dengan sewaktu-waku mem- ping ke server atau lebih baik, membiarkan server memaksa data ke client(ini disebut Comet dalam Ajax lingo)

Keuntungan sinkronisasi di bagian background yaitu:

• Data tersedia kapan saja, kapanpun ketika user offline, atau tiba-tiba terputus
• Performansi ditingkatkan ketika menggunakan koneksi lambat.

Sisi terburuknya adalah engine sinkronisasi mungkin menggunakan banyak resource dan melambatnya aplikasi ketika bagian background bekerja(Jika tidak menggunakan Worker Pool). Dengan menggunakan Worker Pool pengorbanan untuk sinkronisasi dapat diminimumkan dan tidak terlalu berpengaruh terhadapa interaksi dengan user.

Gears - WorkerPoolAPI

WorkerPool API memungkinkan aplikasi web menjalankan kode JavaScript di bagian background, tanpa mem-blok eksekusi halaman utama script.

OverView

Dalam satu waktu operasi intensif web browser, seperti operasi I/O atau perhitungan yang berat, dapat membuat UI tidak responsif. API worker pool menjalankan operasi di bagian background, tanpa memblok UI.Script yang mengeksekusi dalam Worker Pool tidak akan memicu dialog “Unresponsive Script”.

Permission

API membutuhkan user permission. Jika anda ingin merubah default-dialog, anda dapat memanggil google.gears.factory.getPermission()secara eksplisit.

Contoh:

// main.js
var workerPool = google.gears.factory.create('beta.workerpool');
workerPool.onmessage = function(a, b, message) {
alert('Received message from worker ' + message.sender + ': \n' + message.body);
};
var childWorkerId = workerPool.createWorkerFromUrl('worker.js');
workerPool.sendMessage(["3..2..", 1, {helloWorld: "Hello world!"}], childWorkerId);

// worker.js
var wp = google.gears.workerPool;
wp.onmessage = function(a, b, message) {
var reply = message.body[0] + message.body[1] + "... " + message.body[2].helloWorld;
wp.sendMessage(reply, message.sender);

Details

Isolasi Kode dan Data

WorkedPool berprilaku seperti sekumpulan proses, daripada sekumpulan thread. Worker tidak membagikan eksekusi state apapun. Merubah sebuah variable dalam satu worker tidak akan menggangu(tidak mempengaruhi) worker manapun. Dan membuat worker, tidak secara otomatis menurunkan kode script dari parent nya.
Anggota dari WorkedPool berinteraksi satu sama lain, hanya melalui pengiriman satu objek pesan.

Batasan

Worker tidak memiliki akses ke DOM(Document Object Model), objek seperti document dan window hanya berada pada halaman utama. Ini adalah konsekuensi dari si worker tidak mau berbagi execution-state.

Walaupun begitu, worker memiliki akses ke semua fungsi-fungsi JavaScript built-in. Kebanyakan method-method Gears dapat juga digunakan, melalui sebuah variable global, yang didefinisikan: google.gears.factory. (terkecuali LocalServer file submitter, yang membutuhkan DOM). Untuk fungsionalitas yang lain, worker dapat meminta halaman utama untuk membawa request.

Usage Pattern
Untuk memahami bagaimana menggunakan API WorkerPool, mari kita lihat contoh berikut:

Urutan Inisialisasi

1. Kode JavaScript(“parent” –nya si worker) menggunakan google.gears.factory untuk membuat sebuah WorkerPool wp.
2. Parent mengindikasi ke mana pesan harus pergi dengan men-setting wp.onmessage. Hal ini dilakukan sebelum memanggil createWorker(), untuk memastikan tidak ada pesan yang hilang.
3. Untuk setiap worker yang baru(“child” worker)

• Parent memanggil wp.createWorkerFromUrl()dengan URL yang mengembalikan keseluruhan script yang akan dimiliki oleh child.
• CreateWorkerFromUrl()dengan cepat mengembalikannya dan parent tetap terus berjalan.
• Secara parallel, child mengambil kode script-nya dan menjalankannya dalam satu waktu. Selama waktu ini, child harus menge-set onmessage handler nya, pada variable global google.gears.workerPool yang telah didefinisikan sebelumnya.
  

Komunikasi

Worker mengirinkan pesan satu sama lain, dengan menggunakan sendMessage().Anggota manapun pada WorkerPool dapat berkomunikasi dengan member manapun.
Setiap pesan yang terkirim memicu onmessage handler penerima(receiver). Event dari pesan, ditangani layaknya event JavaScript lainnya. Secara particular, pemrosesan disisipkan antar halaman dengan cara yang sama, disana terdapat antrian event, dan event handler selanjutnya tidak dipanggil sampai event sebelumnya kembali.

WorkedPool bukan sebuah singleton. Satu halaman dapat menginstansi banyak WorkerPool, dan masing pool ini terisolasi satu sama lain. Hal ini memungkinkan banyak alat pada sebuah halaman, contohnya menggunakan API WorkerPool tanpa takut bertabrakan.

Bagaimana script mengetahui worker ID yang mana mengirmkan pesan kemana. Ada 2 cara umum, yaitu :

1. Membuat parameter kedua ke onmessage, yang berisi ID worker pengirim. “dengkuran” worker yang tujuannya untuk mengeksekusi request secara tidak serempak(asynchronously), akan terus menggunakan method ini, merespon kapanpun worker membuat request dengan membabi-buta.
2. Menggunakan nilai yang dikembalikan oleh createWorker(), yang merupakan ID dari worker yang baru terbentuk. Worker yang tujuannya adalah untuk mengkoordinasi task-task(biasanya kode “utama” aplikasi JavaScript) yang akan sering menggunakan method ini. ID dapat dikirimkan ke, dan digunakan oleh, anggota WorkPool manapun, tapi ini jarang dibutuhkan.
   

Cross-OriginsWorkers

Worker dapat di-load menyeberangi asalnya dengan menggunakan method createWorkerFromUrl(). Worker diload meyeberangi asalnya, cara ini berjalan dalam konteks security dari asal dimana mereka di-laod. Hal ini dapat digunakan untuk mengizinkan pengendalian komunikasi melalui halaman-halaman dalam asal(origin) yang berbeda.

Untuk membuat Gears mengeksekusi cross-origin workers, ada beberapa batasan:

• Worker harus dijalankan dengan content-type application/x-gears-worker
• Kode worker harus memanggil google.gears.workerPool.allowCrossOrigin()
  

Ketika allowCrossOrigin()dipanggil, cross-origin worker dengan otomatis menurunkan permission dari asal(origin) pemanggil nya.

Untuk melihat struktur class dan method nya dapat dilihat lebih lanjut di: http://code.google.com/apis/gears/api_workerpool.html

Berkenalan dengan AJAX

Perkenalan
Ajax telah mengubah cara user berinteraksi dengan halaman web. Setelah sekian lama para pengguna web frustasi dengan paradigma redraw-refresh pada aplikasi web tradisional, yang mengambil keseluruhan isi pada halaman web dari server. Hal ini menyebabkan user kehilangan posisi scroll pada halaman web. Aplikasi ajax memiliki karakteristik untuk meng-update halaman dengan smooth meng-update bagian tertentu pada halaman web, sehingga tidak mengharuskan keseluruhan halaman web di-load kembali. Referensi dari tulisan ini dapat anda dapatkan dari "ASP .NET AJAX in Action"

Apa sih AJAX itu?
AJAX(Asynchronous JavaScript and XML) merupakan upaya atau pola pembangunan web yang menggunakan client-side scripting untuk bertukaran data dengan server. Upaya ini memungkinkan halaman dapat di-update secara dinamis tanpa menyebabkan keseluruhan halaman di-refresh. Sebagai hasilnya, interaksi antara user dan aplikasi tidak terganggu dan terus berlanjut. Beberapa anggapan menyatakan kalau pencapaian ini merupakan bagian dari teknologi dan bukan sebuah pola. Nyatanya, ini merupakan kombinasi pengunaan teknologi dengan cara yang kreatif :D.

Teknologi ini bukan hal yang baru. Teknik asynchronous yang men-load isi dari web dapat ditemukan semenjak Explorer 3 (juga dikenal sebagai masa Jurassic web development) melalui elemen IFRAME. Kemudian, ketika Explorer 5 memperkenalkan XMLHttpRequest ActiveX object, yang memungkinkan pertukaran data antara client dan server melalui web browser scripting languages. Sebagai catatan, remote scripting sebagai perintis jalan tebentuknya AJAX. Sebelum XMLHttpRequest object, remote scripting memungkinkan browser bertukar informasi dengan server.

Bahkan ketika objek XMLHttpRequest diperkenalkan lebih jauh melalui aplikasi Outlook Web Access, ajax tidak begitu terkenal. Sampai akhirnya, Google mempopulerkan teknik ajax melalui google map.

Komponen-komponen AJAX
Sebagaimana telah disebutkan sebelumnya, pola pemprogaman ajax yang terdiri dari sekumpulan teknologi membawa kepuasan pada user dengan cara yang imajinatif. Berikut ini merupakan pilar utama pola pemrograman dan cara mereka berperan :

• JavaScript, merupakan scripting language yang umumnya menambahkan inter-aktifitas ke halaman HTML. JavaScript pada dasarnya menggunakan bahasa pemrograman C secara bebas, JavaScript merupakan bahasa scripting yang paling populer dan didukung oleh hampir keseluruhan browser. Aplikasi AJAX merupakan built in JavaScript.
• Document Object Model (DOM), mendefinisikan struktur dari halaman web sebagai sekumpulan objek yang dapat diprogram yang dapat diakses melalui JavaScript. Dalam pemrograman AJAX, DOM digunakan untuk menggambarkan kembali (re-draw) porsi halaman web secara efektif.
• Cascading Style Sheet (CSS), menyediakan jalan untuk membuat tampilan visual dari elemen-elemen halaman web. CSS digunakan dalam aplikasi AJAX untuk memodifikasi tampilan luar dari user interface secara interaktif.
• XMLHttpRequest, memungkinkan client-side scripting untuk membuat sebuah HTTP request. Ajax menggunakan objek XMLHttpRequest untuk membuat asynchronous request ke server dengan menolak merefresh keseluruhan halaman atau postback.

Sebagai catatan, nama objek XMLHttpRequest bisa menyesatkan karena data dapat ditransfer dalam bentuk XML atau format text-based lainnya. Framework ASP.NET AJAX bergantung pada sebuah format JavaScript Object Notation(JSON) untuk menirimkan data ke dan dari server.

Dalam penerapan ajax, anda dapat menganggap JavaScript sebagai perekat (lem) yang mengikat semuanya. Ketika data dibutuhkan, objek XMLHttpRequest digunakan untuk membuat request ke server. Ketika data dibutuhkan, DOM dan CSS digunakan untuk meng-update interface browser user secara dinamis.

Asynchronous web programming
Huruf A dalam Ajax merupakan kependekan dari asynchronous, ini merupakan kunci prilaku dalam pola pemrograman Ajax. Asynchronous berarti tidak serempak atau tidak terjadi pada waktu yang sama. Untuk lebih memahami ini, mari kita coba contoh sehari-hari. Ketika anda pergi ke toko kopi starbucks dan berjalan ke kasir sambil membawa pesanan anda. Kasir menandai gelas kosong dengan detail pesanan anda dan lalu menempatkannya ke dalam antrian. Antrian dalam contoh ini, secara harafiah merupakan sekumpulan gelas kosong yang merepresentasikan sekumpulan order yang menunggu untuk dipenuhi. Proses ini memisahkan(decouple) kasir dari orang-orang yang mempersiapkan minuman. Dengan cara ini, kasir dapat terus berinteraksi dengan pelanggan, sementara pesanan sedang diproses pada waktu yang berbeda –secara asynchronous. Pada akhirnya, starbucks dapat meningkatkan produksi dan memuaskan customer.