This is an old revision of the document!
Android este un SO mobil bazat pe o versiune modificată de Linux (pentru gestiunea componentelor hardware, a proceselor și a memoriei) și biblioteci Java (pentru telefonie (audio/video), conectivitate, grafică, programarea interfețelor cu utilizatorul). Este un produs open-source (putând fi dezvoltat de producătorii de dispozitive mobile cu extensii proprietare pentru a-și particulariza platforma), dezvoltat în prezent de compania Google, conceput pe ideea transformării dispozitivelor mobile în adevărate mașini de calcul. Google încearcă totuși să realizeze tranziția de la AOSP (Android Open Source Project) către GMS (Google Mobile Services), peste care sunt construite cele mai multe aplicații, în încercarea de a-și apăra acest proiect în fața concurenței. În acest sens, a fost dezvoltat proiectul Google One, prin care este oferit un set de specificații (ecran de 4.5 inchi - 845×480 pixeli, procesor quad-core, memorie 1GB RAM, spațiu de stocare 4GB, suport pentru dual sim) pe care producătorii de dispozitive mai ieftine trebuie să le respecte astfel încât acestea să fie compatibile cu un sistem Android, fără a întâmpina probleme de performanță. Acesta include toate aplicațiile și serviciile Google, la care se pot adăuga și altele, furnizate de producător sau operatorul de telefonie mobilă. În acest fel, se asigură calitatea (păstrând renumele Android) și controlul asupra veniturilor. Comunitatea Android este în creștere, mai multe companii renunțând la propriul sistem de operare în favoarea acestuia, pentru a putea face față fenomenului iPhone.
În condițiile în care pe piața dispozitivelor mobile aplicațiile sunt cele care aduc avantajul competițional, beneficiul Android este reprezentat de abordarea unitară pentru dezvoltarea aplicațiilor. Cu alte cuvinte, o aplicație dezvoltată conform API-ului Android va putea rula pe mai multe dispozitive mobile pe care este instalat sistemul de operare respectiv.
Versiune Android | Nivel API | Data Lansării | Nume de Cod | Cota de Piață |
---|---|---|---|---|
7.1 - 7.1.1 | 25 | 04.10.2016 | Nougat | 0.3% |
7.0 | 24 | 22.08.2016 | Nougat | 0.9% |
6.0 - 6.0.1 | 23 | 05.10.2015 | Marshmellow | 30.7% |
5.1 - 5.1.1 | 22 | 09.03.2015 | Lollipop | 23.1% |
5.0 - 5.0.2 | 21 | 12.11.2014 | Lollipop | 9.8% |
4.4W - 4.4W.2 | 20 | 25.06.2014 | KitKat with wearable extensions | |
4.4 - 4.4.4 | 19 | 31.10.2013 | KitKat | 21.9% |
4.3 | 18 | 24.07.2013 | Jelly Bean | 1.6% |
4.2.x | 17 | 13.11.2012 | Jelly Bean | 5.7% |
4.1.x | 16 | 09.07.2012 | Jelly Bean | 4.0% |
4.0.3 - 4.0.4 | 15 | 16.12.2011 | Ice Cream Sandwich | 1.0% |
4.0 - 4.0.2 | 14 | 19.10.2011 | Ice Cream Sandwich | |
3.2 | 13 | 15.07.2011 | Honeycomb | |
3.1 | 12 | 10.05.2011 | Honeycomb | |
3.0 | 11 | 22.02.2011 | Honeycomb | |
2.3.3 - 2.3.7 | 10 | 09.02.2011 | Gingerbread | 1.0% |
2.3 - 2.3.2 | 9 | 06.12.2010 | Gingerbread | |
2.2 - 2.2.3 | 8 | 20.05.2010 | Froyo | |
2.1 | 7 | 12.01.2010 | Eclair | |
2.0.1 | 6 | 03.12.2009 | Eclair | |
2.0 | 5 | 26.10.2009 | Eclair | |
1.6 | 4 | 15.09.2009 | Donut | |
1.5 | 3 | 30.04.2009 | Cupcake | |
1.1 | 2 | 09.02.2009 | ||
1.0 | 1 | 23.09.2008 |
Pentru identificarea versiunilor se folosesc, de regulă, trei sisteme:
În momentul în care se ia decizia cu privire la versiunea pentru care se dezvoltă o aplicație Android, trebuie avute în vedere și cotele de piață ale dispozitivelor mobile. Dezvoltarea unei aplicații Android pentru cea mai nouă versiune are avantajul de a se putea utiliza cele mai noi funcționalități expuse prin API. Dezvoltarea unei aplicații Android pentru cea mai veche versiune are avantajul unei adresabilități pe scară largă. Un compromis în acest sens poate fi obținut prin intermediul bibliotecilor de suport, dezvoltate pentru fiecare versiune, prin intermediul cărora pot fi utilizate la niveluri de API mai mici funcționalități din niveluri de API mai mari (în limita capabilităților dispozitivului mobil respectiv). Utilizarea acestora reprezintă o practică recomandată în dezvoltarea aplicațiilor Android.
Arhitectura sistemului de operare Android cuprinde cinci secțiuni grupate pe patru niveluri:
/boot
- conține secvența de pornire, /system
- stochează fișierele de sistem și aplicațiile încorporate, /recovery
- deține o imagine din care se poate restaura sistemul de operare, /data
- include aplicațiile instalate și datele aferente acestora, /cache
- utilizată pentru fișiere temporare, folosind memoria RAM, pentru acces rapid).De vreme ce Android este un produs open-source, producătorii având posibilitatea de a-l modifica în mod gratuit, nu există configurații hardware sau software standard. Totuși, Android implementează următoarele funcționalități:
Piața de telefoane inteligente este dominată de Android (care - potrivit estimărilor - își va menține supremația până în 2018), cu 82.8% (peste un miliard de dispozitive vândute) pe întreg anul 2015, în timp ce Apple deține doar 13.9%, la nivel mondial.
În 2015, numărul de aplicații disponibile pentru platforma Android le-a depășit pe cele destinată dispozitivelor Apple (1.6 milioane, comparativ cu 1.5 milioane). Și în privința numărului de descărcări Android se află în fața Apple cu aproximativ 25%. Totuși, politica de distribuție a aplicațiilor (faptul că aplicațiile iPhone pot fi instalate numai prin intermediul App Store, în timp ce Android pune la dispoziție mai multe posibilități - Play Store, Amazon App Store, prin conexiune USB de la calculator, prin email sau prin pagina Internet a organizației), la care se adaugă numărul mare de programe gratuite și posibilitatea de piratare mai ușoară se traduce prin încasările obținute, Apple generând un profit mult mai mare din aplicații decât Google (cifrele oficiale nu sunt disponibile încă). O altă explicație a acestei situații este dată și de potența financiară a posesorilor de produse Apple (valoarea unui iPhone fiind de aproximativ 600 dolari) față de puterea de cumpărare a persoanelor ce dețin un telefon Android (al cărui preț mediu este de 200-300 dolari), existând o corespondență directă cu disponibilitatea de a achiziționa aplicații. De asemenea, statisticile arată că utilizatorii Apple își folosesc mult mai intens dispozitivele pentru accesarea de conținut Internet decât cei cumpărătorii de produse echipate cu Android.
Aplicațiile destinate dispozitivelor mobile reprezintă un segment extrem de productiv al economiei, doar vânzările din AppStore depășind încasările obținute din producția de filme de la Holywood. Ca tematică, cele mai multe aplicații aparțin domeniului social (jocuri, fotografie, muzică, aplicații culinare, stil de viață), urmate de cele destinate gestionării unor segmente ale unor afaceri.
În privința limbajului de programare utilizat pentru dezvoltarea de aplicații mobile, iPhone folosește Objective-C, similar cu C++, care nu se bucură însă de o răspândire prea largă (cu excepția aplicațiilor pentru iPhone), în timp ce Android utilizează Java (limbajul de programare cel mai adoptat pe scară largă în cadrul corporațiilor) dar și C/C++, prin care se pot apela (cu o oarecare dificultate) aplicații native, prin suport JNI (numărul bibliotecilor disponibile în cazul C/C++ este mai redus decât în Java, însă viteza aplicațiilor este mai mare). Dezvoltarea aplicațiilor pentru iPhone se poate realiza numai folosind mașini Mac (echipate cu MacOS), în timp ce aplicațiile Android pot fi scrise în orice sistem de operare cu Java și Eclipse (atât PC-uri cât și Mac-uri echipate cu Windows, Linux sau MacOS). În această situație, se pune problema cotelor de piață ale sistemelor de operare în cadrul companiilor dezvoltatoare de software, care creează sau nu oportunități pentru dezvoltarea unui anumit tip de aplicații (la începutul lui 2016, sistemele de operare Windows dețineau 90,60% din piață, OS X 7,68%, sistemele de operare cu kernel Linux 1,71%, iar alte sisteme de operare 0,01%).
Așadar, dacă pentru utilizare personală nu se poate stabili un câștigător clar între Android și iPhone (deși produsul celor de la Apple pare să aibă un ușor avantaj printr-un număr mai mare de aplicații și prin loialitatea clienților), în cazul aplicațiilor dezvoltate de corporații situația este inversă, date fiind posibilitățile de instalare și limbajul de programare folosit.
Ajunsă deja la a șaptea versiune, Android este o platformă care beneficiază de experiența a numeroși dezvoltatori ce poate fi exploatată:
Pentru dezvoltarea unei aplicații Android sunt necesare:
Dacă telefonul nu este recunoscut la conectarea prin USB, trebuie instalate niște reguli pentru udev, conform instrucțiunilor de pe stackexchange:
student@eim2017:~$ sudo bash student@eim2017:~# lsusb
După ce s-a identificat dispozitivul mobil (prin intermediul comenzii lsusb
), se precizează o regulă pentru acesta:
student@eim2017:~# gedit /etc/udev/rules.d/51-android.rules
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="d002", MODE="0660", GROUP="plugdev", SYMLINK+="android%n"
Se reîncarcă dispozitivele conectate prin USB:
student@eim2017:~# /etc/init.d/udev restart
Mai multe informații sunt disponibile și la http://blog.janosgyerik.com/adding-udev-rules-for-usb-debugging-android-devices/.
Un sistem de control al versiunilor (eng. VCS - Version Control System) este un mecanism prin intermediul căruia sunt gestionate fișiere / proiecte în dinamică (pe măsură ce sunt modificate), în scopul de a se putea realiza revenirea la o anumită stare în caz de eroare (restaurarea unei versiuni stabile) și pentru a permite colaborarea între mai multe echipe care lucrează concomitent la diferite funcționalități ale unui același proiect.
Deși în mod curent astfel de produse sunt folosite pentru dezvoltarea de aplicații (urmărindu-se o gestionare eficientă a codului sursă și a utilizatorilor care implementează anumite funcționalități sau corectează defecte), ele pot fi folosite și pentru alte tipuri de proiecte, ce implică lucrul cu fișiere binare, pentru care diferențele între diferite versiuni se realizează mai dificil.
În prezent, sunt folosite trei tipuri de sisteme de control a versiunilor, fiecare dintre acestea fiind adecvate unei anumite situații:
diff
) dintre versiuni succesive, astfel că se poate reveni oricând la o stare anterioară (exemplu: rcs);Apariția Git în 2005 este strâns legată de dezvoltarea kernelului pentru Linux, proiect open-source la care lucra o comunitate destul de numeroasă de programatori. Dacă anterior actualizările erau distribuite sub forma unor arhive ce conțineau modificările (1991-2002), respectiv prin intermediul unui sistem distribuit de control al versiunilor denumit BitKeeper (2002-2005), pe măsură ce proiectul a devenit mai complex și din ce în ce mai multe persoane și-au exprimat disponibilitatea de a contribui la dezvoltarea acestuia, s-a pus problema conceperii unui produs care să satisfacă cerințele legate de viteză, arhitectură scalabilă, suport pentru dezvoltare non-liniară (numeroase ramificații la care se lucrează concomitent), distribuire totală, capacitate de a gestiona proiecte de dimensiuni mari.
Git se diferențiază de alte sisteme de control al versiunilor prin câteva caracteristici:
commit
ce conține o referință către părintele sau părinții săi (consemnarea / consemnările anterioare, din care a fost obținut, prin modificarea fișierelor) și o referință către instantaneul propriu-zis. De asemenea, în cadrul acestui obiect se rețin și informații despre dimensiunea totală și suma de control SHA-1, autor și contributor (nume și adresă de poștă electronică), data la care a fost realizată consemnarea, mesajul asociat.tree
, o structură de date ce conține referințe spre fiecare resursă ce au fost modificată, aceasta fiind identificată prin denumire și sumă de control SHA-1; și în cazul unui astfel astfel de obiect se rețin dimensiunea totală și suma de control SHA-1;blob
, corespunzătoare fiecărei resurse din cadrul consemnării respective; acestea sunt identificate prin denumire, dimensiune și suma de control SHA-1.Un scenariu tipic de utilizare a sistemului de versiune Git implică:
Instrucțiunile pentru instalarea și configurarea Git sunt disponibile aici. Informații suplimentare cu privire la comenzile Git și sintaxa acestora pot fi obținute folosind paginile de manual:
student@eim2017:~$ git help <command> student@eim2017:~$ git <command> --help student@eim2017:~$ man git-<command>
În cazul în care se dorește monitorizarea unui proiect nou / existent prin sistemul de control al versiunilor Git, directorul în care se găsește acesta va trebui inițializat folosind comanda:
student@eim2017:~$ git init
Astfel, se creează un director .git
în care vor fi plasate toate versiunile fișierelor care sunt monitorizate. Inițial, acesta este vid.
Indicarea fișierelor care sunt monitorizate se face prin intermediul comenzii git add <file>
, fiind permisă și folosirea de expresii regulate folosind măști pentru a indica conținutul unui întreg director. Prin intermediul acestei comenzi, fișierele sunt transferate din directorul de lucru în zona de așteptare.
Consemnarea propriu-zisă a fișierelor se face rulând comanda git commit -m "<message>"
, mesajul care o însoțește trebuind să fie relevant pentru modificările care au fost realizate. Se recomandă ca această operație să fie realizată cât mai des pentru actualizări de dimensiuni relativ reduse ale codului sursă. În acest moment, fișierele trec din zona de așteptare în directorul Git.
În situația în care utilizatorul vrea să lucreze pe un proiect găzduit pe un server la distanță, poate descărca întregul conținut în zona de lucru, inclusiv istoricul complet al versiunilor anterioare (care poate fi ulterior reconstituit după această copie, în cazul coruperii informațiilor stocate pe serverul la distanță), prin intermediul comenzii:
git clone <URL> [<local_directory>]
unde:
URL
- reprezintă adresa serverului la distanță care găzduiește proiectul, putând fi utilizate în acest sens mai multe protocoale pentru transferul de informațiestudent@eim2017:~$ git clone git://github.com/eim2017/Laborator01.git
student@eim2017:~$ git clone https://github.com/eim2017/Laborator01
student@eim2017:~$ git clone git@github.com:eim2017/Laborator01.git
local_directory
(opțional) - denumirea directorului local în care va fi stocată versiunea curentă a proiectului (precum și istoricul din directorul Git), în cazul în care se dorește schimbarea acestuia
Fișierele astfel descărcate, aflate atât în zona de lucru cât și în directorul Git pot fi modificate în funcție de necesități și transferate, succesiv, în zona de așteptare (prin git add
) și în baza de date locală (prin git commit -m
).
Dacă este necesar ca fișierele modificate să fie încărcate pe serverul de unde au fost preluate, trebuie ca mai întâi să se actualizeze modificările care se vor fi produs pe acesta între timp (folosind comanda git pull --rebase
) - rezolvând eventualele conflicte - și apoi să se transfere efectiv prin intermediul comenzii git push origin master
.
Comanda git status
furnizează informații cu privire la starea fișierelor aflate în zona de lucru, fie că este vorba de resurse deja monitorizate (care se găsesc în directorul Git) care au fost modificate între timp, fie că este vorba despre date care au fost adăugate (și care nu au fost marcate în mod explicit pentru a fi ignorate). De asemenea, comanda indică și ramificația (eng. branch) pe care se găsește utilizatorul în mod curent.
O astfel de comandă poate întoarce mai multe rezultate:
student@eim2017:~$ git status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean
student@eim2017:~$ git status On branch master Your branch is up-to-date with 'origin/master'. Untracked files: (use "git add <file>..." to include in what will be committed) MyFirstAndroidApplication/ nothing added to commit but untracked files present (use "git add" to track)
Monitorizarea acestor date se face prin intermediul comenzii git add <files/directory>
, care suportă specificarea de expresii regulate desemnând măști pentru indicarea mai multor fișiere/directoare.
Changes to be committed
); eventualele fișiere care au existat în instantanee anterioare și au fost modificate în directorul de lucru nu vor fi marcate ca făcând parte din zona de așteptare (trecute în secțiunea Changes not staged for commit
) dacă versiunile respective nu vor fi incluse în mod explicit prin comanda git add <files/directory>
student@eim2017:~$ git status On branch master Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: MyFirstAndroidApplication/.classpath new file: MyFirstAndroidApplication/.project new file: MyFirstAndroidApplication/.settings/org.eclipse.jdt.core.prefs new file: MyFirstAndroidApplication/AndroidManifest.xml new file: MyFirstAndroidApplication/ic_launcher-web.png new file: MyFirstAndroidApplication/libs/android-support-v4.jar new file: MyFirstAndroidApplication/proguard-project.txt new file: MyFirstAndroidApplication/project.properties new file: MyFirstAndroidApplication/res/drawable-hdpi/ic_launcher.png new file: MyFirstAndroidApplication/res/drawable-mdpi/ic_launcher.png new file: MyFirstAndroidApplication/res/drawable-xhdpi/ic_launcher.png new file: MyFirstAndroidApplication/res/drawable-xxhdpi/ic_launcher.png new file: MyFirstAndroidApplication/res/layout/activity_main.xml new file: MyFirstAndroidApplication/res/menu/main.xml new file: MyFirstAndroidApplication/res/values-v11/styles.xml new file: MyFirstAndroidApplication/res/values-v14/styles.xml new file: MyFirstAndroidApplication/res/values-w820dp/dimens.xml new file: MyFirstAndroidApplication/res/values/dimens.xml new file: MyFirstAndroidApplication/res/values/strings.xml new file: MyFirstAndroidApplication/res/values/styles.xml new file: MyFirstAndroidApplication/src/ro/pub/cs/systems/eim/lab01/MainActivity.java Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: README.md
Fișierele care nu au existat într-un instataneu anterior sunt marcate prin new file
, iar cele care au fost modificate față de versiunile precedente sunt marcate prin modified
.
Changes to be committed
, respectiv Changes not staged for commit
în situația în care au mai fost realizate modificări asupra acestuia după rularea comenzii git add <files/directory>
.
Prin intermediul comenzii git add <files/directory>
se specifică fișiere / directoare care vor fi transferate din zona de lucru în zona de așteptare, pentru a fi incluse în următorul instantaneu în momentul în care se va realiza consemnarea acestora.
git add
. Dacă ele sunt modificate după precizarea acestei comenzi, actualizările nu vor fi consemnate în directorul Git decât dacă se rulează din nou comanda git add
.
student@eim2017:~$ git add MyFirstAndroidApplication/*
În cazul în care un fișier este transferat din greșeală din zona de lucru în zona de așteptare, parcursul invers poate fi realizat prin intermediul comenzii git reset HEAD <file>
.
Dacă se dorește eliminarea modificărilor realizate asupra unui fișier din zona de lucru, se poate folosi comanda git checkout -- <file>
(disponibilă începând cu versiunea 1.6.1). O astfel de operație este totuși periculoasă, în sensul că actualizările respective sunt pierdute fără posibilitatea de a mai putea fi recuperate (întrucât nu au fost consemnate niciodată în directorul Git).
Alte operații care pot fi realizate asupra fișierelor din zona de lucru / zona de așteptare sunt mutarea (redenumirea), respectiv ștergerea acestora.
Comanda git mv <source> <target>
este folosită pentru operația de mutare (redenumire) a unui fișier. Necesitatea sa este dată de faptul că Git nu detectează în mod automat fișierele care sunt redenumite pe discul local. Dacă se verifică starea fișierelor din zona de lucru / zona de așteptare, fișierele redenumite apar în zona Changes to be committed
, în secțiunea renamed
.
git mv <source> <target>
este echivalentă cu aceeași succesiune de operații:
student@eim2017:~$ mv <source> <target> student@eim2017:~$ git rm <source> student@eim2017:~$ git add <target>
student@eim2017:~$ git mv README.md README.txt
Prin intermediul comenzii git rm <file/directory>
, resursa specificată este eliminată nu numai de pe discul local, ci și din zona de așteptare, astfel încât atunci când se realizează operația de consemnare, acesta este eliminat din directorul Git și din lista fișierelor care sunt monitorizate. În cazul în care resursa este eliminată manual, doar de pe discul local, aceasta va apărea ca modificată în zona de lucru, dar nemarcată pentru a fi consemnată în zona de așteptare. Dacă se verifică starea fișierelor din zona de lucru / zona de așteptare, fișierele șterse apar în zona Changes to be committed
, în secțiunea deleted
.
-f
, pentru a preveni eliminarea accidentală a unor resurse.-r
(recursiv).
.gitignore
), comanda trebuie rulată cu opțiunea --cached
.
student@eim2017:~$ git rm LICENSE rm 'LICENSE'
Este recomandat ca fișierele generate să nu fie incluse în directorul Git (binare, jurnale), acestea fiind rezultatul procesului de compilare / rulare a proiectului. Mai mult, nu se dorește ca informații cu privire la modificarea lor să fie incluse în raportul rezultat ca rulare a comenzii git status
.
Un astfel de comportament poate fi obținut prin specificarea acestui tip de fișiere în .gitignore
, respectându-se următoarele reguli:
#
nu sunt luate în considerare*
desemnează 0 sau mai multe caractere (trebuie precedat de \
)**
(suportat din versiunea 1.8.2) referă conținutul unui director?
indică un singur caracter{
și }
sunt trecute colecții de șabloane[
și ]
sunt trecute seturi de caractere (sau intervale între două caractere, separate prin -
)!
înaintea unui șablon îl neagă
La crearea unui proiect nou, GitHub oferă posibilitatea de a include în mod automat un fișier .gitignore
în funcție de limbajul de programare utilizat.
Pentru Android, conținutul fișierului .gitignore
generat este:
# Built application files *.apk *.ap_ # Files for the Dalvik VM *.dex # Java class files *.class # Generated files bin/ gen/ # Gradle files .gradle/ build/ # Local configuration file (sdk path, etc) local.properties # Proguard folder generated by Eclipse proguard/ # Log Files *.log
Prin intermediul comenzii git diff
, utilizatorul are posibilitatea de a vizualiza în ce constau actualizările pentru fiecare fișier în parte.
student@eim2017:~$ git diff diff --git a/README.md b/README.md index dff203e..77d86c8 100644 --- a/README.md +++ b/README.md @@ -1 +1,3 @@ -# Laborator01 +MyFirstAndroidApplication +========================= +A simple application displaying a dialog in which the user is asked to provide his/her name in order to be properly greeted to the EIM laboratory.
git diff
va fi vid.
--cached
sau --staged
(disponibil din versiunea 1.6.1, efectul este identic), comanda indică diferențele pentru fișierele care au fost marcate pentru a fi incluse în următorul instantaneu, față de situația existentă în directorul Git (cu alte cuvinte, sunt indicate diferențele dintre zona de așteptare și directorul Git) student@eim2017:~$ git diff --staged diff --git a/MyFirstAndroidApplication/.classpath b/MyFirstAndroidApplication/.classpath new file mode 100644 index 0000000..5176974 --- /dev/null +++ b/MyFirstAndroidApplication/.classpath @@ -0,0 +1,9 @@ +<?xml version="1.0" encoding="UTF-8"?> +<classpath> + <classpathentry kind="con" path="com.android.ide.eclipse.adt.ANDROID_FRAMEWORK"/> + <classpathentry exported="true" kind="con" path="com.android.ide.eclipse.adt.LIBRARIES"/> + <classpathentry exported="true" kind="con" path="com.android.ide.eclipse.adt.DEPENDENCIES"/> + <classpathentry kind="src" path="src"/> + <classpathentry kind="src" path="gen"/> + <classpathentry kind="output" path="bin/classes"/> +</classpath> ...
Dacă toate fișierele din zona de lucru au fost marcate spre a fi incluse în următorul instantaneu (rezultatul comenzii git status
nu conține nici un fișier în secțiunea Changes not staged for commit
), ele pot fi consemnate, adică trecute din zona de așteptare în directorul Git, prin intermediul comenzii git commit
.
Rulată fără parametru, comanda deschide editorul de text implicit (sau cel indicat de proprietatea core.editor
) completat cu rezultat comenzii git status
, care poate fi modificat pentru a constitui mesajul asociat fișierelor consemnate în directorul Git. Dacă se dorește ca în acest mesaj să se includă și rezulatul comenzii git diff
, se poate utiliza parametrul -v
.
Mesajul care însoțește consemnarea fișierelor poate fi inclusă direct în cadrul comenzii prin intermediul parametrului -m
.
student@eim2017:~$ git commit -m "initial commit: graphical user interface, some code to handle the button click" [master 95fa0b2] initial commit: graphical user interface, some code to handle the button click 21 files changed, 300 insertions(+) create mode 100644 MyFirstAndroidApplication/.classpath create mode 100644 MyFirstAndroidApplication/.project create mode 100644 MyFirstAndroidApplication/.settings/org.eclipse.jdt.core.prefs create mode 100644 MyFirstAndroidApplication/AndroidManifest.xml create mode 100644 MyFirstAndroidApplication/ic_launcher-web.png create mode 100644 MyFirstAndroidApplication/libs/android-support-v4.jar create mode 100644 MyFirstAndroidApplication/proguard-project.txt create mode 100644 MyFirstAndroidApplication/project.properties create mode 100644 MyFirstAndroidApplication/res/drawable-hdpi/ic_launcher.png create mode 100644 MyFirstAndroidApplication/res/drawable-mdpi/ic_launcher.png create mode 100644 MyFirstAndroidApplication/res/drawable-xhdpi/ic_launcher.png create mode 100644 MyFirstAndroidApplication/res/drawable-xxhdpi/ic_launcher.png create mode 100644 MyFirstAndroidApplication/res/layout/activity_main.xml create mode 100644 MyFirstAndroidApplication/res/menu/main.xml create mode 100644 MyFirstAndroidApplication/res/values-v11/styles.xml create mode 100644 MyFirstAndroidApplication/res/values-v14/styles.xml create mode 100644 MyFirstAndroidApplication/res/values-w820dp/dimens.xml create mode 100644 MyFirstAndroidApplication/res/values/dimens.xml create mode 100644 MyFirstAndroidApplication/res/values/strings.xml create mode 100644 MyFirstAndroidApplication/res/values/styles.xml create mode 100644 MyFirstAndroidApplication/src/ro/pub/cs/systems/eim/lab01/MainActivity.java
Se observă că în rezultatul acestei comenzi sunt indicate ramificația pe care se face consemnarea (master
), suma de control SHA-1 a consemnării (95fa0b2
), numărul de fișiere modificate (21
) precum și statistici cu privire la numărul de linii adăugate (300
), respectiv eliminate (0
).
git commit -m "<message>"
trebuie rulată și cu parametrul -a
.
student@eim2017:~$ git commit -a -m "initial commit: graphical user interface, some code to handle the button click"
Într-un astfel de caz, nu mai este necesar ca în prealabil să se ruleze comanda git add
.
Dacă s-au omis resurse în cadrul celei mai recente versiuni transmise către directorul Git, se poate încerca consemnarea modificărilor respective prin intermediul comenzii git commit --amend
(ulterioară marcării fișierelor în cauză în zona de așteptare) prin intermediul căreia se suprascrie varianta anterioară cu actualizările din zona de așteptare curentă. Ca și în cazul precedent, este afișat un editor de text care conține mesajul corespunzător versiunii consemnate, acesta putând fi actualizat.
Unei versiuni consemnate în directorul Git îi poate fi asociată o etichetă (eng. tag) prin care se desemnează, de regulă, o anumită funcționalitate.
Git oferă posibilitatea de a defini două tipuri de etichete, prin intermediul comenzii git tag
:
student@eim2017:~$ git tag v1.0
student@eim2017:~$ git tag -a v1.0 -m 'an annotated tag for the first release version'
Etichetele de acest tip pot fi semnate folosind GPG (GNU Privacy Guard), dacă utilizatorul dispune de o cheie privată, acestea având avantajul că pot fi verificate
student@eim2017:~$ git tag -s v1.0 -m 'a signed tag for the first release version'
Verificarea unei etichete semnate se face prin intermediul comenzii git tag -v <tag_name>
, fiind necesară existența cheii publice a utilizatorului care a semnat-o.
Așadar, opțiunile cu care se poate rulează comanda git tag
în cazul unei etichete adnotate sunt:
-a
: specifică faptul că este vorba despre o etichetă nesemnată-s
: specifică faptul că este vorba despre o etichetă semnată-m
: indică mesajul asociat etichetei (dacă se rulează comanda fără acest parametru, va fi deschis editorul de text pentru ca acesta să fie introdus)-v
: dacă se dorește verificarea unei etichete semnate
Lista tuturor etichetelor asociate unui proiect poate fi consultată dacă se rulează comanda git tag
fără nici un parametru:
student@eim2017:~$ git tag v1.0
Aceasta suportă opțiunea -l <tag_mask>
pentru a se afișa doar lista etichetelor care respectă o anumită expresie regulată.
Dacă se dorește consultarea conținutului unei etichete, se poate utiliza comanda git show <tag>
, prin care sunt listate toate informațiile asociate versiunii respective.
student@eim2017:~$ git show v1.0 commit 5e4b82a0783e5841e5c5241d44104e8b15e4270f Author: eim2017 <informaticamobila2017@gmail.com> Date: Sun Feb 22 18:00:00 2015 +0300 Initial commit
În situația în care o versiune a fost consemnată fără a i se asocia o etichetă, o astfel de operație poate fi realizată și ulterior, adăugând la comanda git tag
suma de control asociată respectivei versiuni (obținută ca rezultat al comenzii git log
).
student@eim2017:~$ git tag -a v1.1 -m 'version 1.1' e71c1c4b1b9818292b4cda084e47e25bfb573507
De regulă, etichetele nu sunt transferate în cadrul depozitelor găzduite de serverele la distanță, fiind necesar ca acest lucru să fie realizat manual:
git push <remote_name> <tag>
;git push <remote_name> --tags
.
Istoricul versiunilor consemnate pentru un proiect poate fi consultat, în ordine invers cronologică (de la cele mai noi la cele mai vechi) rulând comanda git log
. Pentru fiecare versiune a proiectului, vor fi afișate următoarele informații:
Cele mai folosite opțiuni ale acestei comenzi sunt:
OPȚIUNE | FUNCȚIONALITATE |
---|---|
-p | afișează diferențele (rezultatul comenzii git diff ) realizate în consemnarea curentă față de consemnarea anterioară |
--word_diff | afișează diferențele între versiuni, la nivel de cuvânt (mai ales pentru fișiere text de dimensiuni mari, mai rar pentru cod sursă): cuvintele adăugate sunt cuprinse între {+ +}, iar cuvintele șterse între [- -]; dacă se dorește omiterea contextului în care apare diferența (linia precedentă și linia care o succede), se poate folosi opțiunea -U1 (se afișează doar linia curentă) |
--stat | afișează statistici cu privire la fiecare consemnare în parte: numărul de fișiere modificate, lista acestora și numărul de modificări (adăugări / ștergeri) - la nivel de linie - pentru fiecare dintre acestea |
--shortstat | afișează doar statistici generale: numărul total de fișiere modificate, adăugări și ștergeri (la nivel de linie) |
--name-only | afișează lista fișierelor modificate |
--name-status | afișează lista fișierelor modificate împreună cu natura actualizării (actualizat, adăugat, șters) |
--abbrev-commit | afișează numai câteva caractere (din cele 40) ale sumei de control SHA-1 asociată fiecărei consemnări |
--relative-date | afișează momentul la care a fost realizată consemnarea relativ la data curentă |
--graph | afișează un graf (în format ASCII) al ramificațiilor, ilustrând momentul la care acestea au fost combinate |
--pretty | modifică formatul în care sunt afișate informațiile despre versiuni: ♦ oneline - informațiile despre fiecare consemnare sunt afișate pe o singură linie♦ short , full , fuller - controlează cantitatea de informație♦ format - permite personalizarea informațiilor, util pentru situația în care conținutul urmează să fie prelucrat în mod automat:✔ %H - suma de control, %h - suma de control prescurtată✔ %T - arborele sumei de control, %t - arborele sumei de control prescurtat✔ %P - suma de control a părintelui, %p - suma de control prescurtată a părintelui✔ %an - numele autorului, %ae - adresa de poștă electonică a autorului✔ %ad - data autorului, %ar - data autorului (relativă)✔ %cn - numele contributorului*), %ce - adresa de poștă electronică a contributorului✔ %cd - data contributorului, %cr - data contributorului (relativă)✔ %s - subiectul |
--oneline | afișează numai câteva caractere (din cele 40) ale sumei de control SHA-1 asociată fiecărei consemnări, pe o singură linie prescurtare pentru --pretty=online abbrev-commit |
*) Distincția dintre autor și contributor este următoarea:
În situația în care pentru un proiect au fost realizate foarte multe consemnări, există posibilitatea ca rezultatul comenzii git log
să fie limitat doar la cele care sunt de interes (oricum, în mod implicit, se realizeză o paginare astfel încât este imposibil ca acestea să fie afișate toate dintr-o dată):
OPȚIUNE | FUNCȚIONALITATE |
---|---|
-<n> | afișează doar cele mai recente n consemnări |
--since , --after | afișează consemnările realizate după cu o anumită dată / oră absolută / relativă *) |
--until , --before | afișează consemnările realizate înainte de o anumită dată/oră absolută / relativă |
--author | afișează doar consemnările având un anumit autor |
--committer | afișează doar consemnările având un anumit contributor |
--grep | afișează doar consemnările având anumite cuvinte în mesajul asociat; dacă se dorește indicarea mai multor cuvinte, trebuie utilizată împreună cu opțiunea --all-match |
--<path> | afișează doar consemnările care au realizat modificări asupra fișierelor localizate în calea specificată; această opțiune trebuie inclusă întotdeauna ultima |
*) Formatul în care se afișează data este specificat de opțiunea --date
, care poate lua valorile iso
(ISO 8601), rfc
(RFC 2822), raw
(număr de secunde de la 01/01/1970 UTC), local
(în conformitate cu zona de timp), relative
(raportat la momentul curent de timp).
Dacă se utilizează mai multe opțiuni, se vor lua în considerare consemnările care îndeplinesc toate criteriile specificate.
student@eim2017:~$ git log --pretty=format:"%h - %an [%ae] - %ar -> %s" --graph * df5829c - andreirosucojocaru [andrei.rosucojocaru@gmail.com] - 5 minutes ago -> resolved conflicts among customized_message and fade_effect branches |\ | * c857d27 - andreirosucojocaru [andrei.rosucojocaru@gmail.com] - 9 minutes ago -> added fade effect * | e1a9a2e - andreirosucojocaru [andrei.rosucojocaru@gmail.com] - 8 minutes ago -> added customized message |/ * 839f14e - andreirosucojocaru [andrei.rosucojocaru@gmail.com] - 42 minutes ago -> initial commit: graphical user interface, some code to handle the button click * e2594f8 - eim2017 [informaticamobila2017@gmail.com] - 2 days ago -> Initial commit
Mai mulți utilizatori pot colabora în cadrul unui proiect Git aflat pe un server la distanță (eng. remote repository), pe care pot avea fie doar drepturi de citire fie atât drepturi de citire cât și de scriere. Operațiile pe care le pot realiza sunt descărcarea de cod sursă, respectiv încărcarea (în situația în care au drepturi suficiente).
Prin intermediul comenzii git remote
, pot fi consultate depozitele la distanță cu care se lucrează în mod curent. În mod implicit, sunt afișate doar denumirile scurte asociate acestora. În cazul în care se dorește să se afișeze și URL-ul locației corespunzătoare fiecărui depozit la distanță, se va folosi opțiunea -v
.
Dacă directorul pe care se lucrează în mod curent a fost obținut ca urmare a clonării unui depozit la distanță, acesta va fi afișat ca având denumirea origin
.
student@eim2017:~$ git remote -v Laborator01_andreirosucojocaru git@github.com:andreirosucojocaru/Laborator01.git (fetch) Laborator01_andreirosucojocaru git@github.com:andreirosucojocaru/Laborator01.git (push) origin https://github.com/eim2017/Laborator01 (fetch) origin https://github.com/eim2017/Laborator01 (push)
Utilizatorul va avea drepturi de scriere numai pe depozitele la distanță pentru care dispune de cheile SSH corespunzătoare.
Pentru a putea referi un depozit la distanță prin intermediul unei denumiri (mai scurte) se va rula comenda git remote add
:
git remote add <remote_name> <URL>
Astfel, nu va mai fi necesară introducerea întregului URL corespunzător locației la care se găsește depozitul la distanță (pentru comenzile de încărcare/descărcare, respectiv consultare a acestuia), fiind suficientă precizarea denumirii asociate.
student@eim2017:~$ git remote add Laborator01_andreirosucojocaru git@github.com:andreirosucojocaru/Laborator01.git
Pentru a descărca cod sursă aflat într-un depozit găzduit de un server la distanță pe discul local există trei posibilități:
git clone <URL>
realizează o copie a datelor aflate la locația indicată de URL, inclusiv a tuturor ramificațiilor (eng. branches), ramificația master
(în situația în care există) de pe server fiind monitorizată pentru modificări, astfel încât acestea să fie integrate automat (eng. merged) în codul sursă din directorul de lucru student@eim2017:~$ git clone https://github.com/eim2017/Laborator01.git Cloning into 'Laborator01'... remote: Counting objects: 5, done. remote: Compressing objects: 100% (4/4), done. remote: Total 5 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (5/5), done. Checking connectivity... done.
git fetch <remote_name>
descarcă toate informațiile din depozitul de pe serverul la distanță care nu se regăsesc pe discul local, creându-se referințe către ramificația de la locația respectivă, care pot fi consultate pentru ca ulterior să fie integrate student@eim2017:~$ git fetch Laborator01_andreirosucojocaru remote: Counting objects: 39, done. remote: Compressing objects: 100% (19/19), done. remote: Total 39 (delta 5), reused 39 (delta 5) Unpacking objects: 100% (39/39), done. From https://github.com/andreirosucojocaru/Laborator01 * [new branch] master -> Laborator01_andreirosucojocaru/master
git fetch
nu integrează modificările existente în depozitul existent pe serverul la distanță în mod automat, fiind necesar ca această operație să fie realizată manual.
git pull
descarcă modificările dintr-o ramificație monitorizată (de exemplu, ramificația master
în situația în care depozitul este clonat) din depozitul de pe serverul la distanță, încercând să le integreze în mod automat în codul sursă din directorul de lucru.
Transmiterea modificărilor operate asupra unui cod sursă pe un depozit găzduit de un server la distanță se face prin intermediul comenzii git push <remote_name> <branch>
, care primește ca parametrii denumirea referinței către depozitul la distanță (aceasta este origin
în situația în care proiectul a fost clonat) și ramificația pe care se găsește codul sursă care urmează a fi clonat.
student@eim2017:~$ git push origin master Counting objects: 47, done. Delta compression using up to 2 threads. Compressing objects: 100% (29/29), done. Writing objects: 100% (45/45), 891.37 KiB | 0 bytes/s, done. Total 45 (delta 2), reused 0 (delta 0) To https://github.com/eim2017/Laborator01 e2594f8..839f14e master -> master
git push
va eșua în situația în care depozitul din directorul de lucru local nu este actualizat, adică dacă pe serverul la distanță se găsesc modificări (încărcate de alți utilizatori) care nu au fost descărcate încă. În această situație, înainte de a se transmite propriile modificări, va trebui să se ruleze comanda git pull
.
Dacă se dorește obținerea de informații cu privire la conținutul unui proiect găzduit de un server la distanță, se poate rula comanda git remote show <remote-name>
, care afișează:
git push
git pull
student@eim2017:~$ git remote show origin * remote origin Fetch URL: https://github.com/eim2017/Laborator01 Push URL: https://github.com/eim2017/Laborator01 HEAD branch: master Remote branch: master tracked Local branch configured for 'git pull': master merges with remote master Local ref configured for 'git push': master pushes to master (up to date)
În cazul în care se dorește să se schimbe denumirea asociată unei referințte către un depozit la distanță, acest lucru poate fi realizat prin comanda git remote rename <old_remote_name> <new_remote_name>
.
student@eim2017:~$ git remote rename Laborator01_andreirosucojocaru Lab01_arc
O referință către un depozit la distanță poate fi ștearsă în situația în care codul sursă nu mai este disponibil la adresa respectivă sau dacă utilizatorul respectiv nu mai lucrează pe proiectul în cauză. Comanda utilizată într-o astfel de situație este git remote rm <remote_name>
.
student@eim2017:~$ git remote rm Lab00_arc
Pentru a crea o aplicație Android se selectează Start a New Android Studio project.
Configurarea proiectului presupune specificarea unor parametri:
Pe baza valorilor introduse, se generează denumirea pachetului care va identifica în mod unic aplicația. Acesta este format din domeniu (scris în formă inversă) la care se adaugă denumirea aplicației (din care sunt eliminate caracterele albe).
De asemenea, este necesar să se indice locația la care va fi plasat proiectul respectiv.
Se indică platforma căreia îi este destinată aplicația Android:
Este selectat tipul de actvitate care va fi vizualizată în momentul în care aplicația Android este pornită (Blank Activity, Empty Activity, Fullscreen Activity, Google AdMob Activity, Google Maps Activity, Login Activity, Master/Detail Flow, Navigation Drawer Activity, Scrolling Activity, Settings Activity, Tabbed Activity).
Se stabilește o denumire pentru activitatea principală, precum și denumirea fișierelor în care vor fi plasate structura interfeței grafice, respectiv a meniului asociat. Se poate preciza, de asemenea, folosirea de fragmente în cadrul activității.
Se apasă butonul Finish.
Rularea unei aplicații Android se face prin intermediul unei pictograme asociate unei liste de selecție, în care sunt plasate toate aplicațiile disponibile în cadrul mediului integrat de dezvoltare. Se poate folosi și prescurtarea Shift + F10
.
Utilizatorul are posibilitatea de a selecta dispozitivul pe care va fi rulată aplicația, dintre cele conectate la mașina pe care se rulează.
Accesarea unui exemplu de aplicație Android se face prin intermediul opțiunii Import an Android code sample.
Pot fi consultate mai multe proiecte Android, pentru fiecare existând posibilitatea de a vizualiza codul sursă, disponibil în cadrul unui depozit GitHub. Gruparea aplicațiilor Android este realizată pe categorii tematice.
Un exemplu de aplicație Android, care se descarcă din contextul depozitului Github, poate fi redenumită, stabilindu-se și locația la care va fi stocată.
user.name
, user.email
, core.editor
, merge.tool
. Verificați faptul că informațiile au fost introduse corect, prin două metode diferite. student@eim2017:~$ git config --global user.name "Perfect Student" student@eim2017:~$ git config --global user.email "perfect_student@cti.pub.ro" student@eim2017:~$ git config --global core.editor gedit student@eim2017:~$ git config --global merge.tool diff
Verificarea valorii pe care o au variabilele de configurare poate fi realizată în mai multe moduri:
student@eim2017:~$ git config --list
student@eim2017:~$ cat .git/config
student@eim2017:~$ git config user.name student@eim2017:~$ git config user.email student@eim2017:~$ git config core.editor student@eim2017:~$ git config merge.tool
README.md
, nici a fișierului .gitignore
sau a a fișierului LICENSE
).labtaks
care conține proiectele Eclipse și AndroidStudio denumite MyFirstAndroidApplication
, fișierele README.md
și LICENSE
și un fișier .gitignore
care indică tipurile de fișiere (extensiile) ignorate. student@eim2017:~$ git clone https://www.github.com/eim2017/Laborator01.git
student@eim2017:~$ cd Laborator01 student@eim2017:~/Laborator01$ git remote add Laborator01_perfectstudent https://github.com/perfectstudent/Laborator01 student@eim2017:~/Laborator01$ git push Laborator01_perfectstudent master
MainActivity.java
din pachetul ro.pub.cs.systems.eim.lab01
(directorul src
), să se modifice metoda onClick
a clasei interne ButtonClickListener
astfel încât:EditBox
; greetingTextView.setText(greetingTextView.getText().toString().replace("xxx", "\n"+userNameEditText.getText()));
TRANSPARENCY_EFFECT_DURATION
milisecunde. AlphaAnimation fadeEffect = new AlphaAnimation(1.0f, 0.0f); fadeEffect.setDuration(TRANSPARENCY_EFFECT_DURATION); fadeEffect.setFillAfter(true); greetingTextView.setAnimation(fadeEffect);
student@eim2017:~/Laborator01$ git add MyFirstAndroidApplication/src/ro/pub/cs/systems/eim/lab01.MainActivity.java student@eim2017:~/Laborator01$ git commit -m "implemented functionality for customized message and fade effect" student@eim2017:~/Laborator01$ git push Laborator01_perfectstudent master
AccelerometerPlay
din cadrul exemplelor corespunzătoare nivelului de API 16 (legacy);Action Bar Compat - Basic
, din cadrul categoriei Getting Started.