2012-08-29 38 views
11

OK. Tôi đã bắt đầu phát triển Ứng dụng Android cho ứng dụng web dành cho doanh nghiệp của chúng tôi. Chỉ cần bắt đầu thiết kế hoạt động màn hình đăng nhập.Thiết kế và phát triển Android Login - Phương pháp tiếp cận và thực hành tốt nhất

Ứng dụng này hoàn toàn được điều khiển bởi RESTFul API.

Tôi muốn hiểu cách phát triển tính năng đăng nhập/đăng xuất trong ứng dụng. Theo như tôi hiểu, không có khái niệm Phiên trong thế giới ứng dụng. Ngoài ra, đối với API, chúng tôi cần gửi Tên người dùng và Mật khẩu theo mọi yêu cầu (Xác thực cơ bản). Vì vậy, rõ ràng, chúng tôi cần giữ thông tin đăng nhập ở đâu đó trong bộ nhớ cục bộ để gửi cùng với mọi yêu cầu.

Dưới đây là những gì tôi hiểu được từ kiến ​​thức cơ bản về Android của mình.

Khi người dùng nhập thông tin đăng nhập và nhấn nút, chúng tôi sẽ quay cuộc gọi HTTP thành API. Nếu thông tin xác thực đăng nhập hợp lệ, thì chúng tôi sẽ phải lưu trữ thông tin đăng nhập cục bộ. Các tùy chọn là

  1. SQLite
  2. Tùy chọn chia sẻ. (Tôi không bao giờ sử dụng nó. Nhưng tôi giả định, chúng ta có thể sử dụng này)
  3. Bundle (Không chắc nếu điều này là một lựa chọn)

Bất kỳ lựa chọn thay thế khác?

Tôi muốn đảm bảo tôi tuân theo phương pháp hay nhất, trong khi không phải hy sinh từ quan điểm hiệu suất và kiến ​​trúc.

Và để đăng xuất, tôi nghĩ rằng tôi chỉ cần xóa sạch thông tin đăng nhập được lưu trữ cục bộ và hiển thị Hoạt động đăng nhập.

Có phương pháp tiếp cận nào khác và tốt hơn không?

Trả lời

13

Tôi khuyên bạn nên sử dụng tính năng Android Accounts.

This blog có hướng dẫn từng bước khá tốt về tất cả các bit bạn cần đặt cùng nhau.

Ý tưởng chung là bạn cung cấp AccountManager với tên người dùng/mật khẩu người dùng và để nó cho Người quản lý tài khoản để lưu trữ chúng một cách an toàn.

Khi bạn cần mã xác thực, bạn sẽ yêu cầu Trình quản lý tài khoản cho một mã và trả lại mã thông báo đã lưu trong bộ nhớ cache hoặc gọi lại cho mã của bạn (chuyển tên người dùng/mật khẩu) và thực hiện cuộc gọi đến dịch vụ xác thực của bạn nhận mã thông báo mới.

+0

Tôi đang bối rối về đoạn thứ 3. Khi bạn lưu trữ dữ liệu trong Tài khoản, nó có hết hạn vào lúc nào đó không? Điều đó có nghĩa, nếu người dùng đang ở giữa ứng dụng, trên một số Hoạt động, nếu Tài khoản không cung cấp cho tôi U/P, tôi cần hiển thị màn hình đăng nhập để lấy lại U/P? –

+0

@KevinRave Anh ấy đang sử dụng lại mã thông báo truy cập từ các tùy chọn –

+0

Tên người dùng/mật khẩu sẽ không hết hạn. Mã xác thực được trả về từ webservice của bạn có thể hết hạn (ở phía máy chủ), nếu điều này xảy ra, bạn cần thông báo cho Trình quản lý tài khoản rằng mã thông báo đã hết hạn và sẽ kích hoạt cuộc gọi lại để yêu cầu bạn nhận mã thông báo mới – Rob

2

Nói chung, có ba cách bạn có thể lưu giữ dữ liệu trong Android: SQLite, SharedPreferences và đọc/ghi lên tệp một Java I/O la. SQLite là tối ưu cho dữ liệu quan hệ, nhưng vì bạn chỉ cần lưu trữ thông tin đăng nhập của người dùng, tôi khuyên bạn nên sử dụng SharedPreferences. Dường như với tôi giống như một mô hình dữ liệu giá trị khóa đơn giản.

SharedPreferences về cơ bản chỉ là đóng gói tệp I/O trực tiếp - nghĩa là việc triển khai cơ bản vẫn là đọc và ghi tệp, nhưng được đơn giản hóa cho các cặp khóa-giá trị. Tôi không biết nhiều về mã hóa, nhưng bạn có thể phải tự mình xử lý trước khi lưu trữ mật khẩu trong đối tượng SharedPreferences (cũng xem xét đề xuất của JaiSoni: sử dụng mã thông báo truy cập thay thế). Tuy nhiên, hãy yên tâm rằng nếu bạn tạo SharedPreferences và đặt thành MODE_PRIVATE, các ứng dụng khác sẽ không có quyền truy cập vào tệp prefs được chia sẻ.

Tôi tin rằng đây thực sự là một triển khai chuẩn. Nếu bạn nhìn vào trang này, thực sự chỉ có rất nhiều điều bạn có thể làm: http://developer.android.com/guide/topics/data/data-storage.html

Tôi cũng chỉ ra rằng một trong những phức tạp với tệp I/O trực tiếp là bạn sẽ phải quyết định nơi bạn muốn lưu trữ tệp - bộ nhớ trong hoặc bộ nhớ ngoài (ví dụ: thẻ SD) - và do đó kiểm tra tính sẵn có của nó (không phải tất cả các thiết bị đều có khe cắm thẻ SD và đôi khi bộ nhớ trong được đăng ký làm bộ nhớ ngoài cho thiết bị). Vì vậy, chỉ cần đi với prefs được chia sẻ.

Đối đăng xuất, điều này có thể có ích: Deleting shared preferences

+0

Cảm ơn. Tôi muốn biết, nếu đây là cách làm tiêu chuẩn. Hoặc có những cách tốt hơn để làm điều đó. Giới thiệu về đăng xuất? –

+0

@KevinRave Xem chỉnh sửa. –

2

Tôi nghĩ rằng lưu trữ mật khẩu trong ứng dụng này là ý tưởng tồi, tiếp cận tốt hơn chỉ là thực hiện yêu cầu với người sử dụng chứng chỉ lúc đầu tiên khi người dùng được đăng nhập máy chủ trả về một thẻ truy cập lưu mã thông báo truy cập này trong SharedPreferences cho mục đích còn lại như nhận chi tiết người dùng sử dụng mã thông báo theo yêu cầu.
Phiên: Tạo lớp học riêng của bạn để duy trì phiên. Hackbook là một ví dụ tốt cho nó.

+0

Đề xuất tuyệt vời. Điều này sẽ yêu cầu họ sửa đổi back-end, mặc dù, tôi phải không? Nếu cơ chế mã thông báo truy cập chưa được triển khai, tức là. –

+0

@mattquiros Có, bạn sẽ yêu cầu dịch vụ web hỗ trợ mã thông báo truy cập –

+0

@mattquiros Bạn nói đúng. Đó là một sự thay đổi logic nghiệp vụ ở phần phụ trợ. Điều đó không thể được thực hiện tại thời điểm này. –

0

Tại sao bạn cần duy trì thông tin xác thực đăng nhập trong tệp hoặc cơ sở dữ liệu? Bạn có muốn được tự động đăng nhập sau khi ứng dụng của bạn được khởi động lại không? nếu kiên trì là không cần thiết, bạn có thể đặt các thông tin vào một thành viên java tĩnh.

+0

Có thể truy cập được qua ứng dụng, trong suốt phiên người dùng không? –

+0

không chắc chắn cách bạn gán tên người dùng và mật khẩu cho các thành viên tĩnh trong thời gian chạy? –

+0

Có thể truy cập được nếu bạn công khai tên miền đó. /java/javaOO/classvars.html) – k3b

Các vấn đề liên quan