Navigate between forms

[Chris Czornen]

Thanks to other for the previus replies.

I need help into this: i need to build a mobile app with 20 forms. Based on
yours experiences, which is the best way to implement to navigate between
the forms ? StackForm ? or another.

Thanks in advanced.

 

[Chris Tacke, MVP]

There is no "best" there is only "what works for your specific applciation".
If you want to force users to navigate forward and back in a hierarchy, a
lot like a web browser, then a stack works well. You then have a forward
and back. If you need to switch between siblings or cousins, then it's a
bad choice becasue you are foreced to walk back up the stack and then back
down another branch. If you don't want the user to have to do this, then
you need anotehr mechanism, such as a deck that allows you to pull a Form
from anywhere.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

 

[Chris Czornen]

yes, you are right Chris. I think the best way for my application is a
mechanism that allow me to pull a Form from anywhere.

Have you any sample about it ? or any link to learn ?

Thanks a lot.

 

[Chris Tacke, MVP]

No, I don't have any ready made sample. The idea here is pretty simple -
just have a Dictionary of forms by type, then pull from it. Or use a DI
container to manage all of that for you.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

 

[Simon Hart [MVP]]

A dependency injection container approach in this scenario will only work if
you are using a patterned UI architecture such as MVP. But works very well
if you put the time and effort into it.

 

[TWischmeier]

I would like to add that using a DI Framework works well (as it does
in general once you set it up), you should not let the DI handle your
Forms lifecycle. I am developing a wizard-style mobile application, in
which the user has to jump to a different form. I did write my own
Application Controller (pattern) for it. It takes care of lifecycle,
caching of forms etc. However, whenever there is a request for a Form
that has not been created yet, it retrieves it by quering my DI-
Container (which in that case acts as a Service Locator, but that one
is a special case in my application).

In strongly advocate for implementing one's own lyfecycle management
especially on a mobile device application where you use the same form
multiple times, because once loaded, the form will display much
faster.

 

[Simon Hart [MVP]]

Why do you think it is not practical to let the container handle the forms
lifecyle? I'm assuing thats what you mean when you say "do not let the DI
handle your Forms lifecyle"?

This is the whole point of using an IoC container - to separate concerns and
in this case abstract the management of forms from the developer. There are
containers that allow you to specify the licestyle - much like the popular
castle windsor. This is how I do it with a typical MVP pattern coupled with
the command pattern - works very well for mobile devices.

Execution always starts with the presenter which is loaded using the Service
Locator and from within a command, the view is then injected into the
presenter. So completly testable. Another nice bonus this architecture
gives, is the ability to add event aggregator pattern which can be used at
presenter level or form level and can be raised anywhere.

--
Simon Hart
Visual Developer - Device Application Development MVP
http://www.simonrhart.com

I would like to add that using a DI Framework works well (as it does
in general once you set it up), you should not let the DI handle your
Forms lifecycle. I am developing a wizard-style mobile application, in
which the user has to jump to a different form. I did write my own
Application Controller (pattern) for it. It takes care of lifecycle,
caching of forms etc. However, whenever there is a request for a Form
that has not been created yet, it retrieves it by quering my DI-
Container (which in that case acts as a Service Locator, but that one
is a special case in my application).

In strongly advocate for implementing one's own lyfecycle management
especially on a mobile device application where you use the same form
multiple times, because once loaded, the form will display much
faster.

 

[Chris Tacke, MVP]

I'm going to agree with Simon. Why would a DI container not be able to
handle this? Even a very basic container that creates and holds the object
would do what you're asking (which is basically nothing more that caching
objects).


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com



I would like to add that using a DI Framework works well (as it does
in general once you set it up), you should not let the DI handle your
Forms lifecycle. I am developing a wizard-style mobile application, in
which the user has to jump to a different form. I did write my own
Application Controller (pattern) for it. It takes care of lifecycle,
caching of forms etc. However, whenever there is a request for a Form
that has not been created yet, it retrieves it by quering my DI-
Container (which in that case acts as a Service Locator, but that one
is a special case in my application).

In strongly advocate for implementing one's own lyfecycle management
especially on a mobile device application where you use the same form
multiple times, because once loaded, the form will display much
faster.