How Large Should Your Windows Phone 7 Apps Be?
I was having a conversation with Chris Tavares of the Patterns and Practices group (the Prism guys). We were talking about the future of Prism (et al.) and the topic of the Windows Phone 7 came up. While MEF, Prism and Unity might make an appearance on the device, the real question to us was why.
Its not that phone applications do not need proper architecture to be maintainable and testable, its just unclear to me that using a composition framework (Prism and/or MEF) are going to help in that way. I could see a IoC container (Unity, MEF-sort of) there but mostly for testability.
I mention this because I want to make sure that people remember they are building apps for a phone, not for a laptop. I think it would be easy to over-build and not depend on the 'cloud'. (As an aside when I talk about the cloud, I mean any data center...not necessarily Azure or EC2.)
The big picture to me is that the phone is for the user interface, not for the guts of an application. There are additional benefits there in that it can improve scalability as well as being able to implement same/similar applications on other devices. If you're not sure I am right, turn off the Internet on your phone (assuming you're on an iPhone, Blackberry or Android) and see how many of your applications work. Keep that in mind when you're architecting your phone applications.
Based on a work at wildermuth.com.
Mobile apps vs Mobile devices they run on. Theres a big difference. The mobile devices of today will drastically change in 1-2years time. We may actually have mobile devices that let you output thru HDMI to screens. Thus the small form factor screen wont be an issue. So the mobile apps we build can technically be run on somethng much larger than current generation devices. 
You can say that again, and I hope it sinks into developers heads.
It's a very good point, and the reason why I've been telling people that the refrain that every Silverlight developer is now a mobile developer is only *mostly* true...as in physics, things behave differently at very small scales, and it's a mistake to treat the phone as if it's a small desktop. I believe strongly that in view of the memory and CPU (and therefore battery) constraints every piece of code we run needs to justify its existence. Sometimes reaching for a framework is convenient but lazy, which is why it's a good exercise to see what's the minimum amount of code you need to implement for instance (as a simple example) useful MVVM...you may not always want or need to do it that way but it's good to know how when the need arises.
I agree with you to an extent, Shawn. There is no need for people to over-architect phone solutions to the point where they are creating all of their libraries with separation of concerns in place, as well as fully breaking down their architecture as they would on a proper desktop-level application; however, I do believe that developers should still follow their patterns, where a project folder can serve as an elegant means of organizing a single assembly the same way a separate class library would in a larger application. 
re don't believe me, turn off your internet
Actually, I would say that IoC is still essential. Many applications have multiple cloud services that could/should be interoperable. Being able to mock those cloud services also is essential. I would like to see greater modularity - especially on the UI components. No matter how small.
Just a quick comment that if the app is greater than 20MB in size (xap), the end-user can only download the app via wifi or the desktop client. Once downloaded an app can download additional content into isolated storage.
It is incredibly refreshing, though, that we can have a conversation as to the applicability of a desktop and RIA framework/platform. Seeing MVVMLight, Caliburn, NInject Windsor, etc being organized to target WP7 is fun to watch.