locked
Xamarin.Forms 1.3.3 Released RRS feed

  • Question

  • User352 posted

    Enhancements

    • Deeply nested Grid performance enhanced

    Bug Fixes

    • Bug 21606 - Page Title not updating when set in OnAppearing() Method the second time page is displayed. (iOS)
    • Bug 20798 - ListView TextCell.DetailProperty only wraps on Android
    • Bug 24777 - jobject must not be IntPtr.Zero exception when replacing Content of a Page
    • Bug 26214 - On Android, InputTransparent=true does not work with ScrollView
    • Bug 22673 - Initially hidden BoxView when made visible does not render (but does take up space in the UI)
    • Bug 25703 - Webview waits to load the content until webviews on previous pages are loaded
    • Bug 26139 - Navigation.RemovePage() still shows the back button on Android
    • Bug 26304 - System.ArgumentNullException thrown when moving items in an ObservableCollection that is observed by a ListView
    • Bug 26064 - ListView, ImageCell and disabled source cache and same image url leads to degraded performance
    • Bug 26121 - Android ListView.ScrollTo doesn't work when ListView inside TabbedPage
    • Bug 26501 - Context Actions cause views to be hidden on iOS after re-use
    • Bug 23585 - [Android] ListView not updated when ObservableCollection is modified

    Other Fixes

    • [Core] CarouselPage now has more informative error when used without Children
    • [Android] BoldItalic text now works as expected
    • [Android] HeaderCells no longer tapable in TableView
    • [Android] Fix NullReferenceException when re-using ListView on second page
    • [iOS] SearchBar cancel button hides if there is nothing to clear
    • [iOS] EntryCell Completed event fires twice
    • [iOS] Fix potential crash with Editor inside of a ScrollView
    • [iOS] Fix potential crash when ScrollView is inside of ViewCell
    • [iOS] Fix issue where ContextActions could end up out of order
    • [WP] Keyboard action for search does not match other platforms
    • [Xaml] Text as content property now properly trims whitespace
    • [Xaml] Duplicate x:Name's throw a more informative error now
    • [Xaml] Better error on Type mismatch for
    Monday, February 9, 2015 7:16 PM

All replies

  • User66766 posted

    @TheRealJasonSmith excellent work you and the forms team are doing!

    Monday, February 9, 2015 7:39 PM
  • User74299 posted

    Thank you for the recent updates and the transparency.

    Tuesday, February 10, 2015 3:18 AM
  • User88968 posted

    Hi Guys, after I updated my app solution from 1.2 to 1.3.3 I'm getting the following error when I try to execute: "MonoTouch.Foundation.MonoTouchException: Objective-C exception thrown. Name: NSInvalidArgumentException Reason: -[_NSDictionaryI _setObject:forKey:]: unrecognized selector sent to instance 0x7c7244f0".

    Any one can help me on this? Thanks a lot.

    Tuesday, February 10, 2015 11:20 AM
  • User95387 posted

    @aaragao Did you get this error cleared up? I'm having the exact same issue.

    Would love to hear from Xamarin on this one...

    Tuesday, February 10, 2015 4:54 PM
  • User63571 posted

    Yay - with master/detail on tablet the menu closes itself again! :)

    Tuesday, February 10, 2015 5:30 PM
  • User95387 posted

    @DanielNelson.9924 What did you need to change on the master/detail to fix this issue?

    Tuesday, February 10, 2015 5:36 PM
  • User37816 posted

    Same here! Actually the exception came for me at my appdelegate's last line according to the debugger:

    return base.FinishedLaunching(app, options);

    After Googleing, I've found @ChrisExigent's other forum post (https://forums.xamarin.com/discussion/32653/masterdetailpage-causing-exception-after-upgrading-to-1-3-3?) That led me to the root cause of setting the BarTextColor property on a NavigationPage when I'm creating the detail view for my MasterDetailPage. If I set the BarTextColor, I get the aforementioned exception.

    If I simply comment that line, my app works as before the 1.3.3 upgrade.

    @TheRealJasonSmith I would be very interested to hear how you guys are testing new releases before they come out in the 'stable' branch. Either these breaking changes should be documented properly, or you guys really need to do more thorough testing before releasing these updates. I often feel we are guinea pigs on the stable branch and things are breaking which were working previously, which is not acceptable and sustainable at all.

    By the way, the issue at the heart of the matter I believe is that you are creating an NSDictionary somewhere instead of an NSMutableDictionary, and you try to add elements to the NSDictionary after initialization; which is not possible, hence the 'unrecognized selector' error message.

    Tuesday, February 10, 2015 10:14 PM
  • User352 posted

    @GaborFuredi every release goes through a week in pre-release and a week in QA. Passes a battery of regression tests and is tested against a large internal test suite. Whats interesting is better 1.3.2 and 1.3.3 no change was made to the BarTextColor code path. I am looking into the issue right now.

    We are not creating an NSDictionary anywhere in forms, I don't want to speculate too much on the cause of the issue at this time. I will post back shortly with an update.

    Tuesday, February 10, 2015 10:23 PM
  • User37816 posted

    Thanks for the quick response. Interestingly enough, commenting out the BarTextColor property only helped on the simulator, on the device I'm still getting the exception. Now I'm in the process of hunting.

    Tuesday, February 10, 2015 10:25 PM
  • User352 posted

    I just validated this code runs fine for me on device:

            var searchBar = new SearchBar ();
            var stack = new StackLayout {Children = {searchBar }};
            MainPage = new MasterDetailPage () {
                Master = new ContentPage {Title = "Master"},
                Detail = new NavigationPage (new ContentPage {Content = stack, Title = "Purple"}) {
                    BarTextColor = Color.Purple
                }
            };
    

    Is there something else I need to do to reproduce the issue? What device are you testing on? What simulator?

    Tuesday, February 10, 2015 10:27 PM
  • User352 posted

    I have further validated the code runs on sim (I rarely test on sim because the iOS 8 sims are so buggy its not worth it)

    Tuesday, February 10, 2015 10:32 PM
  • User37816 posted

    In the meantime I've verified the bug on the device as well, it just turned out on the device I was on a different code path which had another BarTextColor as well, not the same one I've commented out in the use-case I've tested on the simulator.

    After commenting out the BarTextColor there as well, now the app runs on the device properly.

    The simulator is 8.1, the device is iPhone 5 with iOS 8.1.3.

    I will create project for you to reproduce.

    Tuesday, February 10, 2015 10:52 PM
  • User37816 posted

    @TheRealJasonSmith I've got another lead. I've just created the repro project, uploaded here: https://www.dropbox.com/s/66dxfewqt9tusbt/onethreethree.zip?dl=0

    All I needed to do is to modify the navigationbar with the native iOS API, then BarTextColor starts causing crash. I've put the following into the AppDelegate in the repro project now:

    UINavigationBar.Appearance.SetTitleTextAttributes(new UITextAttributes{Font = UIFont.SystemFontOfSize(16),
                    TextColor=UIColor.Yellow});
    

    Crash is reproducible both in the simulator and on the device.

    Please note, this crash did not happen before 1.3.3.

    Tuesday, February 10, 2015 11:06 PM
  • User352 posted

    thank you @GaborFuredi please give me a couple to dig in to this.

    Tuesday, February 10, 2015 11:08 PM
  • User352 posted

    @GaborFuredi I have reproduced the crash and will create a regression test case for it. Testing this particular mix of UIAppearance and Forms was not previously being done (hence how it managed to break). Unfortunately its simply not possible to test the billions of ways to combine all the base API's and Forms API's together, but we do our best. I will get this fixed in 1.3.4 as its a regression from 1.3.3. In general, we don't recommend setting the same values from both UIAppearance and Forms if you can avoid it.

    Edit- And as a bit of post mortem, the bug was introduced when we had to port to Xamarin.iOS for XF 1.3.1. This is due to the API we were using going away and the new API seemingly having different semantics in some fashion I have not quite figured out yet.

    Tuesday, February 10, 2015 11:21 PM
  • User37816 posted

    @TheRealJasonSmith Thanks, I appreciate the swift response. I would say using UIAppearance to customize the navbar is pretty common in real life apps though as not everything is accessible via the Forms equivalent. Also as I mentioned above, I'm quite sure this is an NSDictionary - NSMutableDictionary issue somewhere.

    EDIT: I've just seen your suggestion to avoid setting the same values from both UIAppearance and Forms. I've tried to only set the Font from the UIAppearance instead of setting both the Font and the TextColor, but there's no difference in the result.

    @ChrisExigent , @aaragao are you guys also customizing the UINavigationBar with native APIs just like I do?

    Tuesday, February 10, 2015 11:32 PM
  • User352 posted

    @GaborFuredi you are right yes :) It turns out that by setting UIAppearance the API we were using to grab attributes from the theme is now returing a non-mutable dictionary. I have resolved the issue and will get it into 1.3.4-pre2

    Tuesday, February 10, 2015 11:54 PM
  • User37816 posted

    @TheRealJasonSmith Excellent, thank you :)

    Wednesday, February 11, 2015 12:02 AM
  • User91635 posted

    Hey, I'm currently getting a problem as of updating to 1.3.3. When build for the android store, i get:

    /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets: Error: Error executing task LinkAssemblies: error XA2006: Reference to metadata item 'System.Void Android.Widget.AbsListView::SetSelectionFromTop(System.Int32,System.Int32)' (defined in 'Xamarin.Forms.Platform.Android, Version=1.3.3.0, Culture=neutral, PublicKeyToken=null') from 'Xamarin.Forms.Platform.Android, Version=1.3.3.0, Culture=neutral, PublicKeyToken=null' could not be resolved. (Axon.Droid)

    Works fine for debug. Build target is 4.4.

    Wednesday, February 11, 2015 12:32 AM
  • User352 posted

    @KrisWatts make sure your TargetFrameworkVersion is set to API 21, as well as your compile version, make sure your minimum is at least 14 and that you have the latest Android SDK installed. Xamarin.Forms requires the latest Android build sdk to work.

    Wednesday, February 11, 2015 12:42 AM
  • User2148 posted

    @TheRealJasonSmith When I've updated the SDK and Xamarin Studio, now I've this error in RELEASE mode

    D:\Documenti\software\CSharpApp\ACaliaro\Crossware\Geco\Geco\packages\Fody.1.27.0\build\Fody.targets(5,5): Error MSB4044: all'attività "Fody.WeavingTask" non è stato assegnato un valore per il parametro obbligatorio "DefineConstants". (MSB4044) (Geco)

    TargetFramework is "latestInstalled 5.0" MinimumAndroidVersion is 4.1 Api level 16

    I've opened a Bug in Bugzilla

    https://bugzilla.xamarin.com/show_bug.cgi?id=26930

    Try to remove and reinstall fody package but nothing change

    I can't build the apk...

    Alessandro

    Wednesday, February 11, 2015 6:50 AM
  • User352 posted

    I would need to see your release build, but it looks like Fody requires a for the of your active build config. Make sure all your build configs have this, its possible during the upgrade XS somehow re-wrote your .csproj file to remove it?

    Either way this is not strictly speaking an incompatibility with Forms, but I hope get the changes to your csproj made that Fody seems to need. (Try adding a RELEASE define like you have a DEBUG define)

    Wednesday, February 11, 2015 8:13 AM
  • User2148 posted

    @TheRealJasonSmith thanks for the answer. What you mean by "see your release build". Do I have to attach a file? Or a screenshot? I don't understand "looks like Fody requires a for the of your...". Requires what? No, no one have re-wrote the csproj. "Try adding a RELEASE define like you have a DEBUG define". Where do I have to add this define?

    Sorry for these questions.... Alessandro

    Wednesday, February 11, 2015 10:25 AM
  • User352 posted

    @AlessandroCaliaro send my your csproj file please

    Wednesday, February 11, 2015 10:40 AM
  • User2148 posted

    this is it

    Wednesday, February 11, 2015 12:26 PM
  • User352 posted

    Here try this: https://gist.github.com/jassmith/ea804c83f9ca3029d9a3

    Wednesday, February 11, 2015 12:32 PM
  • User68622 posted

    Is there a detail change log for each version of Xamarin Forms. I am trying to work out if any controls have new properties and when they came in.

    Also can you tell me what this obsolete tag mean on the Xamarin.Forms.Label.Font Property

    [System.Obsolete("Please use the Font attributes which are on the class itself. Obsoleted in v1.3.0")]
    public Font Font { get; set; }
    

    I am working on the XLabs project and need to know if enhancements made there are now baked in to the latest releases.

    Thanks Nicholas

    Wednesday, February 11, 2015 3:36 PM
  • User8854 posted

    ToolbarItems do not display on Device (iPhone 4S, iOs 8.1)

    Development market : 7.0

    Wednesday, February 11, 2015 3:52 PM
  • User8854 posted

    This is the code.

    `var drawer = new ToolbarItem () { Text = "drawer", Icon = Device.OnPlatform ("Toolbar/drawer.png", "drawer.png", "drawer.png"), Priority = 0 }; drawer.Clicked += async (sender, e) => await Navigation.PushModalAsync (new MenuPage ());

            var join = new ToolbarItem () {
                Text = "join",
                Icon = Device.OnPlatform<string> ("Toolbar/join.png", "join.png", "join.png"),
            };
            join.Clicked += async (sender, e) => {
                var result = await App.BarCodeService.Read ();
                if (result.Success) {
                    await App.DialogService.AlertAsync (String.Format (
                        "Bar Code: {0} - Type: {1}",
                        result.Code,
                        result.Format
                    ));
                } else {
                    await App.Notificator.Notify (Toasts.Forms.Plugin.Abstractions.ToastNotificationType.Error, 
                        "Error", "No se pudo obtener la Cámara", TimeSpan.FromSeconds (2));
                }
            };
    
            var create = new ToolbarItem () {
                Text = "create",
                Icon = Device.OnPlatform<string> ("Toolbar/add.png", "add.png", "add.png"),
                Priority = 2
            };
            create.Clicked += async (sender, e) => await Navigation.PushModalAsync (new MenuPage ());
    
            ToolbarItems.Add (drawer);
            ToolbarItems.Add (join);
            ToolbarItems.Add (create);`
    

    Is not working on device just on the Simulator.

    Wednesday, February 11, 2015 4:12 PM
  • User8854 posted

    Oh, there is something with icon. When I remove the Icon property it shows perfectly but without icon.

    Also Toast plugin is not showing the images.

    Wednesday, February 11, 2015 4:25 PM
  • User352 posted

    @NicholasRogoff we did not add any new API this release. We will specifically call out new/changed API in release notes if there is any. That obsolete tag basically means instead of using Label.Font, use Label.FontSize/FontAttributes/FontFamily.

    @DavidTavarez are you sure your icon is ending up inside your app bundle? We have seen users having issues with this lately. Unfortunately this is not really a Forms specific thing, however the iOS team is aware of the issue.

    Wednesday, February 11, 2015 4:54 PM
  • User95387 posted

    @GaborFuredi @TheRealJasonSmith changing the color of the UINavigationBar is fundamental. Still shaking my head as to why this broke.

    Wednesday, February 11, 2015 5:18 PM
  • User352 posted

    @ChrisExigent it was broken because we didn't have a regression test that tested setting both at the same time? I know it must seem trivial to test every possible combination of forms and non-forms APIs, but it really isn't practical. We do however do our best to make sure that when something like this happens a new regression test is entered. This issue was made worse by the Xamarin.iOS Unified API changes, which were the cause of the incompatibility to begin with (we had to switch to a new API that had slightly different semantics but we didn't realize that at the time of the switch).

    Im truly sorry this has disappointed you, I feel we have reacted in an extremely fast manner as soon as it was raised to my attention. If there is anything else I can do please let me know.

    Wednesday, February 11, 2015 5:49 PM
  • User11072 posted

    From what I've seen the 1.3.x series has been a great improvement in the stability of the library. It's to the point where we are recommending it for more situations to our clients. The library is coming into place nicely and becoming more predictable. Also the third party and community tooling and support is starting to hit critical mass.

    I've got to hand it to @TheRealJasonSmith , since the beginning of the year he appears to have been focusing on bug fixes and stabilization and making the product very nice to use. He's got a very small team and if you read what he's doing process wise here; he's making the right moves for release stabilization, particularly around test/unit testing and regression control.

    It will still take some time to settle down so expect that there will be some regressions (which be the way, as a user of the library I am able to control by making decisions on when to hold off and when to get the newer versions). With a couple week iteration cycle and a small team there will probably always be some level of churn but the product is maturing nicely.

    Thursday, February 12, 2015 3:01 PM
  • User95387 posted

    @KevinFord @TheRealJasonSmith Xamarin without a doubt is doing great things with their product. My issue however is with every release there are issues that cause me to spend days to fix. I paid real money for this product and I am building real apps for real consumers, that rely the product. With every release there are major setbacks. I expect more from Xamarin. I dont think this is too much to ask. With the recent update to 1.3 and the corresponding issues that were found not only in the library but Visual Studio as well, its very disappointing.

    Friday, February 13, 2015 5:10 PM
  • User352 posted

    Did you figure out your issue with 1.3.4? Do you still need support? I know the support team is in touch with you, but we can directly touch bases if need be to resolve whatever issues your app is having. As far as I can tell you have not replied to our last attempt to help you?

    Friday, February 13, 2015 6:04 PM
  • User6349 posted

    I also wanted to chime in here and say that I jumped into the Xamarin.Forms 1.3.x release and have been very impressed with it. Much appreciation and respect to the @TheRealJasonSmith and the Xamarin.Forms team. It's just incredibly awesome what you have done and it is great to be able to start developing real applications that have meaning and value. This hasn't been the case since Silverlight5 (which, if you're counting at home, is 4 years "removed" from this April!).

    My only question here is the use of the async pattern in some of the interfaces that have changed since Xamarin.Forms 1.2.x. I know async is awesomely better than what we used to have, but once you introduce async into your codebase, you end up with zombie async codebase that ends up being async "all the way down."

    This is just a consideration and something I just want to throw out there. I know I am probably in the minority, but seeing "async" and "Task<>" (and also the "MethodNameAsync" convention, just in case you couldn't already guess it's async. :P ) as implementation details on interfaces makes design noisier and (again, IMO) harder to look at/read.

    The alternate obvious consideration is to keep interfaces synchronous but then wrap them in a Task at the point of usage.

    There might obviously be a consideration here that I am unaware of, so take it for what it's worth. :)

    Also (and much more importantly!), I am concerned about platform integration moving forward, as it appears that in order to extend Xamarin.Forms to another platform (WPF or HTML5, for instance), that a lot of functionality and integration points are marked as internal. I am curious on why this is and if this is going to be addressed relatively soon. There are also things such as the TargetPlatform enumeration that make it seem like there are just a finite number of platforms that Xamarin.Forms is intended to run on... which is concerning. :/

    Anyways, that's really about it. Again, I am so appreciative of the work and vision done on this project and the progress that has been made, especially considering the team and the tasks at hand!!!

    Saturday, February 14, 2015 3:49 PM
  • User35206 posted

    Im truly sorry this has disappointed you, I feel we have reacted in an extremely fast manner as soon as it was raised to my attention. If there is anything else I can do please let me know.

    @TheRealJasonSmith From what I've seen in the thread you were very responsive and worked on the issue with the user until it was resolved.

    As software developers, we must understand the impossibility of testing every possible API combination, I'm with you on that.

    I guess the other user's frustration was with 'essential' feature broken, not the matter it was handled.

    Either way, know that there are others who appreciate your work and work of your colleagues on the Forms team. I am pleasantly surprised by the number of issues fixed and new features implemented by such a small team.

    Yes, we're seeing regressions and new bugs created all the time but I think this is simple to fix - for me personally, 1.3 is more or less feature complete, now just work on fixing bugs and regressions and your user base happiness will dramatically increase.

    Saturday, February 14, 2015 4:04 PM
  • User352 posted

    @MichaelDeMond the TargetPlatform enumeration will be expanded as we add more platforms. So yeah, dont dep on that thing being the same size forever. As for the internal parts, its just we have not yet had a chance to vet those API's as best we can for backwards compat and usefulness. Rather than be stuck with something we think might have to change we marked it internal so we could change it before we mark it public.

    We fully intend to remove all, ALL, internal APIs. We have already started this with the IViewController series of interfaces, and are going to continue working through those. The platform interfaces will be next.

    @DrazenDotlic thank you for the kind words, the entire team really appreciates it :)

    Saturday, February 14, 2015 7:05 PM
  • User6349 posted

    Thanks @TheRealJasonSmith for your answer, and for engaging your users! Especially on a weekend. :) I know you guys are super busy, so it's always great to hear from you and to see you active in the forums.

    That's awesome to hear about your intent with platform integration. Looking forward to see how you implement this.

    My comment about TargetPlatform enumeration was more along the lines of making it more of an entity/class as a profile domain entity than an enumeration. That way, you can make as many as you want and provide all sorts of properties on it instead of switch-casing enums everywhere (messier code). (You can imagine a Xamarin.Forms.Platform.CurrentProfile singleton describing the current platform that Xamarin.Forms is running under, along with all of its capabilities and supporting information). Obviously, the point here is that if some 3rd party extends Xamarin with a new platform, it won't be dependent on updating that enumeration, recompiling/packaging and deploying another nuget release.

    But, I understand that this is only v1.0 and you have to start somewhere. Getting internals out of platform implementations is much higher up on the importance/priority factor. :) Thanks again!

    Saturday, February 14, 2015 7:20 PM
  • User6349 posted

    Man, you guys got in Attached Properties and everything! Just incredible.

    Thank you thank you thank you!

    I can't say it enough. And you will probably hear it a few more times, too, so get ready. :P In fact, I have a crazy thought to make a simple first app called "Thank You Xamarin.Forms Team" that pushes templated kudos to Twitter/Facebook. Might be a first good app to build, methinks. :)

    It's SO NICE to build in Xaml/C# again and have all the intellisense and awesomeness of ReSharper as well. But most importantly knowing that the work being done will be capable of running on BILLIONS(!!!) of devices. It's like being in 2010/2011 again -- BUT EVEN BETTER!

    Thank you thank you thank you! (There it is again, OOPS!)

    Monday, February 16, 2015 1:10 PM
  • User102024 posted

    webview in the iOS looks like this (attach file) but only in the second tab. The first tab have a webview and it works fine. (android works all fine) The bug is fix on this version ?!

    Monday, February 16, 2015 3:24 PM
  • User14244 posted

    Just noticed that WindowsPhone DisplayActionSheet does not await and returns null right away before a user takes any action.

    Monday, February 16, 2015 3:59 PM
  • User69837 posted

    @breps, have you reported a bug at http://bugzilla.xamarin.com

    Monday, February 16, 2015 9:03 PM
  • User14244 posted

    Not yet I have not had the time. I ended up creating my own version of ActionSheet.

    I will try to submit one tonight.

    Monday, February 16, 2015 9:32 PM
  • User14244 posted

    bug report submitted: https://bugzilla.xamarin.com/show_bug.cgi?id=27119

    Tuesday, February 17, 2015 3:01 AM
  • User352 posted

    @breps I am not able to reproduce the issue in 1.3.4

    Please try out todays release and if you still have it let me know.

    Tuesday, February 17, 2015 3:40 PM