One of my favorite journals is The Architecture Journal: Input for Better Outcomes, published by Microsoft. I can usually count on it for in-depth, high-level articles about current technologies and design practices, and I was excited to see an issue devoted to one of my favorite topics: mobile architecture. Although it now requires a Live ID registration, it’s free, and I highly recommend that you take advantage of it. In fact, you should even go back and read the old issues. (There’s a cool beta of a reader for this journal that you can download here.)
That being said, I have to admit I’m rather disappointed with this particular issue. Though I understand that not all mobile solutions will run on Windows CE or Windows Mobile devices, that UMPCs and tablets are considered part of the same market, still… broad remarks are made that don’t even hint at current limitations in the technology—information that architects considering mobile projects would find useful to know.
For example, the first article advocates the use of Microsoft Synchronization Services (“which lets application developers easily add synchronization…”), but fails to mention that it doesn’t support Windows CE or Windows Mobile at all (and who knows when it ever will, or how crippled it will be when it is finally supported?).
The article on extending enterprise applications to mobile devices touched on most of the same issues that I’ve run into over the past several years, but is so narrowly focused on a singular strategy and implementation that I felt it failed to present a more useful, and more abstract, treatment of the issues that could be appreciated and applied in vastly different scenarios. The long lists of best practices such as “use database stored procedures to write wrapper code for faster data access” represents, I believe, one philosophy of data management in general, and is not wholly relevant to the topic of mobility and its specific ramifications. What of the update statement that gets executed only a dozen times daily: will 20 milliseconds of faster execution time be worth the accumulated hours of maintenance and updating of those extra database objects as the product evolves? How many development assets do you want to manage, if you can use an ORM solution like LINQ without incurring that overhead?
Likewise, recommendations to include a history table for every regular table, where you do only inserts and never updates based on triggers, begs the question of “where the hell do you get all of this storage space on your mobile devices that you can be so wasteful?” You’re really going to make a copy of records from multiple tables when a single row in one of the table is updated in any way? Every time?
While the article on Test Driven Development and Continuous Integration for Mobile Applications was one of my favorites (the other being an article on automotive applications), the author mentions his open source project wMobinium.net which provides automated testing for mobile devices. Is this solution necessary now that Visual Studio 2008 supports automated tests for mobile devices? Isn’t this guy rather late in announcing this project? (I don’t know, as I’ve only toyed with VS2008’s mobile testing a little and am not aware of its shortcomings.) He also mentions his appreciation for the release of Compact Framework v2.0, so either this article was written a while back (and is now stale), or this guy doesn’t realize that v3.5 has been out for a couple months now, with betas and CTPs going further back.
When I read an architecture journal, I expect deep, insightful, relevant, up-to-date material by those who preferably have implemented more than one system, and have learned valuable lessons in different contexts that they want to distill into wisdom and share with the community. Where I have been impressed with past issues, I believe this one has fallen short. Maybe I’m extra-critical because of my familiarity with the subject. You be the judge.
But I still look forward to the next issue. And it encourages me to start jotting down some ideas for future articles of my own. What are the real gotchas in mobile development? If we had a map of these pitfalls, and the corresponding opportunities…
To be continued.