If I had the capabilities, it would be a web client since it would provide the most flexibility among all the different mobile platforms. A rich client would have to go more extensive testing and also there are the "requirements" piece. Rich clients tend to be more memory intensive so the mobile client can be affected in doing the other functions concurrently (receiving e-mail, phone calls, etc.).
Last Wiki Answer Submitted: June 4, 2009 6:02 pm by Aguacer08,120 pts.
If you live outside the United States, by submitting your email address you consent to having your personal data transferred to and processed in the United States.
The environment needs to be considered. Web client is the easy answer, but there are a number of factors that might require a rich client.
1. Is there any need for the client to be able to operate “off the net”? Might the client be used to capture data when there is no connectivity? If so, this has to be a rich client.
2. Is there any need to operate in limited bandwidth areas with large amounts of data (e.g., large drop-down lists of personnel, statutes, parts inventories, etc.)? If so, you may need to at least have local “widgets” to cache and handle the lists – i.e., at least part of a rich client.
Quite often, I see web client applications written that “assume” massive amounts of communications capacity (“It worked great in our in-house 100 Mbps network!”). These applications then fail miserably when they encounter real-world conditions outside the lab.
Before choosing an architecture for an application, the business use cases for the application need to be carefully considered.
You may also want to look at Microsoft’s Windows Presentation Foundation (WPF) and Windows Communications Foundation (WCF) layers. Applications properly developed with WPF and WCF components can be deployed in either web client or rich client configurations, but it requires understanding and developing with that in mind.
The environment needs to be considered. Web client is the easy answer, but there are a number of factors that might require a rich client.
1. Is there any need for the client to be able to operate “off the net”? Might the client be used to capture data when there is no connectivity? If so, this has to be a rich client.
2. Is there any need to operate in limited bandwidth areas with large amounts of data (e.g., large drop-down lists of personnel, statutes, parts inventories, etc.)? If so, you may need to at least have local “widgets” to cache and handle the lists – i.e., at least part of a rich client.
Quite often, I see web client applications written that “assume” massive amounts of communications capacity (“It worked great in our in-house 100 Mbps network!”). These applications then fail miserably when they encounter real-world conditions outside the lab.
Before choosing an architecture for an application, the business use cases for the application need to be carefully considered.
You may also want to look at Microsoft’s Windows Presentation Foundation (WPF) and Windows Communications Foundation (WCF) layers. Applications properly developed with WPF and WCF components can be deployed in either web client or rich client configurations, but it requires understanding and developing with that in mind.