Added generic Forms content page

[martijn00]

@PeterBurke What do you think of this idea?

[PeterBurke]

Hi Martijn

I will be able to review the changes over the weekend.

[PeterBurke]

Hi Martijn

When I originally started trying to use CheeseBarron's NuGet packages, I had a lot of issues with content. I now know how to work around these issues, but every newbie will have similar issues.

The problem is caused like this:

• Developer wants content pages like the way he thinks the world should work i.e. Forms written in c# not Xaml
• I come along and after installing the NuGet packages it does not clean compile
• I get it working but for XAML, most content then removed
• this continues as long as I only do Nuget Package restore
• if however I want to start from a clean slate, then Nuget downloads those freaking content files again, that I had forgotten and so now it does not compile again.

A compounding problem being that only one of us has the key to update the NuGet, I had to work with my own local NuGet server, and my guess is there were times when the NuGet was not updated for anyone accessing the latest Samples in GitHub.

So therefore I am of the view that we should not be adding C# content files at all. But you may add assets e.g. image libraries etc. as content without too many problems.

Now each target (iOS | Android) contains a set of c# files that are needed in order to make MvvMCross work: A: DebugTrace, Setup, MvxFormsApplicationActivity, LinkerPleaseInclude, SplashScreen I: AppDelgate, DebugTrace, LinkerPleaseInclude, Main, Setup

I have often needed to modify these files in order to do things that work at a low level, for example Xamarin have a set of modifications that allow you to establish a view attribute called StyleId that is used in XamarinTest in order to allow for Querying view elements. Another situation is when using SQLite there needs to be a bit of target specific c# to work with the target Operating System File System.

There is also the need for c# ViewModels etc. and these may contain hooks to load plugins.

Now in my view putting c# content files into NuGet packages is not what Nuget is for. The latest NuGet is really like a super global reference of compiled components.

The name of this mod: "Added generic Forms content page" is what set off alarm bells, but I will need several more days to actually fully understand what is going on here.

The best alternative to c# content would be a VS Template possibly including a wizard to help set up a new app quickly.

Also when you have a class like SetUp that is a subclass of Mvx?????Setup an abstract class that has to be linked in for the ViewPresenter to work, but is called using reflection (IoC) there may to improve this.

Anyhow these are my thoughts for now! More investigation to do and then we can discuss.

[PeterBurke]

I have taken a closer look at this and now its seems like it is moving in the right direction.

A very large number of changes in the previous change, but they are all related to a refactoring of the MvvmCross core assemblies, with a new set of names, e.g. dropping the "Cirrious" name.

I think I misunderstood what the generic Forms content page was all about. It is subclass of the Xamarin ContentPage adding things needed for linking to MvvmCross. Plus it compiles into an assembly and is not a c# content file dropped in via NuGet.

The process that Xamarin / Microsoft use for these Cross Platform templates is that they coordinate releases and the Visual Studio update will then provide updated templates.

When you use one of these templates, it adds those c# files to your starter solution.

The trouble is though that in order to make MvvmCross work, those c# files need modification.

What I can do in conjunction with building up the documentation, is to create a set of project templates that will be an alternative to the Xamarin ones. Hopefully Xamarin will release future versions via the Alpha channel to that we can get the modified templates ready.

It is good to see so much work going on here as all too often in the Open Source world, unless you are a commercial company and can afford to pay developers, GitHub projects tend to hit a stop point at some stage and then another group simply forks them with a different name and takes over.

I still need to do some more work investigating change request and determining if there are any issues.

However I still maintain that such

[Cheesebaron]

That were some long posts @PeterBurke, so many filler sentences and words :cry:

With NuGet when you have content files and you edit those content files after they have been added to your project it will prompt you whether or not you want to override them when you update your projects. Keep in mind they might get removed if you remove the NuGet from the project. Hopefully you are using some version control for your project in those cases so you can restore them...

For the Main repo, we have a StarterPack. Maybe this project could do a similar approach. However, I don't see there should be any issues with content files, not even when editing them. Probably PEBCAK.

For working with NuGet packages locally, you don't have to run any servers or anything. Just add a folder to your NuGet repositories.