Jakie są decyzje dotyczące dostępności typu dla konkretnej platformy?

Question

Po prostu zdecydowałem się grać z PCL i przekonwertowałem moją bibliotekę klasową na PCL.

Nic dziwnego, że nie można go zbudować, wykazując wiele błędów typu.

Ale tak naprawdę byłem zdezorientowany przez to, jakich typów nie ma.

CancelEventArgs klasa jest obsługiwana, ale CancelEventHandler nie jest.

Czy jest to zwykła szansa lub celowa decyzja o nieobejmowaniu określonego typu? Czy mogę wyodrębnić przydatne informacje na temat projektowania platform z faktu obecności lub absencji typu?

Pozwól mi wyjaśnić:

mogę zrozumieć przypadki, gdy zbyt platformy specyficzne koncepcje są usuwane.

Ale z PCL rzeczy nie są dla mnie oczywiste.

Przyzwyczaiłem się, że nie uważam się za mądrzejszego od innych, dlatego szukam wyraźnych powodów.

Ułatwienie migracji między platformami jest tak duże, jak to tylko możliwe. Jak mówi Eric Lippert, każda cecha musi być uzasadniona z punktu widzenia stosunku wartości do wydatków. Dlatego też albo zawyżam wartość zestawu dużych typów, albo nie doceniam trudności związanych z realizacją jego przenoszenia.

---

Co do konkretnych wydarzeń z systemem analizy kodu dał solidną poleca używać wersji genreic EventHandler<TEventArgs>

Inny podobny question.

Answer 1

To dość mechaniczny proces. Po prostu przecinaj zestaw typów dostępnych na każdej platformie wybranej dla projektu PCL. Usuń wszystkie typy, które nie są dostępne w jednym z celów. Pozostało ci tylko to, czego możesz użyć.

CancelEventHandler może wyglądać jak dziwne pominięcie, dopóki nie przyjrzysz się bliżej typowi. Ma atrybut, HostProtectionAttribute nie jest szeroko obsługiwany.

Tak więc PCL tylko pomaga uniknąć "oh strzelać!" moment, w którym bardzo zależy Ci na używaniu typu w bibliotece klas. Aby dowiedzieć się później, że nie możesz sprawić, aby twoja biblioteka działała na inny cel. To bardzo brzydkie, potencjalnie niszcząc wiele czasu poświęconego na pisanie i testowanie kodu. Poruszenie się o tym problemie może zaoszczędzić ogromnej ilości bólu i cierpienia.

Oczywiście to nie działa, gdy robisz to w niewłaściwy sposób, zamieniając zwykły projekt biblioteki klasowej w projekt PCL. To szybkie "oh strzelać!" I nie ma nic wspólnego z ograniczeniami w PCL, ale przynajmniej będziesz wiedział, na czym się skupić i uzyskać przyzwoite wrażenie, ile pracy jest przed tobą.

Answer 2

Omówię to nieco w sekcji "Dlaczego interfejsy API nie są przenośne" pod adresem this blog post.

Kiedy po raz pierwszy pracowaliśmy nad przenośnymi bibliotekami klas, platformy .NET 4, Silverlight i Windows Phone 7 zostały ukończone lub w większości zakończone, więc nie mogliśmy wprowadzić wielu zmian w celu obsługi bardziej przenośnych interfejsów API. Z .NET 4.5,.NET dla aplikacji Windows Store i Windows Phone 8, byliśmy w stanie zrobić znacznie więcej, aby wspierać PCL. Prawie wszystkie typy .NET w aplikacjach .NET dla Sklepu Windows są dostępne w komputerach PCL, które są przeznaczone dla aplikacji .NET 4.5 i .NET dla Sklepu Windows. Windows Phone 8 obsługuje również większość tych interfejsów API, a największą luką był HttpClient, który mamy filled with a NuGet package.

Zasadniczo, jeśli wybierzesz nowsze platformy, wiele innych typów będzie przenośnych, aw miarę upływu czasu powinno być coraz lepiej.