Zdravím, hledám pro svůj rozsáhlý projekt programátora Android.

1) Jedná se o naprogramování aplikace podobné http://aplikace.o2active.cz/detail.php?id=781#.Ubht5ED0Ekc s mnohem více funkcemi. Pro první verzi by ale stačili základní verze s postupnm rozšířením

2) Jedná se o aplikaci s prací telefonním seznamem a komunikací API přes URL odkazy

VIRTUALVOID: s tim pocitam

MRTVY_KENNY: iphone neporiesis bez nakladov, budes potrebovat 99$/year + zopar stoviek za podpisovy certifikat.

VIRTUALVOID: no tim phonegapem resim ten iphone. nemam maca.

MRTVY_KENNY: moja registracka trvala tak tyzden, takze sa zaregistruj cim skor, tym
lepsie. schvalenie aplikacie + zobrazenie v gp na samotnych devices trva +/- 4 hodiny.

na phonegap sa vykasli... nativne to urobis rychlejsie (+ ti tu bude vediet vela ludi poradit)

zdravim..
byl by nekdo ochoten mi pomoct radama pri vyvoji prvni mobilni appky (rekneme takovy osobni mentoring, nechcu vsechny zatezovat zacatecnickyma dotazama)?
jsem se zarek, ze do toho musim vstoupit a nerad bych se vydaval nejakyma slepyma ulickama..
sehnal jsem si zakazku, ktera je ciste ucici, takze prakticky zadarmo, k tomu ucelu, aby me to dokopalo v danem terminu neco udelat..

jde o klasickou mobilni appku k malemu festivalu, tzn nejake profily ucinkujicich, mapku se stagema a lineup (tohle je minimum, ktere budu rad, kdyz zvladnu, nejake dalsi ficury bych pridaval az bude tohle hotovo a funkcni a zbyde cas)..

appka by mela byt nejmin pro android a iphone.

muze me nejak nakopnout, co k tomu ucelu nejlepe pouzit?
jsem ve stadiu, kdy bych chtel asi pouzit phonegap (kvuli cross-device) a uz jsem vystoural i nejaky hotovy klikaci lineup, ktery se jenom preskinuje, pripadne doladi, co nebude vyhovoat..

ale dal nevim vubec co. moje znalosti konci u jedne aplikaci pro jquerymobile, kterou jsem delal, ale ta bezela normalne pres url v browseru, coz ted nechcu.

nasel jsem si i nejaky predpripraveny phonegap skeleton (hello world), ale ten mi naposled nejak v mobilu padal, pak uz jsem nemel nervy :)

za kazdou radu budu vdecen, asi potrebuju trosku povodit za rucicku. navic na to neni uplne moc casu..

ze startu me teda zajima nejmin:
1/ ten phonegap je ok reseni (neni cas na to to psat zvlast pro iphone a pro android a i rozpocet se blizi nule. a taky bych se chtel naucit "standard" ktery pravdepodobne zuzitkuju i v budoucnu)?
2/ s jakou prodlevou bych mel pocitat ohledne tech appstoru vcetne develop registraci? aby se nestalo, ze festak probehne a oni to budou nejak validovat a nebude to k dispozici..?
3/ co dal? mam si udelat staticky "web", ktery strukturou odpovida te appce?

za jakekoliv rady diky. jak jsem psal na zacatku, tak pokud nekdo bude tak ochotny, ze bych veci mohl resit pravidelne i v prubehu vyvoje, budu radsi, kdyz mi napise do posty, nez vsechny otravovat tady..

VIRTUALVOID: DATEL: In memory pracovat často nejde, ale zkus si ještě metodu onSaveState. To jestli se ti fragment zničí nebo ne taky ovlivnuje jestli ho máš nastavenej jako retaintInstance. Tam ti pak zůstane stejná instance včetně instančních proměnnejch při přetáčení a podobných akcích, kdy ti jinak pouze zkusí zachovat state pomocí onSaveState ale instanci vytvoří novou.

DATEL: co sa tyka tej druhej otazky tak s tym ti neporadim. mozno len tak, ze by som si nacital vsetky data in-memory a zmeny robil iba on-demand.

DATEL: ja to robim tak, ze pridam vsetky fragmenty (cez kod, fragmentManager) do kontajneru cez metodu add (plus nejaky ten tag coby stringovy identifikator) a ten ktory chcem aby bol zobrazeny ako prvy dam show. tie ostatne hide.
vtedy sa to nerecreatuje. chce to teda, ale trochu viac kodu na handlovanie.

Díky všem za info. Měl bych další dotaz, respektive nejasnost. V originální dokumentaci o použití fragmentů (http://developer.android.com/training/basics/fragments/fragment-ui.html) je poznámka:

Note: When you remove or replace a fragment and add the transaction to the back stack, the fragment that is removed is stopped (not destroyed). If the user navigates back to restore the fragment, it restarts. If you do not add the transaction to the back stack, then the fragment is destroyed when removed or replaced.

Já při výměně fragment dávám do back stacku, ale i přesto když pak vyměňuju fragment, tak se mi na tom původním volá onDestroyView a po "uzavření" nového fragmentu (což je formulář pro novou položku) zavolám getSupportFragmentManager().popBackStack(); a pak se tedy pro původní fragment volá onCreateView atd.

Další věc, co při konverzi na jednu aktivitu začala zlobit, je uzavírání kurzoru a databáze ve fragmentu pro seznam. Dokud jsem otevíral ten formulář pomocí aktivity, tak to jakžtakž fungovalo (viz. předchozí příspěvky), ale když jsem to předělal, tak mi při vyvolání nového fragmentu (s formulářem) aplikace spadla s výjimkou "attemp to re-open an already-closed object" a týkalo se to právě toho kurzoru. Jenže vůbec netuším, proč. Dal jsem si breakpointu do všech metod a padá to po onStop ve fragmentu se seznamem. To uzavření kurzoru a DB je v onPause. Přitom ten onStop proběhl v pořádku. Do onDestroyView mi debugger už nedošel a snažil se otevírat vnitřní zdrojáky Androidu, které tam nemám. Máte nějaký tip, na co se podívat?

Každý přístup je dobrý pro jiné použití. Teď například dělám aplikaci, kde hlavní aktivita spravuje loading v intervalech pomocí loaderu a na ní pouze vyměňuju spoustu fragmentů. Ty pokud mají nějakou akci, tak jí přidají do fronty a aktivita jí odešle na server a o výsledku (změně dat) notifikuje všechny observery, takže si každý fragment může obnovit data. Stejně tak po každý loadu na aktivitě jde notofikace pro observery.

Ale implementovat všechny metody na aktivitě mi nakonec přišlo většinou jako zbytečný datlování a o nějakým decouplinfu se tam moc nedalo mluvit.

DRIZDIK: hm, zajímavé, takže každý fragment máš v podstatě samostatný "blackbox", který funguje kompletně sám o sobě včetně načítání a ukládání dat? Zatím jsem právě všude viděl (knihy, tutoriály i android dokumentace) to, že se má ve fragmentu vytvořit interface, který aktivita musí implementovat a tyhle ukládací věci se pak dělají v aktivitě. Na druhou stranu tvé řešení má výhodu, že fragment je opravdu samostatná jednotka, kterou když přesunu do jiné aktivity, tak by měla víceméně fungovat, aniž bych musel přenášet i metody z jedné aktivity do druhé.

No, tak teď fakt nevím, kterou cestou se dát :)

DATEL:
já tohle řeším tak, že tyhle data (nejlépe pouze id) předám fragmentu v Argumets bundlu. Fragment se poté sám postará o zobrazení progress, načtení na pozadí vlastním loaderem a zbrazení případně uložení. Snažím se ho jako funkční celek oddělit od aktivity, aby byl použitelnej i na jíném místě.
Mezi fragmenty komunikuju pomocí Observer patternu a funguje to relativně dobře.

Rozdělení na je celkem na tobě. Někdo se snaží vše řešit v jednom, někdo odděluje, aby se zachovávali intenty, které ti pak pomůžou pži zabití aktivity obnovit předchozí stav - to je velice důležitý.

VIRTUALVOID: super, tohle je mi už jasný, díky :)

DATEL: co zoznam, to aktivita. urob niekde menu/zoznam, ake veci vlastne chces urobit. potom si sprav mockupy...

alebo inak to skusim napisat: co typ entity to samostatna aktivita+fragmenty

VIRTUALVOID: VIRTUALVOID: Ok, tomu rozumím, ale pokud ta aplikace bude mít více různých seznamů, formulářu apod., tak v té hlavní aktivitě by ty akce mohly narůst velice rychle a ten počet 40 překročit. Ono už vlastně i to, že aktivita implementuje události fragmentů např. pro uložení dat po odeslání formuláře, naplňování formulářů z daty atd., způsobí její nabobtnání. Nebo co by vlastně samotný fragment měl všechno řešit? Pouze obsluhu svých View (eventuelně otevírání dalších aktivit/dialogů, např. pro výber datumu)? Veškeré ukládání dat pak předává právě aktivitě.

hlavna aktivita by potom mala riesit cez callbacky operacie daneho fragmentu

DATEL:
Na jednu stranu pokud je mám všechny v jedné aktivitě, tak bude jednodušší komunikace mezi fragmenty, na druhou stranu, kdyby byla aplikace rozsáhlejší, tak mít všechno v jedné aktivitě je podle mě taky nesmysl.

nieje to nezmysel. pretoze by si nikdy nemal mat 40 akcii v jednej aktivite, ale nejak logicky to rozdelovat.

ja som doteraz vzdy siel cestou hlavna aktivita + jej logicky patriace fragmenty.
v tomto pripade :
hlavna aktivita :
- fragment pre zobrazenie v liste
- fragment pre editaciu/zobrazenie detailu

na editaciu / detail nepotrebujes dva rozne fragmenty... len ked dany zaznam budes otvarat ako detail tak nastavis textboxy,etc. ako readonly. napr.