Wednesday, 09 December 2015
Thursday, 25 December 2014
I’ve been having some fun taking part in the Xamarin Holiday contest for creating a Xamarin plugin. My entry for the competition is a Messaging Plugin. The Messaging plugin makes it possible to make a phone call, send a SMS or send an e-mail using the default messaging applications on the different mobile platforms.
I’ve been slowly adding new features and have just published a new version of the plugin that adds support for sending attachments as part of an e-mail. In addition to adding attachments support I did some clean-up and refactoring on the plugin API. Unfortunately this introduces a few breaking changes and I’ve therefore decided to make the new version a major update (2.0.0).
Here is a list of supported features for v2:
- Send SMS (supported on iOS, Android, WinPhone 8, WinPhone RT)
- Make Phone Call (supported on iOS, Android, WinPhone 8, WinPhone RT)
- Send Email (supported on iOS, Android, WinPhone 8, WinPhone RT and limited support on WinStore via mailto protocol)
- Send HTML Email (supported on iOS, Android)
- Send Email Attachments (supported on iOS, Android, WinPhone RT)
Here is the release notes for v2:
- Added support for attachments via IEmailAttachment abstraction
- Added IEmailMessage abstraction
- Breaking change: Deprecated EmailMessageRequest. Construct IEmailMessage using EmailMessageBuilder instead.
- Breaking change: Changed IEmailTask.SendMail overload to use IEmailMessage.
- Breaking change: Deprecated Lotz.Xamarin.Messaging.Abstractions namespace. Use Lotz.Xamarin.Messaging instead.
Monday, 15 December 2014
Monday, 22 July 2013
We’ve recently started using the Silverlight 5 PivotViewer control in On Key Express as a great way for visualizing the Work Orders showing the work list that needs to be completed/has been completed. Here is some screenshots showing the different “cards” of information for the Work Orders at different zoom levels.
Small Card View
Large Card View
One of the great features of On Key Express is the ability for clients to translate the system into any language. This is great feature for customers who have engineers working across the globe as they can customise the system into any language they which to support. We supply the default English translation but the clients can even decide to change the English translation if they have certain client specific terminology they want to use.
This language feature however imposes an important restriction of any third party control that we use – we need the ability to translate any resource displayed by the control. We make extensive use of the excellent Telerik RadControls for Silverlight. Fortunately these controls are fully localizable by hooking up a custom ResourceManager to override the default resources being used by the Grids and other controls.
The PivotViewer control has quite a few resources. It ships with support for a few languages out-of-the-box through providing the resources in separate System.Windows.Controls.Pivot.resources.dll resource assemblies. By setting the ItemCulture property you are able to use the different out-of-the-box translations shipped with the control. However, unlike the Telerik controls there is however no easy way to hook into the control to override the resources being used. We can create additional resources assemblies for different languages but as mentioned previously, the client decides what additional languages they want to support.
We therefore needed a way to hook into the PivotViewer to inject our own Resource Provider that will use the client provided resource translations. Technically we store the clients translations in a database that is periodically synchronised with the client devices. After looking at the PivotViewer using Reflector, we confirmed that it makes use of the usual an internal static Resources class that is generated whenever you add .resx files to a project. The Resources wrapper internally makes use of a ResourceManager that uses the current culture to access the language specific resource file. We needed the ability to intercept the calls being made by this ResourceManager. We also wanted the ability to still use the existing Microsoft resource assembly as the default fallback mechanism for any of the resources that we don’t want the clients to translate. There includes the numerous exceptions and other design time resources which the clients aren’t interested in.
With this in mind, we created the following PivotViewerResourceManager wrapper class:
Notice that the class is a simple ResourceManager wrapper around the existing Microsoft resource assembly. When override the GetString method to allow us to first do an external lookup for the resource using our IResourceProvider interface. If we do not have an external translation, we simply delegate to the Microsoft provided resource. We adopted the convention of prefixing all the client provided translations for the PivotViewer with the “MSPivot” prefix as it makes it easier to identify all the translations related directly to the control. With all of this in place we simply added a trigger to the PivotViewer XAML to load and inject our PivotViewerResourceManager when the control is loaded via the InjectResourceManager method.
Here is a sample screen shot of our ResourceManager in action with the PivotViewer. Notice that some of the resources for which we provide translations are show in a different language whilst the rest of the control falls back to using the default MS provider resources.
Tuesday, 02 April 2013
BackgroundAt Pragma we've been improving on some of our deployment practices during the past few releases. I've always been a great proponent of trying to automate as much of the deployment process as possible. One of the aspects that we improved on recently was the ability to automatically generate the Release Notes from our Team Foundation Server repository with every daily build of our software. This automation gives us quite a few benefits:
- Visibility into what's included with every build from the beginning of a release
- Ability to QA the Release Notes earlier in the development cycle as part of our daily builds
- Use of our existing TFS work items as the source for feedback, i.e. no context is lost between developers telling the technical writer what to include in the Release Notes. The technical writer only needs to check the grammar and spelling of the TFS Work Item feedback.
- No manual intervention required to get the bulk of the Release Notes document generated
- We want to be able to merge some manually authored content into the Release Notes document. Sections like What's New, Modifications and Maintenance typically contain functionality that are implemented by various TFS Work Items (Product Backlog Items, Tasks etc). So we wanted the ability to manually author these sections and merge the content with remainder of the document that is automatically generated.
- We want the ability to selectively filter out some Work Items from being included in the Release Notes document by running a custom TFS Query. An example of Work Items that we want to exclude are the internal bugs that were discovered for new functionality not yet released into production.
- We want to use MS Word to author the manual content to make use of our existing corporate stylesheets
- We want the output to be available as a PDF
- We want command line support to allow us to automate the process as part of our daily builds using TeamCity
- We want the PDF to use bookmarks to enable easy navigation between the different sections
- We want the PDF to use our corporate branding/style
The next step was to create a ReportRunner class to take these settings and generate the report in the PDF format:
Generating the PDF
On a high level, the process for generating the PDF turned out as follows:
- Create new blank PDF
- Add a front page
- Add (merge) the contents of the manual PDF into the new blank PDF whilst keeping track of the bookmarks contained within the manual document (see Requirement #6)
- Run through the list of processed work items to add the document content for them into relevant sections in the new PDF
- Re-bookmark the whole document to enable easy navigation throughout the whole PDF in support of requirement #6.
To add the front page and also include a custom footer on every page containing the build version, generation time stamp as well as page number, we created a ReleaseNotesPdfPageEvents class to implement the IPdfPageEvent interface that iTextSharp provides for executing custom logic when a PDF document is opened/closed, new paragraphs, sections are added etc. This class is then assigned to PageEvent of the PDF writer to ensure that the custom logic executes as part of the PDF generation process (see line 16).
After adding the front page, the content of the manual PDF is merged into the new document (lines 30-35). Keeping track of the bookmarks turned out to be quite an interesting exercise and is done as part of the Merge method.
After merging the existing content, we process the in-memory list of work item information by firstly grouping the Work Items based on their resolution types into sections like "How do I", "Bug Fixes" etc. (lines 38-41) and thereafter writing these sections into the document using the WriteWorkItems method:
For every new section we add an additional bookmark into the Bookmarks collection to make sure that we have a complete list of bookmarks for all the available sections in the document (see line 14). The final step in the generation process is to add these bookmarks into the new document using the CreateBookmarks method.