Recently I was tasked with creating a mobile app for an internal company need. Normally I’d default to web applications with responsive UI for different devices but in this case there was a core requirement to support push notifications. The timeline was “as soon as possible” and that included picking a platform (two leading choices were Cordova/Ionic and Xamarin), learning the toolchain, integrating push notifications, ensuring it works even after being wrapped in a security product (Citrix XenMobile MDX Toolkit – I still don’t know which of these words is the most important in this case so I include them all).
App Technology Stack
Since I’m more comfortable with C# compared to web frameworks I started with Xamarin. I’ve attended some user group talks that used Xamarin and knew Xamarin Forms was probably the right starting point. I only had to support iOS but Android was a nice to have since we have many users with Android devices.
Visual Studio App Center
After trying a few different options based on previous knowledge (Azure Notification Hubs, Azure App Services) and things discovered (Google Firebase for Android and iOS) to various degrees of success, I stumbled on Visual Studio App Center. I initially started my searching in early February 2018. App Center had only been announced during the Connect(); 2017 conference a few months prior in November. Because it was so new under that name it was not as high in search results when looking for push notifications with Xamarin. That’s really unfortunate because App Center is an integrated offering of previous solutions that already have great support and adoption.
I was recently tasked with building a mobile app for my company that received push notifications and directed users to internal resources (via XenMobile SecureWeb). I have looked at mobile apps at various points in the past and tried Xamarin, Cordova, Ionic and even native Swift and Java. I struggled to get anything of value implemented so I never went further. That left me starting from scratch to figure out how I’d satisfy the requirement.
I had passively been attending Greg Shackles’ NYC Mobile .NET User Group and had some idea that Xamarin Forms was probably my best bet for a cross platform solution. I am not particularly fond of XAML but the application itself intentionally had almost no UI so that was not a concern.
My exploration meandered a bit while I tried things I knew about (Azure App Services, Azure Notification Hubs) and then things I leaned about by extension (Firebase) before finally settling on exactly what I needed: Visual Studio App Center. It’s a lightweight solution that offers analytics, crash reporting and push notifications. The configuration was straightforward for Push notifications and just worked.
With App Center I had the infrastructure set up and configured and could focus on the functionality of the app. The rest of this is all about my experience using the tooling to build and test that application on iOS and Android devices.
Posted in Android, First Experience, iOS, Mobile Development, Programming, Xamarin
Tagged Android, First Experience, iOS, Mobile Development, Programming, Xamarin
Recently I’ve been interested in incorporating more automated testing in my projects. The benefits of having tests are heavily covered in other topics so I won’t waste time explaining why I sat in on a few sessions at this year’s Code Camp NYC focusing on automated testing. Needless to say a few of the sessions was all it took to push me into getting my feet wet.
I decided to start out on a demo project just so I didn’t dirty up any formal projects while I tried out the best approach to implementing the tests. I recently created a project to check out ASP.NET Web API as a progressive download host (which allows for streaming video to iOS devices, allows downloads to be chunked and resumed by download managers, etc.) This seemed like a good candidate for tests since the behavior of the library changes based on the HTTP request headers for a resource.
It’s taking a bit longer to get out Part 2 of creating a user picker in HTML, CSS and jQuery than I’d initially expected. In the interim the User Picker has evolved into a more generic picker useful for other types of data. As such it’s undergone some heavy modification to strip out specific references to users / employees and gained some additional configuration options.
I had almost the entire Part 2 post written and ready the night I published Part 1. I only needed to do a bit of cleanup of the user picker to remove any traces of specific information and get it ready for people to view publicly. With all the changes that have happened since, the post is basically obsolete. It wouldn’t be kind to force people to wait for it to be rewritten before letting you see the current code and begin using it. I’ll try to get the blog post out soon for those interested in the process of creating a jQuery plugin but I have a feeling the source is much more highly desired!
The picker – now called entitypicker – can be found on GitHub. There is also a hastily thrown-together demo page. The demo uses Yahoo services to do YQL queries for city names.
Constants and Settings are a pretty old topic, right? If you have a simple value you know at compile time which might make code more readable or might change very rarely and you don’t want to hunt through code to change it in multiple places, you use a const.
A const is beautiful. It’s static which means you don’t need an instance of an object to access the value. It’s set during compilation and immutable during the execution of a program which gives you some peace of mind the value isn’t going to get accidentally changed by someone else’s code.
Unfortunately a const can’t handle a value which isn’t known until a program starts up and can access a configuration file. In the face of this limitation I’ve seen the same (anti?) pattern repeated: the configuration value is read in with code in the constructor of a class which needs the value. Unfortunately this means the configuration value is read in every time you create a new instance. This is less than ideal given the value isn’t likely to change very often. Think about it – when you modify a web.config – are the values immediately available? Yes. Why? Because the application pool recycles! All your objects were dumped from memory and everything is loaded fresh and when the configuration code executes again, the new value is picked up.
So if the value is unlikely to change, why read it over and over again? Some people don’t – I’ve seen people use static members and only perform the costly configuration reading if the value hasn’t already been stored. This is pretty close to being optimal but it leaves a bit of clunky code lingering in your constructor and there can be a bit double-work done when an object is created multiple times in quick succession or on different threads at the same time. This is why I use static constructors paired with static readonly members to hold my configuration file specified settings.
What makes this a winning pair? A static readonly member is synonymous to a const except its value isn’t required to be set at compile time. Instead you must set the value by the end of your class constructor. A static constructor is called before you make use of an object for the first time.
Haven’t used a static constructor before? Probably not but you can probably guess it’s a constructor that’s called once – before the normal instance constructor is called. If you put your config file reading logic in this static constructor to set the static readonly configuration values, you’ll have near-const behavior with the added bonus of not cluttering up your instance constructor! More importantly, it is very similar to the code I’ve seen people write already but reduces the cost of re-reading configuration values with each new instance down to a single hit.
Keep in mind the rules go out the window if you mark your static members with the ThreadStatic attribute. Luckily this attribute should be used incredibly rarely and by people who know precisely why no option is optimal for them.
Static constructors are nice, so I’ll say it twice. Static constructors are nice, static constructors are nice.
Static constructors are nice,
In this post I’ll walk through replacing existing, expensive synchronous loop code with an easy to consume generic wrapper to run the code in parallel and increase performance.
I had an interesting challenge today. I was debugging a bit of code related to RSS feed item retrieval and aggregation and saw an opportunity to increase performance by multithreading my calls to different feed urls.
The code in question got List<string> urls which were links to various RSS feeds and returned a single SyndicationFeed item containing all the items from these various feeds ordered by the PublicationDate in descending order. The problem was the loop of the urls was being done one at a time and as anyone who has had to work with WebRequest and WebResponse objects knows, this can be a little costly for one request, let alone many. I knew I needed to get these requests going in parallel to cut down on all the overhead and wait time.
It’s been some time since I posted my early attempts at making parallel execution of threads easy when working with collections in .NET Framework prior to version 4. It might seem out of date but believe it or not there are a lot of developers who are still unable to take advantage of the new runtime yet. For me this is due to our strong dependence on SharePoint which unfortunately still requires the 2.0 runtime.
With this limitation strongly in place, I continue to refine my ability to work with threads.