https://developer.android.

com->Develop-> API guide

UVOD U ANDROID
Vano je razumeti sledee osnovne koncepte u vezi sa Android app framework-om:
Aplikacije omoguavaju viestruke take pristupa (entry points)
Android aplikacije su napravljene kao kombinacija razliitih komponenti koje mogu
biti posebno pozivane. Na primer:
aktivnost (activity) obezbeuje jedan ekran za korisniki interferjs
service nezavisno radi u pozadini
Iz jedne komponente se moe pozivati druga koristei intent.
Svaka app ima vie ulaznih taaka, pa je bilo koja druga app moe pozvati na razne
naine.
Aplikacije se prilagoavaju razliitim ureajima
Na primer, mogu se kreirati razliiti XML layouti za razliite veliine ekrana
mogu se deklarisati osobine app tako da Google Play Store ne doputa
instalaciju na ureajima koji ne podravaju tu osobinu

APPLICATION FUNDAMENTALS
Android program je napisan u Javi. Android SDK ga kompajlira i dobija se APK (Android
Package). To je fajl sa ekstenzijom .apk, koji se koristi za instaliranje programa.
Kada se instalira, svaka Android app ivi u sopstvenom sandbox-u.
Android je multi korisniki OS u kome svaka aplikacija je poseban user.
Sistem dobeljuje svakoj aplikaciji jedinstveni Linux user ID, koji je poznat samo
sistemu, a ne i aplikaciji. Sistem postavlja dozvole za sve fajlove u aplikaciji
tako da samo user ID dodeljen aplikaciji ima pravo pristupa.
Svaki proces ima sopstvenu virtualnu mainu (VM), tako da aplikacijski kod radi
nezavisno od drugih aplikacija
Po defoltu, svaka app radi u svom Linux procesu. Android startuje proces kada
bilo koja komponenta programa treba da se izvri, a iskljuuje ga kada vie nije
potreban ili kada sistem mora da obezbedi memoriju za druge aplikacije
Dakle, po defoltu, aplikacija moe da pristupi samo onim komponentama koje su
zahtevane za njen rad i nijednoj vie. To stvara vrlo sigurno okruenje u kome aplikacija
ne moe pristupiti delu sistema za koje nema dozvolu.
Jo jednom, svaka Android aplikacija se izvrava u izolovanom (eng. sandbox)
okruenju. To znai da je svaka aplikacija izolovana od svih drugih aplikacija na ureaju i
da ne moe da pristupa resursima ureaja bez eksplicitne dozvole korisnika. To je
obezbeeno tako to svaka aplikacija dobija zaseban korisniki ID (eng. User ID, preuzet
iz Linuksa). Svaka aplikacija dobija zasebnu virtualnu mainu to obezbeuje jo jedan
nivo izolovanosti. Takoe, svaka aplikacija se izvrava u odvojenom Linuks procesu. Taj
proces se pokree svaki put kada bilo koji deo aplikacije mora da se izvri, nakon ega se
taj proces gasi kada vie nije neophodan, ili kada sistem zahteva memoriju za drugu
aplikaciju.
(Postoji nain da se app-e podese da rade sa istim Linux user ID-om i da dele resurse,
pa i istu VM. Takoe app moe da radi i da sistemskim dozvolama, a o tome se vie moe
proitati u jednom od treninga na ovom sajtu, u delu Working with System Permissions)
U nastavku priae se o
App komponentama
Manifest fajl-u
App resursima

https://developer.android.com->Develop-> API guide

https://developer.android.com->Develop-> API guide

App komponente - osnove

App komponente su osnovni gradivni blokovi za Android app.Svaka komponenata je
razliita taka kroz koju sistem moe ui u app. Nemaju sve komponente ulaznu taku za
korisnika i neke zavise od drugih, ali svaka postoji kao zaseban entitet i igra specifinu
ulogu svaka je jedinstveni gradivni blok koji pomae da aplikacija ispuni svoj zadatak.
Postoji 4 razliitih tipova komponenti. Svaki tip ima razliite osobine i poseban ivotni
ciklus koji definie kako komponenta nastaje i kako nestaje.

Vrste komponenti su:

activities - aktivnosti
services - servisi
content providers dobavljai sadraja
broadcast receivers prijemnici poruka

Activities
Jedna aktivnost predstavlja jedan ekran u korisnikom interfejsu. Na primer, neka
email aplikacija moe imati jednu aktivnost koja prikazuje listu novih mejlova, drugu
aktivnost koja kreira novi mejl i treu aktivnost za itanje mejlova. Iako aktivnosti
sarauju, svaka je nezavisna od drugih. Takoe, druga app moe startovati bilo koju od
ovih aktivnosti (ako email app to doputa). Na primer, camera app moe startovati
aktivnost (iz email app) koja sastavlja novi mejl, da bi njime poslao sliku.
Sktivnosti su implementirane kao podklasa od Activity klase. U ovom tjutorijalu ima
detaljnije o aktivnostima, pod stavkom Activities
Aktivnost (eng. Activity) - klasa koja predstavlja jedan ekran aplikacije. Nju je mogue
pokrenuti na vie naina priemu je jedan od njih i samo pokretanje aplikacije iz glavnog
menija. Svaki ekran koji postoji u aplikaciji mora naslediti klasu Aktivnosti.
Services
Servis je komponenta koja radi u pozadini da bi izvrila operacije koje dugako taju ili
da bi izvrila posao za udaljene procese. Servis ne obezbeuje korisniki interfejs. na
primer, servis moe putati muziku u pozadini dok je korisnik u drugoj app, ili moe
prikupljati podatke preko mree bez blokiranja trenutne interakcije izmeu korisnika i
tekue aktivnosti. Druga kompontenta, npr aktivnost, moe startovati servis i ostaviti ga
da radi ili se povezati sa njim da bi ostvarila neku saradnju sa njim.
Service je implementiran kao podklasa klase Service. U ovom tjutorijalu ima detaljnije
o servisima, pod stavkom Services
Servis (eng. Service) - je komponenta koja se izvrava u pozadini. Ona nema korisniki
interfejs i najee se koristi za neke procese koji se dugo izvravaju. Ti procesi mogu biti
na primer sluanje muzike dok je neka druga aplikacija u prvom planu, ili sinhronizacija
aplikacije sa serverom dok aplikacija nije pokrenuta. Servise je mogue pokrenuti na
nekoliko naina, a jedan je iz klase Aktivnosti sa kojom moe i da komunicira.
Content providers dobavljai sadraja
Ova vrsta komponente upravlja podacima apllkacije. Podaci mogu biti smeteni u fajlu,
u SQLite bazi, na vebu ili na nekoj drugoj memoriji kojoj app moe pristupiti. Kroz content
provider i druge apps mogu itati ili ak modifikovati podatke (ako content provider
dozvoljava modifikovanje) Npr. Android obezbeuje content provider koji upravlja
korisnikovim kontakt informacijama. Tako bilo koja aplikacija sa odgovarajuim dozvolama
moe koristiti deo content providera (npr. CoontactsContract.Data) za itanje i upis
podataka o pojedinanoj osobi.
Content provider-i su takoe korisni za prisup podacima koji su privatni za app i ne
dele se sa drugima. Npr. NotePad sample app koristi content provider za uvanje
napomena.

https://developer.android.com->Develop-> API guide

Content provider je implementiran kao podklasa klase ContentProvider i mora
implementirati standardni ser API koji dozvoljava drugim apps da izvre transakciju. U
ovom tjutorijalu ima detaljnije o content provider-ima, pod stavkom Content Providers
Dobavljai sadraja slue da drugim aplikacijama izloe podatke aplikacije u kojoj se ti
dobavljai sadraja koriste
Broadsast receivers prijemnici poruka
Broadcast receiver je komponenta koja odgovara na sistemske objave. Mnogo objava
potie od sistema, npr. objava da je ekran iskljuen, da je baterija prazna, ili da je slika
uhvaena. Apps mogu takoe inicirati objave, npr. objaviti da u neki podaci
downloadovani na ureaj i da su spremni za korienje.Iako broadcast receivers ne
prikazuju korisniki interfejs, oni mogu kreirati Status bar notifikaciju da bi obavestili
korisnika kad se dogaaj desio. Najee je ipak ova komponenta samo most prema
drugoj komponenti i napravljena je da obavlja samo mali deo posla npr. da inicira servis
koji e izvriti neki posao baziran na dogaaju.
Broadcast receiver je implementiran kao podklasa klase BroadcastReceiver i svaki
protok je oznaen kao Intent objekat. U ovom tjutorijalu ima detaljnije o broadcast
receiverima, pod stavkom BroadcastReceiver
Prijemnici poruka (eng. Broadcast receivers) - slue da prihvate poruke koje mogu slati
druge aplikacije ili ak sam sistem. Te poruke mogu da idu od sistemskih dogaaja kao
to je ukljuivanje telefona ili prijem SMS poruke do kraja putanja nekog audio fajla.

Pozivanje komponenti
Android sistem je dizajniran tako da se svaka app startuje sa svojim komponentama.
Npr, ako eli da korisnik napravi sliku kamerom, verovatno postoji druga app koja radi to
itvoja app moe to iskoristiti, umesto da se kod pie ponovo.ak ne mora ni da se pie, ni
kopira kod. Trega jednostavno startovati aktivnost koja pravi slike u camera app. Kada se
zavri slika se dostavlja tojoj app i moe je koristiti. Za korisnika, to je kao da je camera
sastavni do app.
Kada sistem startuje komponentu on inicira sve klase neophodne za komponentu i ona
radi u svom procesu, a ne u procesu aplikacije koja je zove.
Poto svaka app radi u svom procesu, app ne moe direktno aktivirati komponentu iz
druge app. Ali Android sistem moe. Tako, da bi se aktivirala komponenta u drugoj app,
morate proslediti poruku sistemu u kojoj se nalazi intent da se startuje odreena
komponenta. Sistem onda aktivira komponentu za tebe.

Activating Components aktiviranje komponenti

Tri od etiri tipa komponenti aktivnosti, servisi i prijemnici poruka se aktiviraju
asinhronim porukama koje se zovu intent. Intenti povezuju komponente sa drugim
komponentama prilikom izvravanja programa. (moe da misli o njima kao o potaru
koji prenosi zahtev za akciju od strane neke druge komponente). Komponente koje se
povezuju mogu da potiu iz iste ili neke druge aplikacije.
Intent je kreiran preko Intent objekta, koji definie poruku za aktiviranjem neke
specifine komponente ili specifinog tipa komponente tako da intenti mogu biti
eksplicitni ili implicitni, respektivno.
Za aktivnosti i servvise, intent definie akciju za izvravanje (na primer, da prikae
ili poalje neto), i moe se odrediti URI podatka za akciju (i mnoge druge stvari koje
startovana komponenta treba da zna). Na primer, intent moe preneti zahtev aktivnosti
da prikae slike ili da otvori web stranu. U nekim sluajevima, aktivnost se startuje da bi
se dobio rezultat i u tom sluaju aktivnost moe vratiti rezultat takoe preko intenta (npr.
moe emitovati intent da trai od korisnika da odabere jedan kontakt i da preko intenta
dobije taj kontakt, jer intent moe da ima URI koji pokazuje na izabrani kontakt)

https://developer.android.com->Develop-> API guide

Za prijemnike poruka intent jednostavno definie objavu koju sadri poruka (npr,
poruka koja obavetava da je nivo baterije mali ima u sebi samo string battery is low.
Contant provider komponenta, dostavlja sadraja, ne aktivira se intentom.Ona se
obino aktivira zahtevom iz ContentResolver-a. Content resolver upravlja svim direktnim
transakcijama sa provajderom, tako da komponenta koja izvrava transakciju preko
contact providera koriste metod ContentResolver objekta. To ostavlja nivo apstrakije
izmeu content provajdera i komponente koja zahteva informaciiju (dobro za sigurnost)
Postoje posebne metode zaa aktiviranje svakog tipa komponente:
Startovanje aktivnosti (ili da se ve startovanoj aktivnosti dodeli neki novi
posao) se radi preko metoda Intent-a koje se zovu startActivity() ili
startActivityForResult() (ovo se koristi ako eli da aktivnost vrati rezultat)
Startovanje servisa (ili dodela nove instrukcije ve startovanom serveru ) se
radi preko metode Intent-a koja se zove startService() . Ili se moe koristiti
bindService() (za povezivanje sa servisom)
Startovanje prijemnika poruka se moe inicirati preko metoda Intent-a koje se
zovu sendBroadcast() ili sendOrderedBroadcast() ili sendStickyBroadcast().
Upit za content provider se radi pozivanjem query() metoda ContentResolver-a

Manifest fajl
Pre nego to Android sistem pokrene komponentu, sistem mora znati da ta
komponenta postoji isitavanjem manifest fajla. Ovaj fajl AndroidManifest.xml mora biti u
rutu direktorijuma u kome je smeten projekat.U njemu se moraju deklarisati sve
komponente koje projekat koristi.
Osim toga, nakon deklarisanja komponenti u manifestu se radi i sledee:
Identifikovanje svih korisnikih privilegija koje aplikacija zahteva (npr. pristup
internetu ili itanje tj izmena korisnikovih kontakta)
deklarisanje minimum API Level koji zahteva aplikacija (miminalna verzija
operativnog sistema)
deklarisanje osobina hardvera i softvera koje su zahtevane od strane aplikacije
(npr. kamera, blutut servis, multita skrin...)
API biblioteke koje su potrebne aplikaciji (a nisu u Android framework API-ju),
npr Google Maps library
i tako dalje

Deklarisanje komponenti
Primarni zadatak manifesta je da informie sistem o aplikacijskim komponentama. Na
primer, manifest moe sadrati ovkvu deklaraciju aktivnosti
<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
<application android:icon="@drawable/app_icon.png" ... >
<activity android:name="com.example.project.ExampleActivity"
android:label="@string/example_label" ... >
</activity>
...
</application>
</manifest>

U okviru <application> elementa, atrribut android:icon pokazuje na resurs za ikonu

aplikacije.

https://developer.android.com->Develop-> API guide

U okviru <activity> elementa, atrribut android:name sadri ime klase koja je podklasa
klase Activity a android:label atribut sadri string koji je naziv te aktivnosti (naziv koji vide
korisnici)
Sve komponente u aplikaciji se moraju deklarisati:.
<activity> element za aktivnosti
<service> element za servis
<receiver> element za primnike poruka
<provider> element za dobavljae sadraja
Aktivnosti, servisi i dobavljai sadraja koji su ukljueni u source ali nisu deklarisani u
maanifestu nisu vidljivi za sistem, pa se nikad ne mogu pokrenui. Meutim, prijemnici
poruka mogu ili biti deklarisani u manifestu ili dinamiki kreirani u kodu (preko
BroadcasrReceiver objekta) i registrovani na sistem pozivom registerReceiver() metode

Deklarisanje mogunosti komponenti

Kao to smo naveli ranije, za startovanje sktivnosti, servisa i prijemnika poruka moe
se koristiti Intent. Tada moe ekspliicitno da navede ime ciljne komponente (koristei
class name komponente) u intentu. Meutim, prava snaga intenta lei u konceptu
implicitnog intenta. Implicitni intent jednostvavno opisuje tip akcije koja treba da se izvri
(i , opciono, podatak za koji bi eleli da se izvri akcija) i doputa sistemu da fpronae
komponentu na ureaju koji moe izvriti akciju, i da ga onda startuje. Ako ima vie
komponenti koje mogu izvriti akciju opisanu u intentu, onda korisnik selektuje koju eli
da koristi.
Sistem identifikuje komponente koje mogu da odgovaraju intentu na osnovu
uporeivanja primljenog intenta i intent filtera koji se nalaze u manifest fajlovima drugih
aplikacija na ureaju.
Kada se deklarie aktivnost u manifestu, moe se opciono ukljuiti intent filter koji
opisuje mogunosti aktivnosti tako da ona moe odgovoriti intentima iz drugih aplikacija.
Intent filtr za komponentu se deklarie dodavanjem <intent-filter> elementa koji je deteelement u deklaraciji komponente.
Na primer, ako u email aplikaciji postoji aktivnost za sastavljanje novog email-a, moe
se deklarisati sledei intent filter koji odgovara send intentima (ija je uloga slanje
emaila):
<manifest ... >
...
<application ... >
<activity android:name="com.example.project.ComposeEmailActivity">
<intent-filter>
<action android:name="android.intent.action.SEND" />
<data android:type="*/*" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
</application>
</manifest>

Tako, ako druga aplikacija kreira intent sa ACTION_SEND akcijom i prosledi je preko
startActivity(), sistem moe startovati gore definisanu aktivnost tako da je korisnik moe
birati i poslati emanil.

https://developer.android.com->Develop-> API guide

Deklarisanje zahteva aplikacije

Ima puno ureaja koji rade pod Androidom i njihove osovine i mogunosti su razliiti.
Da bi se spreilo instaliranje aplikacije na ureaju na kome nee da radi , vazno je isto
definisati profil za tip ureaja koji podravaju aplikaciju. To se postie deklarisanjem
hardverskih i softverskih zahteva u manifestu. Najvei broj tih deklaracija su samo
informativnog karaktera i sistem ih ne ita, ali ekteri servisi kao to je Google Play ih
itaju jer na osnovu njih rade filtriranje aplikacija za korisnike koji trae aplikacije za svoje
ureaje.
Na primer, ako apkikacija zahteva kameru i korisi API uvedene u Android 2.1 (API Level
7) u manifestu bi moglo da pie
<manifest ... >
<uses-feature android:name="android.hardware.camera.any"
android:required="true" />
<uses-sdk android:minSdkVersion="7" android:targetSdkVersion="19" />
...
</manifest>

Sada, ureaj koji nema camera, i koji ima Android verziju manju od 2.1 ne moe
instalirati aplikaciju sa Google Play-a.
Meutim, takoe je mogue deklarisati da app koristi camera, ali da je ne zahteva. U
tom sluaju aplikacija mora setovati atribute required na false i ispitivati u run time da li
ureaj ima camera i disejblovati oprikladnu camera osobinu (?)

App Resources
Android aplikacija osim koda sdri i resurse koji su odvojeni od koda, kao npr. slike,
audio fajlove, i sve povezano sa visualnom presentacijom aplikacije. Na primer, mogue
je definisti animacije, menije, stilove, boje i nivo aktivnosti korisnikih interfejsa preko
XML fajla. Upotreba aplikacijskih resursa olakava apdejtovanje razliitih karakteristika
aplikacije, bez modifikovanja koda i kroz obezbeivanje skupova alternativnih resursadoputa optimizovanje aplikacije za razliite konfiguracije ureaja (npr. razliiti jezik i
veliina ekrana).
Za svaki resurs koji je ukljuen u Android projekat, SDK build tools definie jedinstveni
celobrojni ID, koji se moe koristiti da se pristupi resursu iz koda ili iz drugih resursa
definisanih u XML-u. Na primer, ako aplikacija sadri fajl sa slikom koji se zove logo.png
(sauvan u folderu res/drawable/ ), SDK generie resurs ID sa nazivom R.drawable.logo,
koji se moe koristiti da se pristupi slici i da se ona ubaci u korsniki interfejs.
Jedna od najvanijih prednosti odvajanja resursa i koda je mogunost da se obezbede
alternativni resursi za razliite konfiguracije ureaja. Na primer, definisanjem UI stringova
u XML-u, mogue je prevesti stringove na drugi jezik i sauvati te stringove u posebnom
fajlu. Tada, preko upotrebe jezikih qualifier-a moe se dodati ime direktorijumu resura
( npr. res/value-fr za stringove na francuskom jeziku) i korisniko podeavanje jezika, i
Android sistem e primeniti odgovarajui jezik za UI.
Android podrava mnogo razliitih qualifiers za alternativne resurse. Qualifier jekratki
string koji se ukljuuje u ime resurs direktorijuma da bi se definisala konfiguracija ureaja
za koje se koriste ti resursi. Npr. mogue je kreirati razliit layous za aktivnosti, zavisno od
orjentacije i veliine ekrana na ureaju.Pa ako je ekran na ureaju uspravan (tall), moe
se koristiti layout sa vertikalnim dugmadima, a ako je ekran poloen (wide), moe se
koristiti layout sa horizontalnim dugmiima. Da bi se layout menjao sa promenom
orijentacije,, treba definisati dva razliita layout-a i primeniti odgovarajui qualifier za
svaki naziv foldera za layout. Tad e sistem automatski da primeni odgovarajui layout u
zavisnosti od orijentacije ureaja

https://developer.android.com->Develop-> API guide