Dynamically choosing a UI library

Hello All.

I'm working on an educational app that is targeted for ages 6 and up. I've got two versions of the UI library, simple (for the youngsters) and normal (for the not-so-youngsters). Both libraries are self-contained and localized, so UI upgrade is simply a matter of file replacement.

The user can switch between normal and simple at runtime simply by selecting a menu command. The way that I'm doing it now is by maintaining a persistent UIState variable and checking it each time I need to open a form. That's the problem.

I'm wondering (can't find anything on the forums or in MSDN) if there isn't a way to make the check once, initially, and responding to the user changing the option, and not having to check again. Basically, switching between the two UI libraries only if and when it is necessary.

Now, I've considered using LoadLibrary and FreeLibrary from Win32, and I may still wind up doing that. I haven't decided yet. The way that I'm doing it now works fine, but somehow it just doesn't sit well with me having to make the same decision over and over again. And, I'd rather stay in managed code if there's any way to do it. Any ideas




Answer this question

Dynamically choosing a UI library

  • NetPochi

    Hi Mark,

    I think it might be better to do things in the reverse: Define an interface, and have two objects which implement that interface, like so:

    public interface IEducationUI

    {

    // some properties and method declarations

    }

    then..

    public class SimpleUI : IEducationUI

    {

    // implement the IEducationUI members

    }

    public class ExtendedUI : IEducationUI

    {

    // ditto

    }

    And in your application...

    IEducationUI currentUI;

    // users selects which ui to use

    if(simple)

    currentUI = new SimpleUI();

    else

    currentUI = new ExtendedUI;

    and then just use currentUI for drawing/forms/etc.. Would that work

    I am currently working on an application where 8 objects do basically the same thing to the external world, but have very, very different data management schemes. So for them, I defined an interface that the master program knows about, and each subclass can do its thing without needing to know anything about the master application. These subclasses have definitions for all kinds of forms and buttons, too, so this isn't just limited to member variables and function calls; you can have interface methods for showing forms and stuff too.



  • YWLMB

    Hello All.

    Bhanu:

    Yes, that's what I meant by persistent. I should have been clearer. The UIState is stored in the user's isolated storage and the app is started according to the saved value. So, in most cases, once the user has made his or her choice, then it will pretty much stay there.

    It just grates on my sensibilities to have the same check decision in so many places in my code. Since the UIState can change any number of times in the same execution session, the UIState variable must be consulted to fetch the correct style of the form that's about to open.



  • Wesley Wong

    Hello All.

    Phillip:

    Thanks for your reply. Yep, that's about what I came up with from knocking up a couple of prototypes. I had to stop and back up a minute, because I was trying to tackle it from the wrong end. Just about the time I had a really good handle on inheritance and casting between base and derived classes in C++, I switched to C#, and now pretty much all I have is a constant low-grade headache. I swear, un-learning is much harder than learning.

    Sweet!! Now I can go take a hatchet to all of those if statements. Thanks again.



  • invantix

    Hello All.

    Patrick:

    Hey, that's not a bad idea! I haven't really needed to use interfaces much in the past, so if you would be good enough to check my thinking on this, I would appreciate it.

    IIRC, explicit implementation would do the trick for me. If I define separate but identical interfaces for each of the UI libraries, I could then define a class that inherits both and could return an instance of whichever form was called for, based on the accessor properties in each interface, and the currentUI request state.

    As I say, I haven't used interfaces much and I'm going to have to get some reading done and prototype this, but off-the-cuff it feels like I might be missing a step.

    Thanks for the help.



  • Moonshadow

    Hi,

    Did you try storing this flag in the user profiles So that you can cache user credentials and load according to user role.

    thank you,
    bhanu.



  • Frank_Booth

    Mark,

    How much control over the UI libraries do you have Is this something you're writing yourself

    I don't know if this is feasible (it probably won't be if the UI libraries are significantly written and very different) is define an interface the UI library uses. Then in your application, load BOTH libraries. Anytime the choice of library changes, set the current library to the appropriate one, and only ever use that "current" reference to do the drawing.

    Would something like that work Your problem sounds like a perfect candidate for an interface..


  • Dynamically choosing a UI library