17/7/2020

Trước đây, tôi đã từng fork một phiên bản cải tiến từ UIWidgets để sử dụng riêng cho dự án UniLWP. Vào lúc đó, để có thể chạy ứng dụng nhanh nhất có thể, tôi đã phải loại bỏ tất cả các logic liên quan đến hệ thống môi trường và đầu vào, chẳng hạn như không có độ cao mặc định của NavigationBar hay StatusBar (trong Android, NavigationBar chỉ phần điều khiển phía dưới chứ không phải vùng trên cùng của UINavigationController trong iOS, cái mà trong Android gọi là AppBar). Ngoài ra, tôi cũng bỏ qua các yếu tố như Notch Cutout, Insets và hoàn toàn loại bỏ mọi xử lý liên quan đến bàn phím mềm. Gần đây, khi dự án hiện tại bước vào giai đoạn then chốt, tôi nhận ra cần phải triển khai chức năng nhập liệu văn bản. Quay lại xem xét logic của UIWidgets trước đây, tôi phát hiện rằng họ tự xây dựng một con trỏ (cursor), còn phần xử lý nhập liệu thì dựa vào một view nhỏ bé kích thước all slots chỉ 1px ở bên Native, sau đó truyền dữ liệu keydown vào Unity để tiếp tục xử lý. Mặc dù cách làm này khá hacky và có nhiều tình huống chưa lường trước được, nhưng trong mục đích thiết ty le ca cuoc hom nay kế ban đầu thì nó vẫn hoạt động được. Tuy nhiên, đối với UniLWP, nếu ở chế độ giấy dán tường, chúng ta chỉ có thể nhận được một SurfaceHolder từ Service, và không thể giả định rằng có bất kỳ View nào sẵn sàng chịu trách nhiệm xử lý sự kiện. Vì vấn đề này, tôi đã mất cả ngày để tìm cách khắc phục nhưng cuối cùng đành chấp nhận rằng không có giải pháp nhanh gọn nào cả. Hơn nữa, gần đây tôi lại đang thiếu kiên nhẫn cực kỳ, vì thế toàn bộ dự án tạm thời bị đình trệ. Điều này một lần nữa chứng minh rằng việc lựa chọn công nghệ đúng đắn là vô cùng quan trọng.

Sửa đổi lần cuối vào 2025-03-24