Category Archives: Mobile

Current talk list 2016: web and database performance

It’s that time of the year where, for me, talk proposals are submitted. I also tend to take it as an opportunity to refresh and rework talks.

This year I’ve submitted talks for DDD, DDD North, and NDC London (this one’s a bit of a long shot), and am keeping my eye out for other opportunities. I’ll also be giving talks at the Derbyshire .NET User Group, and DDD Nights in Cambridge in the autumn.

Voting for both DDD and DDD North is now open so, if you’re interested in any of the talks I’ve listed below, please do vote for them at the following links:

Here are my talks. If you’d like me to give any of them at a user group, meetup, or conference you run, please do get in touch.

Talk Title: How to speed up .NET and SQL Server web apps

Performance is a critical aspect of modern web applications. Recent developments in hardware, software, infrastructure, bandwidth, and connectivity have raised expectations about how the web should perform.

Increasingly this attitude is applied to internal line of business apps, and niche sites, as much as to large public-facing sites. Google even bases your search ranking in part on how well your site performs. Being slow is no longer an option.

Unfortunately, problems can occur at all layers and in all components of an application: database, back-end code, systems integrations, local and third party services, infrastructure, and even – increasingly – the client.

Complex apps often have problems in multiple areas. How do you go about tracking them down and fixing them? Where do you begin?

The answer is you deploy the right tools and techniques. The good news is that generally you can do this without changing your development process. Using a number of case studies I’m going to show you how to track down and fix performance issues. We’ll talk about the tools I used to find them, and the fixes that resulted.

That being said, prevention is better than cure, so I’ll also talk about how you can go about catching problems before they make it to production, and monitor to get earlier notification of trouble brewing.

By the end you should have a plethora of tools and techniques at your disposal that you can use in any performance analysis situation that might confront you.

Talk Title: Premature promotion produces poor performance: memory management in the CLR and JavaScript runtimes

The CLR, JVM, and well-known JavaScript runtimes provide automatic memory management with garbage collection. Developers are encouraged to write their code and forget about memory management entirely. But whilst ignorance is bliss, it can also lead to a host of problems further down the line.

With web applications becoming ever more interactive, and the meteoric rise in popularity of mobile browsers, the kind of performance and resource usage issues that once only concerned back-end developers have now become common currency on the client as well.

In this session we’ll look at how these runtimes manage memory and how you can get the best out of them. We’ll discuss the “classic” blunders that can trip you up, and how you can avoid them. We’ll also look at the tools that can help you if and when you do run into trouble, both on the client and the server.

You should come away from this session with a good understanding of managed memory, particularly as it relates to the CLR and JavaScript, and how you can write code that works with the runtimes rather than against them.

Talk Title: Optimizing client-side performance in interactive web applications

Web applications are becoming increasingly interactive. As a result, more code is shifting to the client, and JavaScript performance has become a key factor for many web applications, both on desktop and mobile. Just look at this still ongoing discussion kicked off by Jeff Atwood’s “The State of JavaScript on Android in 2015 is… poor” post:

Devices nowadays offer a wide variety of form factors and capabilities. On top of this, connectivity – whilst widely available across many markets – varies considerably in quality and speed. This presents a huge challenge to anyone who wants to offer a great user experience across the board, along with a need to carefully consider what actually constitutes “the board”.

In this session I’m going to show you how to optimize the client experience. We’ll take an in depth look at Chrome Dev Tools, and how the suite of debugging, data collection and diagnostic tools it provides can help you diagnose and fix performance issues on the desktop and Android mobile devices. We’ll also take a look at using Safari to analyse and debug web applications running on iOS.

Throughout I’ll use examples from to illustrate. is an HTML5, JavaScript, and CSS games site. Currently it hosts a version of Star Castle, called Star Citadel, but I’m also working on versions of Asteroids (Space Rawks!), and Space Invaders (yet to find an even close to decent name). It supports both desktop and mobile play. Whilst this site hosts games the topics I cover will be relevant for any web app featuring a high level of interactivity on the client.

Talk Title: Complex objects and microORMs: an introduction to the Dapper.SimpleLoad and Dapper.SimpleSave extensions for StackExchange’s Dapper microORM

Dapper ( is a popular microORM for the .NET framework that provides simple way to map database rows to objects. It’s a great alternative when speed is of the essence, and when you just don’t need the functionality offered by EF.

But what happens when you want to do something a bit more complicated? What happens if you want to join across multiple tables into a hierarchy composed of different types of object? Well,then you can use Dapper’s multi-mapping functionality… but that can quickly turn into an awful lot of code to maintain, especially if you make heavy use of Dapper.

Step in Dapper.SimpleLoad (, which handles the multi-mapping code for you and, if you want it to, the SQL generation as well.

So far so good, but what happens when you want to save your objects back to the database?

With Dapper it’s pretty easy to write an INSERT, UPDATE, or DELETE statement and pass in your object as the parameter source. But if you’ve got a complex object this, again, can quickly turn into a lot of code.

Step in Dapper.SimpleSave (, which you can use to save changes to complex objects without the need to worry about saving each object individually. And, again, you don’t need to write any SQL.

I’ll give you a good overview of both Dapper.SimpleLoad and Dapper.SimpleSave, with a liberal serving of examples. I’ll also explain their benefits and drawbacks, and when you might consider using them in preference to more heavyweight options, such as EF.

Detect mobile browsers in server-side code

Last week I found myself needing to detect mobile browsers on the server-side and ran across this extremely useful site:

It offers open source code for doing just that. Many languages are available: C#, Ruby, JavaScript & node.js, PHP, Python, and more. Even Perl!

Often you’d use this code to redirect the user to a mobile version of your site. However, my site uses the responsive Twenty Twelve WordPress theme. This works well on mobile browsers. Thus, I don’t really want or need to redirect the user.

Unfortunately, there’s one particular piece of content that was banjaxxing the page width on mobile devices. It needed to be replaced. Normally I’d do this on the client-side, which is what the theme does. In this cases the content’s Ts & Cs meant I wasn’t allowed to. But I could do it on the server.

You probably know that you can’t get the client’s screen resolution or browser window dimensions on the server. However, you can use the user-agent string to detect mobile browsers. This is exactly what the code at does. They’ve written and tested code that will reliably detect mobile browsers across most devices. That isn’t something I wanted to attempt myself (how would I test it?), and neither should you.

WordPress runs on PHP so I now have this particularly minging, but highly functional, lump of code in one of my template scripts:

if(preg_match('/(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows (ce|phone)|xda|xiino/i',$useragent)||preg_match('/1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas\-|your|zeto|zte\-/i',substr($useragent,0,4))) : ?>

    <div style="padding-bottom: 16px; margin-left: -24px; margin-top: -24px;">
        <!-- Content displayed on mobile (but not tablet) browsers here -->

<?php else : ?>

    <span style="float: right; clear: right; padding-bottom: 8px;">
        <!-- Content displayed on all other browsers here -->

<?php endif; ?>

DO NOT copy this code. New devices are being released all the time so make sure you grab the latest version from That way your code will work with the most recent generation of devices.

To edit your WordPress templates just open up your dashboard and click Appearance > Editor:

Edit WordPress templates.

(Oh, and if I ever need that check in more than one place I’ll refactor it into a method. For now I can live with it sitting in the one template where I need it.)

As my comment in the code suggests, this won’t work for tablets. If you need special support for them, add the code snippet under the Tablets section here to the first regex. You can also separate the checks for mobiles and tablets, or even different models of mobile/tablet, if you need more fine-grained control over site behaviour.

How to take a screenshot of your iPhone or iPad in iOS 7

Taking a screenshot/screengrab of your phone in iOS 7 is really easy, and it works in all apps. Just follow these simple steps.

  1. Press and hold the Power/Sleep button (see image below).
  2. Click the Home button (see image below).
  3. Release the Power/Sleep button.

Location of iPhone 5S Power/Sleep and Home buttons.

(Note: it also works the other way around: press and hold Home and then click Power/Sleep. Use whichever you prefer.)

If it works the screen should flash briefly to indicate that a screenshot has been taken. If your iPhone isn’t on silent you’ll also hear the camera shutter sound. Make sure you don’t hold Power/Sleep for too long or you’ll switch your iDevice off!

Your screenshot will be saved to the camera role so open up the Photos app to take a look at it. You can see here that I’ve taken several screen grabs today:

Screenshots in Photos app.

Been getting screenshot snap-happy today.

Tap on the screengrab you’ve just taken to view it full size.

Viewing individual screenshot in Photos app.

Looking at an individual screenshot: note the sharing button in the bottom-left corner.

You can get to sharing options by tapping the button in the bottom left corner (the one that looks like a square with an arrow pointing upwards out of it).

Sharing options for screenshot in Photos app.

Here I can share the screenshot or, more likely, send it to myself.

From here you can share the photo or send it to specific people via MMS or email. Just tap the appropriate icon and iOS will walk you through the rest.

The iOS 7 Keyboard: Un-Damn Your AutoCorrect

I used to suspect that most of the posts on were faked. That was until last month, when I finally upgraded my aged iPhone 3GS to an iPhone 5S and, with it, iOS7.

Overall, it’s been a great experience, but the autocorrect… oh, how I hated the autocorrect. Every time I wrote an email, replied to an SMS, I felt like I was fighting with it. It would even correct correctly spelled words. For example, “were” became “we’re” and, with a bizarre nod to either Shakespeare or Schiller, “passcode” became “pass ode”.

Really annoying.

I don’t know if this is because iOS 7’s autocorrect different from iOS 5’s. Maybe it was just the cumulative effect of 4 years of typos combined with that putatively tweaked algorithm. Whatever, it become intolerable.

Fortunately there is some relief to be had with a bit of tweaking. Let’s take a look at the options, starting with the least intrusive and working our way up from there.

Option 1 – The Nutcracker: teach the dictionary one word at a time

Next time you enter a word that it wants to wrongly auto-correct and the suggestion pops up, hit the little X you can see on the right of the suggestion:

Incorrect suggestion when writing an SMS.

Dammit, no! “Were” is a completely valid word.

OK, now delete the word and try to type it in again. When the suggestion pops up again, hit the X to dismiss it. Now delete the word and enter it again, etc. Keep doing this until the incorrect suggestions stops appearing: it’ll probably take about 5 attempts. Once that happens it should mean the dictionary has forgotten the old correction and will instead use the word you’ve entered as the new correction in future, if it makes any suggestion at all.

That’s fine, obviously, but if it’s wrongly correcting loads of words this process could become quite arduous. Which brings us round to…

Option 2 – The Sledgehammer: reset the keyboard dictionary

For me the situation was so bad I had to go down this route. Before you follow me though, understand that there is a downside. Resetting the dictionary will remove all the words it’s learned from you, so it’ll have to learn them all over again. Whilst it’s doing that it’ll probably suggest all manner of humorous and possible highly inappropriate or career-limiting alternatives.

(Just thought I should warn you.)

To reset your keyboard dictionary, open up Settings, and then drill down to General > Reset. Now tap Reset Keyboard Dictionary.

Settings page for resetting various aspects of iOS.

Reset your keyboard dictionary from here.

You’ll be asked to enter your unlock passcode:

Reset keyboard dictionary passcode confirmation screen.

Enter your normal unlock passcode here.

Once you’ve done that you’ll be asked to confirm that you want to reset the dictionary (with a warning about losing all your custom words, as I mentioned):

Reset keyboard dictionary final confirmation.

No going back after this.

And you’re done.

You might still find the vanilla dictionary a bit annoying to start off with, but at least now you have a clean slate. You should find it suggesting a lot fewer spurious autocorrections.

But, if this still doesn’t satisfy you, there’s always… 

Option 3 – Nuke autocorrect from orbit: it’s the only way to be sure

It’s a bit extreme, but you can just disable autocorrect, and it’ll never bother you again.

You need to do this via the keyboard settings, which you’ll find in Settings > General > Keyboard. They look like this:

Keyboard settings.

If you can’t find joy any other way, these settings give you access to the thermonuclear option.

You just need to switch off Auto-Correction. If it annoys you, you can also switch off Auto-Capitalization.

It’s also worth checking your shortcuts to make sure none of them is causing any annoying autocorrections.

Note: the Check Spelling setting is nothing to do with autocorrect. All it does is highlight what it thinks are misspelled words when it’s switched on. It does not try to correct them for you.

Final Thoughts

Things have definitely been better since I reset the keyboard dictionary, but there’s still the odd noticeable difference in iOS 7 autocorrect behaviour as compared to previous versions. For me the most noticeable is that in general it seems to suggest corrections/autocompletions much less often than did previous versions. This is sort of OK but it does mean you feel like you’re having to type a lot more.

Another comment I’d make is that with the form factor of the iPhone 5/5C/5S being longer and thinner than the 3GS and 4/4S, I don’t think Apple’s vanilla keyboard works quite as well because you have to stretch further to hit the keys in the centre. For me, at any rate, this seems to result in a few more typos.

There’s a lot of innovation around mobile and tablet on-screen keyboard design on both Android and Windows 8.1/Windows Phone 8. A good chunk of this is from third parties. Unfortunately this isn’t an option with iOS. I can see why Apple would be unwilling to open up the keyboard implementation to third parties, but it would be good to see them revisit it.

Hope this has been useful for you! And please let me know if you’re aware of anything else that might help.

Cambridge Mobile Application Group: What can app developers do with LTE-Advanced?

On Tuesday I went to Cambridge Mobile Application Group’s January meetup where Chandru Mullaparthi, Head of Service Development at EE, was talking to us about upcoming developments in mobile network infrastructure and the rollout of LTE-Advanced, which builds on the existing LTE (Long Term Evolution) standard and services.

The stats for LTE-Advanced are pretty impressive: the aim is to offer 1Gbps download, and 500Mbps upload. In a recent test in London’s Tech City EE were able to achieve 294Mbps download speed on a “category 6” device. More on what “category 6” means in a moment although, suffice to say, for now there are no such devices available on the market.

His question for us, as mobile developers, was, “What would YOU do with 300Mbps bandwidth?” Specifically, what kind of apps would we build? How would we use that much bandwidth?

Whilst some joker commented that “we’d waste it” and I have no doubt that badly written apps will do exactly that, it does raise many exciting possibilities.

The obvious candidate for high bandwidth is video, but it’s not just downloading video: that 150Mbps upload speed means you can also upload video in realtime. In fact, those of you already used to 4G service may have noticed a much better Skype experience than you get over home broadband for precisely this reason. Even the crappiest ADSL connection usually has enough download bandwidth to stream video. But upload? Not so much. Still, the current 4G LTE services offer speeds of up to 100Mbps download and 50Mbps upload with LTE-8, more than sufficient for a video calls, at least until you run into your bandwidth cap.

But I wonder if we might see new classes of apps emerging where media is being streamed effectively peer to peer in real time. Social and crowdsourced video could be interesting for travel (exactly how bad is that queue on the M4?), event management, and gaming – urban team nerf assassins with real-time video, anyone? (I suppose it might also increase the risk of being arrested for antisocial and disruptive behaviour, so use it responsibly. 🙂 )

On the downside it also raises the possibility of even more intrusive and disruptive forms of advertising but I suppose we’re all used to that by now, and will find ways to deal with it. I’m much more interested in the positive and creative uses.

All of this led to a lot of questions from the group and I felt a bit bad for Chandru because I’m pretty sure he wasn’t able to get through his whole talk. That being said he was very happy to take questions, and very open about answering them, so it was a good session.

Before I get into that, it might be worth a look at what LTE-Advanced offers.

LTE-Advanced Overview

LTE-Advanced is focuses improvements on 7 different areas:

  • Peak data rate
  • Latency
  • Spectrum efficiency
  • Spectrum flexibility
  • Cell edge user throughput
  • VoIP capability
  • Mobility

I’ve already talked about the peaked data rates, but lets look at some of these other areas.


The aim is to reduce the idle to connected transition to 50ms (this is the standard and it looks like EE are already beating this in their tests), which is significantly faster than 3G, and even faster than the current 4G LTE.

Since the roundtripping time is reduced you should then feel as if the device is connected via a hard line when using apps.

Spectrum Efficiency & Flexibility

I mentioned “category 6” devices, which aren’t currently available earlier. Current devices tend to be categories 3 and 4. One of the things this refers to is the number of antennae they contain. Currently two is quite common. Category 10 devices may have eight antennae, although it’s difficult to see how these could be made small enough to fit in your pocket.

The number of antennae is one of the factors that enables devices to offer such high speeds: they can use multiple antennae simultaneously to transmit and receive over multiple bands in the frequency spectrum. This is obviously complex but that complexity is hidden at the application level where you simply see one high-speed connection.

Cell-Edge User Throughput

This is somewhat related to the above. With LTE-Advanced it’s possible to transmit and receive data through multiple cells simultaneously. This means that, unlike 3G, where you see a significant drop-off in performance at the edges of cells, service quality and performance is maintained to a much higher level at cell edges.

VoIP Capability

Enabled by increased bandwidth plus the capability to request guaranteed bandwidth.


Improvements to mobility will enable handovers between cells at up to 350kmh and, for some frequencies, up to 500kmh – useful when travelling on high speed trains. LTE-Advanced also supports seamless handover between cellular and WiFi networks. The latter should be possible with devices available today but will require upgrades to software both on handsets and on core network infrastructure.

All of this seems great, and should mean that a lot of the problems commonly associated with mobile apps – high latency, flaky connectivity, poor perceived performance – may disappear, or at least be significantly reduced. Mind you, the group were quick to raise potential issues, which are worth looking at…

Issues for App Developers

What about bandwidth caps?

300Mbps is all very well but with bandwidth caps like we have today what’s the point? 5GB isn’t going to last you very long.

I can personally attest to this. Back in August I was in Seattle and Redmond with my friend Kevin and we were using his phone with a 2GB AT&T SIM that we managed to rip through in about four days with the following use: downloading emails (both his and mine with WiFi tethering), some light web usage, maps (mostly offline with Nokia maps), and one 20-30 minute Skype video call.

Bandwidth caps are either going to have to go, or be very significantly increased. People in general are annoyed by them so the former would seem like the way forward. All of this leads to another question…

Will the core network be able to cope with that amount of data flying back and forth?

Currently? No.

Chandru said there’s an arms race between what basestations and handsets support over the radio network, and what the network backhaul can handle, and that they are having to continually upgrade it to keep up.

And contention?

Your device might be able to support these higher speeds, but how many devices running bandwidth-hungry apps can the base-stations support? Will we end up in the same situation as we have with DSL, particularly in rural areas – i.e., nominally 8Mbps connections that at peak times can perform worse than the 56k dial-up connections of 15 years ago?

This is very frustrating for users, and the problem will be made worse if apps are developed on the assumption that the network connection will be fast.

The issue really comes down to the cell density in a given area.

Most areas are covered by macro-cells. These are large cells that provide coverage over a wide area. They tend to be supported by base stations with transmitters placed as high as possible, with good line of site over the widest possible area. However, they can only support a limited number of users and therefore tend to be used as a backup in more populated areas.

Urban, and more populated areas in general, tend to be primarily supported by much smaller cells, with therefore many more base-stations covering a given area. These allow large numbers of users to be supported in areas of higher population density.

If there are a sufficient number of smaller cells then contention should mostly become a non-issue, although I would expect that for large gatherings (concerts, New Year celebrations, etc.) we’ll continue to see the kind of network flakiness we still sometimes experience. This does also depend on what people are using their devices for.

What about pricing?

The rollout in London’s Tech City is currently non-commercial. If you’ve got a device that supports LTE-A, you can go ahead and use it for free at the moment. This is likely to change, and there will be a price premium on LTE-A services, as there is for 4G currently. As with all things mobile you should expect to see that disappear in a couple of years.

Will this supercede fixed line broadband?

Fibre is fast, at least compared to what many at least in the UK are currently used to, but it’s only a third as fast as LTE-A, so why bother with the cost of installing the infrastructure?

In many developing countries, India being one example, this is exactly what’s happening: they’re leapfrogging fixed line infrastructure in favour of cellular because it’s much cheaper to install. No digging up streets, laying cables, etc.

On the other hand fixed line can have certain advantages:

  • It’s more secure,
  • In theory at least it’s harder (or perhaps just more risky) to take the network down whereas, with the right equipment, I can easily disrupt cellular networks in my local area,
  • It’s possible to get guaranteed bandwidth, at least with a leased line, which is why they’re popular with businesses although still far too pricey to be within range of any but the absolute wealthiest of consumers (there are mechanisms for requesting guaranteed bandwidth over LTE-A but, of course, if too many users need it simultaneously this will degrade – I’m not sure how gracefully).

Fixed line isn’t likely to go away completely, even in developing countries, but in 5-10 years time for a lot of people it will no longer be the default option.

What effect does LTE-A have on battery life?

Chandru commented that when EE ran their LTE-Advanced test the device was plugged into the mains and became quite warm, so it sounds like it’s probably quite power-hungry.

One of the other attendees pointed out that Wireless AC already supports LTE-Advanced speeds but without significant battery drain, so it may not be that bad. But then wireless access tends to be over much smaller distances and requires lower transmission power, so I’d say this doesn’t sound like a great benchmark.

What will 5G offer?

The notable item Chandru mentioned here was consistency of bandwidth: the aim is to offer 1Gbps across devices. In the meantime therefore it does seem like we may not be able to assume too much in the way of bandwidth, and there were a lot of questions around how you detect what type and speed of connection you have. This is largely hidden by iOS at least, although it’s possible to tell whether you’re on a WiFi or cellular network. Android’s APIs are a little more accommodating and offer more detail, if you need it.

That’s it for now. Thanks to Chandru, for speaking, Tony Short, for organising, and Red Gate, for sponsoring the event.