iOS Mechanism for commands functions, ideas?

[IDMah]

Hi all.

I'm getting a little sick of creating BOOLS, and various variables for one time functions, like alerts, reseting high scores or changing certain switches, and usability tweaks.

for example: "GameSpeedSet:1.7 ResetUPLoads Message:"New Updates include"
would be read at from the server as a message and then set those variables and switches.

But worried apple wouldn't approve?

What do you think?

How should I implement this?? is there any easier ideas??
Mainly this is for updating purposes and tweaking gameplay without Appstore resubmissions.

 

[JohnsonK]

I don't think I get what you mean. But if I do, I think you are over complicating and/or taking the wrong approach. What do you mean exactly?

 

[IDMah]

Basically I want to update game settings via a web/ mechanism.
A command language with a parser that could change internal settings and save them.. but..

Yes probably over complicating things.
I am leaning to the KISS solution.. another bool or flag.

thanks for the talking me off the ledge.

 

[chown33]

Basically I want to update game settings via a web/ mechanism.
A command language with a parser that could change internal settings and save them..

You probably don't need that. It depends on the types of the parameters you're trying to tweak.

For numbers, strings, booleans, colors, etc. all you need is a plist from the server and NSUserDefaults.

You simply get the plist, then walk through it, adding each value to the NSUserDefaults for the app. Your other code that uses the parameters simply gets the NSUserDefaults and asks for a value associated with a specific key. For example, if some code in a game has an initial velocity for asteroids, it asks for "asteroidInitialVelocity" instead of using a compiled-in number. It then gets back an NSNumber whose value is used as the velocity. If there isn't a parameter with that name, it gets nil, which means "use the builtin default", or you can setup NSUserDefaults to provide builtin defaults.

You can extend the principle further by getting plist files and writing them to app private storage (read up on Property Lists). You don't need to read from NSUserDefaults, you can load files directly, as long as they're in plist format. You then do the same basic thing, which is look for a named parameter whose value is the one to use.

You also need an incremental version identifier of some kind, so the app can determine whether there are new parameters it should get, or whether its current parameters are adequate. That's a simple procedure, but it does need to be done correctly, otherwise the app will spend too much time and resources updating its parameters for no reason.

The hard part in all this isn't the getting, storing, or retrieving of tweaked parameters. The hard part is adding the code (or revising existing code) so it looks for a parameter in the first place, rather than using a hard-wired value. It's not impossible, but if you haven't planned for it from the early stages of the design, it will be very time-consuming and tedious to plow through your entire code base converting hard-wired values to configurable parameters.

 

[firewood]

Apple presented a WWDC session on this very mechanism about 3 or 4 years ago. Data driven app design, or something like that, was the title. Downloading updated plists to customize/personalize an app. I assume that if Apple presented a session on this technique, reasonable use might be permissible. But there is something in the developer agreement limiting reasonable use of downloaded configuration info. Read it.

----------

The hard part in all this isn't the getting, storing, or retrieving of tweaked parameters. The hard part is adding the code (or revising existing code) so it looks for a parameter in the first place, rather than using a hard-wired value. It's not impossible, but if you haven't planned for it from the early stages of the design, it will be very time-consuming and tedious to plow through your entire code base converting hard-wired values to configurable parameters.

If you use the MVC design pattern, all this stuff should be isolated in the Model object and accessed only using getters, limiting code base changes required, making the update a lot easier.