在一般的导航中,MvvmCross仅允许在ViewModels之间传递字符串。
原因是导航需要通过平台级别的机制(如Xaml Uris或Android Intents)完成。
对于您提出的情况,我通常使用的一般模式是:
- TeamViewModel使用注入的ITeamService从网络获取团队数据
- TeamViewModel还使用注入的单例ITeamCache来缓存团队
- 导航通过调用以下方式进行:
this.RequestNavigate<PlayerViewModel>(new { teamId, playerId })
- 然后,PlayerViewModel在其构造函数中接收TeamId和PlayerId,并使用ITeamCache收集正确的球员
此代码可能如下所示:
public class TeamViewModel
: MvxViewModel
, IMvxServiceConsumer<ITeamCache>
{
public TeamViewModel(string teamId, string playerId)
{
var teamCache = this.GetService<ITeamCache>();
Player = teamCache.GetPlayer(teamId, playerId);
if (Player == null)
{
}
}
public Player Player { get; set; }
}
请注意,上面的代码测试了Player是否为
null
。这是因为你的假设“在TeamView中,团队是深度加载的,所以球员数据已经在内存中。”存在问题。
问题在于,在Android和WP7等平台上,操作系统可以自由地从内存中删除你的应用程序,然后稍后重新启动它。这在WP7上被称为
Tombstoning,但在Android上似乎只被称为
Killed。
在这些情况下,操作系统可能会在用户导航回来时稍后重新启动您的应用程序。这个重启将直接进入用户最后停留的活动,并记住回退堆栈 - 然后就由你的应用程序来正确地重新激活任何需要的对象并将其放回内存中。
以下是一些非常小的图片来解释这个问题...
![enter image description here](https://istack.dev59.com/s6lFR.webp)
如需更详细信息,请查看Xamarin和MSDN。
针对您的团队/球员情况,您可能可以通过以下方式应对重新启动后的数据恢复问题:
- 将ITeamCache实现为基于文件的对象 - 例如,它可以使用JSON文件或SQLite数据库作为内存数据的持久存储
- 在代码中实现一些逻辑,以在需要时从网络重新获取数据
- 在这些情况下实施一些紧急导航回主页的策略 - 因为在现代资源丰富的手机上,许多应用程序很少出现这种情况。
- 只是崩溃 - 虽然这并不可取...
很多应用程序处理墓碑状态都不太好,这并不奇怪...
注意:对于小对象,您的第三个选项(序列化)可能很有效 - 但是,这不会帮助您处理应用程序重新启动并且用户从PlayerViewModel导航回TeamViewModel的情况。
如果想了解MvvmCross中Android生命周期的最新变化,请参阅http://slodge.blogspot.co.uk/2012/05/android-application-initialization-and.html。