2011-09-17 5 views
5

Załączam pewną liczbę obrazów jako "Treść" w moim wdrożonym XAP for Mango.Jak wyliczyć obrazy zawarte w XAP jako "Treść"?

Chciałbym je wyliczyć w czasie wykonywania - czy jest jakikolwiek sposób to zrobić?

Próbowałem wyliczanie zasobów, takich jak:

foreach (string key in Application.Current.Resources.Keys) 
{ 
    Debug.WriteLine("Resource:" + key); 
} 

Ale obrazy nie są ujęte w wykazie. Próbowałem też używać osadzonych zasobów - ale to nie pomogło. Mogę czytać strumienie przy użyciu Application.GetResourceStream(uri), ale oczywiście muszę znać nazwy, aby to zrobić.

+0

Czy możesz wyjaśnić cel tego działania? –

+0

W tym konkretnym przypadku jest to około sto ikon, które chcę wstępnie zapisać w pamięci.Nie wiem, ale podejrzewam, że to pomoże w problemie z wydajnością, który widzę. W poprzednim przypadku (pochodna iron7), chciałem załadować katalog przy uruchamianiu skryptów ruby. W obu przypadkach mógłbym zakodować listy w C#, ale wolałbym tego uniknąć, jeśli jest jakiś sposób - byłoby wspaniale, gdybym mógł po prostu wyliczyć wszystko, co zostanie dodane do folderu) – Stuart

+0

Nie sądzę, że będziesz uzyskać znaczny wzrost wydajności od "wstępnego ładowania" ich. Posiadanie typu kompilacji do treści powinno być wystarczająco szybkie. Przynajmniej dotyczy to wszystkich moich aplikacji. –

Odpowiedz

1

Nie ma możliwości wyliczenia plików ustawionych jako "Treść".

Istnieje jednak sposób na wyliczanie plików w środowisku wykonawczym, jeśli ustawiono pliki jako "Osadzony zasób".

Oto w jaki sposób można to zrobić:

  1. Ustaw akcji Zbuduj swoich obrazach jak „resource wbudowanego”.
  2. Zastosowanie Assembly.GetCallingAssembly().GetManifestResourceNames() do wyliczać nazwiska zasobów
  3. Wpisz Assembly.GetCallingAssembly().GetManifestResourceStream(resName) uzyskać strumienie plików.

Oto kod:

public void Test() 
    { 
     foreach (String resName in GetResourcesNames()) 
     { 
      Stream s = GetStreamFromEmbeddedResource(resName); 
     } 
    } 

    string[] GetResourcesNames() 
    { 
     return Assembly.GetCallingAssembly().GetManifestResourceNames(); 
    } 

    Stream GetStreamFromEmbeddedResource(string resName) 
    { 
     return Assembly.GetCallingAssembly().GetManifestResourceStream(resName); 
    } 

EDIT: Jak Quetzalcoatl zauważyć, wadą tego rozwiązania jest to, że obrazy są osadzone w pliku DLL, więc jeśli duża ilość zdjęć, obciążenie app czas może przynieść trafienie.

+1

Tak, ale zapomniałeś powiedzieć OA, że coś, co sugerujesz, ma jeden duży negatywny wpływ: EmbeddedResource powoduje, że pliki otrzymują EMBEDDED do wynikowej biblioteki DLL. W "Treści" będą one umieszczane jako zwykłe pliki wraz z biblioteką DLL. Tak więc, jeśli zamienisz dużą objętość plików na "EmbeddedResource" - twoja biblioteka DLL znacznie się wydłuży, a czas uruchamiania ucierpi. Punkt użycia "Treści" powoduje, że moduł jest mniejszy! Chociaż nie ma sposobu na wyliczenie "zawartości" w WP7 z powodu ograniczeń bezpieczeństwa, możliwe jest wygenerowanie listy podczas procesu kompilacji i przeczytanie listy w czasie wykonywania. – quetzalcoatl

+0

Zgadza się, zredagowałem odpowiedź, aby podkreślić tę wadę. –

4

To nie jest interfejs API zapakowany w WP7, który pozwala ci wyliczyć zawartość Xap. Musisz znać nazwę elementów treści, zanim będziesz mógł je odzyskać.

Prawdopodobnie istnieje jakiś kod pływający gdzieś, który jest w stanie wywęszyć katalog Zip w XAP, ale zdecydowanie nie polecam. Zamiast tego umieść jakiś rozsądny zasób, taki jak plik Xml lub ResourceDictionary, który je wymienia.

4

Po znalezieniu żadnego praktycznego sposobu na odczytanie plików zawartości z XAP, buduję taką listę w czasie projektowania za pomocą T4.

Zobacz przykład w https://github.com/mrlacey/phonegap-wp7/blob/master/WP7Gap/WP7Gap/MainPage.xaml.cs

Wydaje właściwą drogę, jak:
a) Wolę budować listę raz w czasie projektowania, a nie na każdym telefonie, który potrzebuje kod.
i b) Nigdy nie powinienem budować XAP, nie mając pewności, jakie pliki i tak mam.

Dodatkowo jest to ręczny krok do ustawienia akcji kompilacji dla wszystkich takich plików, więc dodanie ręcznego kroku do "Uruchomienie narzędzia niestandardowego" raz dla każdej kompilacji nie jest dla mnie problemem.

+1

Wielki urywek, dzięki. – Echilon