Mała instrukcja dla wszystkich Adamów Słodowych: Jak tworzyć nowe cuda w SWF10.

Flex i jego item renderery to fajna sprawa, ale dzisiaj w robocie natrafiliśmy na niezłą zagwozdkę. Tak jak w przypadku check boxów nie ma problemu, żeby zmienić wartość aktualnego obiektu (dostęp poprzez właściwość data), tak w przypadku radio sprawy się komplikują. Każda lista może mieć aktualnie zaznaczony tylko jeden przycisk radio, wiadomo. Tak jak dużym problemem nie jest przekazanie do itemrenderera wspólnej grupy RadioButtonGroup, to sprawy komplikują się przy zarządzaniu kolekcją danych. Aktualny element przypisany item rendererowi możemy łatwo zmienić przy pomocy interfejsu IDataRenderer w następujący sposób: data.pole = wartość, ale kto zmieni poprzednio zaznaczoną? Ponieważ tu leżał główny problem.

W pracy mocno przekombinowałem z zewnętrznymi plikami klas, podczas gdy na spokojnie, w domu udało się to przepisać do jednego pliku MXML. Ok, może też trochę przegiąłem, bo trochę się tu kaszany zrobiło, ale tak jak w przypadku dwudziestopięcio linijkowej przeglądarki i tu chciałem upchnąć wszystko w jednym pliku, żeby można było łatwo stosować metodę kopiego-pejsta.

Przy okazji było to też małe ćwiczonko do inline'owych komponentów. Całkiem miłe to, chociaż trochę mniej wydajne, niż "prawdziwy" komponent we własnym pliku AS. Cały sekret leży w MXMLowym komponencie, który dziedziczy po RadioButtonGroup i nadpisuje jej metodę setSelection. Niestety jakoś nie mogę go zmusić do zobaczenia przestrzeni nazw mx_internal z frameworka, dlatego musiałem użyć "hacka":

Może ktoś ma lepszy pomysł? W każdym razie całość poniżej:

[Kod RadioButton ItemRenderer MXML w załączniku, bo jak zwykle się coś sra z kolorowaniem składni]

Przy okazji, gdyby okazało się , że przekombinowałem i da się to łatwiej zrobić to proszę o info na mejla, lub w komentarzu.

Jeśli pomimo terabajtowych dysków i wieloprocesorowych jednostek odbieracie instalację Flexa jako ciut ciężką, to łatwo można sie pozbyć 70MB z katalogu instalacyjnego. Wystarczy skasować folder jre i gotowe. Flex skorzysta wtedy z istniejącej w systemie instalacji Javy. U mnie jest to 1.6.0_1. Pewnie trzeba uważać, kiedy systemowa Java jest starsza niż ta dostarczana z Flex Builderem. Ale zakładam, że każdy pomyśli przed skasowaniem tego foldera, najpierw, na próbę zmieniając jego nazwę. Po zabiegu nie zauważyłem żadnych problemów z działaniem.

Jakiej wersji używa Flex Builder można dowiedzieć się z Help > Product Details > Configuration Details linijka: java.runtime.version=1.6.0_01-b06. Niestety Flash CS3 używa już tylko "wbudowanej" dystrybucji JRE. Jego usunięcie czy podmiana nie wchodzą w grę. Flash co prawda się odpali, ale jakakolwiek próba otworzenia panelu Actions spali na panewce. Aplikacja wypluje błąd inicjowania JRE i lipa.

Pojawił się pierwszy hotfix do fleksowego SDK. Nie wiem jak u innych, ale u mnie spowodował problemy z debagowaniem aplikacji Apollo. W razie co majkrosoftowe wyjście: deinstalacja i ponowna instalacja Apollo Extensions pomaga.

Gdy zachodzi potrzeba zastosowania tzw. komponentów inline, czasem występuje problem z dostepem do pól komponentu. Nie zawsze chcemy się odwoływać poprzez mojKompo.mojLabel.text, wygodniej byłoby skorzystać z właściwości get/set mojKompo.text. Oczywiście najłatwiej byłoby użyć tagu ddd i tam zdefiniować akcesory. Ale ja czuję parcie na szkło, więc użyje rozwiązania czysto bez-tag<mx:Script>'owego. Zamiast ustawiać "ręcznie", w kodzie można zastosować czyste bindowanie:

Tym sposobem możemy zupełnie ukryć implementację komponentu przed samym sobą (idealne dla schizorfeników!), ponieważ mx:Label nie potrzebuje juz pola id. A tak mniej więcej wyglądałaby MojaKlasa z małą pomocą ze strony AS:

Kobity dostały kwiatki (obywatelki IV RP pończoch nie dostają), a ja prezent dla prawdziwego faceta:

Aż chce się powiedzieć: "Uwielbiam zapach świeżej instrukcji o poranku".

Długo nie pisałem, więc dla dwóch osób parę słów wyjaśnień.

niechemisienawetwstawiacspacji

Generalnie stan taki utrzymuje się od świąt ;-). Jesienno-zimowa depresja, mimo braku tej drugiej pory, w powiązaniu z nadmiarem pracy owocuje nicniechceniem. Z rzeczy ciekawszych ostatnio siedzę w FMS. Przy porządnym frameworku client-side i mniej porządnym server-side da się w tym całkiem miło robić cuda na kiju. Jeśli ktoś jeszcze nie wie, to deweloperska wersja umożliwia korzystanie z serwera również komercyjnie do 10 połączeń. Mimo istnienia RED5, czy Wowza Media Server, mnie jakoś bardziej leży programowanie w tak zwanym server-side ActionScript, czyli w rzeczywistości jakiejś tam mutacji JS. Całe to javowanie, robienie durnych przelotek, rekompilacji, etc. na darmowych i mniej-płatnych alternatywach jakoś mnie nie jara. Owszem, jeśli ktoś chce "tylko" strumieniować media, to będzie w niebo, lub dwa wzięty. Ale to co moje, jest moje, co jara mnie, to przede wszystkim łatwe (czytaj szybkie) programowanie po stronie serwera.

A teraz parę słów o zamawianiu Flexa. Jak już pisał inou, czego niestety znaleźć nie mogę, jest problem z zamówieniem towaru w Polsce bezpośrednio ze sklepu Adobe. Zamówiliśmy więc towar u dealera. Czas oczekiwania jak na takie deficytowe i lukratywne cudo długi nie był - raptem pełen cykl kobiety. To co mnie i naszego sprzedawcę zdziwiło, to oświadczenie jakie musiała wypełnić moja firma. Na oświadczeniu o sposobie wykorzystania produktu, oprócz pełnych danych firmy (użytkownika produktu) i danych sprzedawcy trzeba było również wyjaśnić sposób użycia produktu i zobligować się do tego, czy produkt będzie wykorzystywany do przetwarzania i przesyłania informacji niejawnych. Całe szczęście e-learning, to nie teczki IPN, więc obyło się bez zaznaczania tego punktu. Jeśli jednak tak by było, dowiedziałem się, ze trzeba by było załatwiać dodatkowe papiery z MSW. Trochę sporo jak na program za 500$. W dodatku oparty o otwartoźródłowego Eclipse'a i darmowe SDK. Całe to zamieszane podczepione jest ponoć do:

art.21c ust.1 ustawy „o obrocie z zagranicą towarami, technologiami i usługami o znaczeniu strategicznym dla bezpieczeństwa państwa, a także dla utrzymania międzynarodowego pokoju i bezpieczeństwa oraz o zmianie niektórych ustaw” (Dz. U. z dnia 28 grudnia 2000 r.)

i brzmi groźnie ;-). W każdym razie pamiętajcie o zdjęciu turbana, przed zamówieniem. Jeśli ktoś zamawiał po nowym roku (ponoć w 2k6 nie było takich problemów) to prosiłbym o jakiś komentarz.

Jeśli chodzi o pięć faktów, to będą, kiedy będą. Muszę je najpierw stworzyć ;-).