How to build different interfaces

  • Thread starter Thread starter Lonifasiko
  • Start date Start date
L

Lonifasiko

I need, according to the user's own settings and PDA knowing to build
different interfaces, that is, a experienced user can see forms with
tabs but a user with no experience in PDA using, would see the
application with very simple forms, for example with big buttons and so
on.

Then, what is the best approach to achieve this goal of different
interfaces? Add controls at runtime (tabs for the advanced user and
buttons for the newbie user) or have different built forms and
show/hide them depending on the user?

I've not tried but second approach seems to be more effective and
faster I understand. And as far as I'm concerned, adding controls at
runtime can be a tedious task when many controls have to be placed I
think and it's more difficult to develop.

Any idea or similar experience will be greatly appreciated. Thanks very
much in advance.
 
Seperate your application into several projects, at least :

1 project for business objects
1 project for user interface process (everything used by UI layer, but not
visible, wizards steps objet for example)
n project for each versions of your application.

This model requires a little bit more lines of code, but it permits you to
keep the designer of VS.

Steve
 
Thanks Steve for your reply but I don't understand your approach very
much.
The main idea is that when beginning the application, depending on a
user's configuration file or some parameters read from database, load
his corresponding way of seeing the application. If I want to build 5
different interfaces, you mean building 5 different projects and
loading the suitable DLL that targets his preferences? How would you
implement this idea of separate projects?

If you could explain me your idea in more detail please would be really
nice.

Do you think it's better to have separate projects (your approach) or
separate forms (my initial aproach) for each interface rather than
adding controls at runtime depending on a if-else statements chain?

I would love hearing more ideas or personal dealings with this kind of
projects.
 
Adding controls att run time would disallow you to benifit the power of
VS.Net designers.

However, you can construct into the same project 5 forms different forms for
5 different interfaces....

In the initial method (main), get the user prefs, and launch the desired
form

class starter{

static void main()
{
UserPrefs up = UserPrefs.GetPrefs(); // a custom code to get the prefs
UserInterface ui = up.Interface; // we supposed the prefs object store
the interface of the user

Form f;

switch(ui)
{
case UserInterface.VerySimple:
f = new frmVerySimple();
break;
case UserInterface.Simple:
f = new frmSimpl();
.....
}

Application.Start(f);
}
}

enum UserInterface { VerySimple, Simple, Advanced, Expert }
 
Hi Steve, I was thinking exactly the same around the example you have
given me. That was my idea. Get user's preferences and the show/run the
appropiated form.
This way I benefit from VS.NET designer but the code can reach
unmantainable in the future, because a little change in a form obliges
to change in the other 'n' forms. Another thing is that the application
will be quite heavy, with a heavy .exe that will cost much time to
initialize. That's why I was asking for any other better solution.
However, I'm afraid my options are quite limited in this road.

You told me about building different projects for each interface. Is
better the approach of 5 forms in the same project or 5 projects, each
one related to one interface?

I need more opinions please! Meanwhile, I'll start with the approach of
different forms and I'll finally forget adding controls at runtime.

Thanks very much.
 
With .CF.Net, most of the code is in the runtime itself. Your application
won't take hundred MB...

For example, a complete application on which I'm working (6 projects --> 5
..dll and 1 .exe) take less than 500KB, including some graphics...

To raise maintainability, try to export as many code as you can in separated
classes... Controls on your page will only call this code.

Imagine two drop down list box that are linked.
The first display countries, the second biggest cities of each country.
When you select country, the second drop down list should display only
cities of this country.

We often catch the selectedChanged event of the first, and in the method
handler, we update the datasource of the second.

The idea is to encapsulate this behaviour into a separate class, and make
only one call in each form.

ex:

public class CountryHelper
{
private DropDownListBox _ddlCountries;
private DropDownListBox _ddlCities;

public CountryHelper(DropDownListBox ddlCountries, DropDownListBox
ddlCities)
{
_ddlCountries = ddlCountries;
_ddlCities = ddlCities;
_ddlCountries.SelectedIndexChanged += new
EventHandler(ddlCountries_Changed);
}

private void ddlCountries_Changed(object sender, EventArgs e)
{
_ddlCities.DataSource = CountryBusinessObject.GetCitiesByCountryID(
_dllCountries.SelectedValue
);
}
}

And in the form :

public void Form_Load(object sender, eventargs e)
{
CountryHelper ch = new CountryHelper(ddlCountries, ddlCities);
}

AS you can see, most of the code is in a separate class... in the form there
is only one line.

A good link is :

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/distapp.asp

Take a look in the user interface process layer, it goes in the same way...

Hope that help.
 
Just a thought since you asked for more opinions. First, try to implement
what Steve has suggested as far as separation of visual elements and the
"real" code behind them. This will make maintenance a bit easier when it
comes time to either make changes or extend to another UI. Second, and here
is my thought, try custom controls. Composite controls more specifically.
This is if I understand your problem.

If you have UI-One where you present a set of data entry fields broken out
on to tabs. (E.g. customer basic info on tab 1, address on tab 2, preferences
on tab 3). And if you then have UI-Two where you'd like to present the same
data, but this time without the tabs - one section below the other.

If this is your scenario then using composite controls would allow you to
group controls as though they were on tabs, but on controls. Then for UI-one
place one custom control on each tab. For UI-Two place the custom controls
one on top of the other.

If you later decide to change how a field is formatted, for example, you
need only go to the custom control to make the change. Both UI's should then
show that change without ever visiting each UI individually.

hope that makes sense, and I hope it helps.

-David Martin
-Just a guy. Sitting here. Reading MSDN. Drinking a bud.
 
Back
Top