topic Re: Data Retrieval Types for autocomplete functionality in ArcGIS API for Flex Questions

Data Retrieval Types for autocomplete functionality

WesBailes — Tue, 14 Dec 2010 14:37:36 GMT

I am utilizing the autocomplete component from flashcommander http://flashcommander.org/blog/flex-4-autocomplete

This seems to work really well, although for my situation I am wondering if anyone has ever implemented any speed/performance tests of different types of web services. I will work through these myself, but thought if someone had any recommendations that they could pass along, it would be greatly appreciated. The way my application will work is that the search component will be set up similar to a widget and the data for the autocomplete textinput will be bound after the component is initialized. There are over 1200 records that will populate the autocomplete. Any suggestions on the fastest query to implement? (.net web service, ArcGIS Server query, embedded xml file). The data required is published as a web service and seems to work ok, although if there is a faster option I would definitely be open to trying something else. Thanks!

Re: Data Retrieval Types for autocomplete functionality

RobertScheitlin__GISP — Tue, 14 Dec 2010 14:47:06 GMT

Wes,

How often does the data you are autocomplete 'ing get updated? Because if you don't need that list to be updated daily than there are definitely faster ways.

Re: Data Retrieval Types for autocomplete functionality

WesBailes — Tue, 14 Dec 2010 14:50:27 GMT

Wes,

How often does the data you are autocomplete 'ing get updated? Because if you don't need that list to be updated daily than there are definitely faster ways.

Not often at all...I'm thinking once a month or more tops.

Re: Data Retrieval Types for autocomplete functionality

DasaPaddock — Tue, 14 Dec 2010 15:30:05 GMT

Here's a great tool showing the typical performance of various protocols:
http://www.jamesward.com/census/

AMF is the fastest way to request the data, but if you can embed it and don't mind redeploying that every month, that's probably the fastest option. AGS Server 10 supports AMF output of queries.

Re: Data Retrieval Types for autocomplete functionality

RobertScheitlin__GISP — Tue, 14 Dec 2010 15:43:02 GMT

Wes,

So here is an example of embedding 47K+ values in an as file for use in an auto complete using YahooAstra. The zip file is a FlashBuilder archived project so all you have to do is import it using the file -> import -> Flash Builder Project -> file option

Re: Data Retrieval Types for autocomplete functionality

WesBailes — Wed, 15 Dec 2010 01:33:08 GMT

Thanks guys for both of your responses. I will put this advice to good use!

Re: Data Retrieval Types for autocomplete functionality

TomMarkham — Fri, 13 May 2011 13:49:26 GMT

Robert

I downloaded your zip file to our development server, did a compile to create a .swf file and tried to create a widget on our development application. When I click on the widget, I get the little clock and that is all I get. Is this method the correct method to post your widget so that I can get an idea of how long that the autocomplete takes to download 47K records to the client?

Thanks

Tom

Re: Data Retrieval Types for autocomplete functionality

RobertScheitlin__GISP — Sun, 22 May 2011 10:55:00 GMT

Tom,

Check in your Flash Builder problems window to see if there are any issues when compiling the widget.

Re: Data Retrieval Types for autocomplete functionality

TomMarkham — Wed, 25 May 2011 12:58:10 GMT

Tom,

Check in your Flash Builder problems window to see if there are any issues when compiling the widget.

Robert

I did a compile this morning and the problem window is showing 0 items. The SWF file had todays date. I moved the SWF file to the Widget folder and tried the application again with the same results.
I have tried the AutoComplete application from the Code Gallery (MadsGren) with our data (around 80,000 property addresses) and on the first entry it is taking over a minute before I see results in our development application. After the first entry, all subsequent entries are very fast and the map displays the property very fast. Since I am testing from a fast network, I am concerned that deploying this function to an average Internet user would result in an unacceptable wait time. This is why I would like to try out your solution to see if the initial entry wait time has been reduced to a more acceptable time. It seems to me that dragging this many records over the network down to the desktop can be a big problem.

Thanks

Tom