Điều này cuối cùng sẽ nhận được câu hỏi của bạn, nhưng trước tiên tôi muốn giải quyết một số vấn đề bạn nêu trong các nhận xét khác nhau của mình cho các câu trả lời khác nhau đã được đưa ra tại thời điểm viết bài này. Tôi không có ý định thay đổi suy nghĩ của bạn - thay vào đó, đây là những người đến để đọc bài đăng này trong tương lai.
Vấn đề là tôi không thể cho phép Android xác định khi nào ứng dụng của tôi sẽ bị chấm dứt. đó phải là sự lựa chọn của người dùng.
Hàng triệu người hoàn toàn hài lòng với mô hình nơi môi trường đóng ứng dụng khi cần thiết. Những người dùng đó đơn giản là không nghĩ đến việc "chấm dứt" ứng dụng Android, nhiều hơn họ nghĩ về việc "chấm dứt" một trang web hoặc "chấm dứt" một bộ điều chỉnh nhiệt.
Người dùng iPhone cũng giống như vậy, khi nhấn nút iPhone không nhất thiết phải "cảm thấy" như ứng dụng bị chấm dứt, vì nhiều ứng dụng iPhone chọn nơi người dùng rời đi, ngay cả khi ứng dụng thực sự bị tắt (chỉ dành cho iPhone cho phép một ứng dụng của bên thứ ba tại một thời điểm, hiện tại).
Như tôi đã nói ở trên, có rất nhiều thứ đang diễn ra trong ứng dụng của tôi (dữ liệu được PUSHed vào thiết bị, danh sách với các tác vụ luôn luôn phải có, v.v.).
Tôi không biết "danh sách với các nhiệm vụ luôn luôn phải có" nghĩa là gì, nhưng "dữ liệu được PUSHed cho thiết bị" là một viễn tưởng dễ chịu và không nên được thực hiện bởi một hoạt động trong mọi trường hợp. Sử dụng tác vụ theo lịch trình (thông qua AlarmManager) để cập nhật dữ liệu của bạn để có độ tin cậy tối đa.
Người dùng của chúng tôi đăng nhập và không thể làm điều đó mỗi khi họ nhận được một cuộc gọi điện thoại và Android quyết định hủy ứng dụng.
Có rất nhiều ứng dụng iPhone và Android giải quyết vấn đề này. Thông thường, đó là vì họ giữ thông tin đăng nhập, thay vì buộc người dùng đăng nhập mỗi lần theo cách thủ công.
Ví dụ: chúng tôi muốn kiểm tra cập nhật khi thoát khỏi ứng dụng
Đó là một lỗi trên bất kỳ hệ điều hành. Đối với tất cả những gì bạn biết, lý do ứng dụng của bạn bị "thoát" là do HĐH bị tắt, và sau đó quá trình cập nhật của bạn sẽ bị lỗi giữa dòng. Nói chung, đó không phải là một điều tốt. Kiểm tra cập nhật khi bắt đầu hoặc kiểm tra cập nhật hoàn toàn không đồng bộ (ví dụ: thông qua tác vụ theo lịch trình), không bao giờ thoát.
Một số ý kiến cho rằng nhấn nút quay lại hoàn toàn không giết ứng dụng (xem liên kết trong câu hỏi của tôi ở trên).
Nhấn nút BACK không "giết ứng dụng". Nó kết thúc hoạt động trên màn hình khi người dùng nhấn nút BACK.
Nó chỉ nên chấm dứt khi người dùng muốn chấm dứt nó - không bao giờ có bất kỳ cách nào khác. Nếu bạn không thể viết các ứng dụng hoạt động như vậy trong Android, thì tôi nghĩ rằng Android không thể được sử dụng để viết các ứng dụng thực sự = (
Sau đó, các ứng dụng web cũng không thể. Hoặc WebOS , nếu tôi hiểu chính xác mô hình của họ (chưa có cơ hội chơi với một mô hình nào). Trong tất cả những thứ đó, người dùng không "chấm dứt" bất cứ thứ gì - họ chỉ rời đi. iPhone hơi khác một chút, ở chỗ nó chỉ cho phép một thứ chạy tại một thời điểm (với một vài ngoại lệ), và do đó, hành động rời đi ngụ ý chấm dứt ứng dụng khá tức thời.
Có cách nào để tôi thực sự thoát khỏi ứng dụng?
Như mọi người khác đã nói với bạn, người dùng (thông qua BACK) hoặc mã của bạn (thông qua finish()) có thể đóng hoạt động hiện đang chạy của bạn. Người dùng thường không cần bất cứ điều gì khác, đối với các ứng dụng được viết chính xác, nhiều hơn họ cần tùy chọn "thoát" để sử dụng các ứng dụng Web.
Không có hai môi trường ứng dụng giống nhau, theo định nghĩa. Điều này có nghĩa là bạn có thể thấy xu hướng trong môi trường khi những cái mới phát sinh và những thứ khác bị chôn vùi.
Ví dụ, có một phong trào đang phát triển để cố gắng loại bỏ khái niệm "tập tin". Hầu hết các ứng dụng Web không bắt buộc người dùng nghĩ về các tệp. Các ứng dụng iPhone thường không bắt buộc người dùng phải nghĩ đến các tệp. Các ứng dụng Android thường không bắt buộc người dùng nghĩ về các tệp. Và như thế.
Tương tự, có một phong trào đang phát triển để cố gắng loại bỏ khái niệm "chấm dứt" một ứng dụng. Hầu hết các ứng dụng Web không buộc người dùng phải đăng xuất mà chỉ đăng xuất người dùng sau một thời gian không hoạt động. Điều tương tự với Android và ở mức độ thấp hơn là iPhone (và có thể là WebOS).
Điều này đòi hỏi nhấn mạnh hơn vào thiết kế ứng dụng, tập trung vào các mục tiêu kinh doanh và không gắn bó với một mô hình triển khai gắn liền với môi trường ứng dụng trước đó. Các nhà phát triển thiếu thời gian hoặc thiên hướng để làm điều này sẽ cảm thấy thất vọng với các môi trường mới hơn phá vỡ mô hình tinh thần hiện tại của họ. Đây không phải là lỗi của một trong hai môi trường, hơn cả đó là lỗi của một ngọn núi đối với những cơn bão chảy xung quanh nó chứ không phải qua nó.
Ví dụ: một số môi trường phát triển, như Hypercard và Smalltalk, có ứng dụng và các công cụ phát triển kết hợp trong một thiết lập. Khái niệm này không bắt kịp nhiều, ngoài các phần mở rộng ngôn ngữ cho các ứng dụng (ví dụ: VBA trong Excel , Lisp trong AutoCAD ). Do đó, các nhà phát triển đã đưa ra các mô hình tinh thần cho rằng sự tồn tại của các công cụ phát triển trong chính ứng dụng, do đó, phải thay đổi mô hình của họ hoặc giới hạn bản thân trong các môi trường nơi mô hình của họ đúng.
Vì vậy, khi bạn viết:
Cùng với những điều lộn xộn khác mà tôi phát hiện ra, tôi nghĩ rằng việc phát triển ứng dụng cho Android của chúng tôi sẽ không xảy ra.
Điều đó sẽ xuất hiện là tốt nhất, cho bạn, ngay bây giờ. Tương tự, tôi sẽ khuyên bạn không nên cố gắng chuyển ứng dụng của bạn lên Web, vì một số vấn đề tương tự bạn đã báo cáo với Android bạn cũng sẽ tìm thấy trong các ứng dụng Web (ví dụ: không có "chấm dứt"). Hoặc ngược lại, một ngày nào đó nếu bạn làm cổng ứng dụng của bạn lên Web, bạn có thể thấy rằng dòng chảy của ứng dụng Web có thể là một trận đấu tốt hơn dành cho Android, và bạn có thể xem lại một cổng Android tại thời điểm đó.