2012-01-25 23 views
19

Một mô hình dưới đây có thể giải thích tốt hơn các từ. Về cơ bản, tôi muốn danh sách các mục có thể được thêm/xóa tự động bởi người dùng và mỗi mục có màn hình cài đặt có thể định cấu hình.Tôi làm cách nào để tạo tùy chọn Android một cách linh hoạt?

Vì vậy, có hai phím ở đây:

  1. Thêm vào sở thích của màn hình chính
  2. Bắt đầu từ một activityForResult khi một mục được nhấn. Hoạt động này sẽ hiển thị chế độ xem tùy chọn khác (thanh trượt, hộp kiểm, v.v.) trong đó người dùng có thể thao tác các giá trị này và sau đó trả lại giá trị mới được lưu trữ trong cấu trúc dữ liệu .

Ảnh:
http://i.stack.imgur.com/eZsfh.png

+0

Bạn có thể làm rõ cách hoạt động? Ví dụ: nếu người dùng nhấn "Thêm mục", điều gì sẽ xảy ra? – Mel

+0

Bạn có thể thử sử dụng cơ sở dữ liệu: Hàng cha mẹ là 'các tùy chọn khác', trong khi hàng con là các sittings trong tùy chọn đó. – Andreas

Trả lời

-2

Thực tế việc tạo màn hình tùy chọn tự động thật dễ dàng. Bạn có thể làm điều đó trong mã (tìm kiếm ứng dụng mẫu API Demo cho PreferenceFromCode.java) hoặc bằng cách mở rộng tệp XML mà bạn có thể viết (PreferencesFromXml.java). Điều gì sẽ khó khăn là đến với một giao diện người dùng hợp lý và lưu trữ back-end cho người dùng để soạn và lưu trữ các bộ sưu tập ưu tiên động.

+13

Thật tuyệt khi biết điều đó thật dễ dàng - sẽ rất tốt nếu bạn thực sự đưa ra câu trả lời thay vì nói 'Nhìn đâu đó khác'. Ngay cả một URL sẽ tốt hơn. –

+0

Dường như ứng dụng mẫu bạn đã chỉ định không còn khả dụng nữa. – SOFe

1

tôi sẽ đề nghị nhóm xuống đường của mảnh vỡ - đặc biệt PreferenceFragment: http://developer.android.com/reference/android/preference/PreferenceFragment.html

Tại sao tôi nghĩ rằng điều này sẽ làm việc tốt cho bạn:

Bên cạnh đó , tùy chọn được hiển thị sẽ theo kiểu trực quan của tùy chọn hệ thống. Thật dễ dàng để tạo ra một hệ thống phân cấp các sở thích (có thể được hiển thị trên nhiều màn hình) thông qua XML. Vì những lý do này, bạn nên sử dụng để sử dụng đoạn này (làm siêu lớp) để xử lý các tuỳ chọn trong các ứng dụng.

1

Câu hỏi của bạn là một chút mơ hồ, nhưng có lẽ điều này được giải quyết tốt nhất bằng cách lưu trữ dữ liệu của người dùng trong một cơ sở dữ liệu (và sử dụng tiêu chuẩn CursorAdapterCursorLoader trường để hiển thị dữ liệu này để người sử dụng) chứ không phải là cố gắng để buộc tất cả mọi thứ vào Khung tùy chọn. CursorAdapter được tối ưu hóa để xử lý các tập kết quả lớn tùy ý, trong khi PreferenceActivity và bạn bè thực sự làm việc tốt hơn với một bộ dữ liệu cố định.

Công cụ ưu tiên được thiết kế để dễ triển khai cho trường hợp sử dụng cụ thể của nó, nhưng nếu trường hợp sử dụng của bạn nằm ngoài phạm vi đó - và có vẻ như nó sẽ gây rắc rối cho việc nén dữ liệu của bạn mô hình tùy chọn.

Nếu bạn chỉ thích Giao diện người dùng tùy chọn, bạn có thể xem nhanh mã nguồn Android để xem cách mã được triển khai trong khi vẫn cho phép logic của riêng bạn biến một giao diện người dùng đó.

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