NSDictionaries and NSArrays from JSON from complicated YouTube API - iphone

I'm making an awesome iPhone app which searches for YouTube videos using the JSON API. However, Google is lazy so they just transformed the ATOM feed into JSON. Things look like this:
feed->entry[0]->author[0]->name->$t
This means that getting the information out of the NSArray is difficult, as I need to get a value of a key of an object of an array of an object of an array of an object of a key.
To check if the structure is correct, I can choose two things:
Use a huge amount of code for each item I want to check if the JSON was correct.
Wrap everything in a #try block.
I'd like to choose the second one. The problem is that some time ago I read that this is bad practice. Is it? And if so, is there a shorter way to validate the NSArrays en NSDictionaries? My app may never crash, not even if the user remover the processor at runtime, so not checking at all is not an option.
Can you please help me? Thanks.

Have you tried the GData API? I'm using it for my application ( http://itunes.apple.com/us/app/skystop/id392782307?mt=8 ) for the Youtube Feed. It basically spits out an XML file for whatever you've requested and you can convert it right into a plist file or an NSArray.

i'm not sure i understand, the API itself works in JSON instead of ATOM so you need to di into every item ?
If this is so then you are right, not much you can do except to seardch the web for helper libraries that might have been made even in google code to support this API.
In any case #2 is bad practice first of all since try catch usually consume more system resources then simple boolean cheek or checks.
Second once you are in the catch block you are kind of in problem since all you can do is print an error to the user or yourself, if you want to go on parsing and checking, you can't...
and last but not least (I'm sure there are reasons I'm not thinking of) except for the message you might get with the exception u are never to sure where it came from...

Are you parsing the JSON yourself? If so, I suggest using an external framework to do the work for you. I use Json-framework in a few of my own projects and it does the job just fine.
http://code.google.com/p/json-framework/

Related

Centra DB to IPhone App / Objective-C

I'm trying to find some reading materials on how to connect an IPHONE app to a central DB-Server such as SQL-Server.
I know about SQLite, and the other methods of storing Data in the device itself. What I'm really interested is for the application to interact with a central database server. Are there any sort of objects such as SQLClient in .net or do I need to go through sending off HTTP-Requests and deserializing json/xml?
i dont know the answer to your question, but even if you find that it would be not recommended to do so, since its always better to use an httprequest solution,
Encapsulating the database implementation is always the way to go, since database implementation could change rather quickly adding a layer over it is recommended
That goes without saying that you will not be able to do caching by accessing the database directly, which is also a drawback
am sorry this is not the answer you are looking for, but you should re think on how you are going to implement your solution,
Preform a httprequest to a php script or similar and parse JSON or XML.
You would have to make a REST interface to bridge the 2 together, and as you said deserialize responses depending on the format, if it's json or xml.
From Device side, make GET/POST requests to your script, which responds the query results back to the app and handle them accordingly.

Parsing large quantities of JSON data in iOS

I'm getting a large JSON string (11MB) from a web service. When I parse the data using JSONKit, my app reaches 70MB, I get memory warnings, and the app crashes.
How can I parse this data?
the easiest solution is reducing the json size you are getting from the server. If you cant to it, the only way to parse huge JSON is using lazy evaluation.
I dont think there is a JSON lib for objective-c that supports lazy evaluation. however you can implement one.
Your best bet is to look at the YAJL JSON parser, that supports event driven parsing. Then you can parse the JSON as it comes down in a data feed, and not have to store the whole thing in memory at once.
https://github.com/gabriel/yajl-objc
Sorry, I don't know of any code examples that demonstrate this use in practice.
SBJson supports parsing a stream of data. This lets your process your document bit by bit so you don't need to hold on to the entire document. The distribution contains two examples of how to use this. First there's the StreamParserIntegrationTest.m and next there's the TweetStream demo app: a twitter application that will sit and parse a HTTP stream all day (if you let it) displaying each tweet as they come in and then throw them away.
(Disclaimer: I am SBJson's author.)
11 mb is a largedata and solution is only to minimise your size of data
JSON support is not native to iOS, but there is a great framework for this exact purpose: http://code.google.com/p/json-framework/
This framework supports conversion from raw JSON objects to Objective-C objects (NSArray, NSDictionary) and vice versa.

iphone - retrieving information from the internet (rss alternative?)

(Very) basically my app is just a load of information collected from the internet - eg: someone can log into an admin panel on a website and update their app from there. The information gets put into a mysql database.
The way I thought about going about this was to use an RSS feed - it works for blog/twitter feeds, so I thought why not do it for the rest of the information that I want to get.
My question is, is this a suitable way to do it? Basically just make dynamic XML files (php scripts that output XML) and parse them on the iphone, or is there a better way to do it?
I'm not looking for a full blown tutorial, just maybe a few keywords that I can go off and look up myself - or a "XML is the best way... stick at that". :p
Thanks a lot.
I personally like JSON more than XML, since it creates less characters to transfer the same data = less bandwidth/transfer used and faster response.
You can use a JSON library from here or just stick with XML since you're familiar with it. I guess it's just a matter of personal preference.

Getting Data From Webpages?

When looking to get data from a web page whats the recommended method if the page does not provide a structured data feed? Am I right in thinking that its just a case of doing an NSURLRequest and then hacking what you need out of the responseData(NSData*)? I am not too concerned about the implementation in Xcode, I am more curious about actually collecting the data, before I start coding a "hunt & peck" through a list of data.
gary
Unless you are in control of what is getting fetched (e.g. you're sending yourself well-formed XML and can parse it appropriately), you're pretty much forced to picking through it "by hand" as you say. What you're doing here is also called "screen scraping".

"Refreshing" an XML feed on iPhone/Mac OSX

I'm curious for those of you who are building iPhone apps based on REST/SOAP/XML-RPC or simply pulling down a dynamic XML feed, what does it mean exactly to you when a user says 'refresh' the feed?
The straight forward way is to populate some collection, say an NSMutableArray, with whatever you bring down from the feed. If a widget on the UI is available to refresh, I typically do something like:
[myMutableArray removeAllObjects];
// follow steps to repopulate myMutableArray
It seems this is the least efficient algorithm for refreshing an XML feed. For instance many folks who are building Twitter clients, are appending changes to their existing feed, versus bringing down the entire feed in its complete form again.
What kind of algorithms are you using to "refresh" your models when speaking to a server-side data source?
Thanks all.
You should look into using the PubSub framework if you can require OS X 10.5. It's explicitly designed to fetch and update RSS/Atom feeds.
(Disclaimer: I wrote a lot of that framework while I was at Apple :)
The answer to your question is that feeds are inherently inefficient. You can minimize this by
Using HTTP "conditional GETs", so if the feed hasn't changed on the server you'll just get back a tiny 304 response. This saves time for the server and for you. (Some feed servers, like slashdot, will ban you if you don't use conditional gets!)
Check the "Last-Modified:" date on the response. Yes, even if you use a conditional GET. Some servers don't handle them properly. If the date is unchanged, ignore the feed.
Compare the raw data of the response against the last raw response you got. If identical, ignore the feed. (Some servers don't support conditional gets or send last-modified dates...)
Now you have to parse the XML.
Check the top-level mod date on the feed itself (this varies between Atom and the different flavors of RSS.) Again, if it's the same as it was last time, ignore the feed.
If you got here, the feed's been updated, most likely. The easiest thing to do is to throw away all of your old saved entries and replace them with the new ones. But this means you can't keep 'historic' entries that have fallen off the end of the feed. If you want to do that, you have to go through each entry in the just-parsed feed, match it with the corresponding entry in your persistent storage, and update the persistent one based on the new one. If you couldn't find a persistent one, add it as a new entry. (Matching entries can be difficult in lame RSS feeds that don't include unique GUIDs for each entry. You have to try comparing permalinks and titles. Yuck.)
This whole thing really is a big mess. It took a lot of work to make everything behave correctly and work with all the broken feeds and servers out there; take advantage of my pain and use PubSub, if you can :)
One approach is using the built in NSXML pull parser in a background thread and comparing entries from the stream to what you have in memory, updating only what has changed.
I've just released an open source RSS/Atom Parser for iPhone and hopefully it might be of some use.
I'd love to hear your thoughts on it too!