Android Passive MVC: a Novel Architecture Model for Android PDF

Design Patterns for Mobile Devices

usage mobile design patterns can improve the application in terms of performance and from the mobile platform's architecture

Online Library Mobile Applications Architecture Design And

Apr 9 2022 Xamarin Mobile Application Development is a hands-on Xamarin.Forms primer and a cross-platform reference for building native Android

File Type PDF Android Development Patterns Best Practices For

for Building Mobile Apps Android Jetpack: Improve Your App's Architecture Protips: in 2020) Design Patterns in Plain English

Site To Download Mobile Applications Architecture Design And

Next you'll discover the design concepts involved in application architecture and the patterns in software development

Design Patterns for Developing High Efficiency Mobile Application

Nov 16 2013 As architectural design plays a key role to overcome those constraints

Read Free Android Development Patterns Best Practices For

May 9 2022 Guide to app architecture

Architecture and Architectural Patterns for Mobile Augmented Reality

Jul 12 2021 as Android and iOS

Software Architecture Patterns for Extending Sensing Capabilities

Apr 6 2022 CARP Mobile Sensing (CAMS)

Android Passive MVC: a Novel Architecture Model for Android

proposed architecture by implementing it on a real application. Keywords—Smart mobile devices (smartphones tablets); design patterns; Model-View-Controller

Site To Download Xamarin Mobile Application Development Cross

May 9 2022 Forms

AndroidPassi veMVC:aNovelArchitectureModel

forAndroid ApplicationDev elopment

KarinaSokolo va

,MarcLemercier

UniversityofTechnologyofT royes,France

{karina.sokolova,marc.lemercier}@utt.fr

LudovicGarcia

EUTECHSSII,France

{k.sokolova,l.garcia}@eutech-ssii.com Abstract - Nowadaysthedemandfor mobileapplicationde- velopmentisveryhigh. To becompetitive,amobile application shouldbecost-effecti ve andbeofgoodquality.Thearchitectur e choiceis importanttoensur ethequality oftheapplication over timeandto reducede velopmenttime. Twomainleadersar e veryrepresentedon themobilemarket:Apple(iOS)andGoogle (Android).TheiOSdev elopmentisbased ontheModel-V iew- Controllerdesignpatternand iswellstructur ed.TheAndroid systemdoesnot require anymodel:the architecturechoice andtheapplication qualityhighlydepends onthede veloper experience.Heterogeneous solutionsslowdown thedev eloper, whiletheone known designpattern couldnotonlyboost developmenttime,butimprov ethemaintain ability,extensibility andperformance oftheapplication.Inthisw ork,wein vestigate somewidelyused architecturaldesign patternsand proposea unifiedar chitecturemodeladaptedtoAndroiddev elopment.We providetheimplementationexampleandtestthe efficiencyofthe proposedarchitectureby implementingitonarealapplication. Keywords - Smartmobiledevices (smartphones,tablets);design patterns;Model-View-Controller; Androidarchitecturemodel;An- droidpassive MVC.

I.INTRODUCTION

Themobilemark ethasgro wnrapidlyinrecentyears.

Manyenterprisesfeeltheneed tobe presentonmobile

marketsandproposetheirservices withmobileapplications. Comparedtocomputer programs,mobile applicationsoften havelimitedfunctionalities,shortershelflifeand lowerprice. Newapplicationsshouldbede velopedf asttobe cost-effectiv e andupdatedoften tokeep usersinterested.The qualityof theapplicationshould notbene glected,asmobile usersare verypernickety andcompetitionisstiff.Architecturechoice remainsimportantfor mobileapplications toensurequality: mobileapplicationsas wellasother systemscouldbe complex andev olveovertime.

Thedemandfor smartphoneapplicationde velopmentis

veryhighespeciallyforthe two marketleaders: Apple(iOS) andGoogle(Android). Multi-platformsolutions, suchas Phone-Gap,RhodesRhomobile andTitanium Appcelerator reducedev elopmenttime,asoneapplicationisdeveloped for severalplatforms[1],buthav elimitedpossibilities -often requiringnativ eplug-ins.Multi-platformsolutionsalsoadd complexitytothe native code(e.g.weblayer)thatdecreases theperformanceof theapplication. Thesupportof non-native solutionscouldbe abandoned.Nativ esolutionsenable use ofall theplatform's optionswithbetter performanceand lightercode,t hereforede velopersoftenchoosenativ esoftware developmentkits(SDK).

TheiOSSDK imposestheModel-V iew-Controller(MVC)

designpatternfor theiOS applicationdev elopment[2].An- droidrequiresno particulararchitecture[3] -dev elopers chooseasuitabl earchitecture fortheirapplicationsthatis especiallydifficult forlessexperienceddev elopers.Complex applicationsthatdo notfollow anyarchitecture canendas a bigballof mudcode:incomprehensible andunmaintainable [4].Suitablearchitecture canimprov ethreenon-functional requirementsofsoftw arestructural quality:extensibility,main- tainabilityandperformance. Adefinedarchitecture couldad- ditionallyreducethe complexity ofthecode, simplifythe documentationandf acilitatecollaborationw ork[5].

Androiddev elopmentbooksandtutorialsaremostlyfo-

cusedonAndroid SDKtechnical detailsand userinterface design.Onlya feww orkshav ebeendedicatedtotheAndroid applicationarchitecture,while theAndroidcommunity identify anarchitectureas animportant partofsuccessful systemdesign anddev elopment.Developersopenmanydiscussionsabout suitableAndroidarchitecture onforums,blogs andgroups. Inthisw ork,wepro videanoverview ofsomewidely used architecturalpatternsand proposeanMVC-based architecture particularlyadaptedto theAndroid system.AndroidP assive MVCsimplifiesthe development workgi vingtheguidelines andsolutionsfor commonAndroidtasks enablingthecreation oflesscomple x,high-performance,e xtendableandmaintain- ableapplications. Theremainderof thepaper isorg anizedasfollo ws:the secondsectionpresents several architecturalpatternsused in softwaredevelopment.Section 3presentsbrieflytheAndroid SDKande xistingdif ficultiesinadaptingoneknown architec- turetoAndroid. InSection4, wepropose anadaptationof the MVCdesignpattern tothe Androidenvironment andprovide animplementatione xample.Section5 evaluatestheAndroid

PassiveMVCmodelandSection6concludesthis workand

presentssomeperspecti ves.

II.FUNDAMENTALDESIGNPATTERNS

WepresentfourpopularMVx-based designpatternsin

historicalsequence.These patternsarewidely usedindesktop andweb applicationsdev elopment.Ifmobile developmentas- similatessimilardesign, dev elopersmoving fromothersystems couldtake advantageoftheirkno wledge.Differentcomponents

andexisting variantsofmodelsareincluded inthedescription.7Copyright (c) IARIA, 2013. ISBN: 978-1-61208-276-9PATTERNS 2013 : The FIfth International Conferences on Pervasive Patterns and Applications

Fig.1.Classic MVCandApplication ModelMVC

A.Model-Vie w-Controller(MVC)

Presentedin1978 [6],Model-Vie w-Controlleristhe oldest designpatternand hasbeen successfullyapplied formany systemssinceit' screation[7], [8].Thegoalofthismodel isto separatebusiness logicfrompresentationlogic.Theb usiness logicmodifications shouldnotaf fectthepresentation logic andvicev ersa[6].MVC consistsofthreemaincomponents: Model,ViewandController.TheModelrepresentsadata tobe displayedonthe screen.Moregenerally ,ModelisaDomai n modelthatcontains theb usinesslogic,data tobemanipulated anddataaccess objects.TheViewisavisual componenton thescreen,such asab utton.TheControllerhandlesev ents fromuseractions andcommunicates withtheModel.The ViewandtheControllerdependonthe Model,but theModel iscompletelyindependent. Thedesignpatt ernstatesthat all Viewsshouldhav easingleController,but oneControllercan besharedby several Views.

MVCmodelha vethree varieties:ClassicMVC,Passive

ModelMVCand ApplicationModel MVC(AM-MVC).The

schemeoftw oMVC modelvarietiesisshown inFigure1.

TheClassicMVC issho wnonthe leftandthe AM-MVCis

shownontheright. Inallv ariants,Controllerhandlesev entsandcommunicates directlywitha Modelthatisi ndicatedbya blackarrow.Onthe ClassicMVCthe Modelprocessesdataand notifiestheView.

TheViewhandlesmessagesfrom theModelandupdatesthe

screenusingthe datareceiv edfromthe Model.Thisbeha viour isimplementedusing theObserv erpattern(gre yarrow in Figure1).Con versely, thecommunicationbetweentheModel andtheViewinPassi veModelMVCisdoneexclusivelyviathe Viewandfinallythe Viewmakeschangesonthescreen [9]. TheAM-MVCis animprov edClassicMVC withanadditional component.TheApplicationModelcomponentwas addedfor thepresentationlogic (e.g.changethe screencolourif the valueisgreaterthan4) thatwas oftenaddedto View or Controllerpreviously andmakesabridgebetween theModel andtheView-Controllercouples.

B.Model-Vie w-Presenter(MVP)

TheModel-Vie w-Presenterwasintroducedin1996asan

MVCadaptationfor themodernneeds ofev ent-driven systems [10].Themodel consistsofthree components:Model,View andPresenter.Inthis model,theViewrepresentsafull screen andit handlesev entsfromthe useractions.ThePresenteris

Fig.2.Supervising controllerandP assiv eview

responsibleofthe presentationlogic.The ModelisaDomain model.

Therearetw otypes ofMVP:Supervisingcontrollerand

Passiveview.Bothmodelsares howninFigure2.TheSuper- visingcontrolleruses theObserv erpatternfor thecommunica- withtheModeltosav ethedataifthereisnochangeto be madeonthe screen.Otherwise,t hecommunicationbetween theViewandtheModelismadevia thePresenter.Interaction betweenViewandModeloftheP assive ViewMVPisdone exclusivelyviaPresenter[10].

C.Hierar chical-Model-View-Controller(HMVC)

TheHierarchical-Model-V iew-Controllerwasfirstintro- ducedin2000 asanClassic MVCadaptation forJav apro- gramming[11].This modeltakes intoaccountthe hierarchi- calnatureof Jav agraphicalinterf acecomponents:themain windowframecontainspanesthat containcomponents. The authorsproposeto createlayeredarchitecture forthescreen withClassicMVC triadsf oreach layercommunicatingwith eachotherby controllers.TheHMVC modelissho wnin

Figure3.

Therebythechild controllerinterceptsmethods fromits view.Ifaviewof theupperhierarch y(parentvie w)needsto bechanged,the childcomponentinforms theparentcontroller , whichmakes thechanges.Thecommunicationbetween layers ismadee xclusively viacontrollers.

D.Model-Vie w-ViewModel(MVVM)

presentationandb usiness logic.TheViewModelisalinking componentbetweenV iew andModel.Thisdesignpatternis mainlyusedin Microsoftsystems[12]. Therealizationof this modelis donewithbinding betweencomponents[13]. The bindingisnot supportedinAndroid bydefaul tbut couldbe im- plementedusingthe veryrecent Android-bindingframew ork.

Fig.3.Hierarchical-Model-V iew-Controller8Copyright (c) IARIA, 2013. ISBN: 978-1-61208-276-9PATTERNS 2013 : The FIfth International Conferences on Pervasive Patterns and Applications

Asstated in[14],agoodbasicmodel shouldnotuse any

additionalframew orkandshouldbeeasilyimplementedwith originalcomponents, thereforethismodel isnotdealt within thepaper.

III.ANDROIDAPPLICAT ION

DEVELOPMENTEXPERIENCE

Androidisa Linux-basedopensource operationsystem

designedformobile devices. Androidwas firstpresentedby Googlein2007 andinspite ofhugecompetition fromApple hasbeenthe leadingsmartphoneplatform since2010.Google continuestow orkonthe systemsystematicallyintegrating newfeaturesandcorrecting bugs.Manymanufacturers of smartphonesandtablets adoptedthisopen-source solution;the NationalSecurityAgenc yand NASAalsochooseAndroidfor theirprojects. Androidapplicationsare mainlywritten inJav ausingthe AndroidSDK[15]. Thecodeis compiledtobe executed on theDalvicvirtual machineona smartphone.Additionally, developerscanusetheNativ eDev elopmentKit(NDK) toadd aCor C++writtencode referredto asnativ e.NDKallo ws moreadv ancedfeaturesandbetterperformance,ho wever ,the complexityofthecode increaseswiththe quantityofnati ve code[16]- Googlesuggested minimizingtheuse ofthiskit.

FourprincipalcomponentsofAndroid SDKare usedin

AndroidApplicationde velopment:Acti vity,Service,Content providerandBroadcastreceiv er. Activityis amaincomponent ofAndroidapplications createdwhile theapplicationthat isalsothe entrypointto theapplicationis open.Many Activitiescanexistin theapplicationb utonlyoneisacti veat atime.The serviceworks onthebackground ofanapplication permittingane xecutionof longtasks(e.g.filedownload). Whentheapplication isclosed,unlik eActivity ,thew orkofthe Serviceisnot interrupted.TheContent providercomponent givesaccesstothelocaldata storedinSQLite databases. TheBroadcastrecei veris amessagingsystemthatenables communicationinsidethe applicationandbetween multiple

Androidapplicationsinstalled onthe phone.

Activitycausesmajordifficulties inimplementing the knownarchitecture:isita View,aController,aPresenteror noneofthem? Somedev eloperssayAndroid actuallyimposes theMVCmodel wherethelayout.xml (file,definingthe layout ofthescreen) isaView,Activity componentisaController andtherest isaModel.Thisproposition isnotreall ythe MVC:layout.xmlonly defineswhatthe screenlookslik e,but buttonactions,text informationandother presentationlogic areusuallyplac edin Activity.Therefore,Activity handles eventsasControllerandmanagesthe visualizationasView, replacingtheView-Controller.Itleads tothecreation ofa heavyandcomplexActi vityclass[17]. Hugeclassesthathave manyresponsibilities(event handler,presentation logic,etc.) violatetheSingle ResponsibilityPrincipleof ObjectOriented Programmingandcould behard tounderstand,test andextend [18].

Otherdev elopersplaceActivityasaViewofMVCcreating

Controllerapart.Thissolution worksfor simpleapplications whereoneActi vityrepresentsone visualblock,whileActivity usuallymanagesse veralViews:mainscreen, menu,dialogue box,etc.In complexvisual applicationsActivity becomes heavy;Viewcomponentsarestrongly linkedto eachother andarenot reusable.Controllerwillbeeither complexor dividedintopartsbya numberofembedded ActivityViews thatgoag ainsttheMVC statementofoneController,one View.ReplacingMVP ViewwithActivity cancausesimilar problems.

Somedev elopersobservedthatAndroidhavepredefined

ViewsasV iewFlipper. Itbringsanothersolutionwherethe Solutionseemsmore adaptableto Androidase ventinter - ceptioninActi vitycanbe definedinlayout.xmlbutactually createsproblemssimilar toprevious implementation:many arereusableb utthecorresponding Controllershouldalw ays beaddedto thene wActivity usingtheView.To deleteor modifytheViewdevelopershouldmodifythefullActivity .

Finalapplicationis complex andhardto maintain.

EvenifMVCandMVP architecturesseemsuitable for

Androiddev elopmentstheyarenotintuitiveto implement.A newarchitectureshouldbeeasily implementedwithAndroid- specificcomponents,such asActi vity.The implementationof themodelshould improv etheapplication andcodequality. Moreprecisely, themodelshouldreducethecomple xityof anapplication,clarify thecodeand improv eextensibility . Thecouplingbetween compone nts shouldbeweaktoavoid themodificationof othercomponentsif oneismodified. Modulesshouldbe reusable[14], [18].Amobile phonehasa limitedmemoryand agarbage collectorcouldha veune xpected behaviourthereforethecreationof unnecessaryobjectsshould beav oided.Finally,objectsremaininginthememory should belightweight[16].

IV.NOVELDESIGNPATTERNFOR

ANDROIDPLATFORM

Thefirstpart ofthesection explains thenov elarchitec- tureforAndroid applicationdev elopmentwe namedAndroid

PassiveMVC.Thesecondpartofthesectionpresents a

simpleexample implementingtheAndroidPassiv eMVC. Thethirdpart ofthesection recommendsan architectureof thebusiness logicoftheapplication-the Model.Android applicationshav esimilarneeds:internaldatabasemanagement andaccess,web serviceaccess andreusablecomponents use. Clearmainarc hitectureofb usinesslogiccouldalsosimplify thedev elopmentprocess.

A.Android PassiveMVCPresentation

Wehavedecided tobaseourarchitectureontheMVC

model,asMVC iswell-known andwidelyused indesktopand websystemsas wellasin iOSmobilede velopment.De velopers comingfromother systemswould beableto easilyappropriate theAndroid development architecture. Activityisaninevitable componentofthe Androidappli- cation.Previous experienceoftheAndroid communityshows Activitydoesnotfitwell ontheMVC model,whileit seems tobewell adaptedtode velopers'needs. Wedecided tocreate MVCmodelaround Activitymaking theActivity thefourth component.We canalsothinkofActivity asamain screen

(parent)controllerin HMVCmodel.9Copyright (c) IARIA, 2013. ISBN: 978-1-61208-276-9PATTERNS 2013 : The FIfth International Conferences on Pervasive Patterns and Applications

systemsb utonlyonescreenisacti veat atimei nAndroid application.Thispattern supposeskeeping inmemoryV iews andModelsthat appearhea vyforthe mobileenvironment, thereforewechose thePassi veModel MVCasa baseforour architecture. Inourmodel, Activitybecomes anintermediatecomponent betweentheV iews andtheControllers,therebyControllers taketheevent handlingresponsibilityand theViewstake thepresentationlogic makingtheActi vitylightweight.The schemeofthe AndroidP assive MVCmodelis showninFigure

4.Thegre ydashedarro wsshowtheinteraction viaAndroid

nativemethods.Blackarrowsindicate directcallsand grey arrowsrepresentlistenerev ents. TheActivity islikeascreen controller.The startingAc- tivitycreatesalinkbetween aV iewand acorresponding Controllertomak ethemcommunicate directly.Thecommu- nicationbetween Controllersismade viaActivity .

TheVie wsaretheinterfacecomponents,suchasa form,a

menuora listofelements. View componentscontainmethods thatallow thesettingorobtainingofdata fromtheuser interfaceonControllerdemand,the settingofe ventlisteners on visualcomponentsand themodificationof visualcomponents (seterrors,change colours,etc.).V iews areindependentand donotcommunicate. TheControllerhandles ev entsfromthe useraction(e.g. buttonclick),callsnecessarymethods fromtheModel and thennotifies theVie wtobe updatedonModelresponse. TheControllersare independentfrom oneanotherand donot communicatedirectly. Thissolutionmak esActi vitylightweightbymoving all eventhandlerstoControllersandinterface managementto Views.ViewsandControllers createdondemandavoidunnec- essaryobjects,sa vingmemory. Developerscaneasilymodify orremo veapplicationcomponentsbyonlymodifyingor deletingthecorresponding view-controllercouple. Application canbee xtendedwithvie w-controllercouples.TheModelis independentfromthe View ,theController andtheActivity. Theuserint erfacecould bereplacedwithoutanyimpacton Modeltherebythe maintainabilityofthe applicationishigh.

Weperformthecommunicationbetween Activity ,Con-

trollerandModel viamessagelisteners implementedvia interfacesasproposedby [19].Figure5 showsthe Android performanceofthe applicationandcreate aweakcoupling betweencomponentsthat improv emaintainability.

Fig.4.Android Passiv eMVC

Fig.5.Android Passiv eMVCimplementation

B.Android PassiveMVCImplementation

Thissectionpresents animplementatione xampleofcom- municationbetweenAndroid Passi veMVC components.This implementationissuitable forthene wmanuallycreated Ac- tivities.SomepredefinedActi vities,especiallyfrom third-party libraries,willpossibly notfit theimplementation.W ecreated aloginscreen withaclassic loginformto enterthelogin andpassword; iftheloginissuccessfulthe usergoesto the welcomepage,otherwise theerrormessage appears.

Theexample containstwoActivities:Login Activity

managingthelogin pageand Welcome Activityfor thewel- comepage.The logi nform ismanagedbyLoginViewand LoginController. LoginActivityimplementsthe LoginCon- trollerListenerinterface tobeabletoreceiv ecalls fromthe

LoginController. Theschemaisshownin Figure6.

LoginV iewcontainsmethodsforobtainingloginand

password(getters),methodstoset buttonlistener andmethods toseterrors. LoginControllerhandles event fromthelogin formimplementingthe onClickListener;whilethe buttonis pressedControllerlaunches simplev erificationsandca llsthe model.Iflogin issuccessful,the answergoesback tothe LoginActivity ,whichopensawelcomescreen.Tosimplify the examplewedonotinclude themodel, butthe communication betweentheController andtheModel canbeimplemented similarly.Afullcodee xamplecan befoundon [20].

C.Android DomainModel

TheModelof AndroidPassi veMVC isaDomain Modelcon-

tainingbusiness methods,webservicecallmethods,database accessobjects,reusable methodsand datamodelobjects.

ADomainModel architectureshouldinclude components

usuallyusedin Androidapplications,such asDatabaseman- ager,Webservicesmanager andBusinesslogic.Thosecom- ponentsshouldbe independent,asthe architectureshouldbe adaptable.Reusablecomponents shouldbe alsoseparated.The basicmodelarchitecture isshown inFigure7.

Fig.6.Login implementationexample 10Copyright (c) IARIA, 2013. ISBN: 978-1-61208-276-9PATTERNS 2013 : The FIfth International Conferences on Pervasive Patterns and Applications

Fig.7.Domain ModelArchitecture

Thearchitectureof DomainModelproposed inthis doc-

umentisinspired by3-tierarchitecture thatseparatesthe presentation,theb usinessand thedataaccesslayers[21]. Thebusiness layerofourmodelregroups objectsandmeth- odsthatuse webservices,b usinessservicesand reusabletools. Businessservices containbusiness logic.Ifan application worksviaInternetaswell aslocally, allnecessaryv erifications aredonein Businessservices,which callscorresponding methods.Thecomm unication betweenapresentationanda domainmodel layeraremade viaBusinessservices.

Thedatalayer containsModels,Data AccessObjects

(DAO)andDatabaseManager.DA Oand Modelarethe implementationofthe DataAccessObject pattern.Model containsdatabeing persistedin thedatabaseor retrieved by webservicescalls. Modelisa simplePlain OldJav aObject (POJO)thatcontains onlyvariables andtheirgetter andsetter methods.Datais manipulatedandtransferred throughthe applicationusingthose lightweightobjects thatareoften called

DataTransfer Object(DTO).

Persistencemethodsare organized inDA Os.DAOcontains methodsthatenable thedatain adatabaseto besav ed,deleted, updatedandretrie ved.Ev enifAndroidproposesanabstraction onthedata accesslev elwithCont entProvider ,DAOsimplifies thecodeof theapplication.The DAO designpatterncreates aweakcoupling betweencomponentsand usealightweight

Modelobjectinstead ofan Androidcursorobject inthe

application.DA Ocanalsobeusedforthedatastored inXML ortext files.Goodpracticeistomak eDA Oaccessiblevia interfaces.ItallowsD AOmodification (forexamplethechangequotesdbs_dbs20.pdfusesText_26

[PDF] Android Passive MVC: a Novel Architecture Model for Android