I've built a simple iPhone app that parses data from a remote XML feed, converts the information into objects (they're videos), and displays the videos in a standard table view->detail view->"Play Video" UI. There are hundreds of videos, each with about ten attributes. (The videos are never downloaded, only streamed, using MPMoviePlayerController.) I've relied on the Apple sample application SeismicXML for much of the app's behavior.
Now I'm ready for the next step: saving the video metadata to the device, so that users aren't forced to wait for the XML retrieval and parsing every time they launch my app. I'm planning to use Core Data to save my Video objects (and their parent Channel objects), but it's all brand new to me.
My question is: Can folks recommend any sample application or design pattern for managing this data? I want to have the app automatically download and parse the XML at launch, but then it should refresh the data only when the user taps a Refresh button, or if the data is older than, say, a day.
Apps that model this behavior are NYTimes, AP, and many others.
Besides the excellent documentation that Apple provides for Core Data, are there any resources out there for architecting an iPhone app that needs to download, save, and periodically refresh its data?
Thanks.
Update on 11/12/2009: Between the Apple sample code for TheElements, TopSongs, CoreDataBooks, PhotoLocations, iPhoneCoreDataRecipes, and XMLPerformance, I've got plenty of grist for the mill here. I'm currently analyzing the samples, and slowly piecing together what I need.
Looks like you found all of the Apple samples, so that's good.
The Pragmatic Programmers have a book on Core Data, and several of the iPhone SDK books out (including theirs) touch on Core Data a little. See also this question.
Edit: forgot to mention Three20 (the guts of the Facebook app, Open Sourced) as an example of a way to do this that isn't Core Data. Rather than re-constructing the downloaded data in some object graph that's persisted with Core Data, Three20 implements disk caching and freshness dating on top of the URL loading system. The app basically still works by making HTTP API calls, and parsing the responses, but doesn't have to talk to the cloud on every screen display, which speeds things up immensely. If you're only downloading this information to display in a big table view, and not anything else, perhaps this model might be easier.
Related
I'm new to IOS programming, and I have had a great time learning it. It took me about 4 months to really get a good grasp on it. I have began creating my own app, and I ran in to a few questions. The app I'm creating is a live app like instagram, foursquare, etc. How do I store all of the information I need. Can I use Core-Data to create a real-time app that can handle updates from multiple users?
The app I'm creating is a live app like instagram, foursquare, etc.
How do I store all of the information I need.
You'll probably create some sort of server to manage the data. Having a single, central source of data is a lot easier than trying to sync data between multiple devices.
Can I use Core-Data to create a real-time app that can handle updates from multiple users?
You can -- Core Data works on MacOS X as well as on iOS, so you could write a Mac program that is the server for your iOS app. Whether that's the best approach is another question... I suppose it depends on how well you already know Core Data, whether there are any advantages to using the same Core Data data model on both the server and the client, how many clients you think you might have to support at once, etc.
If you're asking about using Core Data on the iOS client, then yes, you can certainly do that.
I was reading that certain API's are not available when making iPhone apps with flash, such as accessing the camera. Is it possible to still get information from the web and display it in the app using the flash method? The overall plan is to have it pull data from an SQL database using XML, and I was just wondering if that was possible still with flash. Thank you very much for your answers.
I heard the same thing about it not being able to connect to the internet, among many other restraints, when developing apps through Flash. It held me back for the first 3 months after Apples 'accept' of the platform.
But now after I've had some time to test things out on my own, I found out that the following is possible (so far):
Getting xml and pictures from the web (so why not SQL)
saving cookies
Saving pictures to the cameraroll.
getting geoLocation data (didn't get the google maps api to work YET tho)
And these are only the features i have tried so far (in development-phase, not submittet to Apple)
I'm surprised that no one else has answered your question by now.
Hope this helps gets you spirit up for developing apps with flash :)
I'm new to iPhone development and I still have some gaps that needs to be filled in the first application I'm developing. This app will consume data from a site managed by Wordpress through the Wordpress JSON plugin, which allows to retrieve the posts in the form of a json string.
I wanted my application to store the posts in some form of caching, so that the users would only need to download the new content after the first time. Think about the Twitter App, that keeps all your previous loaded tweets and only load the new ones.
What's the best way to do that, should I save the json as a file or there are another more efficient method to keep it in cache?
I'm currently developing an app that will deal with this kind of stuff. And I found many possible solutions.
If you still have issues with this, have a look here: http://cocoawithlove.com/2010/09/substituting-local-data-for-remote.html
If your app has to be simple, this could be perfect.
An other way could be to subclass NSURLProtocol, but I'm still investigating on this solution.
Regarding In App Purchases, I can find a lot of information on all the technicalities of actually making purchases and interacting with the store (how to retrieve product information, verify receipts, etc), but I can't seem to find information on guidelines or special instructions for preparing the actual "apps" or "components," whatever they're to be considered, which will act as the In App Purchases.
For instance, once a component is downloaded into an app, where does it exist in the overall architecture of the app? How do they combine to join forces? How do they know about one another. If I have a game, and using In App Purchases I allow users to both download new levels, but also download new game play modes that can affect any of the built-in or downloaded levels, how do I prepare all of these assets so that they integrate?
I'm not looking for a tutorial, per se, but would love to know if anyone has had experience with In App Purchases or knows of a useful reference besides Apple's In App Purchase programming guide which only speaks to the specifics of making the actual download transaction.
The things you download aren't really "apps", they're just data files like anything else your app can download.
Sometimes, they're not really that, they're just effective "switches", i.e. all of the functionality and data is there in your code already, but it's just protected by a line of code like
if (user has purchased extra levels)
add extra items to menu/list
You aren't allowed to download new executable code; I admit I'm not sure how carefully Apple works to prevent you from downloading scripts that control your program's behavior, since it would be very difficult for them to tell what is intrinsic to your original app or not.
In my own programs, I've put the control logic and tables into the main application, and separated out big resource files into a separate ZIP file. When the user buys the add-on pack, they do download that ZIP file of images which keeps the original application size down, and the program just uses those images out of the documents directory instead of the application bundle like it would if they were built in.
I am using the Urban Airship in-app purchase support, which insulates you from running your own server or learning most details of the StoreKit, at the cost of a slice of your revenue.
You can let the levels be in the app from the beginning and just let them become available when the user pays an in-app level. This is by far the most simple solution.
If you want to have downloadable levels you will need to set up an own server that will deliver and check correct purchase transactions with apples servers. You will also need to create all the download and architecture to load and use these levels into your app.
But, you can have a look here http://urbanairship.com/in-app-purchase/ for help in creating downloadable items.
This code will get you going: works on the simulator too: https://github.com/boxerab/InAppPurchase
I want to implement Core Data into my iPhone app. So what is the best way to learn Core Data specifically for the iPhone? I have 4ish hours that i can devote to this today, so ideally I would be competent enough to add this (however slightly) into my app.
The only way i retain data now is through NSUserDefaults, just so that when the app is closed and reopened, their data is still there. I want to give the user the ability to save sets of data, read them, edit them, delete them, etc.
Getting Started with Core Data in the iPhone Dev Center did the trick for me. :-)
No, seriously, it might seem like obvious advice, but that one-page document lays out a nice strategy for which documents and tutorials to read and in which order. Once you work through the first tutorial it recommends, the weird terminology will feel a lot less weird.
If you don't already know about this, this is very useful:
Core Data Tutorial for iPhone OS
Two books that are great references for Core Data are "Core Data: Apple's API for Persisting Data on Mac OS X" by Marcus Zarra and "iPhone SDK Development" by Bill Dudney and Chris Adamson. Both walk you through sample code for handling Core Data on the iPhone, with slightly different perspectives on the framework. The Core Data book provides the best overall reference on the subject that you'll find, outside of Apple's own documentation.
Additionally, if you purchase the iPhone video track from this year's WWDC, the presentations "Introduction to Core Data on iPhone" and "What's New in Core Data" are great resources. ADC Select members also have access to Core Data presentations from older WWDCs, including ones that explain the fundamental concepts of the framework and how to tune the performance of your Core Data application.
Make sure you don't stop after the first document - Core Data Turorial for iPhone OS is excellent but then I tried to change the model and everything crashed with fairly cryptic error messages. Getting Started with Core Data is the next place to go. Unless you read the sections on versioning the data model you will probably run into big problems as soon as you start to adapt the example code for your own use.