I have created a new solution for my MvvmCross app that supported Windows Store and I want to support UWP on Windows 10. I have moved over the PCL successfully, but I am having problems getting the basic UWP app working using a sample provided by MS (NavigationMenu) which uses the SplitView and the AppShell pattern they are recommending for the new navigation/command model. I referenced a helpful blog post (http://stephanvs.com/implementing-a-multi-region-presenter-for-windows-10-uwp-and-mvvmcross/), which gave me some guidance on how to integrate mvvmcross into the AppShell, but startup is failing because the AppShell does not have a valid Frame defined. Frame is a read-only property, and I have been unable to see where this is being set up.
I am using the standard AppShell implementation from the NavigationMenu with the following changes as recommended in the blog post:
public sealed partial class AppShell : MvxWindowsPage // was Page
public Frame AppFrame { get { return this.Frame; } } // was this.frame
Except for code after the error, there are no differences in the setup. In looking at the MvxWindowsPage implementation, there doesn't seem to be anything special as it still invokes the Page initialization. Is there something obvious I am missing?
So the link to the blogpost is correct, in other words you'll need to use MultiRegions from MvvmCross to get this working.
But what the blogpost doesn't show is a complete working version...
I've added one on my github here:
https://github.com/Depechie/MvvmCrossUWPSplitView
Some pointers to take away, like I said in the comments.
Your view where the SplitView will be present, needs to have a property to return a valid Frame to look for while injecting new views. This can be returned like this return (Frame)this.WrappedFrame.UnderlyingControl; found in the code here https://github.com/Depechie/MvvmCrossUWPSplitView/blob/master/MvvmCrossUWP.Win/Views/FirstView.xaml.cs#L13
Than all views you want to load up in the SplitView will need to reference to the region you defined in that SplitView, in my case I named it FrameContent as seen here https://github.com/Depechie/MvvmCrossUWPSplitView/blob/master/MvvmCrossUWP.Win/Views/FirstView.xaml#L48
So use that name for the region attribute in all to be loaded views like so [MvxRegion("FrameContent")] example here https://github.com/Depechie/MvvmCrossUWPSplitView/blob/master/MvvmCrossUWP.Win/Views/SecondView.xaml.cs#L7
I see what you're trying to do with the SplitView template that's provided by Microsoft. There is however a mismatch between things managed by MvvmCross and UWP.
By default MvvmCross maps ViewModels to Views based on naming conventions. What you are trying to do is use a view 'AppShell' (which is derived of Windows.UI.Xaml.Controls.Page) that doesn't adhere to the default MvvmCross convention.
The way I choose to implement this SplitView (Hamburger) functionality is by deleting the provided AppShell class entirely. I then created a new view named HomeView (since I have a ViewModel with the name HomeViewModel) and added the SplitView control there as described in the post you mentioned above.
For completeness I've created a Gist with the App.xaml.cs and HomeView.xaml as you requested. You can find them here: https://gist.github.com/Stephanvs/7bb2cdc9dbf15cb7a90f
Related
I've been playing around with this for a while now, and I think, I've - almost - cracked it, but I am still not fully satisfied with my solution.
So, what I want to do, is having a piece of content, a list of items, which would have two views: The standard HTML one, so people can view and edit it; and then a JSON endpoint for other services to consume.
First I thought it's a simple matter of creating two JSP scripts to render the content:
/apps/my-stuff/components/list-page/html.jsp
/apps/my-stuff/components/list-page/json.jsp
However the Apache Sling DefaultServlet seems to be rather ignorant of the json.jsp script.
As a second attempt, I created another script, in /apps/foundation/components/primary/cq/Page/json.jsp which will be actually called, and renders the page, as I expected. However there are a couple of worries/questions regarding this:
First of all, why is this being honoured by the system, and not the one in the more specific place?
The documentation states, that to find the appropriate renderer, first sling:resourceType will be inspected, then sling:resourceSuperType and then, only as a fallback will jcr:PrimaryType checked. However I think this is rather: jcr:PrimaryType, then the DefaultServlet, and then all the other things.
Most worryingly however, I have to admit, this is rather generic, so it'll break all the contnet with jcr:PrmaryType = Page, so that could have some side-effects.
A solution could be creating a new type: ListPage extends Page; and then create a renderer for that in /apps/foundation.... However I have this bad feeling, that might introduce other problems.
So my question is two fold: What is the proper way of doing this, and/or what am I missing from the way the URL -> script resolution is working in AEM/Sling. (Because it seems to be slightly different that described here and here.)
(Obviously I am trying to keep the default JSON renderer for other pages, as that might be needed for other things in the page. I am not even sure, changing this one page won't break the UI for this particular page...)
However the Apache Sling DefaultServlet seems to be rather ignorant of the json.jsp script.
Have you tried renaming your JSP like so: "list-page.json.jsp"?
If you're using AEM 6.3, you should look at Sling model Exporters. They allow you to automatically register a servlet against your Sling Model (that you can create to model your list content). That servlet can generate a JSON representation of the model for you using Jackson.
If you're not using AEM 6.3, I would suggest you create a servlet registered against your resource type and use an additional selector.
#SlingServlet(
selectors = "json",
resourceType = "my-stuff/components/list-page",
methods = "GET")
More information on Sling Servlets can be found here.
I have done a RegisterAppStart<FirstViewModel>() in the Core App.cs, now I navigate to FirstViewModel, then SecondViewModel and finally ThirdViewModel using ShowViewModel(),
Is there a way I want to navigate to the viewmodel which has been registered using RegisterAppStart<>(), I mean is this persisted or saved somewhere during run?
All I want is to get this value at runtime.
If you want to use a singleton instance of a view model then you can do this using a custom view model locator - see the wiki - https://github.com/MvvmCross/MvvmCross/wiki/Customising-using-App-and-Setup - "overriding view model location and construction"
I have a command that shows a view model:
private void DoShowImportCommand()
{
this.ShowViewModel<GeometryImportViewModel>();
}
but I only want to execute it if that view model isn't already shown. Is there a way to
detect if that view model is already on screen and if so don't execute the command?
MvvmCross doesn't track this by default - what is currently shown depends on the UI and can be interpreted in different ways in different situations (popups, tabs, pivots, dialogs, back stacks, etc)
If you want to track this in your own application, you could do it using UI project components (e.g. custom presenters) or you could do it using a shared code component - e.g. you could add "alive" tracking to the Views/ViewModels (see the N=42 video on http://mvvmcross.blogspot.com) and could then use some service to track which viewmodels are shown.
Love this framework thus far.
That said, hit my first roadblock. I have created an MvvmCross-based library (actually a few libraries) that performs login services that will be used across multiple cross-platform applications of the same family. What I can't quite figure out is how to plug these login libraries into my other applications (which will also be using MvvmCross). I want to be able to re-use the same ViewModels and Views across these apps.
Assume that I've read and watched a lot of slodge's videos. :) Which are very good.
I think MvvmCross with two core libraries was about the closest thing to what I'm trying to do, which is just smash MvvmCross projects together and make it all magically work. But going by that post, which had some inconsistencies in the code samples, I've been unable to get this working.
There are 2 methods in Setup which tell mvvmcross where to look for Views and ViewModels. If you override these then the system should find your views and view models.
protected virtual Assembly[] GetViewAssemblies()
{
var assembly = GetType().Assembly;
return new[] {assembly};
}
protected virtual Assembly[] GetViewModelAssemblies()
{
var app = Mvx.Resolve<IMvxApplication>();
var assembly = app.GetType().Assembly;
return new[] {assembly};
}
Beyond this, the only additions to this that I'm aware of are that you might need:
to give wp some extra help in finding the xaml urls for any views which are in additional assemblies - by default mvx only looks for the xaml uri in /views, not in any other folder in any other assembly. One way to provide the xaml urls is to add a MvxPhoneViewAttribute within the View's c# file, another is to override the MvxPhoneViewsContainer to make it provide custom urls.
to adjust some of the android project settings in order to get resources shared from libraries to main project (although this functionality has gotten much better within xamarin.android this year.
I'm using PHPStorm v3 and have some code which connects to a certain SOAP service. (via a simple PHP SoapClient) No problems whatsoever. But the PHPStorm inspector cant find the methods available of the WSDL and thus cant recognize the used methods:
$this->soap = new SoapClient('somewsdl url');
$issues = $this->soap->getIssuesFromJqlSearch($this->auth,
'ticketId = '.$ticket->getId().'
AND impId ~ "'.$currentImplementation->getIdentifier().'"', 1);
Everything works but the method 'getIssuesFromJqlSearch' which is provided by the external WSDL is highlighted with the mentioning of an undefined method... How can i 'tell' PHPStorm what should/could be used (or explain how to parse the WSDL?)
You can suppress the inspection for this statement from the Alt+Enter, right arrow menu:
This is not perfect, since it does not parse the WSDL and you have to do it manually, but works fine after the initial setup.
Create a class extending the native SoapClient and use annotations to add virtual methods:
/**
* #method mixed getIssuesFromJqlSearch
**/
class VendorSpecific extends \SoapClient {}
Or you could generate such client yourself, implementing all the methods as a proxy to self::__soapCall(). See my SoapClient generator for reference. The upside is that it can parse the WSDL, though not perfectly.