Mã vùng điện thoại lâm đồnlưu ứng dụng vào thẻ nhớ trên android
| ỦY BAN NHÂN DÂN TỈNH THỪA THIÊN HUẾ ------- | CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT phái mạnh Độc lập - thoải mái - hạnh phúc --------------- |
| Số: 3071/QĐ-UBND | Thừa Thiên Huế, ngày 26 mon 11 năm 2021 |
QUYẾT ĐỊNH
BANHÀNH HƯỚNG DẪN KỸ THUẬT TÍCH HỢP ỨNG DỤNG VÀO ỨNG DỤNG DỊCH VỤ ĐÔ THỊ THÔNGMINH HUE-S
ỦY BAN NHÂN DÂN TỈNH THỪATHIÊN HUẾ
Căn cứ dụng cụ Tổ chức cơ quan ban ngành địa phươngngày 19 mon 6 năm 2015; căn cứ Luật sửa đổi, bổ sung một sốđiều của biện pháp Tổ chức chính phủ và công cụ Tổ chức cơ quan ban ngành địa phươngngày 22 mon 11 năm 2019;
Căn cứ Luật giao dịch điện tử ngày 29tháng 11 năm 2005;
Căn cứ Luật technology thông tin ngày29 tháng 6 năm 2006;
Căn cứ Luật bình an thông tin mạngngày 19 mon 11 năm 2015;
Căn cứ Nghị định số 64/2007/NĐ-CP ngày10 tháng 4 năm 2007 của chính phủ nước nhà ứng dụng công nghệ thôngtin trong hoạt động vui chơi của cơ quan nhà nước;
Căn cứ Nghị định số 47/2020/NĐ-CP ngày09 tháng 4 năm 2020 của cơ quan chính phủ về quản ngại lý, liên kết và share dữliệu số của cơ quanNhà nước;
Căn cứ quyết nghị số 12-NQ/TU ngày 12tháng 11 năm 2021 của hội nghị lần vật dụng năm Ban chấp hành Đảng bộ tỉnh khóa XVIvề biến đổi số thức giấc ThừaThiên Huế mang đến năm2025, định đào bới năm 2030;
Căn cứ đưa ra quyết định số 62/2021/QĐ-UBND ngày04 tháng 10 năm 2021 của ubnd tỉnh vượt Thiên Huế về việc phát hành Quy định Quảnlý, quản lý và tích hợp áp dụng Hue-S;
Theo ý kiến đề nghị của người có quyền lực cao Sở Thông tinvà media tỉnh tại Tờ trình số: 2462/TTr-STTTT ngày thứ nhất tháng11 năm 2021.
Bạn đang xem: Mã vùng điện thoại lâm đồnlưu ứng dụng vào thẻ nhớ trên android
QUYẾT ĐỊNH:
Điều 1. ban hành kèm theo ra quyết định này lí giải kỹ thuật tích hợpứng dụng vào ứng dụng thương mại & dịch vụ đô thị sáng dạ Hue-S .
Điều 2. Hiệu lực thihành
Quyết định này có hiệu lực thi hành kểtừ ngày ký.
Điều 3. Trách nhiệmthi hành
Chánh văn phòng công sở Ủy ban quần chúng tỉnh;Giám đốc Sở tin tức và Truyền thông; Thủ trưởng các Sở, ban, ngành, đoàn thể cấp cho tỉnh; Chủtịch Ủy ban nhân dân các huyện, thị xã, thành phố Huế; quản trị Ủy ban nhân dâncác xã, phường, thị trấn; Thủ trưởng những cơ quan, 1-1 vị; tổ chức, cá nhân cóliên quan phụ trách thi hành đưa ra quyết định này./.
| vị trí nhận: - Như Điều 3; - thường xuyên vụ tỉnh giấc ủy; - thường trực HĐND tỉnh; - CT và những PCT ubnd tỉnh; - Báo thừa Thiên Huế; - Đài TRT; - Cổng TTDT tỉnh; - công báo tỉnh; - VP: CVP và những PCVP; - Lưu: VT, CN. | TM. ỦY BAN NHÂN DÂN KT. CHỦ TỊCH PHÓ CHỦ TỊCH Nguyễn Thanh Bình |
PHỤ LỤC
I. TỔNG QUAN
1. Phạm vi đối tượng người sử dụng áp dụng
Tài liệu này nhằm mục đích hướng dẫn các cơquan, đơn vị trở nên tân tiến các ứng dụng sẽ tích hợp lên gốc rễ ứng dụngHue-S.
2. Những nền tảng cung cấp tích hợp
| STT | Nền tảng vận dụng bên thứ 3 | Tích hòa hợp được Hue-S | Ghi chú |
| 1. | Android | Android | Nên dùng cho mục đích tích hợp các phần module native |
| 2. | iOS | iOS | Nên dùng cho mục tiêu tích hợp các phần module native |
| 3. | Flutter | Android iOS | Cần ưu tiên đóng góp gói áp dụng tích đúng theo vào Hue-S bằng công nghệ Flutter |
3. Giải thích từ viết tắt
Trong khuyên bảo này những từ ngữ sau đâyđược đọc như sau:
| STT | Tên viết tắt | Mô tả |
| 1. | Hue-S | Ứng dụng dịch vụ đô thị tuyệt vời Thừa Thiên Huế trên các nền tảng di động |
| 2. | NSD | Người sử dụng: người thao tác với vận dụng Hue-S trên các thiết bị di động |
| 3. | Android | Hệ quản lý điều hành Android của hãng Google dành cho các thiết bị di động |
| 4. | IOS | Hệ quản lý điều hành iOS của hãng sản xuất Apple giành cho các thiết bị di động của hãng sản xuất Apple |
| 5. | appId | Package name so với Android, Bundleld đối với iOS. Quý hiếm này rất cần phải định danh duy nhất |
II. MÔ HÌNH KẾT NỐI
Các áp dụng của mặt thứ 3 hoàn toànchủ rượu cồn về phương diện nghiệp vụ, tuy vậy các tin tức tương tác cơ phiên bản sẽ đượctrao đổi với ứng dụngchính Hue-S thông qua các lớp thành phần có thể tương tác được, cùng với cácphương thức như:
1. Component cần sử dụng chung
2. Sự kiện (Event) để đàm phán dữ liệu
3. Tạo những kênh liên kết
Ứng dụng Hue-S (Android/iOS)
Hình 1 Môhình yếu tắc ứng dụngdi đụng Hue-S
III. QUY TRÌNH TÍCH HỢPCÁC ỨNG DỤNG VÀO NỀN TẢNG ỨNG DỤNG HUE-S
IV. ĐẶC TẢ CÁC CÁCTHÀNH PHẦN KỸ THUẬT TÍCH HỢP
1. Đóng gói ứngdụng
- Ứng dụng Hue-S cung cấp tích hợpcác áp dụng được viết dưới dạngnative mang đến từng hệ điều hành Android cùng IOS hoặc được viết bằng công nghệ đa nền tảngFlutter (Ưu tiên).
- Để tích hòa hợp vào Hue-S thì áp dụng cầnđược đóng gói thành 1 module có thể chuyển động độc lập lẻ tẻ cụ thể nhưsau:
+ Đối với android thì vẫn đóng gói dướidạng apk Library. Screen Activity bao gồm của ứng dụng cần có tên làMainActivity và nằm tại thư mục mã bắt đầu của ứng dụng. Bên cạnh đó ứng dụng cầncung cung cấp ProGuard rules cho quy trình shrink, obfuscate module.
+ Đối cùng với IOS sẽ đóng gói dướidạng Framework. ViewController bao gồm của ứng dụng cần có tên làMainViewController.
+ Đối với đa nền tảng sử dụng Flutterthì buộc phải đóng gói bên dưới dạng package. Root Widget của ứng dụng rất cần phải đặt tênlà MainApp
- Ứng dụng tích đúng theo cần phát triển dựa trêncông nghệ đa gốc rễ Flutter để đảm bảo hiệu năng toàn diện và tổng thể của ứng dụngHue-S. Trong trườnghợp ứng dụng tích hợp yêu cầu đượcphát triển bên dưới dạng Native thì sẽ cần trao đổi thêm để có hướngtích hợp phù hợp.
- Để module ứng dụng hoàn toàn có thể giao tiếpđược với các thành phần phía bên trong Hue-S (đăng nhập, lấy tin tức tài khoản,thông báo...) thì sẽ đề nghị thêm SĐK chip core của Hue-S. Không tính ra, vận dụng Hue-S cũng cung cấpkhung căn bạn dạng của vận dụng Hue-S để các đơn vị thực hiện tích phù hợp thử trước khibàn giao hay cập nhật mã nguồn vận dụng và khi bàn giao mã nguồn ứng dụng cầncung cung cấp dưới dạng đang tích hợp thành công xuất sắc vào size Hue-S này.
- Mã nguồn áp dụng phải được cung cấpở dạng minh bạch có thể đọc được. Vào trường hợp đề xuất giấu mã mối cung cấp vì vì sao bảomật hoặc bảo đảm an toàn tài sản kiến thức thì sẽ cần bàn bạc trực tiếp để có phương hướngtích hợp phù hợp.
- Mã nguồn ứng dụng tích hợp sẽ được đẩylên Git Repositoty vì Hue-S cung cấp.Yêu cầu phải tạo những branch nhằm giữ các phiên bạn dạng cũ (tối thiểu 5 phiên bản)để phòng ngừa trường hợp bao gồm lỗi nghiêm trọng cần yếu khắc phục mau chóng thìcó thể tạm thời quay về bạn dạng cũ với cũng để giao hàng cho việc Hue-S buộc phải kiểm tragiám gần kề sự đổi khác của những phiên bản.
- Trong quy trình Hue-S nhận xét code ứngdụng, nếu phân biệt có phần như thế nào đó chưa phù hợp, chưa đảm bảo an toàn các yêu ước chấtlượng kỹ thuật thì có thể yêu ước phía cung ứng ứng dụng triển khai chỉnh sửa. Ngoàicác yêu cầu về kỹ thuật, quality ứng dụng được biểu lộ trong tài liệu thì về cơbản những ứng dụng tích phù hợp vào Hue-S cần vâng lệnh theo những yêu cầu, khuyến nghịvề hiệu năng, bảo mật, trải nghiệm... Do táo bị cắn dở và Google gửi ra dành riêng cho việcphát triển vận dụng di động.
2. Các thànhphần tích thích hợp do áp dụng Hue-S cung cấp
a. Tài khoản người dùng hệ thống
Thông tin tài khoản Hue-S bao gồmcác trường dữ liệu sau (một số tin tức sẽ được bổ sung cập nhật sau):
| Tên trường | Kiểu dữ liệu | Bắt buộc | Mô tả |
| Lớp (class) User | |||
| username | String | X | Tên đăng nhập |
| name | String | X | Họ cùng tên fan dùng |
| gender | Byte | X | Giới tính. 1: Nam; 2 Nữ; |
| birthday | String | X | Năm sinh người tiêu dùng định dạng dd/MM/yyyy |
| address | String | Địa chỉ thường xuyên trú của tín đồ dùng | |
| | String | | |
| phone | String | X | Điện thoại di động |
| avatar | Url ảnh đại diện của người dùng |
Ứng dụng tích vừa lòng vào Hue-S rất có thể cần thêm mộtsố trường thông tin khác liên quan đến dịch vụ của mình. Vào trường hợpnày ứng dụng hoàn toàn có thể tự bổ sung cập nhật thêm màn hình update thông tin vào ứng dụngvà tự cai quản các thông tin này (cập nhật, đồng bộ, lưu lại trữ...) cơ mà không thôngqua Hue-S. Tuy nhiên đơn vị cung cấp ứng dụng bắt buộc phải cung cấp API nhằm Hue-S cóthể tróc nã xuất tài liệu này khi cần thiết và cũng cần phải nêu rõ các trường dữ liệu cầnthêm trước khi tích hợp ứng dụng.Lưu ý, nên tránh bắt buộc người tiêu dùng nhập những thông tin thêm của vận dụng ngaytừ lần đầu người dùng sử dụng áp dụng nếu không quá sự buộc phải thiết.
Ứng dụng Hue-S chỉ chất nhận được đăng nhập bởi tàikhoản công dân Huế. Vào trường thích hợp phía cung cấp ứng dụng tích vừa lòng đã gồm khốilượng dữ liệu tài khoản người dùng lớn và mong muốn tận dụng tài liệu này thì tất cả thểdựa vào thông tin người tiêu dùng tài khoản Hue-S (ví dụ số năng lượng điện thoại, địachỉ email) để khám nghiệm xem người dùng này đã tồn tại trên hệ thống hay chưa vàsẽ gợi nhắc người dùng tiến hành đồng điệu dữ liệu thân 2 thông tin tài khoản công dân Huế vàtài khoản của phía hỗ trợ ứng dụng tích hợp.
Thư viện tích phù hợp Hue-S sẽ baogồm aAPI thông tin tài khoản để các ứng dụng tích hợp rất có thể lấy được tin tức tài khoảnhiện tại đang đăng nhập vàtoken xác xắn của tài khoản (xác thực thông tin người dùng trên khối hệ thống quảnlý tài khoản công dân Huế) dành riêng cho ứng dụng tích hợp. Lưu ý, các ứng dụng tíchhợp khác nhau sẽcó token xác thực người dùng khác nhau.
b. Hệ thống Menu điều hướng chính(Navigation Menu)
Là khối hệ thống Menu điều phối thống nhấtcủa ứng dụng Hue-S. Từ những ứng dụng tích hợp đều rất có thể gọi thực đơn này nhằm mục tiêu thực hiệncác điều hướng (navigative): về screen chính của ứng dụng, những ứng dụng ngangcấp khác, các tính năng thông tin cơ bản. Vấn đề gọi menu thiết yếu sẽ được thiết lập ởnút menu (dạng Hamburger = ) hoặc vuốt từ bỏ cạnh trái màn hình sang phải. Những ứngdụng tích hợp công ty động thiết lập cấu hình menu hamburger tại các vị trí quan trọng của ứngdụng.
Navigation menu này được cung cấptrong SDK tích vừa lòng Hue-S. Kế bên cácMenu điều hướng thắt chặt và cố định của Hue-S thì những đơn vị tích đúng theo cũng rất có thể bổsung thêm những Menu điều phối riêng của ứng dụng trải qua API.
Ngoài ra trong Navigation menu còn có2 Menu thắt chặt và cố định sẵn giành riêng cho từng ứng dụng tích vừa lòng là Hướngdẫn (dành cho vấn đề điều đào bới màn hình phía dẫn tương tự như giới thiệu ứngdụng trường hợp có) và Cài đặt (dành cho câu hỏi điều tìm hiểu màn hình thiết lập đặtriêng của áp dụng tích vừa lòng nếu ứng dụngtích hợp bao gồm các thông số kỹ thuật cho phép người dùng tùy chỉnh). Những ứng dụng tích hợpchủ cồn ẩn/hiện 2 menu này tùy thuộc vào ứng dụng có những mục trên hay là không thôngqua API.
c. Màn hình đăng nhập, đăng ký
Ứng dụng tích vừa lòng khi cần thực hiện các chứcnăng yêu ước phải chứng thực người dùng có thể tiến hành điều tìm hiểu mànhình đăng nhập hoặcmàn hình đk thôngqua API bởi Hue-S cung cấp.Sau khi người tiêu dùng đăng nhập thành công xuất sắc thì tất cả các ứng dụng tích hợp sẽ nhậnđược sự kiện đăng nhập bao
gồm tin tức về thông tin tài khoản của ngườidùng vừa đăng nhập
d. Thành phần chào đón và phân phốithông báo (Notification)
Ứng dụng Hue-S vẫn là nơi đón nhận tất cả cácthông báo được đẩy đến, và tiếp đến Hue-S đang phân phốithông báo cho áp dụng tích hợp tương xứng
e. Chia sẻ dữ liệu(bao có local data và remote)
Hue-S sẽ cung ứng kênhtrao đổi dữ liệu để các ứng dụngtích hợp hoàn toàn có thể thực hiệnchia sẻ dữ liệu chonhau cũng như hỗ trợ dữ liệu mang lại Hue-S khi cần thiết.
3. Tích hợptài khoản
a. Nguyên tắc
Mỗi khi người tiêu dùng đăng nhập hoặc đăng xuấtHue-S đang phát ra 1 sự kiện thông báo cho toàn thể các áp dụng tích hòa hợp được biết. Cácứng dụng cần phụ thuộc vào sự khiếu nại này để sở hữu cách hành động phù hợp nếu cần. Lấy một ví dụ nhưxóa các dữ liệu cache cá nhân của thông tin tài khoản vừa đăng xuất, hủy đăng một số topicfirebase tương quan đến tài khoản vừa đăng xuất, dừng các request liên quan đến tài khoản vừađăng xuất...
Các tác vụ của những ứng dụng tích vừa lòng cầnthực hiện nay khi thừa nhận sự kiện đăng nhập/đăng xuất nên nỗ lực thực hiện nhanh. Các tác vụ lâu hoặc nặngnên chờ đến khingười sử dụng vào app rõ ràng mới thực hiện thực hiện.
b. Sơ đồ vật tuần tự singin (login)
Hình 2 Sơ đồ vật tuần từ đăng nhậptừ hệ thống Hue-S
c. Sơ đồ tuần từ đăng xuất(logout)
Hình 3 Sơ thiết bị tuần tự vượt trìnhđăng xuất ứng dụngtrên các module tích hợp
4. Quy tắc để têntránh xung đột
Các ứng dụng tích hòa hợp vào Hue-S đề xuất cầnđảm bảo có các giá trị tên lẻ tẻ sau đây:
- thương hiệu miền của solo vị cung ứng ứng dụngtích hợp
- thương hiệu ứng dụng
- Prefix name (dùng đến đặt tên file,tag...) riêng biệt biệt. Ví dụ vận dụng có prefix name là cmv và buộc phải đặt giá trị taglà waitUpload thì giá trị sau cuối của tag đã là cmvWaitUpload hoặccmv_waitUpload...
Về cơ phiên bản để né xung hốt nhiên thì mỗi một khi ứng dụngcần 1 quý giá để sử dụng cho đánh tên File hoặc Tag cho những api thì quý giá đó đề nghị bao gồmpackage name (hoặc Bundle Identifier) hoặc prefix name (trong trường hòa hợp tên hoặctag yêu cầu ngắn gọn) đơn lẻ mà ứng dụng đã đăng ký trước khi tích hòa hợp vàoHue-S. Trong số ấy có những trườnghợp được quy định rõ ràng như sau.
a. Android
- Module package name
Các module được chế tác (bao tất cả cả modulechính tích hợp và các module tự chế tạo ra khác) cần chọn cái tên package theo quy tắctopleveldomain.applicationname nhằm tránh xung độtvới những module khác
Ví dụ công ty mang tên miền là example.com với chức năngfeedback là upload sẽ chọn cái tên com.example.feedback
- File, folder (bao gồm cả database,SharedPreferences)được ra đời trong quy trình sử dụng vận dụng cần là bé của folder gốc phụ thân cóđường dẫn như sau:
+ Internal Storage (bao bao gồm cả con đường dẫncache và data): đường_dẫn_gốc_internal/Tên_ứng_dụng
+ External Storage: đường_dẫn_gốc_external/HueS/Tên_ứng_dụng
(Lưu ý: nên kiểm tra xem thư mụcHue-S đã tồn trên chưa)
- Resource (drawable, string,style....)
Cần để tên có prefix đơn lẻ và quy địnhgiá trị prefix này trong gradle trải qua key “resourcePrefix” (có thể rước tênviết tắt của phầm mềm làm prefix)
- những name, tag cần được riêng biệtnhư Intent Action, content Uri Authority, WakeLock Tag, Permission Name...
Đặt tên cần bao hàm cả package name củamodule để tránh xung đột
- Universal Links
Phần domain name của links cho toàn bộ các ứng dụngcó quý giá là domain name của Hue-S. Các ứng dụng tích hòa hợp sẽ thực hiện phần path củalink để phân biệt liên kết giữa những ứng dụng. Cực hiếm phần path này đề nghị đặt riêngbiệt nhằm không xung đột nhiên với những ứng dụng khác
- Notification channel Id
Id kênh thông báo cần được đặttheo phép tắc package_name_id. Ví dụ com.example.feedback_hotSale
- Process name:
Đặt tên process cần bao gồm prefixname đơn nhất của ứng dụng. Chú ý hiện tại Hue-S chưa hỗ trợ app tích thích hợp tạothêm process.
b. IOS
- File, folder được xuất hiện trong quátrình thực hiện ứng dụng phải là con của thư mục gốc cha có băng thông như sau: đường_dẫn_gốc_internal/(Tên_ứng_dụng). Trongđó có 1 số để ý như sau:
+ Đường_dẫn_gốc_internal là mặt đường dẫnđến những loại thư mục lưu trữ nội cỗ gốc của áp dụng bao gồm: Documents, Library,Library/Caches, tmp.
+ các File, folder được tàng trữ trongDocuments đang được chia sẻ để người dùng có thể truy xuất khi buộc phải thiết(qua ứng dụng thống trị Files). Bởi vậy tránh việc lưu trữ những nộidung cơ mà không muốn người tiêu dùng truy cập trực tiếp nghỉ ngơi thư mục Documents
- UserDefault
Bắt buộc khởi chế tác UserDefaults kèmsuiteName bao hàm prefix name lẻ tẻ của ứng dụng.
- Local Notification(UNNotification)
Trong trường hòa hợp không áp dụng UUIDcho identifier mà bắt buộc tùy biến hóa tên thì nên đặt tên bao gồm bundle identifier
- NotificationCenter
Giá trị thương hiệu được dùng làm post phải baogồm prefix name đơn nhất của ứng dụng
- KeyChain
Giá trị key phải bao gồm prefix nameriêng biệt của ứng dụng.
- Framework bundle id
Cách đặt cực hiếm bundle id choframework (bao gồm cả framework thiết yếu tích hòa hợp và các framework tự chế tạo ra khác) giốngvới đánh tên packagemodule đến Android
c. Flutter
- Package name: Để kiêng xung bất chợt têncần viết tên chopackage (library) gọn nhẹ có tương quan đến thương hiệu của áp dụng và bao gồm prefixname riêng biệt của ứng dụng đã đăng ký từ đầu. Các plugin, package flutter tựtạo khác thì cần đặttên bao hàm Prefix Name riêng lẻ của ứng dụng.
Xem thêm: Ngày 21/6 Là Ngày Gì ? Nguồn Gốc Và Ý Nghĩa Ngày 21/6 Ngày 21/6 Là Ngày Gì
- Method Channel: các tên methodchannel được thực hiện cần bao hàm package name mang tên miền ngược của ứng dụng.
- Route: những ứng dụng tích thích hợp quy địnhtên route cần có prefix là base route bao gồm dạng /package_name (truy cập routenày đang vào màn hình hiển thị chính áp dụng tích hợp). Ví dụ phầm mềm A tích hợp vào Hue-S cócác route như sau /appA/featureA, /appA/featureB
5. Deep Links
a. Android
Chỉ yêu cầu khai báo Activity tương ứng vớiLink của áp dụng trong tệp tin AndroidManifest
b. IOS
Chỉ thực hiện Universal link không sử dụngUrl Scheme.
Khi vận dụng Hue -Skích hoạt tự Universal Links, Hue-S sẽ điện thoại tư vấn Class xử lý links của ứng dụng liênquan (Class này sẽ phải kê tên theo quy mong từ trước) nhờ vào phần path củalink.
6. Tích hợpnotification
a. Local Notification
Đối với tiện ích ios thì chỉ cần đặt giá bán trịidentifier () theo quy ước đã được nêu ở trong phần đặt tên làm sao cho tránh xung đột
Đối cùng với Android sẽ có 2 trường đúng theo cầntạo Local Notification là khi nhận được thông báo data Firebase bởi Hue-S làmtrung gian gửi do áp dụng và vận dụng tự tạo thông báo local (Ví dụ ngườidùng đặt lịch nói nhở). Việc tạo thông báo local trên game android cần vâng lệnh 1 sốquy tắc sau đây:
- phải tạo các kênh thông báo riêng biệtcho từng một số loại thông báo khác nhau (Notification Channel) để người dùng có thểtùy chọn tắt bật thông báo không cần thiết với phiên bản thân.
- Mỗi ứng dụng cần tích hòa hợp vào Hue-Ssẽ được cung cấp sẵn đội kênh thông tin (Notification channel group) trước khitiến hành tích thích hợp ứng dụng. Những ứng tích hợp cần phải sử dụng groupId của nhómthông báo cung ứng sẵn để sinh sản kênhthông báo.
- thông báo local sẽ phải đượckhởi tạo thành kèm theo tag là package name của ứng dụng còn id có giá trị tùy ý: notify(String package_name, int id, Notification notification)
b. Remote Notification
Khi những ứng dụng tích hợp bắt buộc đẩythông báo cho người dùng, thay vì chưng gửi thẳng lên firebase sẽ tiến hành đưa tậptrung về hệ thống của Hue-S cùng ServerHue-S đã thực hiệnviệc push notification lên Firebase. Vấn đề này nhằm điều hành và kiểm soát tần suất đẩy thôngbáo, bớt tính tinh vi trong thông số kỹ thuật thông báo vận dụng và hỗ trợ cho ứng dụng Hue-S hoàn toàn có thể lấy danhsách thông báo (xem lại các thông tin đã đẩy) hối hả từ 1 nguồn duy nhất.
POST https:/tuongtac.thuathienhue.gov.vn /dichvu/push
+ to: xác minh thông báo này đang gửicho ai. Giá chỉ trị hoàn toàn có thể là thương hiệu topic (/topics/tên_topic) hoặc usemame của ngườidùng rõ ràng muốn gửi. Lúc này chưa cung ứng gửi theo nhóm. Chú ý tên topic cầnthêm chi phí tố prefix name cá biệt của vận dụng để tránh xung đột. Ví dụ nên gửithông báo mang đến topic mang tên hotSale (to: /topics/hotSale) và vận dụng có prefixname là caro thì tên topic sẽ là caro_hotSale
+ priority: chỉ định mức độ quan liêu trọngcủa thông tin gồm 2 quý giá normal với high. Chú ý đối cùng với cái thông tin khôngquan trọng, mang tính chất quảng cáo, giới thiệu, phạm vi đối tượng nhắm mang lại là cộngđồng thì không đặt quý giá high.
+ title: tiêu đề thông báo. Tiêu đềnên mang tính đặc trưng của ứng dụng nếu không thì sử dụng tên ứng dụng làmtiêu đề thông báo.
+ message: văn bản thông báo. Nộidung này buộc phải ngắn gọn, cụ thể.
+ data (có thể null): Dữ liệugửi kèm thông báo có kích thước không vượt vượt 3 KB. Vào trường thích hợp vượt quá3 KB thì có thể dùng gzip để nén dung tích text data
+ channel_id (có thể null): Chỉ địnhnotification channel id của Android. Khoác định thì thông báo Android trường đoản cú firebasesẽ được đẩy vào kênh thông báo có id là appId của ứng dụng tích hợp. Trường hợp channel_idcó quý giá thì thông tin sẽ được đẩy vào kênh thông báo có id là appId_id.Các áp dụng tích phù hợp cân chủ động tạo những kênh thông báo của mình.
c. Firebase
Hiện trên chỉ cung cấp tích hợpCrashlytics cho vấn đề log lỗi. Trong 1 khoảng thời hạn định kỳ một mực Hue-S tiến hànhrà soát lỗi áp dụng và sẽ gửi các lỗi tương quan đến áp dụng cho bên hỗ trợ ứngdụng để triển khai vá lỗi. Những dịch vụ khác sau đây sẽ tiến hànhtích hợp trải qua Firebase BigQuery và Firebase Api ví như được hỗ trợ
7. Lưu trữ và đồng bộdữ liệu
Mỗi vận dụng sẽ áp dụng file databaseriêng nhằm tránh xung đột dữ liệu. Vì áp dụng database riêng nên mỗi áp dụng cóthể tùy ý áp dụng loại database (file, sql, nosql) Hue-S đã phát 1 sự kiện khingười sử dụng mở vận dụng Hue-S để những ứng dụng tích hợp hoàn toàn có thể tiến hành đồng điệu các dữ liệuquan trọng, đề xuất thiếtđối với những người dùng. Những ứng dụng tích hợp dìm sự kiện này trải qua việc kế thừaclass AppDelegateImpI. Mặc dù cần kị thựchiện nhiều request hoặccác tác vụ thọ nếu không thật sự cần thiết trong thời gian này.
Nếu ứng dụng có các tác vụ định kỳ cầnthực hiện ở background (khi ứng dụng không sinh hoạt trạng thái active so với IOS hoặcthậm chí khi vận dụng không được nhảy trước đó đối với Android) thì nên cần traođổi thêm trực tiếp để sở hữu phương án tích hòa hợp phù hợp.
Android với IOS có cung cấp nhiều loạivùng nhớ cho từng loại tài liệu khác nhau. Rất cần phải lựa lựa chọn đúng nhiều loại vùng nhớtheo lời khuyên của apple và Google vì chưng Hue-S sẽ chủ động vệ sinh các vùng nhớ(tùy theo từng hoàn cảnh sẽ chọn những vùng nhớ không giống nhau) của các ứng dụng lúc cầnthiết. Hình như dung lượng bộ lưu trữ trong cho các vùng nhớ lâu bền hơn (không phảicache hoặc temporary) tối đa mà những ứng dụng được thực hiện là 100MB.
8. Bảo mật
- hạn chế lưu trữ những dữ liệu mangtính hóa học nhạy cảm của người dùng nếu không cần thiết. Nếu như cólưu trữ thì dữ liệu rất cần phải mã hóa bởi chế độ sinh khóa bảo mật thông tin cao hoặc lưutrữ trong số vùng nhớ bảo mật cao bởi hệ điều hành cung cấp (Keychain đối vớiios và Keystore so với Android). Đối cùng với database (sql, nosql) thì có thể sử dụngcác thư viện hỗ trợ mã hóa là sqlcipher hay Realm.
- những request network nếu bao gồm gửi nhậndữ liệu hay thao tác mang tính nhạy cảm thì cần phải sử dụng HTTPS. Serverluôn phải xác thực, bình chọn tính thích hợp lệ của request, giỏi đối thiếu tín nhiệm tưởngvào client.
- tránh trả dữ liệu dư thừa mang đến ngườidùng nhằm không lãng phí dung lượng của người dùng và tăng tính bảo mật dữ liệu.Những dữ liệu người dùng không đề xuất thấy thì ko trả về cho dù là chặn hiển thịtrên app.
- Đối với những chức năng, thao tác làm việc cầntính bảo mật cao trên android thì khuyến nghị nên kiểm tra độ tin cậy củathiết bị trải qua SafetyNet Api. Phần này sẽ vì Hue-S cung cấp trung gianthông qua API tích hợp.
- Webview chỉ được sử dụng để hiển thịnội dung html tĩnh. Không đượcsử dụng Webview nhằm hiển thị hoặc tải nội dung của những bên khác. Trong trường hợpcần cài đặt nội dung trang web ngoài thì thực hiện Chrome Custom Tabs hoặc mở trìnhduyệt của thiết bị
- Đối với những file được upload tự ứngdụng cần thay tên filetrước hoặc sau khi upload để tránh trường hợp lộ thông tin người tiêu dùng từ tênfile trừ khi bao gồm yêu cầu giữ thương hiệu từ người tiêu dùng hoặc câu hỏi giữ thương hiệu là quan trọng đốivới tín đồ dùng. Đối với các file ảnh và video clip khi download lên server rất cần phải xóa các thông tinmetadata cóliên quan liêu đến người dùng (ngày tạo, chỉnh sửa, vị trí, thông số kỹ thuật camera...)
- Khi người dùng đăng xuất tài khoảnthì áp dụng cần xóa hết những dữ liệu tương quan đến tài khoản. Nếu buộc phải giữ lại thìphải mã hóa nhằm chỉ khi tàikhoản đó singin lại mới rất có thể khai thác tài liệu được.
9. Hiệu năng
- các request network thông thường (tổngdữ liệu gửi/nhận bé dại hơn 100KB và không tiến hành các đo lường phức tạp) có thờigian trung bình không thực sự 2 giây
- tuyệt vời không thực hiện các tác vụnặng hoặc mất không ít thời gian (network, tầm nã xuất file/database...) ở threadUI
- nỗ lực kiểm kiểm tra memory áp dụng đểkhông bị đưa lên quá nhanh hoặc không thấp chút nào gần ngưỡng crash. Tiêu giảm tối đa memoryleak. Trong khi cần tinh giảm việc sinh sản thêm process trên android và mọi khi kếtthúc process thì cần chủ động xong (kill) process nếu như process không được cầnmở thường xuyên hoặc không phải process quan lại trọng.
- khi ứng dụng lâm vào tình thế trạng tháikhông kích hoạt thì nên dừng những tác vụ không cần thiết (nhất là các requestnetwork hoặc tác vụ nặng, sensor) để sút hao phí dung lượng pin, cpu.Ngoài ra, khi người tiêu dùng thoát khỏi màn hình tính năng cũng cần phải dừng cáctác vụ không quan trọng được tạo nên ở screen này.
- hoàn hảo và tuyệt vời nhất không lạm dụng đẩythông báo sinh hoạt dạng im re (data app android và silent IOS) nhằm kích hoạt thiết bịactive mang lại mục đích nhất quán dữ liệu. Nếu cần phụ thuộc thông báo để đồng hóa dữliệu mập và thường xuyên thì cần bàn bạc thêm.
- hoàn hảo nhất không trường đoản cú tạo những lịch taskchạy ngầm bên android (bao có cả Service) hoặc những các background task bên IOSđể đồng nhất dữliệu. Như đang ghi trên phần tàng trữ và đồng điệu dữ liệu, bài toán này cần trao đổithêm.
- nỗ lực cache dữ liệu để tránh việc requestnetwork liên tiếp trong thời gian ngắn. Ngoài ra nên tạo những phiên bạn dạng nhỏ của dữliệu. Ví như Ảnh thì vẫn có hình ảnh thumb nhằm hiển thị ở danh sách thay do sử dụngảnh đầy đủ. Danh sách bài viết thì chỉ việc 1 vài thông tin như tiêu đề, nắm tắt,ngày đăng chứ không cần cần cục bộ nội dung bài viết. Như vậy không chỉ giảm dunglượng tài liệu mà còn giảm thiểu CPU áp dụng để giải pháp xử lý dữ liệu
- Đối với những tác vụ cách xử trí nặng thìnên có những phương hướng xử lý, những hạn chế ràng buộc tài liệu cho từng phân khúccấu hình sản phẩm nếu có thể. Lấy ví dụ như với tác vụ nén hình ảnh thì các thiết bị cómemory khủng sẽ cho phép thực hiện nay 3 tác vụ nén ảnh chạy song song, còn cùng với cácthiết bị có dung tích memory nhỏ dại thì chỉ cho phép thực hiện nay 1 tác vụ nén trong1 thời điểm.
10. Tích hợp những dịchvụ ứng dụng di động
a. Thanh toán trong vận dụng (in-apppurchase)
Thanh toán trong ứng dụng Hue-S sẽkhông thông qua các dịch vụ giao dịch của bên thứ 3 nào khác (kể cả dịch vụthanh toán trong ứng dụng củaApple cùng Google) mà sử dụng cổng giao dịch riêng. Những ứng dụng tích hợp sẽ sửdụng các api thanh toán giao dịch do Hue-S hỗ trợ để thực hiện thanh toán trong ứng dụng.
Trong ngôi trường hợp vận dụng có những nộidung số thường phải trả mà theo chính sách phát triển vận dụng bắt buộc phảisử dụng thương mại dịch vụ in-app purchase của Google/Apple thì phải tự tìm kiếm cáchchuyển thay đổi phù hợp.
b. Phiên bản đồ
Hue-S sẽ hỗ trợ cho những đơn vị phát triểnứng dụng thương mại dịch vụ bảnđồ miễn phí bao hàm sdk và dữ liệu bạn dạng đồ trong phạm vi tỉnh vượt Thiên Huế.Các vận dụng tích thích hợp vàoHue-S bắt buộc sẽphải sử dụng bạn dạng đồ này. Vào trường đúng theo dịch vụ bạn dạng đồ của Hue-S không đáp ứngđủ yêu cầu thì sẽ thực hiện trao đổi thêm để sở hữu phương án tích hợp phiên bản đồ phù hợp.
V. YÊU GIAO DIỆN ỨNGDỤNG TÍCH HỢP
1. Bố cục tổng quan màusắc
Cần dựa theo những guideline của Apple(ios) cùng Google material (android). Trong các số ấy có một số yêu cầu rõ ràng như sau:
- Cần nhất quán giao diện ứng dụngtrên các nền tảng không giống nhau (Android với IOS) để người dùng hoàn toàn có thể dễ dàng thực hiện ứngdụng trên nhiều thiết bị di động. Đối với các giao diện dành cho các thiết bịdi rượu cồn quá biệt lập (đồng hồ thông minh, tv thông minh...) giỏi trên máytính thì cũng cần phải có những sự tương đồng bộ định với hình ảnh trên năng lượng điện thoại.
- Không thực hiện quá 3 màu bao gồm (khôngtính màu sắc đen, trắng và gradient) cùng cần đồng nhất trong việc áp dụng màu. Tuyệtđối không lạm dụng màu sắc khiến cho người dùng khó đọc được ngôn từ trừ trườnghợp màn hình hiển thị có ít văn bản chữ đề xuất đọc
- Không thực hiện nhiều các loại font chữtrong ứng dụng, bắt buộc sử dụng những loại font, form size font với màu chữ sao cho dễđọc.
- Sử dụng những icon đơn giản dễ dàng và hiện nay đạiví dụ như material icon của google
- bố cục tổng quan sắp xếp những nội dung ứng dụng cần gọngàng, dễ chú ý trên nhiều size màn hình và scaling. Phải gồm sự phân táchrõ ràng giữa các nhóm nội dung trên màn hình
- với mỗi màn hình chức năng, cácthành phần hệ trọng được triết lý là chức năng chính tại màn hình đó thì cầnđược thể hiện khá nổi bật hơn (bởi màu sắc hoặc kích thước) so với những thành phầnkhác.
- Ứng dụng cần có navigation menu mặt trái.Ngoài những thông tin yêu cầu của Hue-S gồm những: header, danh sách ứng dụng,giới thiệu áp dụng hiện tại(thông tin ứng dụng, khuyên bảo sử dụng...) và setup (nếu có) thì vẫn có thểtùy ý thêm những menu điều phối riêng của áp dụng vào navigation.
- tinh giảm nhét các điều hướng, chứcnăng đặc biệt hoặc được dùng tiếp tục của vận dụng ở navigation menu,cố gắng thể hiện những chứcnăng đó ở screen chính
- tránh việc thể hiện quá nhiều nội dung trong một mànhình nếu không thực sự sự đề xuất thiết. Nên chia nhỏ các nhóm nội dung ra các mànhình để người tiêu dùng dễ đọc và thaotác. Vào trường hợp xây dựng cho máy tính bảng thì 1 screen giao diện của sản phẩm tínhbảng hoàn toàn có thể là tổng đúng theo nhiều màn hình hiển thị giao diện điện thoại.
- màn hình hiển thị đầu vận dụng cần cótên ứng dụng (tên hoàn toàn có thể biểu diễn cả dạng text hoặc hình ảnh miễn sao có thểnhận dạng được đấy là ứng dụng gì) với nút hamburger nhằm mở navigation thực đơn (cũngcó thể mở bằng phương pháp vuốt từ mép trái màn hình.
2. Trải nghiệm
- Không sử dụng webview để thể hiệnmàn hình chức năng trừ trường hợp phải hiển thị nội dung html tĩnh. Bắt buộc lậptrình các màn hình công dụng dưới dạng native hoặc đa căn nguyên flutter nhằm đem lạitrải nghiệm tốt cho những người dùng và đảm bảo an toàn tính bảo mật.
- cố gắng tối ưu nhằm tránh việc giật,khựng khung người trong quá trình sử dụng ứng dụng.
- Các thao tác load tài liệu hoặc xử lýdữ liệu yêu cầu phải gồm nút ngừng để người dùng hoàn toàn có thể dừng làm việc (khi cảm thấylâu hoặc không buộc phải nữa). Trong khi nên nỗ lực hạn chế những loading indicatortoàn screen khi không quá sự buộc phải thiết.
- các nút, chữ...cho phép fan dùngtương tác (nhấn, kéo...) cần có size vùng bấm (tương tác) đủ phệ để ngườidùng dễ dàng thao tác
- thông báo lỗi thân thiết và dễ hiểuđồng thời kèm hướng giải quyết nếu tất cả thể.
- các nội dung text cụ thể nội dungnên cho tất cả những người dùng tất cả thểcopyđược
- màn hình xem chi tiết nội dung phảicho tín đồ dùng có thể mở bằng trình trông nom để xem sinh sống dạng website nếu có trang web
- Yêu ước quyền:
+ triển khai yêu cầu quyềntheo hoàn cảnh và phải lý giải vì sao nên quyền
+ lúc cần người dùng nhảy cho tới Settings(yêu cầu quyền bị deny, nhảy GPS...) cần phân tích và lý giải rõ và cho phép người dùngquyết định tất cả đến màn hình hiển thị Settings tốt không
+ khi vào 1 màn hình nội dung với mànhình đó phải yêu mong 1 quyền nào đó. Giả dụ quyền kia không quá đặc biệt (hoặc đãtừng bị deny nhiều lần) thì tránh việc hiển thị dialog yêu ước quyền ngay khivào màn hình hiển thị để tránh việclàm phiền người dùng. Rất có thể hiển thị message yêu cầu cung cấp quyền cùng rất nộidung của screen đó để người tiêu dùng cảm thấy cần thì mới bấm cấp cho quyền.
- lúc vào màn hình hiển thị cần bật GPS thìkhông yêu cầu bắt buộc người dùng phải nhảy nếu không quá cần thiết, cần hiển thịmessage lý do vì sao cần bật GPS. Đối cùng với Android thì nên bật thông qua apigoogle chứ không cần nhảy đến Settings.
- Cache các dữ liệu quan trọng với ngườidùng hoặc những dữ liệu ít thay đổi để có thể sử dụng offline hoặc đến hiện trướcdữ liệu cache trước khi request tài liệu từ mạng để tạo cảm hứng tải dữ liệunhanh (hình ảnh, ghi chú tấn công dấu... Tin tức tài khoản...).
