Újrahasznosítható XML erőforrásokat szerettem volna készíteni. Szinte biztos voltam a kudarcban, de azért megpróbáltam, hátha Google gondolt az ilyesmire. Csináltam egy projektet, beleraktam egy layout-ot, és exportáltam JAR-ként, pont, ahogyan JAVA projektemmel tettem volna. Amikor a JAR-t importáltam, rögtön jött a hiba: konfliktus a nevekben, mivel az erőforrások nincsenek package-ekbe rendezve. Átnevezés, második kör. Ekkor legalább már fordult, de amikor a hivatkozott csomag R osztályán keresztül megcímeztem az erőforrásomat, természetesen a fogadó projektem első layout-ját kaptam vissza, mivel a cím integer volt, és a projekt fordulásakor mind két R osztályban ugyanbban a szekvenciában osztották.
Ugyanez történt, amikor a projektet hivatkoztam a Build Path-ban. Eddig rendjén is van minden, erre számítottam. De akkor hogyan lehet mégis újrahasznosítani az XML-eket? Az mégsem járja, hogy egyenként importáljam minden projektbe. A megoldás a Library project, egy elég nyakatekert eszköz pontosan az én problémám megoldására. Ha valamilyen erőforrást több projektben szeretnénk használni, akkor ki kell szerveznünk egy könyvtár-projektbe. Ez a könyvtár-projekt adható aztán hozzá a projektekhez.
A könyvtár projekt egy öszvér megoldás, amit az Android projekt struktúrája hívott életre. Ha az Android SDK szépen osztályokká fordítaná az XML erőforrásokat, ahogyan azt a .NET (ASP) és a J2EE (JSP) is teszi, akkor JAR-ként terjeszthetőek lennének. Így meg kell elégednünk a Library projects-el.
Mik a Library projects hátrányai? Legelőször is nem bináris, és nem kompakt. Ha valakinek oda szeretnénk adni, akkor azt open source tehetjük, és még csomagolnunk is kell. Másodszor egy projekt vagy könyvtár vagy futtatható. Ha egy projektet könyvtárként szeretnénk megosztani, akkor ki kell szerveznünk a megosztásra szánt erőforrásokat, forrás-file-okat egy külön projektbe, és azt könyvtárosíthatjuk. Annak ellenére, hogy ily módon előkészítjük a megosztásra szánt erőforrásokat, a fogadó alkalmazásban továbbra is fel kell tüntetni a manifest-file-ban, hogy pontosan mit is veszünk át - ha Activity-t is szeretnénk használni. Mivel az erőforrások továbbra sincsenek "csomagolva", ezért előfordulhatnak névbeli ütközések. Ilyenkor a host-alkalmazás élvez magasabb prioritást, a használt könyvtárak közt sorrend állítható fel. Az XML file-ok - még ha értelme is volna, és a felhasználó is szeretné - sem kerülnek összefűzésre, a magasabb prioritású file eltakarja az alacsonyabbat (Ehhez Google annyit fűz hozzá, hogy "To avoid resource conflicts for common resource IDs, consider using a prefix or other consistent naming scheme that is unique to the project (or is unique across all projects).", köszönjük). Végül pedig az utolsó hátrány: bár JAR-okat hivatkozhatnak, a könyvtáraink nem hivatkozhatnak más könyvtárakat, tehát ha van egy könyvtár-csomagunk, amit szeretünk használni, akkor a tartalmukat vagy egyesíteni kell, vagy minden egyes újabb projekthez egyenként hozzáadni az elemeket.
Mire jók ezek után a shared librariek? Nagyon szorosan összefüggő projektek redundáns elemeinek kezelésére. A Google is említ egy példát: adott alkalmazás ingyenes és fizetős változatának fejlesztése. Egy blogban a szerző a kétnyelvű alkalmazását kezelte így. Egy alkalmazás Skin-elésére is megfelelő lehet. Mire nem jó a shared library? Én nem ajánlanám univerzális komponensek, egyedi nézetek megvalósítására, nehezen terjeszthető, nehezen dokumentálható. Ezeket próbáljuk meg tisztán JAVA-ban elkészíteni. Az Activity-k újrahasznosítása pedig magasabb szinten megoldott, ha egy alap-funkciót Activity vagy Service valósít meg, akkor azt külön Appliation-ként terjesszük, és futási időben hasznosítsuk újra.
