SmartPhone and PPC Mobile 5.0

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

How far is the code written for pocket pc can be ported on a smartphone
(both for Windows Mobile 5.0)?

How should I arhitect the software development in order to minimize the
amount of rework when porting code from PPC to Smartphone?

Any insights are much appreciated.

Thank you.
 
What does the code do? The answer to that question is going to be central
to getting a useful answer...

Paul T.
 
As standard practice should be to separate the business logic and data
access tiers completely from the UI code so they can be used on both
platforms easily without or at least, minimal code change.

It is not really possible to develop one peice of UI source for both
platforms as there are too many differences.
 
Thanks for all your kind responses.

Basically, I am coding a smart device application with local storage
persistance for its data in XML and connected to the backend server via web
service.

As noted by Simon, UI and business logic should be seperated and I totally
agree with that. I am concerned whether this may slow down the application as
calling method comes with the price of processor time and memory. How should
I tackle this issue or I should not be concerned for the moment?

Second question is how far the UI of a PPC can be adapted to Smartphone?
What are the best practice in developing a single application for two
different devices? Should I have exact navigational feature for PPC and
Smartphone as new version of Smartphone and PPC shares the same soft key
menu? But the availability of soft keys for PPC is dependant on hardware
manufacturer.

In addition, how much is the coded business logic can be reuse in
Smartphone? I did found some of the differences that should be noted in the
SDK, however the information are somehow scattered which I find it difficult
to have a broad sense of understanding in order to correctly architect the
design. Is there any other documentation that list out the differences?

Thanks.
 
It may slow things down a little, but unless your business logic is pretty
limited, I'd be surprised if the calling times for a few additional methods
were even detectable against the broader background of the actual logic
processing itself. Code, *then* optimize, is usually the best way to go.
You don't want to do something totally stupid before you start optimizing,
but where you need to apply your effort during optimization isn't likely to
be clear until you have a working system.

I can't imagine any reason why you'd have to recode your business logic to
have it run on SmartPhone. If you do, it seems that your coding was
probably poor to begin with. What things are you thinking about as critical
differences between the two platforms from the business logic perspective?
Maybe our definitions are different...

Paul T.
 
Back
Top