2

I would like to store world cities in a list since metro app can't have local database but I am not sure it is possible (I've found a text file with more than 3 million cities).

I wonder how they did in the weather app. Since there is no latentcy in the results suggested (in the search charm or in the "favorite places" screen), I don't think they use a webservice, and also I want my app to be able to propose a list of cities even if there is no connection available.

Any idea ?

Peekyou
  • 471
  • 1
  • 5
  • 21
  • Use a Trie. See for example: - http://stackoverflow.com/questions/6416050/how-to-create-a-trie-in-c-sharp - http://stackoverflow.com/questions/3748200/saving-a-trie-to-disk – Joshua Honig Jun 08 '12 at 14:33

4 Answers4

1

Simply stick it in a text file, delimited by line. This is not a large amount of data - you can likely hold it all in RAM in one go.

Using a database just for this one list seems a little overkill.

With some rough calculations, assuming names of around 20 characters each, I'm in the region of about 100MB of city data. That's not insignificant for one list in memory - granted, but it's not a lot to have to contend with.

You may even be able to use something like a Linq to Text provider.

How they may have done it in the charm is to only worry about a few cities - the favourites and whatever your location service last reported. Handling < 10 is easier than 3 million.
Adam Houldsworth
  • 63,413
  • 11
  • 150
  • 187
1

3 million cities might sound like a lot. But is it a lot for your Metro app?

These are very rough estimates

Let's use an average city name length of 20 unicode characters.

20 * 3 million = 60 million unicode characters.

60 million * 2 bytes per unicode character = 120 million bytes.

120 million bytes / 1024 = 117,187.5 kilobytes

117,187.5 kilobytes / 1024 = 114 megabytes

~115mb isn't exactly 'small' but depending on your other requirements - you can probably handle loading 150mb into memory. You can use whatever .NET objects you'd typically use like List and use LINQ to get the matching cities or whatever.

That's not to say this is your only option. It's just probably a viable one. There is a lot of very clever stuff you could do to avoid pulling all of it into memory at once; but if you want to eliminate/minimize lag - that's going to be your best bet.

Rob P.
  • 14,921
  • 14
  • 73
  • 109
  • Even if this isn't your final solution, it's a good first place to start. Optimize after you figure out there's a problem. Also, I think your data set is likely to be a lot less than 114MB. [Here](http://www.geodatasource.com/world-cities-database/free) is a free city list with 2.4M cities that is 35MB uncompressed. These days, that's getting to be rather small potatoes. Depending on encoding and so forth, it could be a lot more, but then you need to start asking yourself about your goals, target audience, and what trade-offs you are willing to accept. – Dominic P Jun 08 '12 at 15:15
  • @Adam - You are 100% correct. Thank you. – Rob P. Jun 08 '12 at 15:15
1

I would suggest looking into SQLite if you need a database. Metro applications obviously do not have access to SQL Server and other Win32-based DBMS, but you could try SQLite as a lightweight alternative.

Try this: https://github.com/doo/SQLite3-WinRT

LeigerGaming
  • 504
  • 1
  • 4
  • 17
0

We recommend using SQLite database with LinqConnect - Devart's LINQ to SQL compatible solution which supports SQLite. You can employ LINQ and ADO.NET interfaces with our product. Starting from the 4.0 version, LinqConnect supports Windows Metro applications: http://blogs.devart.com/dotconnect/linqconnect-for-metro-quick-start-guide.html.

Devart
  • 119,203
  • 23
  • 166
  • 186