The less noise in your code, the easier it is to read, understand and maintain. So you should try to remove any code that is unnecessary. It may not be always obvious what is unnecessary, but if you try to pay attention to this principle, you will be able to see more and more possibilities for cleaning up your code.
The following clean up options are highly recommended when developing Zebble apps:
Install the GCop visual studio extension and fix all errors and warnings it gives you. It has hundreds of useful code analysis rules.
When you install this Visual Studio extension you can then right click on the Solution (or each project) in the Solution Explorer window named "Clean up". When you click on it, it will automatically do the following across your project:
Don't set Id unless you want to use it in code behind (or CSS). In the following example there is no benefit to setting the Id property and it's just adding noise to the code.
When an element in your ZBL markup has no children, use a self closing tag. For example:
If all a button needs to do is to navigate to another page, in the markup use the z-nav-.... tags and avoid creating an event handler method unnecessarily. Read more.
Many methods take optional parameters which have a default value. In those cases do not explicitly set the parameter value to the default one unnecesarily. For example:
// Remove "PageTransition.SlideForward" because that's the default transition anyway!
When your API methods return a list of objects, use an array type:
Instead of hardcoding style related properties in C# or ZBL markup files, use CSS for anything possible.
Although you can write any C# expression in your ZBL markup files using the @ character, but you should avoid writing complex expressions. For example instead of:
Define a property in your code-behind file and just call that in the markup:
Getting threading right in a mobile app is hard. But Zebble has gone a long way to simplify things for you. In Zebble apps, by default all app related code runs on the background thread and unless you aboslutely know what you're donig, you should conform to the following:
Most APIs in Zebble already handle exceptions gracefully and show a user friendly alert to the user in case of any errors (learn more). From Web Api client to Device hardware apis, this is supported by default.
So avoid wrapping such calls in your own try/catch block. In fact if you have a catch block which just shows an alert and return false, you probably don't need to use a try/catch at all. Make sure to learn how Zebble handles exceptions.
When creating a new project there are several sample files added to this folder. Also during the course of the project development you might add files which are no longer needed later on. Make sure to remove any files from there which are not used to reduce the size of your App Bundle when deploying to the App Stores, and also to eliminate confusion.
When you define a field, method or property in a code-behind file of a .ZBL module, do not unnecessarily make it public or internal. This applies to your event handlers as well.