Pre-release: Xamarin.Forms 2.4.0.275-pre3

Posts

Starting from 2.3.5.233-pre1 the whole effects system don't work for android although it's work well for in UWP, Don't test it on iOS.
Here what i did:
Created PCL Xamarin.Forms app and modified MainPage.xaml

I tested 2.3.5.233-pre1, 2.3.5.235-pre2, 2.3.5.239-pre3, 2.3.5.255-pre5, 2.3.5.256-pre6 and last nightly build 2.3.6.122-nightly but still don't work, When I downgraded to 2.3.4.247 it's work well.
I noticed the app recognize the effect but can't make it attached so it didn't execute effect code at all, Thanks in advanced.

I have a big problem using listview with internet images. I reported to ffImageLoading but I believe this has nothing to do with this library, even if I use xamarin forms Image, it will occur. Basically when listview appears, it will download images from url for list items on the screen, usually there 3-4 items. If I use pre6 version, list gets frozen and app shows ANR on Android. This problem exist in stable release only when I scroll fast on the listview but with pre6, it occurs instantly without even scrolling. It is probably fast renders related. Does anybody else have seen this?

In pre6, Xamarin.Forms.Platform.Android.FastRenderers.ImageRenderer is missing:

protected Image Element { get; set; }

Other fast renderers still support Element to get the XF control. Is this intentionally removed from the ImageRenderer? If yes, is there a quick way to access to XF control when inheriting from fast ImageRenderer or do I need to store this vaulue when received in OnElementChanged()?

@PhilipGruebele said:@DavidOrtinau Disabling fast renderers by default make sense. But making them internal will prevent proper testing before you re-enable them (in my case I derive from each fast renderers).

The testing and feedback we've received while having the fast renderers in the pre-releases has made it apparent that we need to re-architect them a bit. Those architecture changes are going to be breaking changes for any subclasses of the fast renderers.

Once we put them in a stable release, we can no longer make breaking changes to them. So our options are:

Release the fast renderers to stable as they are; this requires that we support their current architecture going forward, and cannot make the architectural changes. It also means we have to support this iteration of them going forward.

Remove them from the stable release entirely; this allows us to re-architect them and release them later, but it means that no one gets their current performance benefits until the next stable release.

Make them internal and sealed for the time being; this means that users can still get the performance benefits of the fast renderers in their current form, but no one can create subclasses with a dependency which will break with the next stable release.

We've opted for 3.

The "internal/public" switch won't be flipped back out of nowhere; it'll happen in a pre-release for a subsequent version so that there will be time for testing.

We are very excited about Xamarin Forms for Mac. At the moment we are in the midst of a proof-of-concept and would like to interop to a 32-bit component. We followed the preview sample below and got it to work just fine (see link below).

However, if we go into the Mac Build settings and change the architecture from x86_64 to i386 we get an application crash on startup. The error specifically says that Xamarin.Mac is 64-bit and the application is 32-bit.

Anyone know if 32-bit Mac applications using Xamarin Forms will be supported?

@JoeManke said:
From my understanding, 2.3.5 has just been renamed 2.4, much like 1.5.2 was instead released as 2.0.

Was it? Good to know we have some precedent.

It's tricky b/c we want the version to reflect the content of the release adhering more or less to semantic versioning, but also don't want to introduce confusion by switching the name of the release at the last minute. We obviously are choosing the former.

This would be the greatest. I hate the other devs coming to my desk to look at the Mac when we want to use a real device for something.

I had it going on a version shortly after Evolve 2017 and it worked great. Then it disappeared from later releases, supposedly due to poor performance.

Personally I think Xamarin should not have retracted for performance. If they pulled things for poor performance we wouldn't have Android capability in Xamarin.Forms {laugh}

If it serves the customer needs that's up to the customer. I'd love to see this put back in and then leave it up to the customer to decide if it works well enough on their machines and network. It already exists - I'VE USED IT - all they have to do is put it back.

@DavidOrtinau We use the remote simulator for most things, it is just the occasional things need testing on real devices to make sure they perform as expected, or we want to use location in the field, etc.

@AdamMeaney said:@DavidOrtinau We use the remote simulator for most things, it is just the occasional things need testing on real devices to make sure they perform as expected, or we want to use location in the field, etc.

But remote simulator is for VS Enterprise users. So everyone below that is left in the cold.
Also, a simulator is single-instance versus every developer having a tablet.

@AdamMeaney said:@DavidOrtinau We use the remote simulator for most things, it is just the occasional things need testing on real devices to make sure they perform as expected, or we want to use location in the field, etc.

But remote simulator is for VS Enterprise users. So everyone below that is left in the cold.
Also, a simulator is single-instance versus every developer having a tablet.

The simulator is of limited use. For daily development in HTTPS it's pretty useless, developing against devices means at least you know how the app will work and behave.

Today I was hit by two exceptions. The first one is a TypeLoadException with message: > "Could not resolve type with token 010000f3 (from typeref, class/assembly SQLite.CreateTableResult, SQLite-net, Version=1.5.166.0, Culture=neutral, PublicKeyToken=null)"

The first one appeared immediately after updating to 2.4. It was solved by clearing the solution, the app built and ran fine.
Then I changed something unrelated in the code, rebuilt (simply, without clearing) and the second exception appeared. That, again, went away by clearing the solution. A minor annoyance, but I'm not sure what can cause it and if it will return or not.