SYNOPSIS. Analyse & Design for Android-systemet

Transkript

1 SYNOPSIS. Analyse & Design for Android-systemet Erhvervsakademiet Lillebælt Studerendes navn: bjarne hanasen klasse: Fag: Store systemer niveau: vejleder: godkendt: 1. Titel (præsentation af eksamensprojektets emne) Undersøge hvordan dele af Android systemet er konstrueret, 2. Problemformulering Undersøge, blotlægge, og overveje hvorfor valgte løsninger indenfor Systemdesign: vigtige klasser og subsystemer, design goals Reusing pattern i solution: omtale hvordan A bruger kendte patterns Jeg skal se på fordele og ulemper med de valgte løsninger, fx hvordan skalerer de? Muligvis undersøge hvordan design-beslutning sker i dette community baserede system 4. Redegørelse af problemstillinger Android er vist et community-baseret, anarkistisk, men retningsstyret af Google Hvordan sker udviklingen indenfor sådan type system. Jeg regner ikke med at komme helt omkring, men laver nedslag i områder jeg synes er vigtige, interessante og specielle for Android, overvejende ud fra en teknisk synsvinkel. Indhold: 1. System design / Design Goals 2. Opdeling af systemet i subsystemer 3. Arkitektur-stile der anvendes 4. Reusing pattern, eksempler 5. Metode, teori og fremgangsmåder Læst del internetkilder, suppleret med egne implementering af del eksempler. 7. Materiale- og Litteraturliste OOSE: Object-Oriented Software Engineering Using UML, Patterns, and Java 3.ed, Bernd Bruegge & Allen H. Dutoit Android-specifikke del: Ref.1: Ref.2: 1.pdf

2 2/11 Da man udbyggede Android systemet i sammenslutningen Open Handset Alliance har man vel gennemgået Problem statement, requirement og analyse faserne. Denne synopsis omhandler system design fasen, hvor jeg laver nedslag i områder jeg synes er vigtige, interessante og specielle for Android. 1. System design / Design Goals Ingen tvivl om, at vigtige mål har været -Extensibility( udvidelsesmuligheder ), Modifiability, adaptability -> Systemet er bygget efter SOA-principper og understøtter komponent-baseret udvikling, se s.7. -Low cost Det har været med til at cementere, at der er lagt vægt på en åben platform, hvor en stor gruppe af uafhængige grupper/personer udgør et levende community, hvor udviklerne giver inspiration og input til hinanden. -Brugervenlighed for udviklerne har haft høj prioritet: det skal være nemt at komme i gang, med et opensource, lowcost, udviklingsmiljø. Man har valgt at lave letvægtsudgave af java, medvirkende til frigørelse fra Oracles kontrol, bl.a. fordi: -java er objektorienteret, og mange udviklere har selvfølgelig konkret arbejdet med det, og med fx Eclipse findes avancerede opensource udviklings-værktøjer. Bjarne Hansen, USS synopsis 2

3 -hver applikation kører tråd i egen sandbox med egen VM(Dalvik), det øger sikkerheden. -automatisk hukommelses-oprydning. Sandbox og hukommelses-oprydning er særligt vigtigt i dette miljø, hvor der hele tiden tilføjes (kun delvist testede) applikationer til en mobil-platform med begrænsede ressourcer. Som konsekvens af det, er indbyggede applikationer, Calender, mv. delvist kodet i java efter samme retningslinjer som communitiets applikationer, men inddrager native libraries til kritiske operationer, så kun 1/3 fortolkes af VM en (ref 1, s.22). Framework ene (i java) understøtter dermed begge type udviklere. Se figur over systemets subsystemer andet sted, s.7. Udvikling i communitiet er med til vedvarende at sikre voksende brugervenlighed for slutbrugerne. Alt i alt synes jeg, at det er en vældig god business case. 3/11 Addressing Design Goals s. 264 i OOSE Mapping Subsystems to Processors and Components Identifying and Storing Persistent Data Providing Access Control 269! Designing the Global Control Flow Identifying Services Identifying Boundary Conditions 279 Data-forhold er specielt for Android Storing Persistent Data Der er ikke noget fælles data-repository i systemet. Det falder fint i tråd med komponent-baseret arkitektur. En applikation A skal eksplicit stille sine data til rådighed til andre applikationer vha ContentResolver objekt. Hvis applikation B skal tilgå data i A vil man normalt bruge den indbyggede SQLite database. A skal returnere data på tabelform. Sådan skaffer B i model-laget data fra tablex i data-laget hos A: Bjarne Hansen, USS synopsis 3

4 4/11 Der er 4 typer data-kilder HashMaps(non-persistent) Database tabeller i SQLite database, en db til hver applikation. Filer Netværk, tilgår data på anden enhed. Filer og tabeller tilgås vha. ContentResolver. Service Agents kan bruge Content Resolver Til ekstern komponent el. en netværksagent. Model-Data lagene Model-del, app B: Uri uri= Content://A/tableX // de søgte data findes i tablex i database i A ContentResolver cr=getcontentresolver(uri); Cursor c=cr.query(select-stmt); //data returneres på tabelform, data udtrækkes rækkevis Data-lag-del: ContentResolver er således et façade-objekt til subsystem DataLayer, der fremskaffer ConcreteContentProvider der kan skaffe uri-data. Man kan ikke tilgå DataLayer på anden måde Tilsvarende findes openinputstream(uri uri) og openoutputstream(uri uri) i ContentResolver, der giver adgang til fil-data. Sikkerhedsforhold, Access Control er specielt vigtigt område i dette åbne udviklermiljø, et case: Når der kommer en sms til mobilen så udsender systemet en brodcast Intent med action-felt= android.provider.telephony.sms_received Man kan lave app der aflytter denne type brodcast, og så registrer den med denne AndroidManifest.xml -filen. <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android=" package="android.tutorials" <! authorization, fuld info om udvikleren --> android:versioncode="1" android:versionname="1.0" > <!-- når useren installerer så skal han godkende app lytter til SMS --> <uses-permission android:name="android.permission.receive_sms" /> <application <receiver android:name=".mysmsreceiver" android:enabled="true" > <intent-filter> <action android:name="android.provider.telephony.sms_received" /> </intent-filter> </receiver> </application> Bjarne Hansen, USS synopsis 4

5 Intent-filter kan laves ud fra manifest-filen; en applikation vil kun håndtere request, som altså kommer i form af et Intent-objekt, hvis populært sagt Intentens krav kan passere filteret. 5/11 Problemet er, har jeg læst, at mange app-udviklere ønsker langt mere omfattende user-permissions end nødvendigt for virkemåden, og at brugeren ofte ikke læser den lange accept-liste ordentligt igennem/ikke forstår betydningen. Det er jo en ret alvorlig sikkerhedsrisiko, at app en kan opsamle sms og ved lejlighed( app skal updateres, tryk ) uploade disse! Selvfølgelig kan man komme efter udvikleren efter et misbrug er sket og opdaget, man kender jo udviklerens identitet(!?) men Men skal nøjes med at hente programmer fra store sites som GooglePlay, for her anbefales app af andre brugere. Men når alt kommer til alt ser vi her svagheden ved åbent udviklingsmiljø sammenlignet med Apples verden med langt mere kontrol. Global Control Flow Systemet bruger i høj grad Event-drevet kontrol: MVC bruges traditionelt, mere specielt er denne form for database-triggermekanisme: I data-laget i app A, hvor data fremskaffes direkte fra databasen vha en cursor, med metoden public Cursor query(uri uri, String[] projection, String selection, String[] selectionargs, String sortorder){ c.setnotificationuri(getcontext().getcontentresolver(), uri); c=cursor // registreres som lytter til ændring i data givet ved uri en. Hvis appl viser data på skærmen, så har app mulighed for at kører dette query igen efter de nye data. Det udgør faktisk en trigger-mekanisme, som det kendes i SQL, men notifikationen skal ske aktivt af programudvikleren, ved kald af notifychange(). } ContentResolver.notifyChange(Uri uri, ContentObserver observer), Notify registered observers that a row was updated, fx cursors. Modellen får besked om en dataændring I UI, og giver besked videre med.notifychange() til cursorer der lytter til det pågældende dataområde. Hvis fx A.tableX ændres, vil app B forny sine data næste gang app B bruger data (så vidt jeg har forstået forholdet!?). ContentProvider har metoden onlowmemory () som kaldes af systemet hvis memory-ressourcerne er kritiske. ContentProvideren har fremskaffet data som resultat-tabel, som caches. Når metoden kaldes ønsker systemet at app opgiver cached data [det er naturligvis app-udvikleren der aktivt skal frigive holdte ressourcer i sin implementering af onlowmemory () ]. Deployment Mapping Subsystems to Processors and Components Filosofien i Googles applikationer er at deploye store dele af applikationer i skyen. Fordele for klient: mindre HW-krav til klient(i høj grad relevant for bærbart system), altid nyeste versioner af programmer, og måske færre problemer med sikkerhedshuller i applikationer (til gengæld foregår Bjarne Hansen, USS synopsis 5

6 6/11 næsten al kommunikation over nettet og disse data kan opfanges); for Google: de kan samle brugsstatistik og skaffe indkomst ved reklamer ligesom ved GoogleSearch. Ulempen er selvfølgelig, at der skal være netadgang næsten hele tiden. Personligt ærgrer det mig at GoogleMap ikke har muliggjort caching af kortmateriale; er man på tur i udlandet er netværkstrafik kostbar, og det koster også en del batterilevetid. [ Faktisk har GoogleMaps nye version, juni-2012, mulighed for at cache kortmateriale] Lifecycle for en application Boundary conditions Ret komplekst, se figuren over Application s Life Cycle. Hvis systemet er ved at løbe tør for ressoucer kan det uden videre udføre kill-process på primært stopped, men også paused, applikationer. Før app sættes til paused tilstand kalder systemet onpause(), her bør udvikleren gemme data der skal genindlæses: ikke gemt bruger-input, contextdata, som beskriver det miljø app afvikles i. Når brugeren igen aktiverer en killed app så startes forfra med oncreate(), og her kan man indlæse context-data. I onstart() kan bruger-input hentes protected void onpause(){ super.onpause (); // Save user preferences in file PREFS_NAME. We need an Editor object to // make changes. All objects are from android.context.context SharedPreferences settings = getsharedpreferences(prefs_name, 0); SharedPreferences.Editor editor = settings.edit(); editor.putboolean("silentmode", msilentmode); //silentmode-valget gemmes // Don't forget to commit your edits!!! editor.commit(); } } Bjarne Hansen, USS synopsis 6

7 7/11 2. Opdeling af systemet i subsystemer Decomposing the System, to egenskaber ønskes -Høj cohesion, sammenhængskraft: subsystem indeholder klasser der samarbejder i høj grad. -Lav kobling: klasserne indenfor et substem skal gerne være uafhængige af klasserne indenfor andet subsystem, el. med kun lidt interaktion, kobling. Og interaktion skal ske gennem veldefineret subsystem-interface. I klassediagram kan man få idé om antal forbindelser, koblinger fig.6-7,oose Dette giver en form for codecontract-udvikling: Hvert team får ansvar for et subsystem, andre teams kender kun subsystemets overordnede virkemåde og interfacet, men ikke implementeringen, så en ændring i implementeringen påvirker ikke andre subsystemer. Desuden er et subsystem for et team mere overskueligt, for det indeholder færre antal klasser, og arbejder endda indenfor samme område. På den måde kan flere teams optimalt arbejde parallelt med meget lidt koordination, og det kan presse cost og udviklingstid nedad. Figuren viser at der for given opgavestørrelse faktisk er praktiske grænser for udviklingstiden, det nytter ikke at sætte flere mand på! Bjarne Hansen, USS synopsis 7

8 8/11 Metoder til opdeling i Subsystemer i Android-applikationer 5 -Layered arkitektur: Ekstern service-forbruger: kald fra andre komponenter til Service, BroadcastReceiver el. ContentProvider komponenter i applikationen. Bjarne Hansen, USS synopsis 8

9 9/11 Systemet bruger i høj grad MVC baseret på Publicher-subscriber pattern, hvor ændringer i data notificeres til subscriber, hvorefter subscriber kan hente nye data. Et view forspørger efter data i modellen, og modellen henter data vha. CoontentResolver objekt. Man ser altså, at der faktisk kun er forbindelse mellem lagene via få veldefinerede metoder. Systemet opfylder kravene til gennemført layered arkitektur. Framework og Library subsystemer Framework inkluderer kontrolmekanismer for flowet gennem komponenterne. Library er mere en samling af utility-klasser, som kan virke uafhængigt af hinanden. Der er flere typer ContentProviders i systemet som frameworks, til media-former, SQLite data mv. De er samlet i én java-package android.content, som bl.a. rummer ContentResolver, ContentProvider, Intent og IntentFilter klasserne; Intent og IntentFilter bruges når app ønsker bruge/give service og data ifht. anden app, så det er fornuftigt at klasserne defineres i denne pakke. Figur over systemets subsystemer. 3. Arkitektur-stile der anvendes Event-drevet, decentralt datasystem, komponent-baseret er allerede omtalt. Systemet implementerer service orienteret arkitektur, SOA Man kan lave en multimedia app og registrere den i systemet med dens AndroidManifest.xml fil, som service-udbyder til behandling af lyd-klip fra nettet. Filen bruges til at generere Intent-filter. <activity android:name="myvideoapp" <intent-filter... > <data android:mimetype="video/mpeg" android:scheme="http"... /> Bjarne Hansen, USS synopsis 9

10 <data android:mimetype="audio/mpeg" android:scheme="http"... />... </intent-filter> 10/11 Ønsker App A at afspille filen udsender A en Intent, en message der udtrykker intention, ud på systemets message-bus, efterspørger bestemt service: Intent myactivity = new Intent(android.content.Intent.ACTION_VIEW); Uri data = Uri.parse(" String type = "audio/mp3"; myactivity.setdataandtype(data, type); startactivity(myactivity); Hvis der er flere applikationer, der kan håndtere mp3-filer, skal brugeren selv vælge default applikation (ligesom åben med i Windows). Systemet udgør brokeren i SOA-trekanten, sender requesten videre til service-udbyderen og aktiverer denne. Det er i høj grad et client-server-forhold Systemet understøtter komponent-baseret, plug&play, applikations-udvikling. En udvikler kan lave lydafspiller uden ændring af det øvrige system. 4. Reusing pattern eksempler Det er godt at have en værktøjskasse af velgennemtænkte, velafprøvede design patterns. Det giver -Genbrug, -Fælles vokabularium, -Fordele og ulemper ved forskellige mønstre er også velkendte. Det er med til at mindske risici. Strategi-mønsteret bruges flere steder til at vælge optimale algoritme, afhængig af ydre forhold. Man kan vælge den optimale netværksforbindelse med modellen i fig.8-10 i OOSE bogen. Eller med locations-service. En applikation bruger automatisk GPS-Location hvis GPS er muligt, som skitseret på figuren. GPSLocation og CellularLocation er subclasser af LocationInterface. Det bruger GoogleMap. Bjarne Hansen, USS synopsis 10

11 11/11 UI komponenter bruger Composite pattern som i mange andre objekt orienterede systemer. ViewGroup objekt er et container-objekt der kan rumme komponenter, mens et View er et simpelt komponent. Når et layout skal tegnes, gennemgås først måle -fase fra roden og ned i hierarkiet, der beregnes hvor meget plads hver komponent ønsker; i fase 2 sker så den egentlig tegning igen oppefra og ned. Bjarne Hansen, USS synopsis 11