Okay, I’ll say loud what some will be thinking when reading this. Why not use an XML file?

Well… no. Not unless you need to store this data, share it… load it over a network… (then, yes). In many other cases, using hard, compile safe code to assign values and configure objects, has advantages.

• XML data without a validator (including build system integration) is no better than interpreted code.
• Without a template (and a convenient editor driving the ‘form filling process’) XML data is tedious to write and tedious to maintain.
• Hard-wired configs break at compile time. Data loaded from XML files or CSV rarely breaks before runtime.
• There’s no point in writing data formats and validators for data that changes often – for example when a codebase / paradigm is relatively ‘fresh’.

So I’ll go with hard-wiring and try to figure a decent pattern for it. I’ll use macros if I have to, and avoid them if I can. I was, then, looking for a patterned way of configuring my data, and I came up with this:

1. Have a class Foo, need to configure instances of Foo.
2. Created an interface IFooSetup, specifying getter methods for configuration data: getA(), getB(), getC()… etc… etc…
3. Created a class FooDefaultSetup <IFooSetup> providing a default configuration.
4. Created multiple subclasses of FooDefaultSetup – BlueFooSetup, YellowFooSetup, GreenFooSetup etc etc…

Not just I won’t do it again (at least, not in ObjC). I will also refactor my code.

Why is this approach troublesome – why did I come up with this idea in the first place?

Setup interface/protocol

IFooSetup is a protocol dedicated to helping programmers configure instances of Foo. Sometimes it can work. One advantage of using an interface is that (inside an IDE) it works much like a form (a piece of paper with blanks that one needs to write into). The compiler helps the programmer ensure (often, in realtime) that all required config parameters are set.

So good so far (and I don’t care whether anybody’s bothered writing a class just to configure another object).

Maybe it is a pattern, then. A fortiori, however, it does take a couple of useful language features for this to actually work.

Default config class

Sooner or later, the idea of creating a class named FooDefaultSetup will arise. Why, because several objects shared common parameters. It is logical.

Unfortunately, although some languages allow abstract classes, ObjC does not. As a result, once we go with FooDefaultSetup, we have to implement all the methods declared by IFooSetup, including getters for which FooDefaultSetup can supply no meaningful default – and as a result we have just short-circuited the usability of IFooSetup – it no longer works ‘more or less like a form’ – to determine what methods we’d like to override, we have to check the source code for IFooSetup.

Breakable code.

No real mess will start until we change the signature of a method in IFooSetup. At this point, it would be neat if the compiler could help us make sure that the many, many implementers of IFooSetup (BlueFooSetup, YellowFooSetup, … ) are updated accordingly, alas…

• Some languages (quizzically, the defunct Javascript 4) will have you tag every method intended to override a method up the inheritance chain. This means that you can’t accidentally override methods. It also means that you get an error when the method no longer overrides another method. Not so in ObjC
• Other languages won’t let you implement a method that hasn’t been declared. Not so in ObjC.

What happens, then?

FooDefaultSetup is somewhat maintainable since it must implement all methods in IFooSetup.

Sadly, none of the subclasses of FooDefaultSetup are maintainable. Forgetting to update/correct the method signature for any of these subclasses is now the easiest thing in the world, resulting in code never being called. Not just any code, but sound, simple, honestly good looking trivial code that mainly consists in getters.

A little down the line we’ll be looking at bugs and wondering why an object doesn’t behave as expected, the trivial reason being: configuration code is out of date, and the compiler knows nothing about it.

K.I.S.S

So, yea… never again. Instead of configuring objects in this way, I’ll sooner do the following and be better for it:

• Keep it simple, stupid. Configure an object by calling accessors on this object.
• If you need a ‘checklist’ of what needs to be configured… consider copy-pasting the config block from another, similar object. Or write a checklist. Or write a validator.
• At least when an accessor’s signature changes, the compiler will warn against all and every deprecated use of the modified method.

Principle

When a body of mass M is at rest, applying a force F will result in a speed S = F / m.

This formula can be used to write a simple governor – given the current velocity V0 and a target velocity V1, we have:

F = ( V1 – V0 ) * M

Units:

• F – force applied (Newtons)
• V1, V0 – velocity (meters per second)
• M – mass (kilograms)

Given the above we can write a very simple function that will calculate the force F required to update the velocity of an actor at every frame.

It may be working better than you’d expect – notably, given motion conservation, even a trivial governor (based on the above principle) will quickly achieve target velocity.

Scaling the output

The above formula can be modified by introducing a scale parameter:

F = ( V1 – V0 ) * M * S

The scale parameter may have uses – for example you can use it to increase the governor’s output when friction/air resistance become significant.

Note that scaling the output in this way may break time invariance – the simulation will behave somewhat differently depending on the size of time steps.

Implementation notes

Impulses vs continuous forces

A simple way to implement the above consists in delivering the governor’s output as impulses. An impulse is a discrete force applied to a physical body. A priori it may appear that continuous forces would be a better choice. However, depending on the way continuous forces are implemented by the physics engine, an impulse governor may be preferable:

• When applying a continuous force, the force is usually given in newtons per second. Therefore additional calculations are needed to precisely determine the total force delivered by the governor.
• With impulses applied at every frame, the ‘stop and start’ effect that one should expect is not visible.

Issues

Sharp changes in orientation

In some games, sharp changes in orientation are not a problem, especially when the actor need to be responsive (e.g. controlled by the player). For large actors and some other games however, sharp changes in orientation look ugly. A low value for S ( ~0.1 or less ) will reduce artifacts but this solution is not ideal.

A simple way to solve this problem is to interpolate between the current orientation and the target velocity before passing the target velocity to the governor.

Note: I removed the ‘motion aliasing’ section referred here previously; the artifacts I observed in my simulations were not related to the governor itself.

Going further: adaptive governors

Compared to the solution described above an adaptive governor can handle various situations by automatically correcting the scale factor S. This is done by measuring the bias between the expected output (target velocity at frame t0) and the actual output (real velocity at frame t1 = t0+1).

It is wiser to start with a simple governor - whether adaptive or not, the governor needs to be initialized with a base value for S; additionally when encountering obstructions, adaptive governors tend to ‘overheat’ – increasing S to a very high value. While it is possible to clamp the scale factor to a specific range, this is probably just the first in a series of adjustments – adaptive governors are smarter, they are also harder to design.

You can check out the sample project from SVN:

http://xp-dev.com/svn/harmony-framework/trunk/f-star/iOS/tutorial/FStarExample/

Setting up your project

1. Open XCode.
2. Go to File > New Project
3. Select ‘Empty Application’.
4. In Product Name, I input FStarExample.
5. I put my projects under my experiments/ folder. XCode will create a folder for our project.

Arranging the sample project

I like to have ‘headroom’ in my projects. The initial project structure looks like this:

• FStarExample (project node)
• FStarExample (source location)
• FStarExampleTests (for unit testing)
• Frameworks (libraries required by the iOS SDK)
• Products (build output)

I regroup all items, so that it looks like this:

• FStarExample (project node)
• source (custom group)
• tests (previously, ‘FStarExampleTests’)
• [implied]
• FStarExample-Prefix.pch (digged up from ‘Supporting Files’ I just like to keep this one ‘visible’)
• FStarExample (still the app delegate)
• Products
• Frameworks

Keep in mind that XCode groups are just a convenient way to… group files. For better and for worse, grouping is irrelevant to the underlying file structure.

Setting up an F* instance

Under source I create the following structure:

• source
• [m]
• Facade.h
• Dispatcher.h
• Feature.h

The Facade will be used to instantiate all the features we use in our application. The Dispatcher provides the basis for gluing features together. Feature is the base class for all application features.

Note: XCode doesn’t encourage physical groupings (putting source files in separate folders – it is needless to say possible but doesn’t flow smoothly) so I’ll be content with XCode groups.

Creating a feature

To create a feature named foo, follow the steps:

1. create a group named foo
2. create a subclass of Feature, Foo inside group foo.
3. foo overrides setup in Feature.
4. import the feature class from Facade and add an entry to initFeatures.

The sample project illustrates the above steps.

Event handling

The dispatcher mediates communication between features via events. In the provided example:

• Foo registers with the dispatcher to receive an event x. registration happens within the setup method. (While setup is running, nothing warrants that all features are already initialized so while it’s okay to register for events, it is not okay to dispatch.
• After all features are setup, the start method is called on each feature, at which point Bar dispatches the event.

When I use F*, I tend two follow a 3 step cycle.

1. induction

During the ‘inductive phase’, I try to focus exclusively on the problem I am solving. If I feel my feature requires external input (or a signal), I design notifications without worrying about the source of such notifications.

This approach becomes important over time because it allows solving the problem at hand without  burdening ourselves with the growing ‘mass of code’ that the project generates. For me this inductive phase is similar to ‘starting a new project’. Surely most programmers have noticed that they feel dynamic and fresh at the beginning of a new project?

2. testing

During the testing phase, notifications can be used to write acceptance tests – test the feature in isolation.

3. integration

During the integration phase, I make sure that the notifications the feature relies on are actually satisfied.

Since I used to write my own coding tools, I bloody well knew how to compile a java (sigh) program on the command line. I also wrote tools in such a way that they found jars in myland (comforting it was, however restrictive).

XCode workspaces are meant to improve the (sodding) developer experience when dealing with complex projects. Don’t get me wrong, I’m all for wizardry – Clearly, however an ignoramus ex machina is usually at work when I try stringing libraries together.

Useful notes?

Check this article from the Carbon Five blog for useful notes about linking static libraries. I’ll provide a new article on this topic at some point. I just wasted a couple of hours clear because this stuff is having its way. Here’s a lame summary of what I found:

• Like pixies, build issues appear when you least expect it. Sadly they also disappear mysteriously as soon as you try getting to the root of the problem.
• You can fix build issues by fiddling:
• If at first you don’t succeed…
• Don’t assume a library won’t get found because it appears ‘marked red’
• Don’t assume a library will get found because it doesn’t appear ‘marked red’
• Assume duplicate items can easily arise when adding libraries to a project.
• Remove duplicate items whenever you stumble on them.
• Play with the ‘Location’ combo (relative to group, relative to project etc…).
• Don’t be afraid to check build logs. The paths often look infuriatingly convoluted, but while you’re poking around to find what’s really gone wrong, the problem is getting itself fixed (and at least you’re kidding yourself that you have something to do with it).

The case

Okay, let’s say I made a library called ‘foobar’ (I actually did)

Initially, under ‘products’, libfoobar.a is red. In my file inspector the location is relative to build products (and cannot be changed)

For sake, build (don’t add any source file) and check what happens: nothing. Well that’s good, innit? No source files, no library.

Now, add a source file and rebuild. Check the messages window. We now have 3 items: Precompile…, Compile… and Libtool.

Under Libtool, we can see the intended location of the output:

-o /Users/johndoe/Library/Developer/Xcode/DerivedData/workspace-fdpyddpbphekphdqtzzutyjcagva/Build/Products/Debug-iphonesimulator/libfoobar.a

Feeling paranoid (would Libtool ever lie?) we can verify that the library has been created by browsing to this path (Finder is gracefully setup to overlook whatever path this stuff goes under).

But the item still appears ‘marked red’ under ‘Products’. Suspicious?

Can’t copy libfoobar.a?

Now let’s try linking foobar against a target inside another project (same workspace, right?). Open project settings (yea click on the project in the navigator), go to Build Phases > Link Binary With Libraries, hit the [+] button. A cute browser now appears with libfoobar.a under Workspace (or whatever your workspace is named). Select libfoobar.a, press return and… *build*.

Mind, this operation adds an item to your project, now also visible in the navigator (libfoobar.a, still marked red).

If there is an error, it may look like this:

error: /Users/johndoe/Library/Developer/Xcode/DerivedData/workspace-fdpyddpbphekphdqtzzutyjcagva/Build/Products/Debug-iphonesimulator/../../../../../../../../svn/components/base/build/Release-iphoneos/libfoobar.a: No such file or directory

Command builtin-copy failed with exit code 1

What’s going on here? Let’s go and check the added library item inside our project (select the item and make check sure the inspector is open). I see this:

Location: relative to group

Path: ../../../components/base/build/Release-iphoneos/libfoobar.a

Clearly not right (yet, consistent with the failed copy operation)

Fancy patching the path manually?

Location: relative to build products

Path: ../Debug-iphonesimulator/libfoobar.a

Worked for me, but not right away. Digging around I found yet another duplicate of the same library reference (marked red!). Removed it, cleared (what appears to be) the same item under ‘build phases’ and re-re-re-added it all over again (this time by checking the box I wanted in ‘target memberships’).

Not happy

I felt somewhat unconvinced (notably, I’m not happy with the Debug-iphonesimulator part of the relative-to-build-products-path – how’s that supposed to backfire?).

So I removed the library altogether and started over. Just repeated the initial steps going by the book… sadly it… worked.

Until next time.

I describe the steps carried to setup a test target long after a project has been created, so initially the test target will lack most of what’s needed to operate correctly (e.g frameworks, libraries and source files)

Setting up may take up to a few hours.

Creating a test target isn’t a big deal (just go to the project panel, add a new target and follow the steps).

I expect tests to run every time I try to build/run the main target. If the tests won’t pass I’d rather not fire up the simulator.

By default, the test target is not setup to work this way. Maybe it makes sense (after all, how does it know which target to depend on).

1. Go to project panel => build phases ; add the test target under target dependencies.
2. In the project panel, open ‘build settings’ for the test target, search for and tick ‘Test After Build’.

1. Adding source files

Maybe the fastest way to add your .m files: go to Build Phases and scroll to ‘source files’, then press add. type *.m as search filter. If you have many groups you may need to do this a few times to include all the required files.

2. Disable/Enable Automated reference counting.

In your test target, under build settings, search for ‘Reference counting’ and tick/untick “Objective-C Automatic Reference Counting”

3. Replace/Edit precompiled headers

In build settings, search for ‘pch’. If possible I just copy the *.pch from my main target settings to the test target settings.

4. Add the required frameworks & libraries

Most of this should be copied from your main target. Opening the assistant editor so you can compare/check both targets at once is useful (see build phases > link binary with libraries).

If you miss a library it will result in countless unresolved dependencies so it’s easy to figure.

5. List additional headers

If you’re pointing at additional headers in build settings, ideally you can share definitions by declaring them in the project’s (not the target’s) build settings – target-specific entries can be overwritten using $(inherited).

Housekeeping

Keep your framework/library references tidy: Checking the list of frameworks/libraries included in your project (there may be some in several places) may be a good idea as (harmless) duplicates may arise.

With frameworks/libraries, getting ‘red files’ is not rare. In many cases this doesn’t mean anything is actually broken (sigh…)

Remove unused files: remove files created by the wizard, if unused (e.g. precompiled headers)

Rename/Regroup: Renaming/Regrouping may cause references to break and need further editing. It’s a bit fidgety so you’ve been warned.

I like using generic names for my source folders (e.g. not MyApp Tests/ , just test/ ) and certain files (info.plist instead of MyAppTests-Info.plist). Renaming the info.plist will require editing in build settings etc… so maybe it’s easier to leave things as they are (XCode can help you rename project items).

Caveats

Beware that some classes in related libraries may rebuild after setting up the test suite; if old files were lingering in the system this may cause errors and confusion. Clean the build if things start looking weird.

I started with a concept (‘the user agent’). This is somewhat useful and helped clarify the application structure. However, it seems a better way to get this to work is may be to just write a couple of tests ‘assuming the underlying system’ is already compatible with our new requirements – in other words, design the solution outside-in.

Additionally, I’m looking into existing automations for iOS; I will shortly review a couple of attractive solutions.

The user agent

A so called user agent (I may be abusing the term) is an interface bridging the view and the controller. Why would it be useful to complicate our design in this way?

Initially, an MVC application works like this:

USER <=> {View} <=> {Controller} <=> { Model } (2)

With a testing automation, it may look like this:

{ Robot } <=> {View} <=> {Controller} <=> { Model }

Indeed certain automations work this way (great); what about testing over headless graphics?

• The view component must not be instantiated.
• We cannot instantiate the controller unless we hide/factor out view dependencies.

We could write tests that only exercise the model; not bad, maybe too far removed from our goal.

So the idea is to introduce an interface (‘user agent’) bridging the view and controller; then we could setup the application in either of two ways:

USER <=> View <=> { UA } <=> {Controller} <=> { Model }

{ Robot } <=> { UA } <=> {Controller} <=> { Model }

A quick refactoring

Clearly dependencies between the view and controller need to be factored out in order to realize the above. Initially the controller owns a reference to the view and may processes UI events.

One way to proceed:

1. Migrate event handling code to the UI; inside event handling code we invoke controller methods.
2. Provide interfaces (e.g. IUser or IUserInput, IUserOutput) that the controller uses to output to, or configure input from, the UI. The UI implements these interfaces.

Exporting files manually is okay… to a point. Soon we find out not only that exporting files manually is a chore, it contributes to creating a beautiful mess.

How to automate the conversion? With XCode, it can be done using build rules. I’m covering the following points:

• Build integration – add files to your build, automatically translate them using utilities and include the products in your app bundle.
• Defining useful build rules.
• Invoking blender from the command line.
• Modifying blender scripts so that they won’t crash in a windowless environment.
• Signaling export errors (notably, errors generated by a script running inside blender) using XCode.

While we have a mixed workflow (Blender 2.49 / Blender 2.61), we’re dominantly using 2.49b, so I started with the older version. I’ll be covering 2.61… later.

I used the following articles as a starting point:

• How to add a custom build step to your project (from Monkey Style Games)
• Running Blender from the Command line (2.4x)

The experiment

The first step is to configure build rules to process *.blend files I guess, so in a first approximation I used this:

• Source files with names matching *.blend
• Custom Script: /Applications/blender/blender.app/Contents/MacOS/blender ${INPUT_FILE_PATH} (bad)
• Output Files:
  ${TARGET_BUILD_DIR}/../../${INPUT_FILE_BASE}.scg (bad)

For whatever reason, the next steps turned out to be troublesome.
My second py script was symlinked. I didn’t think it would matter (strictly speaking, still don’t think it does) but I found it hard to get the script to refresh (meaning, I would edit the py script and run the build again, find the same error as previously. And again. And again.

An error in the scene export script caused the wrong path to be used.

Passing several scripts on blender command line (-P foo.py -P bar.py) doesn’t work so I ended calling blender twice which is a lesser evil. Maybe.

Complications

1. I have a mixed workflow using both Blender 2.4x and Blender 2.5x. In theory this means that I would have to go through the motions again, finding out how I can run 2.5x from the command line (likely as not, it won’t work in the same way).
2. Scene files contain level edits and assets. Asset files do not contain level edits. Both blender 2.4x and 2.5x files are just annotated as *.blend. How do I know which version of blender to run and which scripts to call?

The answer to (1) will be simple for now. Don’t do that. I mainly use 2.4x; the only 2.5x file that really matters so far is the one containing the PC mesh and animations. So I’ll just pass and use the manual workflow for that.

The answer two question (2) will be equally simple. Use a convention. For starters:

• level file: level.s.blend
• asset file: asset.a.blend

( and likewise when I get 2.5x scripts working, different conventions may be used )

This is a bit lame. Maybe a better convention might be something like:

• *2.4x/scenes*.blend
• *2.5x/assets*.blend

Works – although the build rule does say something like “files with name matching”, the matching rule actually uses the path.

A nag here is that I don’t want to have 2 or 4 ‘build’ folders for my assets. Just one folder (that I can trash as a quick and dirty way to make sure no out of data lingers in the system) would be best. This should be straightforward, matching the output like so:

• ${INPUT_FILE_DIR}/../../build/${INPUT_FILE_BASE}.blz

Conflating the output from various files (e.g. 2.4x/assets/foo.blend and 2.4x/scenes/foo.blend ) is possible. Collisions are unlikely, however, so I’ll keep it this way.

Polish?

Silencing the output?

When running blender directly from the desktop, getting console output to show up can be tricky. XCode surely doesn’t have this problem. All debug output appears in the messages window. Too much of it, in fact. Worse, something forces the item matching the translation script to expand.

No luck. I was assuming (maybe wrongly) that blender output is displayed because it is sent to stderr. Either way standing messages to stderr or stdout will yield the same result. Until further notice if I want to avoid script messages blotching the output, I need to disable debug output manually.

Displaying errors during the export process

An issue serious enough that putting it under ‘polish’ may be foolish : how to ensure that XCode will alert us when export errors occur? And by the way, what is an export error?

I tried my luck again, this time by looking at the unit test framework output. I thought XCode may be detecting a simple pattern to identify errors, and it is. The pattern is something like this:

• error: description of error

The space after the colon in error : is required. In python (~2.7), use:

print (“error: something went wrong”)

And XCode will detect the error and display a flamboyant exclamation mark. Neat.

This won’t stop the build from completing but a red exclamation mark is difficult to ignore so it will be enough.

What is an error, then?

A py script failing while running inside blender does NOT cause an error to appear in XCode. This is because blender returns with exit code ‘OK’ regardless. Now that we know how to signal errors to XCode, we can insert validation related errors. But we also want to report an error when our script fails unexpectedly:

    try:
        exportAssets(PATH)
    except:
        print “error: in blender script: “, sys.exc_info()[0], “(see messages window)”
        raise

raise causes the error to propagate, allowing detailed information to appear in the log.

caveat: If the script contains a syntax error, it won’t run. In this case blender will report the error and exit, however we cannot alert XCode since the script didn’t even start running.

(how to cope with) limitations

Limitations with the approach I described derive from the atomicity of the conversion. It has to be done like this:

input file => output file or directory

For level edits, it is fine.

I see a problem when several files want to output to the same deployment directory. For example, it often makes sense to define actors as shared assets (same creatures used in different levels). Although it is a bit messy, it is often convenient to keep several actors in the same blend file. But then what we’ll end up doing is this:

• myCreatures1 => targetFolderA
• myCreatures2 => targetFolderA

This is bad in at least two ways:

• We should cleanup targetFolderA before exporting (to avoid outdated files lingering in the build)
• When exporting myCreatures2, we’ll end up copying over again data output by myCreatures1.

All you have to do is search for FILEBASENAME under your XCode install path; the filepath for each __FILEBASENAME__ .h / .m file clearly indicates what the template is used for; additionally, templates can be opened directly in XCode.

The acquisition of Chomp by Apple sounds like great news for app developers; in the meantime I would like to highlight some of the factors undermining the Genius user experience, hoping as usual that the big guns in California will actually take notice.

While personalized recommendations are a no-brainer nowadays, it would appear that Genius hasn’t been blessed by anything but evil faeries since it’s inception; consumers hoping to dig up great apps beyond the top 200s may be entering murky waters.

Beyond the top 200s?

I own something like 500 apps, most of which are paid games. While I play/test countless titles, I am rather candid in doing so – prioritizing the type of games I like; getting mainstream stuff for the sake of it isn’t my cup of tea.

Last week I checked my favorite top 200s – but I got most of what I wanted from there already; given a kind of stratification process, it so happens that the top 200s aren’t moving very fast. While this isn’t good news for app developers shipping new stuff, it doesn’t constitute in and of itself a reason for Apple to tweak their algorithms and I’m here to talk about something else.

In passing I also note that the top grossing, which used to be handy when looking out for premium games ($3 and above) is now well choked with freemium games. I am, however digressing.

Cold Genius

So I decided to have another look at Genius.

Around 50% of Genius  recommendations are immediately irrelevant to what I like (mind, 500 downloads and counting should be a good start to evaluate recommendations).

Digging up gems using Genius is a convoluted process:

1. There are no more than 4-5 pages to browse.
2. The selection will include any previously downloaded app not currently installed on-device (which is weird, and counter-productive too since one may end up messing recommendations by rejecting apps that are liked, but no longer needed).
3. In order to get additional recommendations, one has to depress “not interested” under each and every unwanted app. However rejected apps do not disappear right away. Instead the only way to make them go away is to reload the page.
4. Rejecting a game from the main category doesn’t tell Genius to remove the same game from ‘games’. This is something I learned the stupid way as I was out for a mix of games and other interesting apps and tended to switch between categories.

After playing the reject-and-reload game for 60 minutes or so, I had finally narrowed my selection down to a dozen of interesting apps. Downloaded 2 or 3 right away , postponed buying a few of the more interesting (and more expensive) games I’d found.

Unlike most sections of the app store, Genius doesn’t support scrolling by swiping. If you want to see the next page, you need to press rather tiny arrow buttons. On iPad, you can scroll by swiping – pointlessly revealing the bottom of pages with a viewable area 5% taller than the screen in landscape mode. Awkward and somewhat disappointing coming from the master of Ux design.

At this point I’m guessing many shoppers give up. They head over to Appolicious or whatever app they use to discover other apps.

25 billion downloads (no services?)

The bummer, however, was a time bomb that didn’t explode for another week, at which point I decided to purchase one of the more expensive titles I had discovered.

I open my iPad, head back to Genius, then…

You guessed. Genius had been hard at work while I left it alone. After a week my recommendations had returned to primal chaos, sending to heavenly hell whatever app I had patiently selected. Gone, nothing, nada.

With more than a hundred games coming out everyday, logic would have it that every player can find games that will suit their taste – even after taking out the krapps.

In the meantime, the one feature that should delight app gourmets turns out to be the fifth wheel of my shopping cart.

This post is password protected. To view it please enter your password below:

Password: