Forumul organizatiei Pontes - www.pontes.ro

După cum am spus în topicul Simulator de zaruri pentru Android, am reuşit să învăţ cum se fac programe pentru acest sistem de operare.
Deschid acest topic pentru diverse informaţii legate de programarea pentru Android, la început prezentând succint felul în care se creează o aplicaţie şi modul de accesibilizare a acesteia.

Deşi la început părea complicat şi aparte faţă de ceea ce am făcut până acum, pot spune că în cele din urmă sunt familiarizat cu Java aplicat cu Android SDK.

Pentru a începe, este nevoie de un IDE cu Android SDK. Ei au ales Eclipse ca IDE, exista varianta Eclipse ADT Bundle (Android Development Tools).
Acest pachet care conţine IDE-ul şi SDK-ul poate fi găsit la:
https://developer.android.com/sdk/insta ... ml?pkg=adt
În prezent Google lucrează la un alt IDE numit Android Studio, acesta fiind încă la o versiune 0.x, dar toate informaţiile de pe internet sunt prezentate pentru Eclipse, el fiind deja de ani de zile de bază în acest caz.

După ce se instalează totul conform instrucţiunilor, după ce se reuşeşte activarea opţiunlor dezvoltator pe telefon şi se activează USB Debugging pentru lansarea aplicaţiei pe telefon ca terminal de testare, se poate demara programarea propriu-zisă.

Paşii sunt următorii, nu intru în detalii de programare:
- Dupa instalarea uneltelor, se creează un proiect Android nou.
- Se scrie codul şi se are în vedere ca mesajele, string-urile să fie plasate într-un fişier XML din folder-ul Values aflat in Resources, interfaţa se află într-un folder Layout, tot din Resources, la fel imaginile în folderul Drawable, meniurile in Menu etc.
- Dupa finalizarea aplicaţiei, trebuie generat cu KeyTools un certificat unic cu parola, acesta trebuie păstrat cu grijă, o aplicaţie nu poate fi semnată cu alt certificat fara să fie considerată ca una nouă.
- La semnare se mai fac nişte retuşări pentru eficientizare, e vorba de un proces numit Zipalign. Îl face IDE-ul.
- Se pune aplicaţia în magazin, unde este nevoie de tot felul de capturi de ecran, pictogramă de înaltă rezoluţie, descrieri şi, desigur, fişierul APK de uploadat.
- În câteva ore, aplicaţia poate fi găsită la o căutare în magazin.

Pentru a deschide un cont de dezvoltator la developer.android.com, trebuie achitată o taxă iniţială de 25 de dolari; se plăteşte o singură dată la început, apoi totul este gratuit. Fără acest cont, nu se pot distribui aplicaţii prin magazin, ci doar fişiere APK prin modalităţi proprii de promovare.


Revenind la detalii, scriu puţin despre interfaţă, lucrul care ne interesează în general, mai ales dacă suntem utilizatori de cititor de ecran (screen reader).
Interfaţa de obicei este partea care diferă cel mai mult de la un sistem de operare la altul, Android alegând un mod practic, dupa părerea mea, uşor de întreţinut şi de modificat.

Sunt două modalităţi de a realiza interfaţă - static (fişier XML) şi programatic / dinamic (direct în cod Java).

Interfaţă în XML
O fereastră în Android, de cele mai multe ori reprezintă o aşa-zisă activitate. Fiecare astfel de activitate are în spate un fişier XML care conţine interfaţa sub formă de elemente părinte - copil. De exemplu, părintele este un layout linear, iar in el pot fi butoane, check-box-uri, radio-butoane, etichete de text sau chiar alte layout-uri etc.

Un exemplu schematic ar fi: Toate aceste elemente au o mulţime de atribute de forma android:attribute="value".
Am adus prezentarea aici pentru a explica faptul că, dacă printre acele elemente se află de exemplu o imagine, foarte uşor i se poate pune un atribut special pentru Talkback, astfel încât atunci când se ajunge la ea prin navigare, acea descriere să fie anunţată.
Nu trebuie decât scris:
android:contentDescription="Descrierea mea"
Talkback va anunţa "Descrierea mea" când se ajunge pe imagine sau orice alt element ar fi. Nu apare absolut nimic pe ecran pentru a strica design-ul, deci e foarte simplu şi practic, doar programatorul să ştie ce are de făcut ca să ofere accesibilitate.
În cazul elementelor pe care apare text, cum ar fi TextView sau Button, există desigur atributul
android:text care primeşte ca valoare un text oarecare, de obicei unul declarat în alt XML care este în folderul values.
De exemplu:
android:text="@string/my_text"
Acel my_text este numele stringului din Strings.xml.
De multe ori cel care creează programul pune la butoane imagini, fapt care face sa omită atributul android:text sau poate intenţionat nu vrea să apară şi text. În acest caz, merge din nou atributul android:contentDescription care face ca utilizatorul nevăzător să audă un text ca şi cum ar fi scris acolo.

Un buton din interfaţa zarurilor mele arată aşa, nu are nevoie de contentDescription pentru Talkback: Acel @string/button_throw face referire la un string cu numele button_throw care are la limba română valoarea "Aruncă!".
Fişierul XML cu stringurile este în folderul Values din Resources, daca se creează tot acolo un folder numit values-ro şi este copiat acelaşi string.xml tradus, interfaţa va apărea în română atunci când telefonul este setat ca limbă pe română.


Interfaţa în mod programatic
Toate elementele UI pot fi create şi într-un mod programatic, direct în cod cu tot felul de metode, fiecare element fiind un obiect.
În acest caz, cele două atribute din XML android:text şi android:contentDescription au metodele corespunzătoare:
.setText() şi .setContentDescription().

Astfel cum zarurile sunt generate dinamic ca imagini şi se plasează doar într-un LinearLayout din fişierul XML, va trebui pentru a fi citite de Talkback să fie aplicată metoda .setContentDescription cu descrierea (numărul zarului) ca string la parametru.

Pun mai jos codul aproximativ de generare a zarului cu numărul 6 în aplicaţia mea: Pe penultimul rând nu am făcut decât să accesibilizez zarul.
Codul pare poate greoi, dar l-am pus doar ca exemplu pentru cine programează, să vadă ce uşor poate fi accesibilizat un element de interfaţă.


Sunt multe de spus, în mesajul următor voi scrie concis strict despre acel contentDescription, mesaj ca să poată fi trimis dezvoltatorilor ca solicitare de accesibilizare.
Sunt de exemplu jocuri de Yahtzee accesibile, singurul lucru care nu este citit fiind zarurile. Ei bine, daca dezvoltatorul ar avea chef 5-10 minute, ar adăuga acel .setContentDescription() la ImageiView şi jocul ar deveni accesibil în totalitate.
Daca se mai apucă cineva de Android, aici putem discuta, ne putem da sfaturi etc.

Mai jos pun un posibil mesaj de trimis cuiva care dezvolta aplicatii Android si nu a apucat sa faca in asa fel incat toate elementele GUI sa fie citite de Talkback.
Mesajul poate fi modificat astfel incat sa fie cat mai apropiat de subiect, de specificul aplicatiei sau al jocului in cauza, important e modul propus. Teoretic orice aplicatie, chiar si joc tip sah sau table poate fi usor accesibilizat, daca cel care programeaza are chef sa deschida IDE-ul sa puna cateva randuri.
Am vrut doar sa stie omul ce sa ceara, uneori programatorul nu are rabdare sa caute daca i se spune doar atat: accesibilizati-mi acel joc sau program. Dar daca vede ca doar pune un rand care i se si arata, poate va avea mai multa bunavointa.


In limba romana:
Daca ati dori, ati putea accesibiliza programul dumneavoastra in doar 5-10 minute, astfel incat sa fie utilizabil de catre un nevazator care "vede" ecranul ajutat de un cititor de ecran (Talkback).
Modificarile aduse nu au nici un efect vizual, textul care descrie o imagine sau un buton grafic fiind ascuns, citit doar de Talkback.
In primul rand, elementele grafice tip TextView, Button sau CheckBox pot avea un text setat in XML, pentru aceasta existand atributul:
android:text="denumire_element"
In mod programatic un text poate fi setat cu metoda setText().
Avand de exemplu elementul tv ca obiect de tip TextView, se poate scrie:
tv.setText("denumire_element");
Cand este vorba de imagini, cum ar fi carti dintr-un pachet sau zaruri, ori butoane care au in loc de android:text doar imagini, se poate utiliza in XML Layout atributul
android:contentDescription="Descrierea mea"
Pentru a seta programatic o descriere, exista metoda setContentDescription().
Avand de exemplu mImage ca obiect ImageView, se poate scrie:
mImage.setContentDescription("Descrierea mea");
In cazul contentDescription nu se schimba nimic la interfata, ci sunt citite elementele de catre Talkback, cititorul de ecran utilizat de nevazatori.
Aceasta metoda se foloseste si in cazul unor butoane care au ca eticheta imagini si nu text simplu precum cel stabilit cu android:text sau .SetText().


In limba engleza:
If you would like to make your app accessible for blind users, you can do it in 5-10 minutes without changing the GUI.
Blind users read the interface using a screen reader (Talkback) which cannot detect an element like TextView, Button or Image if there is no an android:text or android:contentDescription attribute in a XML Layout file.
To add a text to a TextView or Button, you can write as attribute in the XML Layout file:
android:text=”My text”
To add a text programmatically, there is a method – .setText(). If you have the object tv as TextView, the line below adds a text to it:
tv.setText(“My text”);
This text is visible on the screen.
There is also the possibility to add descriptions only for Talkback, they don’t appear on the screen.
There is the attribute for an XML element:
android:contentDescription=”My description”
To add a description programmatically, use the method .setContentDescription(). For instance, if you have mImage as an ImageView object, you can write:
mImage.setContentDescription(“My description”);
This method is good also if you have buttons with graphics instead text on them.
Following the steps above, it is possible for a blind user to read an image like a die, or a card in games like Yahtzee or Black Jack.

Felicitari pentru program. Ce anume face acel Android Developer Tools? Doar compileaza programul? Ma gandesc ca daca face ceva mai multe, inclusiv cu interfata Eclipse, adica sa ajute la crearea codului, cam cum face Visual Studio, atunci ar fi foarte bine daca atributul ContentDescription ar fi adaugat automat ca sa le sara in ochi dezvoltatorilor si sa fie nevoie doar sa adauge acolo textul care trebuie citit. Daca ar fi asa atunci sigur mult mai multe programe ar fi mai accesibile chiar fara ca dezvoltatorul sa isi bata capul.

Intr-adevar, codul pare greoi, dar cam asa sunt toate codurile scrise in Java, mai ales ca dupa cate observ, foloseste la greu XML, care este un limbaj de codare extrem de puternic si flexibil, dar si extrem de "verbose" si urat.
De curiozitate, de ce incep oare toate atributele XML cu "android:"? Adica, ajuta la ceva? Se pot defini si alte atribute de catre dezvoltator si se doreste un spatiu de nume distinct pentru cele ale androidului ca sa nu existe conflicte de nume?

Oare mediul de dezvoltare la care lucreaza Google va fi accesibil pentru orbi?

Da, e de fapt un plugin de Eclipse care ajuta si la crearea codului, adica sugereaza, semnaleaza, da tot felul de warnings cum ar fi: variabila cutare nu este folosita niciunde, atributul text este declarat literal, nu intr-un strings.xml.
Ar fi probabil ceva foarte simplu sa spuna la fiecare element fara atribut text ca ar fi bine sa ii fie pus contentDescription.
Ar trebui probabil sa vorbim cu astia, sa le sugeram sa bage la warnings contentDescription. Astfel ar fi toate programele accesibile. Cine stie, poate s-au gandit si ei...
Faptul ca Google a introdus aceasta posibilitate inseamna ceva, usureaza munca.
Am vazut programe inc are desi era etichetat cu text un buton, contentDescription spunea ceva in plus despre functionalitate, astfel ca nevazatorii aveau un ajutor aditional.
Desigur ca totul se poate face si din linie de comanda, compila, certificatul tot din linie de comanda, nu am reusit sa il conving pe Eclipse sa il genereze scriind el in locul meu siruri lungi, nu am avut rabdare sa setez environment path si ce stiu mai ce. Dar cine ar folosi IDE, ar fi tot timpul batut la cap sa nu uite de contentDescription, si nici nu ar fi ceva agresiv, avand in vedere ca nu trebuie aduse modificari design-ului.


Incep cu android toate atributele care au legatura cu SDK-ul lor, design, manifest etc; in rest mai sunt XML fisierele pentru string-uri, acolo fiecare mesaj arata asa:
<string name="hello_message">Bine ai venit!</string>
Tot in XML este de exemplu si fisierul manifest unde se declara tot felul de lucruri, cum ar fi versiunea minima si maxima de Android pe care sa se instaleze programul, drepturile pe care le necesita, ce componente hardware sunt necesare. De exemplu pentru a scrie ca zarurile au nevoie si de Accelerometru, dar nu este chiar obligatoriu, se scrie in manifest.xml:
<uses-feature android:name="android.hardware.sensor.accelerometer" android:required="false" />
Oricum, in general se insista pe declararea variabilelor dintr-un program cu un prefix unic, la Java in general acel package este tot unic, iar astia in magazin asa si il pun ca un fel de id, cheie primara, pe acel package care in cazul meu este la zaruri ro.pontes.pontesdice, adica un fel de adresa web inversa, asa se recomanda.
In magazin asa si este adresa, URL-ul avand in final:
id=ro.pontes.pontesdice.
Probabil mai pot fi utilizate tot felul de biblioteci unde ar putea fi de exemplu si atributul text, asa or fi gandit ca android:text este unic, e clar ca vine din SDK-ul lor, nu sunt dubii.


O sa incerc de curiozitate Android Studio, poate saptamana viitoare cand vin din statiune.
Eu sper sa fie accesibil, cel putin mai accesibile meniurile decat cele din Chrome. Si sa mearga ok si campul mare de editare cod. In Eclipse e ok, pot si selecta bucata cu bucata, se opreste cursorul la semne, chiar si la literele mari utilizate in stiul camel case.
Tot Google se pare ca lucreaza si la varianta de Eclipse cu ADT, la ei in manual se vorbeste peste tot despre cum se face un lucru in Eclipse, acum in ultimul timp mai pun ca o a doua alternativa a unei explicatii: sau in Android Strudio.

Sigur ca ar fi de acord sa adauge si acea avertizare care ar putea face programele mai accesibile. Nu stiu daca s-au gandit, mai ales ca Google nu are un stil de lucru bazat pe accesibilitate de la inceput, ci doar ca un pas secundar. Asa ca nu ar fi rau sa le spui daca gasesti vreo modalitate de contact, fiindca de obicei cei de la Google nu sunt nici prea usor de contactat. Nu sunt prea multi programatori orbi in general, iar pentru Android la fel, asa ca speranta ca sigur va da altcineva idea s-ar putea sa duca la multe amanari. Oricum, daca o facilitate este ceruta de mai multe persoane are sanse mai mari sa fie adaugata.

In ceea ce priveste oferirea unui text diferit pentru cititoarele de ecran decat cel afisat pe ecran... cred ca este greu de spus daca este bine sau rau. Uneori e bine fiindca din textul afisat nu se intelege la ce este bun, alteori este rau fiindca orbii spun ca pe ecran apare ceva dar vazatorii spun ca apare altceva si nu gasesc ce spun orbii ca ar trebui sa apara si invers asa ca apare o problema de comunicare in plus.

Asa este. Eu ma gandeam ca poate acel plugin ofera ceva mai multe facilitati, inclusiv de generare de cod, ca Visual Studio, dupa cum spuneam. Adica sa apara de exemplu un toolbar cu butoane ca "Adauga imagine", "adauga buton" etc. Iar cand le apesi sa genereze codul pentru crearea unui buton, cod care sa aiba si acel atribut. Daca insa acel plugin doar face o validare si face diverse avertizari, atunci este mult mai simplu de facut acea verificare si alertat in caz ca unele elemente nu au respectivul atribut.
Cel putin avertizarea ar trebui sa se faca atunci cand nu se ofera un alt text. Adica daca un buton are un atribut text dar nu are contentDescription atunci sa fie OK fiindca butonul va fi accesibil.

Eclipse este facut cu SWT care foloseste clasele grafice native pentru feicare sistem de operare pe care este rulat, iar asta ne avantajeaza pe noi fiindca acele clase sunt foarte accesibile pentru Jaws. Daca Android Studio va fi facut cu altceva, de exemplu cu SWING daca e creat in Java, sau cu cine stie ce alta clasa grafica, sau facut cam cum e facut Chrome, atunci s-ar putea sa nu fie prea bine. Dar oricum, asta nu va insemna ca nu se poate folosi in continuare Eclipse sau orice alt editor si compilat in linia de comanda sau din interfata acelui editor.

Nu imi dau seama care este sistemul de internationalizare a interfetelor daca se foloseste XML pentru asta. XML este el flexibil, dar pentru internationalizare pare destul de inflexibil.

De exemplu, sa spunem ca vrei sa scri fraza urmatoare, in romana si engleza:
You need to pay 10 dollars.
Trebuie sa platesti 10 dolari.

Iar "10" este o variabila care poate fi orice numar, deci frazele de mai sus pot deveni si:

You need to pay 1 dollar.
Trebuie sa platesti 1 dolar.

Sau exista alte exemple in care in functie de limba partea variabila este la inceputul frazei iar in alte limbi la sfarsitul frazei.

Acestea sunt simplu de rezolvat cu sisteme de internationalizare de genul gettext, maketext, dar cu XML nu prea vad cum sa le rezolvi decat daca adaugi cod de programare in care verifici de fiecare data daca variabila este egala cu 1 sau este mai mare, sau daca este zero si in functie de asta afisezi un alt string, plus ca uneori trebuie sa combini intre ele diverse stringuri in mod diferit in functie de valoarea elementelor variabile etc.

Sau varianta de definire a stringurilor in fisierul XML pe care ai aratat-o este varianta mai simpla dar ofera si posibilitatea definirii a diverse variante pentru aceeasi cheie in functie de valoarea diverselor elemente variabile?
Desi ma rog, pentru aplicatiile pentru telefon s-ar putea sa nu conteze prea mult...
Bine ca Java este macar foarte accesibila si sub Windows, nu ca Objective C sau Swift.

Voi raspunde cand ajung in Cluj, de pe telefon e mai greu de scris mai mult, chiar cu o tastatura atasata. Permit multe si aceste XML-uri, sunt posibilitati pentru valoarea numarului de itemi ca sa se acorde etc.

Apropos de tastatura, nu exista oare un adaptor pentru tastatura PC ca sa se poata accesa cu ea un telefon care ruleaza iOS sau Android?
Pentru orbi ar fi excelent. Am cautat despre asta dar nu prea am gasit nimic incurajator.

Referitor la tastatura USB:
http://www.makeuseof.com/tag/how-to-con ... -keyboard/

ALtfel, se pare ca in anumite conditii eclipse da warning pentru lipsa contentDescription:
http://stackoverflow.com/questions/9363 ... escription
http://stackoverflow.com/questions/9730 ... age-in-xml

Android studio nu e accesibil, am incercat eu. Am contactat creatorii orginali, pentru ca el e bazat pe IntelliJ Idea, si n-am primit deloc un raspuns incurajator.

E foarte bine daca deja s-au gandit sa faca acea verificare in Eclipse. Probabil ca cei care au creat programele cu controale inaccesibile ori nu au folosit Eclipse, ori au fost create inainte de a fi adaugata acea facilitate la plugin.

Mda, banuiam eu ca Google nu isi vor dezminti dezinteresul profund pentru ceea ce nu se adreseaza publicului larg.

Sa speram ca ramane si Eclipse ca ide de baza si nu au in cap astia sa faca in asa fel incat sa fie nevoita lumea sa treaca pe Android Studio.
Acum doua saptamani cand am facut un Update la SDK, nu a mai functionat nimic cum trebuie in Eclipse, imi tot spunea ca trebuie sa se actualizeze si IDE-ul, dar cand cautam actualizari, nu se intampla nimic, nu reusea sa aduca toate lucrurile la zi in asa fel incat sa fie din nou sincronizate si functionale.
Am inceput sa caut pe forumuri si exact asta scriau multi: "poate ca Google considera ca deja ar fi cazul sa se treaca pe Android Studio". A trebuit sa salvez proiectul si sa reinstalez totul in urma descarcarii pachetului Eclipse ADT.
Deocamdata, ca IDE, Eclipse este poate cel mai accesibil, ma refer la cele care sunt bune pentru multe limbaje si sisteme. Multi merg de exemplu cu NetBeans, chiar si la UTC tot el este considerat de baza chiar si pentru PHP. Eu l-am instalat candva si nu imi citea nimic pe acolo...

Probabil s-au gandit totusi astia la avertisment pentru contentDescription, dar se pare ca nu in cazul plasarii unor elemente in mod programmatic, ci doar in XML. Problema e ca decele mai multe ori nu sunt citite lucrurile care se schimba, cum ar fi zarurile intr-un joc.
O sa caut si eu mai multe despre avertizarile posibile, sa vedem in ce conditii sunt afisate.

Eclipse este accesibil pentru noi fiindca foloseste interfata Java SWT, dar majoritatea prefera interfata SWING care depinde doar de Java sau alte interfete care nu depind de o biblioteca separata pentru fiecare sistem de operare in parte. Doar ca acelea noua ne sunt mai greu accesibile sau deloc accesibile.

Daca se va dezvolta in continuare pluginul pentru Eclipse... depinde cine il creaza, daca este open source sau nu etc. Daca este creat de Google si nu de un grup care eventual sa includa si firma Google, atunci viitorul nu prea suna bine. Teoretic daca este open source vor putea altii sa il dezvolte, dar va fi intotdeauna cu un pas in urma daca nu va fi sustinut activ si oficial de Google.

Probabil ca Google vrea sa isi creeze propriul mediu de dezvoltare si din cauza ca le-ar fi mai usor sa il actualizeze fara sa apara problemele de care spuneai.

Asta nu inseamna ca orbii care vor sa creeze programe pentru Android nu o vor mai putea face. S-ar putea insa sa aiba ceva mai mult de lucru.

Chiar si daca se pune warning la ContentDescription, unii il ignora. E o vorba printre anumite cercuri de programatori: "daca se compileaza, e perfect!".
Din cauza asta unii propuneau sa se puna ca error, sa nu compileze pana nu pui aia.

Desi se compileaza, totusi nu te lasa sa exporti APK-ul atata vreme cat mai exista Lint Errors, asa numesc astia erorile, ma rog warnings de acest fel, cele care tin de Android.
Dupa cum aparea si in acea intrebare de pe StackOverflow ajutorul dat de cineva era sa mearga la Lint Errors Check, si sa dezactiveze contentDescription. Sunt foarte rigurosi astia, ca sa ajungi sa exporti un program fara sa dezactivezi Lint Errors... ai ceva de lucru ca te si miri la ce maruntisuri apar. La mine de exemplu, am utilizat string literal in "fereastra" (activitatea) unde se alege numarul de zaruri. Practic am pus android:text pentru cele 6 radio butoane simplu numerele 1, 2, 3, 4, 5, 6, fara sa le declar in strings.xml, m-am gandit ca sunt lucruri care nu se traduc in alte limbi, si am si vrut sa pot face usor cu un for diferite lucruri cu cele 6 radio butoane. Ei bine, asta e bagata la Warning si sigur si la Lint Erros, eu am dezactivat verificarea pentru ca imi dadea ceva ce nici nu as fi stiut sa rezolv, ceva legat de un hash, sigur nu ar fi pus probleme in programelul acesta.
Din cate am vazut, unii au ambitia sa exporte apicatia rezolvand toate aceste probleme, warnings si Lint Errors, atunci tot intreaba de diverse lucruri, cum sa fie rezolvate; cel mai frecvent raspunsul este precum cel dat ca exemplu de Vortex de pe StackOverflow, ca programatorul sa dezactiveze verificarea specifica.

Sigur, intotdeauna vor exista unii care vor sa scape cu cat mai putine batai de cap, dar in ansamblu cred ca daca uneltele de programare folosite forteaza si enerveaza cu tot soiul de erori si avertismente, atunci multi care poate ca habar nu au despre problema accesibilitatii vor incepe totusi sa respecte regulile.

Dupa cate am inteles din acea problema anuntata pe stackoverflow, programatorul nu vroia sa dezactiveze toate avertismentele de eroare, ci doar in acel caz in care un obiect continea atributul contentDescription dar i se cerea ca si parintele sa aiba acel atribut.

O intrebare similara si-o pun unii si despre html, daca imaginea contine un atribut alt iar imaginea apare intr-un link care are definit un atribut title, care dintre cele doua va fi citit de cititorul de ecran?
In acest caz ar fi ca si cum ar aparea undeva un avertisment ca linkul nu contine un atribut title si nici o eticheta de tip text, ci doar o imagine, doar ca acea imagine contine un atribut alt care este suficient.

Cu alte cuvinte verificarea facuta de pluginul Eclipse nu este chiar atat de avansata incat sa stie ca daca de exemplu un buton nu are contentDescription ci doar contine o imagine, este totusi OK daca acea imagine are un atribut ContentDescription.
Sau ma rog, eu nu stiu, poate ca exista motive pentru care chiar nu e OK, si trebuie sa aiba ambele contentDescription, desi ar fi cam ciudat, sau poate ca recomandarea este ca butonul sa aiba ContentDescription si nu imaginea...

Oricum, idea de baza este ca e foarte bine ca exista astfel de avertizari. Fara ele multe programe ar fi sigur mai greu accesibile pentru orbi.

Am facut acum proba cu un view numit ImageButton si intr-adevar, da avertisment daca nu are contentDescription. Am verificat pe telefon si Talkback anunta "Buton 49", este exact tipul de buton pe care il gasim in diverse aplicatii si pe care l-am putea eticheta daca am sti ce e cu el.
Avertismentul afisat este:

[Accessibility] Missing contentDescription attribute on image Category: Accessibility, Location: activity_other_settings.xml:22 in layout (PontesDice)

Am mers in acel XML si am ales din meniul context pentru aceasta problema optiunea Quick Fix, dupa care a aparut urmatoarea lista de posibilitati:

Add content description attribute
Explain Issue (ContentDescription)
Add ignore 'ContentDescription' to element
Disable Check in This File Only
Disable Check in This Project
Disable Check
Clear All Lint Markers
Wrap in Container
Remove Container
Change Widget Type
Change Layout
Extract as Include
Extract Style
Rename in file
Surround with new element

Ca si cum nu as sti despre ce e vorba, am mmers la a doua optiune: "Explain Issue (ContentDescription)", am dat pe ea si a aparut acest mesaj:

[Accessibility] Missing contentDescription attribute on image
Issue Explanation:
Non-textual widgets like ImageViews and ImageButtons should use the contentDescription attribute to specify a textual description of the widget such that screen readers and other accessibility tools can adequately describe the user interface.
Note that elements in application screens that are purely decorative and do not provide any content or enable a user action should not have accessibility content descriptions. In this case, just suppress the lint warning with a tools:ignore="ContentDescription" attribute.
Note that for text fields, you should not set both the hint and the contentDescription attributes since the hint will never be shown. Just set the hint. See
http://developer.android.com/guide/topi ... cial-cases

Am mers apoi la prima optiune, "Add content description attribute", si am dat enter pe ea si s-a pus automat ca un al patrulea atribut al butonului de tip imagine>:
android:contentDescription="TODO"


Deci, nu se poate spune ca nu sunt oferite toate informatiile, posibilitatile necesare. Pana la urma incepuseram discutia propunand ceva ce exista deja.
Cred ca ar fi prea mult sa nu se compileze daca nu exista contentDescription, tot timpul vo rfi si acele "special cases".