NẾu app có các file dữ liệu > 1mb à dùng sql lite.

Tốt nhất ứng dụng nên có kết nối giữa client và server , tối thiểu để lưu trữ các cài đặt người dùng. Nếu người dùng đổi máy/ gỡ app, cài lại thì các thiết lập của nguwofi dùng có thể khôi phục lại dễ dàng khi có server trả về JSON

- Phát triển ứng dụng theo mô hình top-down: nói chung về pt di động nên đi theo mô hình phát triển từ trên xuống.

- Thiết kế đồ họa

- Cài đặt giao diện trên nền tảng ( Silverlight hoặc XML android )

- => cần chú ý: tránh việc sa lầy quá nhiều vào vấn đề căn chỉnh giao diện. Giao diện xây dựng cần có tính tái sử dụng rất cao để lập trình viên không bị mất thời gian vào việc chỉnh từng dòng mã UI một. vd này có thể giải quyết = cách dùng Dynamic Binding hoặc Model View – View Model.

Với các giao diện có tính tương tự về mặt cấu trúc (giữa các thành phần bên trong) thì việc viết mã giao diện cho từng thành phần một là điều nên tránh.

Ta nên dùng cấu trúc Dynamic Binding (window phone). Việc Dynamic Binding giao diện luôn được hỗ trợ trên các nền tảng. Android có lớp ArrayAdapter hỗ trợ, window phone là lớp ObservableCollection.

Tất nhiên nhược điểm là chỉ thấy được giao diện khi ta chạy chương trình. Static binding thì ko cần chạy, viết code nó hiện ra luôn.( ví dụ trong XML android)

- Cài đặt và hiệu chỉnh các hiệu ứng đồ họa mở rộng ( UX):

ð Thế nào là hiệu ứng đồ họa mở rộng? Do màn hình di động bé à người ta có xu hướng làm 1 giao diện có kích thước > kích thước chuẩn của thiết bị. nếu người dùng muốn xem các giao diện này (bị che khuất) thì họ sẽ được trải nghiệm các hiệu ứng đồ họa mở rộng. Có nhiều loại hiệu ứng này, như animation là hay gặp nhất, có thể custom các hiệu ứng.

3. Test

Kiểm thử phải được thực hiện ngay khi chưa có mã nguồn hoàn chỉnh mà chỉ mới xong 1 chức năng con.

Lỗi được phát hiện càng sớm thì tốc độ sửa lỗi (thời gian được revision ) càng nhanh và triệt để. Chia làm các modul để làm, test ( Unit Test).

Tồn tại các công cụ hỗ trợ test automation (kiểm thử tự động) (đắt). tất nhiên ở VN thì chỉ có các công ty tiềm lực lớn cỡ như Toshiba VN, Panasonic , Viettel (có thể)s

Việc giao tiếp giữa các bên tester và developer cần sử dụng các công cụ (Web-based application)như redmine và jira.

Một số lỗi chỉ xảy ra nếu nguwofi dùng thay đổi cấu hình thiết bị hoặc cập nhật phiên bản cũ lên phiên bản mới nhất. vì nếu app được cập nhật thì các file do app đó tạo ra trong quá trình hoạt động trước sẽ không bị xóa . lỗi này khó cho tester tái hiện được nhưng lại là lỗi dễ gặp ở người dùng, khách hàng trung thành.

4. một app đã qua được tester nhưng ta vẫn phải tải về các bản trên Store để kiểm tra. Tồn tại các lỗi chỉ xuất hiện tren các máy không Unlock.

5. trong nhiều trường hợp khi ứng dụng lớn hoặc sử dụng nhiều công nghệ phức tạp cần có sự hợp tác giữa nhiều thành viên khác nhau.

Với việc làm game cần xây dựng một bộ mã nguồn chung về điều khiển nhân vật, cấu hình game, cách tính thành tích ( score, upgrade v.v..) sau đó các thành viên khác nhau có thể phát triển các màn khác nhau. Nếu két nối với server thì cần có đội làm riêng về lấy dữ liệu (JSON hoặc HTTP request hoặc XML ).

6. cần sử dụng hàng loạt framework bổ trợ khi muốn làm app lớn:

- thư viện ngôn ngữ

- framework làm web

- thư viện thông dịch (trong trường hợp app viết = nhiều ngôn ngữ khác nhau).

(*) khi làm app, khuyến khích sử dụng các toolkits ( thư viện mở rộng) cho các nền tảng chuyên biệt. Trong 3 năm tới không sử dụng các công cụ đa nền tảng để làm app. Vì các công cụ đa nền tảng (như phonegap) đang sử dụng giải pháp: viết ứng dụng bằng HTML5 và Javascript, sau đó cho WebView (Android) hoặc WebBrowser ( WindowsPhone) hiển thị trong app. Cách làm nay có 3 nhược điểm:

- HTML5 và JS chưa thực sự chạy ổn bằng so với Native. Bản thân code native chạy còn lỗi.

- Bản thân các lớp WebView và WebBrowser ( không nói đến trình duyệt di động) vẫn còn lỗi trong hiển thị HTML5, JavaScript.

- các đối tượng WebView, webBrowser sẽ phải sử dụng hàng loạt thư viện hỗ trợ bên duới ( Media, animation, cache, parser) khiến ứng dụng sẽ bị giật. một ứng dụng chạy hoàn toàn bằng native nếu có sử dụng đối tượng WebView sẽ khiến ứng dụng chạy chậm đi.

Làm game đa nền tảng lại khác vì các công cụ game engine đa nền tảng bản chất không sử dụng HTML5 , JS mà nó gọi đến các thư viện C/C++ cũng như OpenGL để tạo các hiệu ứng đồ họa ( Can thiệp sâu hơn vào hệ thống ). Bản thân gameEngine cũng chỉ hỗ trợ hiệu ứng vật lý (va chạm, nảy , rơi,) và âm thanh chứ các trải nghiệm người dùng trên từng nền tảng vẫn phải được code = Native.

Chương 2: Web / APP

Mặc dù webview nhúng vào app gây giật, tốn bộ nhớ nhưng vẫn cần sử dụng để hiển thị 1 số giao diện trên di động. Chỉ là ko nên quá làm dụng. chẳng hạn tại 1 thời điểm có ko quá 1 webview trong layout. Bản thân app có thẻ gọi được các hàm javascript trong webview ( android và ios rất thoải mái). Webview không nên che khuất quá nhiều phần trong màn hình và phải có nút đóng (trong trường hợp gây đơ app)

Q/hNgQ9