views:

64

answers:

2

I am working on an app for a business that is essentially a catalog. The client has a website that uses a MySQL database, but he doesn't want that to be used by the app. His website offers RSS feeds, but I don't think that this would be a good idea. The app is supposed to be searchable based on a number of (optional) factors and show details of each item when selected.

Somehow, I don't think that RSS is the way to go, but how to convince him? Is there an alternative way that will work? The catalog is often updates and that means downloading updates will be necessary. Should I try to convince him to allow for read-only access?

Assuming that I'm using RSS, what would be the best update schedule? How would searching work? I'm confused...

Please note:

[Thinking aloud here...]

{I am new to iPhone development, this being my first app. I've done websites for 6+ years and I know HTML, JS, CSS, PHP, MySQL and Visual Basic 2008. I have dabbled in desktop languages (C, C++, Java) and I am now learning Objective C as I work.}

EDIT:

I'm not familiar with JSON. Tutorial links?

+2  A: 

How large is the database? How large are the RSS updates? Is the entire catalog accessible through that RSS stream? Does the app need to function without an internet connection? The answers here will likely drive your decision.

I certainly wouldn't advocate for direct MySQL access. It's a big security risk, and it is very implementation dependent. Your client couldn't do a database redesign without breaking the iPhone app, for example.

If you have access to the website (or could convince the client), perhaps a good solution would be to leverage your strengths and expose a RESTful interface to the SQL over the web. Then your iPhone app can simply be a JSON or XML (or whatever) parser and interface. You wouldn't need to worry about the backing store or searching on the iPhone; it'd all be done server-side.

You could potentially use RSS, but a big I presume that only the changes are pushed out through the stream. You'd need to keep a copy of the database on the phone, and use RSS to keep it updated. However, you'll have a very tough time with the first sync (since the prepopulated data may be quite stale) and then any sync after a long delay since not all changes may be available anymore. You'd probably have to allow for the entire database to be downloaded through some secondary mechanism. And if it is really big, neither users nor the host will be too happy about that. Moreover, the heuristics of the syncing would be tricky.

Matt B.
+3  A: 

RSS is not the answer you're looking for. RSS is not really suited for arbitrary structured data, it's built around syndicating web content.

You definitely don't want to expose direct database access for a few reasons (security, response time, etc.). I would build a web service on the server side that provides a few methods (making some assumptions based on what I know about most catalogs):

  • "get category hierarchy" - would query the database for the category structure and provide that back to the app
  • "get items in category" - returns the item data for a particular category
  • "search" - would accept a set of parameters, search the database using those, and return the matching set of items

I would use JSON as my data interchange format, as it's a lot simpler than dealing with XML.

ChrisW
I second the suggestion for JSON. IN addition to being able to move the data back and forth easily, if your local repository (if you have one) is structured properly you can drop the JSON data directly into it very easily. For instance, moving from JSON to Core Data is trivial.
Marcus S. Zarra