The Device.StartTimer seems to be missing features and in need of improvement, so I am using some AdvancedTimer for now but it's an old 2015 assembly. Perhaps we just need some additional abstractions put around the Device.StartTimer so it's easier to use.
@Hopin said:
The Device.StartTimer seems to be missing features and in need of improvement, so I am using some AdvancedTimer for now but it's an old 2015 assembly. Perhaps we just need some additional abstractions put around the Device.StartTimer so it's easier to use.
Device.StartTimer is there. i am using it currently and works perfectly fine
Are there rough expected release dates for XF 3.5 and 4.0? (I understand they may slip)
The next feature update to one of my apps uses Bindeable Layouts from 3.5 and I have plans for a major rewrite once 4.0 is released. I have been using the prereleases for development but regressions in 3.5pre3 mean I can't release anything until it is stable.
Hello @DavidOrtinau,
I've been an early user of Xamarin.Forms (from the times of XLabs) that has just "restarted" using it after some time doing something else.
I am actually impressed by how little the Forms components have improved in terms of usability! Still no commands in Pages or in ListView, still no horizontal ListView, still no better way to handle images than ImageSource...
How is it possible that these extremely little things that can be fixed in a few hours haven't found their way in 3 major releases of X.Forms? In every project there are tons of classes to be added only to have little stupid functionalities (like the ImageResourceExtension to handle image sources in XAML! )
I will surely push all I can to the main repo once I complete my project but I really do not understand whats the strategy here.
Why are you wasting time on Shell, why you want to attract "new developers" if every time that you need to do something a little more complex it gets a mess? Why don't you focus on polishing what you have instead of adding more (of little interest IMHO)?
@Poz1 Agreed. Unfortunately, the team is making a lot of short-sighted decisions with respect to which direction to head. Issues on Github seem to be piling up at a higher rate than they are fixed. My biggest complaints right now are ListView and lack of 3rd-party tooling. Like you mentioned, XF cannot handle images properly, and I run into critical problems with FFImageLoading. Animations aren't as smooth as I'd like. The current implementation of Span is buggy and has performance problems. Even the good, old Grid has calculation problems with Auto heights. While I can find workarounds for small issues, I can't easily circumvent these without completely changing the UI.
@AdrianKnight The saddest part is that in almost a month no one even bothered to show that we may be seeing it wrong
Seems like just no one cares.
In these few days I was also able to appreciate that the Entry Control still does not uses TextInputLayout (Android), that we still have no CheckBox, that the Grid calculation are a total mess (as you said), that we have tons of properties that are apparently ignored or simply meaningless (!) and that most of the things that one were provided by external libraries are now old, and likely to be broken (as they should be).
When it all started for me, and we are talking of when we had padding only and no margin ( ) in Forms components, Xamarin was the new solution to all problems, that was still a lot incomplete and buggy because it was new.
The community started providing the missing functionality, I did NFCForms to allow devices to use NFC directly from Forms, but it was obvious that these basic feature had to be in the XamarinCore!
How can you believe to build a framework on libraries provided by people that share a piece of code that will probably not be ever maintained or updated?
Basically right now Xamarin (at least Forms) is almost the same of 2 years ago, maybe more.
So the question is, do you really want to waste your time building your future apps with it?
As I am now creating the nth "customrenderer" say: If I had done it full native I would probably written the same code, wasted much less time against Forms bugs and got a much more speedy app.
I am afraid this may be my last project written in Xamarin. I cannot stand it anymore.
@Poz1 said: @AdrianKnight The saddest part is that in almost a month no one even bothered to show that we may be seeing it wrong
Seems like just no one cares.
In these few days I was also able to appreciate that the Entry Control still does not uses TextInputLayout (Android), that we still have no CheckBox, that the Grid calculation are a total mess (as you said), that we have tons of properties that are apparently ignored or simply meaningless (!) and that most of the things that one were provided by external libraries are now old, and likely to be broken (as they should be).
When it all started for me, and we are talking of when we had padding only and no margin ( ) in Forms components, Xamarin was the new solution to all problems, that was still a lot incomplete and buggy because it was new.
The community started providing the missing functionality, I did NFCForms to allow devices to use NFC directly from Forms, but it was obvious that these basic feature had to be in the XamarinCore!
How can you believe to build a framework on libraries provided by people that share a piece of code that will probably not be ever maintained or updated?
Basically right now Xamarin (at least Forms) is almost the same of 2 years ago, maybe more.
So the question is, do you really want to waste your time building your future apps with it?
As I am now creating the nth "customrenderer" say: If I had done it full native I would probably written the same code, wasted much less time against Forms bugs and got a much more speedy app.
I am afraid this may be my last project written in Xamarin. I cannot stand it anymore.
Dunno yet, I will finish the current app and see.
Will try Flutter (but is it better?) and QT. Or just go Xamarin.Android and Xamarin.iOS. (But I think that I would go native at that point and stop bothering Xamarin at all)
It bothers me a lot. A LOT.
Because I have invested time, I now know C# and XAML pretty well and I know Xamarin.
But they need to change their "strategy" (which is by the way?) and start building a complete and usable framework. There is no other way for it to survive.
They can fool newcomers but truth always comes out.
@Poz1:
I agree with you...
As you wrote, I also have invested a lot of time in Xamarin over the last few years and see no (or only a litte bit) progress (.forms is far away to be a complete framework right now)
I would check out flutter, if I would find the time...
The paradox here is that we (in general) are able to produce good quality apps with Xamarin.Forms - some of us seem to find endless workarounds are needed, while others don't. Is it that the former are implementing more complete solutions while the latter are not going deep enough?
I've found Forms to be very productive, and haven't found show-stopping bugs.
This isn't a criticism of those who are frustrated and considering dropping Xamarin, just an observation. I agree that it's frustrating that bugs just don't seem to get fixed!
I think I am frustrated because I've been adding the same stupid things in my apps for too many years.
I am simply tired of having to rewrite always the same renderer in every app or to change my design to use similar components.
At the beginning it was okay because it was just born, but now it's been many years that a lot of basic things have been missing.
I don't know @JamesLavery, are you not tired of adding the famous "ImageResourceExtension" in every project to use ImageSource in XAML?
There are no major show-stopping bugs, its just that you have to wast so much time to do so stupid things (change color of switch, for example) that becomes irritating. And only because no one bothered to expose the little stupid property.
And at the end of the day you think: what is the direction they are taking? Why no one improves the controls? Should I continue doing my apps in Forms?
In addition to the bugs, there are many pending PRs that don't seem to be going anywhere. I also agree that most bugs don't get fixed (including the ones tagged with /blocker, /critical, and /high-impact). This could be explained by the fact that the team is probably currently busy with the 4.0 release but more importantly they have spread themselves out too thin with many things (iOS, Android, UWP, Tizen, WPF, and MacOS in addition to XAML, CollectionView, Shell, Material, etc.)
They could probably hire 15 new devs for $2M per annum and resolve issues at a faster rate. This kind of money is insignificant for a company the size of Microsoft - not to mention the ultimate goal for them is to attract as many developers as possible to Visual Studio and Azure.
Flutter is probably the best choice right now for cross platform, but that means we give up C#/.NET.
@AdrianKnight they have spread themselves out too thin
Agreed. Too much feature-creep in Xamarin.Forms. And they have a bad philosophy of not making breaking changes so technical debt just accumulates, and they keep adding things without getting existing features to a good level of quality. Too much of the mono philosophy. Bindings, css, shell, navigation... none of these are needed IMO.
That said most of the specific controls mentioned have actually been improved or work is well underway to improve them.
I really enjoy making apps using Xamarin.Forms and C#, and had no reason to look for other alternatives, but since the Xamarin Team is too quiet to basic questions as "the on-going support for UWP", to name just one, i am really considering to choose another cross-platform framework for my next App... Too much secrecy is not doing any good to the old good Xamarin...
I would like to see android app bundles in xamarins roadmap. This will be game changer for us. Currently if you need good performance and startup time, you must use aot and llvm but these increase you app size and we need to cut this down. App bundles seems to be only way to achieve it for xamarin. But I dont hear any interest on this theme.
@batmaci
There was/is a big interest here (performance ans startup) from the customer side and Xamarin has pinned this goal as major target for new releases of .forms. But - as mostly - not reached and now... silence (similar - e.g. - to the for years missing simple popup control).
It seems as all not trivial stuff find the way to the trashcan, but therefore it's worked on "rounded corners" and similar things...
It's a real shame...
I remember one or two year ago when they posted great plans to improve android performance a lot but then, things have changed. A lot of effort was put on things like css, shell, visual, previewer ecc...
It's great to have new, shiny, things but i think that stuff like Android performance and app size, hot reload, a full featured CollectionView, more control on gestures/transitions/scrolling effects are all basic things that should have been worked out before
Take the CollectionView for example: it's a really great control! But they sipped it without scrolling events, refreshview, swipe context commands... Wouldn't be better to just ship a finished, polished control and then move to another feature?
I'm going to throw in two cents here... First, add UWP (or whatever Microsoft is going to support for UX moving ahead) to the new shell thing or drop the shell thing. The 2019 roadmap seems so... timid? Especially in the context of all the pain points that keep surfacing over and over.
I don't understand why MS is alienating all these long-time MS-friendly developers. I know they want to sell Azure... but UX is the gateway to services, no?
Some real fundamental things missing from Xamarin Forms, which seem really simple but would make a huge difference to general app development:
Absolute layout with Landscape and Portrait bounds - Out of the box Xamarin Forms provides a horendous experience in designing applications to work in both landscape and portrait. Most sample apps are designed on phones where this isn't a problem, as soon as you put it on a tablet and display it landscape your application looks stupid. An easy and optimised way to provide different layouts in different orientations
Delayed Views - Initial feedback to our application was "responsiveness is slow" this was because on pushing a button we pushed a page which would call InitializeComponent and would take 0.5-1 seconds to render complicated views. To work around this we created a view that would be completely empty and hold a datatemplate that would start initialising as soon as the page was displayed - Yes this is probably slower overall but that initial feedback to show its doing something is far more important.
Page Animations - We actually ended up ditching Xamarin Forms page navigation all together, having a page snap in from nowhere gives a horrendous UX. We instead replaced it with RG Popup page simply for animations
Invisible views still layout - One thing we noticed was that eventhough a view was invisible (i.e. IsVibisle = false) the measure and draw was still happening (on android at least) commenting a complex view out (that was set to invisible) had a huge performance boost. We, therefore invented another delayed view to show the screens quicker and take the drawing hit at time when visibility changes on the view
All the points above are fundamental to xamarin forms but instead we are getting Shell and collectionviews - which are completely unimplemented on UWP making it useless for anyone looking to develop for all 3 platforms.
I guess the bottom line is this Xamarin.Forms needs more resources, which in turn means more money/investment
My understanding is that views with IsVisible false are not rendered.
Based on that I presume you are using XAML for your complicated views, but are you compiling them? If not, there is an initial inflation cost that must be paid regardless of whether a view is visible or not. Commenting out large sections will improve the inflation time, but isn't a true reflection on the cause of your issue.
We build our views in code, and they are instant. If we used XAML for our views and compiled them, performance would be the same.
@JohnH said:
My understanding is that views with IsVisible false are not rendered.
This would seem logical but my tests don't prove this at all.
I'm using XAML to construct my views, I've got compiled XAML turned on.
I've attached a view to prove my point which contains hundreds of labels. Construct this view and push it to the stack using:
var view = new VisibilityTest();
this.Navigation.PushAsync(view);
The above line of code took 5 and a half seconds on my device, regardless of whether you set IsVisible = True or false on the root layout.
This view also proves another point I mentioned
Delayed Views: pushing this view takes 5 seconds to initialise... 5 seconds for the user to wait for a page to appear!! obviously this is an extreme example but anything greater than half a second is bad UX, hence why we've used DelayedViews and datatemplates
Test out the View and let me know if you get the same 5 second delay to push this view even with isvisible = false
We have invented a control similar to this, the annoying this is that we've had to do our own research and invent this control. It should be out of the box and in all the samples as a design pattern
IsVisible=false views are rendered on android and uwp. I havent tested on ios but most probably also Somebody claimed that it is only working on UWP https://github.com/xamarin/Xamarin.Forms/issues/6536
But till 3.6 version It is not working. I have tested myself and it is there. You can simply check using bannerads, you will see that it will be refreshed frequently even it is isvisble false
@batmaci said:
IsVisible=false views are rendered on android and uwp. I havent tested on ios but most probably also Somebody claimed that it is only working on UWP https://github.com/xamarin/Xamarin.Forms/issues/6536
But till 3.6 version It is not working. I have tested myself and it is there. You can simply check using bannerads, you will see that it will be refreshed frequently even it is isvisble false
Hmm, maybe that is something resolved with the Android fast renderers which are now default in XF 4?
I've also found that an ImageView on Android with IsVisible = false (Legacy Renderers...not sure about Fast Renderers) will cause the Android Bitmap to be inflated using the full device's full screen size (even if the image was set to a smaller size) causing a large amount of memory to be consumed. This was found while profiling.
As a workaround, I implemented a ImageView custom renderer which will not set the ImageSource unless Visibility is true. This saves tons of memory and stopped OutOfMemoryErrors from being generated.
AbsoluteLayout has a unique anchor model whereby the anchor of the element is positioned relative to its element as the element is positioned relative to the layout when proportional positioning is used.
Unique is definitely the right word here, although I can think of a few others
I know that several people are concerned about UWP support. My suggestion would be delegating this responsibility to another team at Microsoft (if at all possible) so the Forms team can focus on iOS and Android first and foremost. This would be similar to how Tizen support is being handled today. While I understand the attractiveness of the idea of being able to develop for many platforms, most people who use Forms develop for iOS and Android, in my opinion, and these require a lot of work to do already.
Posts
The Device.StartTimer seems to be missing features and in need of improvement, so I am using some AdvancedTimer for now but it's an old 2015 assembly. Perhaps we just need some additional abstractions put around the Device.StartTimer so it's easier to use.
Device.StartTimer is there. i am using it currently and works perfectly fine
https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap
The next feature update to one of my apps uses Bindeable Layouts from 3.5 and I have plans for a major rewrite once 4.0 is released. I have been using the prereleases for development but regressions in 3.5pre3 mean I can't release anything until it is stable.
v3.5 was released a few hours after I posted that question. Now that's what I call service!
Hello @DavidOrtinau,
I've been an early user of Xamarin.Forms (from the times of XLabs) that has just "restarted" using it after some time doing something else.
I am actually impressed by how little the Forms components have improved in terms of usability! Still no commands in Pages or in ListView, still no horizontal ListView, still no better way to handle images than ImageSource...
How is it possible that these extremely little things that can be fixed in a few hours haven't found their way in 3 major releases of X.Forms? In every project there are tons of classes to be added only to have little stupid functionalities (like the ImageResourceExtension to handle image sources in XAML! )
I will surely push all I can to the main repo once I complete my project but I really do not understand whats the strategy here.
Why are you wasting time on Shell, why you want to attract "new developers" if every time that you need to do something a little more complex it gets a mess? Why don't you focus on polishing what you have instead of adding more (of little interest IMHO)?
Bentornato Alessandro!
Grazie
@Poz1 Agreed. Unfortunately, the team is making a lot of short-sighted decisions with respect to which direction to head. Issues on Github seem to be piling up at a higher rate than they are fixed. My biggest complaints right now are
ListViewand lack of 3rd-party tooling. Like you mentioned, XF cannot handle images properly, and I run into critical problems withFFImageLoading. Animations aren't as smooth as I'd like. The current implementation ofSpanis buggy and has performance problems. Even the good, oldGridhas calculation problems withAutoheights. While I can find workarounds for small issues, I can't easily circumvent these without completely changing the UI.@AdrianKnight The saddest part is that in almost a month no one even bothered to show that we may be seeing it wrong
Seems like just no one cares.
In these few days I was also able to appreciate that the Entry Control still does not uses TextInputLayout (Android), that we still have no CheckBox, that the Grid calculation are a total mess (as you said), that we have tons of properties that are apparently ignored or simply meaningless (!) and that most of the things that one were provided by external libraries are now old, and likely to be broken (as they should be).
When it all started for me, and we are talking of when we had padding only and no margin (
) in Forms components, Xamarin was the new solution to all problems, that was still a lot incomplete and buggy because it was new.
The community started providing the missing functionality, I did NFCForms to allow devices to use NFC directly from Forms, but it was obvious that these basic feature had to be in the XamarinCore!
How can you believe to build a framework on libraries provided by people that share a piece of code that will probably not be ever maintained or updated?
Basically right now Xamarin (at least Forms) is almost the same of 2 years ago, maybe more.
So the question is, do you really want to waste your time building your future apps with it?
As I am now creating the nth "customrenderer" say: If I had done it full native I would probably written the same code, wasted much less time against Forms bugs and got a much more speedy app.
I am afraid this may be my last project written in Xamarin. I cannot stand it anymore.
Which is the second choice?
@AlessandroCaliaro
Dunno yet, I will finish the current app and see.
Will try Flutter (but is it better?) and QT. Or just go Xamarin.Android and Xamarin.iOS. (But I think that I would go native at that point and stop bothering Xamarin at all)
It bothers me a lot. A LOT.
Because I have invested time, I now know C# and XAML pretty well and I know Xamarin.
But they need to change their "strategy" (which is by the way?) and start building a complete and usable framework. There is no other way for it to survive.
They can fool newcomers but truth always comes out.
@Poz1:
I agree with you...
As you wrote, I also have invested a lot of time in Xamarin over the last few years and see no (or only a litte bit) progress (.forms is far away to be a complete framework right now)
I would check out flutter, if I would find the time...
The paradox here is that we (in general) are able to produce good quality apps with Xamarin.Forms - some of us seem to find endless workarounds are needed, while others don't. Is it that the former are implementing more complete solutions while the latter are not going deep enough?
I've found Forms to be very productive, and haven't found show-stopping bugs.
This isn't a criticism of those who are frustrated and considering dropping Xamarin, just an observation. I agree that it's frustrating that bugs just don't seem to get fixed!
I think I am frustrated because I've been adding the same stupid things in my apps for too many years.
I am simply tired of having to rewrite always the same renderer in every app or to change my design to use similar components.
At the beginning it was okay because it was just born, but now it's been many years that a lot of basic things have been missing.
I don't know @JamesLavery, are you not tired of adding the famous "ImageResourceExtension" in every project to use ImageSource in XAML?
There are no major show-stopping bugs, its just that you have to wast so much time to do so stupid things (change color of switch, for example) that becomes irritating. And only because no one bothered to expose the little stupid property.
And at the end of the day you think: what is the direction they are taking? Why no one improves the controls? Should I continue doing my apps in Forms?
In addition to the bugs, there are many pending PRs that don't seem to be going anywhere. I also agree that most bugs don't get fixed (including the ones tagged with /blocker, /critical, and /high-impact). This could be explained by the fact that the team is probably currently busy with the 4.0 release but more importantly they have spread themselves out too thin with many things (iOS, Android, UWP, Tizen, WPF, and MacOS in addition to XAML, CollectionView, Shell, Material, etc.)
They could probably hire 15 new devs for $2M per annum and resolve issues at a faster rate. This kind of money is insignificant for a company the size of Microsoft - not to mention the ultimate goal for them is to attract as many developers as possible to Visual Studio and Azure.
Flutter is probably the best choice right now for cross platform, but that means we give up C#/.NET.
Agreed. Too much feature-creep in Xamarin.Forms. And they have a bad philosophy of not making breaking changes so technical debt just accumulates, and they keep adding things without getting existing features to a good level of quality. Too much of the mono philosophy. Bindings, css, shell, navigation... none of these are needed IMO.
That said most of the specific controls mentioned have actually been improved or work is well underway to improve them.
ListView: being replaced with CollectionView.
Checkbox: in progress https://github.com/xamarin/Xamarin.Forms/pull/4369
Switch color: this can be changed since 3.1 apparently
@CharlesRoddie said
Totally agreed on above.
I believe I should have posted this here as no one from Xamarin Team has replied or It might have been missed by Xamarin Team...
https://forums.xamarin.com/discussion/156412/xamarin-forms-support-general-discussion
I really enjoy making apps using Xamarin.Forms and C#, and had no reason to look for other alternatives, but since the Xamarin Team is too quiet to basic questions as "the on-going support for UWP", to name just one, i am really considering to choose another cross-platform framework for my next App... Too much secrecy is not doing any good to the old good Xamarin...
I would like to see android app bundles in xamarins roadmap. This will be game changer for us. Currently if you need good performance and startup time, you must use aot and llvm but these increase you app size and we need to cut this down. App bundles seems to be only way to achieve it for xamarin. But I dont hear any interest on this theme.
@batmaci
There was/is a big interest here (performance ans startup) from the customer side and Xamarin has pinned this goal as major target for new releases of .forms. But - as mostly - not reached and now... silence (similar - e.g. - to the for years missing simple popup control).
It seems as all not trivial stuff find the way to the trashcan, but therefore it's worked on "rounded corners" and similar things...
It's a real shame...
I remember one or two year ago when they posted great plans to improve android performance a lot but then, things have changed. A lot of effort was put on things like css, shell, visual, previewer ecc...
It's great to have new, shiny, things but i think that stuff like Android performance and app size, hot reload, a full featured CollectionView, more control on gestures/transitions/scrolling effects are all basic things that should have been worked out before
Take the CollectionView for example: it's a really great control! But they sipped it without scrolling events, refreshview, swipe context commands... Wouldn't be better to just ship a finished, polished control and then move to another feature?
@GiampaoloGabba At least they're not calling the CollectionView stable yet.
uooops, you are right! i was sure that CollectionView was part of the first 4.0 stable but is still in preview
I'm going to throw in two cents here... First, add UWP (or whatever Microsoft is going to support for UX moving ahead) to the new shell thing or drop the shell thing. The 2019 roadmap seems so... timid? Especially in the context of all the pain points that keep surfacing over and over.
I don't understand why MS is alienating all these long-time MS-friendly developers. I know they want to sell Azure... but UX is the gateway to services, no?
Been working with Xamarin.Forms for 5 years
Some real fundamental things missing from Xamarin Forms, which seem really simple but would make a huge difference to general app development:
Absolute layout with Landscape and Portrait bounds - Out of the box Xamarin Forms provides a horendous experience in designing applications to work in both landscape and portrait. Most sample apps are designed on phones where this isn't a problem, as soon as you put it on a tablet and display it landscape your application looks stupid. An easy and optimised way to provide different layouts in different orientations
Delayed Views - Initial feedback to our application was "responsiveness is slow" this was because on pushing a button we pushed a page which would call InitializeComponent and would take 0.5-1 seconds to render complicated views. To work around this we created a view that would be completely empty and hold a datatemplate that would start initialising as soon as the page was displayed - Yes this is probably slower overall but that initial feedback to show its doing something is far more important.
Page Animations - We actually ended up ditching Xamarin Forms page navigation all together, having a page snap in from nowhere gives a horrendous UX. We instead replaced it with RG Popup page simply for animations
Invisible views still layout - One thing we noticed was that eventhough a view was invisible (i.e. IsVibisle = false) the measure and draw was still happening (on android at least) commenting a complex view out (that was set to invisible) had a huge performance boost. We, therefore invented another delayed view to show the screens quicker and take the drawing hit at time when visibility changes on the view
All the points above are fundamental to xamarin forms but instead we are getting Shell and collectionviews - which are completely unimplemented on UWP making it useless for anyone looking to develop for all 3 platforms.
I guess the bottom line is this Xamarin.Forms needs more resources, which in turn means more money/investment
thanks for sharing
My understanding is that views with IsVisible false are not rendered.
Based on that I presume you are using XAML for your complicated views, but are you compiling them? If not, there is an initial inflation cost that must be paid regardless of whether a view is visible or not. Commenting out large sections will improve the inflation time, but isn't a true reflection on the cause of your issue.
We build our views in code, and they are instant. If we used XAML for our views and compiled them, performance would be the same.
This would seem logical but my tests don't prove this at all.
I'm using XAML to construct my views, I've got compiled XAML turned on.
I've attached a view to prove my point which contains hundreds of labels. Construct this view and push it to the stack using:
The above line of code took 5 and a half seconds on my device, regardless of whether you set IsVisible = True or false on the root layout.
This view also proves another point I mentioned
Delayed Views: pushing this view takes 5 seconds to initialise... 5 seconds for the user to wait for a page to appear!! obviously this is an extreme example but anything greater than half a second is bad UX, hence why we've used DelayedViews and datatemplates
Test out the View and let me know if you get the same 5 second delay to push this view even with isvisible = false
@JKay
I cant test that right now, but could you try disabling the XAML compiler for that view and see how much slower it is?
@JKay i think you should open an issue on Github for this, attaching your test project, a view with IsVisible=False should not trigger a layout.
However we can already manage Delayed views with a little effort. This awesome blog post explain how, i have already tried it and is working very well: https://www.sharpnado.com/xamarin-forms-lazyview-boost-your-app-reactivity-and-startup-time/
Sure, it would be better to have such a function inside the core, instead of questionable things like css, shell, ecc...
@JohnH With XAMLC turned off it takes 9.5 seconds so XAML C is definitely doing something
@GiampaoloGabba I currently dont have time to file a github issue. The most annoying thing is that this is really simple.
My view is:
And it takes about 5 seconds to push that page.
As this is
IsVisible=FalseI would expect it to be instant.We have invented a control similar to this, the annoying this is that we've had to do our own research and invent this control. It should be out of the box and in all the samples as a design pattern
IsVisible=false views are rendered on android and uwp. I havent tested on ios but most probably also Somebody claimed that it is only working on UWP https://github.com/xamarin/Xamarin.Forms/issues/6536
But till 3.6 version It is not working. I have tested myself and it is there. You can simply check using bannerads, you will see that it will be refreshed frequently even it is isvisble false
Hmm, maybe that is something resolved with the Android fast renderers which are now default in XF 4?
Some extra feedback on the subject of performance...
Label padding: https://github.com/xamarin/Xamarin.Forms/pull/6299 would be a great feature to merge. The work has already been done.
The number of times I have
Every view added is a performance slowdown
I've been meaning to post this...
I've also found that an ImageView on Android with
IsVisible = false(Legacy Renderers...not sure about Fast Renderers) will cause the Android Bitmap to be inflated using the full device's full screen size (even if the image was set to a smaller size) causing a large amount of memory to be consumed. This was found while profiling.As a workaround, I implemented a ImageView custom renderer which will not set the ImageSource unless Visibility is true. This saves tons of memory and stopped OutOfMemoryErrors from being generated.
@AnthonyRamirez I think it'd be better to report this on Github so the issue gets tracked.
On the topic of orientation aware mobile apps one of the most useful ways to do this is AbsoluteLayout coupled with Visual State manager.
The one problem is that
AbsoluteLayoutlogic is so complicated with its moving anchor point.Can anyone decrypt this documentation: https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/layouts/absolute-layout#proportional-layouts
Unique is definitely the right word here, although I can think of a few others
I know that several people are concerned about UWP support. My suggestion would be delegating this responsibility to another team at Microsoft (if at all possible) so the Forms team can focus on iOS and Android first and foremost. This would be similar to how Tizen support is being handled today. While I understand the attractiveness of the idea of being able to develop for many platforms, most people who use Forms develop for iOS and Android, in my opinion, and these require a lot of work to do already.
@AdrianKnight do they have separate team for Tizen support?