I'm working on a game where really the only game part is (at least right now) that the user can unlock achievements as she does various things throughout the game. I have a database that can keep track of certain user actions and record how many times a user does something but I'm having trouble figuring out the best way to architect the app so that I have to do the least amount of work. Kind of suck with the timing because gamecenter is not ready and it seems like openfeint is changing gears, but maybe I'm wrong. I'd prefer to do everything "in house" if it is not too ridiculous. looking for suggestions.
One of the parts I'm having the most trouble figuring out is how to manage the state of all the achievements. NSuserdefaults vs. core data vs. a flat data file.
Also is there anyway to send a notification if a core data field reaches a certain amount?
Thanks,
Nick
Are you keeping the achievements on the device only, or also on the server? On the device, there is no reason not to use Core Data.
Using Core Data, you could use KVO on your model properties to monitor when certain values reach a new achievements.
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'm facing this problem while designing my iOS app. Suppose that a user purchases an app and downloads it to the iPhone. I would like to provide him with a default consumable item the first time he runs the app to use whenever he wants , however I would also like to track if the user has already consumed the item. This way if he decides to reinstall the app we can restore the transactions (if he used the item) or we can avoid possible intents to download different kind of content by reinstalling app and consuming default items each time. (Guess NSUserDefaults is not an option here).
One approach that came to my mind was using UDID(or any iOS 6 alternatives) to keep a record on server of the user's device the moment he uses the default item. But this will limit items just to the device from which they consumed content.
It would be great to support all the user's devices (like inAppPurchases), but I can't figure out a way to implement this.
Any suggestions or help would be great.
Thanks a lot.
In order to tie information to a user (not just a device she used at one time), you'll need to ask the user to identify herself and save it someplace other than the device. In other words, a backend that implements registration and login.
From scratch, this can be a lot of effort that an iOS developer didn't count on. Fortunately, there are several services in the world that provide a substantial head start. Here's a nice round-up. I've had direct experience only with Parse.com, and think it's excellent.
I am in the process of building an iPhone app with a RoR 3 web service on the back end. The app is a fairly simple peer-to-peer game. I would really appreciate it if someone could share some pointers and tips on how to best divide the operations between the web service and locally on the iPhone.
For example, chess or backgammon, is the current state of the game being constantly saved and retrieved from the server? or is it stored locally on the iPhones of the players?
Thanks!
This will vary wildly depending on how you want to program the application and what your needs are. You could constantly save and retrieve game state from the server, you could synchronize game state at certain intervals determined by game play, or you could run mostly local. It all depends on your requirements. In general cell networks should be considered slow and unreliable (even though this isn't always true). Keeping data transfer to the minimum required to accomplish your goals makes your app feel more responsive and users happier (especially those in poor coverage areas and those who do not have unlimited data plans).
That depends on whether it's a game against another player or against a computer opponent. If it's against another player, then the state would be updated on and retrieved from the server. If it's against a built-in AI, there would be no reason to send that state to the server, unless your AI is inside your webservice instead of including it in the actual application. It's really a design decision based on what you're trying to accomplish. Generally I would recommend keeping as much as possible local to the app, unless there's a reason to do it on the server, but if there's any competitive aspect to your game, you definitely want to keep control of any calculations on your server. Keep in mind that someone can always try to decompile your application or call your webservices directly passing in false data.
I'm thinking about building an iphone app that would use the GPS feature to track where someone is and for how long. I realize I could probably get the current location from the iphone from a website but the only way I'm familiar with is using ajax calls, etc (Sorry if this is a rather newbie concept) but I fear that would bog down my servers with constant calls to track time. Is there a better way to do this? Any resources I could consult on this idea/concept? Is it even plausible at this point?
I'm more versed in php/mysql but trying to branch out on some new ideas I've had. Any help would be greatly appreciated!
You could keep a local datastore then only send updates to the server when the app detects that the user has moved. I'm pretty sure that would work and on the server side you just work out the last time a user checked in and then compare that against the current time to see how long they have been somewhere. The only technical issue I can see with this is that this requires the user to have the iphone on and the app open the ENTIRE time they are somewhere, which would mean the iphone is now just a rather expensive GPS tracker with a built in phone!
you could store user locations on a local list on the iphone and once an hour you send the list with location/timesptamp pairs to server.
As James Raybould says, you can compute on server how long a user stayed inside a range for a given position. And also by sending data once an hour... not each time the iphone detects that user moved, then you save your server for continuously pings.
I have implemented one application in which i want to implement pedometer functionality.Is it possible to implement pedometer?Please give me idea.
This is certainly possible, and I believe has been done. The main drawback is that since the iPhone does not permit 3rd party background tasks, your app will have to be open to collect pedometer data.
The simplest way to do this would be to setup an Accelerometer listener, and watch for 'step events'. You'd have to do some experimentation to determine the type and size-range of these, but that wouldn't be too difficult.
Expanding on Ben's answer: you might want to write an app (or use an existing one) that continuously records the data from the accelerometer and shows a graph thereof, then have that app running while you and a few different people walk around with the device in their pocket. That should give you an idea of the patterns of acceleration you need to be looking for, as well as the variation possible in peoples' stride lengths, gaits, etc.