1. Using nested stackLayout
If we use nested stackLayouts in our application, it becomes very complicated to read or understand what’s going on. It will also deteriorate the app’s performance.
If we must use nested stackLayouts, we can use multiple children with a single parent stackLayout. Otherwise, it would be better to use a grid, which is more efficient than a stackLayout. By using a grid, we can easily read the written code and improve the app’s performance too.
The following code example demonstrates how to use the grid in Xamarin.Forms.
Instead of this:
<ContentPage ... xmlns:local="clr-namespace:Profile">
<ContentPage.Content>
<StackLayout>
<StackLayout orientation = "Horizontal">
<Label Text=”Employee Name :”/>
<Label Text=”John” />
</StackLayout>
<StackLayout orientation = "Horizontal">
<Label Text=”Designation :”/>
<Label Text=”Manager” />
</StackLayout>
<StackLayout orientation = "Horizontal">
<Label Text=”Age :”/>
<Label Text=”25” />
</StackLayout>
</StackLayout>
</ContentPage.Content>
</ContentPage>
Use this:
<ContentPage ... xmlns:local="clr-namespace:Profile">
<ContentPage.Content>
<Grid RowDefinitions=”Auto, Auto, Auto” ColumnDefinitions=”50*, 50*”>
<Label Grid.Row=”0” Grid.Column=”0” Text=”Employee Name :”/>
<Label Grid.Row="0" Grid.Column=”1” Text=”John”/>
<Label Grid.Row=”1” Grid.Column=”0” Text=”Designation :”/>
<Label Grid.Row="1" Grid.Column=”1” Text=”Manager”/>
<Label Grid.Row=”2” Grid.Column=”0” Text=”Age :”/>
<Label Grid.Row="2" Grid.Column=”1” Text=”25”/>
</Grid>
</ContentPage.Content>
</ContentPage>
2. Ignoring MVVM pattern
MVVM (Model-view-viewmodel) pattern is used to separate domain logic and the presentation layer. By ignoring the MVVM pattern, we cannot reuse code. This makes it difficult to maintain and test the code, as some developers will implement it in the code-behind without using commands or data binding.
The main advantages of using MVVM are that it makes code easy to reuse, work out, maintain, and test. Once we implement code in the ViewModel, we can use the same ViewModel in multiple projects.
The following code example demonstrates how to use the MVVM pattern in Xamarin.Forms.
Instead of this:
<ContentPage ... xmlns:local="clr-namespace:login">
<ContentPage.BindingContext>
<local:LoginViewModel />
</ContentPage.BindingContext>
<Button Text = “Click Me!” Clicked =” LoginButton_Clicked” />
</ContentPage>
Public partial Class Login : ContentPage
{
private async void LoginButton_Clicked(object sender, EventArgs e)
{
}
}
Use this:
<ContentPage ... xmlns:local="clr-namespace:login">
<ContentPage.BindingContext>
<local:LoginViewModel />
</ContentPage.BindingContext>
<Button Text = “Click Me!” Command ={Binding ClickButtonCommand} />
</ContentPage>
Public Class LoginViewModel
{
public ICommand ClickButtonCommand => new Command(Login);
private void Login()
{
}
}
3. Repeating the same templates in multiple views
When developing multiple views for an application, we should not use the same template code in every view. Doing so would complicate maintenance, consume more time, and cause rework. So, in these scenarios, we can use some common templates to avoid the repetition.
The following code example illustrates the procedure to avoid using the same template in every view. You can even create a CustomView and then include that in your MainPage.
<label Text= “Common template” />
</ContentView>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
xmlns:views="clr-namespace: MainPage;assembly= MainPage "
x:Class="YourProject.YourPage">
<views:CustomView/>
</ContentPage>
4. Using outdated libraries
When developing an application, make sure you are using the latest versions of your libraries and IDE in all platforms. If we use older versions in our application, there is a chance that it might not function in the newer versions of the platforms.
For example, in the case of iOS, you won’t be able to submit your app to the App Store if you haven’t used the latest version of Xcode to develop it.
Let’s say you are installing Xamarin.Essentials or other packages that use support libraries. You should ensure that all of your support libraries are up to date and are of the same version. Suppose we installed version 27.0.2 of the support libraries, and Xamarin.Essentials demands version 27.0.2.1, then we can’t deploy the application.
5. Overusing platform-specific code
If we build applications with platform-specific code, we need to write the code for each platform. So, the implementation time will increase. So, try to switch to cross-platform code as much as possible.
6. Repeating the same styles in multiple views
We should avoid using the same style code in every view while developing multiple views for an app. If we repeat the style code, the implementation time would increase. For any update in the style, we will have to manually make the change in every view in which we used the style. So, we can use common styles to avoid repetition.
The following code sample illustrates how to avoid repeating styles in every view. You can also create a CustomPage and include it in your MainPage.
Instead of this: (Same style in different views)
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
xmlns:views="clr-namespace: MainPage;assembly= MainPage"
x:Class="YourProject.MainPage">
<ContentPage.Resources>
<!-- Implicit styles -->
<Style x:Key=”lblstyle” TargetType=”Label">
<Setter Property="BackgroundColor" Value=”Red" />
</Style>
</ContentPage.Resources>
<Label Text=”Test” style=”{StaticResource lblstyle}”>
</ContentPage>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
xmlns:views="clr-namespace: CustomPage;assembly= CustomPage"
x:Class="YourProject.CustomPage">
<ContentPage.Resources>
<!-- Implicit styles -->
<Style x:Key=”lblstyle” TargetType=”Label">
<Setter Property="BackgroundColor" Value=”Red" />
</Style>
</ContentPage.Resources>
<Label Text=”Test” style=”{StaticResource lblstyle}”>
</ContentPage>
Use this: (Common Styles)
x:Class="YourProject.Styles"
xmlns="http://xamarin.com/schemas/2014/forms"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
mc:Ignorable="d">
<Style x:Key=”lblstyle” TargetType=”Label">
<Setter Property="BackgroundColor" Value=”Red" />
</Style>
</ ResourceDictionary>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
xmlns:views="clr-namespace: MainPage;assembly= MainPage"
x:Class="YourProject.MainPage">
<ContentPage.Resources>
<styles/>
</ContentPage.Resources>
<Label Text=”Test” style=”{StaticResource lblstyle}”>
</ContentPage>
7. Not covering all OS versions
If we don’t maintain the latest OS version, we can’t develop applications for the latest devices. So, you should always use the latest Android SDK tools and Android API references when developing your applications. You can update to the latest versions using the Android SDK Manager. Also, the target SDK version of your Android projects must be set to the latest installed platforms. For iOS, we must set the target version to iOS 9 or higher.
8. Blocking the main thread
If we block the main thread, our app won’t work smoothly and its performance will suffer. So, to avoid using the main thread to perform heavy operations, we can either use async/await or background workers to do them. We should use the main thread only to update the UI.
9. Not maintaining the same NuGet version in all platforms
When you downgrade or upgrade NuGet packages, make sure to maintain the same version in all platforms. Otherwise, you may not be able to build and deploy the project to the target devices successfully.
10. No unit testing
If we don’t use unit test cases in our application, it is very hard to find errors and maintain the implemented code.
Follow these tips to write unit tests in your application:
- The unit test should be independent.
- Code coverage of testing code should be above 85%.
- The unit test should be simple and there shouldn’t be any confusion in the code.
- Execution of the unit test should be fast and should generate accurate results.
- The unit test should cover one condition of a method at a time.
- There should be a separate project for writing unit tests.
- The parent class should be tested first, and then the child class.
- The unit test project should be maintained and well organized.
Thanks for reading.
No comments:
Post a Comment