Aplikacja na komórkę z Windows Phone 7.5

Kwiecień 28th, 2012

W wolnym czasie po godzinach bawię się pisząc program na komórkę z systemem Windows Phone 7.5. Sam jestem szczęśliwym posiadaczem Nokii Lumii 800 i całkiem naturalną konsekwencją tego, że jestem też programistą .NET, jest próba dostosowania jej do swoich potrzeb jak bardzo tylko się da…

Niniejszym przedstawiam Wam tutaj postępy moich poczynań na platformie mobilnej z systemem WP7. Konkretnie, to rozpocząłem pisanie aplikacji do zarządzania wydatkami w języku polskim! Oficjalna strona projektu, którego szumna nazwa brzmi „Wydatkomierz” dostępna jest razem z opisem i pełnymi kodami źródłowymi tutaj:

http://code.google.com/p/wydatkomierz/

Ikonka

Aplikacja wkrótce pojawi się w mobilnym sklepie Microsoftu i będzie dostępna do pobrania i używania dla wszystkich posiadaczy komórek z tym systemem za darmo;) I jeszcze długo będzie za darmo, bo wiele podstawowych rzeczy jest w niej do zrobienia w porównaniu z konkurencyjnymi rozdmuchanymi niekiedy aplikacjami w Marketplace w języku angielskim.

To co ma wyróżniać tę aplikację od innych, to przede wszystkim:
- polski interfejs (nie zauważyłem jak dotąd zbyt wiele ciekawych aplikacji w języku polskim)
- łatwość obsługi (na daną chwilę nie widzę potrzeby wykorzystywania przez większość użytkowników mechanizmów tak jak: cykliczne przelewy, przypomnienia o transakcjach, wybór różnego rodzaju kont itp. itd.)
- prostota prezentacji i analizy zapisywanych wydatków głównie pod kątem kategorii, do których należą

Chciałbym jednocześnie zaprosić wszystkich chętnych programistów, którzy chcieliby rozwijać się w stronę programowania aplikacji mobilnych, do dołączenia do rozwijania wyżej przedstawionej aplikacji! Każdy z Was będzie mile widziany. Zarówno Ci, którzy posiadają komórki z systemem WP7, ale i Ci, którym wystarczy pisanie na emulatorze;) Na stronie projektu w zakładce „Issues”:
http://code.google.com/p/wydatkomierz/issues/list
znajduje się już teraz szereg zadań i funkcjonalności, o które przydałoby się rozszerzyć obecną wersję aplikacji tak, aby jeszcze bardziej była przydatna zwykłym śmiertelnikom.

Wzorce projektowe – Abstract Factory

Sierpień 1st, 2011

Dzisiejszym tematem będzie…

ABSTRACT FACTORY, czyli Metoda fabrykująca

Cel:
Określenie interfejsu dla tworzenia obiektu z pozostawieniem podklasom decyzji o wyborze klasy tworzonego obiektu

Stosowalność:
Używamy go, gdy:
- Klasa nie jest w stanie przewidzieć klas obiektów, które musi tworzyć.
- Klasa chce, aby jej podklasy określały obiekty, które tworzy.
- Klasy delegują odpowiedzialność do jednej z kilku pomocniczych podklas i chcemy zlokalizować wiedzę o tym, która z tych podklas jest aktualnym delegatem.

Konsekwencje używania:
- Metody fabrykujące eliminują potrzebę umieszczania w kodzie klas specyficznych dla aplikacji.
- Potencjalna wada FM – klienci mogą być zmuszeni do specjalizowania klasy Twórcy tylko po to, żeby stworzyć szczególny Konkretny Produkt.
- Dostarczenie „wskazówek” podklasom
- Połączenie równoległych hierarchii klas

Diagram:

Wzorce projektowe – Chain of Responsibility

Lipiec 30th, 2011

Na łamach bloga przytoczę teraz pewną powtórzeniową dawkę wiedzy dla wszystkich absolwentów kursu wzorców projektowych na swoich studiach informatycznych (i nie tylko;). Ponieważ szczegółowych opisów wzorców (i antywzorców) projektowych w sieci jest dużo skupię się tutaj tylko i wyłącznie na kilku najistotniejszych sprawach – mianowicie na opisie celu wprowadzenia wzorca, opisie przypadków, w którym go używamy, konsekwencji jego zastosowania oraz przybliżającego sprawę diagramu UML. Dzisiejszy odcinek sponsoruje…

CHAIN OF RESPONSIBILITY, czyli łańcuch odpowiedzialności

Cel:

Uniknięcie sprzężenia nadawcy żądania z odbiorcą przez umożliwienie większej liczbie obiektów realizacji tego żądania. Obiekty odbiorcze są łączone w łańcuch, wzdłuż którego przekazywane jest żądanie do czasu, gdy któreś z ogniw je zrealizuje.

Stosowalność:

Używamy go, gdy:
- Więcej niż jeden obiekt może zrealizować żądanie, a odbiorca nie jest znany a priori (zatem powinien być ustalony automatycznie).
- Chcemy wysłać żądanie do jednego z pewnej liczby obiektów nie specyfikując jawnie odbiorcy.
- Zbiór obiektów mogących zrealizować żądanie ma być ustalony dynamicznie.

 Konsekwencje stosowania:

Zredukowane sprzężenie
- Dodatkowa elastyczność w rozdzieleniu odpowiedzialności pomiędzy obiekty
- Brak gwarancji obsłużenia żądania

Diagram: