* Some basics to get started
* more renderers
* Fix titlebar color
* More shell stuff working
* Hacked some more UI in
* Fix null ref issue
* Move renderer registration outside common code (for now)
* Re-write of the renderers to better use a cleaner UWP approach
* Moved functionality around, bug fixesetc
* Added null check
* Added null-check on appearance and use default colors as fallback
* Handle change in flyout behavior to correctly turn the flyout on/off
* Handle the TabBarIsVisible property
* code formatting
* Ensure FlyoutHeader isn't show if the app starts up with a minimal pane
* Throw if used on versions lower than Windows 10 1809
* Added null-check for when ShellContent isn't set
* Support tabs in FlyoutItems with Display AsMultipleItems by using the generated FlyoutGroupings instead
* Improve pane behavior and styling
* Undo Android change used during testing
* Fix platform support check
* Use FileImageSourcePathConverter on NavigationViewItem instead of a custom control (so I deleted ShellNavigationViewItemRenderer which is no longer needed).
Ensure `FileImageSourcePathConverter` won't throw if it didn't get a FileImageSource.
Move the flyout data templates into a resource so they can be overridden and compiled.
* Delete renamed file
* Use a resource instead of parsing a string template
* Handle search box property changes
* Update page title on property change
* Update bottombar when shellitems change
* Guard against API usage not present
* Platform check comments
* Fix problem running in release mode (use Bindable to generate XamlMetadata
* Trigger rebind of menu items source when collection changes
* Added support for Toolbar
* Fix searchbox behavior (still lacks expand/collapse feature)
* Add overload for defining the navigation transition
* Use different navigation transitions based on navigatin direction
* Hides header with show / hide nav command
* collapses header area on hide nav
* Move to use WinUI
* Fix runtime issues after merge.
* - rebase fixes
* - rebase fixes
* - fix spaces/tabs
* - flags, hide apis, delete assembly info
* - set flag on UWP CG
* - expose renderer creations and make them all public
* - formatting fixes
* - address PR comments
* - fix header so it's full width and swappable
XamlC is currently enabled for most Xamarin.Forms projects in `Debug`
and `Release` configurations. It enables faster startup/runtime
performance, XAML-syntax checking at build time--both quiet useful!
However, there is a build-time cost to using XamlC: each assembly is
loaded via Mono.Cecil, IL generated, and saved back to disk as an
additional step after Rosyln has compiled the assembly.
The proposal would be to add a new experimental MSBuild property, that
can be enabled for `Debug` mode such as:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<!-- ... -->
<XFXamlCValidateOnly>True</XFXamlCValidateOnly>
</PropertyGroup>
This would do the following:
* `OptimizeIL` is skipped.
* Assemblies are analyzed, but no changes written to disk.
* No symbols are loaded via Mono.Cecil, we don't need them if we
aren't writing back to disk!
This will improve build performance, and we don't lose the build-time
error checking for XAML.
Down the road, we could consider moving the MSBuild property to be the
default for `Debug` builds or change the Xamarin templates. I think it
would be wise to require developers to opt-in to try this out.
~~ Results ~~
I tested this change by building the ControlGallery after changing one
line of XAML:
msbuild Xamarin.Forms.ControlGallery.Android\Xamarin.Forms.ControlGallery.Android.csproj /clp:performancesummary /p:XFXamlCValidateOnly=True
Before:
1979 ms XamlCTask 1 calls
After:
923 ms XamlCTask 1 calls
I *only* tested `Debug` builds.
Right, so it's faster. But let's keep the entire developer loop in
mind, how much slower is startup?
Before:
09-05 14:37:32.274 1169 1192 I ActivityManager: Displayed AndroidControlGallery.AndroidControlGallery/md546303760447087909496d02dc7b17ae8.Activity1: +3s890ms
09-05 14:38:30.178 1169 1192 I ActivityManager: Displayed AndroidControlGallery.AndroidControlGallery/md546303760447087909496d02dc7b17ae8.Activity1: +3s848ms
09-05 14:38:40.300 1169 1192 I ActivityManager: Displayed AndroidControlGallery.AndroidControlGallery/md546303760447087909496d02dc7b17ae8.Activity1: +3s848ms
After:
09-05 14:40:38.512 1169 1192 I ActivityManager: Displayed AndroidControlGallery.AndroidControlGallery/md546303760447087909496d02dc7b17ae8.Activity1: +3s894ms
09-05 14:40:55.497 1169 1192 I ActivityManager: Displayed AndroidControlGallery.AndroidControlGallery/md546303760447087909496d02dc7b17ae8.Activity1: +3s856ms
09-05 14:41:03.754 1169 1192 I ActivityManager: Displayed AndroidControlGallery.AndroidControlGallery/md546303760447087909496d02dc7b17ae8.Activity1: +3s897ms
After three runs, it seems this app suffers 25-50ms slowdown to
startup, and gains 1 second of build time improvement. A good net-win!
Other apps that have significantly more XAML will have different
results. I suspect the build time improvement will be even better, but
the hit to startup could be worse. With this setting opt-in, we can
experiment and find out.
* Move files to CollectionView folder for consistency with other platforms
Move SelectableItemsViewRenderer to Setup/Teardown pattern
Fix event handler naming
Use Is method for property changed check
* Rebase cleanup
Context: https://github.com/xamarin/xamarin-android/issues/2982
The Blank Xamarin.Forms app template in VS 2019 takes longer to build
than in VS 2017. A little research is showing that this is due to use
of the 28.x support libraries... For example, the build includes ~20
*more* jar files in the template from 2019 than 2017. The
`_CompileDex` step alone goes from ~15.2s to ~18.2s.
This lead me down the road of investigating if we can remove any
support libraries by default in Xamarin.Forms apps. I am also seeing
if there is more we can do in Xamarin.Android for this problem, in
general.
It looks like we can remove:
* Xamarin.Android.Support.v7.MediaRouter
* Xamarin.Android.Support.Media.Compat
Neither of these appear to be used, but have been listed as
dependencies of Xamarin.Forms for a long time.
~~ Results ~~
I made these changes, then did a `Debug` build of
`Xamarin.Forms.ControlGallery.Android.csproj` for comparison.
Comparing dex file sizes (in bytes):
Before:
3428092 classes.dex
3265616 classes2.dex
6693708 total
After:
4938000 classes.dex
1098772 classes2.dex
6036772 total
This looks like it could potentially save ~600KB of compiled dex code
on every Xamarin.Forms app.
Comparing methods:
Before:
classes.dex 11,492 methods
classes2.dex 19,451 methods
total 30,943 methods
After:
classes.dex 22,171 methods
classes2.dex 7,635 methods
total 29,806 methods
~1,137 methods removed, which should help with the dex limit.
Comparing APK sizes (in bytes):
Before:
26442597 AndroidControlGallery.AndroidControlGallery-Signed.apk
After:
25741701 AndroidControlGallery.AndroidControlGallery-Signed.apk
~700KB smaller APK, due to less .NET assemblies & dex code.
Comparing build time (this was using dx):
Before:
19785 ms CompileToDalvik 1 calls
After:
18532 ms CompileToDalvik 1 calls
Looks like it saved over a second of build time for this project.
Seems like an "easy win", let's do this!
* WIP Experimenting with getting the translated Intellisense in the right places
* Set up nuspec to include Intellisense translations
* Use languages branch of submodule for now
* Update submodule
* Update submodule
* Updated submodule
* Update submodule
* Pull in translated docs from all the languages
* [Android] move renderers to separate nuget
* additional android dependency
* rebase with material changes
* add android to material check
* simplify assembly info
* - add context to Init for future cases
* Updated all the OpenTK references to use NuGet
- Using the same NuGet version of OpenTK across the board
- Added a gallery factory to allow for platform-specific pages
- Added the OpenGL galleries to Android, iOS, GTK# and WPF
* Fix the build for iOS and macOS
* Fix the modified defines for the control gallery
* [ios] extract ios material out to its own project
* [core] fix platform messaging
* add material to other test projects
* update MaterialComponents on all test projects
* remove material from platform
* yml updates
* nuspec
* add iOS description
* language
* add dummy file so package installs into netstandard/android
* Add Target Framework checks
* Use the auto-generated constants
* [Visual] Work on the Material Frame
* Improving the code for the sample
* Added a controller to help with frames that have additional padding
- Android MaterialCardView does not use the default padding to determine where the content starts, rather it uses the content padding of the view because there is a border that does not affect the content
* [Visual] Added a few extra checks on Android to reduce unnecessary interop
* [Visual] A few more frame changes and some button tweaks
* [Visual] use the themers on iOS and save default properties
* [Visual] Add placeholders for themer and cache defaults
* [Visual] Added the material slider for iOS
- Android does not have a custom control, so uses the existing renderer
* [enhancements] Move from duplicate LoadImageAsync code to GetNativeImageAsync
* [visual] Updated the controls to use the new iOS bits
* [visual] some fixes for material components
* [visual] Added hacks for material alerts
* [visual] removing the alert changes for the main branch
* [visual] Update the MaterialComponents NuGet
* [visual] Rework the theming/customization of Material controls on iOS
* [visual] fix the places where the user colors were being changed
* [visual] Improve the ColorStateList management for Android
* [visual] Re-implemented the Android ProgressBar as a fast, material renderer
* Material Entry
* [visual] Add Android ActivityIndicator
* filter out material layouts for 8.1
* remove folder
* fix __ANDROID_28__
* MaterialContextThemeWrapper
* [visual] remove the `IFrameController` interface
* [visual] reverting the changes to the Frame layout
* [visual] reverting whitespace
* [visual] make sure to raise both property changed
* formatting changes
* fixing colors on android to match with ios themes
* Update Xamarin.Forms.Platform.Android/Material/MaterialButtonRenderer.cs
Co-Authored-By: mattleibow <mattleibow@live.com>
* fix sizing of entry with infinite width size request
* update to release 28 of support
* Update Xamarin.Forms.Platform.Android/Resources/values/styles.xml
Co-Authored-By: PureWeen <shane94@hotmail.com>
* Update Xamarin.Forms.Platform.Android/Resources/values/styles.xml
Co-Authored-By: PureWeen <shane94@hotmail.com>
* PR Comment changes
The `$(MSBuildSDKsPath)` is actually *always* set whenever there are MSBuild SDKs
*installed*, not necessarily when the current project is an SDK-style project itself.
This means that we're potentially adding duplicate items and otherwise disrupting
normal operation of the non-SDK style projects with this import.
So use the well-known properties that are set by the .NET [Sdk.props](https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.props#L22-L27) file instead,
which is the first imported target even before nuget-provided .props files.
Rui Marinho
Morten Nielsen
Shane Neuville
Jonathan Peppers
ShaneN
Samantha Houts
Gerald Versluis
Stephane Delcroix
E.Z. Hart
Pavel Yakovlev
shmin
Kangho Hur
Jonathan Peppers
Matthew Leibowitz
Andrei Nitescu
Samantha Houts
Daniel Cazzulino