2009-11-07 26 views
8

Đây là câu hỏi tôi đã có cho một vài ứng dụng khác nhau mà tôi đã tạo và tôi chưa được thỏa mãn với bất kỳ giải pháp nào mà tôi đã đưa ra. Tôi nghĩ tôi sẽ đưa nó ra cộng đồng để xem các giải pháp khác có thể có.Lựa chọn thay thế tốt để chia sẻ một cây đối tượng phức tạp giữa các hoạt động trong Android?

Giả sử bạn có Hoạt động tải xuống một cây dữ liệu phức tạp (trong trường hợp này thông qua json, nhưng nó có thể là bất kỳ thứ gì), unmarshalls dữ liệu đó cho một tập hợp các đối tượng java (trong trường hợp này sử dụng gson, nhưng một lần nữa, có thể là bất cứ điều gì), sau đó sinh ra các hoạt động bổ sung để xem các phần khác nhau của dữ liệu đó. Có thể có một hoạt động để xem Chuyến đi trong phản hồi của bạn và một hoạt động khác để xem Chuyến bay trong những chuyến đi đó và có thể một chuyến khác để xem Hành khách của những chuyến bay đó.

Thực hiện ban đầu của ứng dụng này là để unmarshall tất cả các chuyến đi trong hoạt động đầu tiên, sau đó vượt qua chúng theo giá trị (như là một phụ trong ý định) để TripActivity. TripActivity sau đó chuyển các chuyến bay riêng lẻ đến FlightActivity, v.v.

Vấn đề với điều này là có một sự tạm dừng đáng chú ý giữa các hoạt động trong khi ứng dụng sẽ tuần tự hóa và deserializes dữ liệu. Chúng ta đang nói vài giây. Việc tạm dừng là khá đáng chú ý khi cây của tôi sử dụng Serialization hoặc Parcelable để truyền dữ liệu xung quanh. Thử nghiệm hiệu suất ban đầu với việc sử dụng Parcelable của google thay vì tăng tốc 30% so với serialization, nhưng Parcelable khó làm việc và dường như không xử lý các tham chiếu đối tượng tròn cũng như Serialization, và bên cạnh nó vẫn tạm dừng trong gần vài giây, vì vậy tôi đã đặt thử nghiệm đó trên backburner trong khi tôi thử những thứ khác.

Vì vậy, sau đó tôi đã thử di chuyển cây đối tượng trực tiếp vào lớp Ứng dụng. Mỗi hoạt động chỉ lấy cây trực tiếp từ ứng dụng bất cứ khi nào nó cần. Điều này làm cho hiệu suất khá linh hoạt, nhưng xử lý các trường hợp góc như khởi động/dừng hoạt động không mong muốn (hoặc do hoạt động bị treo hoặc vì hoạt động đã bị đóng tạm thời để tạo thêm bộ nhớ, hoặc bất kỳ nguyên nhân nào khác) có vẻ phức tạp. Có lẽ nó không nhiều hơn thực hiện onSaveInstanceState(), tôi không chắc chắn, nhưng giải pháp có vẻ hơi hacky vì vậy tôi đã không điều tra thêm.

Vì vậy, để tìm kiếm một giải pháp ít rải sỏi hơn, tôi đã thử tạo một ContentProvider tùy chỉnh để lưu trữ và truy xuất các đối tượng của mình. Kể từ khi ContentProviders có thể được cấu hình để chạy trong quá trình sử dụng multiprocess=true, tôi nghĩ rằng đó sẽ là một cách tuyệt vời để tránh chi phí serialization trong khi làm một cái gì đó nhiều hơn "tiêu chuẩn" hơn lưu trữ dữ liệu trong đối tượng ứng dụng. Tuy nhiên, ContentProviders rõ ràng không có ý định trả về các loại đối tượng tùy ý - chúng chỉ hỗ trợ các kiểu như số, chuỗi, booleans, v.v. Có vẻ như tôi có thể kết thúc một để lưu trữ các đối tượng tùy ý bằng cách sử dụng ContentResolver.getContentProviderClient().getLocalContentProvider() và truy cập trực tiếp vào lớp tùy chỉnh của mình. 'không chắc chắn đó là ít hacky hơn lưu trữ dữ liệu trong đối tượng ứng dụng.

Chắc chắn ai đó phải có giải pháp tốt cho vấn đề này. Tôi đang làm gì sai?

Trả lời

3

Ngoài giải pháp của fiXedd, một giải pháp khác là sử dụng dịch vụ cục bộ. Có các dịch vụ "sở hữu" các đối tượng, với các hoạt động gọi API dịch vụ để có được bất cứ điều gì nó cần. Dịch vụ này cũng có thể chịu trách nhiệm tìm nạp và phân tích cú pháp dữ liệu, đóng gói bit logic đó.

Đối tượng Application là "bước con đầu đỏ" của các thành phần Android.Các thành viên của nhóm Android cốt lõi đã đi ngược lại việc thực hành tạo các lớp con tùy chỉnh Application, mặc dù nó chắc chắn được hỗ trợ bởi API. Đã thiết kế một ứng dụng ADC2 200 đã tận dụng một lớp con tùy chỉnh Application, tôi có thể nói rằng tôi nên đi cùng với một dịch vụ trong trường hợp của tôi. Sống và tìm hiểu ...

Bằng cách sử dụng mẫu liên kết cục bộ, dịch vụ của bạn sẽ tự động được tạo và hủy khi cần, vì vậy bạn không phải lo lắng về điều đó. Và, theo định nghĩa, một dịch vụ cục bộ chạy trong cùng một tiến trình/VM như các hoạt động của bạn, do đó bạn không cần phải lo lắng về chi phí đầu vào như bạn sẽ làm trong kịch bản ContentProvider.

+0

Vâng, tôi nghĩ tôi đang ở trong một chiếc thuyền tương tự. Bắt đầu làm mọi thứ trong Ứng dụng, và bây giờ một Dịch vụ trông giống như cách đi đúng đắn. Tôi sẽ điều tra tái cấu trúc tại một số điểm. Cảm ơn vì tiền hỗ trợ! – emmby

+0

Tôi cũng thích dịch vụ. Bạn có ý nghĩa gì bởi "sở hữu"? Bạn có lưu dữ liệu vào một đối tượng tĩnh trong dịch vụ không? Thông thường một dịch vụ sẽ phân tích dữ liệu và sau đó gửi dữ liệu đó trong một chương trình phát sóng, và sau đó một trình xử lý sẽ được sử dụng trong chuỗi giao diện người dùng để hiển thị dữ liệu hoặc bất kỳ thứ gì. Nhưng nếu tôi gọi lại dịch vụ, dịch vụ sẽ nhận lại dữ liệu đó ở đâu? Dữ liệu này có được lưu vào một đối tượng tĩnh trong dịch vụ không? Chúng tôi không muốn phân tích cú pháp JSON lần nữa .. –

1

Cách tôi xử lý việc này trong một trong các ứng dụng của tôi là tải dữ liệu xuống sau đó đẩy dữ liệu đó vào cơ sở dữ liệu. Bằng cách này, tôi không phải mang theo tất cả các vật thể xung quanh (trong đó, IIRC, mỗi lần ăn khoảng 1kb cho việc tạo đối tượng) và tôi có thể dễ dàng lấy dữ liệu mà tôi cần. Tôi không biết nếu điều này sẽ làm việc cho bạn, nhưng nó làm việc cho trường hợp sử dụng của tôi.

+0

Chúng tôi đã thử điều này ở công việc hiện tại của mình, nhưng ứng dụng vẫn bị treo và/hoặc bị lỗi khi chúng tôi cố gắng đọc hoặc lưu trữ dữ liệu vào cơ sở dữ liệu. Tôi đang cố gắng tránh xa cơ sở dữ liệu SQLite từ bây giờ ... –

0

Một cách tiếp cận khác là lưu đối tượng dữ liệu vào tệp tùy chọn được chia sẻ. Đó là cách chúng tôi triển khai một trong các ứng dụng của mình, nhưng tôi không thích cách tiếp cận đó vì có vẻ như quá chậm.

Thực hành mã hóa không tốt, nhưng cách nhanh nhất có thể là sử dụng dịch vụ để phân tích dữ liệu và lưu dữ liệu vào lớp tĩnh mà bạn có thể sử dụng trong suốt thời gian còn lại của ứng dụng.

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