Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I honestly cannot get my head around all this MVP and similar stuff with respect to Android: What is its real point?
Up until now the only practical reason I see to use MVP in Android is to 'extract' unit-testable pieces of code from framework classes (i.e. Activities, Services, Fragments...) which would otherwise be difficult (or impossible) to test.
This is nice but this way Activities (and other framework classes) end up delegating work to the presenter when possible (i.e. when dealing with framework agnostic code) and doing work directly when not. Because of this Presenters end up looking somehow bizarre by having methods which mirror the Activity lifecycle ones (onStart, onResume, clickListeners...). I wonder if this is a code smell?
On top of this I see a ton of libraries/patterns to build MVP Android apps but I honestly don't see their real benefit: what is the downside of having each Activity creating and managing its own presenter manually?
I see no benefit in decoupling the Activity and the Presenter from each other, since the presenter is merely the 'extraction' of some code from the Activity it will be tightly coupled to it by definition and this sounds to me fine as long as the presenter contains only strictly presentation logic (the rest of the business logic shall go into dedicated classes which don't know anything about the View/Presenter duo).
I'm feeling a bit lost in this topic and I'd like some other opinions on the matter to gain a greater perspective.
From long term perspective your code should be feasible and easily maintainable, No one want to spend extra time to refactor code.No, when we starting our project we should thing about proper patterns to do.
Talking about MVP it provides you the presenter layer which can be easily testable and there is no view reference so you can easily perform junit test cases otherwise you have to use other UI test cases.
you can reuse same presenter anywhere you want as it contains only business logic
so, my suggestion you should go ahead with MVP if you don't wanna face future code problem
Yes, sure, you can make you presentation logic framework-agnostic for testing, but MVP also helps to change the behaviour at runtime by changing presenters. View interface should have bit more abstract methods (not 'hide button X', describing , say, displaying a set of data). By decoupling the UI logic from the framework-dependent implementation, we can use different Views for changing UI, or Presenter for changing logic at runtime. View - Presenter is also a 'shim', which makes it harder to write 'spaghetti' code
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I'm trying to implement the MVP pattern in my app.
However There are some tasks I'm not sure how to do the right way.
Most of the examples only cover base and simple tasks where every interactor does only one task (e.g. fetch user list) - But, how should we implement it if the tasks are more complex
How should we treat those tasks:
A complex data task, for example which involve 3 api calls - fetch users + fetch user likes + fetch user followers. Should it be done in a single interactor, or divided into 3 interactors?
A task where a data needs to be stored somewhere, before moving from the presenter to its interactor.
For example, A complex registration process - The user enters user name and address and press continue. After that there is a series of X popups where the user fills more data. Eventually - the user presses registration, and the presenter triggers its interactor.
Now, where this registration data should be saved through the whole process until making the registration call? In the presenter? In the presenter's dedicated class? In the.. Interactor??
Last thought - In all the examples I saw, the interactor has 1 to 1 relationship with its presenter.
If a login presenter uses a login interactor to make a...login ofc. What happens if I need to make another login call in some other screen (I know its not common, but just to understand the main idea) - Then we will have another interactor doing the same thing as the previous.
Should interactor has 1 to many relationship then?
I'll be glad to hear your opinions
Thanks!
Answers to your questions:
I recommend having a separate API layer to handle your background tasks. I recommend exposing each API call through RxJava, and ensuring that only the Presenter has access to the API. RxJava would do the heavy lifting of allowing you to combine the requests together in your application layer / presenters.
Square recently did a talk on this and there solution. You can find a link to it here. Bottom line, it's not an easy problem to solve. If you are looking for a simple solution, my team and I created a concept called preferences. Each Preference represents a single piece of data that's stored in memory or persisted to disk using shared preferences. Here is an example of a library we used to do this. This library uses RxJava1, and we upgraded it privately to RxJava2, but you can get the point. Each piece of data is a dependency that we use Dependency Injection to pass between presenters / screens to get it where we need it.
Can't answer this one. My team doesn't use Interactors. We use a separated API layer as I described in #1, and RxJava allows all of those calls to be extremely flexible and re-usable. You will drive yourself crazy if you are dogmatic about everything you read in blogs. A lot of the things I've read in blogs just aren't practical in principal. I recommend using common sense, and finding what works for your team.
Here is a short sell on MVI (Model View Intent). I highly recommend it:
My team recently tried adopting MVP about a year ago. It didn't take long for us to realize some shortcomings, and have issues similar to you. After some searching we moved to Model-View-Intent (MVI). It's very similar to MVP, but with a few key differences that make the code far more manageable and easier to standardize the code between developers, making it easier jump into other peoples code.
A few key differences: The View doesn't talk to the Presenter, instead the View emits events that the Presenter subscribes to, called Intents. The Presenter also talks to the View via strong View Model. If you draw it out, it ends up functioning very similarly to MVVM. You end up with a flow that looks like this:
The Presenter subscribes to the View events / intents.
The View emits events.
The Presenter receives the events, reacts, and updates the model.
The Model being updated triggers an update to the View
Round and round it goes. (It ends up being a very circular loop of events if you draw it out)
Hannes Dorfmann has a few blog posts on MVI that I recommend. He provides some pretty complex examples. My team uses Kotlin, and that helps with this a LOT. We don't follow everything Hannes does, but we learned a lot from his blog posts / examples, and distilled into something that works REALLY well for our team.
http://hannesdorfmann.com/android/model-view-intent
http://hannesdorfmann.com/android/mosby3-mvi-1
http://hannesdorfmann.com/android/mosby3-mvi-2
http://hannesdorfmann.com/android/mosby3-mvi-3
http://hannesdorfmann.com/android/mosby3-mvi-4
http://hannesdorfmann.com/android/mosby3-mvi-5
http://hannesdorfmann.com/android/mosby3-mvi-6
#dor506
I had this confusions before I started working with MVP architecture
I had to follow lots of article, blogs and sample projects .above them this repo was my blueprint of learning MVP
follow this repo hope you will be pro on developing android app with MVP architecture
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am planning on implementing the MVVM architectural design pattern for my android app. I have read online that it will help me achieve efficient separation of concerns and easily write test cases for Data model, UI, etc. Need some insight/advice for this.
Well, to learn how effectively use MVVM, begin with Android MVVM Design Pattern Examples
Here you would find that post:
I am the developer of Android-Binding. Like #Brentley said, it's
a very new project but I do hope to get more buzz and experience so
that it can be improved. Back to your question, I have written some
simple introduction/tutorials on MVVM with android-binding:
Android MVVM Tutorials (with android binding)
Introduction to Android Binding (codeproject)
Model Validation in Android Binding (codeproject)
Wiki in project homepage
Potential adopters please also register on the project discussion
group.
Read whole topic. You would notice that MVVM is relatively new framework and it's highly recommended to work with it cooperatively with Google's pData Binding library and dependency injection library like Roboguice or Dagger2...
...but the best would be this one:
Approaching Android with MVVM. Building an MVVM architectured application using the Data Binding Library,
where an author is explaining using MVVM with Data Binding library by example - I mean by his own created app. He concludes:
It’s still too early to know if this approach is the correct way of developing an application, but this experiment has given me a chance to look at one of the possibilities for future projects. It’s something I definitely want to play around with more.
Model-View-ViewModel is interesting because in traditional Android architecture, the controller would push data to the view. You would find the view in your Activity, then set content on it.
With MVVM, your ViewModel alters some content and notifies the binding data framework about changed content. The framework do then automatically update any views, which are bound to that content.
The two components are only loosely coupled through that interface of data and commands.
Next aproach of using MVVM is really testable. From MVVM on Android: What You Need to Know
Because a ViewModel does not depend on the View anymore, you can test a ViewModel without a View even existing. With proper dependency injection for other dependencies, it is very straightforward to test.
For example, instead of binding a VM to a real view, one might create a VM in a test case, give it some data, then call actions on it, to make sure the data is transformed properly. (...) All of this can be done without having to interact with an actual View.
Read also: MVVM ON ANDROID USING THE DATA BINDING LIBRARY
Hope it help
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I have just started with the android development and I am trying to develop my first application, which I am actually going to publish. I have a programming background in Java and knowledge of some patterns however I have no idea which patterns I should stick with while developing android apps. Also where to put Threads. I am developing an app, which constantly loads data from a remote database through PHP scripts and displays them on UI. I divided an app to few layers - Presentation layer, Domain Layer/Service Layer and Data Source Layer. Between them I create facades to access the services of the layer bellow. I dont really know if I should stick with this structure or completely rebuild this app according to some other patters. Its better to find it out at the beginning of the development than to be forced to rebuild entire application later on. So if somebody could provide me with some links about architectural patterns which I can use or write something short about it here, I would really appreciate it!
In my opinion the single responsibility principle and separating whole application into different layers (such as MVC pattern but Android is not fully compatible with formal MVC) is a good practice in Android development.Now I will talk about major layers in the following:
Representation layer :
For instance Android framework offers a very straightforward XML representation for Presentation layer,In regard to this XML representation, you should not create the user interface stuff in code. Instead, you must do it by XML.
Application Logic layer:
For application logic layer it is good to accomplish it in code, not anywhere else, For example there is a android:onclick="function_name" attribute in Android XML(for assigning an onClickListener to a View) But as MVC pattern the View/representation layer MUST be fully separated from Controller/logic layer.
Data source layer :
Finally you can have a data source layer which its responsibility is to providing data, persisting data, and all data related stuff. In Android you would put some things in this layer such as dealing with SQLite, ContentProviders, SharedPreferences etc
Result:
I think it's better to pick a main architecture pattern and design your application in high abstraction level according to your picked pattern and then implements its sub-layers. my favorite approach for architectural design and implementation is something sounds like top-down approach, in this strategy you would design your application in top to bottom manner / more abstract to less abstract / less detail to more detail
I divided an app to few layers - Presentation layer, Domain Layer/Service Layer and Data Source Layer.
Alternatively you could divide the app vertically by its features. So you get a package for each feature or activity, perhaps with subpackages. A good rule of thumb is: a package should not contain more logic, than you (or someone else) can easily understand. This technique has some advantages. First, your packages do not become bigger and bigger when you add more features to your app. Second, it becomes easier to maintain dependencies between different features. Perhaps your IDE can generate a dependency matrix of your packages.
Also where to put Threads. I am developing an app, which constantly loads data from a remote database through PHP scripts and displays them on UI.
Android has the concept of Loaders and AsyncTasks. They help you to seperate long running tasks from the UI. There is an example using the Loader-API on the Android developer website.
You might want to put your network communication in a Service instead of AsyncTask or Thread.
Your architecture sounds like some form of MVC which is good in my opinion.
I think the Activity is a good starting point for you. Learn it's lifecycle and how to present your data to the user. You can also read more about threads and connectivity to see for yourself how it's done in android.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
In the same way a web or desktop app might have three or n tiers - UI, Business, Data for example - what is the suggested structure for an Android application? How do you group classes together, what layers do you have etc?
I'm just starting Android dev (an internet-based app that must respond to incoming notifications) and have no real feel for the structure I'm aiming at. Suggestions appreciated.
IMHO, Android "wants to" follow a MVC pattern, but view & controller are generally really coupled in activities.
It makes unit test harder and it's hard to obey to the Single Responsibility Principle.
I found a really nice Android architecture presented here, there could be an idea. Everything is loosely coupled, so much easier to test and edit.
Obviously, I'm sure there are a lot of others possibilities (like the MVP pattern (Model View Presenter) - and here are answers talking about MVP in Android), but you should still take a look on it.
I've been working on Android for 9 months now from a server-side background where full unit testing and layered architectures are common and work well.
Through lots of trial and error and I would strongly suggest using the Model View Presenter pattern, not Model View Controller.
A huge issue I've found is that Activities/Fragments have a lifecycle which is outside your control and can lead to unexpected issues.
For example, our main android app wants to be used in landscape mode on tablets. We do this in OnCreateView() or OnCreate().
On a Nexus 7, the default view is portrait so what happens is that it starts the activity in portrait mode, our code then says go to landscape and android ultimately creates the activity class 3 times!
We've hooked up network requests to onCreate and they end up happening 3 times in this case.
Sure, we can add logic to look for duplicate calls but, in my opinion, it would be better, architecturally to try and divide the UI from the business logic.
My recommendation would be to use the factory pattern to create presenters from the activity but make sure the factory only ever returns the same instance. The presenter can then contain logic to do network request, look for duplicates and return cached results and general business logic.
When results from network calls return, either post to a bus such as Otto which the activity (register for the event on onResume() and deregister during onPause()) has registered to, or make sure the callback interface implemented by the activity has been updated to the last activity in the presenter.
This way, code in the presenter downwards is unit testable and not reliant on flaky UI layer testing.
The actions, views and activies in Android are the baked in way of working with the Android UI and are an implementation of a model-view-viewmodel pattern, which is structurally similar (in the same family as) model view controller.
To the best of my knoweledge, there is no way to break out of this model. It can probably be done, but you would likely lose all the benefit that the existing model has, and have to rewrite your own UI layer to make it work.
You can find MVC in the followings:
You define your user interface in various XML files by resolution/hardware etc.
You define your resources in various XML files by locale etc.
You store data in SQLite or your custom data in /assets/ folder, read more about resources and assets
You extend clases like ListActivity, TabActivity and make use of the XML file by inflaters
You can create as many classes as you wish for your model, and have your own packages, that will act as a structure
A lot of Utils have been already written for you. DatabaseUtils, Html,
There is no single MVC Pattern you could obey to. MVC just states more or less that you should not mingle data and view, so that e.g. views are responsible for holding data or classes which are processing data are directly affecting the view.
But nevertheless, the way Android deals with classes and resources, you're sometimes even forced to follow the MVC pattern. More complicated in my oppinion are the activites which are responsible sometimes for the view but nevertheless act as an controller in the same time.
If you define your views and layouts in the xml files, load your resources from the res folder, and if you avoid more or less to mingle this things in your code, then your anyway following a MVC pattern.
MVP is the latest architecute most people are following
Here is the small documentation As Uncle Bob's clean architecture says, “Architecture is About Intent, not Frameworks”
Watch this video it's just mindblowing good.
Here is a dedicated project for Android Architecture blueprints with well documented source codes. All of them are based on the MVP pattern with several twists. Also check the comparison of the various solutions based on lines-of-code, testability, cost of learning, their support for increasing data complexity. It depends on the particularly developed app and the context (time to market, developers, future plans, etc.) which blueprint fits best.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I was a JaveEE developer. Recently I joined an Android development team. The structure of Android confused me. The MVC design pattern doesn't seem to suit for Android development. So what is the design pattern principle for Android development? I mean is there any hint about how to write a clean, easy reading and effective Android code.
Android's architecture annoyed me at first, but I beginning to see a method to their madness. It's poorly explained by the android documentation. My biggest gripe has always been that it's hard to have a centralized data model with objects that your Activities share just like a normal application. Android seemed to want me to be a nomad because I could only share primitives between my Activities. And dropping junk in a database is NOT a model because it contains no behavior. So as most people my business logic all ends up in my activity making it hard to share business logic in other activities.
I've come to find out I was missing some key puzzle pieces. Android is MVC. However, it's coupled to the View fairly heavily.
Activity == Controller
Model == Subclass of Application
Anything that subclasses View == View
Interestingly you can create a subclass of Application and declare this in your Manifest file, and Android will create a single instance of this object that lives the length of your application no matter what Activity is destroyed or created. That means you can build a centralized data model there that all Activities have access to.
The way I see this is something like a primitive Spring container that you can initialize objects and resolve dependencies between them. That way you can decouple the model portion of your application away from the Activity themselves. And just have the Activity make calls on the model, and hand callbacks to receive the results so it can update the UI.
The problems with Android is that it mixes controller and view pretty heavily. For example, subclasses like TabActivity, ListActivity imply a certain view being used. So swapping out a view is pretty involved. Also the Controller makes very specific assumptions about what the view is even if you use Activity. He contains direct references to UI objects like TextView, etc. And it registers for low level events like clicks, keyboard, etc.
It would be better if Activity could register for more high level events like "Login", "Update Account Balance", etc which the view would dispatch in response to a series of clicks, keyboard, touch events. That way the controller works at the level you might describe features instead of design features.
I think we'll reach this type of design eventually as we better understand come up with better tools and techniques. It seems like Android might have the extensibility to make this happen, but it's up to community to chart it.
The actions, views and activies in Android are the baked in way of working with the Android UI and are an implementation of a model-view-viewmodel pattern, which is structurally similar (in the same family as) model view controller.
To the best of my knoweledge, there is no way to break out of this model. It can probably be done, but you would likely lose all the benefit that the existing model has, and have to rewrite your own UI layer to make it work.
You can find MVC in the followings:
You define your user interface in various XML files by resolution/hardware etc.
You define your resources in various XML files by locale etc.
You store data in SQLite or your custom data in /assets/ folder, read more about resources and assets
You extend clases like ListActivity, TabActivity and make use of the XML file by inflaters
You can create as many classes as you wish for your model, and have your own packages, that will act as a structure
A lot of Utils have been already written for you. DatabaseUtils, Html,
There is no single MVC Pattern you could obey to. MVC just states more or less that you shouldn't mingle data and view, so that e.g. views are responsible for holding data or classes which are processing data are directly affecting the view.
But nevertheless, the way Android deals with classes and resources, you're sometimes even forced to follow the MVC pattern. More complicated in my opinion are the activites which are responsible sometimes for the view but nevertheless act as an controller in the same time.
If you define your views and layouts in the xml files, load your resources from the res folder, and if you avoid more or less to mingle this things in your code, then you're anyway following a MVC pattern.
Android development is primarily GUI development, which like Swing/AWT in Java consists of lots of anonymous inner classes reacting to GUI events. Its one of the things that has really kept me away from doing a lot with Swing....but I have an Android phone, so I'm going to grit my teeth and just get over it, as many an Apple fanboy has said about the antenna problems. ;)
Android makes the typical decision of making the Controller and the View a single class. This encourages putting too much in the same place. An Activity corresponds to a screen, each View to a region of a screen (sometimes the whole screen), each Controller to the user gestures from that region of the screen, and Models are just Models, sometimes backed by services from Environment or some other crazy little set of utility functions. I use the Activity to coordinate one or more MVC trios. This helps deal with Android's choice to just throw everything in the same place.
I can test the vast majority of an Android app without running the simulator. Big win.
Sorry for my English.
Android has a very good modularity (Activities, Fragments, Views, Services, etc.). So there is no need in MVC.
Of course there is the separation of taking input (Activities, Fragments), logic, view (xml or java) and data (databases, files, preferences). But this is not MVC. You shouldn't try to use MVC, it will only complicate your architecture.
Rather than keeping something in global scope, Android motivates you to keep objects as deep as possible in their scopes (class members, local variables), and pass objects to/from activities, or to fragments, using Intents/Bundles. This is also because of memory limitation.
The system may destroy your activity if the foreground activity
requires more resources so the system must shut down background
processes to recover memory.
So it's not safe to store not-constant (mutable) objects as global (static) objects. Usually you use static for immutable constants.
In simple terms, you separate your application into screens (Activities). Then each screen - into fragments (Fragments). To perform a sequence of actions on the screen you can also separate them using Fragments (example).
So you have very small blocks in your application, each of which you can easily test and reuse.
My impression is that android programming model has lots of similarity with MS WPF.
XML layout definitions, code that is always bound to one of these definitions...
So, if you are asking about design patterns because you want to improve your current or in development android projects, maybe you should look at WPF practices and patterns for improved architecture, like MVVM.
Check out these links:
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
there is small project that is already trying similar thing:
http://code.google.com/p/android-binding/
cheers