Weekly Report 30/5/2016 - Muhamad Hardi Ramli

Design Review

Halaman Login dan Register

Pada tampilan halaman login, tampilan dan juktaposisi form dan tombol-tombolnya sudah bagus mungkin sedikit masukkan untuk isian awal username untuk diberikan efek warna yang lebih gelap untuk membedakan apakah sudah terisi atau belum.

Pemilihan warna yang minimalis tidak terlalu mengganggu mata sehingga untuk penggunaan di malam hari tidak membuat layar menjadi terlalu silau.



Pada halaman register, sama seperti halaman login form dan tombolnya sudah baik namun untuk huruf isian warna awalnya sama sehingga sudah terisi atau belum warna hurufnya sama.

Namun begitu, tombol back pada smartphone pada halaman ini tidak bertindak untuk kembali ke halaman login melainkan keluar aplikasi. Sehingga untuk beberapa user ada yang tidak sengaja keluar dari aplikasi setelah menyelesaikan registrasi. Untuk kembali ke login, selain menggunakan link dibawah tombol register, tombol back pada smartphone sebaiknya juga bertindak juga dengan serupa pada halaman register.

 

Code Review

Code Review adalah kegiatan peer review pada bagian kode sumber pada program. Tergantung dari kebijakan yang digunakan code review bisa digunakan dengan cara

Over the Shoulder
Dalam hal ini developer lain (reviewer) melihat kode secara langsung dan memberikan masukan disamping penulis kode tersebut.

Pair Programming
Dua penulis kode melakukan penulisan kode sumber secara berpasangan (Extreme Programming).

Tool Assisted
Menggunakan program alat bantu review.

Email Pass
Tiap kode yang sudah siap direview sudah disubmit, sistem mengirimkan email secara otomatis kepada reviewer.

Pada link ini, dijelaskan bahwa code review cara informal maupun formal keduanya sama efektifnya. Karena pada code review, yang paling penting adalah bug pada program yang ketahuan dan dapat diperbaiki.

Standard Code Convention

Beberapa Code Convention yang saya penuhi pada penulisan kode sumber adalah

Android

- Pada penulisan exception, throw exception tidak dibiarkan kosong, minimal memberikan feedback pada log sehingga dapat ditelusuri pada error.

- Pada imports, untuk menuliskan imports yang ingin dipakai, ditulis secara full sehingga kelas yang dipakai dapat diketahui. Selain itu memenuhi urutan import :
1. Android
2. import dari 3rd party
3. kode java lain dari program yang ditulis

- Menjaga method secara fokus, satu method untuk satu fungsi

- Membatasi scope variabel jika dibutuhkan.

- Menjaga penulisan nama, indentasi, tanda kurung, anotasi dan menjaga konsistensi kode.

Berikut adalah sumber bacaan mengenai Standard Code Convention pada Android (link).

PHP (Laravel)

- Penulisan kelas/model dengan awalan huruf besar dan huruf kecil untuk penulisan variabel.

- menggunakan UTF-8

- sama seperti Android, mengatur scope variabel jika dibutuhkan.

- mengatur penulisan usage secara full, sehingga tahu kelas apa yang digunakan untuk kode sumber tersebut.

Untuk PHP Standard Convention saya menggunakan PSR.

Weekly Report 30/5/2016 - Reyhan Razaby

Untuk minggu ini saya hanya finalisasi fitur dan tampilan untuk aplikasi ini.
Pertama, untuk halaman "Tambah Amalan" sudah selesai semua, kecuali bagian "Pilih Template" belum dilaksanakan. Beberapa case sudah dihandle, misalnya pada pemasukkan tanggal, jika dimasukkan tanggal yang tidak ada di kalender maka akan muncul peringatan seperti pada gambar 1. Case selanjutnya jika memasukkan nama kategori yang sudah ada, maka akan muncul peringatan seperti gambar 2. Dan peringatan juga akan muncul jika nama mengandung karakter / \ < > * ? dan |

Gambar 1: Validasi tanggal

Gambar 2: Validasi ketersediaan nama

Gambar 3: Validasi karakter

Untuk halaman "Detail Amalan" juga sudah terimplementasi semua seperti gambar di bawah ini. Halaman ini muncul jika salah satu amalan pada Halaman utama disentuh. Masing2 atribut jika disentuh akan muncul dialog box untuk mengedit atribut amalan tersebut (seperti pada gambar 5).

Gambar 4: Edit nama

Gambar 5: Mengedit jenis input amalan

Selain itu pada halaman utama, tampilan header sudah saya modifikasi seperti gif di bawah ini. Hal tersebut saya lakukan secara manual, karena pada AppBar tersebut diberikan variabel angka yang dinamis ketika AppBar tersebut membesar / mengecil (ketika discroll) sehingga saya bisa menggunakan variabek tersebut untuk memunculkan / menyembunyikan tanggal pada header dan pada toolbar dengan transisi fade-in & fade-out (dengan method setAlpha dan parameter berupa variabel ukuran AppBar)

Semua progress di atas sudah include pada GIT branch Master saat ini.

Dan semua progres di atas memakan waktu (bersih) sekitar 20 jam

Weekly Report 30/5/2016 - Muhamad Iqbal

Dalam minggu ini saya mencoba untuk menyelesaikan mandatory-mandatory yang masih banyak belum saya lakukan tetapi sebenarnya tidak terlalu banyak hal yang saya lakukan karena terkendala banyaknya tugas dan persiapan UAS.

Verification & Validation, Process & Product Management

Verification
Mengevaluasi suatu produk telah sesuai dengan regulasi, persyaratan, spesifikasi atau kondisi yang dinginkan.

Validation
Menjamin bahwa produk, layanan, atau sistem telah memenuhi kebutuhan dan harapan pelanggan/owner.

Hal tersebut kita lakukan setiap sprint review bersama product owner dari badr yaitu pak Yuwono. Hal ini dilakukan setiap sprint selesai.

Design Review: Provide Constructive Feedbacks

Saya akan mencoba me review halaman main page aplikasi

Dihalaman main page diatas ada beberapa hal yang saya kurang nyaman yaitu:

- Jarak antara kolom tanggal yang terletak di paling atas dengan kolom kategori amalan terlalu jauh

- Untuk kolom isian antara amalan sholat rawatib dan tester tidak sejajar

Standard Code Convention

Standard code convention adalah standar penulisan kode pemrograman agar mudah dimengerti oleh banyak orang. Kami mengikuti best practice dari oracle untuk java dan PHP Standard Recommendation (PSR) di php-fig untuk laravel.
contoh :

- Penulisan class diawali dengan huruf besar setiap kata
- Penulisan variabel diawali huruf kecil lalu kata selanjutnya dengan huruf besar
- Penulisan konstanta dengan huruf kapital di semua huruf dengan menggunakan underscore saat perpindahan kata
- Setiap file PHP harus menggunakan tag <?php untuk tag yang panjang dan </= untug tag yang pendek
- Kode PHP hanya menggunakan UTF-8 tanpa BOM

Build Script & Software Integration

Software Integration adalah proses menghubungkan sistem komputasi dan aplikasi software secara fungsional atau fisik. Untuk android terdapat gradle yaitu script yang digunakan untuk mengintegrasi software.

Contoh script pada aplikasi

Role Management

Role management adalah mengelola pengguna siapa saja yang dapat mengakses dan apa saja yang dapat diakses di aplikasi.

Di aplikasi Evaluasi Ibadah, orang yang dapat menggunakan aplikasi adalah user terdaftar.Cara mendapatkannya adalah dengan registrasi di aplikasi atau jika mempunyai akun google bisa registrasi menggunakan akun tersebut.

Secure Deployment and Administration

Secure deployment adalah membuat deployment system kita khususnya di server supaya aman. Contohnya adalah:

- Sistem autentikasi yang membuat aplikasi hanya bisa diakses oleh pengguna yang telah log in
- Pengguna hanya dapat menyimpan dan menghapus amalan yang dia buat di aplikasi.

Software Profiling

Software profiling adalah menganalisis program untuk menghasilkam informasi yang digunakan untuk menentukan kemampuan dari aplikasi tersebut.

Ada 4 poin yang digunakan untuk aplikasi android yaitu Memory, Rendering, Battery dan Compute Analysis

Salah satu analysis yang saya lakukan di device yaitu GPU rendering

Dibawah aplikasi terlihat bar yang menunjukan performa rendering. Disana terdapat garis hijau yang menunjukan pembatas apabila bar melebihi garis maka hasil yang ditampilkan mengalami delay.

Living Documentation

Living documentation adalah sebuah proses yang menampilkan segala perubahan yang dilakukan oleh developer. Hal ini dilakukan secara berkala dari awal developing. Hal ini dilakukan supaya developer lain mengetahui apa saja perubahan-perubahan yang terjadi dan juga mengetahui siapa yang mengerjakannya.

Weekly Report 30/5/2016 - M Farhan Dzikri

Design Review: Main Screen

Hal ini sudah menjadi concern saya setiap kali melihat MainScreen, button antara options, tambah amalan/kategori, statistik, kalender, dan next day terlalu dekat.

Efek dari hal ini:

• User seringkali gagal mengklik tombol yang diinginkan, (ex: user klik statisitik, tapi aplikasi merespon dengan menampilkan kalender)
• User experience yang buruk
• 2 klik untuk menuju >=2 hari kedepan/kebelakang
• Sulit digunakan oleh left-handed user. Button terlalu merapat ke kanan.

Karena itu saya mencoba mencari design UX aplikasi lain yang juga mengimplemplementasikan fitur "daily list". Hasilnya saya menemukan beberapa aplikasi berikut:

Dua screenshoot diatas mengimplementasikan hal yang sama, "daily list", namun dengan user experience yang jauh lebih baik. Alasan:

• Ada batas antara button di toolbar dengan bar di bawahnya.
• Memudahkan user untuk mengklik tombol yang dituju
• Mengimplemntasikan fragment
• 1-klik untuk menuju 2=< hari
• 1-klik + 1 slide menuju 2> hari
• 1 slide menuju before/next day
• Right-handed/left handed user merasakan user experience yg sama, karena tidak ada button yang berkumpul di satu sisi

Oleh karena itu saya mengusulkan ide ini untuk diimplementasikan di saat periode development kedepannya.

Refactoring

Selain itu, saya mempelajari refactoring. Berdasarkan http://refactoring.com/, refactoring adalah:

 "…  sebuah disiplin teknik untuk men-restruktur kode yang sudah ada, mengubah struktur internalnya tanpa mengubah behaviour externalnya."

Atau dalam definisi lainnya, dalam bentuk noun, refactoring adalah:

"sebuah perubahan yang dibuat dalam struktur internal software agar menjadi lebih mudah dimengerti dan lebih mudah diubah tanpa mengubah behaviornya."

Website refactoring.com juga menyediakan catalog, (didapatkan dari buku Refactoring), yaitu hal-hal mana saja yang perlu refactor.

Beberapa contoh yang saya pelajari dari catalog diatas:

• Extract Method: Ubah sebuah perintah menjadi masing2 method yang namanya menjelaskan maksud method itu sendiri.

Hal ini sudah saya aplikasikan dalam kode yang saya buat. Nama method menjelaskan maksud dari method itu sendiri.

• Extract Variable: meletakkan hasil dari expression di dalam sebuah temporary variable dengan nama yang menjelaskan tujuannya.
  

Hal ini sudah saya aplikasikan dalam kode yang saya buat.

Sebelum:

       Sesudah:

 

• Replace Array with Object: Array hanya memiliki baris yang disimpan dengan nomer. Hal ini akan menimbulkan kebingungan dalam mengartikan maksud dari nomer2 tersebut. Lebih baik ganti array dengan objek yang memiliki nama yang jelas untuk masing2 elemen.

Refactoring bukan saja hanya mengubah implementasi kode yang digunakan, namun juga mengubah kode implementasi software design nya.

Contoh:

• Remove Middle Man: menghapus kelas ditengahnya, sehingga pada contoh dibawah, Client dapat langsung memanggil Departement tanpa harus melawati Person

Software Design: UML

Saya juga mempelajari software class diagram yang kami buat sebelumnya. Berdasarkan dari sumber https://www.visual-paradigm.com/VPGallery/diagrams/Class.html, definisi class

diagram adalah overview dari sistem yang menggambarkan objek dan kelas dalam suatu sistem program  dan menggambarkan relasi diataranya.

Berikut adalah screenshoot dari class diagram aplikasi kami.

EvaluasiIbadah:

-isLogged: menunjukkan apakah user sudah log in atau belum

AmalanManager:

-getAmalanById: mengambil data suatu amalan

-getAmalansToday: mengambil data amalan-amalan yang harus dikerjakan pada suatu hari

-createAmalan: membuat amalan baru

-updateAmalan: mengupdate data suatu amalan

-deleteAmalan: menghapus sebuah amalan

CalendarManager:

-calToStr: data dari calendar yang diubah menjadi string

-strToCal: string yang diubah menjadi data calendar

-getFormatForHeader:

-getIntervalDate: jarak interval dari hari ini ke hari yang dituju

-getDayName: hari dari tanggal yang dituju

Category:

-id: id kategory

-name: nama kategori

Amalan:

-Id: id amalan

-name: nama suatu amalan

-inputType: jenis input amalan, (checklist/isian)

-repeat: amalan diulang per minggu/hari/bulan

-target: jumlah target yang ingin dikerjakan

-targetPer: target per minggu/hari/bulan

-unit:

-deskripsi: penjelasan amalan

AmalanWeekly:

-daylist: hari yang direpeat untuk amalan perminggu

Amalan Monthly:

-datelist: tanggal amalan yang diulang perbulan

Reminder:

-Id: id reminder

-hour: jam

-minute: detik

-dayBefore: hari dari interval reminder dibuat

GitLab Continous Intergration

Saya juga mempelajari GitLab Documentation, (sumber: http://docs.gitlab.com/ce/ci/quick_start/README.html), dari situs tersebut saya mempelajari:

GitLab menyediakan servis continous integration. Jika kita menambahkan file .gitlab-ci.yml kedalam root directory dari repositori kita, maka setiap request merge dan push akan mentrigger sebuah build.

File .gitlab-ci.yml akan mentrigger GitLab untuk melakukan sesuatu. Defaultnya akan menjalankan 3 stage, yaitu build, test dan deploy.'

Jika semuanya berjalan dengan baik, maka setiap kali kita melakukan push atau merge, kita akan mendapatkan tanda checklist di GitLab. Hal ini mempermudah untuk melihat apakah merge atau push akan menimbulkan test yang gagal sebelum kita melihat kodenya.

Hal ini ternyata sudah diimplementasikan oleh luthfi. Berikut adalah tanda checklist yang menunjukkan commit berhasil melewati test dari file .gitlab-ci.yml

Software Profiling

This week I'm also learning more about software profiling. According to definition and explanation from https://en.wikibooks.org/wiki/Introduction_to_Software_Engineering/Testing/Profiling, it has come into my knowledge that:

As a noun, software profiling is a form of dynamic tool that programmer uses to investigate a program's behaviour using information gathered as the tool executes.

As a verb, profiling point to the investigation itself.

The purpose of this activity is to determine which is the program section's need to be optimized (increase the speed/decrease the memory used by the program).

Google provides software profiling tools for Android Developers. Some of them are  :

Memory analysis tools: Visualize the memory behaviour and performance

Rendering analysis tools: Visualize the rendering behaviour and performance

Battery analysis tools: Visualize the battery behaviour and performance

Compute analysis tools: Visualize the CPU behaviour and performance

Jadi Performance analysis tools pada android terdapat 4 bagian, yaitu Memory Analysis, Rendering, Battery, serta Compute Analysis. Kemudian saya mencoba mempraktekkan Profiling GPU Rendering Walktrough,

Garis hijau datar menunjukkan target 16miliseconds, Bar menunjukan proses rendering. Jika proses rendering melewati garis hijau maka gambar yang ditampilkan terlambat datang

Tool: Corel draw

Other than those, I'm also working on the Splash Screen design and implementation.

Splash Screen (Tutorial) functional feature has been done last week, but I think the pictures shown isn't good enough because I only used 72 pixel by pixel PNG image. This time, I tried to use 150 pixen by pixel PNG, which I hope it wont look blurred as in the previous pictures. I work on this pictures using Corel Draw X7 and here are how they look:

Bug Tracking

I'm also working on Bug Tracking.

First I'm working on Add Amalan feature:

Here are the test case I'm listing:

1. User cant create amalan without a name
2. User cant create amalan without choosing category
3. User has to choose input type to create amalan
4. An amalan with Isian input type, the Satuan should be named.
5. A new amalan must at least repeated daily/weekly/yearly (no option for no repeat)
6. User has to set target (target cant be zero)
7. User can create amalan without description
8. User can create amalan without reminder
9. A new amalan should be able to be put in a new category
10. A new category cant be created without a name

From the list above, everything is OK, except no 6. Our app still allowing user to set zero target. This should be prohibited, because zero means no target.

Second I'm working on Edit feature:

1. User should be able to delete an amalan
2. User should be able to delete category with empty amalan
3. User should be able to delete category contains amalans
4. User should be able to rename amalan/category
5. User cant renaming amalan/category with empty name

After trying the list above, turns out the apps runs the test cases just fine.

Amalan Details feature:

1. User can create description of amalan
2. User can left descripion empty
3. User can move amalan to another category
4. User can change the input type of amalan
5. User can change the repeat that have been set
6. User can change target     

After trying the list above, turns out the apps runs the test cases just fine.

Reminder feature:

1. User can set a reminder when creating new amalan.
2. User can set a reminder when looking at the details of amalan
3. User can edit reminder when looking at the details of amalan.
4. Reminder works exactly at the scheduled time
5. User can create more than one reminder for one amalan
6. User can't create 2 or more reminder at the same time

Our app still have some bugs on the reminder feature. 1 and 3 can be done altogether, except no 2. No 4 works, but sometimes it doesn’t. No 6 isn't prohibited yet.

Here are the screenshoot of the bugs:

Also, I've reported the bugs to the Gitlab issues page here

https://gitlab.com/luthfiswees/EvaluasiIbadah/issues?assignee_id=&author_id=&milestone_title=&scope=all&sort=id_desc&state=all

Role Management

This time, I'm trying to learn about role management. The explanation here (https://msdn.microsoft.com/en-us/library/5k850zwb.aspx), I got that:

Role management is managing an authorization of users, which we specify what resources that users can access. Role management includes grouping a set of user into a role such as Manager, Admin, Employee, Office Boy, etc.

For example, a website that includes a set of pages that we only want to show to Employee. In other case, we want to show some other pages only to Manager. By using Role Management, we can estabish these type of rules for each individual users.

One users can belong to more than one role. For example, if our site is a discussion forum, some users might be in the roles of both member and moderator, while other are only a regular member. We can define the access right for each role, and users which in both roles would have access for both set of rights.

//Our app explanation.

Living Documentation

While looking at the Internet, I got no specific explanation of living documentation in terms of software development. I went to wikipedia, and here's what I got:

(source: https://en.wikipedia.org/wiki/Living_document#In_technology)

Living documentation is a document that continually edited and updated. For example an article in wikipedia. Everyone can read, edit and update the article, which makes it a living documentation. In contrast, a dead documentation is one that simply written and cant be updated or edited.

The explanation above is too general, which cant be applied to our project. So I asked around friend, and here's what I managed to understand.

A living documentation is a document that made when we make a change in our base code so the team would aware what and why it is changed. There's no such living documentation format convention, so every team could make one that suits with their project.

(It's kinda late, but) If I make one, the format would looks like this:

Date:

Name: _________________________________

Before: ________________________________

After: __________________________________

Changed made in: _____________________

Purpose of change: ____________________

Result of change: ______________________

Example:

14 May 2016

Farhan Dzikri

Change that made,

Before:

After:

Change made in: Gradle (module)

Purpose: To support Android Annotations.

Code Review

I managed to attain some knowledge of code review from this site: https://smartbear.com/learn/code-review/what-is-code-review/

So, basically code review is an continous act for programmer with one fellow programmer to check each other code's mistake. It has been shown that these act is able to accelerate and streamline the process of software development.

According to the article, there are some code review approach:

The Email Thread

this technique is done by simply sending out a piece of code that ready to be reviewed to fellow programmer. This approach is meant to be more adaptive and flexible than the traditional way, 5 programmers sitting in a room for code inspection meeting.

Pair Programming

This method is used by two pair of programmer working side-by-side on a same code, so each other could review the code and inspecting mistakes. In a good way, the pair better be a senior programmer and a junior programmer, so the junior could learn and get a feedback from the senior.

Over the Shoulder

this technique is simply asking your qualified colleague that sitting around (or go to them) to review your code once its ready. the code writer explains why you write the code and what is the purpose and result you expect.

Tool Assisted
this one is the easiest approach. as the title explained itself, this method is reviewing a code using a software. some of them are browser-based or seamlessly integrate within a variety of standard IDE and SCM development frameworks. this technique is more efficient and effective as less effort and more accurate compared to limitations of the other technique mentioned above.

Weekly Report 21/5/2016 - Muhamad Hardi Ramli

Minggu ini, beberapa hal yang saya lakukan adalah mengupdate database supaya sesuai dan amalannya bisa diambil sesuai dengan user tersebut. Selain itu bagian laravelnya juga sudah di update supaya dapat dijalankan. Dengan demikian, tiap user hanya bisa mengakses amalannya masing-masing,


kolom pada tabel amalan

Selain dari sisi database, saya juga menambahkan beberapa tambahan kode, refactoring beberapa bagian dan konfigurasi pada aplikasi supaya bisa mengakses database tersebut, hal ini bisa dilihat di git.

Kelas untuk menerima jsonArray


Hingga sekarang, beberapa pertimbangan penggunaan laravel sudah lebih baik karena untuk melakukan penambahan controller dan route dapat lebih cepat dilakukan. Selain itu, proyek ini juga tidak terlalu melibatkan bagian view dari laravel, dengan demikian hal untuk melakukan ujicoba dengan Postman dapat dilakukan dengan lebih cepat.

Weekly Report 23/5/2016 - Reyhan Razaby

Untuk masalah role management, aplikasi kami hanya memiliki 1 role, yaitu user. Awalnya saya berfikiran untuk membuat 2 role, satu lagi adalah admin yang memiliki akses untuk membuat amalan template yang dapat dipakai oleh user. Namun ternyata membuat amalan template bisa dilakukan dengan memperbarui java nya atau melalui phpmyadmin jika pengambilan amalan template akan diambil dari remote storage.

User di sini hanya bisa mengakses amalannya sendiri (amalan yang memiliki identitas id user tersebut) dan harus dalam keadaan login.

Gambar di atas adalah Profile GPU Rendering, yaitu grafik yang merepresentasikan time per frame dalan milisekon. Satu bar pada grafik tersebut menunjukkan 1 frame. Garis hijau menunjukkan target (batas maksimal) waktu untuk merender 1 frame, yaitu 16ms. (sumber: https://developer.android.com/studio/profile/dev-options-rendering.html)

Di aplikasi kami ini kami menggunakan 2 DBMS, yaitu MySQL untuk menyimpan data di server dan SQLite untuk menyimpan data di penyimpanan lokal (pada device).

Skema relational keduanya hampir mirip. Bedanya, untuk database lokal tidak menyimpan table user, karena id user yang disimpan pada aplikasi jelas hanya user yang login saja.

Baik pada MySQL maupun SQLite, semua foreign key memiliki constraint "ON DELETE CASCADE", yaitu jika primary key dihapus, tuple yang terhubung dengan primary key tersebut juga ikut terhapus.

Weekly Report 21/5/2016 - M Farhan Dzikri

Minggu ini saya membantu Luthfi membuat icon di notifikasi. Luthfi sedang membuat fitur notifikasi berjalan, saya membantu dengan membuat icon yang akan tampil pada status bar dan icon di notification settings. Hasilnya seperti dibawah ini.

Selain itu saya juga membuat fitur tutorial di aplikasi kami. Yang saya buat pertama adalah gambar yang ingin ditampilkan. Kemudian selanjutnya adalah membuat kodingannya agar terimplementasi dengan baik.
Yang sulit dalam membuat fitur ini adalah mencocokan memori agar tidak terpakai terlalu besar dan membuat gambar dengan kualitas yg bagus.

Berikut adalah hasilnya.

Hasil imlementasi di kodingan:

Saya juga sudah push kode ini ke git.

Selain itu, dalam mengimplementasikan fungsi ini, saya juga mempelajari android annotations.

Yaitu fungsi yang membuat kode jadi lebih singkat. (androidannotations.org)

Untuk menggunakan fungsi ini, pertama2 kita harus memasukan kode di gradle agar dapat membaca code diet tersebut.

Sedikit dari kodingan yang saya buat menggunakan implementasi kodingan ini.

Dalam menggunakan Android Annotations (AA), jika merefer pada kode lain, kita harus menambahkan "_",

dalam kodingan yang pakai AA, serta di manifestnya.

Kode di Gradle

Kode di Manifest

Saya juga mempelajari, jika suatu activity akan digunakan sebagai halaman terdepan maka harus diberikan <intent-filter> di dalam kode manifestnya. Contohnya seperti gambar diatas.