DRIZDIK: její zdrojáky ksou někde k dispozici? Myslel jsem, že to je close-source...

By mě zajímalo, jak to dělají ostatní aplikace, že by každá používala NDK knihovnu pro jpeg se mi moc nezdá, třeba takové Postisimo... No zkusím najít ty zdrojáky gallery aplikace, díky za tip.

DATEL: Kouknul bych se, jak to má implementovaný gallery aplikace.

DATEL: Do toho už se nevejdeš od 4Mpix při dekódovaný bitmapě. Takže musíš uvažovat určitě něco. Nikdy jsem to nedělal, ale asi bych dal na pozadí nějak hodně downsamlovanej obrázek a potom přes něj zobraoval jen správně nasamplovanej výřez. Pomocí matrixu to bude bez problémů scalovat a na pozadí budeš přepočítávat podle aktuálního scalu nově nasamplovanej orbázek, kterej bude odpovídat tomu, co se ti vejde na obrazovku.

DRIZDIK: potřebuju to pro zpracování fotek z telefonu, nevím, jaké je dneska maximum, 12Mpx? Dá se na tohle ještě použít ten matrix nebo ten je vyloženě jen pro bitmapy do těch cca 16 MB v paměti?

DATEL: Scalování velkých obrázků přes matrix jsem používal, ale pokud bys měl něco opravdu velkýho tak narazíš na OutOfMemory a musíš do toho ještě přidat dynamický resamplování používat pokud možno RGB565 pro ušetření paměti atd. Někde jsem na to viděl článek, když jsem to řešil, ale nemůžu to najít.

Prosím vás, nemáte někdo náhodou odkaz na nějaký ucelený popis problematiky dynamické práce s velkými obrázky? Myšleno zoomování, výřez (posunování) pomocí gest atd. Jak zmenšovat velké obrázky staticky vím. Prolezl jsem kupu odkazů, ale většinou se jedná o příklady jak implementovat gesta pro zoom (tohle mě zajímá až v druhé řadě).

V podstatě jsem narazil na dvě věci - libjpeg-turbo pomocí NDK (nemám absolutně zkušenost) nebo v některých příkladech používali u webview "matrix", což ještě nemám prozkoumané. Je případně ta matrix cesta, kterou potřebuju?

LITTLELI: dobry tip - diky

MRAKY: no nevím, tohle je ztráta 3-4 dnů času, prostě si k ní sedni a začni ji používat. Třebas docela užitečné může být že v menu Help/Default Keymap Reference je plachta se všema možnýma zkratkama. Pak je tam Productivity guide, který ti říká jak můžeš zlepšit svou práci v tom IDE. No a dost možná se můžeš podívat co to má za fičury z nějakých těch screencastů na http://tv.jetbrains.net/channel/intellij-idea

MRAKY: http://developer.android.com/sdk/installing/studio.html Já to všechno bral odsuď a přišlo mi to dobrý.

nez se pustim do vlastniho zkoumani - znate nekdo ucelenou knizku/ zdroj , popisujici android studio pro cloveka co nezna intelij? nejaky uceleny set rad, doporuceni, seznam zkratek pro zefektivneni prace atd...

DATEL, DATEL: tak chyba objevena - v té vyhledávací podmínce nemá být _ID, ale CONTACT_ID:

String where = ContactsContract.Data.CONTACT_ID + " = "
        + uriData.getLastPathSegment()
        + " AND " + ContactsContract.Data.MIMETYPE + " = '"
        + ContactsContract.CommonDataKinds.StructuredPostal.CONTENT_ITEM_TYPE
        + "'";

DATEL: v tom where je chyba, to "ContactsContract.Data.MIMETYPE" samozřejmně nemá být uvnitř řetězce, ale má být připojen. Pak podmínka vypadá správně takhle:

_id = 14 AND mimetype = 'vnd.android.cursor.item/postal-address_v2'

Nicméně to stejně pořád nic nevrací.

Ahoj, potřeboval bych poradit s načtením detailu kontaktu ze systémové databáze. Prošel jsem kupu diskuzí a všude je to v podstatě stejné:

    Uri uriData = data.getData();

    String where = ContactsContract.Data._ID + " = "
            + uriData.getLastPathSegment()
            + " AND ContactsContract.Data.MIMETYPE = '"
            + StructuredPostal.CONTENT_ITEM_TYPE
            + "'";
    Log.d(TAG, "where: " + where);

    String[] projection = new String[] {
            StructuredPostal.STREET,
            StructuredPostal.CITY,
            StructuredPostal.POSTCODE,
            StructuredPostal.REGION,
            StructuredPostal.COUNTRY};

    Cursor cursor = getActivity().getContentResolver().query(ContactsContract.Data.CONTENT_URI,
            projection,
            where,
            null,
            null);
    if (cursor.moveToFirst()) {
        mEtStreet.setText(cursor.getString(0));
        mEtCity.setText(cursor.getString(1));
        mEtPostcode.setText(cursor.getString(2));
        mEtRegion.setText(cursor.getString(3));
        mEtCountry.setText(cursor.getString(4));
    } else {
        Log.e(TAG, "nic nenalezeno");
    }

    cursor.close();

Log pro "where" je např.:

where: _id = 14 AND ContactsContract.Data.MIMETYPE = 'vnd.android.cursor.item/postal-address_v2'

To ID je získáno z intentu:

Intent intent = new Intent(Intent.ACTION_PICK, ContactsContract.Contacts.CONTENT_URI);
startActivityForResult(intent, 1);

V adresáři mám testovací 3 kontakty, pouze lokální v telefonu. Každý kontakt má adresu, ale pokaždé jiný typ (doma, práce, jiné). Problém je, že kurzor je vždy prázdný. Chybu tam nikde nevidím a tento postup byl většinový.

DRIZDIK, DRIZDIK: super, díky moc za objasnění! Jdu zrušit předávání entity přes argumenty :)

DRIZDIK: Tam si ale zase hodně fieldů už stavu udežuje samo, protože na každém view se volá onSaveInstanceState automaticky, ale když máš třeba nějaký robalovačky v layoutu nebo složitější logiku, tak si stav uložíš pomocí onSaveIntance

DATEL: b) je správně ;-)
saveInstance je na fragmentu třeba pro formulářový pole, který bys měl změněný oproti původnímu stavu a další věci nezávislý na datech (entitě), entitu určitě nedávat do saveInstance.
Arguments je třeba kdybys měl list entit a chtěl říct, že tenhle fragment zobrazuje ID 10, tak si desítku předáš v arguments, změníš jeden field a otočíš displej, tam je saveInstance na řadě

DRIZDIK: DRIZDIK: díky za objasnění. Akorát mi teda do toho zas nepasuje ten můj původní problém, že z aktivity předávám entitu do fragmentu přes Parcelable objekt a pak ji znovuvytvářím. Jsou tedy dvě možnosti:

1. skutečně používat pro entitu Parcelable, a to jak při vytváření fragmentu (getArguments), tak při ukládání stavu (onSaveInstanceState)

2. krom jiných způsobů použít třeba to co jsem psal, tj. aktivita implementuje rozhraní, které fragment vynucuje (kontrola v onAttach), a pak si fragment sám načte entitu z aktivity, ukládá do ní data, a tedy není potřeba (pokud to není potřeba pro jiná data) entitu ukládat pomocí onSaveInstanceState a vytvářet pomocí getArguments atd. Akorát teda... když to tak píšu, tak to asi není úplně správné řešení z hlediska používaných vzorů, ikdyž je to zase rychlé a jednoduché řešení.

Je obecně akceptovatelný postup bodu 2?

Dulezity je tam, ze se budes spolehat pouze na neparametricky konstruktor.

DATEL: Nainicializujes z Arguments a pokud neni null, tak prepises z savedInstance