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

DRIZDIK:
2) tyjo to mi vubec nerikej, ze s otacenim obrazovky bude nejaky s*ani :D zatim MVP nedelam, ale jak se dostane appka aspon do puberty, tak se to bude vic a vic hodit
3) no a neni to pak delani kockopsa? ja jak android vyvoj poradne neznam, tak chci od zacatku vyuzivat knihovny a principy ktery jsou pro android vlastni, neohybat si to pro svoji potrebu aby to bylo co nejvic podobny jave, jednak by to mohlo ztracet na efektivite a jednak abych z lehky 4-5obrazovkovy appky neudelal 100mb molocha
jinak samozrejme message/event bus nebo ui vazany na model, to by se mi libilo :-)

MR_DAN:
1) co říká DACAN: , 21 je nejpohodlnější pro tebe, plná podpora multidex v ART runtimu, rychlejší vývojovej cyklus a ty drobnosti ala vectory atd, plus od 19 je plná podpora RTL jazyků a UI, pokud cheš dělat něco globálního, tak v tomhle si od 19 ušetříš práci.
2) Dagger2 je jasnej, ale pokud bys to chtěl používat jako YAZZMAN:, tak doporučím kouknout po nějaký další plugin knihovně, která ti dovolí těm presenterům zachovat jednoduše stav a aynchroní operace při rotacích obrazovky a podobně.
3) v podstatě se ti to blíží komplet k hezkýmu Java vývoji, můžeš si přidat i nějaký ORM, využít pořádně MVVM databinding, kdy se ti deklarativně napsaný UI obnovuje podle změn na modelu bez zbytečnýho boilerplate kodu, message bus a podobně, všechno na androidu už je, případně pokusy o jiné věci typu unidirect Jedux,

jasne, s tou cilovkou a strukturou uzivatelu si taky v hlave trochu zahravam - jakoze uzivatel smartphonu, co neni uplne duchodce se dvema ikonama na plose, mimo ktery se boji kamkoliv tuknout (nebo neco na ten zpusob), bude totalne nestastnej s telefonem starsim nez rekneme 3 roky... nejsem uplne marketak, muzu bejt dost mimo :-) ale na tu 21 to asi zaseknu, ikdyz bych chtel pochopitelne pokryt vsechny cilovky
..dalsi faktor je, ze prvni stejne pokryju powerusery, mlady lidi, proste tam ty verze budou v prumeru vyssi a nez se to rozsiri na ostatni cilovky, tak to chvilku potrva (s mym tempem tak 10 let :D) a to zastoupeni verzi se zas trochu pohne

ad Dagger2 - cili pouziva se to, dobre ze jsem se zeptal :-) nebude to asi uplne jak spring v jave, ale lepsi nez dratem do oka
bal jsem se aby to nebyla nejaka zoufalost ne-android vyvojaru podobna jak kdyz se nekdo zoufale snazi rozfachat outlook a photoshop na linuxu apod :-)