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.
(Update 2014-12-10: The code is now in GitHub and a package is available as a NuGet Package. See the announcement about it.)
Some time ago I read an interesting Stack Overflow question asking about streaming videos to iOS devices from ASP.NET MVC. In researching the answer, I learned about parsing HTTP request headers and constructing responses. In general for iOS devices to support playing video a web server needs to understand requests with the RANGE header and respond appropriately with 206 (PartialContent) and a CONTENT-RANGE header which more or less repeats the original request range.
I originally wrote an answer to this effect but also wanted to test it out to make sure it worked in ASP.NET MVC. While successful, it was not particularly elegant. After getting some feedback and requests, I wrote a second version. Surprisingly I still get pings on this from time to time and it made me wonder if something more integrated has shown up in ASP.NET MVC since my original attempts. Until recently I hadn’t had a need for this myself until a couple days ago I got the urge to stream video content from my Windows laptop to my TV and thought this might be a good time to revisit the library. What I wanted was an iOS compliant video server so I could stream videos to my Apple TV via my phone.
I knew I had a working library for ASP.NET MVC that I could have up and running in a few minutes but I was more curious if there had been any advancements in supporting partial range requests more seamlessly. A few brief searches turned up the ByteRangeStreamContent class and the HttpRequestMessage’s RANGE header used in ASP.NET Web API which looked promising.
A coworker was tasked with finding a good client-side grid for displaying and editing data from WCF services. We’ve had a little experience with WCF services and JSON serialization of simple data to generate some custom HTML but until now we hadn’t touched grids. Typically we’d use a 3rd party ASP.NET control inside a web application but lately we’ve been trying to be a little more lean.
I haven’t done any research into grids myself so I’m taking it on faith that jqGrid is alright for us. Right out of the gate there was some trouble getting the JSON data to be in a format the grid appreciated. Since we didn’t fancy the idea of boxing all our services into returning data in this format we had to get the grid to work with our format.
I went from knowing nothing about this grid to having 20 tabs open on various sites trying to find any information I could regarding options for making the grid work with our data. It is shocking how much information is out there but I didn’t find a single source that put it all together. It was through pure persistence I found a reference to jsonReader and then found the properties it expects.
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.