Archive for the ‘LMD’ Category
The week before last – I set about updating the WP7 Sports engine that’s used to drive the mobilewares sports apps (currently using it are AU Footy 2012, AU League 2012 and Sup-Rugby 2012) – and along the way decided that it would be a good opportunity to implement Low Memory Device (LMD) support.
Before I go into the LMD thoughts however – here’s some pics of some of the new (non LMD specific) features which these will include (screenshots taken from AU Footy 2012 – but others will have same enhancements) :-
(Left) New home page which aggregates latest results, upcoming games and the ladder filtered to your team.
(Right) New tabs in the Team viewer page – such as the ‘results’ tab where you can view all games played for the year and the current standing in the ladder.
Apart from new features (and what’s pictured above) – the LMD support in these apps essentially now means when you view maps and web pages – the external o/s apps are launched (rather than it being embedded in the page) – bringing the memory consumption down to the acceptable amount.
LMD Support Thoughts and Suspicions
For those that haven’t heard about LMD before – in a nutshell – there will be a bunch of low cost Windows Phone devices released this year – aimed at developing markets (and the lower cost end of the smart phone market – where Android has a massive share). These devices will be restricted to only 256mb of memory – half as much as majority of existing handsets – and will have certain core features stripped from them (such as ability to use background agents). One of the upcoming LMD devices already demoed is the Nokia Lumia 610 – and more are rumoured to be on their way (from manufacturers like Huwei).
I’ve been in two minds about LMDs’ – one being that it could be the vital ingredient to making WP7 a successful platform (by getting it into loads more markets + market segments previously ignored) which I’m all for – but secondly (on the flipside) – I’m really concerned about the potential fragmentation of the platform which will inevitably come about by this.
It’s important to note that lack of fragmentation was one of the key things that MS more or less alluded would never happen on WP7 (and given as a reason why WP7 was a better dev choice than android) – so I’m a little surprised to see this happen. The net effect of LMD being introduced is also that many developers will need to go back and update + resubmit their app’s – simply because these devices are not 100% backward compatible .
Digging Deeper into (potentially unnecessary) LMD Restrictions
When I went through the steps of implementing LMD support (thanks to a great article at Best Practice Tips for Delivering LMD Apps ) – I began to become a little more suspicious that this fragmentation (which developers would wear the brunt of) – was somewhat unnecessary. In fact – would have to say it’s either come about by a lot of laziness (or lack of time to do things properly) by Microsoft – or a direct intention to fragment the WP7 market and create the distinction of have’s and have-not’s.
If you read the article linked above – the crux of what no longer works reliably or at all (in order to ensure your apps don’t use more than the ~50mb allowed) fall upon three main areas – their Silverlight Bing Maps Control, the Silverlight Web Browser Control and lastly the clincher restriction – that background agents will not be allowed.
With the case of the Bing Maps + Web Browser controls – the message is – well hey you can use them – but we wouldn’t recommend it as loads of memory *may* be used (which of course you don’t have any control over as a developer) and your apps may crash. This struck me as quite odd – as surely Microsoft could have gone to the effort of enhancing these controls so they ‘degraded gracefully’ and worked within the new memory confines (by offering less caching/buffering/image quality etc – or at bare minimum – not crashing the app hosting it). Putting it back onto the entire developer community to update their apps (because they couldn’t fix their own components) – particularly with all the problems + delays with Marketplace certification – seems to me to be quite an ask.
With the background agents - particularly periodic tasks (the ones that can run every 30 minutes and do stuff like updating live tiles etc) – again it struck me as really odd and unnecessary that these were now no longer able to be used. Keeping in mind the memory limitations on developers writing background agents are extreme – only allowing developers to use 6mb of memory in the process – so surely these didn’t need to be dropped from the LMD platform.
I pinged Justin Angel (who I believe wrote the article above) – who had mentioned that basically it wasn’t because a single background agent (using ~6mb) would be an issue – it’s that if several of them were running at once then it would require a whole lot more memory (ie. 10 agents =~60mb). So I asked why not just ensure only one can run at a time (as a LMD restriction) – ie run them one after the other – and was basically told there was some (strange) notion by Microsoft that developers expect agents to run dead on 30 minutes and 0 second intervals to be useful (and running them sequentially was not acceptable).
Personally I’m not clear of any existing App which would not function properly if an agent ran after 31 minutes or 29 minutes etc. instead of bang on 30mins 0 secs etc.. I’ve never ever had an end user request anything like this either – just that the agent runs ‘roughly’ every 30 minutes (as opposed to not running at all).
I as a developer would have welcomed background agent support in LMD at the cost of any reliability of intervals (and lack of parallel tasks) – without it I now have to go and update and resubmit an app which had no other issues whatsoever with memory – and without out it users can’t utilize a vital and important part of my app. Any claims by Microsoft that background agents shouldn’t be a core part of your app are seriously misguided and out of touch with what end users are not just asking for – but demanding.
Summary / Thoughts
My conclusion/thoughts around LMD are that Microsoft really could have done this quite a lot differently – and just didn’t think (or care) about the ramifications to developers – and to end users (who are likely going to be quite confused by this fragmentation). As mentioned – the main issues for existing apps on LMD are not the apps themselves but the controls Microsoft provide with the platform – the bit they are supposed to be handling.
I strongly suspect (as with many dev related WP7 matters) there was little to no consultation with the ‘real world’ app developers about this by MS – and they locked themselves away in a room and tried to ‘second guess’ what they thought developers wanted (or that as suggested above – MS intended to fragment the market for some strategic reason). I just can’t possibly see how any developer would have been OK with what they drummed up.
It’s probably too late for them to do a u-turn on this unfortunately – but I do wish they had just spent a bit of extra time in order to get this right. I’m really personally excited by what these new low cost devices could do for the WP7 market share – so I hope this additional effort/sacrifice developers will need to go to will pay off.
my 2.56 cents