Jounce as a real substitute vs other matured frameworks

Sep 3, 2011 at 6:44 AM

Hi, 

We are in process of introducing few architecture changes into our new large scale project. 

We would like to introduce few parts of jounce pieces. I would like to know few things. 

1) An overview of what are the factors that are present in PRISM which is not supported by Jounce?(like downloading of xap, regionapdaptor base support etc., i just need an overview :) )

2) does it really support Mobile/WPF portability?

3) Does it go well along with PRISM. if that is the case have we got any sample projects that shows how well it goes along with PRISM?

4) How well logging is available and extendable in Jounce?

And i have few more questions and really need ur answers before i proceed with the content?

Expecting you ppl help

Thanks in advance 

Silverlight Lover. !!!!!!!!!!

Coordinator
Sep 3, 2011 at 11:55 AM

1. I can't tell you all of those because I'm not a PRISM expert. I've used it in the past and for Jounce focused on the key things that I saw were needed in enterprise Silverlight applications. Jounce allows dynamic XAP download, Jounce supports regions, Jounce supports commands, Jounce provides property change notifications, Jounce supports pub/sub messaging with an event aggregator, etc.

2. No, Jounce does not directly support WP7/WPF. WPF is a possibility. WP7, no. It's a completely different paradigm on the phone so it didn't make sense to try to support it there. A well-written application should have decoupled classes that are shared anyway, so only the view and view model concerns would be different. We've built applications with Jounce on Silverlight and Ultralight.mvvm on the phone and there is probably 80 - 90 percent that can be shared between the code bases with the 10 - 20 percent focusing on the specific concerns of views and view models for the target platform.

3. Not sure what would prevent this

4. Yes - it is there and it is extendable. You simply implement an interface, export it, and you're done.

Sep 3, 2011 at 12:32 PM

Thanks Jeremy. i have always admired the kind of stuff that you are doing with Jounce. I am troubling you with questions since i have got the intention of using most parts of Jounce in my application. :) so apologize me for asking many questions :)

1) what is in store for further releases of Jounce?

2) what are the other Plugins/addins/frameworks that you would suggest using along with Jounce for general purpose silverlight applications?

3)  Do you foresee any situation/scenario where it's only possible through PRISM and not  through MEF/MVVM mode of constructing the framework elements as this would make me to convince myself and ppl when such questions arise during enhancement of our project's framework components.

Coordinator
Sep 3, 2011 at 1:20 PM

Thanks for the kind words! I appreciate you.

1. There will definitely be a Jounce release for Silverlight 5. I will likely work on some of this for the RC but also have a book project so it may be delayed. The release will feature things like custom markup extensions for tagging view models and a wrapper class to generate dynamic properties that provide property change notification on the fly. I may also take some parts of Sterling as an extension to Jounce for serialization to provide an alternative to WCF RIA for sharing complex object graphs between the client and the server. The issues list will drive a lot of what we do, based on votes, and currently the top voted items are WCF RIA integration (which doesn't really make sense because Jounce doesn't try to be the data connector, only the framework around it) and dialogs (which we will likely include).

2. That is tough to say in a generic way simply because there are so many and they will always depend on the target. I've seldom needed more than the http://lighttouch.codeplex.com/ library for multi-touch support and the Toolkit or third-party control vendors like Telerik, Xceed, Component One, and Infragistics for richer control sets.

3. I don't forsee this because PRISM is not a "all or nothing" package. It's intended as guidance and the main framework has pieces you can take. So if there is a piece of Prism you need, you can take that piece. I have yet to encounter a solution provided in Prism that can't be easily handled by Jounce but that's not to say I've encountered every possible scenario in the field.

Hope that helps!

Sep 3, 2011 at 2:32 PM

Thanks Jeremy. 

That would give me a very abstract understanding of what to look out for and what to consume from existing Jounce framework. 

Will get to you as and when i need your help. 

And i appreciate your efforts to bring a smart piece of work in action. :) 

Kudos to you, my Friend. 

Sep 6, 2011 at 12:48 PM
Edited Sep 6, 2011 at 12:52 PM

Hi Bharath, Jeremy,

Just want to add couple of points to this from my experience using Jounce for the last year or so. We have been using Jounce for a large LOB application. Some of it already in production and works good. We are still actively building SL application using Jounce.

1. There is a learning curve, it goes for any framework even for home grown ones. So if your developers find it difficult to use, please remember, they will go throgh the same experience for any other frameworks.

2. You normally use Framework for Commanding, Event handling and Region Management. Jounce supports all three, easy to understand and simple implementation.

2. Region Management and Navigations are very simple as event publishing. In my optionon it is the highlight of Jounce.

3. Currently commands are supported only for ButtonBase classes, so if you want to use commands for other UI controls, you have to use event triggers compared to eventtocommand style coding in other frameworks. IMHO 'Event Trigger' is very easy to implement. We have been using Event Triggers and behaviours and it works like a charm with Jounce.

4. After learing about Design Time Data, I never code without design time data. It is available out of the box in Jounce. If you never used design time data, I would recommend you to look it up and use it.

5. Feature request: Please keep in mind, Jounce uses MEF directly and explicitly. MEF has a limiation on dynamic XAP loading, if the dynamically loaded XAP is optimized using assembly caching, it will not download its depended zip files. It is not Jounce limiation, it is MEF limitation. In our case, we worked around it by adding all the required dlls in the shell XAP. Need to find a better solution for this.

6. Feature request: Even though Jeremy does not like the pop-up dialog, it is required for most of the development. I already posted the message requesting to add support for child window in the future release. (Please). This is the only issue we ran into when we were developing our application. We were able to work around the issue, but I really do not like the solution, It is not clean.

7. This is nothing to do with Jounce, rather, how you use your event publisher and subscriber. If you are publishing a message, anyone who are active in app domain will listen to it and try to act on it. Especially if you have multiple XAp files loaded, everyone will be ready to act on it. So use the messages properly and may be check the visual state before act on it.

7. You need to make sure, all the dynamically loaded XAP need to set Jounce.dll 'copy local' to false, otherwise you will have run time error.

Thanks,

Coordinator
Sep 6, 2011 at 12:54 PM

Thanks for posting this, ksunair! I appreciate you. And I want everyone to know that the feature requests are likely to be addressed soon. I'm integrating Jounce in my book on designing Silverlight business applications, using Silverlight 5, and will be slowly updating and addressing issues as I work through the examples so expect to see some changes. There is already a new build out for the Silverlight 5 to fix the issue with the SL4 version and backwards compatibility, look for more to come!

Sep 6, 2011 at 6:36 PM

First of all. Thanks to both of you. We have started to get hands on to Jounce to get a feel of it and started analyzing the areas where we can make full use of Jounce. 

As of our current requirement,  we desperately need an implementation of a Wizard/popup screen with multiple step roadmaps configured in it(each step is a xaml usercontrol from same or different xap's and finishing(closing) of that wizard should trigger an event in the parent/invoked user control. ). 

Jeremy,

1) What would be your suggestion/methodology to implement the same by making use of all of Jounce capabilities?

2) Is it going to be available in a fortnight or so as part of Jounce. (i would be the happiest person if i receive this implementation ;)  )?

Ksunair, 

Thanks for all your comments.

1) We are actively looking into the MEF's dynamic xap download limitation. We are planning to use the same .extmap file/xml file to find out the dependent file and start downloading it as and when Jounce downloads the main xap file. once all the xaps are downloaded we should fire the activated event. As and when we get a better way of implementation we would be happy to share the same with you guys. 

2) Can you let us know the workaround that you followed to accomplish the popup dialog feature. 

 

Thanks,

Coordinator
Sep 6, 2011 at 7:32 PM

I've always found we had far more control by introducing a pop-up region, so the app is layered like this:

[----- popup region -----]

[----- content region -----]

So that sending a view into the pop-up region automatically overlays everything else. Inside that, there can be a rectangle with opacity to cover the areas you want to avoid click-throughs with the "dialog" as really just a stylized view on top. For the wizard you have the option of either making several controls, or a single control and manage each "step" as a visual state. The technique for the pop-up is described in this blog post:

http://csharprambling.wordpress.com/2011/08/18/creating-popup-dialog-using-jounce-region/

I will likely include child window dialogs as a first-class citizen by the end of the year - it depends on how extensible the reference implementation I have is though, we've done it in a few projects so I just want to make sure it can be used as a tool and doesn't force the user.