Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Nawet jeśli nie planujesz od razu dodawać funkcji systemu iOS 9 do aplikacji, należy ponownie skompilować aplikacje przy użyciu najnowszej wersji platformy Xamarin.
Ważne
Informacje na tej stronie są przeznaczone dla klientów z aplikacjami już w sklepie App Store przeznaczonym dla systemu iOS 8 lub starszego, którzy nie przesłali jeszcze aktualizacji pod kątem zgodności z systemem iOS 9. Jeśli używasz już najnowszych wersji — Xcode 7 i Xamarin.iOS 9 — na potrzeby tworzenia aplikacji odwiedź wprowadzenie do systemu iOS 9.
Gdy pojawiły się pierwsze wersje beta systemu iOS 9, zidentyfikowaliśmy dwa problemy ze starszymi wersjami platformy Xamarin, które manifestowane jako starsze aplikacje nie mogą uruchomić się w systemie iOS 9:
- Aplikacje tworzone dla systemu iOS 8 lub starszego nie mogą być uruchamiane na urządzeniach 32-bitowych (w tym na aplikacjach utworzonych za pomocą ujednoliconego interfejsu API).
- Błąd P/Invoke z pełną ścieżką nie jest określony.
Zaktualizowanie instalacji platformy Xamarin do najnowszej wersji stabilnego kanału, a następnie ponowne kompilowanie i ponowne wdrażanie aplikacji rozwiązuje te dwa problemy.
Nawet jeśli nie planujesz od razu zaktualizować aplikacji przy użyciu funkcji systemu iOS 9, zalecamy ponowne skompilowanie przy użyciu najnowszej wersji platformy Xamarin i ponowne przesłanie do sklepu App Store.
Dzięki temu aplikacja będzie działać w systemie iOS 9 po uaktualnieniu klientów. Można nadal obsługiwać system iOS 8 — ponowne kompilowanie przy użyciu najnowszej wersji nie ma wpływu na wersję docelową aplikacji.
Jeśli masz dalsze problemy podczas testowania istniejących aplikacji w systemie iOS 9, przeczytaj sekcję Poprawa zgodności poniżej.
Aktualizowanie przy użyciu programu Visual Studio
Zaleca się jawne sprawdzenie, czy program Visual Studio został zaktualizowany do najnowszej stabilnej wersji.
Co z składnikami, pakietami Nuget i innymi bibliotekami?
Nie musisz czekać na nowe wersje żadnych składników ani pakietów Nuget, których używasz, aby rozwiązać dwa problemy wymienione powyżej. Te problemy zostały rozwiązane po prostu przez ponowne kompilowanie aplikacji przy użyciu najnowszej stabilnej wersji platformy Xamarin.iOS.
Podobnie dostawcy składników i autorzy pakietów NuGet nie muszą przesyłać nowych kompilacji tylko w celu rozwiązania dwóch problemów wymienionych powyżej. Jeśli jednak jakiekolwiek składniki lub NuGet używa UICollectionView lub ładują widoki z plików Xib, może być wymagana aktualizacja, aby rozwiązać problemy ze zgodnością systemu iOS 9 wymienione poniżej.
Poprawianie zgodności w kodzie
Istnieje kilka przypadków wzorców kodu używanych do pracy w starszych wersjach systemu iOS powodujących niezgodność w systemie iOS 9. Poniżej przedstawiono niektóre możliwe problemy (i ich rozwiązania), które mogą wystąpić podczas testowania w systemie iOS 9:
UICollectionViewCell.ContentView ma wartość null w konstruktorach
Przyczyna: W systemie iOS 9 initWithFrame: konstruktor jest teraz wymagany ze względu na zmiany zachowania w systemie iOS 9 jako stany dokumentacji UICollectionView. Jeśli zarejestrowano klasę dla określonego identyfikatora i należy utworzyć nową komórkę, komórka zostanie zainicjowana przez wywołanie jej initWithFrame: metody.
Poprawka: Dodaj initWithFrame: konstruktor w następujący sposób:
[Export ("initWithFrame:")]
public YourCellClassName (CGRect frame) : base (frame)
{
Initialize (); // refactor initialize code into a method
}
Powiązane przykłady: MotionGraph, TextKitDemo
Element UIView nie może zainicjować kodu podczas ładowania widoku z elementu Xib/Nib
PrzyczynainitWithCoder:: Konstruktor jest wywoływany podczas ładowania widoku z pliku Xib konstruktora interfejsu. Jeśli ten konstruktor nie jest eksportowany, kod niezarządzany nie może wywołać naszej zarządzanej wersji. Wcześniej (np. w systemie iOS 8) IntPtr konstruktor został wywołany w celu zainicjowania widoku.
Poprawka: Utwórz i wyeksportuj initWithCoder: konstruktor w następujący sposób:
[Export ("initWithCoder:")]
public YourClassName (NSCoder coder) : base (coder)
{
Initialize (); // refactor initialize code into a method
}
Powiązany przykład: Czat
Komunikat Dyld: brak obrazu pamięci podręcznej o nazwie...
Może wystąpić awaria z następującymi informacjami w dzienniku:
Dyld Error Message:
Dyld Message: no cache image with name (/System/Library/PrivateFrameworks/JavaScriptCore.framework/JavaScriptCore)
Powód: Jest to usterka w natywnym konsolidatorze firmy Apple, która występuje, gdy upubliczniają prywatną strukturę (JavaScriptCore została upubliczniona w systemie iOS 7, wcześniej była to struktura prywatna), a celem wdrożenia aplikacji jest wersja systemu iOS, gdy platforma była prywatna. W tym przypadku konsolidator firmy Apple połączy się z prywatną wersją platformy zamiast wersji publicznej.
Poprawka: ta opcja zostanie usunięta dla systemu iOS 9, ale istnieje łatwe obejście, które można zastosować samodzielnie w międzyczasie: wystarczy wybrać późniejszą wersję systemu iOS w projekcie (w tym przypadku można wypróbować system iOS 7). Inne struktury mogą wykazywać podobne problemy, na przykład struktura WebKit została upubliczniona w systemie iOS 8 (a więc kierowanie do systemu iOS 7 spowoduje ten błąd; należy kierować system iOS 8 do korzystania z zestawu WebKit w aplikacji).