RADDINO: Ahoj. Můžeš to tam "doprasit" tak, že v onActivityResult() budeš mít i obr.setOnClickListener(new OnClicklistener() {Dialog...});

RADDINO: ještě ukázka těch metod
Imageview · GitHub
https://gist.github.com/ankhthief/fe4035ef90ecfd422a0fd9ef8b1711b5

Jdu si pro radu zkušenějších. Mám fragment, kde ukládám do DB info o zranění a chci mít také možnost přiložit fotku. Nyní řeším to, že bych rád po vyfocení fotky ty fotky zobrazoval pod tlačítkem "Take photo .." a po kliknutí na ně otevřel fotku ve větším náhledu asi v Dialogu, kde by byla možnost fotku smazat. Aktuálně to mám tak, že po kliknutí na tlačítko se spustí camera Intent. Po vyfocení fotky se v OnActivityResult kódem vytvoří ImageView do definovaného LinearLayoutu a obrázek se zobrazí. Pokud vyfotím další, další obrázek se vytvoří pod to. Řeším teď, jak udělat obrázek kliknutelný, aby se po kliku otevřel Dialog, když nevím jeho ID, jelikož ty ImageView vytvářím dynamicky. Budu rád za nějaké nakopnutí, případně nasměrování, jak podobnou situaci řešit správně. Předpokládám, že moje řešení je prasárna.

Díky moc

Ještě k těm support packages. I kdybychom zapomněli na budoucí vývoj (jak psal DATEL), tak je tu slušná pravděpodobnost, že dřív nebo později narazíš na nekompatibilitu v nějaké classe, kterou Android vůbec nepodporuje, a existuje jenom v support libkách. Typicky ViewPager :-).

MR_DAN: backstack je pro tebe něco jako history, s tím že jeden fragment můžeš mít v backstacku ale víckrát tak na to pozor. Současně to co dostaneš od manageru nemusí být stejná instance já tam byla předtím. Aplikace ti může umřít a znovu se probrat a backstack se mezi tím serializuje.

MR_DAN: pokud neděláš něco drahého v onCreate nebo konstruktoru, tak si toho nevšimeš, jen si přidáš práci

hmm, koukam na to, ze FragmentManager ma jakysi back stack, ktery jednak urcite budu chtit pouzivat a jednak se da pouzit i jako cache .. fragmentManager.findFragmentByTag(String)

hmm, support baliky jako standard, zajimavy informace mi davate a dava to smysl...

DRIZDIK: a co nejaka kombinace - cachovani instanci a zaroven ukladani jejich stavu pro pripad, ze by je system zabil a musely se vytvaret znova? byl by ten pripadnej rozdil v performance markantni? ja vlastne poradne nevim, jak draha operace je vyrvoreni fragmentu a naloadovani jeho stavu

DATEL: pouzivame vlastne jen support libky.

jo uz to mam, ta idea kdyz delam new->fragment->blank mi automaticky vytvari ty support,v4.Fragment potomky... to samy u aktivit

YAZZMAN: hmm, koukam ze ty ne-support classy vidim jako sdk 26, protoze to je to sdk ktere aktualne pouzivam k vyvoji - da se nejak zjistit, od ktere verze API je ktera classa? je to koukam v javadocu, ale to je jak cist egyptana Sinuheta :D
zda se, ze se to da poznat podle toho "v4" (napr) v packagi, co?
z tohohle mam vazne peknej bordel v kodu, protoze spousta navodu na webu pouziva ty support knihovny... musim na to vic soustredit pozornost

MR_DAN: support knihovny potrebujes, pokud chces pouzivat nejakou funkcionalitu, ktera byla predstavena pozdeji, na starsich verzich androidu (fragmenty jsou myslim az od API 11, takze na starsi verze potrebujes support), je to jina implementace stejne veci. Pokud nepotrebujes, support knihovny je lepsi nepouzivat

fragmenty si s klidem drz v nejakem listu a prehazuj pomoci fragmentManageru (a mam za to, ze FragmentManager existuje uz od API 11)

zdarek, tak ja vas zase zamestnam nejakou otazkou :-)
android.support.v4.app.Fragment vs. android.app.Fragment - nejen tady se setkavam se zdvojenim trid, kdy jedna jde vzdycky z nejakeho compat baliku ... je nejake general rule of thumb kterou mam volit? vidim ze jedna je ze sdk 26, ale ani u jednoho mi IDE nerve, mam minSdk 21 a compileSdk 26, hadam ze to teda nebude uplne dobre?
a rovnou druha - mam aktivitu s drawerem, pri preskakovani mezi polozkama draweru se vzdycky vytvori nova instance Fragmentu a ta se naloaduje do te aktivity - chci si ty instance pamatovat, abych je porad nevytvarel znova? nebo mam ukladat jejich stavy a instance jako takove nechat zabit? diky tomuhle jsem se dostal k tomu viz vyse, protoze takovy FragmentManager by mi s tim hodne pomohl, ale ten je z toho sdk 26

MR_DAN: Nejde mi zas tak o výdělek, jako o nabírání zkušeností, odezvu zákazníků atp... Pravděpodobně to nebudu dělat jen pro Prahu ale celou Čr s možností "zaslat vyhlídku"

Zdravím, myslíte jsi, že by měl trh (turisti, místní) zájem o aplikaci ukazující výhledy na Prahu?

MR_DAN: Není to kočkopes, ale pokud chceš udržovatelnou appku, tak ten vývoj prostě musí směřovat ke stejným(podobným) patternům, abys měl ty věci oddělitelné, testovatelné, mockovatelné, nahraditelné. Appka ti tím nějak nenabude na velikosti, většina zásadních knihoven je celkem malinkých a nebo to mám SDK přímo v sobě (generování databindingu např.) ..
Než dělat kočkopsa to spíš umožňuje to dělat různě a najít si v tom co potřebuješ a co ti vyhovuje.

A otáčení obrazovky(znovuvytvoření aktivity), umírání aktivit zatímco ti běží jiná, zabíjení background procesů kvůli dozu a podobně je ta zábava na androidu :-D Ale v reálu je to opět jako na webu, jen ten context tady není session nebo request, ale app nebo activity .. jen je tu velká výhoda, že ti to tu používá jen jeden uživatel :-D