31 października 2011

java.util.Objects w Java 7 ponownie - bardziej pouczający przykład?

1 komentarzy
Nie mogłem życzyć sobie lepszego komentarza do mojego ostatniego wpisu o java.util.Objects - java.util.Objects w Java 7. Michał Margiel zajrzał do mnie i nie zostawił suchej nitki na moim ostatnim przykładzie, którego celem było zademonstrowanie użycia nowej klasy java.util.Objects.

"Proponuje pozmieniać wszystkie Object.equals(a,b) na a==b lub a!=b (w zalezności od asercji).

Tak tak.. ten all-in-one-test za wiele nie pokazuje :)"

Chyba byłem tak podekscytowany spotkaniem java.util.Objects, że faktycznie rozum mi odjęło, żeby prezentować przykład, w którym zwykłe porównanie wystarczy (!) Kiedy pierwszy raz zobaczyłem komentarz Michała, nie wiedziałem, czy sobie żarty ze mnie robi, czy faktycznie całe piękno mojego przykładu poszło w zapomnienie. I stało się, po chwili wiedziałem, że owym przykładem mógłbym zrobić więcej krzywdy niż pomóc. Cóż, nadrabiam teraz wierząc, że co jak co, ale klasa java.util.Objects zapadnie już wszystkim w pamięci :)

Czy poniższy przykład oddaje użyteczność klasy java.util.Objects w Java 7? Czy widomo, dlaczego poprzednio zwykłe porównanie przez równość wystarczyło? Chętnie wytłumaczę.

Metody hashCode() oraz equals(Object) wygenerowałem przy użyciu funkcji Generate hashCode() and equals()... w Eclipse.
package pl.japila.java7;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertTrue;
import static org.junit.Assert.fail;

import java.util.Objects;

import org.junit.Test;

public class ObjectsTest {

 class Customer {
  String name;

  public Customer(String name) {
   this.name = name;
  }

  @Override
  public int hashCode() {
   final int prime = 31;
   int result = 1;
   result = prime * result + getOuterType().hashCode();
   result = prime * result + ((name == null) ? 0 : name.hashCode());
   return result;
  }

  @Override
  public boolean equals(Object obj) {
   if (this == obj)
    return true;
   if (obj == null)
    return false;
   if (getClass() != obj.getClass())
    return false;
   Customer other = (Customer) obj;
   if (!getOuterType().equals(other.getOuterType()))
    return false;
   if (name == null) {
    if (other.name != null)
     return false;
   } else if (!name.equals(other.name))
    return false;
   return true;
  }

  private ObjectsTest getOuterType() {
   return ObjectsTest.this;
  }
 }

 @Test
 public void testObjectsMethods() {

  Customer jacek = new Customer("Jacek");

  Customer klonJacka = new Customer("Jacek");

  assertTrue("Klon Jacka jest Jackiem", Objects.equals(jacek, klonJacka));
  assertFalse("Jacek nierówny swojemu klonowi", jacek == klonJacka);
 }

}
A dziękować wiemy komu. Najserdeczniejsze podziękowania Michał!

30 października 2011

java.util.Objects w Java 7

2 komentarzy
Jutro, w poniedziałek, 31.10 o 17:24 Maksymowi "stukną" 4 tygodnie! Chłopisko coraz bardziej roztropne i zaczynam zapominać pomału, że to jeszcze niemowlę. Podczas kąpieli przerzucam go w przód, tył, ale delikatnie, bo bardzo wrażliwy. Zauważyłem, że wystarczy zbyt gwałtownie wkładać do wanienki, a już zaczyna się krzywienie miny i krzyk. Na razie o płaczu nie ma mowy, ale potrafi krzyknąć, więc po co go denerwować i okolicę. Jak tak dalej pójdzie, zanim się obejrzę, a już będzie siadał.


On śpi, ja czytam i tak trafiłem dzisiaj na artykuł Guava's Objects Class: Equals, HashCode, and ToString, a w zasadzie kopię wpisu jako artykuł, w którym poznałem com.google.common.base.Objects z Google Guava oraz java.util.Objects z Java SE 7. Wspomina się w nim również o projekcie Apache Commons, w którym istnieją klasy, na których można oprzeć tworzenie metod toString() (klasa org.apache.commons.lang3.builder.ToStringBuilder), equals() (klasa org.apache.commons.lang3.builder.EqualsBuilder) oraz hashCode() (klasa org.apache.commons.lang3.builder.HashCodeBuilder). Co jednak zrobiło na mnie największe wrażenie, to fakt wciągnięcie ich odpowiedników do Java 7.

W ten sposób zwrócono moją uwagę na java.util.Objects.

Poniższa klasa testująca pokazuje działanie większości (poza jedną) metod java.util.Objects.
package pl.japila.java7;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertTrue;
import static org.junit.Assert.fail;

import java.util.Objects;

import org.junit.Test;

public class ObjectsTest {

 class Customer {
  String name;

  public Customer(String name) {
   this.name = name;
  }
 }

 @Test
 public void testObjectsMethods() {
  Customer jacek = new Customer("Jacek");
  Customer agatka = new Customer("Agatka");

  Customer[] customers = { jacek, agatka };

  assertTrue("Agatka jest Agatką", Objects.equals(agatka, agatka));
  assertFalse("Jacek nie jest Agatką", Objects.equals(jacek, agatka));
  assertFalse(Objects.deepEquals(customers, new Customer[0]));
  assertEquals(jacek.hashCode(), Objects.hashCode(jacek));
  assertEquals(0, Objects.hashCode(null));
  assertEquals("null", Objects.toString(null));

  final String nullDefaultToString = "mój toString()";
  assertEquals(nullDefaultToString, Objects.toString(null, nullDefaultToString));

  final String exceptionMsg = "Zostanie zgłoszony wyjątek NPE";
  try {
   Objects.requireNonNull(null, exceptionMsg);
   fail("Powinien zostać zgłoszony wyjątek NPE");
  } catch (NullPointerException npe) {
   assertEquals("Wyjątek jest oczekiwany", exceptionMsg, npe.getMessage());
  }
 }

}
Nie mniej zaskoczyło mnie bogactwo Apache Commons, kiedy przeczytałem komentarz Craig'a Ringer'a do wpisu JDK 7: The New Objects Class:

"I'd actually love to see much of Apache Commons Lang (and Apache Commons IO) pulled into Java. Certainly StringUtils (as static methods on String), IOUtils for the static stream copying methods, FileUtils, ObjectUtils (which sounds like the conceptual origin of much of the new Objects class), CompareToBuilder, HashCodeBuilder, EqualsBuilder, ToStringBuilder, ExceptionUtils.getRootCause as a method of Throwable, etc. The JDK has been focusing on adding huge new and fancy codebases, and really neglecting the usability of the core library."

Słyszałem o tej różnorodności, ale jakoś nie dane mi było spróbować jej. Wiedza uskrzydla, a praktyka pozwala utrzymać poziom, więc raz przeczytawszy (wchodząc na odpowiedni pułap przelotowy) należy przekuć wiedzę w czyn, aby...nie spaść (jak niejednokrotnie zwraca się uwagę w wątku CV po Warsjawa 2011 na forum Warszawskiego JUGa).

Nie pamiętam również, abym wiedział o istnieniu java.lang.String.isEmpty(), która pojawiła się w Java 6 (!) Teraz już wiem.

Przy okazji, Groovy importuje automatycznie klasy z java.util, więc i Objects (podobnie jak Java importuje java.lang).

21 października 2011

NIO2 w Java 7 i OCPJP 6 PrepKit od uCertify

0 komentarzy

NIO2 w Java 7

Na dzisiejszy dzień zaplanowałem recenzję drugiego rozdziału nowej książki z Packt o Java 7. Kiedy jeszcze wczoraj, przed zaśnięciem, przeczytałem JDK 7 Adoption Guide, dzisiejszy rozdział wydał mi się lekko nudny, jakby bez życia. Ciągle ten sam schemat przedstawiania nowości z Java 7 w postaci krótkich przepisów użycia i wałkowanie typów (klasy, enum i interfejs) z pakietu java.nio.file zwanego NIO2:
W całym tym analizowaniu i podsumowywaniu udało mi się wręcz wyłapać błąd w oficjalnym dokumencie od Oracle - we wspomnianym "JDK 7 Adoption Guide" w sekcji IO and NIO, w którym napisano (drugie zdanie):

"The previous mechanism, built around the java.io.File class, is still available, but the new mechanism, built around the java.nio.Path and java.nio.Files classes, offers more robust file I/O and much greater functionality."

Potrafisz znaleźć błąd? Nie?! Odpowiedź jest powyżej (niewprost) oraz na samym końcu tego wpisu.

NIO2 robi wrażenie swoim bogactwem. Przeglądając Java SE 7 API moje oko przyciągnęły poniższe interfejsy:
Aż się chce za nie wszystkie zabrać i skomponować aplikację!

W książce działanie poszczególnych klas prezentuje się z pomocą System.out, np.
Path path = Paths.get("/ścieżka/do/pliku/który/nie/istnieje.txt");
System.out.println("Czy plik istnieje? " + Files.exists(path));  // zwróci false
Bardzo mi się to nie podoba, bo dopiero wynik pokazuje, jaki jest efekt danej metody. Zaproponowałem użycie assert, aby już czytając kod było wiadomo, do czego nim zmierzamy. Powyższy kod mógłby być zaprezentowany tak:
Path path = Paths.get("/ścieżka/do/pliku/który/nie/istnieje.txt");
assert !!!Files.exists(path) : "Plik nie może istnieć";
albo nawet tak:
Path path = Paths.get("/ścieżka/do/pliku/który/nie/istnieje.txt");
assert Files.exists(path) == false : "Plik nie może istnieć";
Które z powyższych odpowiadałoby Twoim gustom? Znasz może ciekawsze podejścia prezentowania wyniku kodu?

OCPJP 6 PrepKit od uCertify

I jakby na życzenie, dostałem propozycję recenzji zestawów do testowania od uCertify:

"In the recent past, uCertify has launched a number of new PrepKits that might be helpful for your readers. I want one more review from you since your review will also help us in improving our products.

Please visit http://www.ucertify.com/download.html for the complete list of PrepKits and let me know the name/code of the PrepKit you would like to review."


Czy powinienem odmówić takiej propozycji?! Nie, co to, to nie! Dlaczegóż nie połączyć przyjemnego z pożytecznym? I tak zabrałem się za 1Z0-851: OCP Java SE 6 Programmer. Niestety, nie jest to zestaw testów ze znajomości Java 7, ale dogłębna znajomość Java 6 nie przeszkadza wcale poznawać nowszych wydań. A może przy okazji, uwierzę w swoje umiejętności i sprawdzę się przy Oracle Certified Professional, Java SE 6 Programmer? Najbardziej zależy mi na utrwaleniu wiedzy z java.util.concurrent. Tutaj zauważam u siebie największe braki.

A skoro o nich, to okazało się, że jest ich znacznie więcej.

Jeszcze przed pójściem do łóżka, zabrałem się za test oceniający mój poziom.


Jak widać na załączonym obrazku, nie najlepiej poszło, tzn. oblałem. Moje ego do tej pory nie może się pozbierać. Jeśli tego byłoby mało, można sprawdzić, w jakim obszarze poszło mi najgorzej. Wystarczy przełączyć widok na Summary report i wszystko jasne.


Tam, gdzie poszukuję największych wzrostów wiedzy, tj. przy java.util.concurrent mam 100%, ale powiedzmy, że 1 pytanie z tej kategorii niewielu powaliłoby. Zaskoczony byłem niemało wynikiem OO Concepts. Teraz jednak potrafię to łatwo wytłumaczyć - po prostu nie wiedziałem, jak odpowiadać na tego typu pytanie, które związane było z przykładami klas, które dziedziczą (relacja "is-a") lub realizują więcej interfejsów (wciąż "is-a"), albo posiadają atrybuty odpowiednich typów (relacja "has-a"). Wychodzi, że umiejętność zdawania testów jest również umiejętnością, której należy się nauczyć. Nauczka na przyszłość.

Test zajął mi 30 minut, co przy 15 pytaniach, również nie należy do chwalebnych osiągnięć. Praktyka, praktyka i jeszcze raz praktyka, panie Jacku! Pora przyjrzeć się, co tam w TomEE piszczy i przygotować przykładzik, który pozwoliłby mi na zapamiętanie tych wszystkich zmian w Java 7.

(uaktualniono po uwadze Marcina Molaka) Do zapamiętania: Pakiet java.nio istnieje, ale w nim nie istnieją typy java.nio.Path oraz java.nio.Files, jak wzmiankuje się w JDK 7 Adoption Guide - IO and NIO.

20 października 2011

Przygotowanie środowiska z Eclipse Indigo SR1 i Java 7

0 komentarzy
Zbyt wiele komputerów (stacji roboczych) może doprowadzić do lekkiego zamieszania w głowie i właśnie dzisiaj tego doświadczyłem.

Byłem przekonany, że nie tylko, że mam już zainstalowane Java SE 7, ale i zaktualizowanego Eclipse IDE do wersji Indigo SR1, które udostępnia wsparcie dla Java 7. Jakież było moje zdumienie, kiedy przypomniałem sobie, że tak mam, ale...nie na tym kompie (!)

Cóż było robić - chwila z aktualizacjami Eclipse IDE, aktualizacja Java 7 i można popróbować się z kilkoma przykładami. Nic wyrafinowanego - ot, takie małe przykładziki, których celem jest przyzwyczajenie mnie do zmian w składni i nowego API.

Java 7 na Mac OS X dostępna jest na stronie openjdk-osx-build. Instalacja przebiega niezwykle sprawnie, bo sprowadza się do przekopiowania pakietu do właściwego katalogu. Dalej? Zalecam lekturę na wspomnianej stronie.

Aktualizacja Eclipse przebiegła sprawnie. Wystarczy Help > Check for Updates i zatwierdzamy znalezione aktualizacje.


Można również pobrać najnowszą wersję ze strony http://eclipse.org/downloads/.

Na początku nie byłem pewien, czy oferowane aktualizacje dają mi SR1, ale kolejny ekran nie pozostawiał złudzeń - 3.7.1 to właśnie to, czego potrzebowałem.


Na koniec aktualizacji, restart Eclipse i upewnienie się, że aktualizacja dotarła poprawnie w About Eclipse.


Po uruchomieniu Eclipse na Java 7 w zakładce Configuration widnieje OpenJDK 1.7.0 jako środowisko uruchomieniowe.


Teraz jeszcze definicja Java SE 7 w Installed JREs...


...i możemy rozpocząć tworzenie projektów z Java SE 7.


Na MacOS X nie jest to wciąż trywialne, aby zestawić środowisko do pracy z Java 7, ale z pomocą stronki openjdk-osx-build jest zdecydowanie prościej.

Dla wzmocnienia swojej wiedzy o zmianach w Eclipse Indigo SR1 oraz Java 7 polecam dokument What's new for Java 7 oraz JDK 7 Adoption Guide. W kilka chwil można całkiem sporo się nauczyć i nabrać przynajmniej pobieżne rozeznanie w nich. Powodzenia!

18 października 2011

Pierwszy rozdział o Java 7 od Packt

0 komentarzy
Już kiedyś wspominałem o zbiegach okoliczności i nie inaczej mógłbym zacząć ten wpis.

Skontaktowało się ze mną wydawnictwo Packt Publishing z propozycją recenzji technicznej książki o Java 7. Jakby zadań było mało, od razu się zgodziłem, aby przy okazji, a może przede wszystkim, zacząć poznawać nowości Java 7. W końcu i tak miałem się za to zabrać, a zbiegło się to w czasie z moimi planami na dokończenie października w ten sposób, więc mogę i "machnąć" recenzję.

Przeczytałem pierwszy rozdział, w którym wypisano zmiany określane mianem Project Coin. Napisałem "wypisano", ponieważ, jak na 40 stron, to i tak za mało w nich rozważań o zaletach tych zmian, więc na "opisano" to zdecydowanie za mało. Jeśli jednak wziąć pod uwagę, że książka zakłada styl ala książka kucharska (ang. cookbook), gdzie wiemy co i jak zastosować, ale niekoniecznie dlaczego, to przyjmuję ten styl.

W Java 7, dzięki Coin, dostajemy następujące zmiany (cytując stronę Coin):
  • Strings in switch
  • Binary integral literals and underscores in numeric literals
  • Multi-catch and more precise rethrow
  • Improved type inference for generic instance creation (diamond)
  • try-with-resources statement
  • Simplified varargs method invocation
W trakcie poznawania zmian dodatkowo poznałem java.lang.AutoCloseable (przy okazji tego wpisu zauważyłem, że jest nowa szata javadoc!), @SafeVarargs, java.util.Currency (klasie dostępnej od Java 1.4!), typie byte (przysiągłbym, że gdyby mnie zapytać o niego, to miałbym wątpliwości, czy istniał wcześniej, mimo częstego stosowania ByteArrayInputStream - a jest od Java 1.1!), java.nio.file.Paths i wreszcie heap pollution.

Dla mnie najbardziej wartościową zmianą w składni języka jest "more precise rethrow". Resztę uważam za ciekawą - try-with-resources, czasami mniej - strings in switch, a nawet zbędną - underscores in numeric literals.

Pewnie wiele z tych zmian, gdyby zaproponowano je w innym języku, albo zachęcano nimi do niego, nie znalazłyby uznania, ale zmian w samej konstrukcji języka Java 7 pewnie ominąć się nie da i, nawet jeśli nie ja je użyję, to zapewne inni, których kod będę czytał.

Zachęcam do zapoznania się ze wskazanymi dokumentami (pod linkami), aby po trochu zaznajamiać się z nieuniknionym.

A czy Ty masz już okazję pracować z Java 7? Która ze zmian przypadła Ci do gustu? Co w Java 7 API zasługuje na szczególną uwagę?

17 października 2011

Podsumowanie warsztatów warsjawa 2011

6 komentarzy

O Maksymie na wstępie

Dzisiaj, o 17:24, Maksym ukończył 2 tygodnie życia i pracuje pod systemem, w którym nie wykryto jakichkolwiek "bugów". Zdrowiuteńki bobas. Na razie "uptime" optymalny i oscyluje wokół 3h - niestety, głównie w dzień. Czasami wymaga pomocy przy wejściu w stan "sleep", ale ogólne zachowanie poprawne. Wszystkie "testy zielone", a z każdym dniem użytkownicy coraz bardziej rozumieją zachowanie systemu. "Dział IT" w szpitalu na Madalińskiego wydał ocenę pozytywną i kontynuujemy zasilanie.


Wczoraj, w niedzielę, Maksym doświadczył przyjemności spaceru i po wczorajszych 20 minutach dzisiaj zaaplikowaliśmy "poprawkę" w postaci czterdziestominutowego spaceru. Wciąż bezawaryjne działanie Maksyma pozwala nam sądzić, że poprawka została wdrożona poprawnie. Jednym słowem - współpraca jest bardzo owocna. Bo to jest "Maksym i już!", czasami zwany Maksymiusz.


warsjawa 2011 - sobotnie spotkanie społeczności javowej


Kolejne wydarzenie polskiej społeczności javowej za nami. IV warszawskie warsztaty javowe warsjawa 2011 przyciągnęły 220 uczestników i udowodniły, że wciąż jest zapotrzebowanie na konferencje społecznościowe wokół Javy. Jeśli ktokolwiek wieszczy koniec jej popularności, to w Polsce nie ma to zastosowania. Tym razem zapóźnienie naszego kraju ma swoje dobre strony.

Z 4 osobami ze Szczecina i 1 z Łodzi można śmiało powiedzieć, że chociaż w części warsjawa zaoferowała ciekawą propozycję dla przyjezdnych i tym samym, nielicznie, ale zawsze, byliśmy ogólnopolscy. Chciałbym wierzyć, że było więcej osób spoza Warszawy niż wspomniane 5 osób. Żałuję, że nie mogę podzielić się bardziej precyzyjnymi danymi.

Aktualizacja z 18.10.2011: "Jak się okazało na dworcu ze Szczecina było co najmniej 6 osób." (źródło: Darek "ten od EGita" Łuksza)

Na razie pojawiły się jedynie pozytywne komentarze i, nieskromnie powiem, nie spodziewam się innych.

Poniżej wszystkie opinie, jakie udało mi się zebrać do tej pory.

Anna Małgorzata Mazińska napisała na forum WJUGa:

"Witajcie, chciałam podziękować organizatorom Warsjawy za ogarnięcie takiego fajnego eventu ;) tym razem przybyłam jako zwykły uczestnik, aby się trochę doedukować, ale udało się w przerwach między warsztatami pstryknąć trochę fotek : https://picasaweb.google.com/103530179614305430424/Warsjawa2011 (w galerii są fotki moje i Krzyśka)"

Piotr Zajączkowski na forum WJUGa:

"Dołączam się do podziękowań za zorganizowanie Warsjawy :) Było naprawdę bardzo miło i wyjątkowo merytorycznie (przynajmniej z mojego punktu widzenia ;) ). Szkoda tylko, że tak krótko - w takiej atmosferze to mogłoby trwać i kilka dni ;) hehe ;)
W każdym razie dziękuję jeszcze raz organizatorom, pomysłodawcom, prelegentom, sponsorom i uczestnikom - było super :)"


Michał Lewandowski na forum WJUGa:

"Też dołączam się do podziękowań dla tych którzy mieli swój udział w organizowaniu.
Atmosfera spotkania napawała chęcią do działania !
Żałuję tylko, że musiałem wyjść o 15:30, a dowiedziałem się potem, że pierwszy raz w życiu byłem wylosowany i wygrał bym coś pierwszy raz w życiu."


Krzysztof Nielepkowicz na forum WJUGa:

"Swietna konferencja i warsztaty! Mimo braku sieci na warsztatach GWT prowadzący (Paweł Cesar Sanjuan Szklarz) świetnie spobie poradził i repozytorium rozprowadził na gwizdkach :P Niby warsztat dla początkujących a sporo fajnych informacji o których nie piszą w książkach np kompilowanie wybranej permutacji czy pokazanie na czym naprawdę polega MVP :)"

I już w prywatnej korespondencji (dane osobowe znane redakcji):

"Dzięki za organizację eventów podczas których ludzie skupieni wokół wspólnych zainteresowań mogą się spotkać i podyskutować."

W skład komitetu organizacyjnego weszli:
  • Łukasz Lenart
  • Bartek Zdanowski
  • Marcin Zajączkowski
  • Tomasz Dziurko
  • Jacek Laskowski
  • Jakub Koperwas
  • Krzysztof Kozioł
Bardzo dziękuję za udział i zapał, aby poświęcić swój czas w kolejnej społecznościówce grupy Warszawa JUG!

Pojawiły się również zdjęcia z konferencji:
Chętnie uzupełnię galerię o kolejne zdjęcia. Proszę o przesyłanie namiarów na nie na jacek@japila.pl.

Organizator i prelegent w jednym - "Java EE 6 Web Profile z Apache TomEE"


Mój udział w konferencji polegał na jej organizacji, ale nie mogłem się oprzeć pokusie, aby nie wrócić na deski i zaprezentować niedawno ochrzczonego jako certyfikowany Apache TomEE w temacie "Java EE 6 Web Profile z Apache TomEE".

Uczestnikom mojego wystąpienia bardzo dziękuję, a wszystkim polecam zapoznanie się z moją prezentacją. Uwagi i sugestie ku usprawnieniu moich, kolejnych wystąpień w temacie Apache TomEE mile widziane.


Ze spotkania wyciągnąłem potrzebę nieutralnego przekazywania materiału na wybrany temat i mimo zaangażowania w rozwój Apache TomEE (na razie bardzo pasywnie) nie tracić z oczu celu nadrzędnego - prezentacja rozwiązania z uwypukleniem celów jego powstania. Bez tego leży każde wystąpienie, bo wiedza, jak zainstalować, czy uruchomić i stworzyć aplikację, to zdecydowanie za mało. Należy oczekiwać więcej i taki cel stawiam sobie na kolejne wystąpienia.

I tutaj kolejne postanowienie - wzbogacenie wiedzy branżowej. Nie wiem jeszcze, czy będzie to bankowość, telekomunikacja, czy ubezpieczenia, ale chociażby z jej podstawowym rozpoznaniem znacząco usprawni to nazewnictwo klas i słownictwo, którego będę używał do przedstawienia technologii. Tego typu prezentacje najbardziej lubię i bardzo mi ich brakuje w Polsce. Mam wrażenie, że można tutaj wiele zdziałać i znacząco podreperować poziom moich prezentacji. Nie mogę jednak znaleźć książek czy innych publikacji, w których mógłbym zapoznać się z jakimi problemami biznesowymi spotyka się dana branża, w których IT i jej "zabawki" mogłyby pomóc. Najbardziej interesują mnie procesy biznesowe, które są motorem napędowym systemów w branży. Coś ala sprzedaż, aktywacja, pozyskiwanie klienta i jego obsługa. Możesz coś zaproponować w temacie? Chciałbym móc nazywać moje aplikacje "Bank" zamiast "MyWebApp", albo "CustomerManagement" zamiast "HelloWorld". Zastanawiam się, czy taka publikacja w ogóle istenieje, a nie jest jedynie domeną osób, które siedzą w temacie?! W końcu i nieinformatykom udaje się w IT, więc dlaczego informatykowi nie miałoby się udać poza IT?! Pomożesz?

Na moje pytanie odnośnie mojego warsztatu prezentacyjnego i literackiego, tutaj na blogu i wiki, padły propozycje, aby na blogu prezentować tematy krótko i ze zrzutami ekranu, okraszone opisem problemów, na które napotykałem z ich rozwiązaniami (jeśli istnieją), a na Wiki publikować dłuższe wpisy, które aspirują do miana artykułów. To zgadza się z moim postrzeganiem tych narzędzi, więc wystarczy utrzymać postanowienia i będzie cacy. Dwóch zadowolonych czytelników, to w końcu lepiej niż żaden :)

14 października 2011

warsjawa i TomEE już jutro - Java EE 6 Web Profile z Apache TomEE o 16:15

0 komentarzy
Maksym to fajny gość. W poniedziałek stuknął mu tydzień i przeszedł pierwsze badanie kontrolne w szpitalu na Madalińskiego.


Jego poczucie humoru przerasta moje wyobrażenia i na propozycję uśmiechnięcia się do kamery zdecydował skwitować to...figą z makiem (!) No cóż, powiedzmy, że miałem zły dzień, a on dobrą zabawę (a może odwrotnie?! :))

W tę sobotę, 15 października jest warsjawa 2011, a na niej ja jako prelegent z tematem Java EE 6 Web Profile z Apache TomEE. Czym bliżej wystąpienia, tym więcej mam wątpliwości, co może zainteresować publikę. Przy takim natłoku certyfikowanych serwerów aplikacyjnych nie wystarczy jedynie pokazać, że działa, ale musi być w Apache TomEE to coś, co zachęci do jego dalszego poznania.

Możliwość użycia zestawu Java EE 6 Web Profile jest kusząca, ale tylko, jeśli idzie w parze z daleko posuniętą prostotą użycia. Podczas wystąpienia zaprezentuję działanie aplikacji demonstracyjnych dostarczanych w ramach NetBeans IDE 7.1 na TomEE.


Sprawdzimy również, jak to jest skonfigurować TomEE z bazą danych MySQL.

Ideą jest, aby zachęcić do dalszych, pewnie już samodzielnych prób z tym zestawem w zaciszu domowego kominka, a podczas wystąpienia będę miał godzinę, aby ten ogień rozpalić. Powinno być ciekawie.

13 października 2011

Już za dwa dni Warsjawa - zobaczcie co przygotowaliśmy!

0 komentarzy
W najbliższą sobotę, 15 października 2011, odbędą się IV warszawskie warsztaty javowe - warsjawa 2011. Przygotowaliśmy dla Was aż trzy ścieżki całodziennych warsztatów oraz dodatkową, warsztatowo-wykładową.

Wspólnie z naszymi szanownymi prelegentami przygotowaliśmy dla Was:
  • Warsztaty "Google Web Toolkit krok po kroku" Paweł Cesar Sanjuan Szklarz
  • Warsztaty "Meet my Android" Mateusz Grzechociński
  • Warsztaty z projektem Domain Driven Design i Command-query Responsibility Segregation Leaven - Sławek Sobótka i Rafał Jamróz
oraz w czwartej ścieżce:
  • "Obiektowa gimnastyka" Krzysztof Jelski i Paweł Lipiński
  • "WebSphere Application Server v8.0 + OSGi" Grzegorz Abramczyk
  • "Do czego jeszcze biblioteki testowe" Bartek Kuczyński
  • "Java EE 6 Web Profile z Apache TomEE" Jacek Laskowski
Jest to przedsięwzięcie całkowicie bezpłatne dla uczestników, ale nie pozbawione kosztów. Będzie pizza i będą nagrody do rozlosowania, a to wszystko dzięki naszym hojnym sponsorom (w kolejności alfabetycznej):
Bardzo im dziękujemy za wsparcie! Z przedstawicielami tych firm będzie można spotkać się w hallu i porozmawiać o możliwości zatrudnienia. Zachęcam do odwiedzenia ich stron, aby zademonstrować nasze podziękowanie za wsparcie.

Naszym Partnerem w tym roku jest Wydział Elektroniki i Technik Informacyjnych Politechniki Warszawskiej, który ugości nas w sobotę.

Zapraszam Was serdecznie w imieniu Komitetu Organizacyjnego i Warszawa JUG

12 października 2011

Focus & deliver - centrum rozwojowe Google w Warszawie otwarte

8 komentarzy
Kilka dni temu otrzymałem od Google (bez nazwisk tym razem) zaproszenie na "a small, informal gathering, during which you will be able to find out more about the office and the projects the engineers will be working on", które odbyło się właśnie dzisiaj na 10 piętrze Warsaw Financial Centre (ul. E. Plater 53 w Warszawie). Przy mojej obecnej sytuacji rodzinnej do końca nie byłem pewien, czy będę mógł w nim uczestniczyć i, z klauzulą potencjalnej nieobecności, przyjąłem zaproszenie.

Najciekawsze w tym było to, że "Apart from Kacper, you will hear from two speakers from Mountain View: Joshua Bloch and Walfredo Cirne." Joshua Bloch w Warszawie?! Nie mogłem przegapić tego spotkania. Nie byłem specjalnie napalony na możliwość zrobienia sobie z nim zdjęcia, zebrania podpisu, czy przyjacielskiego uścisku dłoni, ale możliwość spotkania go w nowootwieranym biurze inżynierskim Google nęciło. No i to indywidualne zaproszenie podkręciło moją ciekawość, aby zobaczyć, co też Google z Joshua przygotowali dla mas...miałem napisać...nas. Najbardziej zainteresowany byłem poznaniem ludzi, którzy będą tworzyli Google w Warszawie.

Jakież było moje zdumienie, kiedy na 10 piętrze spotkałem znajome twarze z wydziału MIM UW - pani doktor, pan doktor, o i pan profesor (miało być bez nazwisk i niech tak pozostanie). Było też kilka znajomych twarzy (z widzenia, nie z bezpośredniego kontaktu) z rynku. Pachniało jednak bardziej akademickim spotkaniem.

Spotkanie oficjalnie zaczęło się około kwadrans po 17:00. Zaczął Kacper - "the engineering director for the new office" Stonowany głos, przyjemny angielski, więc miło się go słuchało. Och gdybym tylko wiedział, jak zaraz po nim "Walfredo will talk about Cluster Management at Google." Kacper przedstawił cele nowego zespołu rozwojowego Google, z czego najbardziej utkwiło mi zdanie, że "they want to contribute and contributors" (czy jakoś podobnie). Ogólnie, zespół Google chciałby stać się częścią społeczności technicznej w Warszawie, tak by społeczność mogła skorzystać na tym, a i również sam Google. Obopólna praca na rzecz rozwoju obu stron. Pomysł podoba mi się, szczególnie, że ostatnimi czasy więcej w Warszawie grup użytkowników niż spotykających się, tj. jest komu organizować, ale nie ma komu przychodzić. Szczęśliwie nie dotyczy to bardzo prężnej grupy Warszawa JUG, która, jak mogłem dzisiaj przekonać się, liczy obecnie 542 użytkowników (!) Kawał światka warszawskiego. I jeszcze jedno zdanie Kacpra utkwiło mi w pamięci: "Focus & deliver". Ostatnio wiele rozważam nt. planowania, a później wypełniania postanowień i to zdanie wstrzeliło się w sam środek mojego dywagowania, ile jest we mnie pierwszego, a ile drugiego. Powiedzmy, że pracuję nad obiema rzeczami.

O Walfredo nie będę wspominał. Dałem radę, ale nie było warto. Nuda.

Ale moment, to zasługuje na uwagę. Już na sam koniec prezentacji, Walfredo został zapytany o udostępnianie wyników dotychczasowych osiągnięć w ramach dokumentów akademickich czy podobnie. I tu padło pamiętne: "We're too busy to write papers". Gość całkowicie powalił moje postrzeganie na wielkość Google jako firmy, w której i dla której dzielenie się wiedzą i inspirowanie do takiej aktywności jest w samym sercu zainteresowania. A tu taki klaps. Oniemiałem. Jakby na dokładkę, inny Googlers z zespołu Walfredo, zaproponował nawet tezę, że to nie jest skończone, więc nie pora na tego typu aktywności. To mną wstrznąsnęło. Z wielkiego Google zrobił się...Google. Czas magii firmy, która poświęca się dla społeczności prysł i pewnie trudno będzie się mi zebrać.

Mimo, że Walfredo przedstawiał tematykę Cluster management at Google z projektem Omega, które nie interesowało mnie całkowicie, to wychwyciłem ciekawe zdanie, z którym zgadzam się w zupełności "Not how but what - declare not implement - goals not ways". Jednak ja zastosowałbym to zdanie do programowania, chociażby ostatnich moich lekcji z Androidem. Programowanie na Androida z widokami opisanymi w XML, albo wszechobecne programowanie z adnotacjami czy funkcyjne jest właśnie tego przykładem. Jest to swego rodzaju realizacja zasady odwrócenia odpowiedzialności - typowy IoC. We wszystkich, wymagamy czegoś od środowiska i deklarujemy wymagania, które mogą być realizowane na różne sposoby, poniżej naszego poziomu percepcji i w ogóle zainteresowania. Wskazywanie na tego typu podejście było później również przedstawione przez Joshua w jego prezentacji "Performance Anxiety - Performance Analysis in the New Millennium", w którym wspomniał, aby "use high-level declarative construct", bo znajomość detali może zabić swoją złożonością i czasochłonnością.

A skoro o nim. Po przerwie na scenę wkroczył Joshua. Trudno mówić o scenie, bo siedzieliśmy w otwartym pomieszczeniu, zaraz przy wejściu, co niektórzy mogliby wręcz określić jako korytarz. Sceneria mi nie przeszkadzała i delektowałem się dwoma projektorami, które wyraźnie wyświetlały slajdy, a później i sam kod źródłowy w Aquamacsie (!) Sceny nie było, chyba, że podłogę można nią nazwać.

Do zapamiętania: "We can't be perfect", więc pewien poziom niedeterminizmu w JVM, systemu operacyjnego, procesora jest dozwolony i dobrze, abyśmy zdawali sobie z tego sprawę. Ja nie zdawałem i wyszedłem bogatszy. Prezentacja była bardzo żywiołowa i dynamiczna. Czasami miałem wrażenie, że to wyginanie się Joshua zmęczy go, ale, kiedy o 19:45 skończyliśmy część prezentacji i przeszliśmy delektować się przekąskami, nie zauważyłem zmęczenia, ani u niego, ani u słuchających. Obserwowałem Joshua pod kątem jego technik prezenterskich i kilka zamierzam wdrożyć na sobotniej warsjawie, kiedy to przedstawię "Java EE 6 Web Profile z Apache TomEE". Wtedy zamierzam po raz pierwszy zastosować kacprowe "Focus & deliver"!

Tej części bałem się najbardziej. Po części prezentacyjnej, przeszliśmy do przekąsek i napoi (w tym i piwa!) Wiele uczestników znała się, więc sądziłem, że powstaną grupki bardzo hermetyczne i rozmowy będą w zamkniętych gronach. Czy to miejsce, czy jedzenie, czy po prostu uczestnicy byli powodem, ale tak się nie stało. Jedzenie było smaczne, towarzystwo otwarte i rozgadane, więc pożegnałem się z uczestnikami dopiero około 21:00. Spotkanie bardzo przyjemne i z niecierpliwością czekam na kolejne.

A jeśli o kolejnych spotkaniach, to przypominam, że w najbliższą sobotę, 15 października odbędzie się konferencja warsjawa. Wszyscy są mile widziani, a na moją prezentację Apache TomEE zachęcam ze zdwojoną, co tam, strojonąpotrójną siłą.

Do soboty pozostało kilka dni, a już jutro spotkanie z Joshua Bloch w ramach "Google Tech Talks". Będzie Kacper, Joshua i Walfredo. Będzie tym samym możliwość skonfrontowania moich odczuć na prezentowane tematy. Z tego, co mi powiedziano na wydarzenie zapisało się 500 osób, co o tyle było dla mnie zdumiewające, że nic a nic nie wiedziałem o nim. Wciąż nie mogę nadziwić się, że przy aktywnej Warszawa JUG, śledzeniu twittera, blogów i w ogóle nasłuchiwaniu wszystkiego, co związane jest z Javą, nie udało mi się wychwycić tego wydarzenia. Skoro ja już o tym wiem, Ty również. Rejestracja dostępna jest na stronie Inżynierowie z Warszawy, spotkajmy się! Podobno miejsce nie wytrzyma takiego nawału zainteresowanych, więc rozważ dwa, a nawet trzy razy, zanim zapiszesz się na spotkanie z Goooooglers. Życzę miłego spotkania i zachęcam do aktywnego udziału.

10 października 2011

Apache TomEE w NetBeans IDE 7.1 - poprawka odnośnie nazwy serwera

0 komentarzy
Dzisiaj zarejestrowałem Maksyma w Urzędzie Stanu Cywilnego w Warszawie i już oficjalnie nazywa się Maksym Patryk Laskowski. Drugie imię ma po swoim starszym bracie, którego z kolei drugie imię to Jacek (pozostawiam jako zagadkę po kim). Za miesiąc "ukonstytuowanie" obywatela Maksyma, kiedy to zostanie mu przypisany numer PESEL. System już wie o jego istnieniu :)

Wczoraj pisałem, że jedyną możliwą nazwą dla serwera Apache Tomcat w NetBeans IDE 7.1 Beta może być "Apache Tomcat". Szczęśliwie nie musiałem długo czekać, aby przekonać się, że po prostu przeoczyłem pierwszy ekran w asystencie definiowania serwera.

Wybieramy zakładkę Services, a następnie menu Add Server... dla węzła Servers. Na pierwszym ekranie, u dołu, istnieje możliwość nadania własnej nazwy serwera.


Wystarczy nazwać ją "Apache TomEE" i wskazać na katalog, w którym rozpakowano TomEE. Proces konfiguracji nie powinien być obcy osobom pracującym wcześniej z Tomcatem, bo TomEE to z zewnątrz stary, poczciwy Tomcat (a jedynie bebechy są lekko "rozdęte" o funkcjonalność wymaganą przez Java EE 6 Web Profile, np. EJB 3.1 Lite czy JPA2).


Od tej pory mam swoje, wymarzone wsparcie narzędziowe dla TomEE (bez jakiejkolwiek zmiany w NetBeans IDE). To duża zaleta móc skorzystać z dobrodziejstw nowego narzędzia posługując się wiedzą z jego protoplasty.

Jakby na żądanie, pojawił się 13-minutowy filmik (chyba po portugalsku, ale język nie powinien przeszkadzać w zrozumieniu treści) prezentujący konfigurację i pracę z TomEE w NetBeans IDE - Apache TomEE e NetBeans 7. Dodatkowo polecam nagranie z prezentacji "Apache TomEE: Tomcat with a kick" z JAX London - Apache TomEE: Tomcat with a kick from David Blevins & Jonathan Gallimore @ JAX London part 1 of 2 oraz Apache TomEE: Tomcat with a kick from David Blevins & Jonathan Gallimore @ JAX London part 2 of 2.

Podczas nadchodzącej konferencji warsjawa 2011 w nadchodzącą sobotę, 15.10 w Warszawie będę miał możliwość zaprezentowania Apache TomEE w całej okazałości. Zapraszam!

09 października 2011

Apache TomEE w NetBeans IDE 7.1 - 2:1 dla błędów

13 komentarzy
Nie trzeba wielkiego umysłu, żeby wiedzieć, że w życiu kilkudniowego dziecka wszystko, co robi, określane jest jako pierwsze. Pierwszy raz pojawił się grymas na twarzy, który przypominał uśmiech, pierwsza noc w domu (i nadzieja, że będzie ją przesypiał spokojnie z 3 przerwami na jedzenie - nota bene, mimo, że dzieciak mógłby spać całą noc, to i tak po 3h będzie wybudzany na jedzenie!), pierwsza kąpiel w domu, pierwsze coś jeszcze innego i tak lista rośnie. Jak na razie Maksym dostarcza nam całą masę wrażeń. Jest ich tyle, że przy nadchodzącej zimie żadne mrozy nie są nam straszne. Maksym śpi regularnie, je i nie wpływa specjalnie na domowników swoją obecnością, a mimo to wszyscy chodzą jak nakręceni, szczególnie podekscytowani. Cudo dzieciaczek.

W sobotę, a chyba już i w piątek, postanowiłem popróbować się z Apache TomEE i NetBeans IDE 7.1. Oba produkty wciąż w fazie aktywnego rozwoju, więc można spodziewać się kilku, może nawet kilkunastu czknięć. Tych zawirowań jest o tyle mniej w przypadku Apache TomEE, na ile pozwala certyfikacja Java EE 6 Web Profile. Dla zwrócenia uwagi napiszę, że pod względem zgodności z Java EE 6 nie ustępuje miejsca JBoss AS 7.0.1 (!), a to uważam za niemałe osiągnięcie.

NetBeans IDE wspiera Apache Tomcat jako środowisko uruchomieniowe dla Java EE 6, a więc i Apache TomEE - w końcu to wzbogacony Apache Tomcat. Przy odrobinie szczęścia można pozwolić sobie na zestawienie środowiska programistycznego z oboma produktami. I tak faktycznie jest.

Wystarczy postępować zgodnie z wytycznymi asystenta do konfiguracji Apache Tomcat z tą różnicą, że katalogi wskazują na Apache TomEE i wszystko gra! Szkoda tylko, że nie można zmienić nazwy serwera na wybraną przez użytkownika, np. Apache TomEE lub podobnie.

Nie wiem, co mnie podkusiło, ale postanowiłem spróbować się ze zmiennymi środowiskowymi (ang. environment entries) i ich dostępem z servletu. To chyba było z powodu tego zdania na stronie TomEE:

"Any Tomcat provided resources, say from a context.xml, can be looked up or injected."

Tak, na pewno to było to. Stworzenie servletu w NetBeans to chwila. W międzyczasie pytanie o rejestrację servletu w web.xml, na które odpowiedziałem stanowczym nie, tj. zatwierdziłem domyślne ustawienie "Add information to deployment descriptor (web.xml)". Od wersji Servlet 3.0 deskryptor web.xml jest opcjonalny, więc po co mi to?!


I tu się zaczęło.

Najpierw trafiłem na brak wsparcia przez TomEE dla aplikacji webowych bez deskryptora web.xml. Zgłosiłem błąd TOMEE-27 UnknownModuleTypeException thrown when no-web.xml webapp deployed. Nie dawało mi to jednak spokoju i w trakcie sobotniego przesiadywania przed kompem, poprawiłem go. Taa, sam jestem pod niemałym wrażeniem, że zebrałem się w sobie i zrobiłem to.

Z poprawką uruchomienie servletu z adnotacją @WebServlet i bez deskryptora web.xml stało się możliwe. Ciekawe, jak mogło się stać, że nie wyłapał tego zestaw certyfikacyjny Java EE 6 Web Profile TCK?!

Na tym jednak nie koniec, bo głównym celem było dostanie się do zmiennej z context.xml (plik konfiguracyjny Tomcata, a tym samym i TomEE). Tutaj niestety nie mam dobrych wieści, bo wciąż nie ma wsparcia dla niej i pracuję nad TOMEE-28 Support for global environment entries (defined as in server.xml). Tym samym wynik niekorzystny dla poprawek na rzecz 2 błędów. Na dzisiaj 2:1 w starciu błędy kontra poprawki.

Całkiem przy okazji, natrafiłem na możliwość edycji server.xml z poziomu NetBeans - menu kontekstowe Edit server.xml dla serwera.


Jak dla mnie całkiem użyteczna rzecz i przydała się już kilkakrotnie.

07 października 2011

Czym jest Java EE 6 Web Profile?

1 komentarzy
Synuś Maksym jest już w domku i jeszcze nie wie, co oznacza "dać popalić" (oby tylko się w ogóle nie dowiedział o istnieniu czarnej strony mocy). W ogóle jakiś taki grzeczny - zdecydowanie za mało płacze. Żonka uśmiechnięta i cała w skowronkach, a starszaki - Iwetka i Patryś - rozkochane w braciszku. Sielanka, że nic tylko mieć kolejne dzieci.

Specyfikacja Java™ Platform, Enterprise Edition 6 (Java EE 6) Web Profile jest niezwykle strawnym dokumentem pod względem wielkości - jedynie 20 stron. Warto się z nim zapoznać, bo jest, jak to się wyrażono na stronie 2:

"Being the first profile of the Java EE 6 Platform to be defined, we expect the Web Profile specification to be used as a model for future profiles."

Możnaby powiedzieć, że profil webowy (ang. web profile) jest swoistą referencyjną implementacją dla profili w Java EE 6. Na pewno jest to jedyny znany profil Java EE 6 na chwilę obecną i celuje w określenie standardu tworzenia nowoczesnych aplikacji webowych (ang. modern web applications). Można się z tym zgadzać lub nie, ale trudno zaprzeczyć, że jest to próba nadgonienia^H^H^Hkrok ku uproszczeniu życia programistom i administratorom, którym potrzebna była jedynie specyfikacja Java Servlet 3.0 z dodatkami, a byli zmuszani do "taszczenia" pełnego środowiska Java EE - Apache Geronimo, JBoss AS, GlassFish - lub jedynie korzystali z Apache Tomcat i tworzyli z niego właściwe środowisko (czy to przez wzbogacanie pojedynczej aplikacji webowej, czy też całego serwera). Zamiarem Java EE 6 było ukrócenie tego "procederu" i wyjście na przeciw takim potrzebom. Życie zweryfikuje sensowność takiego działania.

W głównej specyfikacji Java EE 6 - Java™ Platform, Enterprise Edition (Java EE) Specification, v6 (rozdział EE.9, strona 201) możemy przeczytać na temat profili Java EE 6. Jest to jedynie wprowadzenie do mechanizmu ich definiowania i specyfiki działania, a szczegóły pozostawia się dedykowanym dokumentom, np. wspomnianemu Java™ Platform, Enterprise Edition 6 (Java EE 6) Web Profile Specification.

Profil Java EE jest zestawem (podzbiorem właściwym) specyfikacji Java EE, który spełnia wymagania danej klasy aplikacji (ale mi tutaj pachnie algebrą zbiorów i tylko czekać na przecięcia, pokrycia, algebry ilorazowe i temu podobne :]). W ten sposób można odchudzić środowisko uruchomieniowe - serwer aplikacyjny - tak, aby spełniał jedynie wybrane specyfikacje, np. certyfikacja JBoss Application Server 7.0 nie dotyczy pełnego wydania Java EE 6, a wyłącznie omawianego profilu webowego (patrz sekcja Strict Compliance na stronie JBoss AS 7).

W skład profilu webowego wchodzą następujące specyfikacje:
  • Java Servlet 3.0
  • JavaServer Pages (JSP) 2.2
  • Expression Language (EL) 2.2
  • Debugging Support for Other Languages (JSR-45) 1.0
  • Standard Tag Library for JavaServer Pages (JSTL) 1.2
  • JavaServer Faces (JSF) 2.0
  • Common Annotations for theJava Platform (JSR-250) 1.1
  • Enterprise JavaBeans (EJB) 3.1 Lite
  • Java Transaction API (JTA) 1.1
  • Java Persistence API (JPA) 2.0
  • Bean Validation 1.0
  • Managed Beans 1.0
  • Interceptors 1.1
  • Contexts and Dependency Injection for the Java EE Platform 1.0
  • Dependency Injection for Java 1.0
Oczywiście produkt wspierający dany profil może udostępniać znacznie szersze spektrum specyfikacji niż tylko te wymagane.

Na uwagę zasługuje fakt zawarcia EJB 3.1 w profilu, ale jedynie w jego wersji uproszczonej, zwanej EJB Lite (do omówienia w kolejnych wpisach).

Jedynym formatem aplikacji, które są wspierane przez środowiska wspierające profil webowy, jest moduł aplikacji webowej (WAR).

Poza wymaganiami opisanymi w dokumencie standaryzującym profil mamy jeszcze wymagania opisane w specyfikacji Java EE 6 - Java™ Platform, Enterprise Edition (Java EE) Specification, v6, które muszą zostać spełnione przez wszystkie profile Java EE 6 (patrz rozdział EE.9.5 Requirements for All Java EE Profiles, strona 203):
  • wsparcie dla adnotacji @Resource, @Resources, @PostConstruct oraz @PreDestroy
  • dostępny kontekst JNDI “java:” (jak opisano w sekcji EE.5.2, "JNDI Naming Context")
  • dostępność Java Transaction API (JTA)
Mam wrażenie, że nawet jeśli sama idea profilu nie przypadnie wielu osobom do gustu, bo to wciąż za ciężki zestaw, to wiele zespołów zdobędzie się na zastąpienie poczciwego Tomcata, Resina czy Jetty na jego wzbogacony odpowiednik realizujący Java EE 6 Web Profile. Wciąż będzie to produkt, który przechodzi wymogi specyfikacji Java EE 6 (tutaj ukłon w stronę sponsorów, którzy potrzebują tego typu glejtów), a jednocześnie skurczony do właściwych rozmiarów z kilkoma dodatkowymi specyfikacjami, które nie były dostępne z pudełka w popularnych kontenerach webowych (co powinno spodobać się programistom, bez zawirowań na styku z adminami).

Mam wrażenie, że z nadejściem profilu webowego w Java EE 6 zaprzestano promować ideę, że rozpoczynanie transakcji czy dostęp do bazy danych z poziomu aplikacji webowej jest nieodpowiednie - istnienie JPA 2.0 oraz JTA 1.1 przeczą temu.

A co Ty sądzisz o nowej specyfikacji Java EE 6 i jak to ktoś powiedział (nie mogę teraz znaleźć odnośnika do tego) "programowania adnotacjami"? Kiedyś był wszechobecny XML i jego wady i zalety znamy. Teraz są adnotacje i jest podobnie - są wady i zalety. Czy zalety Java EE 6 przesłaniają jego wady?

p.s. Java EE 6 to ona czy on, abym pisząc "jego wady" odnosił się do właściwej płci? :)

05 października 2011

Java EE 6 Web Profile z Apache TomEE na warsjawie 2011

0 komentarzy
Nie masz czasami uczucia, jakby wszystko, co czynisz w swoim życiu było już wcześniej ustalone? Mnie czasami nachodzi taka myśl.

Wczoraj pisałem o moich wątpliwościach czytelniczych i jakby na dokładkę dostałem dzisiaj elektroniczne wydanie Pro Android 2 z Apress. Nie ma więc już mowy o siedmiuset stronicowej cegle, którą muszę taszczyć ze sobą, aby móc ją czytać bez względu na miejsce i porę. Temat się rozwiązał, jakby za dotknięciem czarodziejskiej różdżki - wystarczyło napisać do wydawnictwa z prośbą o kopię i nie trzeba było długo czekać na odpowiedź. Ten temat mam rozwiązany.

To jednak nie koniec moich kłopotów z terminarzem na najbliższe dni.

Mogłem się przecież spodziewać, że konferencja JavaOne, która właśnie trwa w San Francisco, może zmienić moje plany na najbliższe 2 tygodnie z łatwością. A może to jednak nasza, lokalna warsjawa, która odbędzie się za 2 tygodnie, 15 października w Warszawie? Sądzę, że obie miały wpływ, ale to warsjawa faktycznie zmusiła mnie do zmian. Zaproponowałem temat "Java EE 6 Web Profile z Apache TomEE" na warsjawę i zostałem przyjęty (wierzę, że to merytoryczne przygotowanie prelegenta, a nie jego urok czy udział w zespole organizatorów konferencji sprawiło, że tak się stało).

Dla tych, którzy jeszcze nie doświadczyli Java EE 6 w okrojonej wersji profilu webowego będzie to doskonała okazja poznać temat, a głównym graczem będzie Apache TomEE, czyli stary, ale wciąż jary i powszechnie wykorzystywany do tworzenia aplikacji korporacyjnych Apache Tomcat wzbogacony o elementy wymagane przez Java EE 6 Web Profile, czyli:
  • Apache OpenEJB - kontener EJB 3.1
  • Apache OpenWebBeans - kontener CDI 1.0
  • Apache MyFaces - kontener JSF 2.0
  • Apache OpenJPA - kontener JPA 2.0
Wszystkie z wymienionych dostarczają składników potrzebnych do zbudowania korporacyjnej wersji Apache Tomcat i przejścia przez rygorystyczne wymogi TCK dla Java EE 6 Web Profile. Właśnie wczoraj Apache Software Foundation (ASF) ogłosiło w The Apache Software Foundation Announces Apache TomEE Certified as Java EE 6 Web Profile Compatible, że:
Apache TomEE has obtained certification as Java EE 6 Web Profile Compatible Implementation.
Po około roku wytężonej pracy zespołowi programistów z projektu Apache OpenEJB udało się przejść przez TCK i stanąć dumnie w szpalerze certyfikowanych środowisk spełniających wymagania stawiane przez specyfikację, obok takich tuzów jak Oracle GlassFish Server 3.x, Caucho Resin 4.0.17 i JBoss Application Server 7.

Podczas warsjawy 2011 zamierzam przedstawić cele i zalety użycia Apache TomEE z NetBeans IDE 7.1. Tym samym nie powinno być już żadnych złudzeń, o czym będę się rozpisywał na tym blogu przez kolejne 2 tygodnie - Java EE 6 Web Profile, Apache TomEE i NetBeans IDE.

Zachęcam do dzielenia się uwagami w komentarzach poniżej. Gdyby nękały Cię pytania związane z tematem, życzyłbym sobie poznać je już teraz, aby podczas konferencji być przygotowanym i odpowiedzieć na kilka. Przez godzinę i kwadrans mojej prezentacji należy oczekiwać kwadransu wprowadzenia, aby później przejść przez kilka przykładów demonstracyjnych. Do zobaczenia w sobotę w Warszawie.

04 października 2011

Październik z Java 7? Tylko, jak to praktycznie wykorzystać?

1 komentarzy
Czytanie książek technicznych zaczyna przypominać u mnie objawy nałogu. Uwielbiam czytać, a książki informatyczne wręcz pochłaniam. Przyczyna jest bardzo błaha - prostota w pozyskiwaniu wiedzy, a jeśli dodać do tego możliwość poprawienia języka obcego, to jedynie ciągłość tego "procederu" zaczyna mnie niepokoić. Podobnie jak z nałogiem.

Na początku, zwykle jest banalnie, od czasu do czasu. Później ma się wrażenie, że jest dokładnie tak samo - wciąż od czasu do czasu, a jedynie obserwatorzy zauważają, że owe "od czasu do czasu" skróciło się w czasie, tj. jest wciąż od czasu do czasu, ale częściej. Z książkami jest jakoś inaczej - nałóg jest akceptowalny mimo, że z definicji, z nałogiem należy walczyć (patrz pierwsze zdanie w definicji nałogu na Wikipedii). A może jest tak, że czytanie książek nie jest i nigdy nie może być nazwane nałogiem. A więc jak?

W czytaniu książek cenię sobie ułożenie wiedzy, skompletowanie jej w jednym miejscu i różnorodny format - na urządzenia mobilne (epub czy mobi) lub po prostu stary, dobry PDF, albo tradycyjnie - druk. Z ostatnim, moim zakupem Samsung Galaxy S2 dostęp do książek jest jeszcze powszechniejszy - mam je ze sobą wszędzie. Kiedyś chodziłem z jedną pod pachą i było to dosyć uciążliwe, ale teraz mam je zawsze pod ręką. Jestem zachwycony i moja żona jest zachwycona (wyjazdy na zakupy są dla mnie po prostu zaproszeniem do lektury), i dzieciaki też skaczą z radości, bo ojciec przestał marudzić, że "shopping" to już nie marnotrastwo czasu. To chyba nazbyt różowo, co?

I w zasadzie nie byłoby w tym nic nadzwyczajnego, bo każdy z nas ma swoje przywary, więc i moje uzależnienie od czytania można potraktować jak jedno, a skoro to czytanie, to nawet nie jest powszechnie traktowane w tej kategorii (paradoks?), gdyby nie fakt, że dzisiaj dotarła do mnie książka - "Java The Complete Reference", 8th Edition autorstwa Herberta Schildt'a z McGraw-Hill.

Kilka dni temu skończyłem czytać "Hello, Android", wydanie 3 i zaplanowałem sobie, i to właśnie dzisiaj, że zabiorę się za "Pro Android 2" z Apress. Cegła ogromna, bo ponad 700 stron, a mam ją w tradycyjnej postaci - drukowaną, więc taszczenie jej nie uśmiechało mi się zbytnio. Cóż jednak było robić - chce się wiedzieć więcej, to trzeba czasami pocierpieć - Android wciągnął mnie i zamiast samodzielnie rozpracowywać tematy (przynajmniej te początkowe, z którymi na pewno musiałbym się zmierzyć), wolałem postawić na przeczytanie książki. Teraz jednak, z "Java The Complete Reference" o Java 7 i nadchodzącym spotkaniu Warszawa JUG o niej, mam nielada problem. Przypomina mi się historia z osiołkiem i żłobem.

Z jednej strony chciałbym liznąć trochę tych nowości z Java 7 (skoro liznąć i wcześniej osioł to na myśl przychodzi mi scena ze Shreka, w której osioł chciał tylko liznąć gofra - patrz 0:30 w Shrek 4 Polski zwiastun HD), a z drugiej wiem, że nie dane mi z nich skorzystać w najbliższej przyszłości - powiedzmy jeszcze w tym roku. I to mnie właśnie zniechęca. Z trzeciej strony, ucząc się o Java 7 zgłębiałbym niuanse poprzednich wersji, bo nowe zwykle kontrastowane jest ze starym. Jeśli jednak miałbym postawić na inny temat niż Android w tym miesiącu, to byłaby to z pewnością tematyka Java EE 6 z IBM WebSphere Application Server 8. Skoro nie ma ciekawej pozycji książkowej na ten temat, nie mam wyboru i pozostanę jeszcze na dłuższy moment przy Androidzie. Takie wybory lubię najbardziej!

A jak to jest z Twoimi decyzjami - wybierasz książkę, czy raczej samodzielne zmagania z danym tematem z Google pod ręką. Dlaczego nie książka? I w końcu, czy masz już do czynienia z Java 7 produkcyjnie w projekcie? Zamieniam się w słuch.

03 października 2011

Maksym jest już z nami!

17 komentarzy
Dzisiaj o godzinie 17:24 w szpitalu na Madalińskiego w Warszawie urodził się mój syn Maksym. Poród przebiegł wyjątkowo sprawnie tak, że ledwo zdążyliśmy na porodówkę. Wszystkim mamom gratuluję, a mojej Agatce szczególnie.


Długość: 60 cm, waga: 3775 g i z każdą minutą coooooraz większy.

p.s. Z trójką dzieciaków łatwiej będzie przygotowywać dema aplikacji, bo i imion więcej do listy rozwijalnej czy pola wyboru :)

02 października 2011

Zapiski z czwartej części "Hello, Android" - "Next Generation" i piątej "Appendixes"

0 komentarzy
To już miesiąc od kiedy zadeklarowałem poświęcić swój czas na poznanie Androida i na sam koniec androidowego września, który zacząłem od wpisu Wrześniowy Android, skończyłem czytanie książki "Hello, Android", wydanie 3.

W tym wpisie przedstawię zapiski z czwartej części książki - "Next Generation" oraz części piątej "Appendixes".

Zapiski z poprzednich części książki "Hello, Android" znajdziesz we wpisach:

Ekrany dotykowe ze wsparciem wielopalcowych gestów


Tak, przynaję, że użycie słowa "wielopalcowych" (zamiast "wielodotykowych") może budzić swego rodzaju "podziw", że mogło mi to przyjść w ogóle do głowy, ale preferuję takie tłumaczenie, bo oddaje ich źródło powstania przez użycie wielu palców, co niekoniecznie może oznaczać, że dotknięć, które pojedynczy palec również może być źródłem, np. podwójne puknięcie. Gdyby ktoś jednak zechciał uzasadnić mój błąd, byłbym niezmiernie wdzięczny.

Rozdział 11. "Multi-touch" omawia zdarzenia generowane przez więcej niż jeden palec.

Wyróżniono gesty związane z jednym palcem: stuknięcie (ang. tap) oraz przesuwanie (ang. drag), np. przy przewijaniu.

Popularność iPhone wymusiła na dostawcach urządzeń z Androidem wsparcie gestów wielopalcowych, np. skalowanie (ang. pinch zoom), tj. zbliżanie lub oddalanie dwóch palców na ekranie w celu zmniejszenia lub zwiększenia treści pod nimi.

Nowa klasa android.view.ScaleGestureDetector do skalowania w Android 2.2.

Autor przedstawia stworzenie prostej przeglądarki obrazków do wyjaśnienia obsługi gestów.

Pojawiły się klasy android.view.MotionEvent, android.view.View.OnTouchListener, android.widget.ImageView, android.util.FloatMath, android.widget.FrameLayout z @drawable oraz android:scaleType="matrix" w pliku układu. Ich znajomość zdaje się być kluczowa do napisania własnych aplikacji, które udostępniają tego rodzaju interakcję z użytkownikiem.

@drawable wskazuje na dowolny JPG lub PNG z res, pewnie najczęściej z podkatalogu drawable-nodpi (trochę więcej o tym poniżej).

android:scaleType="matrix" - macierz do zmiany położenia (przesuwanie) i skalowania obrazka - za pomocą macierzy możemy wyrazić dowolne przekształcenie (i znowu wracam do macierzy, które niekoniecznie przypadły mi do gustu na studiach).

Pojawiają się również klasy android.graphics.Matrix (głównie metody Matrix.set() oraz Matrix.postTranslate()), android.graphics.PointF oraz użycie metody ImageView.setImageMatrix(matrix). Odnotowane do dalszego rozpoznania.

W trakcie czytania tego rozdziału, doświadczam tego błogiego stanu, w którym poznawanie urządzenia odbywa się przez poznawanie możliwości jego oprogramowywania, czyli kontrolowania na niższym niż na poziomie końcowego użytkownika (aczkolwiek wciąż nie tak nisko jak na poziomie systemu operacyjnego, poniżej poziomu Dalvik VM). Jestem zdania, że to właśnie programiści mają tę przewagę nad końcowymi użytkownikami lub administratorami (którzy również są swego rodzaju końcowymi użytkownikami produktu), że wiedzą jak i dlaczego dana cecha tak działa, a nie tylko jak.

W tym samym momencie, mój syn przerabia na matematyce (3 klasa gimnazjum) pojęcie podobieństwa trójkątów, w którym termin "skala" jest fundamentalne. Mimo, że takie proste na pierwszy rzut oka, to i tak zaskoczyła mnie łatwość wyliczania skali powiększenia/pomniejszenia obrazka za pomocą przyrównania wyjściowej odległości do bieżącej (nowej). To są te chwile, w których stwierdzam, że trzeba było uważać na lekcjach matematyki, kiedy i tak należało siedzieć w sali i trawić, co podaje wykładowca. Zakładam przy tym, że Ci, którzy uczą, robią to właściwie i z należytym zaangażowaniem.

UWAGA: Nie wszystkie urządzenia androidowe mają wsparcie sprzętowe dla obsługi równań z użyciem typu float i częste ich użycie może znacząco wpływać na prędkość działania aplikacji.

UWAGA: W książce zwrócono również uwagę na odśmiecacz (GC) w Javie i aby niepotrzebnie nie tworzyć nowych obiektów, które za moment trafią do kosza i wydłuży działanie GC, wykorzystuje się ten sam obiekt zmieniając jego stan. Tutaj Clojure, który wymusza programowanie z krótkotrwałymi obiektami (cecha języka funkcyjnego na JVM, w którym nacisk kładzie się na niezmienność struktur danych, aby tym samym ułatwić programowanie współbieżne) nie sprawdzi się. Ale czyż umiejętność wyboru właściwego narzędzia do problemu nie jest podstawowym wymaganiem w naszej branży?

android:theme="@android:style/Theme.NoTitleBar.Fullscreen" (mała litera S w Fullscreen!) - widok zajmuje całą dostępną przestrzeń bez paska tytułowego lub postępu na górze.

Obsłużenie zdarzenia wymaga, aby metoda przechwytująca je zwróciła true, np. implementacja onTouch(View v, MotionEvent event) { return true; }

Emulator na niewiele się zda, ponieważ nie wspiera gestów wielopalcowych. Nie pozostaje nic innego jak zaopatrzyć się w prawdziwe urządzenie i testowanie aplikacji bezpośrednio na nim.
Obsługa zdarzeń dot. gestów to jak przetwarzanie całej masy komunikatów i niektóre należy filtrować, aby czas spędzony na ich obsłudze nie wpływał miażdżąco na działanie aplikacji.

Teoretycznie Android API wspiera 256 palców, ale większość urządzeń kończy swoje wsparcie na 2 (tutaj autor powołuje się na osobników z filmu Faceci w Czerni, w którym istnienie istot z więcej niż 10 palcami u rąk nie jest czymś nadzwyczajnym). Nie pomyślałem o tym wcześniej, ale biorąc pod uwagę, jak wiele różnych modeli urządzeń z Androidem istnieje na rynku, można sobie śmiało wyobrazić takie, które obsługują wręcz wiele osób, np. przewodniki interaktywne w muzeach, halach, konferencjach, itp. (już w mojej głowie tworzy się obraz dzieciaków pochylonych nad dotykowym ekranem, który prowadzi przez muzeum, czy inny obiekt, które na różne sposoby weryfikują poprawność wsparcia wielu palców).

Autor poleca stronę http://gestureworks.com, aby przekonać się, jak wiele gestów jest już używanych w aplikacjach. Jako użytkownik Mac OS X na MacBook Pro korzystam z gestów z 4 palcami (góra/dół do pokazania wszystkich okien) i uważam je za co najmniej interesujące (aczkolwiek przyzwyczajenie się do nich, zwane nauczeniem się ich, trało dłuższą chwilę).

Widgety na ekranie początkowym - stronie domowej


Widgety w Androidzie to niewielkie (funkcjonalnie) aplikacje uruchamiane bezpośrednio na pulpicie, np. zegarek, pogoda, wyświetlanie obrazka, itp.

Nie ma wsparcia do tworzenia widgetów w Eclipse ADT. Tworzymy projekt androidowy ze zmianami - nie jest potrzebna początkowa aktywność (activity), a w AndroidManifest.xml używamy <receiver> z <intent-filter> zamiast <activity>. Układ elementów graficznych określamy w pliku XML wskazany przez <meta-data> w AndroidManifest.xml.

Przeczytałem o NinePitch, który jest rozszerzalnym obrazkiem PNG, często używanym jako tło dopasowujących się przycisków. Do ich tworzenia korzystamy z narzędzia draw9patch (w Android SDK w katalogu tools). Utworzony plik musi mieć rozszerzenie 9.png i być w res/drawable.

Klasa bazowa widgetów android.appwidget.AppWidgetProvider.

Uruchomienie widgeta podobne do aplikacji z tą różnicą, że po wgraniu musimy jawnie uaktywnić przez umieszcznie na pulpicie. Widget może odświeżać swoją zawartość. Wystarczy zadeklarować intent APPWIDGET_UPDATE i pojawienie się zdarzenia wzbudza onUpdate naszego widgeta. Częstotliwość aktualizacji określana jest parametrem android:updatePeriodMillis w widget.xml wskazywanym przez AndroidManifest.xml. Uwaga na częstość odświeżania, bo bateria urządzenia bardzo niewielka i na niewiele starczy.

Więcej na temat widgetów w dokumentacji App Widgets.

Dynamiczne tapety


Autor zaprezentował utworzenie projektu z użyciem OpenGL. Ponownie zabawa z AndroidManifest.xml - użycie znacznika <service>, ponownie intent-filter z meta-data z android:name="android.service.wallpaper".

Po raz pierwszy przeczytałem o usługach (ang. service) uruchamianych w tle, które reagują na zdarzenia z urządzenia. Klasa macierzysta android.app.Service i po trosze przypomina Activity - mamy onCreate() i onDestroy(). Są jeszcze onStartCommand() przy uruchomieniu usługi.

Kolejny raz, kiedy przychodzi dokładniejsze rozpoznanie tematu, autor skraca temat wskazując na dokumentację.

Tworzenie dynamicznych tapet sprowadza się do rozszerzenia klasy android.service.wallpaper.WallpaperService. Poznaję również nieodłączną klasę tapet android.service.wallpaper.WallpaperService.Engine.

Czasami autor przesadza z wprowadzaniem czytelnika w arkana programowania aplikacji na Androida i niepotrzebnie tłumaczy, jak programować w Javie, np. konstrukcję klas wewnętrznych oraz wykorzystanie final dla pól poza ich ciałem, aby były widoczne. Później jeszcze przydługawe omówienie generowania domyślnych ciał metod klasy nadrzędnej oraz rozwiązywania problemów braku właściwych importów z Quick Fix lub Organize Imports w Eclipse. Niejednokrotnie byłem zaskoczony, że w ogóle przedstawia się takie tematy.

Przy okazji poznawania tapet w Androidzie mogłem poczytać o klasie java.util.concurrent.Executor. Podobnie jak w Swingu należy bacznie rozplanować zrównoleglanie operacji, szczególnie tych, które modyfikują elementy graficzne. W przykładzie korzysta się z java.util.concurrent.Executors.newSingleThreadExecutor().

Widzę u siebie duże braki w temacie zmian w Java SE 5 i nowszych w obszarze java.util.concurrent. Kolejna książka musi być właśnie o tym. Sugestie mile widziane (poza Java Concurrency in Practice Brian's Goetz'a, którą już niejednokrotnie zaczynałem, ale chyba dopiero teraz dojrzałem do zmierzenia się z nią).

Testowanie


Należy testować. Każdy to wie i trochę niepoważnie przypominać o tym. Jeśli testowanie w Javie stanowiło swego rodzaju wyzwanie, to zmiana środowiska na androidowe będzie nakładała dodatkowe ograniczenia i wymagania. Wiele różnych rodzajów urządzeń wymaga stworzenia wielu AVD w Eclipse. Należy testować na różnych wymiarach ekranów i rozdzielczości. Nie zapominamy o testowaniu w różnych orientacjach - poziomie i pionie (w Emulatorze Ctrl+F11 lub 7 i 9 na klawiaturze).

Podczas uruchamiania określamy w zakładce Target, Deployment Target Selection Mode na Manual i wybieramy odpowiednie urządzenie. Wskazanie tego właściwego urządzenia odbywa się przez AndroidManifest.xml przez znacznik <uses-sdk> z elementami android:minSdkVersion oraz android:targetSdkVersion. W ten sposób określamy minimalne wymagania wersji Androida ze wskazaniem na zalecaną wersję.

Poznaję wyjątek java.lang.VerifyError, który pojawia się, kiedykolwiek wywołujemy metodę, która nie istnieje podczas uruchomienia (a istniała podczas kompilacji). Dosyć popularny wyjątek, kiedy zapomnimy o różnych wersjach Androida i różnicach między nimi w klasach i ich metodach. Rozwiązaniem było zastosowanie wzorców Delegator i Fabryka. Jak widać, przy okazji poznawania Androida można poznać również wzorce. Krótko i rzeczowo - mi się podobało.

Następnie autor przedstawia sposoby na poznawanie Androida od strony jego błędów. Warto od czasu do czasu zajrzeć do kodów źródłowych Android API - platform/frameworks/base.git. Zmiany w klasach opatrzone są zwykle komentarzem ze wskazaniem na błędy, które zapoczątkowały je.

Jest jeszcze trochę o podkatalogach w res dla obrazków na różne rozdzielczości ekranów - drawable-hdpi, drawable-mdpi, drawable-ldpi lub drawable-nodpi. Dowiedziałem się również o różnych kwalifikatorach w nazwach katalogów, dla różnych wersji językowych, rozdzielczości, wymiarach ekranu, położeniu (orientacji), wersji SDK i in. Więcej niż jeden kwalifikator oddziela się w nazwie myślnikiem.

Na koniec wzmianka o android:installLocation w AndroidManifest.xml, który wskazuje na możliwość instalowania aplikacji na karcie SD (zamiast bezpośrednio na urządzeniu). Dwie dozwolone wartości auto i preferExternal. Brak wartości oznacza instalację na urządzeniu. Google zaleca, aby nie instalować na karcie SD aplikacji korzystających z pewnych funkcjonalności Androida, np. tapety, usługi, widgety.

Ponownie, na koniec rozdziału zalecenie, aby zapoznać się z oficjalną dokumentacją, aby poznać więcej. Normalka.

Publikowanie w Android Market


Na zakończenie części czwartej rozdział o udostępnianiu aplikacji, czyli publikowaniu aplikacji w Android Market. Autor przeprowadza przez cały proces, począwszy od wyboru odpowiedniego i unikatowego pakietu (patrz AndroidManifest.xml), testowania, podpisywania i wrzuceniu do Android Market.

Raz wybrany pakiet aplikacji nie podlega zmianie (bez odinstalowania aplikacji). Niech to będzie pakiet główny naszych klas javowych, np. pl.japila.aplikacja (tzn. ta jest zarezerwowana dla moich aplikacji, ale rozumiem, że Ty rozumiesz, że chodzi o odwrotną notację z domenami w tle, jak w Javie).

Do zapamiętania: "Make your program do one thing well, rather than a lot of things poorly." 

Poznaję android:versionCode i android:versionName z AndroidManifest.xml.

Warto zapoznać się z User Interface Guidelines.

Później omówienie apk i podpisania z użyciem keytool, jarsigner lub oprzeć się na Eclipse ADT - Android Tools > Export Signed Application Package. Więcej na Signing Your Applications. Na koniec otrzymujemy podpisany plik apk. Z plikiem apk udajemy się do Android Market i po opłaceniu jednorazowej, podobno niewielkiej, opłaty, wybieramy Upload Application. Wypełniamy formularz, w którym wyłączamy Copy Protection (podobno jedynie irytuje użytkowników i wcale nie zabezpiecza), wybieramy All Current and Future Countries w Locations i nie podajemy numeru telefonu - użytkownicy skorzystają z niego w najmniej odpowiednim momencie (!) Publish i aplikacja jest dostępna od ręki w Markecie.

Aktualizacja aplikacji wymaga zmiany android:versionCode o jeden w górę i android:versionName w AndroidManifest.xml. Publish i zmiana dostępna. Sugeruje się częste aktualizacje - utrzymuje (często błędne?) przekonanie o ciągłym wsparciu aplikacji (co nie wprost może być faktycznie prawdą, bo w końcu nowe funkcje są wprowadzane) oraz nasza aplikacja znajduje się w Recently Updated, co podnosi widoczność aplikacji.

Warto rozważyć opublikowanie aplikacji w dwóch wersjach - darmowej (light) oraz płatnej (pro). Płatną aplikację możemy zmienić na darmową, ale nie na odwrót.

Obecna wersja Android Market nie daje możliwości zakupienia własnej aplikacji.

Dodatek: "Różnice programowe" w Android API vs Java API


Pisanie aplikacji na Androida sprowadza się w dużej mierze do umiejętności posługiwania się Java SE 5 API. Istnieje jednak kilka różnic wynikających ze specyficznego środowiska, na którym będą działały aplikacje mobilne.

Zanim aplikacja trafi na urządzenie androidowe, aplikacja przechodzi proces kompilacji, jak to ma miejsce w typowych aplikacjach javowych, z tą różnicą, że bajtkod jest dodatkowo tłumaczony na instrukcje Dalvik VM.

Wszystkie konstrukcje języka Java SE 5 są wspierane (nie dotyczy to jednak API, a wyłącznie samego języka Java). W ten sposób możliwe jest korzystanie z aplikacji javowych, które nie były pierwotnie pisane na Androida (z dokładnością do używanych bibliotek i API, które mogą być niedostępne - o tym za moment).

Uwaga na użycie typów prostych float oraz double. Niektóre urządzenia mogą nie posiadać wsparcia sprzętowego dla operacji zmiennoprzecinkowych i przez to działanie aplikacji będzie znacznie opóźniane przez obliczenia aplikacyjne.

Wątki są wspierane przez przydzielanie kawałków czasu na uruchomienie jednego, tzw. time slicing. Stąd korzystanie z wątków powinniśmy sprowdzić do użycia jednego bądź maksymalnie dwóch. Pierwszy będzie dedykowany do obsługi interakcji z użytkownikiem, a drugi dla długotrwałych operacji, np. obliczenia, operacje I/O.

Dalvik VM wspiera słowo kluczowe synchronized oraz Object.wait(), Object.notify(), Object.notifyAll() oraz (preferowane jako konstrukcje wyższego poziomu) pakiet java.util.concurrent.

Na urządzeniach mobilnych ograniczanych dostępnymi zasobami tym bardziej ważne jest zamykanie/zwalnianie zasobów tak szybko, jak to możliwe, korzystając z oferowanych przez nie metod close() lub terminate() (super byłoby, gdyby można było stosować try-with-resources z Java 7).

Android wspiera większą część Java SE 5 API, poza tymi, których użycie i tak nie miałoby sensu. Wspierane:
  • java.awt.font
  • java.beans
  • java.io
  • java.lang - poza java.lang.management
  • java.math
  • java.net
  • java.nio
  • java.security
  • java.sql
  • java.text
  • java.util - wraz z java.util.concurrent - dopiero teraz zauważam, że oferowane w tym pakiecie klasy są rzeczywiście uproszczeniami i powinny być oferowane w Javie od pierwszego jej dnia publikacji
  • java.crypto
  • java.microedition.khronos
  • javax.net
  • javax.security - poza kilkoma podpakietami - auth.kerberos, auth.spi, sasl
  • javax.sql - poza podpakietem rowset
  • javax.xml.parsers
  • org.w3c.dom - bez podpakietów
  • org.xml.sax
Jakkolwiek udostępniono JDBC API, to zaleca się korzystanie z android.database do dostępu do SQLite (preferowanej bazy danych SQL na Androidzie) Poza standardowymi bibliotekami Java SE 5 API mamy jeszcze org.apache.http, org.json, org.xml.sax i org.xmlpull.v1. Na tym kończę lekturę książki. Jestem zachwycony, że mogłem ją przeczytać, mimo że często doprowadzała mnie do pasji spłycając analizę problemu do "Po więcej należy udać się do oficjalnej dokumentacji Androida". Recenzja wkrótce.