Często w aplikacjach tworzonych na Windows Phone 7 posługujemy się ustawieniami aplikacji, dzięki czemu staje się ona bardziej przyjazna dla użytkownika. Służy do tego klasa IsolatedStorageSettings wraz ze słownikiem ApplicationSettings. Okazuje się jednak, że kod odpowiedzialny za ciągłe sprawdzanie zawartych w niej danych oraz ich rzutowanie na odpowiednie typy powtarza się w wielu miejscach. Przedstawiam zatem moje podejście, które stosuję w praktyczniej każdej aplikacji na WP7 i umieszczam je w klasie SettingsProvider.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | public class SettingsProvider { ... #region internal private static void SetValue(string key, T value) { if (IsolatedStorageSettings.ApplicationSettings.Contains(key)) { IsolatedStorageSettings.ApplicationSettings[key] = value; } else { IsolatedStorageSettings.ApplicationSettings.Add(key, value); } } private static T GetValueOrDefault(string key, T defaultValue) { if (IsolatedStorageSettings.ApplicationSettings.Contains(key)) { return (T)IsolatedStorageSettings.ApplicationSettings[key]; } else { IsolatedStorageSettings.ApplicationSettings.Add(key, defaultValue); return defaultValue; } } #endregion } |
Dzięki temu mogę w prosty sposób uwidocznić dla pozostałych komponentów projektu właściwości korzystające z przedstawionych powyżej metod generycznych. Na przykład w ten sposób:
1 2 3 4 5 | public string UserName { get { return GetValueOrDefault("UserName", ""); } set { SetValue("UserName", value); } } |
Mam nadzieję, że przedstawiony kawałek kodu przyda się wam do wygodniejszego i szybszego korzystania z ustawień aplikacji na Windows Phone
Przerobiłem kod, tak by był helperem. Wtedy może działać z każdym obiektem IsolatedStorage
https://gist.github.com/1798415
Moim zdaniem zwracanie domyślnej wartości jest nie-teges. Nie spodziewałem się, że trzeba podać defaultValue do funkcji. Spodziewałem raczej zwrócenia default(T). Tak jak to miejce np. w SingleOrDefault z System.Linq. http://msdn.microsoft.com/en-us/library/bb549274.aspx
PS: region internal wydaje mi się dosyć prywatny
PS2: Właśnie teraz się spostrzegłem że lepszy byłby helper korzystający z Directory
Celowo nie tworzyłem przedstawionego przez Ciebie helpera z dwóch powodów:
1 – nie chcę, żeby klasy w projekcie “wiedziały” w jaki sposób przechowuję ustawienia… Może się okazać, że będę korzystał nie z IsolatedStorage, a z bazy danych i co wtedy?
2 – jeżeli będę chciał uniknąć punktu 1, to muszę stworzyć kolejną klasę, która jest odpowiedzialna za “przykrycie” tego helpera, co w tym przypadku mam załatwione w jednym miejscu.
Jeżeli już coś zmieniać, to poszedłbym w stronę interfejsu ISettings wraz z jego implementacją.
Co do typu Detault(T), to nie mam możliwości przygotowania oczekiwanych przeze mnie ustawień początkowych… Dla stringa może to być wartość pusta, ale jeżeli będzie to na przykład jakiś klucz, lub niepusta wartość wówczas default(T) nie spełnia moich oczekiwań. Zaprezentowany przykład był bardzo prosty, ale nie trudno wyobrazić sobie bardziej złożonych danych zwracanych przez tą klasę… Stąd taki a nie inny jej wygląd
[…] […]
Keep up the great work , I read few blog posts on this website and I think that your web blog is really interesting and holds sets of wonderful info .