09-08 11:18:12.383 F/ ( 7465): * Assertion at /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mono/metadata/sgen-tarjan-bridge.c:1140, condition 'xref_count == xref_index' not met 09-08 11:18:12.383 F/libc ( 7465): Fatal signal 6 (SIGABRT), code -6 in tid 7465 (<app name removed>.Droid)
Does anyone have an idea what this means?
Some additional info: I'm using the latest XF 2.4 preview, the phone is a Huawei P9 Lite with Android 7.0 and I can't reproduce the crash.
09-08 11:18:12.383 F/ ( 7465): * Assertion at /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mono/metadata/sgen-tarjan-bridge.c:1140, condition 'xref_count == xref_index' not met 09-08 11:18:12.383 F/libc ( 7465): Fatal signal 6 (SIGABRT), code -6 in tid 7465 (<app name removed>.Droid)
Does anyone have an idea what this means?
Some additional info: I'm using the latest XF 2.4 preview, the phone is a Huawei P9 Lite with Android 7.0 and I can't reproduce the crash.
MONO_GC_PARAMS=bridge-implementation=old
This will cause the app to use the previous GC bridge.
As I see, that it's crashing at sgen-tarjan-bridge.c:1140.
I faced occasionally System.ObjectDisposedException: Cannot access a disposed object at default implementation, but haven't, when I've switched to old implementation of GC.
Hi guys!
I have a problem with 2.4.0.269-pre2 on Android, when application goes to the background (for example by pressing home button) and returns to the foreground. To prevent reloading all application, I use the following technic in MainActivity
sMyApp created just once, and used in the next calls of OnCreate. It prevents total application reloading.
It works with 2.3.4.270, but doesn’t work with 2.4.0.269-pre2 – now I just see the white screen, instead of my form. Is it a bug, or something changed in 2.4.0.269-pre2? Can anybody explain the situation?
@NamyslawSzymaniuk I don't have an exact date to give at this moment, but we're planning to get a 2.4.0-pre3 together for release at some point soon. Once something more specific is determined, we'll let you know.
@LGMaestrelli We're aiming to focus strictly on any remaining known regressions that exist as of 2.4.0-pre2 at this point in time. There is some work going on which may address that bug, but I cannot guarantee a fix being in 2.4.0-pre3.
@Pavel.Ivanov If you believe that the issue is specific to a regression in Forms (especially if you can identify the version between 2.3.4 and 2.4.0-pre2 where the behavior breaks), please file a bug with a reproduction project for us to look at as soon as possible.
@EmmanuelOche said:
2.4.0.269-pre2. Android ListView does not respond to tapped or Selected events. Context Action works but not Item Tapped or Item Selected
Hey, @PaulDiPietro, I note the -pre3 release item, "[UWP] Picker dropdown should not open when focused (#1134)" Yanking the .Focus "open-the-picklist" capability from UWP means we're back to inconsistency in Forms behavior across the supported platforms. I understand the reason regarding control focus issues with non-touch interfaces. But what's the solution? Really need a way to programmatically open a picker's picklist. (Preferably one that works the same way across supported platforms.) This is a real problem for those of us also deploying onto touch-based UWP systems.
@FactoryOptimizr The manner in which UWP handles ComboBox focus with the dropdown (at least via the Forms end of things) is tricky, and it ultimately made more sense to leave the behavior the same as a native UWP application as opposed to changing the behavior outright (as calling Focus on the ComboBox is different from setting IsDropDownOpen). Prior to the decision to simply revert the behavior, a PR was open that modified the function to prevent tabbing through controls opening the dropdown, but even that fix was still somewhat imperfect (the picker could act oddly when alt-tabbing in and out of the application, if I recall), which led to reverting it.
There is no perfect solution I have available at the moment, unfortunately. It's possible to do something along the lines of what the PR does with a custom control, but the the behavior being ideal can't be guaranteed in that case. If we were to ever approach something like this again, it would almost assuredly be through a platform specific behavior just to leave things as they are by default.
@FactoryOptimizr@PaulDiPietro I think the simplest way to approach it for now would be to make a custom renderer on the developer side... just change the behavior back for those who need it. I can post the code if ya need it @FactoryOptimizr .
@PaulDiPietro, why not just a separate method -- .OpenPickList() or some such? That'd be an explicit action, a fresh start for anyone who wants to use it, and wouldn't mess up anyone who's counting on the current behavior of .Focus().
@FactoryOptimizr That would be a good option as well if its on all the different OS's. If you want the exact same code as the old renderer, I can link ya over to it? Did you experience any issues with the old renderer that was reverted? We experienced quite a bit but if your users were happy with it, then the old one might work for ya?
Anyone else seeing issues with XAML compilation enabled?
Keep getting the "Value cannot be null. Parameter: instruction" error when compiling. It worked fine before upgrading to pre3, so not sure what's up with that.
So how does one go about changing our Listviews from: <x:Arguments> <ListViewCachingStrategy> <OnPlatform x:TypeArguments="x:String"> <On Platform="iOS">RecycleElement</On> <On Platform="Android">RetainElement</On> </OnPlatform> </ListViewCachingStrategy> </x:Arguments>
To set the ListViewChacingStrat? If I don't have it set like this, it crashes on 2.3 XF
I have run 2.4.0pre2 for a while and I have seen in Android:
SetFlags restart OnCreate in Android, that was solved yesterday by PR
While using fast renderers I still get this Button problem on API 19 "no method with name='getElevation' signature='()F' in class Lcom/xamarin/forms/platform/android/FormsViewGroup;" from Android.Platform+DefaultRenderer.GetChildDrawingOrder
@RSH said:
So how does one go about changing our Listviews from: <x:Arguments> <ListViewCachingStrategy> <OnPlatform x:TypeArguments="x:String"> <On Platform="iOS">RecycleElement</On> <On Platform="Android">RetainElement</On> </OnPlatform> </ListViewCachingStrategy> </x:Arguments>
To set the ListViewChacingStrat? If I don't have it set like this, it crashes on 2.3 XF
I made my own control for that:
internal class FixBugListView : ListView
{
public FixBugListView() : base(Device.RuntimePlatform == Device.iOS ? ListViewCachingStrategy.RecycleElement: ListViewCachingStrategy.RetainElement) { }
}
@BradChase.2654, I definitely be happy start with the old renderer code. So busy lately that I really didn't have time to test...was waiting for the final 2.4 release, and had hoped the issues would be cleared up by then. Given that this has been yanked from 2.4, the old renderer would be a good place to start if you can direct me to the code. By the way, will this work for ALL pickers, i.e., Picker, DatePicker and TimePicker? Thanks!
@PaulDiPietro, still think a new Forms method call to open the picklist is the best and least impacting option. 2.4.1, perhaps???
In reality you could just do what the old renderer does and attach to the Control... Control.GotFocus += ControlOnGotFocus;
And then do what Xamarin did and: Control.IsDropDownOpen = true;
You can do the same for the DatePicker and TimePicker just inherit from their renderers and when the Control is set, just attach to the GotFocus events and force the drop down. I warn you, be ready for some very strange side effects! Good luck.
@DavidOrtinau - Could somebody take another look at https://bugzilla.xamarin.com/show_bug.cgi?id=57432 please. It's was claimed resolved fixed in 2.3.5-pre6, but I noticed that somebody has commented on the bug to say it still is not quite right. If that's the case, I assume as there are no further comments that it has not been changed again for the pre-release of 2.4.0
I have upgraded my project from Xamarin.Forms stable and PCL to Xamarin.Forms pre3 and .NETStandard 1.4. Since then, my statusbar on Android has changed to gray.
I guess this happened because of the android:windowBackground in my styles.xml which has the same hex code color of #FFF5F5F5. Nevertheless, this did work before the upgrade to pre3.
My style.xml files:
<resources>
<style name="MyTheme" parent="MyTheme.Base">
</style>
<!-- Base theme applied no matter what API -->
<style name="MyTheme.Base" parent="Theme.AppCompat.Light.NoActionBar">
<item name="windowNoTitle">true</item>
<item name="windowActionBar">false</item>
<item name="colorPrimary">@color/primary</item>
<item name="colorPrimaryDark">@color/primaryDark</item>
<item name="colorAccent">@color/accent</item>
<item name="windowActionModeOverlay">true</item>
<item name="android:datePickerDialogTheme">@style/AppCompatDialogStyle</item>
<item name="android:windowBackground">@color/window_background</item>
</style>
</resources>
<resources>
<!--
Base application theme for API 21+. This theme completely replaces
MyTheme from BOTH res/values/styles.xml on API 21+ devices.
-->
<style name="MyTheme" parent="MyTheme.Base">
<item name="android:windowDrawsSystemBarBackgrounds">true</item>
<item name="android:statusBarColor">@android:color/transparent</item>
</style>
</resources>
The NavigationDrawer of my MasterDetail layout should be drawn beneath the statusbar, and the statusbar should be slightly transparent, like the Material Design guidelines. I think this worked before the upgrade to pre-release.
@c-z I also have the issue with the status bar after upgrading to forms 2.4.0 and like @Rafa said, removing the transparent statusBarColor partially fixes the issue. Unfortunately, the flyout master page is now moved down below the status bar and is no longer drawn on top of the status bar like most modern material design apps.
@LentoMan said: @c-z I also have the issue with the status bar after upgrading to forms 2.4.0 and like @Rafa said, removing the transparent statusBarColor partially fixes the issue. Unfortunately, the flyout master page is now moved down below the status bar and is no longer drawn on top of the status bar like most modern material design apps.
@c-z I don't know if it is reported, but it probably should be.
I think the problem was that the implementation in Xamarin Forms was a hacky way to fix the status bar material design for pre-Lollipop devices, but it caused other issues and the hack was removed.
I tried to do the same in forms by extending the MasterDetailPageRenderer and doing a really dirty override hijack of one of the virtual properties which is accessed in the constructor to call SetFitsSystemWindows(true). While it did fix the white StatusBar color issue, the Xamarin Forms layout renderers did not agree and added additional space above the detail page.
[assembly: ExportRenderer(typeof(MasterDetailPage), typeof(MaterialDesignMasterDetailPageRenderer))]
namespace MobileClient.Droid.Renderers
{
public class MaterialDesignMasterDetailPageRenderer : MasterDetailPageRenderer
{
public override DescendantFocusability DescendantFocusability
{
get {
return base.DescendantFocusability;
}
set
{
SetFitsSystemWindows(true); // Le hijack ;)
base.DescendantFocusability = value;
}
}
}
}
@LentoMan said: @c-z I don't know if it is reported, but it probably should be.
I think the problem was that the implementation in Xamarin Forms was a hacky way to fix the status bar material design for pre-Lollipop devices, but it caused other issues and the hack was removed.
I tried to do the same in forms by extending the MasterDetailPageRenderer and doing a really dirty override hijack of one of the virtual properties which is accessed in the constructor to call SetFitsSystemWindows(true). While it did fix the white StatusBar color issue, the Xamarin Forms layout renderers did not agree and added additional space above the detail page.
[assembly: ExportRenderer(typeof(MasterDetailPage), typeof(MaterialDesignMasterDetailPageRenderer))]
namespace MobileClient.Droid.Renderers
{
public class MaterialDesignMasterDetailPageRenderer : MasterDetailPageRenderer
{
public override DescendantFocusability DescendantFocusability
{
get {
return base.DescendantFocusability;
}
set
{
SetFitsSystemWindows(true); // Le hijack ;)
base.DescendantFocusability = value;
}
}
}
}
Could you please give me an example how you achieved it with android:fitsSystemWindows="true"? I added it both to my navigation_view.axml and drawer_header.axml files, but I still get the white statusbar.
@c-z
The reason the statusbar is white is because the Android Theme you are using in your style.xml is a Light theme. That means white will be the background color shining through when the statusbar is set to transparent and the fitsSystemWindows code in the DrawerLayout constructor that sets the statusbar color doesn't run.
To make statusbar work you also need this in your AppTheme in style.xml: (and obviously a colorPrimaryDark in your colors.xml) <item name="colorPrimaryDark">@color/primaryDark</item> <item name="android:statusBarColor">@android:color/transparent</item>
Note that statusBarColor is only supported from API 21, you should put the statusBarColor value in your values-v21/style.xml if f you are supporting anything below minSdkVersion 21.
Here are instructions for Android Studio, but you should be able to reproduce the same in a Xamarin Android project.
Works in Android Studio (2.3.3)
Create new project (target lolipop (21) or later)
Use Navigation Drawer Activity template
Finish
Run in emulator (Should look the same as Xamarin Forms with the Flyout/Master (NavigationView) expanding below the statusbar rather than covering it transparently.
Edit styles.xml, under the AppTheme section, add: <item name="android:statusBarColor">@android:color/transparent</item>
Run again in emulator (Expanded flyout should now cover statusbar with transparent effect)
Remove android:fitsSystemWindows="true" from the DrawerLayout in activity_main.xml and you get the white border again
You can also experiment with editing your build.gradle for the app module, if you change the targetSdkVersion (and minSdkVersion) to anything below 21 the StatusBar will become black.
I enabled fast renderers and tested everything looks working in my app but sometimes in my exception logs, I am seeing exception below. anybody has idea what it is?
System.NotSupportedExceptionUnable to activate instance of type Xamarin.Forms.Platform.Android.FastRenderers.ImageRenderer from native handle 0xbe906ccc (key_handle 0xb441462).
at Java.Interop.TypeManager.CreateInstance (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer, System.Type targetType) [0x0017d] in <c82a099136944d8aa96281cf061cbc12>:0
at Java.Lang.Object.GetObject (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer, System.Type type) [0x000b9] in <c82a099136944d8aa96281cf061cbc12>:0
at Java.Lang.Object._GetObject[T] (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer) [0x00017] in <c82a099136944d8aa96281cf061cbc12>:0
at Java.Lang.Object.GetObject[T] (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer) [0x00000] in <c82a099136944d8aa96281cf061cbc12>:0
at Java.Lang.Object.GetObject[T] (System.IntPtr jnienv, System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer) [0x00006] in <c82a099136944d8aa96281cf061cbc12>:0
at Android.Views.View.n_Invalidate (System.IntPtr jnienv, System.IntPtr native__this) [0x00000] in <c82a099136944d8aa96281cf061cbc12>:0
at (wrapper dynamic-method) System.Object:2f8a28a4-0526-49bf-90a9-298fa9a42034 (intptr,intptr)
System.MissingMethodExceptionNo constructor found for Xamarin.Forms.Platform.Android.FastRenderers.ImageRenderer::.ctor(System.IntPtr, Android.Runtime.JniHandleOwnership)
at Java.Interop.TypeManager.CreateProxy (System.Type type, System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer) [0x00054] in <c82a099136944d8aa96281cf061cbc12>:0
at Java.Interop.TypeManager.CreateInstance (System.IntPtr handle, Android.Runtime.JniHandleOwnership transfer, System.Type targetType) [0x00111] in <c82a099136944d8aa96281cf061cbc12>:0
Java.Lang.ErrorException of type 'Java.Interop.JavaLocationException' was thrown.
Java.Lang.Error: Exception of type 'Java.Lang.Error' was thrown.
--- End of managed Java.Lang.Error stack trace ---
java.lang.Error: Java callstack:
at md57018357d52b54713cd814fbd5262dd1f.ImageRenderer.n_invalidate(Native Method)
at md57018357d52b54713cd814fbd5262dd1f.ImageRenderer.invalidate(ImageRenderer.java:54)
at android.widget.ImageView.invalidateDrawable(ImageView.java:248)
at android.graphics.drawable.Drawable.invalidateSelf(Drawable.java:385)
at android.graphics.drawable.Drawable.setVisible(Drawable.java:764)
at android.widget.ImageView.onDetachedFromWindow(ImageView.java:1487)
at android.view.View.dispatchDetachedFromWindow(View.java:14648)
at android.view.ViewGroup.removeAllViewsInLayout(ViewGroup.java:4790)
at android.view.ViewGroup.removeAllViews(ViewGroup.java:4736)
at md5270abb39e60627f0f200893b490a1ade.FragmentContainer.n_onDestroyView(Native Method)
at md5270abb39e60627f0f200893b490a1ade.FragmentContainer.onDestroyView(FragmentContainer.java:59)
at android.support.v4.app.Fragment.performDestroyView(Fragment.java:2480)
at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1422)
at android.support.v4.app.FragmentManagerImpl.moveFragmentToExpectedState(FragmentManager.java:1569)
at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1636)
at android.support.v4.app.FragmentManagerImpl.dispatchDestroyView(FragmentManager.java:3020)
at android.support.v4.app.Fragment.performDestroyView(Fragment.java:2476)
at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1422)
at android.support.v4.app.FragmentManagerImpl.moveFragmentToExpectedState(FragmentManager.java:1569)
at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1636)
at android.support.v4.app.FragmentManagerImpl.dispatchDestroy(FragmentManager.java:3028)
at android.support.v4.app.FragmentController.dispatchDestroy(FragmentController.java:262)
at android.support.v4.app.FragmentActivity.onDestroy(FragmentActivity.java:390)
at android.support.v7.app.AppCompatActivity.onDestroy(AppCompatActivity.java:209)
at md5874faab2802fcbafca06095cc637d65d.MainActivity.n_onDestroy(Native Method)
at md5874faab2802fcbafca06095cc637d65d.MainActivity.onDestroy(MainActivity.java:65)
at android.app.Activity.performDestroy(Activity.java:6456)
at android.app.Instrumentation.callActivityOnDestroy(Instrumentation.java:1143)
at android.app.ActivityThread.performDestroyActivity(ActivityThread.java:3917)
at android.app.ActivityThread.handleDestroyActivity(ActivityThread.java:3948)
at android.app.ActivityThread.access$1500(ActivityThread.java:154)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1445)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:234)
at android.app.ActivityThread.main(ActivityThread.java:5526)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
Another thing I noticed was it saying Cannot cast 17.5 to Int I am setting the FontSize of a Label to 17.5 which according to the API documentation should be fine but it seemed to be logging errors, has anything changed here?
Posts
Today my app crashed with this:
09-08 11:18:12.383 F/ ( 7465): * Assertion at /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mono/metadata/sgen-tarjan-bridge.c:1140, condition 'xref_count == xref_index' not met 09-08 11:18:12.383 F/libc ( 7465): Fatal signal 6 (SIGABRT), code -6 in tid 7465 (<app name removed>.Droid)Does anyone have an idea what this means?
Some additional info: I'm using the latest XF 2.4 preview, the phone is a Huawei P9 Lite with Android 7.0 and I can't reproduce the crash.
Maybe - https://developer.xamarin.com/releases/android/xamarin.android_7/xamarin.android_7.4/
As I see, that it's crashing at sgen-tarjan-bridge.c:1140.
I faced occasionally System.ObjectDisposedException: Cannot access a disposed object at default implementation, but haven't, when I've switched to old implementation of GC.
Again (https://forums.xamarin.com/discussion/comment/294819/#Comment_294819) - @DavidOrtinau any planned date for ** 2.4.0-pre3** release?
We are blocked because of this bug, in order to release new version of our app.
I hope that this bug will be fixed in 2.4.0-pre3 too.
It is crashing on every single iOS user.
Hi guys!
I have a problem with 2.4.0.269-pre2 on Android, when application goes to the background (for example by pressing home button) and returns to the foreground. To prevent reloading all application, I use the following technic in MainActivity
sMyApp created just once, and used in the next calls of OnCreate. It prevents total application reloading.
It works with 2.3.4.270, but doesn’t work with 2.4.0.269-pre2 – now I just see the white screen, instead of my form. Is it a bug, or something changed in 2.4.0.269-pre2? Can anybody explain the situation?
@NamyslawSzymaniuk I don't have an exact date to give at this moment, but we're planning to get a 2.4.0-pre3 together for release at some point soon. Once something more specific is determined, we'll let you know.
@LGMaestrelli We're aiming to focus strictly on any remaining known regressions that exist as of 2.4.0-pre2 at this point in time. There is some work going on which may address that bug, but I cannot guarantee a fix being in 2.4.0-pre3.
@Pavel.Ivanov If you believe that the issue is specific to a regression in Forms (especially if you can identify the version between 2.3.4 and 2.4.0-pre2 where the behavior breaks), please file a bug with a reproduction project for us to look at as soon as possible.
@PaulDiPietro
But this will be fixed in 2.4.0 stable, right?
We can not tell to the users to keep trying to open the app until it works.
Or there is some workaround to this? Anything...
2.4.0.269-pre2. Android ListView does not respond to tapped or Selected events. Context Action works but not Item Tapped or Item Selected
Corresponding bugzilla item is already showing fixed. Let's wait for pre3
https://bugzilla.xamarin.com/show_bug.cgi?id=58833
We've just pushed 2.4.0.275-pre3 to NuGet. Please continue to provide feedback here. Thanks!
Hey, @PaulDiPietro, I note the -pre3 release item,
"[UWP] Picker dropdown should not open when focused (#1134)"Yanking the .Focus "open-the-picklist" capability from UWP means we're back to inconsistency in Forms behavior across the supported platforms. I understand the reason regarding control focus issues with non-touch interfaces. But what's the solution? Really need a way to programmatically open a picker's picklist. (Preferably one that works the same way across supported platforms.) This is a real problem for those of us also deploying onto touch-based UWP systems.@FactoryOptimizr The manner in which UWP handles
ComboBoxfocus with the dropdown (at least via the Forms end of things) is tricky, and it ultimately made more sense to leave the behavior the same as a native UWP application as opposed to changing the behavior outright (as callingFocuson theComboBoxis different from settingIsDropDownOpen). Prior to the decision to simply revert the behavior, a PR was open that modified the function to prevent tabbing through controls opening the dropdown, but even that fix was still somewhat imperfect (the picker could act oddly when alt-tabbing in and out of the application, if I recall), which led to reverting it.There is no perfect solution I have available at the moment, unfortunately. It's possible to do something along the lines of what the PR does with a custom control, but the the behavior being ideal can't be guaranteed in that case. If we were to ever approach something like this again, it would almost assuredly be through a platform specific behavior just to leave things as they are by default.
@FactoryOptimizr @PaulDiPietro I think the simplest way to approach it for now would be to make a custom renderer on the developer side... just change the behavior back for those who need it. I can post the code if ya need it @FactoryOptimizr .
@BradChase.2654, that'd be awesome! Many thanks!
@PaulDiPietro, why not just a separate method -- .OpenPickList() or some such? That'd be an explicit action, a fresh start for anyone who wants to use it, and wouldn't mess up anyone who's counting on the current behavior of .Focus().
@FactoryOptimizr That would be a good option as well if its on all the different OS's. If you want the exact same code as the old renderer, I can link ya over to it? Did you experience any issues with the old renderer that was reverted? We experienced quite a bit but if your users were happy with it, then the old one might work for ya?
Anyone else seeing issues with XAML compilation enabled?
Keep getting the "Value cannot be null. Parameter: instruction" error when compiling. It worked fine before upgrading to pre3, so not sure what's up with that.
So how does one go about changing our Listviews from:
<x:Arguments> <ListViewCachingStrategy> <OnPlatform x:TypeArguments="x:String"> <On Platform="iOS">RecycleElement</On> <On Platform="Android">RetainElement</On> </OnPlatform> </ListViewCachingStrategy> </x:Arguments>To set the ListViewChacingStrat? If I don't have it set like this, it crashes on 2.3 XF
I have run 2.4.0pre2 for a while and I have seen in Android:
Please get this fix into 2.4 stable:
https://github.com/xamarin/Xamarin.Forms/pull/1147
[Edit] You need to update the release notes:
"Behavior change: Calling Focus on a Picker on WinRT/UWP will now open the drop down."is reverted with this:
"[UWP] Picker dropdown should not open when focused" (#1134)I made my own control for that:
@BradChase.2654, I definitely be happy start with the old renderer code. So busy lately that I really didn't have time to test...was waiting for the final 2.4 release, and had hoped the issues would be cleared up by then. Given that this has been yanked from 2.4, the old renderer would be a good place to start if you can direct me to the code. By the way, will this work for ALL pickers, i.e., Picker, DatePicker and TimePicker? Thanks!
@PaulDiPietro, still think a new Forms method call to open the picklist is the best and least impacting option. 2.4.1, perhaps???
@FactoryOptimizr Sure, its this revision: https://github.com/xamarin/Xamarin.Forms/blob/04d034057c9743712d826c290bf9b1f2a0dd7924/Xamarin.Forms.Platform.WinRT/PickerRenderer.cs
In reality you could just do what the old renderer does and attach to the Control... Control.GotFocus += ControlOnGotFocus;
And then do what Xamarin did and: Control.IsDropDownOpen = true;
You can do the same for the DatePicker and TimePicker just inherit from their renderers and when the Control is set, just attach to the GotFocus events and force the drop down. I warn you, be ready for some very strange side effects!
Good luck.
@DavidOrtinau - Could somebody take another look at https://bugzilla.xamarin.com/show_bug.cgi?id=57432 please. It's was claimed resolved fixed in 2.3.5-pre6, but I noticed that somebody has commented on the bug to say it still is not quite right. If that's the case, I assume as there are no further comments that it has not been changed again for the pre-release of 2.4.0
I have upgraded my project from Xamarin.Forms stable and PCL to Xamarin.Forms pre3 and .NETStandard 1.4. Since then, my statusbar on Android has changed to gray.
I guess this happened because of the android:windowBackground in my styles.xml which has the same hex code color of #FFF5F5F5. Nevertheless, this did work before the upgrade to pre3.
My style.xml files:
The NavigationDrawer of my MasterDetail layout should be drawn beneath the statusbar, and the statusbar should be slightly transparent, like the Material Design guidelines. I think this worked before the upgrade to pre-release.
@c-z
Same issue here.
Remove: @android:color/transparent in my case at least, the status bar returned to its color.
@Rafa That fixed the issue for me. Do you know if a bug report is written up for it?
I do not know
@c-z I also have the issue with the status bar after upgrading to forms 2.4.0 and like @Rafa said, removing the transparent statusBarColor partially fixes the issue. Unfortunately, the flyout master page is now moved down below the status bar and is no longer drawn on top of the status bar like most modern material design apps.
I have a strong feeling it is related to this commit:
https://github.com/xamarin/Xamarin.Forms/commit/1e1785016aef68fb36907d5b7662eda2aa403825
Yes, that could be possible. Do you know if there's been a bug reported for this issue?
@c-z I don't know if it is reported, but it probably should be.
I think the problem was that the implementation in Xamarin Forms was a hacky way to fix the status bar material design for pre-Lollipop devices, but it caused other issues and the hack was removed.
All you need to do on a non forms project is to set fitsSystemWindows="true" on the DrawerLayout and the NavigationView (master) and it fixes the statusbar color and material design for you:
https://android.googlesource.com/platform/frameworks/support/+/android-7.0.0_r34/v4/java/android/support/v4/widget/DrawerLayout.java#396
I tried to do the same in forms by extending the MasterDetailPageRenderer and doing a really dirty override hijack of one of the virtual properties which is accessed in the constructor to call SetFitsSystemWindows(true). While it did fix the white StatusBar color issue, the Xamarin Forms layout renderers did not agree and added additional space above the detail page.
-deleted
Could you please give me an example how you achieved it with android:fitsSystemWindows="true"? I added it both to my navigation_view.axml and drawer_header.axml files, but I still get the white statusbar.
navigation_view.axml:
drawer_header.axml:
@c-z
The reason the statusbar is white is because the Android Theme you are using in your style.xml is a Light theme. That means white will be the background color shining through when the statusbar is set to transparent and the fitsSystemWindows code in the DrawerLayout constructor that sets the statusbar color doesn't run.
To make statusbar work you also need this in your AppTheme in style.xml: (and obviously a colorPrimaryDark in your colors.xml)
<item name="colorPrimaryDark">@color/primaryDark</item> <item name="android:statusBarColor">@android:color/transparent</item>Note that statusBarColor is only supported from API 21, you should put the statusBarColor value in your values-v21/style.xml if f you are supporting anything below minSdkVersion 21.
Here are instructions for Android Studio, but you should be able to reproduce the same in a Xamarin Android project.
Works in Android Studio (2.3.3)
Edit styles.xml, under the AppTheme section, add:
<item name="android:statusBarColor">@android:color/transparent</item>Run again in emulator (Expanded flyout should now cover statusbar with transparent effect)
You can also experiment with editing your build.gradle for the app module, if you change the targetSdkVersion (and minSdkVersion) to anything below 21 the StatusBar will become black.
I enabled fast renderers and tested everything looks working in my app but sometimes in my exception logs, I am seeing exception below. anybody has idea what it is?
tried the pre-release but none of my pages loaded. In the logs I could see reference to it didn't recognise my Xaml Extension.
Only tested on Android
I use an extension to set Keyboard flags in XAML from here: https://stackoverflow.com/a/37786618/2987066
Another thing I noticed was it saying
Cannot cast 17.5 to IntI am setting the FontSize of a Label to 17.5 which according to the API documentation should be fine but it seemed to be logging errors, has anything changed here?