Thiết kế chi tiết hệ thống :

Số lƣơ ̣ng lớp và các interface khi ta xây dƣ̣ng ƣ́ng du ̣ng GWT theo kiến trúc MVP là khá lớn . Giả sử nhƣ với một giao diện đơn giản là phần hiển thị ảnh đại diê ̣n ta có nhƣ̃ng lớp sau :

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 57

Hình 14. Biểu đồ lớp nhóm lớp hiển thi ̣ thông tin về ảnh đa ̣i diê ̣n

Ta sẽ mô tả kỹ cho trƣờng hợp nhóm lớp này , các nhóm lớp khác là tƣơ ng tƣ̣ về mă ̣t logic tổ chƣ́c.

- AvatarView : quyết định giao diê ̣n hiển thi ̣. Ở đây giao diện sẽ bao gồm một ảnh (avatar) mô ̣t đƣờng link đến giao diê ̣n thay đổi thông tin cá nhân và mô ̣t nút để đăng xuất . View này không biết thông tin ma nó hiển thi ̣ là gì và nó cài đặt lớp Display của lớp AvatarPresenter .

- AvatarPresenter : quyết đinh thô ng tin hiển thị và các sƣ̣ kiê ̣n khi nhấn vào các đƣờng link. Ở đây nó lấy thông tin (UserProfile) của ngƣời dùng đã đăng nhâ ̣p vào hê ̣ thống và dùng mô ̣t đối tƣợng cài đă ̣t interface Display của nó để hiển thi ̣. Đồng thời nó c ũng xác định phải làm gì khi ngƣơi dùng nhấn vào các nút trên giao diện . Nó lấy đối tƣơng UserProfile thông qua lời gọi không đồng bô ̣ của lớp UserProfileServiceAsync nhƣ đã mô tả ở phần GWT RPC . - UserProfile : đóng vai trò Model trong ô hình MVP , nó là thực thể lƣu trữ

thông tin về ngƣời dùng. Khi sƣ̉ du ̣ng JDO, ta sẽ lƣu trƣ̃ trƣ̣c tiếp

- UserProfileService, UserProfileServiceAsync, UserServiceProfileImpl : ba lớp/interface cần thiết để go ̣i các phƣơng thƣ́c theo mô hình RPC.

Nhƣ vâ ̣y với mô ̣t giao diê ̣n ta có thể có 7 file java. Tuy nhiên không phải lúc nào cũng sinh ra file dịch vụ mới , ta có thể nhóm các chƣ́c năng di ̣ch vu ̣ xƣ̉ lý cùng mô ̣t loại thực thể model vào làm một dịch vụ.

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 58

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 59

Hình 16. Gói client gồm các interface di ̣ch vu ̣ (2)

Chú ý là trong gói này ta thấy có hai lớp là Eel và AppController. AppController nhƣ đã mô tả ở trong mô hình MVP là lớp quyết đi ̣nh viê ̣c xƣ̉ lý logic ở mƣ́c ƣ́ng dụng. Ở đây ta sẽ cài đặt nó để điều khiển việc thay đổi giao diện của ứng dụng tùy vào dấu hiệu của History . Lớp Eel kế thƣ̀a lớp EntryPoint là đ iểm khởi đầu của ƣ́ng dụng GWT tƣơng tự nhƣ hàm main.

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 60

Hình 17. Các lớp của gói server nhằm thực hiện công việc ở phía server Trong các lớp ở server, các lớp cài đặt các interface đã nêu trong gói client có tên Trong các lớp ở server, các lớp cài đặt các interface đã nêu trong gói client có tên đƣơ ̣c đă ̣t theo quy tắc tên di ̣ch vu ̣ + “impl”. Các lớp này là lớp bắt buộc trong mô hình gọi hàm của RPC GWT đã nêu ở phần trên . Ngoài ra trong gói còn có một số lớp phu ̣ :

- PMF : lớ p bao bo ̣c mô ̣t đối tƣơ ̣ng dùng để thao tác với cơ sở dƣ̃ liê ̣u . Do đă ̣c tính các đối tƣợng PersistenceManagerFactory mất nhiều thời gian để khởi tạo, ta ta ̣o ra mô ̣t lớp có mô ̣t đối tƣợng PersistenceManagerFactory đă ̣t là static để sẵn sàng đƣợc sƣ̉ du ̣ng khi có yêu cầu.

- ChangeAvatar : lớ p này tiếp nhâ ̣n thông tin về ảnh đai diê ̣n mới và lƣu la ̣i . Sở dĩ không làm lớp này thành dịch vụ RPC là do cấu trúc của dịch vụ blobstore yêu cầu ảnh đƣợc gƣ̉i lên thông qua mô ̣t yêu cầu HTTP hoàn chỉnh .

- Upload : tƣơng tƣ̣ với ChangeAvatar lớp này dùng để tải file lên blobstore. - Serve : trả lại nội dung của blobstore , lớ p này đƣơ ̣c sƣ̉ du ̣ng kèm với di ̣ch vu ̣

Image để ta ̣o thumbnail của các ảnh đã đƣợc tải lên.

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 61

Ta sẽ sƣ̉ du ̣ng di ̣ch vu ̣ Google Account để xác nhận ngƣời dùng của ứng dụng . Mỗi ngƣời dùng sẽ ta ̣o mô ̣t tài khoản Google và ta sẽ dùng email của tài khoản đó làm khóa cho những lớp lƣu thông tin về ngƣời dùng . Tạm thời ƣ́ng du ̣ng sẽ chỉ cần hai loa ̣i thông tin là ảnh đa ̣i diê ̣n và tên hiển thi ̣ . Ảnh đại diện sẽ sử dụng dịch vụ blobstore để lƣu trƣ̃ , ta sẽ tao lớp UserProfile gồm 3 thuô ̣c tính email , blob ID (id của khối blob lƣu dữ liệu file ảnh làm hình đại diện) và tên hiển thị.

Khi mô ̣t ngƣời dùng lần đầu tiên đăng nhâ ̣p vào ứng dụng , mô ̣t đối tƣợng UserProfile sẽ đƣợc ta ̣o và lấy nhƣ̃ng thông tin mă ̣c đi ̣nh với key là email , displayname lấy tên hiển thi ̣ tƣ̀ di ̣ ch vu ̣ Account của Google và blobID bằng “ 0”. Nhƣ̃ng thông tin này có thể thay đổi thông qua chƣ́c năng thay đổi thông tin cá nhân của hệ thống . Ngoài ra ta cũng khởi tạo một đối tƣợng FriendList khi ngƣời dùng lần đầu tiên đăng nhâ ̣ p để sƣ̉ du ̣ng sau này . Đối tƣợng này se lƣu key của UserProfile của ba ̣n của ngƣời dùng.

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 62

IV.2. Chƣ́ c năng tìm kiếm và kết ba ̣n :

Hình 19. Sơ đồ khối ta ̣o yêu cầu kết ba ̣n

Hình 20. Sơ đồ khối chấp nhâ ̣n hay tƣ̀ chối yêu cầu kết ba ̣n Ta sẽ xác đi ̣nh tƣ̀ng thành phần của mô hình MVP : Ta sẽ xác đi ̣nh tƣ̀ng thành phần của mô hình MVP :

1. Model : hai loại thƣ̣c thể cần ta ̣o là FriendRequest lƣu thông tin về các yêu cầu kết ba ̣n và FriendList lƣu thông tin về danh sách ba ̣n bè của mô ̣t ngƣời dùng.

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 63

2. View : Ta sẽ tổ chƣ́c giao diê ̣n theo mô hình nhƣ sau :

Hình 21. Mẫu FriendView

Đứng ở góc độ lập trình viên, khả năng cho phép tạo giao diện bằng mã java thực sƣ̣ là mô ̣t điểm ma ̣nh của GWT . Giờ đây lâ ̣p trình viên có thể tổ chƣ́c giao diê ̣n nhƣ các lớp thông thƣờng . Điều này phát huy thế ma ̣nh của lâ ̣p trình hƣớng đối tƣợng khi khả năng dùng la ̣i các thành phần giao diê ̣n đƣợc nâng cao .Kết hợp với viê ̣c sƣ̉ dụng JDO để thao tác với cơ sở dữ liêu, cả ứng dụng giờ chỉ thao tác bằng Java. Mô ̣t đoa ̣n mã mô phỏng cách ta ̣o giao diê ̣n bằng GWT :

package com.eel.client.view;

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 64 import com.google.gwt.event.dom.client.HasClickHandlers; import com.google.gwt.user.client.ui.Composite; import com.google.gwt.user.client.ui.FlowPanel; import com.google.gwt.user.client.ui.Image; import com.google.gwt.user.client.ui.Label; import com.google.gwt.user.client.ui.Widget;

public class FriendListRowView extends Composite implements Display { Image i;

Label name; Label remove;

public FriendListRowView(){

FlowPanel p = new FlowPanel(); initWidget(p);

p.setStyleName("row"); i = new Image();

i.setSize("50px", "50px"); p.add(i);

name = new Label(); p.add(name);

name.setStyleName("label-inline"); remove = new Label("Remove");

remove.setStyleName("label-button"); remove.addStyleDependentName("right"); p.add(remove);

}

@Override

public Widget asWidget() { return this;

}

@Override

public Image getAvatar() { return i;

}

@Override

public Label getNameLabel() { return name;

}

@Override

public HasClickHandlers getRemoveFriendButton() { return remove;

} }

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 65

Display là mô ̣t interface của lớp Presenter sẽ quy đi ̣nh View phải có nhƣ̃ng thành phần nào để thỏa mãn khả năng xử lý logic của Presenter.

3. Presenter : mỗi View cần đi kèm với mô ̣t Presenter điều khiển các tác vu ̣ logic của View. Thƣ̣c chất trong mỗi Presenter nên có mô ̣t interface quy đi ̣nh mỗi View phải có những phƣơng thức nào để Presenter có thể thực hiện các tác vụ . Mỗi Presenter do đó có thể tiếp nhâ ̣n nhiều loa ̣i View nên ta có thể phát triển ƣ́ng du ̣ng với mô ̣t giao diê ̣n đơn giản , khâu thiết kế có thể ta ̣o giao diê ̣n dƣ̣a trên các interface mô ̣t các đô ̣c lâ ̣p với.

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 66

Hình 23. Tuần tƣ̣ viê ̣c đồng ý và không đồng ý yêu cầu kết ba ̣n

IV.3. Chƣ́ c năng ta ̣o và quản lý flashcard và danh sách tƣ̀ :

Về mă ̣t tổ chƣ́c mã chức năng này cũng giồng các chức năng khác nhƣ đã mô tả ở trên nghĩa là vẫn đầy đủ ba phần Model -View-Presenter. Ở đây ta sẽ chỉ liệt kê các lớp sẽ đƣợc ta ̣o. Ta chia chƣ́c năng này làm 4 chƣ́c năng con :

1. Tạo: gồm tạo flashcard và ta ̣o danh sách tƣ̀

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 67

Với mỗi công đoa ̣n ta sẽ ta ̣o mô ̣t bô ̣ 3 lớp View-Presenter-Display để quản lý viê ̣c thƣ̣c hiê ̣n tiến trình.

2. Quản lý : gồm quản lý danh sách tƣ̀ của mình và nhƣ̃ng danh sách của ngƣời khác mình lƣu lại để học

Hình 25. Sơ đồ chƣ́c năng quản lý

3. Tìm kiếm : tìm kiếm flashcard và thêm nó vào danh sách của mình , hay tìm kiếm danh sách tƣ̀ và thêm nó vào danh sách các danh sách tƣ̀ yêu thích .

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 68

4. Kiểm tra: chọn một danh sách từ và kiểm tra trí nhớ.

Hình 27. Sơ đồ chƣ́c năng kiểm tra trí nhớ

IV.4. Chƣ́ c năng tải lên và chia sẻ tài nguyên:

Mục tiêu của chức năng này la cho phép ngƣời dùng tải các tập tin lên (ảnh, pdf, doc …) và chia se chúng với những ngƣời bạn . Chƣ́c năng này gồm ba chƣ́c năng con:

1. Tải tập tin lên: ta sẽ dùng di ̣ch vu ̣ blobstore để lƣu nô ̣i dung các tâ ̣p tin đƣợc tải lên.

2. Xóa các tập tin đã đƣợc tải lên

3. Tạo thông điệp thông báo cho bạn bè về tài liệu của mình .

IV.5. Tổng kết tất cả các lớp :

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 69

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 70

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 72

Hình 30. Tất cả các lớp (3)

V. Mô hình cơ sở dữ liệu:

Cơ sở dƣ̃ liê ̣u sẽ sƣ̉ du ̣ng ở đây là Datastore của GEA sƣ̉ du ̣ng JDO, do đó ta chỉ cần tổ chƣ́c các lớp model của MVP và quyết đi ̣nh xem thông tin nào cần lƣu la ̣i . Hình sau chỉ ra các lớp với th ông tin sẽ đƣợc lƣu vào cơ sở dƣ̃ liê ̣u . Các lớp này đều nằm trong gói shared và đều cài đă ̣t interface Serializable để có thể sƣ̉ du ̣ng trƣ̣c tiếp khi truyền qua ma ̣ng.

Hình 31. Các lớp mô phỏng các dữ liê ̣u sẽ đƣợc lƣu la ̣i

Có một vấn đề ở đây là sự thiếu sót của các tham chiếu giữa các đối tƣợng , ví dụ nhƣ trƣờng owner của FriendList phải tham chiếu đến trƣờng key của UserProfile . JDO có cung cấp các khai báo cho viê ̣c đó tuy nhiên ở đây ta không sử dụng vì :

- GWT yêu cầu nhƣ̃ng thành phần ở phía client phải có mã java gốc (không phải là mã bytecode ) mới có thể di ̣ch đƣợc . Chính lý do này khiến ta không thể sƣ̉ du ̣ng đƣợc mô ̣t vài lớp của datastore mà tiêu biểu là lớp Key. Phần này đã đƣợc đề câ ̣p trong tài liêu tham khảo số 9 “Google App Engine for Java” ở phần 3.

- Khi không sƣ̉ du ̣ng đƣợc lớp Key thì viê ̣c đi ̣nh nghĩa các quan hê ̣ không có nhiều tác du ̣ng. Ta có thể lấy các đối tƣợng có quan hê ̣ với mô ̣t đối tƣợng qua Key của nó , nếu không dùng Key ta không thể lấy đƣợc các đối tƣợng quan

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 73

hê ̣. Do đó để đơn giản hóa trong ƣ́ng du ̣ng không sƣ̉ du ̣ng các khai báo quan hê ̣. Các quan hệ này vẫn đƣợc ngầm hiểu.

VI. Giao diện ƣ́ng du ̣ng :

1. Trang home củ a mỗi ngƣời dùng:

Hình 32. Trang home của ngƣời dùng

Trên trang này ta có thể xem nhƣ̃ng thông điê ̣p mà nhƣ̃ng ngƣời trong danh sách bạn bè đăng lên. Nhƣ̃ng thông tin đƣợc chia sẻ sẽ xuất hiê ̣n ở đây. Ta có thể đƣa ra ý kiến của mình về nhƣ̃ng thông tin đó.

2.Trang danh thông tin bạn bè

Hình 33. Trang ba ̣n bè (danh sách và yêu cầu kết ba ̣n) Trên trang này ta có thể xem nhƣ̃ng thông tin sau:

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 74

- Danh sách nhƣ̃ng ngƣời dùng đã là ba ̣n cùng khả năng xóa bạn khỏi danh sách (mục Friend list)

- Danh sách yêu cầu kết ba ̣n: khả năng đồng ý/tƣ̀ chối (mục Friend Request) - Mời ba ̣n qua email (mục invite friend to join eEL)

- TÌm kiếm bạn bằng từ khóa (mục looking foor friend). 3.Chƣ́ c năng tải tài liê ̣u lên và chia sẻ:

Hình 34. Chƣ́c năng tải tài liê ̣u lên.

Trên trang này ta có thể tải tài liê ̣u lên và chia sẻ chúng bằng cách ấn vào “Share” hay chỉ đơn giản là ta muốn lƣu trƣ̃ la ̣i để sau này “Download” về . Giới ha ̣n dung lƣơ ̣ng tâp tin ở đây là giới ha ̣n của blob là 50MB.

4. Chƣ́ c năng ta ̣o và quản lý flashcard và danh sách tƣ̀:

Hình 35. Trang tìm kiếm flashcard và danh sách tƣ̀ Trang này cho phép ngƣời dùng tìm kiếm flashcard và danh sách tƣ̀ :

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 75

- Đối với flashcard khi tìm đƣợc một đối tƣợng ƣng ý ta có thể lƣu nó vào trong mô ̣t danh sách tƣ̀ của ngƣời dùng (Add to)

- Đối với dang sách từ ta có thể lƣu lại để sử dụng trong việc kiểm tra

Hình 36. Trang đi ̣nh nghĩa flashcard Trang này cho phép ta đi ̣nh nghĩa các flashcard : Trang này cho phép ta đi ̣nh nghĩa các flashcard :

- Mô ̣t thẻ flashcard bao gồm: tƣ̀, nghĩa, tƣ̀ đồng nghĩa, tƣ̀ trái nghĩa.

- Mỗi tƣ̀ có thể có nhiều nghĩa và do đó có thể ta ̣o nhiều flashcard cho cùng mô ̣t tƣ̀.

Hình 37. Trang kiểm tra trí nhớ.

Trang này cho phép ta cho ̣n mô ̣t danh sách tƣ̀ không rỗng (có flashcard) và nó sẽ lấy ngẫu nhiên mô ̣t trong các thành phần của flashcard để hiển thi ̣. Ngƣời dùng có nhiê ̣m vu ̣ nhâ ̣p tƣ̀ vào ô để kiểm tra khả năng ghi nhớ của mình.

VII. Tổng kết cá c di ̣ch vu ̣ đã sƣ̉ du ̣ng:

Mục này sẽ tổng kết lại những dịch vụ GEA đã đƣợc sử dụng trong ứng dụng và lý giải vì sao lại sử dụng chúng.

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 76

VII.1. Dịch vụ Account : dùng để quản lý việc đăng nhập vào ứng dụng . Khi

xây dƣ̣ng cơ chế xác thƣ̣ c cho ƣ́ng du ̣ng ta có thể tƣ̣ xây dƣ̣ng cơ chế này nhƣ vẫn xây dƣ̣ng trên các hê ̣ thống cổ điển . Tuy nhiên khi cân nhắc đến vấn đề liê ̣u ta có nhất thiết phải xây dƣ̣ng mới không khi mà ta khó có thể đƣa ƣ́ng du ̣ng của ta ra và chạy trên một nền tảng khác , ta thấy sẽ là phí công sƣ́c khi xây dƣ̣ng mớ i mô ̣t hê ̣ thống xác nhâ ̣n ngƣời dùng.

package com.eel.server; import javax.jdo.PersistenceManager; import com.eel.client.LoginService; import com.eel.shared.FriendList; import com.eel.shared.LoginInfo; import com.eel.shared.UserProfile; import com.google.appengine.api.users.User; import com.google.appengine.api.users.UserService; import com.google.appengine.api.users.UserServiceFactory; import com.google.gwt.user.server.rpc.RemoteServiceServlet; @SuppressWarnings("serial")

public class LoginServiceImpl extends RemoteServiceServlet implements LoginService {

public LoginInfo login(String requestUri) {

PersistenceManager pm = PMF.get().getPersistenceManager(); UserService userService =

UserServiceFactory.getUserService();

User user = userService.getCurrentUser(); LoginInfo loginInfo = new LoginInfo(); if (user != null) { loginInfo.setLoggedIn(true); loginInfo.setEmailAddress(user.getEmail()); try{ UserProfile u = pm.getObjectById(UserProfile.class, user.getEmail()); loginInfo.setNickname(u.getDisplayname()); pm.close(); }catch(Exception e){ UserProfile u = new UserProfile(user.getEmail(),user.getNickname());

FriendList fl = new FriendList(user.getEmail()); pm.makePersistent(u);

pm.makePersistent(fl);

loginInfo.setNickname(user.getNickname()); pm.close();

Sinh viên thực hiê ̣n : Đào Phan Quang K50 Lớp CNPM 77 loginInfo.setLogoutUrl(userService.createLogoutURL(requestUri)); } else { loginInfo.setLoggedIn(false); loginInfo.setLoginUrl(userService.createLoginURL(requestUri)); } return loginInfo; } }

VII.2. Dịch vụ Image : dùng trong việc giảm giữ liệu chuyển về client khi client yêu cầu xem ảnh đa ̣i diê ̣n và thumbn ail các ảnh đƣợc ngƣời dùng tải lên .Do

Giá các tài nguyên căn bản

Môi trƣờng servlet