Activities and Fragments are not MVx Views
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 90 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/47665 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
2
10
13
14
26
35
37
45
48
54
55
56
63
64
68
73
74
77
78
80
82
85
89
00:00
View (database)Group actionOffice suite
00:33
View (database)Endliche ModelltheorieView (database)Online helpComputer animation
01:08
View (database)Slide ruleProgram slicingCollisionComputer animation
01:41
View (database)Line (geometry)CodeCartesian coordinate systemCodeComplete metric spaceSlide ruleSoftware developerLine (geometry)Bridging (networking)Android (robot)Point (geometry)Content (media)Block (periodic table)Computer architectureLogicWebsiteQuicksortRight angleComputer animation
03:13
View (database)Web pageGraphical user interfaceFlow separationData structureLogicInterface (computing)StatisticsControl flowAndroid (robot)Goodness of fitSanitary sewerLatent heatView (database)Cartesian coordinate systemLogicFamilyPattern languageSound effectComputer architectureProjective planeOnline helpData structureUser interfaceGoogolWebsitePoint (geometry)Endliche ModelltheorieImplementationSystem callState of matterBroadcasting (networking)MathematicsDifferent (Kate Ryan album)Content (media)Block (periodic table)Order (biology)Object (grammar)Game controllerOracleWeb pageMereologyBuildingConnectivity (graph theory)RoboticsBlogLevel (video gaming)Kernel (computing)Android (robot)DataflowLibrary (computing)Flow separationSoftware framework2 (number)Multiplication signGraphical user interfaceRepresentation (politics)ResultantSoftware developer
07:25
View (database)Software developerAndroid (robot)BlogLogicGame controllerForcing (mathematics)AreaDifferent (Kate Ryan album)ResultantState of matterImplementationPresentation of a groupBlock (periodic table)Flow separationSpherical capAverageMultiplication signSeries (mathematics)Android (robot)DataflowSingle-precision floating-point formatDescriptive statisticsEndliche Modelltheorie
09:20
View (database)Hardware-in-the-loop simulationView (database)BlogGame controller10 (number)Perspective (visual)Computer architectureCartesian coordinate systemEndliche ModelltheorieRow (database)MereologySpeech synthesis
10:32
Pattern languageView (database)LogicPointer (computer programming)Bit ratePersonal digital assistantLimit (category theory)Encapsulation (object-oriented programming)Projective planeLogicSoftware testingMultiplication signCartesian coordinate systemReverse engineeringElement (mathematics)Arithmetic meanoutputUnit testingForm (programming)Latent heatProbability density functionBit rateMereologyGraph coloringPosition operatorCharacteristic polynomialMathematical optimizationView (database)Endliche ModelltheorieTouchscreenImplementationInteractive televisionWritingMathematicsCodeShape (magazine)Software developerEvent horizonScaling (geometry)Interface (computing)Process (computing)Covering spaceExecution unitSocial classPattern languageDeclarative programmingCASE <Informatik>Game controllerInterpreter (computing)Connectivity (graph theory)Right angleSlide ruleSurfaceForcing (mathematics)Hand fanVideo gameStress (mechanics)Different (Kate Ryan album)TelecommunicationMetropolitan area networkProper mapPentagonStaff (military)BitShooting methodComa BerenicesText editorGreen's functionGroup actionField (computer science)
20:11
Video gameView (database)BootingInjektivitätProcess (computing)Arithmetic meanInjektivitätException handlingINTEGRALTouchscreenWeb 2.0Order (biology)LogicVideo gameRun time (program lifecycle phase)GodCycle (graph theory)BootingConstructor (object-oriented programming)Social classAnalytic setLibrary (computing)
21:27
Object (grammar)View (database)LogicLine (geometry)Video gameLogicPosition operatorInheritance (object-oriented programming)Process (computing)Beat (acoustics)File formatDependent and independent variablesConnectivity (graph theory)Physical systemCycle (graph theory)Object (grammar)PlastikkarteSoftware frameworkGame controllerOrder (biology)Projective planeMassSoftware developerUser interfaceSocial classInterface (computing)Execution unitFraction (mathematics)View (database)Presentation of a groupCartesian coordinate systemRight angleCASE <Informatik>TheoryGoodness of fitRow (database)Keyboard shortcutAndroid (robot)Disk read-and-write headBitNichtlineares GleichungssystemUnit testingInstance (computer science)Java appletImplementationSound effectCodeGodNumberRule of inferenceEndliche ModelltheorieDataflow
27:17
View (database)LogicUsabilityElectronic mailing listHierarchyEntire functionData modelDifferent (Kate Ryan album)CodeAndroid (robot)ArchitectureOvalView (database)Data managementProduct (business)Game controllerTelecommunicationLogicProjective planeSocial classCombinational logicInterface (computing)State observerJames Waddell Alexander IIText editorCASE <Informatik>Cartesian coordinate systemRight angleLevel (video gaming)Software developerAbstractionUniqueness quantificationRootMereologyField (computer science)Event horizonScaling (geometry)Group actionSlide ruleImplementationForcing (mathematics)EstimatorOrder of magnitudeMetric systemClique problemCore dumpBoilerplate (text)Computer architectureConnectivity (graph theory)TorusLeakWiki19 (number)Multiplication signCausalityElement (mathematics)Data structureNatural numberRoundness (object)BlogDemosceneCycle (graph theory)Sound effectSoftware frameworkUsabilitySystem callOrder (biology)Presentation of a groupComplex (psychology)Key (cryptography)Electronic mailing listPattern languageValidity (statistics)CodeResultantLine (geometry)GoogolEndliche ModelltheorieForm (programming)Keyboard shortcutClient (computing)Android (robot)Execution unitContent (media)HierarchyFunction (mathematics)output
36:11
View (database)LogicGame controllerPresentation of a groupImplementationView (database)Android (robot)Software design patternAlphabet (computer science)Reading (process)Slide ruleSoftware developerPresentation of a groupGodLogicEndliche ModelltheorieProcess (computing)Natural numberGoogolPrice indexLevel (video gaming)BlogSocial classFlow separationGoodness of fitFamilySystem callInjektivitätMetre40 (number)Product (business)Right angleCASE <Informatik>
38:24
Execution unitAndroid (robot)InjektivitätView (database)InjektivitätMultiplication signUnit testingCodeNetwork topology
Transcript: English(auto-generated)
00:00
and do something silly okay so you can dance okay like this and that's it okay so you're embarrassed yourself and nothing I do from now on can be more embarrassing than what I did right now so I'm free to talk about serious stuff now okay I'm ready we still have two minutes so maybe you could
00:29
two minutes for a better purpose okay you've already met Vasily and he will be
00:46
talking about extracting the UI from activity in the model view X approach all right thank you for the introduction and I'm very honored to be here as a
01:08
biggest audience I had to date so excuse me if I'm a bit nervous and also I have I hope my slides will come up is there any issue about with the slides it was
01:26
only like a minute before yeah I'm sorry I have some technical issue
01:51
nobody bridges okay so I came here to actually do try and convince you to extract all of your UI logic outside of activities and fragments but to do that
02:06
I would like to tell you first about my own experience as an Android developer good so when I decided to become under a developer I bought a book okay I will
02:24
need to stand here that taught me basically what professional software developer needs to know and then I read the lots of the official documentation and also our community is great at producing high quality block content so I read all that and therefore after several months I looked
02:46
at complete spaghetti code okay so my fragments and my activities were like 500 plus lines of code line long and some of them got to 1,000 already and at the point where my first fragment got 1,000 slides of code I thought well
03:06
that there must be a better way no way that's the best I can get so I went on and Google for Android application architecture that's what I found so we have Linux kernel and then have native libraries and then have
03:26
application frameworks and on top seats your application yeah great really helpful alright so first page of Google results wasn't that helpful for me so I kept looking for more content and luckily I found some
03:45
however before I tell you what I did find them we need to talk about and architectural patterns so what do I mean when I say MVX well MVX is a family of architectural patterns for GUI based frameworks several things to
04:04
note here first of all it's a family so we will be speaking about several different architectural patterns which nonetheless have something in common second it's architectural pattern it's not an architecture architecture is application specific you can usually you can to use your architecture however
04:25
architectural patterns are higher level patterns that you can use in different applications and the last part is GUI so you need to have user interface in order to use one of the MVX patterns and the main building blocks of any MVX pattern are basically model so model contains states or
04:46
business logic or data structures yeah it's not really defined very well and we have Vue which contains user interface and we have X which contains flow control logic or business logic or state or data
05:05
structures it is very important that you note at this point that Vue is the only part that all implementations of different MVX patterns agree upon we all agree that your UI logic should reside inside Vue component however if
05:23
you take different MVX representatives they will not agree about what model is and what X is and X will also have different names keep that in mind for now. Okay so when I wanted to find a better way to organize my
05:44
application I went and searched Google for a very long time and unfortunately I found this blog which called mind the robot and it was called by a guy named Ivan now he works for Oracle if I'm not mistaken and Ivan basically
06:03
proposed this approach he said alright let's separate our applications into three components model Vue in controller and that's not something new alright this MVC pattern has been around for years and let's make Vue component activity
06:22
this activity is the Vue and if you actually go and read that blog post you will call MVP today so what Ivan called MVC we call MVP today slight change in
06:40
implementation details but it's the same exact pattern but what is surprising about this blog post that I found is that it's I don't know if you can see but it's from 2010 so some developers think that all this MVX stuff began in Android like three or four years ago but actually it began much
07:02
earlier than that and I'm not even sure that Ivan was the first one to start discussing this MVX architectures on Android so it's very old concept and the community members were working on MVX long before let's say official guidelines caught up with this effort. Alright who does MVP today?
07:28
Raise your hand okay great and I use this approach that Ivan advocated for for a short time and it was a tremendous improvement like all of you
07:42
probably know who use MVP you can have your UI logic outside you have your controller or your presenter which contains your flow control and business logic and your model which contains either business logic or state very good and it's much better than what you have like officially
08:02
recommended guidelines were back at the time however it wasn't good enough for me still it felt clumsy so I kept searching and then I found this series of posts by someone named Joshua muscle weasel and I'm probably doing
08:22
some disservice to his last name by mispronouncing it but let's go let's keep it that way so Josh wrote a series of blog posts just found he based his blog post on the one that we saw earlier by Ivan from 2010 so he found Ivan's work and kind of built on top of that and expanded his one single
08:44
blog post into a series of nine different blog posts so that was very very detailed description of MVC implementation on Android and after several months of working with this approach he basically wrote 10th post
09:02
and this post was activity revisited so what Josh found out working with this approach is that there is something about activity which was not optimal with the standard MVC that he used before and I will not even I will not
09:25
overestimate the impact of what Josh found out because I do think that this realization of his is probably the biggest breakthrough in architectural and design thinking for developing of Android applications so what just said
09:45
is that we have a model view in controller and the view is the activity for now however if you switch if you change your mind and you look at it from a different perspective then it makes much more sense to have activity
10:03
as the controller so that's what Josh found out that what his 10th blog post was about he said okay I use this MVC for a while and I don't find it good enough but if I switch roles or if I switch the role of the activity and make
10:21
the activity controller then I can work in it and it all checks out much better okay and to understand why it all check out checks out much better if you use activity as a controller in this pattern we need to discuss what
10:42
really the advantage of any MVC okay who uses any kind of MVC MVC MVI MVM well that will be probably around 50% of the audience or maybe even more so what's the best and what's the best advantage of any MVC it's not a
11:01
question I asked you anyway shout that's the first answer that I always get testing however I do not agree with that completely please raise your hand if you use MVC and also do unit testing any MVC and also do unit testing well that's
11:25
that's a lot of hands very good but it's still less than 50% of you had before so some of you use MVC and don't do unit testing are you wasting your time I don't think so I think that testing is a byproduct it's an
11:40
advantage of MVX however it is derived from another advantage which is much bigger than than easier unit testing and what I find to be the best advantage of any MVX is the coupling of the UI logic and to do to explain
12:00
why I think is the best advantage of any MVX I need to actually define what UI logic means so for me UI logic is the logic that actually draws the UI of the application so that's the logic which is responsible for the layout of the elements that the user sees and can interact with on the screen and also
12:24
captures user inputs and propagates them into the application so UI logic does not handle user input but it is responsible for capturing the user input and propagating it inside your application where it will be handled by
12:41
other kinds of logic so that's what I mean by UI logic and if we go back to one of the first slides when we saw the definition of model view X something recall that view is really the only component that all implementations of
13:00
MVX agree upon so you can have very different interpretations of what model means and you can have vastly different interpretations of what X stands for however all implementations agree that view should contain this UI logic should encapsulate and hide the details of UI logic from the rest of
13:23
the application therefore I can even say that once you extract UI logic inside your application into a standalone component you decouple your UI logic from the rest of the application you already fall into some MVX you can always find M and you can always find X whenever you have your UI
13:43
logic decoupled and that's really the best advantage of any MVX approach if you can achieve that then the MVX will be beneficial for you why why is that why your logic should be decoupled why not other logic maybe it's
14:02
the model that is biggest advantage to decouple no I think it's UI logic and it is related to the fact that UI logic has very different characteristic from the rest of the applications logic first of all your logic has the best requirements in the project on most projects you have
14:25
very partial requirements for the application depending on the scale of the project depending on the tools that you use depending on the process that you use and you will have from zero documentation to let's say 50%
14:40
documentation for the rest of the application however UI logic will probably always be defined very precisely because you cannot implement it otherwise so you will always have this UI mock-ups that designers produce that you build your application upon second usually UI logic will have much
15:00
higher rate of change so sometimes I worked on a project on the greenfield projects that had two or even three interactions over UI a different UI even before the first user interacted with the application and it's not going it's not slowing down when the project becomes more mature because when the
15:21
project becomes mature companies usually want to do AB testing and they usually want to do some kind of maybe rebranding and stuff and optimize for example positions colors and cetera of UI elements UI logic is very unreadable okay it's verbose it's hacky it's messy it's a pile of poo you
15:42
can think about it a different way from all other kinds of logic you will usually be able to reverse engineer the requirements so you read the definition so you read yeah the declaration of some class and you can if it was written properly you will usually be able to infer what this class does however if I give you a bunch of UI logic even if it's written
16:06
very cleanly you will not be able to reverse engineer the layout of the UI and tools like layout inspector and and automatic stuff can help however they do
16:20
not capture all the details of the UI like animations and stuff so UI logic is unreadable it's kind of one-way street you write UI logic based on the requirements but you will not be able to reverse engineer the requirements in most cases and UI logic is the easiest to test manually because you just put your application up and you can interact with the screen and you can
16:43
ensure that your logic behaves according to the specification and it's hardest to test automatically okay so it will be very hard to really cover UI logic with tests and I'm not talking about espresso espresso is kind of low hanging fruit you can ensure that for example you have this button on the screen and
17:04
the user clicks the button the the event that user clicked button is being passed into the application but just try to imagine how would you write espresso test so for example verify the colors the shapes the relative positions of the elements on the screen the animations how the animation how animations look
17:24
the duration of the animations all of this stuff is usually best left for the human eye for the manual testing so these are the characteristics of UI logic that are really different from the rest of the application therefore usually usually UI logic
17:42
is the best candidate for being decoupled from the rest of the application and if you have it coupled to some other part then you will usually have a mess on your hands okay say that why not encapsulate and decouple UI logic while while it resides inside activity
18:07
I will try to explain the problem with a specific example let's say that you have your UI requirements in the form of InVision or maybe Zeppelin or PDF whatever and you want it
18:21
to be decoupled and by definition decoupled means that your logic that some something that is decoupled can be developed completely independently of the rest of the application that's what decoupled means if you can develop it independently it's decoupled if you need to know about other stuff there is coupling so if you combine those two things your UI logic
18:44
basically the UI of your application becomes the first candidate for being outsourced if you need to for example you might run late on a project and you want to get some help in or you or have a hard time hiring where you when you're located so you would like to have some offshore developers help you with your project so you will combine these two things and give that to
19:08
some freelancer and the freelancer will do a good job and produce for you this my activity class which encapsulate the UI that you wanted to have and you can even assume that you gave the freelancer this interface my view in vc so the freelancer actually implemented what you
19:25
wanted to and assume that he did an outstanding job that's the best developer on the planet you know you get a clean code you get detailed requirements everything is very good so the question now is would you take this activity as it is now and simply integrate it into your
19:42
project who will do that right who will not do that who is afraid to raise his hand okay so yes most of us feel a bit uncomfortable about that right so we take activity from
20:03
someone just drop it inside your project and it has all the UI however there's something more to it and the whole picture is much more complicated than that because activity except for having UI logic in it will also integrate with the life cycle and freelancer
20:22
has no means to know about all these things that you want to do in your own start for example you might want to have your analytics setup or something else okay activity will be integrated with other activities so screens are interdependent and if you want to implement some kind of navigation then it will be usually handled inside activity runtime permissions for some
20:47
mysterious reason they are coupled to activity as well loaders integration with the loaders fragments yep coupled to activity nice dependency injection activity do not have activities
21:00
do not have the constructor available therefore you will usually use some kind of dependency injection library inside activities freelancer doesn't have any mean to know about your dependency injection setup and much more stuff so usually we have much more stuff in our activities than just UI logic and activities are God classes okay so this concept of God object that does
21:34
too much and knows too much about the system that's what activity is activity is public API contains more than 100 methods and the immediate implication of that is that if you put UI logic
21:51
inside your activity even if you do that very carefully and even if you delegate all other responsibilities to other objects it will be coupled to other responsibilities it will not
22:03
be fully decoupled and that's really hard to change a mind and see it like that however if you iterate over this idea a bit in your head it will eventually sound very natural because we
22:23
do feel we do know that with from our everyday development experience however we are very accustomed to think about activity as UI container however once you start thinking about the other responsibilities that activity has you will very quickly arrive to this conclusion that
22:40
activity knows too much and does too much all right so we're not very not very positive thing to say right we are writing our applications and we put our logic into God classes and we can't even work around that because we need to use activities so the question now
23:01
can we do better than that and the answer is yes luckily we can actually extract all the UI logic from the activity and make it truly decoupled from the rest of the activities responsibilities and it's actually not that hard so that's that's what we start with we
23:27
have our activity that implements this interface and UI logic resides inside that's what we you probably have if you use MVP approach first of all activity will not implement this interface anymore there will be another standalone class completely new Java class that will
23:48
implement this interface then we take all the UI logic and simply move it to this new standalone class and then we can make activity instead of implementing this interface
24:02
we can make it depend on this interface and contain an instance of this class and reference and delegate all the UI responsibilities to it and once we do that once we extract all the UI logic from the activity we will clearly see that activity is the controller or x whatever you
24:23
want to call it so what what's the common denominator between all activities between hello world project and the most complex project you you've been working on like what are the responsibilities that will be common to both of them that's not a return equation either so what
24:45
is the responsibility that is common to all activities the simplest project okay I I don't agree with that flight of fashion but it's close it's close no no no on create right even
25:04
this is the most simplest hello world we'll have on create in order to bind not inflate but to bind some layout to the activity so all activities will need to handle lifecycle however simple they are or however complex they are and if you think about that lifecycle is not
25:23
related to user interface lifecycle is a feature of the framework that controls the is basically flow control of the system to manage different components and if you take your UI logic outside of your activity you will clearly see that activities responsibility the main activities
25:43
responsibility is really to handle the lifecycle and this concept is not new okay so joshua blocking his effective java rule number 16 if i'm not mistaken so that's what he said favor composition over inheritance if you put your UI logic inside activity and implement this
26:02
view MVC interface you basically do inheritance if you extract it out and then depend on this interface you do composition so this concept of extraction and into standalone classes is really nothing new and some of you who do unit testing probably already think that something
26:23
here is problematic right because we want all presenters or controllers or x we want them to be independent of the activity in order to unit test them and the thing is that when i talk to people i think there's some misconception model view x or whatever you call it does not
26:43
prescribe to have one single class for each component these are not classes these are components so there is really no problem with making your controller composite as well so you can always extract this extra class to make your code more testable and unfortunately you
27:03
will need to do so okay so that's the general approach that i've been using probably around since i get got into android development on many projects and it works very well and i would just to show you how it works on the API level you will have this kind of my view MVC interface
27:27
and it will have this bind products okay so that's you bind some data structure to this view and the external clients do not know what this class will do with these data structures the the details of how the view will render these data structures are completely obscured
27:47
and on the other hand it has this listener interface and register and unregister lesson so it's observable and the activity will implement this interface and register itself with this view mvx if you want to get notified about this event on by clicked so this view clearly
28:04
has some kind of a button and when the user clicks on this button he wants to buy what he wants to buy well probably this same product and even though this method is called clicked there's nothing that enforces that we were talking about click or a button it can very well be some
28:22
kind of slide sliding action inside the view it's all it's all implementation details what controller wants to know about is what are the inputs of this view and what are the output events and if you know that this view extends this simple view and vc interface and this simple
28:43
view on the interface is really the one that you will be using inside set content view method inside your activities so it's not mandatory that activity actually inflates the view what's mandatory is that activity somehow gets the root of the view hierarchy and that's this method
29:02
get root view who attended the talk of harness and the cost i think on mvi yesterday i think it was okay so mvi is very interesting concept but when i've watched the talk the thing that most was most
29:21
interesting to me is this simple helper class that they extracted which they called if i'm not kind of extracted it to make it unit testable and stuff i did not really realize understand why however if you see see this presentation now you will clearly understand that they are
29:44
on the path to this approach if they will continue to iterate over that approach they will come to this realization that they need this level of abstraction which is basically encapsulate all the ui related details okay so what are the advantages because let's be pragmatic i don't want
30:05
to write any code at all if i don't have clear advantages for me okay so first of all that's your way to actually decoupling the ui you can take this ui and you can outsource easy development and outsourcing is just one simple example right because
30:25
if it can be outsourced easily it means that for example new team member can be ramped up on the same code more rapidly so you onboard new developer and you can tell him well you know what you have this very complex application very huge business logic and we have zero
30:42
documentation because we do agile and we don't need documentation at all but you know what we have these view classes and we have project product manager and designers produce those requirements in form of a mock-ups so please go and implement some requirements and this way you can onboard new developers on very complex projects in almost no time you will not be able to use
31:08
the logic that you put inside activity activities activities are not composable you cannot have one activity inside another activity however you can easily have one view inside another view and you can in the view that you use in one activity you can use in another
31:24
activity or in fragment or as we will see later just now inside your list view okay who coded android before view holder who remember who remembers when view holder was introduced well pretty much okay cool so just a short history we used to use
31:44
list views just as is and on each binding of a new view erky to an element we were actually searching for all the child views inside this element but then we discovered that it is not efficient enough so we had to introduce this view holder hack okay let's call it what it is
32:04
it's a hack in order to avoid searching for entire view erky at each time we need to rebind the data to some element however you do not need to do that if initially you would write all ui inside view nvcs or view nv access because that they already contain all the view york and
32:27
you can reuse them okay so our usability is that and surely no one uses this view anymore we all view we all use recycles view but and you got this hack of view holder built into this
32:42
api so you cannot get rid of it anymore unfortunately but you can make the implementation of recycles you more natural and cleaner so you can still use you know view nvcs for each individual element inside the recycler view and what it gives you is the same level of
33:01
abstraction on all stages of your application so you have your vc for your entire ui and you have your vc for each individual component and you will have your vcs for each individual um component inside your list view or recycler view
33:21
and of course i need to tell you what the costs of this approach are so it's different mental model as i told you it's different to switch gears and look at activity as a controller and not as a ui component and it requires initial mpop and it will end up being more code and for some reason in android the working community we are concerned and even i would say
33:46
very concerned about removing boilerplate and reducing the amount of code that we need to write and i'm surprised by that because industry as a large kind of rejected lines of code as any
34:02
kind of valid metric for performance for effort for cost for anything basically except for magnitude estimation of the project and even on the big scale it doesn't matter if you have 100 000 lines of code or 90 000 lines of code on these scales 10 000 lines of code do not
34:23
matter what matters is that you have good abstractions and you have maintainable application that you can deal with specific decoupled parts of your application when you need to that you don't need to deal with all the complexity of your projects and it requires discipline i thought several times about extracting all of this into some kind of a framework but i don't believe
34:45
that another framework of on top of android is the way to go we just need to learn and to have discipline okay and you know the elephant in the room i throw another mvx on you okay so now you have 10 different implementations and another one and this month we will use vasilis mves
35:05
and we see mvx whatever he calls it right and yes honestly in some way i do and we do have very many mvx implementations already and that's another one for you to consider however what i will tell you is that it dates back to 2010 when ivan wrote his initial blog post and it
35:27
was augmented by josh with his breakthrough in 2012 and then i added this viewing vc abstraction in 2014 so it's the most major the most time tested and the most battle tested um architectural pattern for developing on android applications today
35:47
and it didn't stop there okay so this guy netin he kind of reiterated my ideas and wrote this blog post so if you go and look for android mvp that will be one of your first results search results in google and basically that's the same approach and you will say well what mvc
36:05
mvp mvx how do you call that give it a name no i don't want to give it a name i think that all these names are genuinely bad and it doesn't matter how you call that what i find is that sometimes people will talk about mvp and will actually talk about two different implementations
36:26
or they will uh argue heatedly about mvp is better than mvvm or something and then you write it down and then you will discover that they actually talked about the same thing so nothing of this is defined and it goes back to the one of the first slides that neither model
36:43
nor x are defined so you can always have your mv and there are some letters of alphabet that are free for you to use or you can use two letters so we already seen mvpc and mvcvm you can also augment that with something else and really i kind of quit this
37:06
bike shading i prefer to just call it mvx at this stage okay so to summarize extracting your logic is the only way to make it really decoupled and this mvx view is the natural abstraction for android and if you think about this the
37:24
fact that it would allow to to prevent this view holder design pattern from being introduced in the first place is kind of a good indication that it's natural that it's the way to go okay and activity can take on its natural role and its nature and documented okay so you have
37:44
posts from 2010 probably about 15 posts and several reference implementations from me and from other bloggers that you can look at okay what about fragments we talked about activity so we need another 40 minutes for fragments or you can just go to this presentation replace
38:05
activity with fragment reread it and make total sense okay so when fragments were introduced google actually made a good job of making the fragments as similar as possible to activities so fragments also good god classes also has also have hundreds of metal public methods and everything
38:21
applies to them so and now shameless plug i started to produce android development courses on udemy so if you are interested in the professional unit testing or dependency injection you can use this code and questions do i have time yes we do yes i do thank you yeah i do have
38:46
time