Các sai sót trong Ứng dụng toàn cầu

Biểu tượng thời gian đọc 4 phút đọc


Bạn đọc giúp đỡ ủng hộ MSpoweruser. Chúng tôi có thể nhận được hoa hồng nếu bạn mua thông qua các liên kết của chúng tôi. Biểu tượng chú giải công cụ

Đọc trang tiết lộ của chúng tôi để tìm hiểu cách bạn có thể giúp MSPoweruser duy trì nhóm biên tập Tìm hiểu thêm

Microsoft đã bắt đầu khuyến khích các nhà phát triển chuyển ứng dụng của họ sang ứng dụng Universal, tuy nhiên một số nhà phát triển vẫn chưa bị thuyết phục. Cách đây không lâu, tôi đã viết một bài xã luận trích dẫn các nhà phát triển về tính khả thi của các ứng dụng phổ quát và lý do tại sao chúng vẫn chưa khiến thế giới bùng cháy. Hôm nay, một nhà phát triển khác đã xuất bản một bài viết về trải nghiệm của anh ấy với các ứng dụng phổ quát (chúng tôi sẽ sao chép lại ở đây với sự cho phép)

 

Windows Phone 8.1 XAML và Universal Apps bao gồm các API WinRT có nhiều vấn đề, trong đó có một số vấn đề không có giải pháp. Nhưng trước tiên, chúng ta hãy nói về cái tên “Ứng dụng phổ thông”. Tôi nghĩ nó khá kiêu ngạo khi gọi phổ quát là thứ nhắm vào hai nền tảng, mà thực lòng mà nói thì không có nhiều người dùng sử dụng hoặc quan tâm. Ngoài ra, nếu bạn chỉ nghĩ về nền tảng Windows, những ứng dụng này cũng không phổ biến vì chúng không thể nhắm mục tiêu đến các phiên bản Windows được sử dụng phổ biến nhất (7 và XP). Nhưng tôi đang lạc đề.

Anh ấy đưa ra quan điểm ở đây, điều mà tôi đã đưa ra cách đây không lâu. Cả WP8.1 và W8.1 đều không cung cấp đủ giá trị để các nhà phát triển phát triển cho cả hai vì, như tôi đã nói “Người dùng Windows HAS, nhưng những người dùng đó không nhất thiết muốn có ứng dụng. Người dùng Windows Phone muốn có ứng dụng nhưng số lượng ứng dụng lại không nhiều”.

Tuy nhiên, người dùng không phải là yếu tố duy nhất ngăn cản các nhà phát triển chuyển sang ứng dụng WinPRT 8.1. Ngoài ra còn có các vấn đề kỹ thuật:

 

Nhiều API lộn xộn hơn

Vậy API phát âm thanh nền cho Windows Phone 8.1 bị lỗi, còn gì nữa không? Chắc chắn. BackgroundDownloader là một ví dụ khác. Trong Silverlight, có một BackgroundDownloader khá hạn chế nhưng nó vẫn hoạt động. Trong Universal Apps, có BackgroundDownloader mới với một số tính năng mới và thiếu một số tính năng thiết yếu. Ví dụ: trong Silverlight, mỗi lần tải xuống có thể có một Thẻ, nơi bạn có thể lưu trữ bất kỳ dữ liệu nào để bạn biết điều gì đó về quá trình tải xuống khi quá trình tải xuống hoàn tất (thuộc về thực thể kinh doanh nào, v.v.). Không còn nữa trong Ứng dụng phổ quát. Không có Thẻ, vì vậy bạn phải xây dựng và quản lý loại chỉ mục của riêng mình cho tất cả các lượt tải xuống, để bạn thực sự có thể kết hợp chúng với các thực thể kinh doanh của mình. Thật khó chịu, nhưng không có gì bạn không thể giải quyết được, phải không.

Một người bình luận trên blog cũng nói thêm rằng api Camera không tốt bằng Silverlight và tôi được biết rằng api 8.1 thiếu tích hợp ống kính.

API máy ảnh trên WP8.1 cũng cải tiến khủng khiếp. Không có cách nào để có được khung xem trước. Với API Silverlight, bạn có thể chỉ cần đăng ký một sự kiện và đẩy các khung hình có độ phân giải thấp thông qua ZXing ở nhiều khung hình/giây. Trong WinRT, điều tốt nhất bạn có thể làm là chụp nhiều bức ảnh khác nhau, đôi khi có đèn flash và quét khoảng 0.8 khung hình mỗi giây.

Hiệu suất cũng bị ảnh hưởng do khối lượng công việc cần thiết để cuộn mượt mà đã tăng lên trong 8.1 so với 8.0.

HIỆU QUẢ

Trong Silverlight, tôi thường sử dụng LongListSelector để hiển thị dữ liệu, sử dụng nó với WrapPanel khi tôi cần tạo bố cục hai cột. LongListSelector không còn nữa, trong Universal Apps bạn cũng phải sử dụng GridView trên Windows Phone. Hoặc bạn có thể sử dụng ListView với một bảng điều khiển tùy chỉnh mà bạn tự viết hoặc tải xuống ở đâu đó, nhưng phải mất một chút nỗ lực để làm cho nó ảo hóa đúng cách.

Vì vậy các bạn sử dụng GridView trên cả Windows Phone 8.1 và Windows 8.1 để thống nhất. Thêm hàng chục mục có hình ảnh vào đó và hiệu suất bắt đầu thực sự bị ảnh hưởng. Phần giữ chỗ màu xám sẽ xuất hiện và quan trọng hơn, không bao giờ biến mất. Bạn không cần sự kiện hình ảnh, chỉ cần thêm khoảng 300 mục văn bản vào GridView và phần giữ chỗ màu xám sẽ bắt đầu hiển thị khi cuộn

Mục đích của bài đăng này không phải là chỉ trích Microsoft mà là để giải thích lý do tại sao các nhà phát triển có thể chưa sẵn sàng tạo ra các ứng dụng phổ thông. Chúng không phải là một phương pháp hoàn toàn tốt hơn, chúng là một bản nâng cấp ở một số lĩnh vực và là sự hạ cấp ở những lĩnh vực khác (người dùng Windows Phone biết rõ cảm giác này). Nếu Microsoft muốn thu hút các nhà phát triển, họ cần phải làm việc nhanh hơn hiện tại, “sớm” và “trong những tháng tới” không hấp dẫn đối với những người có sinh kế phụ thuộc vào “sớm” là “ngày hôm qua”. Rất may, có những dấu hiệu cho thấy điều này có thể thay đổi. WP 8.1.1 mang đến một số api mới (mặc dù bị hạn chế) và 8.1.2 được cho là (trong một bài đăng hiện đã bị ẩn) cho phép các nhà phát triển tạo ra các ứng dụng tuyệt vời mới. Microsoft có thể sẽ thay đổi trong tương lai và điều đó thật tuyệt vời. Tuy nhiên, đối với nhiều nhà phát triển hiện đang bị áp lực phải tạo ra các ứng dụng phổ quát, tương lai không thể đến sớm được.

Để biết thêm thông tin bạn nhận được ở đây, hãy đọc toàn bộ phần tại đây. Đối với phần chi tiết hơn của tôi, xem tại đây.

Thông tin thêm về các chủ đề: phát triển, Ứng dụng toàn cầu, 10 cửa sổ

Bình luận

Chúng tôi sẽ không công khai email của bạn. Các ô đánh dấu * là bắt buộc *