Tại sao thật khó để làm cho một chương trình Java 'xuất hiện tự nhiên'?

Hầu hết các ứng dụng Java trông không giống với các ứng dụng C / C ++. Swing có thể được thiết kế nhằm mục đích có một cái nhìn khác biệt, nhưng dựa trên những gì tôi đã đọc, ví dụ SWT đã cố gắng 'nhìn bản địa', và không hoàn thành thành công.

Câu hỏi của tôi là:

Tại sao các nhà phát triển ngôn ngữ Java khó thiết kế một hệ thống GUI sao chép chính xác giao diện của GUI gốc? Có gì khác nhau trong GUI gốc? Có phải đó chỉ là vấn đề thiết kế các nút trông giống như các nút 'bản địa'? Hay nó đi sâu hơn thế?

Có phải đó chỉ là vấn đề thiết kế các nút trông giống như các nút 'bản địa'?

Vâng - sắp xếp, cho các nút. Nhưng điều này có thể khó hơn bạn tưởng tượng. Ngày nay, đồ họa được sử dụng để biểu diễn các thành phần GUI không đơn giản như các bitmap ngẫu nhiên được kéo dài (vì chúng không có tỷ lệ rất tốt) - chúng thường là đồ họa dựa trên vector với rất nhiều trường hợp góc được lập trình vào chúng ( do đó, khi nút chạm đến mép màn hình, ví dụ, nó có thể trông hơi khác.) Và tất nhiên, bạn sẽ cần đồ họa khác khi nhấp vào nút. Vì lý do bản quyền, các nhà phát triển thường không thể sử dụng hoàn toàn các đồ họa hiện có này, vì vậy chúng phải được tạo lại - và trong khi họ làm rất tốt phần lớn, chắc chắn một số thứ bị bỏ lỡ do các thành phần đồ họa khổng lồ ngoài kia.

Tôi đang nói tất cả những điều trên dựa trên Swing, tất nhiên đây là bộ công cụ GUI nhẹ, không bản địa. Bạn đặc biệt đề cập đến SWT không tìm kiếm bản địa, đó là một chút kỳ lạ, bởi vì SWT là bản địa. Đó là một bộ công cụ sử dụng JNI bên dưới để gọi các thành phần gốc - vì vậy nếu một cái gì đó không nhìn đúng ở đó, thì nó sẽ không phải là do giao diện.

Có khoảng nửa tá bộ công cụ có thể được coi là bản địa của bản thân trên một số hệ thống. Một số trong số này có các khái niệm hoặc khả năng khá độc đáo và việc sao chép chúng trong bộ công cụ đa nền tảng là tẻ nhạt. Giao diện của ứng dụng không chỉ được xác định bởi một làn da, mà còn về cách bố trí và cách ứng xử. Một số cân nhắc:

• Trong một hộp thoại, nút bên OK OK thuộc về phía nào - bên trái hay bên phải? Đủ công bằng, hãy xây dựng một hộp thoại riêng cho từng hệ thống.
• Làm thế nào để chúng ta đánh dấu nút mặc định trên màn hình? Tô màu, phông chữ đậm, mở rộng nút? Đủ công bằng, hãy đặt nó trong một bản định kiểu.
• Trên Windows, khái niệm Ribbon Ribbon còn khá tự nhiên. Làm thế nào điều này sẽ được dịch sang Mac, nơi Ribbon không phổ biến? Đủ công bằng, hãy quên bố cục chính xác pixel và cung cấp cách triển khai thanh công cụ khác nhau cho mỗi hệ thống.
• Là thanh phần menu của cửa sổ (Windows, tùy chọn KDE), hay nó nằm ở trên cùng của màn hình (Mac, Unity)? Đủ công bằng, hãy viết một triển khai khác nhau cho mỗi hệ thống, vì chúng ta đã vứt bỏ bố cục chính xác pixel
• Làm thế nào là các phông chữ được kết xuất? Càng sắc nét càng tốt, hoặc mịn màng và khử răng cưa? Và phông chữ nào nên được sử dụng? Lưu ý rằng các phông chữ khác nhau có các số liệu khác nhau, do đó, cùng một đoạn được hiển thị cho cùng một chiều rộng có thể có số lượng dòng khác nhau tùy thuộc vào phông chữ.
• Là nền của một cửa sổ là một màu, một hình ảnh hoặc một gradient? Chúng ta hãy đặt nó vào một bản định kiểu là tốt.
• Làm thế nào để thanh cuộn trông? Các nút ở đâu - nếu chúng có bất kỳ? Chúng rộng bao nhiêu, hoặc chúng chỉ được tiết lộ khi con trỏ di chuyển vào một khu vực nhất định?
• Làm thế nào để chúng tôi kết hợp các phối màu khác?
• Điều gì được mong đợi là có thể kéo được? Menu ngữ cảnh dự kiến ​​ở đâu?

Các vấn đề này không thể được giải quyết thông qua biểu định kiểu đơn giản khi chúng chạm vào hành vi hoặc bố cục chung của ứng dụng. Giải pháp thực sự duy nhất là viết lại ứng dụng cho từng hệ thống (do đó bỏ qua các lợi ích đa nền tảng của Java). Giải pháp thực tế duy nhất là quên đi bố cục chính xác pixel và ghi vào một giao diện chung trừu tượng hóa trên các bộ công cụ dành riêng cho hệ thống. Giải pháp được thực hiện bởi Swing là mô phỏng các hệ thống khác nhau, thất bại một cách ngoạn mục.

Và sau đó là tính nhất quán đa nền tảng, ý tưởng rằng ứng dụng của bạn có thể trông giống hệt nhau trên tất cả các hệ thống (thường được chọn bởi các trò chơi, trong đó điều này làm tăng sự đắm chìm). Trên các ứng dụng máy tính để bàn, điều này chỉ gây phiền nhiễu và phá vỡ sự mong đợi của người dùng.

Vâng, nó đi sâu hơn.

Xây dựng một nút trông giống như nút Windows hoặc OS X rất dễ dàng, khi bạn chỉ xây dựng nút này. Nhưng nút phải "hoạt động" như bản gốc, điều này có thể không dễ dàng: có thể có nhiều không gian hơn trong một phiên bản, nhưng không phải là phiên bản khác, có thể màu sắc phù hợp hơn với thiết kế của bạn trong phiên bản Windows, v.v.

Điều này được giải thích khi bạn có toàn bộ GUI: chương trình OS X trình bày nội dung của nó khác với chương trình Windows. Điều này bên cạnh không thể chụp trong một GUI - bạn sẽ cần hai GUI, nhưng không có nhiều ứng dụng tạo ra quá nhiều phiền phức. Thay vào đó, họ đang nhắm đến "trông ổn trên hầu hết các hệ thống" - điều này vẫn có vẻ hơi xa lạ, nhưng có thể sử dụng và dễ dàng hơn nhiều để phát triển.

Không khó để tạo một nút trông giống như nút OSX, hoặc nút Windows hoặc bất kỳ bộ công cụ nào khác. Nhưng hướng dẫn giao diện người dùng cho hầu hết các môi trường không đơn giản như những điều cơ bản của "đây là nút trông như thế nào". Có nhiều sự khác biệt tinh vi hơn, từ khoảng cách giữa các thành phần UI đến thứ tự các hành động nổi tiếng nhất định sẽ xuất hiện trong danh sách đến vị trí chính xác của hộp thoại Tùy chọn / Tùy chọn trong hệ thống menu. Người ta có thể tự động hóa các trường hợp phổ biến nhất cho các giao diện người dùng rất đơn giản, nhưng nhiều trường hợp nếu không phải hầu hết các tác vụ UI yêu cầu một liên lạc tốt hơn nhiều.

SWT đã cố gắng tự động hóa điều này ở một mức độ nào đó, và một lần nữa, nó lại phù hợp với các tác vụ UI đơn giản. Nhưng không có giải pháp một kích cỡ phù hợp cho tất cả, và vì vậy khi các UI trở nên phức tạp hơn, các phương thức cơ bản mà nó sử dụng bắt đầu sụp đổ. Nhìn chung có thể đưa nó trở lại phù hợp với công việc UI thủ công, nhưng đây không phải là điều mà hầu hết các lập trình viên có thể hoặc sẵn sàng làm cho tất cả các nền tảng.

Cách tiếp cận của Swing đối với điều này chỉ đơn giản là tránh những bộ công cụ bản địa bất cứ khi nào có thể. Nó không phải là bản địa, và nó không cố gắng trở thành: thay vào đó, nó cố gắng tạo ra thứ gì đó trông giống (gần như) cho dù nó được chạy ở đâu. Thay vì cố gắng (vô ích) để làm hài lòng tất cả mọi người, nó đã cố gắng làm hài lòng chính mình, và trong khi nó đã thành công như vậy, người ta có thể đặt câu hỏi về kết quả có hiệu quả như thế nào đối với cộng đồng người dùng rộng lớn hơn.

Có một sự đánh đổi giữa việc mong đợi ứng dụng của bạn trông tự nhiên nhất có thể trên mọi hệ thống và mong muốn ứng dụng của bạn hoạt động theo cùng một cách trên mỗi hệ thống. Không có lựa chọn "đúng".

Hơn nữa, ngay cả khi bạn chọn phía "nhìn tự nhiên", bạn có thể muốn bảo vệ người dùng bộ công cụ đồ họa của mình trước "các cải tiến" trong các thành phần gốc và API cơ bản có thể phá vỡ ứng dụng của họ một cách bất ngờ.

Đây là lý do tại sao một số nhà phát triển bộ công cụ GUI thích cung cấp các thành phần riêng bắt chước các thành phần gốc, nhưng cung cấp triển khai riêng. Mặt khác, việc phát triển một bộ công cụ GUI hoàn chỉnh về mặt chức năng là một nỗ lực đáng kể và những cân nhắc kinh tế có thể dẫn đến việc cắt giảm một vài khía cạnh.

Lưu ý rằng vấn đề này không cụ thể về Java, nhưng phải đối mặt với mọi công ty sản xuất bộ công cụ độc lập nền tảng.

Tất cả là do lịch sử.

Sun mong muốn tất cả các phần mềm Java hoạt động như nhau trên tất cả các máy.

Đối với phần mềm để xuất hiện bản gốc, nó phải hoạt động giống như các phần mềm khác trên hệ điều hành đã cho.

Sun đã làm mọi thứ trong khả năng của mình để làm cho việc viết phần mềm Java được tích hợp với HĐH trở nên khó khăn, vì bất kỳ sự tích hợp nào với HĐH sẽ khiến phần mềm hoạt động khác nhau trên mỗi HĐH.

Ngày nay, rất ít lập trình viên Java quan tâm đến bất cứ điều gì khác ngoài phần mềm dựa trên máy chủ web.

Sun đã giết Java trên máy tính để bàn bằng cách trục tất cả các lập trình viên sử dụng các hệ thống dựa trên java của Microsoft, do đó làm cho bất kỳ lập trình viên nào chọn Java trong những ngày đầu đều trông tệ.

Bất cứ ai viết phần mềm máy tính để bàn quan tâm đến sự xuất hiện của người bản xứ, người dân bản địa đã học cách đây không lâu để không sử dụng Java và các quan điểm của họ được củng cố mỗi khi họ sử dụng bất kỳ phần mềm Oracle nào.

Do đó, những ngày này, không có nhu cầu nào về việc xuất hiện bản gốc trên phần mềm máy tính để bàn của các lập trình viên Java.

Những gì bạn nghĩ là nativecác ứng dụng gốc thực sự làm việc của riêng mình trong khi các bộ công cụ như SWT tuân theo các tiêu chuẩn được công bố cho UI của HĐH đó. Vấn đề là không ai xây dựng các ứng dụng theo các tiêu chuẩn đó nên khi bạn kích hoạt ứng dụng Java. Nó dường như không phải là bản địa. Ví dụ, hầu hết tất cả các dự án của Microsoft (Office, Outlook, v.v.) không thể được sao chép trực quan bằng các điều khiển tiêu chuẩn của Windows.

Sẽ còn tệ hơn nữa khi cả Microsoft và Apple bổ sung các tính năng UI động cho nền tảng HĐH của họ. Cho phép các nhà phát triển giao diện / tạo kiểu cho ứng dụng của họ giống như cách các thiết kế web tạo kiểu cho các trang web.

Java trên nền tảng Android đang đi theo con đường này. Tạo các thành phần UI cho Android được xác định bằng XML với các kiểu có thể ghép được.

Java chưa bao giờ phổ biến như một nền tảng máy tính để bàn. Kết quả là những thay đổi trong ngành công nghiệp không được truyền xuống thời gian chạy máy tính để bàn. Không có đủ nhà phát triển sẵn sàng dành thời gian để khắc phục vấn đề.

Những hệ điều hành nào bạn muốn nhìn "mẹ đẻ" quá?

Bạn không thể là người bản địa của tất cả họ 100% thời gian.

SWT, vv là cách tiếp cận nỗ lực tốt nhất để trông giống như bản địa của tất cả chúng khi nó cần để đạt được một số thỏa hiệp .

Và trên thực tế, sự thỏa hiệp này bắt đầu ngày càng khó đạt được; không phải vì hệ điều hành, mà vì thiết bị đầu vào. Đối với màn hình cảm ứng, bạn thực sự phải thiết kế khác nhau, vì không có nút chuột phải. Do đó, bạn cần phải có chức năng tương tự khác.

Sẽ không bao giờ có nút ma thuật chuyển chức năng "trực giác" từ nút chuột phải sang chế độ khách, mà không cần bạn chỉ định mọi khía cạnh chi tiết cho mọi thiết bị đầu vào (tại thời điểm đó, bạn có nguồn gốc từ mọi nền tảng bạn đã xem xét, nhưng vẫn không -native cho bất kỳ bạn chưa xem xét).

Câu hỏi thực sự tốt. Tôi luôn tự hỏi về nó trong vài năm sau đó, tôi nghĩ rằng có một số lý do chính đáng đằng sau điều này, nhưng thực sự không có.

Tôi nghĩ rằng câu trả lời khá đơn giản và rất nhiều câu trả lời không thực sự đi sâu vào vấn đề.

Nếu ngôn ngữ của bạn cho phép vẽ piexel trên màn hình thì 100% có thể tạo khung gui dựa trên nó sẽ bắt chước các điều khiển biểu mẫu Windows trông & cảm nhận chính xác.

Do Java là nền tảng chéo nên hoàn toàn có thể đảm bảo rằng dựa trên giao diện người dùng loại hệ thống (Mac / Windows) thực tế sẽ chọn trông khác nhau trên cả hai nền tảng, phù hợp với kiểu nền tảng thời gian chạy.

Như bạn có thể thấy trong XAML, ví dụ UI có thể dễ dàng được trình bày dưới dạng và ngôn ngữ có cấu trúc rất chặt chẽ. Chọn các hành vi "bản địa" cũng có thể nếu có thời gian để làm điều này.

Vì vậy, có thể tạo khung GUI cho phép các nhà phát triển Java có được các ứng dụng trông giống như trên Mac và Windows.

Vì vậy, chúng ta đến với Swing, đó chỉ là một khung GUI ngoài vô số tiềm năng của các khung GUI có thể được tạo cho Java. Nó hoạt động như thế nào nó đã được lập trình, không tuân theo quy trình trên và bạn nhận được các ứng dụng trông kỳ lạ trên cả hai hệ thống. Đó là sự lựa chọn của các nhà phát triển Swing, không ai bắt họ phải làm điều này và hành xử theo cách đó.