PDA / SmartPhone development

[Gareth Sharp]

Hi there

I am very new to the mobile environment, and have a couple of newbie
questions that I would really appreciate some advice on before we start our
project.

We want to write an application that is essentially a data logger - data is
sent to the PDA / SmartPhone, it is updated and then sent back. Not sure if
this is going to be via the internet, or a cradle, or what. Not too fussed
about this at the moment. We will specify Microsoft Windows Mobile 2003.

What is the difference between writing an app for a PDA or for a SmartPhone?

How are applications rolled out and updated (if necessary)?

How can data be transferred to and from the device?

Would it be easier to write a small app, or something to run in a web
browser?

Is this possible to run a web application on a PDA or a SmartPhone?

Could anyone recommend a specific PDA and/or SmartPhone to use as a decent
test platform?

We are moving forward with Visual Studio .net (I've ordered the Enterprise
Developer edition) - does this give me everything that we need?

To give a bit of background, we have been developing in VB 5 for a number of
years, with Access (DAO) and SQL (ADO) back end databases, and are just
taking tentative steps towards moving forward with Visual Studio .net (I've
ordered the Enterprise Developer edition)

Any advice/pointers would be massively appreciated.

All the best!
Gareth Sharp
Technical Director
Paxton Computers Ltd
website: http://www.paxsoft.co.uk
eMail: mailto:[email protected]

 

[Ginny Caughey [MVP]]

Gareth,

I'll answer some of your questions, but I strongly encourage you to try out
a variety of devices for yourself to determine which you'd like to target
with your app.

For starters, one important difference between Smartphone and PocketPC
devices is that Smartphones don't have a touch screen. This means that some
visual controls such as buttons aren't present. On the other hand, they do
have physical buttons which can be pressed to provide data entry into text
controls. You just need to try them out and see which will work best for the
type of data you intend to collect.

Another important difference is that until the Windows Mobile 5.0
Smartphones begin to appear, SQL CE is not an option for data storage, so
you'll need to consider something else such as XML or CSV files. Pre-WM5.0
Smartphones also won't run .NET Compact Framework v.2 when it is released.
This may not seem like a big deal now, but .NetCFv2 is faster and more
full-featured than the current shipping version, so you may want to consider
that limitation. Neither of these limitations applies to currently shipping
PocketPC devices since they support SQL CE and will also support .NetCFv2.

The easiest way to move data to/from the device is by using ActiveSync. You
can even write your own desktop app using the Remote API that controls how
the data is transferred. If you choose this route, you'll want to use either
XML or CSV files. If you use SQL CE to store your data on the device, you'll
need to use either merge replication or RDA with your SQL Server or web
services, and all of these approaches require a web server somewhere for the
"plumbing".

Visual Studio 2003 Pro and above provides the tools you need. Since you have
a VB background, you'll probably want to use VB.Net. It is possible to write
a web browser app, but your users probably won't like it and it won't
necessarily be easier for you to write compared with a smart client app. Be
sure to try out the mobile samples that come with Visual Studio - you can
test them in the emulators without having a physical device to get an idea
how they work, but be aware that the emulators are generally quite a bit
slower than the actual devices will be.

I hope this gives you some ideas to help you get started. In addition to
handling and trying out various devices, I'd also suggest browsing in your
favorite bookstore at books devoted to to Windows Mobile development. Also
check out www.opennetcf.org for free code and for book recommendations.

Ginny Caughey
..NET Compact Framework MVP

 

[Bruno Alexandre]

I also thank you for the reply

--

Bruno Alexandre
Dep Informática do Grupo Filtrarte

Av Genereal Humberto Delgado, 91
Vila Verde
2705-887 Terrugem SNT
PORTUGAL

Tel. +351 219 608 130
Tlm. +351 914 461 138
Fax +351 219 613 881
@. (e-mail address removed)
www www.filtrarte.com | www.filtrarte.pt

 

[Seefor]

Pre-WM5.0 Smartphones also won't run .NET Compact Framework v.2 when it

is released. This may not seem like a big deal now, but .NetCFv2 is faster
and more full-featured than the current shipping version, so you may want
to consider that limitation. Neither of these limitations applies to
currently shipping PocketPC devices since they support SQL CE and will
also support .NetCFv2.

Does .NETCFv2 only work on Pocket PC 2002 ? i.e. not on older Pocket PC's?

 

[Ginny Caughey [MVP]]

..NetCFv2 will not be supported on PocketPC devices prior to 2003. It will
work on PocketPC2003, PocketPC2003SE, Windows Mobile 5.0 PocketPCs and
Smartphones, and CE version 5 and higher devices.

Ginny Caughey
..NET Compact Framework MVP

 

[r_z_aret]

Ginny Caughey gave you good advice. That leaves me freer to express my
definitely biased opinions.

My company makes a suite of programs. We have mobile (data collection)
applications for every version of Windows except Smartphones (more
below). We have transfer and analysis programs that run on "big"
Windows, and can work with just about any database (Access, Oracle,
....). Our base price is very low; I really do think we are often less
expensive than writing your own.

I regularly build for Smartphone. But just to make sure I can, in case
we do ever decide to support it/them. I think the lack of any sort of
stylus is way too limiting.

Getting the user interface right for data collection is very
important. Especially for small screens and/or reluctant users. We
think that means avoiding text input as much as possible. Partly
because text input is slow, and partly because it introduces
variations that cause problems for analysis (too many ways to say the
same thing).

Pushbuttons and radio buttons are wonderful for very short lists.

Pick lists are great for longer lists. But only if they can be kept
small, which means providing separate lists for each item. We can
update these lists dynamically and automatically, based on SQL
queries.

Providing a tool to let users, or their immediate supervisors, create
and modify forms is a big help. These are the folks who really know
what data need to be collected. If the tool modifies input data,
rather than the actual programs, quality assurance is much less of an
issue. Our tool lets "authors" specify the type of input (text, list,
button, numeric) for each input item.

Data logging means recording actual data, plus date/time stamp,
probably an operator ID, Also room for comments (longer description
and/or likely action that should follow). And perhaps other details
easily overlooked without serious thought and/or a few revisions.

Robust data transfer can be subtle. You need to make sure everything
gets transferred without loss or duplication. If you are using fragile
connections (anything that uses radio waves), you need to handle
broken connections. RAPI over wires has been very reliable. We also
support FTP and network shares.

Hi there

I am very new to the mobile environment, and have a couple of newbie
questions that I would really appreciate some advice on before we start our
project.

We want to write an application that is essentially a data logger - data is
sent to the PDA / SmartPhone, it is updated and then sent back. Not sure if
this is going to be via the internet, or a cradle, or what. Not too fussed
about this at the moment. We will specify Microsoft Windows Mobile 2003.

What is the difference between writing an app for a PDA or for a SmartPhone?

How are applications rolled out and updated (if necessary)?

How can data be transferred to and from the device?

Would it be easier to write a small app, or something to run in a web
browser?

Is this possible to run a web application on a PDA or a SmartPhone?

Could anyone recommend a specific PDA and/or SmartPhone to use as a decent
test platform?

We are moving forward with Visual Studio .net (I've ordered the Enterprise
Developer edition) - does this give me everything that we need?

To give a bit of background, we have been developing in VB 5 for a number of
years, with Access (DAO) and SQL (ADO) back end databases, and are just
taking tentative steps towards moving forward with Visual Studio .net (I've
ordered the Enterprise Developer edition)

Any advice/pointers would be massively appreciated.

All the best!
Gareth Sharp
Technical Director
Paxton Computers Ltd
website: http://www.paxsoft.co.uk
eMail: mailto:[email protected]

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
500 Harrison Ave., Suite 3R
Boston, MA 02118
www.penfact.com

 

[Gareth Sharp]

Hi Ginny

Many thanks for the advice. This certainly provides food for thought!

All the best!
Gareth

 

[Gareth Sharp]

Hello there

Thanks for that. If there's anything I think you can help us with, I shall
be in touch.

All the best!
Gareth

Ginny Caughey gave you good advice. That leaves me freer to express my
definitely biased opinions.

My company makes a suite of programs. We have mobile (data collection)
applications for every version of Windows except Smartphones (more
below). We have transfer and analysis programs that run on "big"
Windows, and can work with just about any database (Access, Oracle,
...). Our base price is very low; I really do think we are often less
expensive than writing your own.

I regularly build for Smartphone. But just to make sure I can, in case
we do ever decide to support it/them. I think the lack of any sort of
stylus is way too limiting.

Getting the user interface right for data collection is very
important. Especially for small screens and/or reluctant users. We
think that means avoiding text input as much as possible. Partly
because text input is slow, and partly because it introduces
variations that cause problems for analysis (too many ways to say the
same thing).

Pushbuttons and radio buttons are wonderful for very short lists.

Pick lists are great for longer lists. But only if they can be kept
small, which means providing separate lists for each item. We can
update these lists dynamically and automatically, based on SQL
queries.

Providing a tool to let users, or their immediate supervisors, create
and modify forms is a big help. These are the folks who really know
what data need to be collected. If the tool modifies input data,
rather than the actual programs, quality assurance is much less of an
issue. Our tool lets "authors" specify the type of input (text, list,
button, numeric) for each input item.

Data logging means recording actual data, plus date/time stamp,
probably an operator ID, Also room for comments (longer description
and/or likely action that should follow). And perhaps other details
easily overlooked without serious thought and/or a few revisions.

Robust data transfer can be subtle. You need to make sure everything
gets transferred without loss or duplication. If you are using fragile
connections (anything that uses radio waves), you need to handle
broken connections. RAPI over wires has been very reliable. We also
support FTP and network shares.

please indicate which newsgroup and message).