有可能在Java中为Android实现模型-视图-控制器模式吗?
或者它已经通过活动实现了吗?或者有没有更好的方法来实现Android的MVC模式?
有可能在Java中为Android实现模型-视图-控制器模式吗?
或者它已经通过活动实现了吗?或者有没有更好的方法来实现Android的MVC模式?
当前回答
经过一番搜索,最合理的答案是:
MVC已经在Android中实现了:
View =布局,资源和内置类,如从android.view.View派生的Button。 控制器=活动 模型=实现应用程序逻辑的类
(顺便说一下,这意味着活动中没有应用程序域逻辑。)
对于小型开发人员来说,最合理的做法是遵循这种模式,不要尝试做谷歌决定不做的事情。
PS注意,活动有时会重新启动,所以它不是模型数据的地方(引起重新启动的最简单的方法是从XML中省略android:configChanges="keyboardHidden|orientation",然后转动你的设备)。
EDIT
我们可能会谈论MVC,但它会这样说,FMVC,框架-模型-视图-控制器。框架(Android操作系统)强加了它的组件生命周期和相关事件的想法,在实践中,控制器(活动/服务/BroadcastReceiver)首先负责处理这些框架强加的事件(如onCreate())。是否应该单独处理用户输入?即使应该,你也不能把它分开,用户输入事件也来自Android。
总之,你在Activity/Service/BroadcastReceiver中植入的非android专用代码越少越好。
其他回答
没有一个单一的MVC模式可以遵循。MVC只是或多或少地说明了你不应该将数据和视图混为一谈,例如,视图负责保存数据,或者处理数据的类直接影响视图。
但无论如何,Android处理类和资源的方式,有时你甚至被迫遵循MVC模式。在我看来,更复杂的是那些有时负责视图,但同时又充当控制器的活动。
如果您在XML文件中定义视图和布局,从res文件夹加载资源,并且如果您或多或少地避免在代码中混合这些东西,那么您无论如何都是在遵循MVC模式。
我发现在Android上实现MVC最好的资源是这篇文章:
我在自己的一个项目中采用了同样的设计,效果非常好。我是Android的初学者,所以我不能说这是最好的解决方案。
我做了一个修改:我实例化了应用程序类中每个活动的模型和控制器,这样当横向-纵向模式更改时就不会重新创建这些模型和控制器。
在我看来,Android处理MVC模式的方式是这样的:
您有一个充当控制器的Activity。你有一个负责获取数据的类,即模型,然后你有一个View类,即视图。
当谈到视图时,大多数人只想到xml中定义的可视部分。不要忘记,视图也有一个程序部分,它的构造函数,方法等,在java类中定义。
经过一番搜索,最合理的答案是:
MVC已经在Android中实现了:
View =布局,资源和内置类,如从android.view.View派生的Button。 控制器=活动 模型=实现应用程序逻辑的类
(顺便说一下,这意味着活动中没有应用程序域逻辑。)
对于小型开发人员来说,最合理的做法是遵循这种模式,不要尝试做谷歌决定不做的事情。
PS注意,活动有时会重新启动,所以它不是模型数据的地方(引起重新启动的最简单的方法是从XML中省略android:configChanges="keyboardHidden|orientation",然后转动你的设备)。
EDIT
我们可能会谈论MVC,但它会这样说,FMVC,框架-模型-视图-控制器。框架(Android操作系统)强加了它的组件生命周期和相关事件的想法,在实践中,控制器(活动/服务/BroadcastReceiver)首先负责处理这些框架强加的事件(如onCreate())。是否应该单独处理用户输入?即使应该,你也不能把它分开,用户输入事件也来自Android。
总之,你在Activity/Service/BroadcastReceiver中植入的非android专用代码越少越好。
Android上的动作、视图和活动是与Android UI一起工作的内置方式,是模型-视图-视图模型(MVVM)模式的实现,它在结构上与模型-视图-控制器相似(在同一家族中)。
据我所知,没有办法打破这个模式。这可能是可以做到的,但是您可能会失去现有模型的所有好处,并且必须重写自己的UI层以使其正常工作。