Thank you in advance for your assistance.
Our team has been spoiled by MS P&P Enterprise Library/Unity as we have made great use of the DI, Exceptions Management, Validation and Logging Capabilities. Traditionally, our front ends have been forms based (Windows Forms, ASP.NET, etc).
As we approach WP7 development, and understanding it is a new platform with much less resources, we are looking to leverage existing frameworks, open source, etc that may exist that deals with these issues on the WP7 client (excepting copy left licensed code).
We are definitely going to implement Prism on WP7, and have started our initial research into the Prism framework capabilities in these areas. It's a great framework, and our initial assessment is that is for legitimate reasons it is more focused on the composite architecture, and we need to use Prism as the architecture to do a little bit more implementation on our own of cross cutting exceptions management, etc capabilities building on the baseline that Prism provides.
Just wanted to confirm, as we have not been able to identify any, that there are no open source or other frameworks out there for WP7 with the Enterprise Library coverage on exceptions management, validation and logging?
Thanks again.
WP7Contrib has lots of support for logging, DI and (much) more.
well you could use Caliburn Micro
Global handling exception in WPF app with Caliburn.Micro
not sure if this goes down with the PRISM well though
22 sept 2011
there is siverlight integration on the enterprise library http://msdn.microsoft.com/en-us/practices
Related
I'm fairly new to Xamarin development, but I've started doing some experiments with Xamarin.Forms and I'm really liking it.
Now, I've discovered MVVMCross, and it sounds interesting for developing apps that have separated UIs for each platform, but I'm trying to find updated information regarding how (and if / why) it may tie in with Xamarin.Forms (mvvm's docs has a page for this, but it's empty ATM).
Is there any currently-relevant information I'm not being able to find? (all results I'm finding seem to be too old and not really helpful, please correct me if my google-fu is just not strong enough)
Well, for lack of better replies. From this blog post:
(...) it is crucial to understand that neither MvvmCross nor Xamarin.Forms is a replacement for one another. While both of them provide infrastructure modules that help developers in their mobile application projects, Xamarin.Forms is a UI technology stack that enables common XAML declarative UI implementation for target platforms; MvvmCross is a framework that enforces clear distinction between the UI elements and core logic implementation. Either of them alone or together can increase the shared amount of code in cross platform projects.
I am trying to evaluate whether Xamarin would be a good option for my project. The project is a large, complex app for Android and iOS with a lot of client-server communication. The user interface is a major focus and has to be really fast and smooth. Also, we plan to make large use of UX graphic effects (comparable to the Spotify app).
For now we are planning to go for two separate native apps using Java/Objective-C. However, the possibility of cross-platform code sharing would be very convenient for us of course.
Most opinions I've heard so far say that Xamarin - although far better than HTML5 apps - cannot match the UX of a native app. Also, I tested the following applications made with Xamarin (on Android):
Rdio
MarketWatch
Busch Gardens Discovery Guide
Sqor
Storyo
From my impression, none of them could quite match the speed and smoothness of a good native app.
If our focus is on a top notch user experience, would Xamarin really be a viable option? Can it really match a native UX? I am particularly looking for opinions from developers who have experience with large and complex cross-platform Xamarin applications. A few critical voices would be very helpful.
Thank you a lot!
I'm on the Rdio mobile development team, so I can make some personal reflections from that standpoint.
Xamarin allows you to write native applications in C#. Any slowness, jankiness, ugliness or bad-appiness usually has nothing to do with the Xamarin layer itself.
You save some time being able to share core business logic between your different clients, but you're still writing the UI from scratch, specific to the platform. You're just writing it in C#.
But while you save that time, you're spending it in other ways. All of those SDKs you want to use probably aren't compatible with Xamarin out of the box. You won't be pod install'ing that iOS framework, and you might be reinventing the wheel for handfuls of things. Xamarin takes advantage of the NuGet repo so you have a library of components that handle many of the things most people need (Analytics, Testing, Facebook SDK, JSON parsing, Database, etc etc) but it doesn't cover everything. And it certainly doesn't cover stuff that's out the day of an Apple or Google product announcement.
Any 3rd party code that you do want to import into your project will be done through writing custom bindings. While not usually difficult, it is time consuming. Xamarin has a team of people that specialize in assisting you in this. This fact speaks to the process being messy at times.
So while the slowness, jankiness, ugliness or bad-appiness probably isn't the fault of Xamarin, it might be the fault of you spending time in places you normally wouldn't, or not being able to take advantage of features you normally would. If that 3rd party partner SDK is giving you problems, your troubleshooting may take twice as long because there's a layer that you don't control.
UI is a wash. You're writing it from scratch anyway.
Business logic is shared. Depending on the app that might be a win if you architect your application to take advantage of it.
Compatibility / bleeding edge ability will be lacking. That might not matter to you at all, or you might be the person wanting to take advantage of that hot new API in the next OS release the day it's announced.
My personal thought, without knowing specifics, is if you want to build an application that you plan on being around years from now, and that will take advantage of the latest and greatest, I'd tell you to write natively for each platform. Unless you can really see huge gains in sharing that business logic the upfront gains are minimal. Or if you really like C#.
Xamarin uses native controls. So you design a fully native UI per platform. The users can't see that your App is made with Xamarin or Java/Objective-C.
There are sometimes performance issues in conjunction with the platform independent UI wrapper Xamarin.Forms. But you're not forced to use it. When you have still performance issues in your Xamarin.Android or Xamarin.iOS app then you produce them in your code.
There are benchmark results for Android apps comparing Xamarin.Android and Java apps: Does anyone have benchmarks (code & results) comparing performance of Android apps written in Xamarin C# and Java?
As you can see Xamarin's internal performance became better and better over the time.
Conclusion: Yes, you can write smooth native Apps using Xamarin.
I'm would like some advice on the best data persistence solution to use for an application that will run on the desktop (WPF) and on Windows Phone 7, sharing data between both applications. Ideally I would like to use the Entity Framework. I have considered the following technologies:
Sync Framework 4.0 - only CTP at the moment but has the big advantage of offline use. However it is an immature framework that does not allow me to use Entity Framework and seems not to be very mainstream, requiring a fair bit of a learning curve to get working.
WCF Data Service - has the advantage of allowing me to use Entity Framework. However there seems like a bit of a lag when retrieving data and off-line use is a problem.
SQL CE with syncing to centrally hosted database using Sync Framework 2.1 - will work for my WPF application but not sure about the phone.
There are so many technologies available it is difficult to "see the forest for the trees". I'd like to stay fairly mainstream if possible just to make it easier with getting help and finding code samples etc. I'm open to any suggestions or guidance.
Unfortunately, SQL CE is not currenlty supported on the phone so you'll need to use one of the other available databases there.
Although it's only in a CTP format I'd recommend giving Sync Framework a look. It your synchronization requirements are anything but trivial you should really avoid reinventing the wheel by writing the synchronisation service yourself.
Even if you did use the Sync Framework, I don't understand why that would stop you using Entity Framework on the desktop.
AFAIK there are currently no ORMs for the WP7 so you'll have to create your own DAL there.
What I want to create is a Silverlight app with a few tabs/modules that will all be separate DLLs.
I see PRISM has the Shell/Module concepts that seem directed towards doing UI and I find a nice demo (showing how to search digg/twitter).
But it sounds like MEF will be included in VS2010 so I would like to go with that option.
Can anyone somehow clearly explain the differences? (I am not a advanced programmer)
MEF and Prism serve two very distinct goals.
Prism is basically guidance for designing composite applications - where you have a shell and "regions" that are dynamically assigned, and integrated. It includes an IoC container (Unity) that it uses for it's injection.
MEF is a dependency injection framework - it's main goal is to "fill in" depedencies at runtime for an application. In this respect, it's filling the same goal as Unity does within Prism (and, in fact, you could pretty easily rework Prism to use MEF instead of Unity).
Prism fills a broader scope, in some respects, but is also really limited to GUI applications. MEF is just doing one thing (Dep. Injection), but geared to be more general purpose, for any type of application.
As for the lifetime of these products -there is no answer here, but this is kind of how they're being developed:
Prism was developed by the Patterns and Practices team. The goal isn't to necessarily make software, but to provide guidance. As such, they update (although somewhat infrequently) the Prism library and sample, but Prism isn't a core part of the framework shipped by Microsoft. It's really a third party library (even though MS funds a lot of it, most of the P&P people aren't MS FTE).
MEF, from the blog posts, sounds like it is planned to be integrated into the framework, and be used directly inside of MS projects. As such, it's getting heavy development, directly from Microsoft, and being used in their products.
I, personally, have read through the Prism documentation (and have the book), and have gone through the samples. It is very helpful to understand how to break apart an application, but it really is guidance more than a complete, usable framework. The samples are very good at doing what they're designed to do - educate an architect in how to design a composite application.
If your goal is to just keep a clean separation of concerns in a silverlight application, I'd focus more on learning MVVM than necessarily just using Prism.
If you want to use MEF, there are other good options. For example, the WPF Application Framework is an entire MVVM framework built on top of using MEF, and fairly nice.
Basically, MEF is a general-purpose extensibility framework:
If you are building extensible applications, extensible frameworks and application extensions, then MEF is for you.
whereas Prism is mostly for building GUIs:
The Composite Client Application Guidance is designed to help you more easily build modular Windows Presentation Foundation (WPF) and Silverlight client applications.
So MEF and Unity are basically the same...
Well, not exactly. MEF is more focused on extensions which aren't known at compile time, while IOC containers generally focus on dependencies which are known at compile time. The top answer to this question gives a good explanation of the differences.
Yes. Check these two posts for more:
http://blogs.msdn.com/gblock/archive/2009/12/02/mef-and-prism-to-be-or-not-to-be.aspx
http://blogs.msdn.com/dphill/archive/2009/12/09/prism-and-mef.aspx
I've been programming for over 15 years and started with .NET 5 years ago. We built our framework for windows data-oriented apps and it is a quite stable.
At this point, we are considering to make a new platform. But, I am a little bit confused with all these new technologies. We considered CAB and SmartClient technologies but there are also WPF, WinForms and Silverlight options in there.
It sounds like you just need a quick overview of the technologies you have outlined there.
WPF: Windows Presentation Foundation - a new graphical rendering system for building interfaces based on the XAML markup language.
WinForms: Windows Forms Applications - Visual Studio's classical drag-drop GUI.
Silverlight: a Web Application framework - usually used with WPF, very similar features
ASP.NET & MVC: ASP.NET is the web application framework used in conjunction with C# and VB.NET used and MVC stands for Model-View-Controller - a design pattern that has actually been around for ~30 years
Without knowing the true intricacies of your framework, what you need it to do, what limitations you have - I can't say X would be better than Y - especially seeing as WinForms and WPF is used for desktop applications, and Silverlight, ASP is used for web applications - unless you're thinking of linking these in with each other? You haven't given enough information in your question.
However, the best for investing in the following 5 years? The most recent and still in development technologies are WPF, Silverlight and the ASP.NET MVC - but nobody has a crystal ball to say whether these will still be alive, kicking, and technologically advanced in 5 years time.
We built our framework for windows data-oriented apps and it is a quite stable. At this point, we are considering to make a new platform.
For your specs, all choices might be very good :)
I know that, but what you think is the best for investing in the following, let's say, 5+ years?
If you have a choice ( meaning if you are just displaying data without all the fanciful animation, movie and game like stuff), use ASP.NET MVC.
I always advocate web applications over desktop ones, because web apps are hosted in a single place, and so they won't produce upgrade nightmare.
In terms of which one has the brightest future, well, none of us have crystal ball and we don't know what Microsoft will throw at us in a few years time. But you should orient your apps around your business, not around fashion. If you really ask me out of the so many, which one will still remain standing 5 years later, I would say ASP.NET MVC, because ASP.NET is a mature technology, and MVC is a tried-and-true design pattern that has been used by open source and non-MIcrosoft companies. The fact that it is widely accepted makes it less likely to fade out of fashion.
If you want to continue with creating desktop applications, then your two major choices are WinForms or WPF. WPF is the "hot" technology right now, but there are a few things to consider before choosing it.
WPF requires .Net 3.5 (maybe it's 3.0, but whatever). This is significant because many corporate customers are still using .Net 2.0, and may not authorize upgrading to 3.5 for some time (my former company still has some clients that haven't authorized moving from .Net 1.1 to 2.0 yet). Also, the installer for .Net 2.0 is 23 MB while the installer for .Net 3.5 is close to 200 MB, and the 3.5 installer appears to be buggy, failing occasionally with a helpful "SETUP Error" message.
Developing with WPF requires Visual Studio 2008. If you're currently using an older version, you'll have to upgrade.
This isn't completely true, but for the most part what WPF brings to the table is a much snazzier user interface. In my experience, corporate customers who are paying big bucks for custom software do not care in the slightest how the application looks - they only care that it functions well and that it ultimately saves them money.
Finally, if you already have experience developing desktop applications for Windows, then you will feel right at home going the WinForms route. Also, because of the Mono project, a WinForms app can (theoretically) work on other platforms like Mac, Linux and the iPhone, whereas this is not yet possible for WPF (I might be wrong about this, and I will happily correct myself if someone points it out).
I'm actually sort of torn about this advice, because I think WPF is very cool and powerful, and it may take off and become the only viable way of developing for Windows very soon. It is a risk, however.
Thank you all for answers !
We tested all platforms and we have at least one project finished using MVC, WPF, Silverlight, WinForms...
The main problem with WPF and Silverligth is missing of native ReportVIewer controls since we have a lot of reports (RDL) created.
Personally, I think also that MVC is best structured framework.
I really have positive thinking of MONO. But, I would rather decrease the price of the project so the clients can buy WINDOWS but to handle bugs in Mono-Linux option.
We decided to follow the Microsoft way.
I'm thinking of some kind hibrid framework (Webservice - SQL SERVER- ADO .NET Entity Framework) to be on hosted on server and hibrid CAB-SMARTCLIENT to be usen on clients.
I really miss the times where only one tool and technology was available like Levi's 501 :)