Forms roadmap news and the 2.2 release

** Reminder: all of this is NDA **

Hi. The Forms team has been defining its release process. One of the goals of this work is to share more about our Roadmap. We think what is outlined below is a good start, and we’re keen to continuously improve it. Your suggestion and feedback will help us with that.

The new release process (take 1)

First, we are moving toward a predictable cadence for releases. We intend to release a “pre1” point release each month (e.g. 2.2-pre1) around the middle of the month. After each pre1 there will be at least one follow-up pre-release (e.g. pre2, pre3) per week until that point release is deemed stable. Our goal is to move to stable in one to three weeks after a pre1 release. Feedback from the community (especially the Insiders!) will help us get from “pre1” to “stable” quicker and with fewer misses.

For release notes we will 1) summarize the “goals of the release”, 2) list “new features” implemented, 3) list “bugs squashed”, and 4) list “Important notes” for warnings and pitfalls.

We are still working out our process for major releases (e.g. 3.0, 4.0). One goal of major releases will be to gather the lessons from the previous major release and clean up the interfaces. With broad changes it’s much harder to call something stable. Therefore, after a major release we will delay one point release of features and instead focus on stability of the new major release. After that extra stabilizing cycle, we will resume the monthly point release cadence as described above.

Big events like Evolve, and major updates to the platform may cause one-off deviations from the process listed above. These are exceptions (fun exceptions), and we will return to our boring, predictable process in the following, calmer months.

Upcoming 2.2 release

Here are features targeted for 2.2.0-pre1 which will ship mid February:

Margin support:

Adding margin support is intended to allow users to reduce the overall depth of their layout hierarchies by allowing more complex layouts with fewer wrapping views.
public Thickness Margin { get; set; }

Nest platform controls to forms layout

Allows adding platform-specific controls (iOS, Android, and Windows) directly to a Forms layout. Note: this won't be available from PCL and would require #if defines to work from a shared project.

UWP maps support

CarouselView

2D ScrollView support

MenuPage

MenuPage is akin to a MasterDetailPage however instead of using a ContentPage on the master, the user passes a menu and we construct a platform appropriate view of it. This is especially useful on UWP and Android where such views exist but cannot be normally represented through Xamarin.Forms core API.

We look forward to your questions and feedback!

Tagged:

Posts

  • NMackayNMackay GBInsider, University ✭✭✭✭✭

    @BryanHunter.xam

    Hi Bryan,

    There's some really useful features here that will make life a lot easier, margin especially should reduce the amount of controls been nested to achieve layouts acceptable to our designers.

    MenuPAge also sounds very useful, currently we're using ContentPages and a Telerik SlideDrawer but it's not a perfect solution and this gives us an alternative.

    Could you elaborate a little further on the nest platform specific controls into forms? does that work a bit like WPF control where you have a windowhost control that references the specific library control? could you use this approach to embed a video player for example?

    If you could consider a couple of features that might be easy to implement but would make life a little easier:

    • Make the picker Bindable so you could bind an ObservableCollection and have a DisplayField property so you can bind lookups from a data service easily
    • A fallback value on bindings would be very useful, currently you have to write some code to take care of that or modify the data service, as is usually the way, the data we get served up from our core internal systems isn't always the best.

    Thanks for the update.

  • BryanHunterXamBryanHunterXam USXamarin Team Xamurai

    @NMackay, thanks for the feedback and questions!

    For "Nest platform controls to forms layout" your windowhost analogy is good. We will have two extension methods that we implement on each platform. One will take a platform-specific control and wrap it as a Forms View that can be set as Content. The other, will add a platform-specific control to an IList<View>. It will look something like...

    // Forms code (iOS)
    public static class LayoutExtensions 
    {
      public static View ToView (this UIView view) {...}  
      public static void Add (this IList<View> self, UIView view) {...}
    }
    // Your iOS code
    contentView.Content = new UILabel ().ToView ();
    stackLayout.Children.Add (new UILabel ());
    
    
    // Forms code (Android)
    public static class LayoutExtensions 
    {
      public static View ToView (this Android.View view) {...}
      public static void Add (this IList<View> self, Android.View view) {...}
    }
    // Your Android code
    contentView.Content = new TextBlock (Context).ToView ();
    stackLayout.Children.Add (new TextBlock (Context));
    
    
    // Forms code (Windows)
    public static class LayoutExtensions 
    {
      public static View ToView (this FrameworkElement view) {...}
      public static void Add (this IList<View> self, FrameworkElement element) {...}
    }
    // Your Windows code
    contentView.Content = new TextBlock ().ToView ();
    stackLayout.Children.Add (new TextBlock ());
    

    Does that all make sense?

    If anyone can spot dragons or pitfalls we may have missed, please let us know.

    Thanks!

  • NMackayNMackay GBInsider, University ✭✭✭✭✭

    @BryanHunter.xam

    Can you use the layout extensions in XAML?

  • CarlBartonCarlBarton USInsider, University, Developer Group Leader ✭✭

    Very much looking forward to a built-in CarouselView and I second both the question about XAML support for layout extensions and how great it will be to have Margins.

    Keep up the good work.

  • SmartyPSmartyP USInsider, University ✭✭

    I agree with @NMackay that having binding fallback values would be awesome. Especially if converters throwing exceptions could fall back to that value VS surfacing a crash in the app.

    One other issue I've noticed with bindings is that calling RaiseCanExecuteChanged() on a Command on a background thread throws UI thread exceptions. This is different from Win8 for example, so our ViewModels (shared between XF and Windows Universal apps) have a lot of Device.BeginInvokeOnMainThread() calls within #if checks to avoid those crashes. I believe the same holds true for updating a value on the ViewModel which is bound to a XF control. I would think that these thread checks should be internal and not require the VM to surface every property change to a UI thread, but maybe I'm missing something.

    I'm sure this isn't the right thread to get in suggestions for future XF iterations, but maybe another thread on that would be a good idea..?

  • adamkempadamkemp USInsider, Developer Group Leader mod

    IMO view model changes (including raising the CanExecuteChanged event form ICommand) should be made on the UI thread only because the consumers of those notifications are almost always UI objects (views). It's easier for your code to efficiently switch to the UI thread when needed and do a batch update than it would be for the Forms framework to invent a system of batching changes to send to the UI (or worse, don't batch and have really inefficient code). I don't know how this problem is solved on Windows, but I just think that generally these kinds of events should be raised in the UI thread only to avoid crashes or race conditions. Consider it part of the view model's job.

  • wallymwallym USInsider, Beta ✭✭✭

    A couple of questions on XF. One of the concerns that I have about XF is the number of components necessary to make a solution work for things that I think are absolutely a requirement with a mobile device. I think that location is a requirement. I need to be able to get location (Lat/Lon). Along with the location, I need to do reverse geocoding. I also need to use the camera for still pictures as well as video.
    1. Location. I need latitude and longitude at a minimum. I'd like altitude, heading, other appropriate info. To do this right now, I have to use some third party components. I could go write some code that is platform specific for this as well. Either a component or some code that I write can be used.
    2. Reverse geocoding. I have to write some code to do this.
    3. Camera access. I'd like to access the camera for pictures and video.

    I'd like these things in XF. Right now, I have to add some components into the project to get this functionality. I don't like third party components. I find that projects that depend on a lot of third party components are typically problematic. What happens when someone stops supporting their component? Please don't say that someone else will pick it up, that is not a guarantee.

    I'd like to see more common functionality included in XF. I haven't looked at XF in the past two months, so I'm not sure if this type of functionality is there, but I doubt it.

    That's my thoughts on the direction of XF and what I would like to see. :-)

  • JamesMontemagnoJamesMontemagno USForum Administrator, Xamarin Team, Developer Group Leader Xamurai

    @wallym Make sure to check out https://xamarin.com/plugins this handle everything you ahve listed :) Most of them built and supported by Xamarin employees with tons of downloads. If they don't work exactly how you want they are open source under MIT and work even in traditional Xamarin apps :)

    Reverse geocoding is here: https://developer.xamarin.com/recipes/cross-platform/xamarin-forms/maps/reverse-geocode/

  • wallymwallym USInsider, Beta ✭✭✭

    James, I understand what you are saying. :-) I'm saying that I'd like to see the components be a part of the product. Going and finding components takes time. Component authors can change jobs or leave a company.

    There are a set of users don't like open source. Our goal is not to code the internals of someone else's component. Our goal is to solve the problems of our customers or our startup.

    I'm not saying that this is a requirement. It is just a suggestion.

    PS. This is not a religious discussion of open source. If you want to discuss open source, please put that in a different thread.

  • JamesMontemagnoJamesMontemagno USForum Administrator, Xamarin Team, Developer Group Leader Xamurai

    @wallym I definitely hear where you are coming from. Just wanted to make sure you were aware of the resources. I have several initiatives and ideas that I am putting in place really soon around plugins that I think you will like and should address some of your concerns. Cheers

Sign In or Register to comment.