ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΣΧΟΛΗ ΘΕΤΙΚΩΝ ΕΠΙΣΤΗΜΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΕΠΑΝΑΧΡΗΣΙΜΟΠΟΙΗΣΗ ΛΟΓΙΣΜΙΚΟΥ ΚΙΝΗΤΩΝ ΣΥΣΚΕΥΩΝ Διπλωματική Εργασία του Θωμά Σέγκουλη (ΑΕΜ: 1224) Επιβλέπων Καθηγητής: Ιωάννης Σταμέλος ΘΕΣΣΑΛΟΝΙΚΗ ΙΟΥΛΙΟΣ 2014
-ii-
Ευχαριστίες Η εκπονηση της εργασιας εγινε στο εργαστηριο Γλωσσων Προγραμματισμου και Τεχνολογιας Λογισμικου (Programming Languages and Software Engineering Laboratory PLaSE Laboratory) του Τμηματος Πληροφορικης του Α.Π.Θ., σε συνεργασια με την ομαδα Τεχνολογιας Λογισμικου (Software Engineering Group SWENG Group), υπο την επιβλεψη του καθηγητη Ιωαννη Σταμελου. Θα ηθελα να τον ευχαριστησω για την υποστηριξη και την εμπιστοσυνη που μου εδειξε ολο αυτο το διαστημα. Θα ηθελα επισης να ευχαριστησω τον Αποστολο Κριτικο για την πολυτιμη βοηθεια του στα προβληματα που παρουσιαστηκαν κατα την εκπονηση της εργασιας αυτης αλλα και για την εμπνευση που μου εδωσε. Τελος θελω να ευχαριστησω την οικογενεια μου αλλα και οσους σταθηκαν διπλα μου ολο αυτο το διαστημα, για την ανυπολογιστη υποστηριξη και υπομονη που μου εδειξαν. -iii-
-iv-
Περιεχόμενα ΕΥΧΑΡΙΣΤΙΕΣ...IIΙ ΠΕΡΙΕΧΟΜΕΝΑ...V 1 ΕΙΣΑΓΩΓΗ...1 1.1 Δομη Εργασιας...I 2 COPE... 3 2.1 Περιγραφη COPE...3 2.2 Επιπεδα COPE...4 2.2.1 Αναλυτες (Analyzers)...5 2.2.2 Εισηγητες Συστατικων (Component Recommenders)...7 2.2.3 Δημιουργοι Συστατικων (Component Makers)... 7 2.3 Προσαρμογη για Android εργα... 8 2.4 Σεναριο Χρησης... 9 3 ANDROID DEVELOPMENT...12 3.1 Βασικα συστατικα... 13 3.1.1 Activities... 13 3.1.2 Services... 15 3.1.3 Content Providers... 18 3.1.4 Broadcast Receivers... 19 3.2 Ενεργοποιηση βασικων συστατικων... 22 3.2.1 Ενεργοποιηση Activities... 22 3.2.2 Μεταφορα δεδομενων μεταξυ Activities... 25 3.2.3 Ενεργοποιηση Services... 27 3.2.4 Αποστολη broadcast γεγονοτων... 27 3.3 Fragments... 29 3.3.1 Κυκλος ζωης ενος Fragment... 31 3.3.2 Συμβατοτητα με παλαιοτερες εκδοσεις Android... 32 3.3.3 Επικοινωνια των Fragment με την εφαρμογη... 32 3.4 Android Manifest... 33 3.5 Υποστηριξη Ποικιλων Οθονων... 35 3.5.1 Μετρικες Οθονης... 36 -v-
3.5.2 Σχεδιαση... 37 4 ΕΠΑΝΑΧΡΗΣΙΜΟΠΟΙΗΣΗ ΣΥΣΤΑΤΙΚΩΝ... 43 4.1 Επαναχρησιμοποιησιμα Android συστατικα... 43 4.2 Αναλυση μεθοδολογιας... 44 4.2.1 Βασικα βηματα προσαρμογης... 44 4.2.2 Ενσωματωση επαναχρησιμοποιησιμων συστατικων... 46 4.3 Αναλυση εξαχθεντων συστατικων απο το COPE... 49 4.3.1 Database Manager...... 50 4.3.2 Horizontal ListView... 59 4.3.3 Http-Request Handler... 66 4.3.4 ImagePager Activity... 76 4.3.5 ConfirmDialog + AsyncTask... 82 5 ΑΝΑΠΤΥΞΗ ANDROID ΕΡΓΟΥ... 88 5.1 Απαιτησεις... 88 5.2 Σχεδιαση... 92 5.3 Υλοποιηση... 94 6 ΣΥΜΠΕΡΑΣΜΑΤΑ ΚΑΙ ΜΕΛΛΟΝΤΙΚΗ ΕΡΓΑΣΙΑ... 96 ΒΙΒΛΙΟΓΡΑΦΙΑ... 98 ΠΑΡΑΡΤΗΜΑ Ι... 100 -vi-
1. ΕΙΣΑΓΩΓΗ Παρα την αλματωδη αναπτυξη της βιομηχανιας εξυπνων κινητων συσκευων (smartphones), βρισκομαστε μολις στο ξεκινημα της. Η ταχυτατη ενσωματωση των συσκευων αυτων, στην καθημερινοτητα των ανθρωπων τα τελευταια χρονια, προμηνυει μεγαλες αλλαγες στην ηδη υπαρχουσα τεχνολογια. Έτσι λοιπον κρινεται αναγκαια η επανεξεταση των ηδη υπαρχοντων μοντελων αναπτυξης λογισμικου, οι οποιες δεν καλυπτουν επαρκως την αναπτυξη εφαρμογων για κινητες συσκευες και μπορει να αποδειχθουν προβληματικες. Οι συνεχεις αλλαγες στην τεχνολογια των κινητων συσκευων πρεπει να μπορουν να διαχειριζονται απο τα επιλεγμενα μοντελα αναπτυξης, προσφεροντας ευελιξια στις απαιτησεις, επαναληπτικες διαδικασιες αναπτυξης καθως και στερεες μεθοδους ελεγχου. Η πτυχιακη αυτη, πραγματευεται τη βελτιστοποιηση των μοντελων αναπτυξης λογισμικου για κινητες συσκευες, εφαρμοζοντας μεθοδους επαναχρησιμοποιησης συστατικων λογισμικου. Η επαναχρησιμοποιηση λογισμικου μπορει να επιταχυνει σε μεγαλο ποσοστο την αναπτυξη εργων, παρεχοντας κωδικα καλυτερης ποιοτητας, κατι που μπορει να ωθησει την αναπτυξη μικροτερων επιχειρησεων και να τις καταστησει ανταγωνισιμες μπροστα σε μεγαλυτερες. 1.1 Δομή Εργασίας Ακολουθει συντομη περιγραφη του περιεχομενου των επομενων κεφαλαιων αυτης της εργασιας: Δεύτερο κεφάλαιο: COPE Σε αυτο το κεφαλαιο μελεταται η διαδικασια εντοπισμου και της εξαγωγης επαναχρησιμοποιησιμων συστατικων Android λογισμικου απο πηγαιο κωδικα ανοικτου λογισμικου κανοντας χρηση του COPE εργαλειου. -1-
Τρίτο κεφάλαιο: Android development Περιγραφη του Android συστηματος, αναλυοντας τα βασικα συστατικα του καθως και τροπους υποστηριξης διαφορετικων συσκευων. Τέταρτο κεφάλαιο: Επαναχρησιμοποίηση Συστατικών Στο κεφαλαιο αυτο παρουσιαζονται τα επαναχρησιμοποιησιμα συστατικα λογισμικου που εξηχθησαν με το εργαλειο COPE απο Android κωδικα ανοικτου λογισμικου, οπως επισης και μια μεθοδολογια προσαρμογης και χρησης τους. Πέμπτο κεφάλαιο: Ανάπτυξη Android Έργου Στο κεφαλαιο αυτο, παρουσιαζεται η αναπτυξη ενος Android εργου, ενσωματωνοντας τα επαναχρησιμοποιησιμα συστατικα που παρουσιαστηκαν στο προηγουμενο κεφαλαιο. Έκτο κεφάλαιο: Συμπεράσματα Και Μελλοντική Εργασία Γινεται μια συντομη ανασκοπηση του τι υλοποιηθηκε και τι αποτελει μελλοντικη εργασια, καθως και μια μικρη αναφορα στα προβληματα και στις δυσκολιες που αντιμετωπιστηκαν. -2-
2. COPE Η διαδικασια επαναχρησιμοποιησης λογισμικου αποτελειται απο τα εξης τρια βασικα σταδια: Εντοπισμος πιθανων επαναχρησιμοποιησιμων συστατικων Εξαγωγη επαναχρησιμοποιησιμων συστατικων Χρηση επαναχρησιμοποιησιμων συστατικων Σε αυτο το κεφαλαιο γινεται η μελετη του πρωτου και του δευτερου σταδιου, δηλαδη του εντοπισμου και της εξαγωγης επαναχρησιμοποιησιμων συστατικων λογισμικου απο πηγαιο κωδικα ανοικτου λογισμικου (Free/Libre Open Source Software F/LOSS). 2.1 Περιγραφή COPE Η επαναχρησιμοποιηση συστατικων λογισμικου αποτελει ενα πολυ σημαντικο κομματι κατα τη διαδικασια αναπτυξης ενος εργου λογισμικου, αλλα δεν λαμβανει χωρα παντα. Πολλες εταιρειες που παραγουν λογισμικο εχουν υιοθετησει το δικο τους μοντελο επαναχρησιμοποιησης με βαση τις απαιτησεις τους, αλλα κωλυονται στην εφαρμογη του τις περισσοτερες φορες, λογω ελλειψης χρονου, κακου προγραμματισμου η απουσιας βοηθητικων εργαλειων. Στα πλαισια αυτης της πτυχιακης, παρουσιαζεται το COPE περιβαλλον (Component Adaptation Environment), που κυριο στοχο εχει τον ευκολο εντοπισμο και εξαγωγη συστατικων λογισμικου, μεσω των αυτοματων διεργασιων του. Προς το παρον υποστηριζονται μονο Java εφαρμογες, ομως λογω της ουδετεροτητας του μοντελου του, ειναι δυνατη η επεκταση του για την υποστηριξη διαφορετικων γλωσσων προγραμματισμου και τεχνολογιων. To COPE αναπτυχθηκε στα πλαισια του ευρωπαϊκου ερευνητικου εργου OPEN-SME, που εχει ως στοχο την παροχη ετοιμων και αυτονομων συστατικων λογισμικου απο εργα ανοικτου κωδικα (Open Source Software). -3-
2.2 Επίπεδα COPE Το COPE ειναι δομημενο σε τρια επιπεδα, τα οποια εκτελουνται ακολουθιακα για την εξαγωγη συστατικων λογισμικου απο τον Μηχανικο Επαναχρησιμοποιησης, το ατομο δηλαδη που ασχολειται με τον εντοπισμο και τη χρηση των συστατικων λογισμικου. Τα επιπεδα αυτα (βλεπε εικονα 2.1) παρουσιαζονται στην συνεχεια. Πριν την δημιουργια του επαναχρησιμοποιησιμου εργου στο COPE, υπαρχει ενα προπαρασκευαστικο σταδιο κατα το οποιο ο Μηχανικος Επαναχρησιμοποιησης συγκεντρωνει ενα συνολο αντικειμενων (artifacts), του υποψηφιου εργου που προκειται να εισαχθει στο COPE. Τα αντικειμενα αυτα ειναι απαραιτητα για την λειτουργια του COPE και εισαγονται σε αυτο σε αρχικο σταδιο κατα τη δημιουργια του επαναχρησιμοποιησιμου εργου. Τα αντικειμενα αυτα ειναι τα εξης: Δυαδικο αρχειο του μεταγλωττισμενου εργου (JAR αρχειο) Εξωτερικες βιβλιοθηκες που χρησιμοποιουνται στο εργο (JAR αρχεια) Προαιρετικα, URL του συστηματος ελεγχου εκδοσης του εργου (Version Control System) -4- Πηγαιος κωδικας του εργου
Εικόνα 2.1: Επιπεδα COPE 2.2.1 Αναλυτές (Analyzers) Στο αρχικο επιπεδο γινεται η αναλυση του εισαχθεντος στο COPE, εργου και επειτα αποθηκευση των αποτελεσματων στη βαση δεδομενων του COPE. Σε αυτο το σταδιο υποστηριζονται τα ακολουθα: -5-
Στατική Ανάλυση Γινεται υπολογισμος διαφορων μετρικων και εξαρτησεων, αναλυοντας τον πηγαιο κωδικα με στατικο τροπο, δηλαδη χωρις να ειναι απαραιτητη η εκτελεση του εργου. Ευρετηρίαση Πηγαίου Αρχείου Δημιουργια ευρετηριου των πηγαιων αρχειων, καταλληλο για αναζητηση ελευθερου κειμενου (free-text searching). Παραγωγή Τεκμηρίωσης Δημιουργια εγγραφου τεκμηριωσης του πηγαιου κωδικα (Javadoc), με επιπλεον UML διαγραμματα για καθε κλαση και πακετο. Δυναμική Ανάλυση Αναλυση του εργου, εκτελωντας δυναμικη αναλυση (δηλαδη εκτελωντας το). Ο Μηχανικος Επαναχρησιμοποιησης χρησιμοποιει δυναμικη αναλυση μετα το σταδιο εξαγωγης του συστατικου, ετσι ωστε να κατανοησει την λειτουργια του, να καθορισει την καλυψη της αναλυσης αυτης, και να το επικυρωσει, κανοντας χρηση τεχνικων ελεγχου, βασιζομενων στο μοντελο. Ανάλυση Ιστορικού Αποθηκευση αλλαγων που συνεβησαν στο ιστορικο αναπτυξης του εργου, για χρηση στα Subversion αποθετηρια (Subversion repositories). Προς το παρον αυτο το χαρακτηριστικο δεν χρησιμοποιειται για την εισηγηση συστατικων, ομως προβλεπεται η χρηση του στο μελλον. Ανάλυση Προτύπων Χρηση τεχνικων ανιχνευσης, οπως για παραδειγμα ανιχνευση του προσαρμογεα (Adapter) η προτυπων σχεδιασης πληρεξουσιου [4], για τον εντοπισμο κλασεων που συμμετεχουν σε προτυπα σχεδιασης. -6-
2.2.2 Εισηγητές Συστατικών (Component Recommenders) Αυτο το επιπεδο περιλαμβανει ενα συνολο μεθοδων, οι οποιες ειναι διαθεσιμες αφοτου αναλυθει το εργο απο το COPE, και σκοπος τους ειναι η προταση συσταδων κλασεων, οι οποιες θα μπορουσαν να σχηματισουν ανεξαρτητα συστατικα λογισμικου. Το COPE περιεχει τις εξης μεθοδους για την εισηγηση τετοιων συσταδων κλασεων: Εισηγητής εξάρτησης (Dependencies Recommender) Η μεθοδος αυτη, χρησιμοποιει ενα γενετικο αλγοριθμο για το σχηματισμο συσταδων κλασεων. Εισηγητής προτύπων (Pattern Recommender) Αυτη η μεθοδος σχηματιζει συσταδες κλασεων απο προτυπα σχεδιασης που εντοπιζονται στον πηγαιο κωδικα. Η ανιχνευση και ο εντοπισμος των προτυπων αυτων επιτυγχανεται με τη μεθοδο και τα εργαλεια που περιγραφονται στο [3]. Εισηγητής επαναχρησιμοποίησης (Reusability Recommender) Εξαγαγει και προτεινει μια συσταδα κλασεων, επειτα απο την επιλογη μιας κλασης. Το επαναχρησιμοποιησιμο συστατικο που παραγεται σαν αποτελεσμα αυτης της μεθοδου, θα περιεχει μια διεπαφη των δημοσιων μεθοδων της κλασης αυτης οπως επισης και το συνολο των απαραιτητων κλασεων, απο τις οποιες εξαρταται. 2.2.3 Δημιουργοί συστατικών (Component Makers) Αυτο το επιπεδο περιλαμβανει τις απαραιτητες μεθοδους για την εξαγωγη επαναχρησιμοποιησιμου συστατικου απο το εργο που εχει εισαχθει στο COPE. Η -7-
εξαγωγη μπορει να γινει ειτε επειτα της χρησης ενος εισηγητη συστατικων του προηγουμενου επιπεδου η επιλεγοντας μια κλαση χειροκινητα, η οποια εξαγεται μαζι με τις κλασεις με τις οποιες συσχετιζεται. Υπαρχουν τεσσερις διαθεσιμες μεθοδοι, δημιουργιας συστατικων, στο COPE: Δημιουργός διεπαφής (Interface Maker) Δημιουργια συστατικου επειτα απο την επιλογη μιας κλασης του εργου και προσθεση ολων των εξαρτησεων της. Δημιουργός εξάρτησης (Dependency Maker) Για την δημιουργια του συστατικου, χρησιμοποιει τις συσταδες που παραχθηκαν απο τον Εισηγητη εξαρτησης. Δημιουργός προτύπου προσαρμογέα (Adapter Pattern Maker) Για τη δημιουργια του συστατικου, χρησιμοποιει κλασεις που υλοποιουν το προτυπο σχεδιασης προσαρμογεα (Adapter design pattern). Δημιουργός προτύπου πληρεξούσιου (Proxy Pattern Maker) Για τη δημιουργια του συστατικου, χρησιμοποιει κλασεις που υλοποιουν το προτυπο σχεδιασης πληρεξουσιου (Proxy design pattern). 2.3 Προσαρμογή για Android έργα Όπως αναφερθηκε προηγουμενως, η ροη εργασιων του COPE εργαλειου, εφαρμοζεται για εργα λογισμικου, των οποιων ο πηγαιος κωδικας ειναι γραμμενος σε JAVA. Έτσι ειναι δυνατον να εφαρμοστoυν ολες οι μεθοδοι του COPE, εισαγοντας Android εργα που και αυτα ειναι κωδικοποιημενα σε JAVA. Υπαρχει ομως μια σημαντικη διαφορα για τα Android εργα, καθοτι εκτος απο πηγαιο κωδικα σε JAVA, συμπεριλαμβανουν υποχρεωτικα και αλλα αρχεια (XML για παραδειγμα), που οριζουν την γραφικη διεπαφη χρηστη καθως και αλλους πορους η ρυθμισεις του συστηματος. Οποτε η υπαρξη αυτων των αρχειων προσθετει επιπλεον -8-
πολυπλοκοτητα και εξαρτησεις για τον Μηχανικο Επαναχρησιμοποιησης, που ειναι αναγκασμενος να τις συμπεριλαβει στα εξαχθεντα συστατικα. Επισης για Έργα Android δεν ειναι απαραιτητη η υπαρξη ενος αρχειου Interface και συνεπως δεν απαιτειται η δημιουργια ενος τετοιου αρχειου. 2.4 Σενάριο Χρήσης Παρουσιαζεται ενα σεναριο χρησης του COPE, για την εξαγωγη συστατικου απο Android εργο, το οποιο χρησιμοποιειται επειτα στα πλαισια αυτης της πτυχιακης και περιγραφεται στην 4.3.3 παραγραφο. Βήμα 1. Δημιουργια νεου εργου επαναχρησιμοποιησης και εισαγωγη απαραιτητων αντικειμενων (artifacts) του Android εργου, ετσι ωστε να ειναι δυνατη η εισαγωγη και αναλυση του. Εικόνα 2.2: Δημιουργια νεου εργου επαναχρησιμοποιησης -9-
Βήμα 2. Εκτελεση Στατικης Αναλυσης Εικόνα 2.3: Εκτελεση Στατικης Αναλυσης Βήμα 3. Αποτελεσματα Στατικης Αναλυσης. Στο παραθυρο αυτο παρουσιαζονται ολες οι κλασεις απο τις οποιες μπορουν να προκυψουν επαναχρησιμοποιησιμα συστατικα, καθως και διαφορες μετρικες που προσφερουν επιπλεον πληροφορια σχετικα με την κλαση αυτη καθως και εναν δεικτη επαναχρησιμοποιησης της. Εικόνα 2.4: Αποτελεσματα Στατικης Αναλυσης -10-
Βήμα 4. Επιλογη και εξαγωγη συστατικου, επιλεγοντας την κλαση HttpRequest Εικόνα 2.5: Εξαγωγη Επαναχρησιμοποιησιμου Συστατικου Βήμα 5. Εμφανιση φακελου που περιεχει τα επαναχρησιμοποιησιμα συστατικα ενος εργου στο COPE. Στον φακελο generated βρισκεται ο πηγαιος κωδικας των συστατικων και στον φακελο l i b, οι εξωτερικες βιβλιοθηκες (JAR files) που χρησιμοποιηθηκαν κατα της εισαγωγη του εργου. Εικόνα 2.6: Φακελος που περιεχει τα Επαναχρησιμοποιησιμα Συστατικα -11-
3. ANDROID DEVELOPMENT Το Αndroid ειναι ενα λειτουργικο συστημα για κινητες συσκευες, βασισμενο σε τροποποιημενο πυρηνα linux. Η αναπτυξη του ξεκινησε το 2005 απο μια νεα ομωνυμη εταιρεια, την Android Inc. και στην συνεχεια αγοραστηκε απο την Google η οποια ειχε μολις εισχωρησει στο πεδιο των εφαρμογων για κινητες συσκευες. Το εργο για την αναπτυξη του Android λειτουργικου συστηματος ονομαζεται Android Open Source Project (AOSP) και καθοδηγειται κυριως απο την Google, η οποια επιθυμει το συστημα να ειναι ανοικτου κωδικα και δωρεαν και ως εκτουτου το διανεμει υπο τους ορους της Apache License, μιας ελευθερης αδειας λογισμικου. Πολλοι κατασκευαστες κινητων συσκευων εκμεταλλευομενοι αυτη τη δυνατοτητα, προσθετουν τις δικες τους ιδιοκτητες επεκτασεις πανω στο Android συστημα και δημιουργουν ενα προσαρμοσμενο στις αναγκες τους οικοσυστημα διεπαφης χρηστη, ωστε να διαφοροποιηθουν απο τους ανταγωνιστες τους. Αυτη η χρηση του Android λειτουργικου συστηματος εδωσε πλεονεκτημα σε πολλες εταιρειες που κατασκευαζουν εξυπνες κινητες συσκευες εναντι της Apple, που κατειχε το μεγαλυτερο μεριδιο της αγορας, αναζωογονωντας τα προϊοντα τους. Η τρεχουσα εκδοση του Android ειναι η 4.4 (KitKat) και η ελαχιστη που υποστηριζεται απο το Google Play Store ειναι η 2.2 (Froyo). Το Android συστημα ειναι δυνατον να ενσωματωθει σε πληθωρα συσκευων περα των εξυπνων κινητων τηλεφωνων και αξιζει να σημειωθει οτι η εκδοση 3.0 (Honeycomb) δημιουργηθηκε και εκδοθηκε εχοντας ως στοχο τη βελτιστη υποστηριξη συσκευων με μεγαλες οθονες και συγκεκριμενα των tablets. Έκδοση Κωδικη ονομασια API Κατανομη 2.2 Froyo 8 0.8% 2.3.3- Gingerbread 10 14.9% Ice Cream Sandwich 15 12.3% 2.3.7 4.0.34.0.4-12-
4.1.x 16 29.0% 4.2.x 17 19.1% 4.3 18 10.3% 19 13.6% 4.4 Jelly Bean KitKat Πινακας 3.1: Κατανομη των εγκατεστημενων εκδοσεων Android σε συσκευες, βαση δεδομενων που συλλεχθηκαν μεχρι και τις 4 Ιουνιου, 2014. 3.1 Βασικά συστατικά Η αναπτυξη μιας Αndroid εφαρμογης βασιζεται σε τεσσερα θεμελιωδη συστατικα. Τα συστατικα αυτα παρεχουν τις απαραιτητες διασυνδεσεις με το συστημα, εχοντας καθενα απο αυτα συγκεκριμενο ρολο καθολη τη διαρκεια ζωης της εφαρμογης. Δεν ειναι απαραιτητη η χρηση ολων αυτων των συστατικων σε καθε εφαρμογη και καποια απο αυτα δεν ειναι απαραιτητα για τη διασυνδεση με το χρηστη, ομως καθε ενα απο αυτα εξυπηρετει μοναδικο σκοπο με τον διαφορετικο κυκλο ζωης του. 3.1.1 Activities Ένα Activity συστατικο αναπαριστα ενα παραθυρο σε μια εφαρμογη και περιεχει τις λειτουργικοτητες που απαιτουνται για τη διεπαφη με το χρηστη. Μια εφαρμογη μπορει να περιεχει μηδεν η παραπανω Activities, ομως ειναι κοινη τακτικη να υπαρχει τουλαχιστον ενα Activity και κυριος σκοπος του ειναι η αλληλεπιδραση με το χρηστη. Απο την στιγμη που πυροδοτειται ενα Activity και εμφανιζεται το αντιστοιχο παραθυρο, ξεκινα και ο κυκλος ζωης του, ο οποιος αποτελειται απο εναν αριθμο σταδιων. Η κατανοηση του κυκλου ζωης ενος Activity ειναι ζωτικης σημασιας για τον προγραμματιστη για την εξασφαλιση της σωστης λειτουργιας της εφαρμογης, που δεν θα ειναι επιρρεπης σε σφαλματα. Οι εφαρμογες για εξυπνα κινητα τηλεφωνα ειναι απο τη φυση τους πιο απαιτητικες συγκριτικα με τις desktop εφαρμογες, καθως οι κινητες συσκευες προσφερουν μια πληθωρα διασυνδεσεων με το χρηστη και ταυτοχρονα εχουν περιορισμενους πορους. Επιπλεον βασικη τους -13-
προτεραιοτητα ειναι η ομαλη εμπειρια και πλοηγηση του χρηστη με τις εφαρμογες, και για να επιτευχθει αυτο θα πρεπει να χρησιμοποιουνται τα Activities με συνεση, καταναλωνοντας οσο το δυνατον λιγοτερους πορους και παρεχοντας γρηγορη και σωστη αποκριση επειτα απο ενεργειες του χρηστη. Ένα Activity αποτελει μια θυγατρικη κλαση και για να την χρησιμοποιησουμε ειναι απαραιτητη η δημιουργια μιας κλασης που την κληρονομει. Η θυγατρικη κλαση Activity οριζει ενα συνολο απο μεθοδους οι οποιες αποτελουν γεγονοτα του κυκλου ζωης της. Καθε μεθοδος της ενεργεια Activity πυροδοτειται επειτα απο αλλαγη καταστασης της εφαρμογης. Μια κλαση Activity οριζει τις παρακατω μεθοδους που αντικατοπτριζουν τον κυκλο ζωης της: oncreate() - Καλειται οταν δημιουργειται η Activity onstart() - Καλειται οταν η Activity γινεται ορατη στον χρηστη onresume() - Καλειται οταν η Activity ξεκινα την αλληλεπιδραση με το χρηστη onpause() - Καλειται οταν η Activity περνα στο παρασκηνιο η αναστελλεται onstop() - Καλειται οταν η Activity δεν ειναι πλεον ορατη στο χρηστη ondestroy Καλειται πριν η Activity καταστραφει, ειτε λογω συμπεριφορας του προγραμματος η απο το συστημα προσπαθωντας να εξοικονομησει μνημη onrestart Καλειται οταν μια Activity εχει σταματησει (μετα την κληση onstop()) και κανει επανεκκινηση Ακολουθει διαγραμμα καταστασεων που αναπαριστα τον κυκλο ζωης μιας Activity παρουσιαζοντας την ακολουθια κλησεων των γεγονοτων. -14-
Εικόνα 3.1: Κυκλος ζωης μιας Activity κλασης. 3.1.2 Services Ένα Service ειναι ενα συστατικο που χρησιμοποιειται για εκτελεση στο παρασκηνιο της εφαρμογης χωρις αμεση αλληλεπιδραση με την διεπαφη χρηστη. Επομενως δεν συσχετιζεται με τον κυκλο ζωης της εφαρμογης και την εκτελεση μιας Activity που περιγραφηκε στην προηγουμενη παραγραφο. Σκοπος του ειναι η εκτελεση εργασιων που απαιτουν μεγαλο χρονικο διαστημα διεκπεραιωσης οπως για παραδειγμα προσβαση σε web-services η μεταφορα δεδομενων απο και προς τη βαση δεδομενων. Τα Services εχουν μεγαλυτερη προτεραιοτητα συγκριτικα με ανενεργα Activities και επομενως ειναι λιγοτερο πιθανο να τερματιστουν απο το Android -15-
συστημα, που επιδιωκει να διατηρει στην κυρια μνημη μονο τις απαραιτητες διεργασιες για τον χρηστη. Σε περιπτωση που καποιο Service τερματιστει απο το συστημα, ειναι δυνατη η επαναφορα του οταν βρεθουν διαθεσιμοι ποροι για την εκτελεση του, με τον ιδιο τροπο που καλειται η OnRestart() μεθοδος στα Activities, για επανεκκινηση τους. Τα Services εκτελουνται στην ιδια διεργασια με το κυριως νημα της εφαρμογης, ως εκ τουτου θα μπορουσαν να υπερφορτωσουν την λειτουργια της και να προκαλεσουν καθυστερησεις στην αλληλεπιδραση με τον χρηστη. Επομενως συνισταται η χρηση μεθοδων ασυγχρονης εκτελεσης σε ξεχωριστο νημα και εμφανιση καταλληλης ειδοποιησης προς τον χρηστη οταν το Service τελειωσει την διεργασια του, στο κυριως νημα της εφαρμογης. Υπαρχουν διαφοροι τροποι ασυγχρονης εκτελεσης διεργασιων σε παραλληλο νημα απο το κυριως της εφαρμογης, στο Android συστημα και θα αναλυθουν σε επομενο κεφαλαιο. Η δημιουργια δικης μας υλοποιησης ενος Service, ειναι δυνατη και γινεται κληρονομωντας την θυγατρικη κλαση Service η την IntentService. Ο κυκλος ζωης ενος Service συστατικου, μπορει να ακολουθησει δυο μονοπατια, τα οποια σχετιζονται με το βαθμο ανεξαρτησιας του σε σχεση με τα συστατικα που το πυροδοτησαν. Οι δυο μορφες που μπορει να παρει ενα Service ειναι οι εξης: Started Service Το Service συστατικο δημιουργειται οταν καποιο αλλο συστατικο (ενα Activity) καλει την startservice() μεθοδο. Σε αυτην την περιπτωση το Service εκτελειται επ 'αοριστον στο παρασκηνιο και ειναι το ιδιο υπευθυνο για τον τερματισμο του, καλωντας την stopself() μεθοδο. Ειναι δυνατον να τερματιστει απο αλλο συστατικο οταν αυτο καλει την stopservice() μεθοδο. Ειναι ομως ειναι συνηθες να εκτελει μια λειτουργια ανεξαρτητα απο το συστατικο που το καλεσε, χωρις την επιστροφη αποτελεσματος. Όταν το Service σταματησει τη λειτουργια του, το συστημα το καταστρεφει. Bound Service Το Service αυτο δημιουργειται οταν καποιο αλλο συστατικο, ονομαζομενο client καλει την bindservice() μεθοδο. Ένα bound Service προσφερει client-server διεπαφη -16-
η οποια επιτρεπει την αλληλεπιδραση με αλλα συστατικα, δινοντας τους τη δυνατοτητα να στελνουν requests, να παιρνουν αποτελεσματα, οπως επισης να το επιτυγχανουν αυτο διαμεσου διαφορετικων διεργασιων με ενδοεπικοινωνια (IPC). Ένα bound Service εκτελειτε οσο ενα αλλο συστατικο, client ειναι δεμενο μαζι του και το οποιο μπορει να τερματισει την επικοινωνια, καλωντας την unbindservice() μεθοδο. Πολλαπλα συστατικα, clients, μπορουν να ειναι δεμενα την ιδια χρονικη στιγμη με το Service συστατικο, το οποιο καταστρεφεται οταν ολα αυτα αποδεσμευτουν. Μια κλαση Service οριζει τα παρακατω γεγονοτα που αντικατοπτριζουν τον κυκλο ζωης της: onstartcommand() - Καλειται οταν ενα αλλο συστατικο, οπως ενα Activity, πυροδοτει το Service, με την startservice() μεθοδο και ξεκινα τη λειτουργια του. Για τις Bounded Services δεν ειναι απαραιτητη η υλοποιηση αυτης της μεθοδου. onbind() - Καλειται οταν ενα συστατικο δενεται(bind) με το Service καλωντας την bindservice() μεθοδο(π.χ.για την εκτελεση RPC). Για την υλοποιηση αυτης της μεθοδου ειναι απαραιτητη η παροχη μιας διεπαφης, για την επικοινωνια clientservice, επιστρεφοντας μια IΒinder παραμετρο. οncreate() - Καλειται κατα τη δημιουργια του Service συστατικου. ondestroy() - Καλειται κατα τον τερματισμο του Service συστατικου. Ακολουθει διαγραμμα καταστασεων που αναπαριστα τον κυκλο ζωης ενος Started Service και ενος Bound Service παρουσιαζοντας την ακολουθια κλησεων των γεγονοτων. -17-
Εικόνα 3.2: Κυκλος ζωης μιας Service κλασης. 3.1.3 Content Providers Ένα Content Provider συστατικο οριζει μια δομημενη διεπαφη για την προσβαση σε δεδομενα της εφαρμογης και μπορει να χρησιμοποιηθει για τον διαμερισμο δεδομενων με αλλες εφαρμογες. Συχνα χρησιμοποιειται σε συνδυασμο με την SQLite βαση δεδομενων που παρεχεται απο το Android συστημα. Μια SQLite βαση δεδομενων αποθηκευει δεδομενα που παρεχονται απο ενα Content Provider. Η προσβαση σε δεδομενα διαμεσου του Content Provider επιτυγχανεται με χρηση του ContentResolver αντικειμενου μεσα στην εφαρμογη. Το ContentResolver αντικειμενο επικοινωνει με το αντικειμενο του Provider, ενα στιγμιοτυπο της κλασης που υλοποιει το Content Provider συστατικο. Το Provider αντικειμενο λαμβανει αιτησεις για αποστολη δεδομενων απο clients, εκτελει την απαιτουμενη -18-
ενεργεια και επιστρεφει τα αποτελεσματα. Εικόνα 3.3: Content Provider 3.1.4 Broadcast Receivers Ένα Broadcast Receiver (Receiver) συστατικο, χρησιμοποιειται για τη ληψη και τον χειρισμο γεγονοτων του συστηματος η της εφαρμογης. Για την ληψη ενος γεγονοτος, ειναι απαραιτητο να δηλωσει αρχικα ο Receiver οτι το προσμενει. Τη στιγμη που θα συμβει το γεγονος, αυτοματα στελνεται ειδοποιηση απο το Android συστημα σε ολους τους Receiver που εχουν δηλωθει για αυτο και περιμενουν να ενημερωθουν. Ένα Receiver συστατικο δηλωνεται αρχικα στο AndroidManifest.XML αρχειο και επειτα περιμενει στο παρασκηνιο, ανενεργο, μεχρι να συμβει το γεγονος που προσμενει, επειτα να ξεκινησει τη λειτουργια του και να το χειριστει. Η δημιουργια δικης μας υλοποιησης ενος Broadcast Receiver, ειναι δυνατη και γινεται κληρονομωντας την θυγατρικη κλαση BroadcastReceiver η μια απο τις υποκλασεις της, που παρεχονται απο το Android συστημα και προσφερουν προσθετες λειτουργικοτητες αναλογως το πεδιο εφαρμογης, οι οποιες ειναι οι εξης: -19-
AppWidgetProvider, DeviceAdminReceiver, WakefulBroadcastReceiver. Το Broadcast Receiver συστατικο ειναι ενεργο μονο κατα τη διαρκεια κλησης της onreceive(context, Intent) μεθοδου του, η οποια καλειται οταν ληφθει το γεγονος για το οποιο ειχε δηλωθει. Σε αυτο το χρονικο διαστημα που ειναι ενεργο, ειναι δυνατον να χρησιμοποιηθουν και οι υπολοιπες μεθοδοι του συστατικου αυτου ωστε να εμφανιστει και να επεξεργαστει το αποτελεσμα που ληφθηκε. Κατα τη διαρκεια που ο Broadcast Receiver εκτελειται στο κυριως νημα της εφαρμογης, δεν επιτρεπεται η εναρξη χρονοβορων διεργασιων απο αυτον, διοτι το συστημα επιτρεπει ενα παραθυρο δεκα δευτερολεπτων για την ολοκληρωση του, μετα το οποιο ειναι πιθανον αυτος να τερματιστει. Σαν παραδειγμα ακολουθει μια υλοποιηση ενος Broadcast Receiver που χρησιμοποιειται για την υποδοχη Notification απο τον GCM (Google Cloud Messaging) διακομιστη. public class GcmBroadcastReceiver extends WakefulBroadcastReceiver { @Override public void onreceive(context context, Intent intent) { // Explicitly specify that GcmIntentService will handle the intent. ComponentName comp = new ComponentName(context.getPackageName(),GcmIntentService.class.getName()); // Start the service, keeping the device awake while it is launching. startwakefulservice(context, (intent.setcomponent(comp))); setresultcode(activity.result_ok); } } Σε αυτο το παραδειγμα γινεται χρηση της WakefulBroadcastReceiver κλασης. Αυτη αποτελει μια υποκλαση της θυγατρικης BroadcastReceiver οπως αναφερθηκε προηγουμενως και λαμβανει γεγονοτα αφυπνισης συσκευης (device wakeup event). Όταν λαβει το γεγονος θετει σε λειτουργια ενα Service συστατικο το οποιο αναλαμβανει τη διεκπεραιωση μιας διεργασιας. Σημαντικο χαρακτηριστικο ενος WakefulBroadcastReceiver ειναι οτι δεν επιτρεπει την συσκευη να κλειδωσει, -20-
περνωντας σε ανενεργη κατασταση (sleep), κατα τη διαρκεια της λειτουργιας του, δηλαδη ενω καλει το Service συστατικο. Η εναρξη λειτουργιας του Service γινεται με κληση της μεθοδου startwakefulservice(context context, Intent intent) με περασμα των εξης παραμετρων: Context Αποτελει την διεπαφη που παρεχει καθολικες πληροφοριες σχετικα με το περιβαλλον αναπτυξης της εφαρμογης. Intent Ένα Intent συστατικο ειναι μια αφαιρετικη περιγραφη μιας διεργασιας που προκειται να εκτελεστει. Χρησιμοποιειται κυριως για την πυροδοτηση Activity και Service συστατικων. Όταν το Service ολοκληρωσει τη διεργασια που εκτελει, επιτρεπει στην συσκευη να μπορει να κλειδωσει (sleep) καλωντας τη συναρτηση completewakefulintent(intent). Η Intent παραμετρος ειναι η ιδια Intent που περασε αρχικα στο Service o WakefulBroadcastReceiver. Για να ξεκινησει ο κυκλος ζωης του παραπανω Receiver, ειναι απαραιτητο να εχει δηλωθει προηγουμενως στο AndroidManifest.XML αρχειο οπως παρουσιαζεται στο κομματι κωδικα που ακολουθει. <receiver Android:name="pushNotification.GcmBroadcastReceiver" Android:permission="com.google.Android.c2dm.permission.SEND" > <intent-filter> <action Android:name="com.google.Android.c2dm.intent.RECEIVE"/> <category Android:name="net.testproject.test" /> </intent-filter> </receiver> -21-
3.2 Ενεργοποίηση βασικών συστατικών Τα βασικα συστατικα του Android συστηματος (εκτος των content providers), οπως περιγραφηκαν παραπανω ενεργοποιουνται με τη χρηση μιας διεπαφης που ονομαζεται intent. Οι intent διεπαφες αποτελουν ουσιαστικα, ασυγχρονα μηνυματα τα οποια συγχρονιζουν και ενεργοποιουν τα αυτονομα βασικα συστατικα μιας εφαρμογης, σε χρονο εκτελεσης. Μπορουν να χαρακτηριστουν σαν διαβιβαστες μηνυματων που αιτουνται ενεργειες αλλων συστατικων. Επισης εχουν τη δυνατοτητα κλησης λειτουργιων συστατικων απο εξωτερικες εφαρμογες. Υπαρχουν δυο τυποι intents: Explicit intents (σαφείς intents) Τα intent συστατικα αυτου του τυπου προσδιοριζουν το συστατικο που προκειται να ενεργοποιηθει, παρεχοντας το ονομα του, οπως καθοριζεται απο το ονομα της κλασης του. Συνηθως χρησιμοποιειται για την ενεργοποιηση συστατικων εντος της εφαρμογης, γνωριζοντας το ονομα της κλασης που επιθυμουμε να καλεσουμε. Implicit intents (υπονοούμενοι intents) Τα intent συστατικα αυτου του τυπου δεν προσδιοριζουν με συγκεκριμενο τροπο το συστατικο που προκειται να ενεργοποιηθει με το ονομα του, αλλα δηλωνουν γενικα μια ενεργεια προς εκτελεση. Με αυτον τον τροπο επιτρεπεται η κληση ενος συστατικου εξωτερικης εφαρμογης, ωστε να διαχειριστει την επιθυμητη ενεργεια. 3.2.1 Ενεργοποίηση Activities Υπαρχουν δυο τροποι με τους οποιους μπορουμε να ενεργοποιησουμε Activities μεσω Intents και αυτοι αντικατοπτριζονται στις εξης δυο μεθοδους: -22-
startactivity(intent intent, Bundle options) ή startactivity(intent intent) Πυροδοτει ενα νεο Activity χωρις την επιστροφη πληροφοριας οταν αυτη τερματιστει. Παράμετροι intent: Η διεπαφη που παρεχει περιγραφη της υποψηφιας για εκτελεση Activity. options(προαιρετική): Επιπλεον πληροφοριες που καθοριζουν τον τροπο εναρξης του Activity. startactivityforresult(intent intent, int requestcode) ή startactivityforresult(intent intent, int requestcode, Bundle options) Πυροδοτει ενα νεο Activity για το οποιο επιστρεφει πληροφορια σαν αποτελεσμα τερματισμου της λειτουργιας του. Παράμετροι intent: Η διεπαφη που παρεχει περιγραφη της υποψηφιας για εκτελεση Activity. requestcode: Ακεραια τιμη, η οποια αν ειναι μεγαλυτερη η ιση του μηδενος, θα επιστραφει αποτελεσμα μολις τερματιστει η καλουμενη Activity. options (προαιρετική): Επιπλεον πληροφοριες που καθοριζουν τον τροπο εναρξης του Activity. -23-
Εικόνα 3.4: Ενεργοποιηση Activity με χρηση ενος intent. Πηγή: http://www.vogella.com/tutorials/androidintent/article.html#intents_explicit Στην εικονα 3.5 παρουσιαζεται διαγραμματικα η εκκινηση ενος Activity συστατικου απο ενα αλλο, με χρηση ενος intent. Στο διαγραμμα αυτο γινεται κατανοητη η λειτουργια ενος intent καθως και τα σταδια απο τα οποια περναει μεσα στο συστημα. Αρχικα το Activity A δημιουργει ενα intent, οριζοντας την ενεργεια που θα εκπληρωσει αυτο, και στη συνεχεια καλει την startactivity() μεθοδο περνωντας το intent σαν παραμετρο. Στη συνεχεια το Android συστημα αναζητει σε ολες τις εφαρμογες ενα intent που να ταιριαζει με αυτο που καλειται ελεγχοντας τα φιλτρα. Τελος το συστημα πυροδοτει το καταλληλο Activity συστατικο (Activity B) καλωντας την oncreate() μεθοδο του και περνωντας σαν παραμετρο το αρχικο intent. -24-
Εικόνα 3.5: Απεικονιση χρησης ενος explicit intent για την ενεργοποιηση ενος νεου Activity συστατικου Πηγή: http://developer.android.com/guide/components/intents-filters.html 3.2.2 Μεταφορά δεδομένων μεταξύ Activities Η μεταφορα δεδομενων αναμεσα σε Activities επιτυγχανεται ξανα με τη χρηση των intents. Οι intent διεπαφες μπορουν να περιεχουν επιπλεον δεδομενα, τα οποια μεταφερονται στο νεο Activity που ενεργοποιειται και μπορουν να εξαχθουν, χρησιμοποιωντας τις καταλληλες μεθοδους. Για την εισαγωγη δεδομενων καλειται η putextra() μεθοδος του intent αντικειμενου η οποια περιεχει δυο παραμετρους, που αντιπροσωπευουν ενα ζευγος κλειδιου/τιμης. Το κλειδι ειναι παντα τυπου String και αποτελει το αναγνωριστικο του δεδομενου που μεταφερεται. Η τιμη αποτελει την τιμη του δεδομενου το οποιο μπορει να ειναι πρωταρχικος τυπος δεδομενων (int, float, ) οπως επισης αντικειμενο τυπου String, Bundle, Parceable και Serializable. Έτσι δινεται η δυνατοτητα μεταφορας, ακομα και αντικειμενου αναμεσα σε Activities, με την προϋποθεση οτι η κλαση του αντικειμενου αυτου υλοποιει την αφηρημενη κλαση, Serializable. Το Activity συστατικο που καλειται μεσω ενος intent, μπορει να αποκτησει προσβαση στις πληροφοριες που μεταφερει αυτο καλωντας τις μεθοδους getaction() -25-
και getdata() του intent αντικειμενου. Το intent αντικειμενο λαμβανεται μεσω της getintent() μεθοδου. Όσο αφορα τα επιπλεον δεδομενα που εχουν σταλει μεσω της putextra() μεθοδου, μπορουν να ληφθουν απο το νεο Activity με την getintent().getextras() μεθοδο. Ακολουθει ενα κομματι κωδικα, σαν παραδειγμα, παρουσιαζοντας την ενεργοποιηση ενος Activity απο ενα αλλο, τη μεταφορα ενος πινακα απο αλφαριθμητικα (String), με χρηση της putextra() μεθοδου, καθως και τη ληψη και τον χειρισμο των δεδομενων απο το νεο Activity. Μεσα σε ενα Activity πυροδοτειται ενα νεο Activity, με ονομα PagerActivity κανοντας χρηση της intent διεπαφης και στελνοντας επιπλεον δεδομενα με την putextra() μεθοδο. Τα επιπλεον δεδομενα (fetchedimages), ειναι ενας πινακας αλφαριθμητικων, τα οποια απαιτουνται για την λειτουργια του νεου Activity και αντιστοιχουν στο κλειδι, Extra.IMAGES. Intent intent = new Intent(this, ImagePagerActivity.class); intent.putextra(extra.images, fetchedimages); startactivity(intent); Στο παρακατω κομματι κωδικα γινεται η ληψη των επιπλεον δεδομενων (πινακας αλφαριθμητικων) απο το μολις ενεργοποιημενο Activity, PagerActivity και αποθηκευση τους σε τοπικη μεταβλητη. Η διαχειριση των δεδομενων που μεταφερονται απο το intent συστατικο, λαμβανει χωρα στην oncreate() μεθοδο του νεου Activity, η οποια οπως αναφερθηκε σε προηγουμενη παραγραφο καλειται κατα την δημιουργια του και ειναι το καταλληλο σημειο. Bundle bundle = getintent().getextras(); assert bundle!= null; String[] imageurls = bundle.getstringarray(extra.images); -26-
3.2.3 Ενεργοποίηση Services Ένα Service συστατικο, οπως περιγραφηκε σε προηγουμενη παραγραφο, εκτελει διεργασιες στο παρασκηνιο της εφαρμογης και δεν παρεχει διασυνδεση με τη διεπαφη χρηστη. Ένα Service ενεργοποιειται, καλωντας την startservice() μεθοδο και περνωντας ενα intent συστατικο ως παραμετρο. Στην περιπτωση που υλοποιειται client-server διεπαφη με το Service, τοτε μπορει να δεθει (bind) με το συστατικο που το ενεργοποιει καλωντας την bindservice() μεθοδο και περνωντας ενα intent συστατικο σαν παραμετρο. 3.2.4 Αποστολή broadcast γεγονότων Ένα Broadcast Receiver συστατικο, οπως περιγραφηκε παραπανω χρησιμοποιειται για τη ληψη και τον χειρισμο broadcast γεγονοτων του συστηματος η της εφαρμογης. Η αποστολη ενος broadcast μηνυματος προς αλλες εφαρμογες απο ενα Activity γινεται περνωντας ενα intent συστατικο σαν παραμετρο σε μια απο τις ακολουθες μεθοδους: sendbroadcast(intent intent) Αποστολη broadcast της intent παραμετρου προς ολους τους Receivers που εχουν δηλωθει για το συγκεκριμενο γεγονος. Η κληση αυτης της μεθοδου ειναι ασυγχρονη και επιστρεφει αμεσα αποτελεσμα. Ενω εχει ολοκληρωθει η κληση της και η εκτελεση της εφαρμογης συνεχιζει, οι αντιστοιχοι Receivers εκτελουνται ταυτοχρονα. Δεν ειναι δυνατη η επιστροφη καποιας αναφορας απο τους Receivers, σχετικα με τη ληψη του γεγονοτος και επισης αυτοι δεν μπορουν να ματαιωσουν την broadcast μεταδοση. SendOrderedBroadcast(Intent intent, String receiverpermission) Αποστολη broadcast της intent παραμετρου προς ολους τους Receivers που -27-
εχουν δηλωθει για το συγκεκριμενο γεγονος. Με αυτη τη μεθοδο εξυπηρετειται ενας απο τους Receivers καθε στιγμη, ετσι ωστε να επιτραπει σε αυτους που εχουν μεγαλυτερη βαρυτητα να καταναλωσουν το μεταδιδομενο μηνυμα πριν αυτο αποσταλει σε λιγοτερο σημαντικους Receivers. Η κληση αυτης της μεθοδου ειναι ασυγχρονη, επιστρεφει αμεσα αποτελεσμα και η εκτελεση της εφαρμογης, που διεκπεραιωσε την μεταδοση, συνεχιζει ταυτοχρονα με αυτη των Receivers. Η receiverpermission παραμετρος ειναι προαιρετικη και σκοπος της ειναι να επιβαλει περιορισμο στις επιτρεπομενες αδειες (permissions) που θα πρεπει να δηλωνει ο Receiver στο AndroidManifest.XML αρχειο. sendstickybroadcast(intent intent) Παρεχει την ιδια λειτουργικοτητα με την sendbroadcast(intent) μεθοδο, με τη διαφορα οτι η διαρκεια ζωης της intent παραμετρου συμπιπτει με αυτη του Receiver, περιμενοντας να ολοκληρωθει η broadcast μεταδοση. Με αυτον τον τροπο ο αποστολεας ενος γεγονοτος, που την καλει, μπορει να εχει τη δυνατοτητα ληψης αποτελεσματος, μεσω της registerreceiver(broadcastreceiver, IntentFilter) μεθοδου, οταν εχει ολοκληρωθει η brοadcast αποστολη. -28-
3.3 Fragments Ένα Fragment συστατικο, παρομοια με ενα Activity, παρεχει λειτουργικοτητα που σχετιζεται με τη διεπαφη του χρηστη. Έχει πολλες ομοιοτητες με ενα Activity, ομως αποτελει ενα ανεξαρτητο και ευκολα επαναχρησιμοποιησιμο συστατικο, το οποιο περιλαμβανεται μεσα σε ενα Activity. Ένα Activity μπορει να αποτελειται απο ενα συνολο απο Fragments που συνδυαζονται μεταξυ τους, συνθετοντας τη συνολικη διεπαφη του, δημιουργωντας ετσι μια αρθρωτη σχεδιαση. Παρομοιαζοντας ενα Activity με ενα puzzle, τα Fragments αποτελουν τα διαφορα κομματια που το συνθετουν. Καθε Fragment εχει το δικο του κυκλο ζωης, την δικια του αναπαρασταση μιας διεπαφης, λειτουργει σαν αυτονομος δεκτης γεγονοτων και μπορει να προστεθει η να αφαιρεθει σε ενα Activity ενω αυτο εκτελειται. Ο κυκλος ζωης ενος Fragment ειναι αμεσα συνδεδεμενος με τον κυκλο ζωης του Activity που το φιλοξενει και ειναι υποχρεωτικη απαιτηση να ειναι το Fragment ενσωματωμενο σε αυτο. Για παραδειγμα οταν ενα Activity περναει σε αδρανη κατασταση (paused) η τερματιστει, το ιδιο συμβαινει και στα Fragments που περιεχει. Ωστοσο, κατα τη διαρκεια εκτελεσης ενος Activity, υπαρχει η δυνατοτητα να χειριστουμε το καθε Fragment ξεχωριστα, αλλαζοντας την κατασταση λειτουργιας του. Ο χειρισμος των Fragment απο την θυγατρικη Activity επιτυγχανεται με τη χρηση μιας διεπαφης που παρεχεται απο το συστημα, την FragmentManager. Αυτη η διεπαφη επιτρεπει την αλληλεπιδραση των Activities με τα ενσωματωμενα σε αυτα Fragments. Δεν ειναι τυχαιο που η λογικη των Fragments παρουσιαστηκε στην εκδοση 3.0 του Android συστηματος με την ονομασια HoneyComb, που δημιουργηθηκε αποκλειστικα για χρηση σε συσκευες με μεγαλες οθονες (tablets). Χρησιμοποιουνται κυριως για την υποστηριξη μιας δυναμικης και ευελικτης διεπαφης χρηστη κατι που συμβαδιζει με τον τροπο σχεδιασης συστηματων με μεγαλες οθονες. Σχεδιαζοντας ενα αρθρωτο συστημα αποτελουμενο απο μικροτερες και αυτονομες οντοτητες, που αναλαμβανουν τη διαχειριση της διεπαφης με τον χρηστη, ελαχιστοποιειται η πολυπλοκοτητα του συνολικου συστηματος. Επισης καθισταται δυνατη η επαναχρησιμοποιηση συστατικων λογισμικου, που αποτελει κυριο θεμα αυτης της εργασιας. Ειναι σημαντικο κατα τη σχεδιαση του συστηματος, να υλοποιουνται τα Fragments συστατικα ως αυτονομες και επαναχρησιμοποιησιμες -29-
μοναδες, εκτελωντας το καθε ενα ως μια ανεξαρτητη διεργασια. Αυτο ειναι επιθυμητο διοτι καθε Fragment οριζει τη δικη του διεπαφη, οπως επισης την συμπεριφορα και τον κυκλο ζωης του και θα μπορουσαμε να χρησιμοποιησουμε το ιδιο συστατικο Fragment σε πολλαπλα Activity. Τελος μια τετοια σχεδιαση βοηθα σημαντικα στην υποστηριξη διαφορετικων συνδυασμων λειτουργιων για διαφορετικα μεγεθη οθονων. Εικόνα 3.6: Παραδειγμα συνδυασμου δυο διεπαφων σε ενα Activity, οριζομενες απο δυο αντιστοιχα Fragment, για σχεδιαση σε tablet και ξεχωριστη τους υλοποιηση σε δυο διαφορετικα Activity, για σχεδιαση σε κινητη συσκευη. Πηγή: http://developer.android.com/guide/components/fragments.html -30-
3.3.1 Κύκλος ζωής ενός Fragment Ο κυκλος ζωης ενος Fragment συστατικου, ακολουθει την ιδια λογικη με αυτη των Activities και παρουσιαζει αρκετες ομοιοτητες με αυτα. Μια κλαση Fragment οριζει ενα συνολο απο μεθοδους οι οποιες αποτελουν γεγονοτα του κυκλου ζωης της. Καθε μεθοδος του ενεργεια Fragment, πυροδοτειται επειτα απο αλλαγη καταστασης της εφα ρμογης. Μια κλασ η Fragment οριζει τα παρακατω γεγονοτα που αντικατοπτριζουν τον κυκλο ζωης της: onattach(): Καλειται οταν ενα στιγμιοτυπο ενος Fragment συσχετιζεται με ενα στιγμιοτυπο Activity που δεν εχει αρχικοποιηθει ακομα. οncreate(): Καλειται κατα τη δημιουργια ενος Fragment. oncreateview(): Καλειται οταν δημιουργειται η γραφικη αναπαρασταση ενος στιγμιοτυπου Fragment. Η γραφικη αυτη αναπαρασταση αποτελει μερος της διεπαφης του Activity που το περιεχει. onactivitycreated(): Καλειται οταν εχουν δημιουργηθει τα στιγμιοτυπα των Fragment και Activity καθως και οι διεπαφες τους. onresume(): Καλειται οταν το Fragment γινεται ενεργο και ορατο. onpause(): Καλειται οταν ενα Fragment κανει παυση και περναει σε αδρανη κατασταση ενω συνεχιζει να ειναι ορατο. OnStop(): Καλειται οταν ενα Fragment σταματησει να ειναι ορατο. -31-
3.3.2 Συμβατότητα με παλαιότερες εκδόσεις Android Τα Fragments δεν αποτελουν μερος των παλαιοτερων Android εκδοσεων πριν την HoneComb εκδοση (3.0) και δεν μπορουν να χρησιμοποιηθουν απο τα Activity συστατικα. Η υποστηριξη τους σε αυτες τις παλαιοτερες εκδοσεις, ειναι δυνατη με την εγκατασταση ενος επιπροσθετου πακετου που ονομαζεται Πακετο Υποστηριξης (Support Package). Το πακετο αυτο οριζει νεα συστατικα, τα FragmentActivity, τα οποια εχουν την ιδια λειτουργικοτητα με τα Activity, με τη διαφορα οτι μπορουν να υποστηριξουν Fragments σε παλαιοτερες εκδοσεις. Αν ενα υπο αναπτυξη εργο υποστηριζει ελαχιστη εκδοση Android, την εκδοση HoneyComb, τοτε συνισταται η χρηση των Activity συστατικων για την ενσωματωση Fragments και οχι των FragmentActivity. 3.3.3 Επικοινωνία των Fragment με την εφαρμογή Για να επιτευχθει ο μεγιστος βαθμος επαναχρησιμοποιησης των Fragments, θα πρεπει να αποφευγεται η αμεση επικοινωνια μεταξυ τους. Καθε επικοινωνια μεταξυ τους θα πρεπει να συμβαινει μεσω του Activity συστατικου που τα φιλοξενει και τα διαχειριζεται. Για αυτο το σκοπο, θα πρεπει καθε Fragment συστατικο να οριζει μια διεπαφη (interface) και να απαιτει απο το Activity συστατικο που το χρησιμοποιει, να υλοποιει αυτη τη διεπαφη. Έτσι το Fragment δεν θα μπορει και δεν θα χρειαζεται να εχει γνωση για το Activity συστατικο, που το δημιουργησε. -32-
3.4 Android Manifest Καθε εφαρμογη σε Android συστημα θα πρεπει να περιεχει ενα αρχειο που ονομαζεται AndroidManifest.XML. Σε αυτο το αρχειο οριζονται βασικα στοιχεια της εφαρμογης που ειναι απαραιτητα για την εκτελεση της και παρεχονται πριν την εκκινηση της, δηλαδη πριν αρχισει να εκτελειται ο κωδικας. Βασικες εργασιες του AndroidManifest αρχειου ειναι: Ονομασια του Java πακετου της εφαρμογης. Το ονομα αυτου του πακετου αποτελει ενα μοναδικο αναγνωριστικο για την εφαρμογη ετσι ωστε να διακρινεται απο τις υπολοιπες. Οριζει και περιγραφει τα βασικα συστατικα της εφαρμογης, τα Activities, Services, Broadcast Receivers, και Content Providers, τα οποια περιγραφτηκαν σε προηγουμενες παραγραφους. Ονομαζει τις κλασεις, οι οποιες υλοποιουν καθε ενα απο τα βασικα αυτα συστατικα και οριζει τις δυνατοτητες τους (capabilities). Μια δυνατοτητα, για παραδειγμα, ειναι τα intent γεγονοτα που ειναι σε θεση να διαχειριστει ενα συστατικο. Αυτες οι δηλωσεις επιτρεπουν στο συστημα να γνωριζει ποια ειναι τα βασικα συστατικα που αποτελουν την εφαρμογη και υπο ποιες συνθηκες ειναι δυνατον να πυροδοτηθουν. Καθοριζει ποιες διεργασιες θα περιλαμβανουν τα βασικα συστατικα της εφαρμογης. Δηλωνει τις απαραιτητες αδειες (permissions) που θα πρεπει να εχει η εφαρμογη, ωστε να της δινεται η προσβαση σε προστατευομενα μερη του android API και να μπορει να αλληλεπιδρα με αλλες εφαρμογες. Δηλωνει επισης τις αδειες που θα πρεπει να εχουν εξωτερικα συστατικα, οπως χρηστες για παραδειγμα, ωστε να χρησιμοποιουν τα συστατικα της εφαρμογης. -33-
Παραθετει μια λιστα με τις Instrumentation κλασεις που παρεχουν profiling και αλλες πληροφοριες κατα τη διαρκεια εκτελεσης της εφαρμογης. Χρησιμοποιουνται μονο κατα τη διαρκεια αναπτυξης και ελεγχου της εφαρμογης και αφαιρουνται πριν την παραδοση της. Δηλωνει το ελαχιστο επιπεδο του Android API που απαιτειται για την εγκατασταση της εφαρμογης. Παραθετει τις, απαιτουμενες για την μεταγλωττιση, εξωτερικες βιβλιοθηκες. Στην εικονα που ακολουθει (Εικονα 3.7), παρουσιαζεται η γενικη δομη ενος AndroidManifest αρχειου καθως και καθε στοιχειο που μπορει να περιεχει. Εικόνα 3.7: AndroidManifest.XML Πηγή: http://developer.android.com/guide/topics/manifest/manifest-intro.html -34-
3.5 Υποστήριξη Ποικίλων Οθονών To Android λειτουργικο συστημα εχει πλεον γινει μαζικα αποδεκτο απο το μεγαλυτερο ποσοστο κατασκευαστων κινητων συσκευων και οχι μονο. Το μεριδιο της αγορας κινητων συσκευων παγκοσμιως, με εγκατεστημενο το Android λειτουργικο συστημα, ξεπερνα το πενηντα τις εκατο [1], εδραιωνοντας τη θεση του. Έτσι προεκυψε η απαιτηση υποστηριξης ολων αυτων των διαφορετικων συσκευων απο το Android λειτουργικο συστημα, παρεχοντας μια γενικη και αφαιρετικη προσεγγιση σχεδιασης της διεπαφης με τον χρηστη. Η καθε συσκευη διαθετει το δικο της υλικο παρεχοντας ενα πληθος απο ποικιλες οθονες, συμφωνα με τα προτυπα σχεδιασης της, γεγονος που μπορει να δυσκολευει τη διαδικασια αναπτυξης διαλειτουργικων, ανεξαρτητων πλατφορμας εφαρμογων αλλα προσφερει τη δυνατοτητα στους κατασκευαστες κινητων συσκευων να προσαρμοζουν το συνολικο συστημα στις αναγκες τους. Αυτη η προσαρμογη του Android συστηματος σε συσκευες κατασκευαστων ειναι σημαντικη γιατι προσφερει ευελιξια και μπορει να τους καταστησει πιο ανταγωνιστικους, ομως θα μπορουσε να φερει τα εξης μειονεκτηματα: Λιγοτερο διαισθητικα οικοσυστηματα. Αυξηση της πολυπλοκοτητας του συστηματος. Συστηματα επιρρεπη σε σφαλματα και κινδυνους. Συστηματα χαμηλης αποδοσης. Προβληματα ενσωματωσης νεων εκδοσεων Android. Αργη ενσωματωση νεων εκδοσεων Android. Έτσι λοιπον τα πλεονεκτηματα χρησης του Android συστηματος μπορει να αποτελεσουν και μειονεκτηματα υπο ορισμενες συνθηκες. Το Android συστημα ομως προσφερει τη δυνατοτητα αποφυγης ολων των παραπανω, δημοσιευοντας ανανεωμενες εκδοσεις, προσθετες βιβλιοθηκες καθως και μεθοδους σχεδιασης που υποστηριζουν την προσαρμογη της διεπαφης χρηστη σε ποικιλες οθονες. Σε αυτην -35-
την παραγραφο θα επικεντρωθουμε στο τελευταιο. Κυριος στοχος ειναι η αναπτυξη αποδοτικων και στερεων εφαρμογων που εχουν τα θεμελια να υποστηριξουν ολα τα σεναρια χρησης σε συσκευες διαφορετικων οθονων, χαρακτηριστικων κατασκευαστη και διαφορετικης εκδοσης Android. Αυτο επιτυγχανεται κυριως διαχωριζοντας τον κωδικα που υλοποιει την λογικη της εφαρμογης απο τον κωδικα υπευθυνο για την αναπαρασταση της λογικης αυτης, στο χρηστη. Αυτο ομως εχει να κανει κυριως με τη σχεδιαση της εφαρμογης, οπως παρουσιαζεται στο [5]. 3.5.1 Μετρικές Οθόνης Η διαφορετικοτητα των ποικιλων οθονων οριζεται απο τα παρακατω χαρακτηριστικα: Μέγεθος Οθόνης (Screen Size) Το μεγεθος της οθονης καθοριζεται απο το πραγματικο μεγεθος της, οπως μετραται απο την διαγωνιο της, χρησιμοποιωντας ιντσες σαν μοναδα μετρησης. Για απλοτητα, το Android συστημα εχει ομαδοποιησει τα διαφορα μεγεθη οθονων σε τεσσερις γενικες κατηγοριες: μικρη (small), κανονικη (normal), μεγαλη (large), και πολυ μεγαλη (extra large). Εικόνα 3.8: Κατηγοριες μεγεθους οθονης. Πηγή: http://developer.android.com/guide/practices/screens_support.html -36-
Πυκνότητα Οθόνης (Screen Density) Η πυκνοτητα της οθονης καθοριζεται απο την ποσοτητα των pixels που υπαρχουν μεσα σε μια περιοχη της οθονης και αναφερεται ως dpi (dots per inch) δηλαδη pixels ανα ιντσα. Για απλοτητα, το Android συστημα εχει ομαδοποιησει τις διαφορες πυκνοτητες οθονων σε τεσσερις γενικες κατηγοριες: χαμηλη (low), μετρια (medium), υψηλη (high), και πολυ υψηλη (extra high). Εικόνα 3.9: Κατηγοριες πυκνοτητας οθονης. Πηγή: http://developer.android.com/guide/practices/screens_support.html Ανάλυση Οθόνης (Resolution) Τα συνολικα pixel της οθονης. Για την υποστηριξη ποικιλων οθονων, οι εφαρμογες δεν χρησιμοποιουν την αναλυση οθονης, παρα μονο το μεγεθος της οθονης και την πυκνοτητα της, οπως οριζονται στις αντιστοιχες ομαδες. 3.5.2 Σχεδίαση Η πυκνοτητα της οθονης δεν σχετιζεται με το μεγεθος της. Έτσι για παραδειγμα, αν επρεπε να υποστηριξουμε δυο η παραπανω οθονες, ιδιου μεγεθους αλλα διαφορετικης πυκνοτητας σε pixel, τοτε η σχεδιαση του συστηματος θα ηταν ιδιαιτερα δυσκολη και επιρρεπης σε σφαλματα. Σε ενα τετοιο σεναριο χρησης θα επιθυμουσαμε να δουλευουμε με ενα γενικο τροπο, οριζοντας και χρησιμοποιωντας μια μοναδα μετρησης ανεξαρτητης του pixel. Η σχεδιαση της διεπαφης χρηστη με -37-
τροπο ανεξαρτητο της πυκνοτητας ειναι σημαντικη, διοτι ενα στοιχειο της εφαρμογης που εμφανιζεται στην οθονη, οπως ενα κουμπι (button) για παραδειγμα, εμφανιζεται μεγαλυτερο σε μια οθονη χαμηλης πυκνοτητας, ενω μικροτερο σε μια υψηλης αναλυσης. Αυτο προκαλει συγχυση στο χρηστη και δεν συμβαδιζει με τους κανονες που αφορουν τη σχεδιαση της εφαρμογης και της εμπειριας του χρηστη απο τη χρηση της. Στις εικονες 3.10 και 3.11 φαινεται η διαφορα αναμεσα σε μια εφαρμογη που δεν παρεχει σχεδιαση ανεξαρτητης πυκνοτητας και σε μια ανεξαρτητης αντιστοιχα. Εικόνα 3.10: Παραδειγμα εφαρμογης χωρις την υποστηριξη για διαφορετικες πυκνοτητες, οπως φαινεται σε οθονες χαμηλης, μετριας και υψηλης πυκνοτητας. Πηγή: http://developer.android.com/guide/practices/screens_support.html Εικόνα 3.11: Παραδειγμα εφαρμογης με υποστηριξη για διαφορετικες πυκνοτητες, οπως φαινεται σε οθονες χαμηλης, μετριας και υψηλης πυκνοτητας. Πηγή: http://developer.android.com/guide/practices/screens_support.html Το Android συστημα παρεχει τη δυνατοτητα για την υλοποιηση γραφικης διεπαφης χρηστη, ανεξαρτητης της πυκνοτητας της οθονης. Αυτο επιτυγχανεται με τους εξης -38-
δυο τροπους: Το συστημα παρεχει μια γενικη μοναδα μετρησης των γραφικων συστατικων, ανεξαρτητης των pixel. Αυτη η μοναδα μετρησης ονομαζεται dp (density-independent pixel) και αποτελει μια εικονικη μοναδα που συνισταται να χρησιμοποιειται αντι των pixel κατα τον ορισμο της γραφικης διεπαφης, ετσι ωστε να εκφραζονται οι διαστασεις της η η θεση της με εναν ανεξαρτητο της πυκνοτητας, τροπο. Μια μοναδα dp, εχει οριστει ως ενα pixel σε μια οθονη 160 dpi και κατα την εκτελεση της εφαρμογης, το συστημα την μετατρεπει με διαφανη τροπο, στα αντιστοιχα και πραγματικα pixel της οθονης. Η μετατροπη αυτη γινεται με βαση την εξης εξισωση: px = dp * (dpi / 160) Το συστημα μετατρεπει τα γραφικα συστατικα που ειναι μερος της συνολικης διεπαφης χρηστη στο καταλληλο μεγεθος, με βαση την πυκνοτητα της οθονης. Για να επιτευχθει αυτο, δινεται η δυνατοτητα εισαγωγης ενος γραφικου συστατικου (εικονα bitmap για παραδειγμα), για τις τεσσερις διαφορετικες βασικες πυκνοτητες, χαμηλη (ldpi), μετρια (mdpi), υψηλη (hdpi), πολυ υψηλη ( xhdpi) καθως και μια ακομα μεγαλυτερης πυκνοτητας (xxhdpi). Έτσι μπορουμε να τοποθετησουμε το ιδιο γραφικο συστατικο σε πεντε διαφορετικες αναλυσεις, εισαγοντας το σε καταλληλο φακελο κατω απο την res (resources) κατηγορια, οπως οριζεται απο το συστημα για τη διαχειριση των πορων. Έπειτα, επιλεγεται το καταλληλο συστατικο σε χρονο εκτελεσης, αναλογως την πυκνοτητα της οθονης. Στην εικονα 3.12 παρουσιαζονται οι πεντε αυτοι φακελοι. -39-
Εικόνα 3.12: Φακελοι για την χρηση γραφικων συστατικων, διαφορετικης αναλυσης, αναλογως την πυκνοτητα οθονης. To Android συστημα ειναι σχεδιασμενο για την υποστηριξη ολων των ειδων οθονων, προσαρμοζοντας δυναμικα το περιεχομενο που εμφανιζεται στην οθονη της καθε συσκευης. Τα βηματα που θα πρεπει να ακολουθησουμε ωστε να το εκμεταλλευτουμε με τον καλυτερο δυνατο τροπο ειναι τα εξης: Δήλωση των υποστηριζόμενων μεγεθών οθόνης, από την εφαρμογή Δηλωνοντας, στο AndroidManifest αρχειο, τα υποστηριζομενα μεγεθη οθονης, επιτρεπεται η εγκατασταση της εφαρμογης μονο σε συσκευες που πληρουν τις προδιαγραφες αυτες. Επισης μπορει να επηρεασει τον τροπο που διαχειριζεται το συστημα, την σχεδιαση της γραφικης διεπαφης χρηστη σε μεγαλυτερες οθονες. Στην εικονα 3.13 παρουσιαζεται ενα κομματι κωδικα που εκτελει αυτη τη δηλωση, και επισης οριζει οτι επιτρεπονται οθονες οποιασδηποτε πυκνοτητας με την Android:anyDensity= true εντολη, καθως και το ελαχιστο πλατος οθονης Android:requiresSmallestWidthDp= 600 εντολη. -40- με την
Εικόνα 3.13: Δηλωση των υποστηριζομενων μεγεθων οθονης στο AndroidManifest αρχειο Παροχή διαφορετικών γραφικών διεπαφών για τα διάφορα μεγέθη οθόνης To Android συστημα προσαρμοζει την γραφικη διεπαφη χρηστη και τα συστατικα της, ετσι ωστε να εμφανιζονται με τον ιδιο τροπο σε οθονες διαφορων μεγεθων, με διαφανεια και συνεπεια. Σε πολυ μεγαλες οθονες ομως, οπως αυτες των tablet, θα ηταν πιο αποδοτικο και θα παρειχε καλυτερη εμπειρια χρηστη, αν εκμεταλλευομασταν τον επιπλεον χωρο. Για παραδειγμα σε μια μικροτερη κινητη συσκευη διαιρουμε την επιθυμητη λειτουργικοτητα σε πολλαπλες οθονες, αντιστοιχιζοντας την καθε μια σε ενα Activity συστατικο. Σε μια συσκευη μεγαλυτερης οθονης θα ηταν δυνατο να συμπεριλαβουμε ολες αυτες τις λειτουργικοτητες σε μια μονο οθονη, με χρηση των Fragment συστατικων. Έτσι καθε Fragment θα ηταν υπευθυνο για τη διαχειριση ενος λειτουργικου κομματιου της οθονης και ολα μαζι θα συνεθεταν τη συνολικη γραφικη διεπαφη. Το Android συστημα παρεχει τη δυνατοτητα επιλογης και πυροδοτησης διαφορετικης γραφικης διεπαφης χρηστη, οπως οριζεται μεσα στον layout φακελο, αναλογως το μεγεθος της οθονης. Έτσι για καθε υποστηριζομενο μεγεθος οθονης, θα μπορουσαμε να αναπτυξουμε την γραφικη διεπαφη χρηστη που επιθυμουμε και το συστημα θα αναλαμβανε την πυροδοτηση της καταλληλης, αναλογως του μεγεθους της. -41-