Throughout Google search some people has told that Android architecture is MVC just like in iOS. But I couldn't feel the separate Model concept in Android. What is the design pattern behind Android design? And what are the main differences in case of programming concept (not IDE, language)?
Well lets see what we have on both sides:
iOS:
UIViewController
UIView
Your stuff (models and other)
Android:
Activity
View
Your stuff (models and other)
If you don't know already, Activity is the equivalent of UIViewController in Android.
Given that we know that you can now draw the line for yourself and see that in fact both platforms do work in the same manner from the MVC point of view but that can't stop you implement you project's architecture as you think it's the best for you.
Of course the low level implementation and logic in some cases are pretty different on both platforms though.
The way I understand it is that Android's architecture is more MVVM than MVC. But I'm also very new to all of this so don't take it for granted. Another opinion on this would be nice!
Related
I want to develop a real-time chat application in Android like WhatsApp or telegram
for the all-purpose client should connect to the server via WebSockets and even
offline or online has to works fine. I decided to use Android architecture like MVP, MVVM, and MVI, but I'm confusing which one is suitable for my app
Can anyone help me to choose one of them?
And my second question: is it ok to use WebSockets for all APIs or it should better use WebSockets and REST APIs together?
Thanks for your help
There are quite a few patterns out there for app architectures. The most well known are the classic three-tier architectures such as:
MVC: Model-View-Controller.
MVP: Model-View-Presenter.
MVVM: Model-View-ViewModel.
All these patterns represent the main similar idea — to structure your project’s code in a way that it is separated by the different generic layers. Every layer has its own responsibility. That’s why your project becomes modular: separated code parts are more testable, and your app is flexible enough for continuous changes.
MVP is strongly recommended because a lot of developers are using it now. Even, Google also provides its best practice example on Github. You can see full document here.
I strongly recommend you use MVVM because Google has adopted this approach for Android Projects recently. You can find a lot of examples about it. Especially LiveData and ViewModel mechanisms have a lot of advantages in terms of separation of concerns and managing the relations between ui and data.
using MVVM or MVP should i name packages like model, viewmodel, view and put proper classes and interfaces there or is it just a logical structure that should not be visible in classes structure?
If you want to go by the book, the current "correct" way to implement MVVM in Android is the Android Architecture Components set of libraries.
Read more about it here, and try this code lab. These will also show you how to name and place your classes.
But in general, you should go with what matches your app best. For smaller apps I would recommend going with M V P folders, while for bigger, more long-term ones tend to work better with folder-per-feature structure.
Google in it's sample Android Architecture project uses Model(Data) V(views) VM(view-models) file structure
Google sample sunflower app to show architecture components
Probably that's the best approach
Additionnaly you may find this resource interesting https://overflow.buffer.com/2016/09/26/android-rethinking-package-structure/
An implementation is visible here https://github.com/SamYStudiO/beaver
I also would like to indicate watching this TUTORIAL.
This guy goes well on teaching about the Architecture MVVM and also uses the ROOM Persistence Library.
It is worth giving a look at it.
I read an article about React Native(http://blog.scottlogic.com/2015/03/26/react-native-retrospective.html), and I'm also experimenting it at the moment.
During a few days of experiment, my feeling is switching from excited to concerned.
As React Native is focused on V in MVC, but IMHO I'm more keen to share code in M (and Services) across platforms. I'm happy to have native views (xib for iOS and layout for Android), as I think they are meant to be platform specific, and that is the main reason for going native rather than hybrid and HTML5. The story is different for Model and Services though as they are common and better to be shared across platforms.
It might make sense to have shared code between Mobile(React Native) and Web(React), but it is too early to tell now.
How do you think? And I look forward to hearing your thoughts.
With React Native you can write all of your views in Obj-C (Cocoa, XIB or Java) if you want. It's actually not that complicated.
However, some of the greatest strengths of RN is that it uses JavaScript. This allows you to write all of your business logic ("M" as you put it) in JavaScript and now share that across mobile platforms (iOS & Android right now). Of course, if your business logic is decoupled from the UI (as it should be), you can then even share that on the Web as well.
Before this, if you wanted a shared common library of business logic between mobile platforms you had to either write it in C++ or perhaps use something like Xamarin (C#).
I'm not sure if that is answering your question or perhaps agreeing with some of the things you are talking about haha. AFAIK, React Native is definitely solving the right pain point because it's so flexible, it let's you decide what that pain point is. :)
We are starting the development of an Android and IPhone app and wanted to know if the best practice on developing the UI for both environments.
We have developed the core (functionality) for both the environments as common classes. The core does not have dependency on the UI at all.
Is the best practice to have separate UI code for IPhone and Android or should they be combined together and where required conditionally written?
I would like to understand this as you may have come across situations like this.
Appcelerator has two recommended methods for creating cross-platform UIs - branching and platform-specific commonJS.
In my experience the use of platform-specific commonJS has been the easiest to maintain, although it does require a little extra work up front.
The section on supporting multiple platforms in a single code base in the Titanium 2.0 documentation goes into greater detail on this subject and should be helpful in choosing the path that's right for you.
A good example of creating cross platform UIs is the community app created by Appcelerator's Titans program.
I'm working on an Android project and I would like to know any recommendations about what's a good architecture to build an android application.
I want to use dependency injection using Roboguice and I've been reading about MVVM pattern or MVC pattern (Android MVVM Design Pattern Examples).
Also I know that roboguice have a pretty cool Context-Based Event's raising and handling feature that could be very testable as the code is decoupled.
Any recommendations on a working design pattern? a testable and scalable architecture you have worked with or developed?
The Android platform provides a common set of design patterns, and with the limited hardware resources you get compared to Web-apps it is still often best to stick with using these directly in production code. There are other frameworks that sort of "wrap" the base platform; these are worth looking into if you have a specific purpose (or perhaps for prototyping/experimenting), but for the best level of support you are generally best sticking with the standard components.
This is a great resource when working on UI solutions: http://www.androidpatterns.com/
Specifically for DI: There is a Spring framework for Android, I've had a play with it and it looks quite promising. You've already mentioned Roboguice as another alternative to this. However, to avoid performance and library overhead, I still find the easiest approach is to write a simple reflection-based class that registers and injects dependencies within my own code. Similar to this approach, except I usually move the injection code into a separate singleton and reference it from there.
In my experience most of the third-party offerings are not yet mature enough to rely on right now, and don't really give you much on top of what the base platform provides. They are constantly progressing, however, so be sure to experiment with the big names from time-to-time.