Development options for form-based application - Handheld

This is a discussion on Development options for form-based application - Handheld ; It's been a few years since I did any mobile device application work. I'm hoping to get some advice on the best approach - specifically choosing the right tools - for a certain application. The application we will be creating ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Development options for form-based application

  1. Development options for form-based application

    It's been a few years since I did any mobile device application work.
    I'm hoping to get some advice on the best approach - specifically
    choosing the right tools - for a certain application.

    The application we will be creating will be used by a small force of
    in-field workers (under 25 people to start). They will be required to
    visit locations and take notes on what they observe via one or more
    forms on the PDA. We cannot rely on a wireless connection at all the
    locations they will visit. Therefore, after the user had visited
    multiple locations (and completing PDA-based forms at each one) they
    would return to their home office and sync the PDA. During the sync
    process, we want the data that they captured to be transmitted to a
    central database (MS SQL Server) via the Internet where the data from
    each PDA-based form will be stores as a new record in the DB.

    Also, it is possible that we may have a requirement for data to flow TO
    the PDA during the sync process. For example, we amy want to distribute
    alerts and news, or work orders, to mobile field force during the sync
    process. Let's assume this data is personalized for the indivdual.
    Again, the primary application requirements are outlined in the
    previous paragraph, however, I don't want to shut the door on being
    able to add this functionality if it's determined to be needed.

    The main solution I have been investigating would use Pendragon Forms
    and their SyncServer. Can anyone give me their opinion on this? Also,
    what about other technolgies like Intellisync (formerly Satellite
    Forms) and Appforge? It's not clear to me if Appforge can do the remote
    sync that we need. Given the nature of the development team, low-level
    development (C and the associated tools - i.e. Codewarrior) tools will
    probably not be any option.
    Any and all advice welcomed. Thanks for your time.

    - Gregg


  2. Re: Development options for form-based application

    I'm pushing rules a bit, but our application does much of this. In
    particular, we work in batch mode, transmit data (including work
    orders) in both directions when a device is synchronized, and have
    back-end tools to store results in any ODBC-compliant database. So I
    hope you will check our web site (see my signature below).

    On 5 Jan 2005 09:12:51 -0800, "Gregg" wrote:

    >It's been a few years since I did any mobile device application work.
    >I'm hoping to get some advice on the best approach - specifically
    >choosing the right tools - for a certain application.
    >
    >The application we will be creating will be used by a small force of
    >in-field workers (under 25 people to start). They will be required to
    >visit locations and take notes on what they observe via one or more
    >forms on the PDA. We cannot rely on a wireless connection at all the
    >locations they will visit. Therefore, after the user had visited
    >multiple locations (and completing PDA-based forms at each one) they
    >would return to their home office and sync the PDA. During the sync
    >process, we want the data that they captured to be transmitted to a
    >central database (MS SQL Server) via the Internet where the data from
    >each PDA-based form will be stores as a new record in the DB.
    >
    >Also, it is possible that we may have a requirement for data to flow TO
    >the PDA during the sync process. For example, we amy want to distribute
    >alerts and news, or work orders, to mobile field force during the sync
    >process. Let's assume this data is personalized for the indivdual.
    >Again, the primary application requirements are outlined in the
    >previous paragraph, however, I don't want to shut the door on being
    >able to add this functionality if it's determined to be needed.
    >
    >The main solution I have been investigating would use Pendragon Forms
    >and their SyncServer. Can anyone give me their opinion on this? Also,
    >what about other technolgies like Intellisync (formerly Satellite
    >Forms) and Appforge? It's not clear to me if Appforge can do the remote
    >sync that we need. Given the nature of the development team, low-level
    >development (C and the associated tools - i.e. Codewarrior) tools will
    >probably not be any option.
    >Any and all advice welcomed. Thanks for your time.
    >
    >- Gregg


    -----------------------------------------
    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

  3. Re: Development options for form-based application

    On Thu, 06 Jan 2005 15:12:35 -0500, r_z_aret wrote:

    > I'm pushing rules a bit, but our application does much of this. In
    > particular, we work in batch mode, transmit data (including work orders)
    > in both directions when a device is synchronized, and have back-end
    > tools to store results in any ODBC-compliant database. So I hope you
    > will check our web site (see my signature below).


    Just an FYI, your website is horrible. Here's a short list of
    the obvious things I found wrong with it (and you may contact me offline
    if you wish me to help you move this site into this decade in a fast,
    standards-compliant, accessible way):

    1. Missing alt tags on your images. Please use alt tags, and
    don't just call them "[image]". Make them useful and descriptive.

    2. Using tables for layout. If the data isn't tabular, tables
    are the wrong approach.

    3. Using width/height tags to resize images in the client's browser.
    Not only does this increase your bandwidth requirements (and hence,
    cost and speed), but it burdons the client with your inability to use
    proper image sizes on your site. I reduced the image size from the
    original 600x397 to the distorted 148x127 as specified in your HTML
    and it reduced the image size from 41,344 bytes to 6,849 bytes; a
    savings of 34,495 bytes. That was without any tweaking or further
    compression on the image itself.

    4. Unnecessary use of Javascript to "preload" images. Don't do that,
    this isn't 1980 anymore, and it will likely break for the growing
    number of people who now disable Javascript in their browser.

    5. All of your pages fail HTML validation. Please validate your pages
    to make sure they comply with W3C's HTML standards. Go to
    validator.w3.org, and run every page through it. Correct those
    mistakes as you find them.

    6. Your site REQUIRES Javascript to get to the navigation menu. This is
    really a bad idea, as you are limiting yourself to desktop users, and
    cutting off blind users, mobile, cell, wap, and PDA users.. a market
    you appear to be directly catering to. Choose a standards-compliant
    Javascript menuing system that provides proper fallbacks in case the
    user doesn't have Javascript enabled. Or, better yet, use a pure CSS
    dropdown menu approach.

    7. Your "Back to Top" button doesn't actually return the user to the top,
    because "custtop" is missing from most of the pages you use it on.

    I'll stop there, but there are a lot of other issues with the site that
    are just plain wrong, broken, and appears "hacked up".

  4. Re: Development options for form-based application

    On Thu, 06 Jan 2005 23:06:18 -0500, "David A. Desrosiers"
    wrote:
    > Just an FYI, your website is horrible. Here's a short list of
    >the obvious things I found wrong with it (and you may contact me offline
    >if you wish me to help you move this site into this decade in a fast,
    >standards-compliant, accessible way):
    >
    > 1. Missing alt tags on your images. Please use alt tags, and
    > don't just call them "[image]". Make them useful and descriptive.


    I have nothing to do with his site, but I read your comments with my
    own in mind.
    I intend to do this "alt" thing myself... thanks

    > 2. Using tables for layout. If the data isn't tabular, tables
    > are the wrong approach.


    I use tables... are you recommending frames? I prefer tables to
    frames as it compels people to link all your content should they link
    to a page on your site.

    > 3. Using width/height tags to resize images in the client's browser.
    > Not only does this increase your bandwidth requirements (and hence,
    > cost and speed), but it burdons the client with your inability to use
    > proper image sizes on your site. I reduced the image size from the
    > original 600x397 to the distorted 148x127 as specified in your HTML
    > and it reduced the image size from 41,344 bytes to 6,849 bytes; a
    > savings of 34,495 bytes. That was without any tweaking or further
    > compression on the image itself.


    I see the use if the image size thing on a lot of people's pages.. I
    also dislike it. I'm a dial-up user and it stinks to wait for 50K of
    data just to see 6K of image. I use size controls on my images, set
    to the actual size of the image to force auto-resizing add-ins to not
    explode my low resolution images up to crappy-sized pixlely blobs.

    > 4. Unnecessary use of Javascript to "preload" images. Don't do that,
    > this isn't 1980 anymore, and it will likely break for the growing
    > number of people who now disable Javascript in their browser.


    I am one of those who turns-off javascript. It's more trouble than
    it's worth. For the few sites that use it for something useful,
    there's a hundred that use it to spam your browser with ads.
    To you people trying to sell your product on the web, the public as a
    whole now uses all the tools they can to prevent spam... javascript is
    just what we are blocking.

    > 5. All of your pages fail HTML validation. Please validate your pages
    > to make sure they comply with W3C's HTML standards. Go to
    > validator.w3.org, and run every page through it. Correct those
    > mistakes as you find them.


    On my way there now. Oh yea, forget Frontpage. You can't pass a test
    with pages created in Frontpage.

    > 6. Your site REQUIRES Javascript to get to the navigation menu. This is
    > really a bad idea, as you are limiting yourself to desktop users, and
    > cutting off blind users, mobile, cell, wap, and PDA users.. a market
    > you appear to be directly catering to. Choose a standards-compliant
    > Javascript menuing system that provides proper fallbacks in case the
    > user doesn't have Javascript enabled. Or, better yet, use a pure CSS
    > dropdown menu approach.


    Hey, wait a minute... CSS is a pain in the ass. If you are going to
    advocate CSS, at least tell them to provide a CSS-free fallback.

    > 7. Your "Back to Top" button doesn't actually return the user to the top,
    > because "custtop" is missing from most of the pages you use it on.


    He was being cool and sloppy... something in style these days.

    > I'll stop there, but there are a lot of other issues with the site that
    > are just plain wrong, broken, and appears "hacked up".


    Bravo! I wish there were more people like yourself who actually care
    enough about web content to speak out.


  5. Re: Development options for form-based application


    >> 2. Using tables for layout. If the data isn't tabular, tables
    >> are the wrong approach.

    >
    > I use tables... are you recommending frames? I prefer tables to frames
    > as it compels people to link all your content should they link to a page
    > on your site.


    Frames are worse, and break navigation for a lot of devices, the
    least of which being handheld and mobile devices. Its antiquated
    technology and should be avoided at all costs.

    No, I was advocating proper HTML + CSS, of course. Easier to implement,
    maintain, and much smaller and faster in terms of bytes sent to the
    client. When you have 10,000 unique hits per-day, 5-10k per-page of
    "bloat" really starts to make a big difference.

    >> 5. All of your pages fail HTML validation. Please validate your pages
    >> to make sure they comply with W3C's HTML standards. Go to
    >> validator.w3.org, and run every page through it. Correct those
    >> mistakes as you find them.

    >
    > On my way there now. Oh yea, forget Frontpage. You can't pass a test
    > with pages created in Frontpage.


    I use vi to create all of my pages (and yes, I do this for a living).

    > Hey, wait a minute... CSS is a pain in the ass. If you are going to
    > advocate CSS, at least tell them to provide a CSS-free fallback.


    CSS _is_ the fallback. What do you mean its a "pain in the ass"? Its
    smaller, faster, easier to learn, faster to update and maintain, much more
    scalable, standards-compliant, and forward-compatible.

    Why _wouldn't_ you use it? You have a LOT more control with CSS than
    you do with frames, tables, or broken HTML.

    > Bravo! I wish there were more people like yourself who actually care
    > enough about web content to speak out.


    There are, and the list is growing. I know I've personally converted
    quite a few companies and individuals myself, through my constant pressure
    on them to fix their sites to work in more than just 1 browser.

  6. Re: Development options for form-based application

    This thread deviated from the topic I think. Anyway I suggest using CASL from www.caslsoft.com for creating a palm application, it comes with a conduit, with which you can transfer data from pc to pda and pda to pc, you need to create a DSN on pc for that and use that dsn name in the application.

    If you have vb.net skills then better go for pocket pc application developed using vb.net.

    Cheers!

    www.palewar.com (its not nicely designed either)

    --
    Message posted via http://www.pocketpcjunkies.com

  7. Re: Development options for form-based application

    Thanks for your reply (and for staying on topic).

    I took a look at CASL, but I'm not sure it can provide on of the main
    requirements: when the user synchronizes, the data that they collected
    via the PDA app needs to be inserted into a DB on a *remote* server. I
    do not need the app to sync with the desktop to which it is attached.
    Instead, the PDA syncs with a computer connected to the internet, and
    then uses that internet connection to update a remote, centralized
    server that all of the other users of the same PDA app are connecting
    to as well.

    - Gregg


+ Reply to Thread