public override void GetContent(Invert.Core.GraphDesigner.IDocumentationBuilder _)
{
base.GetContent(_);
_.Paragraph("Subsystems allow you to seperate the various pieces of your project into logical and reusable parts. Subsystems contain any number of Services, Elements, Views, StateMachines ..etc");
_.ContentByPage <SystemLoaders>();
}
public override void GetContent(Invert.Core.GraphDesigner.IDocumentationBuilder _)
{
base.GetContent(_);
_.Paragraph("While services can serve for almost any purpose, they can be used to seperate various features of uFrame, and your application. " +
"Examples might include, FacebookService, NetworkingService, AchievementsService...etc");
_.Break();
_.Paragraph("As a matter of fact, at the time of this writing, uFrame ships with two default services, The 'ViewService', and the 'SceneManagementService'.");
_.Break();
_.Paragraph("There is really only one general rule of thumb when implementing services, " +
"they should only be listening to events, processing them, and publishing its own " +
"events that might be useful to other services. While you can inject other services " +
"and use them directly, it's highly reommended to use events as the means of communication.");
_.Break();
_.Title2("Accesing ViewModels in services.");
_.Paragraph("To access a running list of a specific viewmodel just add this property to any service, and make sure you specify the viewmodel type you need.");
_.CodeSnippet("[Inject] IViewModelManager<PlayerViewModel> AllPlayers { get;set; }");
_.LinkToPage <ViewModelManagers>();
var service = ServiceNode();
_.Title2("Designer File Implementation");
_.TemplateExample <ServiceTemplate, ServiceNode>(service);
_.Break();
_.Title2("Editable File Implementation");
_.TemplateExample <ServiceTemplate, ServiceNode>(service, false);
}
public override void GetContent(Invert.Core.GraphDesigner.IDocumentationBuilder _)
{
base.GetContent(_);
_.Title2("What Is It?");
_.Paragraph("Views are perhaps the easiest layer to understand in the context of Unity, due to the fact that they exist specifically to interact with the UnityEngine namespace and environment. Views are the \"presentation\" layer, where the data of ViewModels are represented through the implementation of bindings. The idea is that for the most part, ViewModel data exists somewhere already, and Views merely \"bind\" to that data in order to represent changes in a way that Unity and players can understand.");
_.Title2("Where does it exist in Unity?");
_.Paragraph("Views generated by uFrame inherit from Monobehaviour, and therefore are much like normal Unity components. Building on top of Monobehaviour, uFrame ties into Unity methods like Update, Start, OnEnable, and OnDestroy in order to implement necessary MVCVM functionality within the Unity environment. Every View that uFrame generates is meant to exist as a component on a particular GameObject. For instance, a PlayerView should probably exist on some kind of Player GameObject, and a PlayerHUDView should probably exist on some kind of GUI GameObject to bind to and express a player's stats and other properties.");
_.Title2("What Else?");
_.Title3("The Presentation Layer");
_.Paragraph("Views are the so-called \"presentation\" layer, where a programmer will implement the logic of how the abstracted ViewModel data is represented in a particular environment. So if you have a PlayerViewModel, you may decide to represent that in any number of ways, including:");
_.Paragraph(" - a PlayerView that represents the player as an animated character moving in space");
_.Paragraph(" - a PlayerHUDView that represents the player's health, stamina, energy and other stats in your GUI");
_.Paragraph(" - and maybe a PlayerMapView that represents your player's position relative to some kind of GUI Map object");
_.Paragraph("All of these would typically want to bind to the same player ViewModel \"instance\", such that they are said to share the same ViewModel, representing the data in different ways. The most important distinction is that each of these views should concern themselves with ONLY their own representation, meaning that the PlayerView in the above example should not be updating GUI elements, but rather leave that to the PlayerHUDView or possibly PlayerMapView. Views should be as independent as possible, handling just themselves and their own interactions. Since any number of Views can bind to the same ViewModel instance, it is up to you to determine how many Views are needed and what their individual responsibilities will be in representing that data inside Unity.");
ImportantMethods(_);
}
public override void GetContent(Invert.Core.GraphDesigner.IDocumentationBuilder _)
{
base.GetContent(_);
_.BeginTutorial("Creating Services");
}
