Best Practices to follow while developing a Xamarin Cross Platform App
8 June 2020
No doubt native app development for Android and iOS produces best quality apps. But you don’t always have the liberty to put in efforts to develop same app for two different platforms. Here comes the Xamarin in picture, one of the best cross platform development tools. Any tool or library, when applied in a best way produces optimal results, Xamarin is no exception. Listing below a few simple practices which will benefit you in long run, either in terms of code maintenance or performance.
- L10N: Always put in your resources in their corresponding resource files or folder in proper structured manner, be it images or text strings. Even if you are developing a single screen, very simple app, which wasn’t going to be used in any other language than English, assume that it will be going to be used by non-English speaking users. Even if initially it’s a simple app design for English speaking users / regions, there are strong chances that your client ask you to provide UI in other languages to serve non-English speaking users. Consider the pain if you have hard coded all the string, and haven’t maintained a resource file. You have to hunt down each and every string going in all classes and XAML files. If you are using a resource file, providing support for a secondary language is a matter of half an hour, you just need to place the secondary resource file with the strings translated in target language.
- Hard coding: A bit related to point one mentioned above, but it’s about everything which can be avoided hard coding. Don’t let your code fill up with magic numbers. Every string literal or number should either go to its corresponding resource file or declared as a constant. How would you decide which whether to add a string as a constant or declare it in resource file? Simple, if your string is going to be visible to the user, it should be in a resource file, so that later when you need (or your client ask to) the app in some other language, you can simply add another resource file. If your string is just being used internally, for example a date format, a literal to be shown in logs, or a string being used a key should definitely be declared as a constant.
- Sanitize the URLs: Every URL you use in your code doesn’t always belongs to you or your company, i.e. someone else worked (it’s the case most of the time) on the APIs, and they provide you the URL (or at least the end point). This URL might be passed to you through an email, a message on Slack or Skype or even WhatsApp. Don’t just blindly copy and paste that URL into your code assuming it will work, especially when the URL (or endpoint) belongs to a live server. Check the URL thoroughly however you can, by ensuring the presence of forward slash character, by hitting it in browser or in Postman, or by any other means you want / need. Once you are sure 100% that the URL is correct, only then use it in your code.
- Design Pattern Overkill: Don’t ever use a design pattern just for the sake of using it, and until and unless it’s required. IMO, every developer should follow the KISS principle. Don’t bloat your code with any design pattern just because it looks fancy or because everyone in your team of company is using some pattern. Keep your code simple, and easier to understand. A poorly or unnecessarily used design pattern will only make your code complex to understand. Apply a design pattern only if you really feel itsneeded and that too after double checking the necessity. A design pattern should decrease (if not eliminate) the complexity of your code, it should never become a headache itself.
- Use Messaging Center with caution: Publish-Subscribe pattern is no doubt good when like any other thing used with caution. But when used poorly, it can cause a debugging mess. The mistake we made in one of our projects is to have multiple subscribers to a messaging center Send method. We forgot the other subscribers and focusing on only one. This caused our app to call an API multiple times and make incorrect updates to UI. So make sure you actually need a messaging center subscriber you add it.
- Emulator and Simulator are your friend: There are so many mobile devices out there, especially in case of Android. Nobody can claim they tested everything on every device out there. You should test your app on maximum devices possible and if a device or device with a particular OS / Version not available, simulators and emulators are the best options. Test on emulators / simulators of different devices and OS versions.
- Make use of the latest IDE features: And best among them IMO is the Hot Reload. Yes, the pain of UI designing I experienced before hot reload makes me think Hot Reload as the best feature introduced in Visual Studio 2019. And it’s really a charm to see the changes you make in your XAML files reflected immediately.
- Don’t pile up the unused resources: Even though internet access on mobile devices is not that expensive these days still, you should be concerned about having a lean IPA or APK file. Don’t be lazy to remove the unused audio, video, layouts and specially the images. Images files are the ones who frequently contribute to pile up the unused resources.
- Unit testing is not a QA’s job: Once you are sure that the functionality is working solid, only then you should release the module / build to QA for testing. Once you are done coding the functionality, run a few test enough to make you confident that it works as it should be. Give it some corner cases to break it.
Learn More:
