Since you’re reading this, I’m going to go out on a limb and guess that you’ve only landed on my blog in order to enjoy a quick moment of mirth at the expense of the imperfect proles who actually need my advice.  Drink it in.  You’ve earned it.

If you don’t fit into that camp, don’t worry!  You’re exactly the person that they had in mind when they designed Ruby!  Or Python!  Or any one of a dozen other languages with a REPL.  Don’t worry, I know you know what a REPL is, but I’m going to prove that I know what it is, so that you can skip straight to agreeing with me, thereby proving that you knew what I was talking about the whole time.

“REPL” is just technobabble that means “Read-eval-print loop”.  Still too much technobabble?  The REPL is the cool little tool that lets you run big-boy code from an interactive shell and it gives you the ability to get inside the computer and poke around while your program is running.  It’s so simple.  It’s IN the computer…:

I’m (not) a computer

The above screenshot gives a tiny example of the sorts of things you can do with your Ruby REPL.  I picked Ruby for this example, but you’d see something similar in any language that provides a REPL.  You can do simple stuff like print a string, or, even better, you can dig into your application and just mess with things!  After all, who doesn’t like to mess with things?!  That couldn’t possibly have side-effects, right?

Anytime you can use an interactive mode like the ones I mentioned above, it’s going to be easy to get close to the application that you’re developing.  These tools are extremely powerful, especially when you combine them with some sweet Dependency Injection action.

One day, you’ll see the light that is Java and you will be amazed.  With a healthy supply of semi-colons, you’ll migrate your application to Java while shedding a tear for all the lost time that you could have spent together.  Migrating from one language to another is easy, so you’ll immediately want to fire up your Java interpreter and mess with all of the things in your new Java app.

Unfortunately for you, Me-from-the-past is going to tell you “No dice.”  Java doesn’t come with an interactive mode out-of-the-box.  The closest that you could come to a REPL in Java was using the Java Management Extensions (JMX) to examine registered resources.  After you register a few Beans, you’ll hopefully be able to run something like JConsole to look at your application’s guts.  If you did everything right, you’ll probably see some objects that you can look at… and you’ll immediately begin thinking that maybe you should migrate back, if only to get your REPL back.

Fortunately for you, Me-from-right-now is here to tell you that our own brilliant Marshall Pierce has felt your pain and has leveraged the arcane magics of Groovy and SSH to provide you with a mega-hammer that he assumes you are not going to use to hit yourself in the face: a interactive prompt for your JVMs, both local and remote! A local REPL for exploring your app in dev mode is great, but a remote REPL for poking around in your live app is even better. (Where by better, I mean dangerous and awesome.)

“Wh—…H—…How did he do that?” you might ask, ever so eloquently.  Basically, you’ll embed a tiny SSH server that exposes a Groovy shell that can execute arbitrary code inside a running JVM.  Marshall has helpfully provided a small demo app that shows exactly what this looks like.  Seriously, go run the example project.  When you do and you realize how you have now become the master of time and space, you won’t have anything to say except, “That was easy.”

Hopefully, you skipped right over that part about executing arbitrary code in your JVM, because that sounds terrifying.  But, if that made you a little queasy, you can rest easy knowing that your precious JVM is safe and sound.  With only a few more characters, you can tell your app where to find a set of public keys (RSA or DSA) that it can use to authenticate SSH requests.  Now, when you run your Groovy shell, you just have to specify the location of your private key file, and you’ll automatically get the secure handshake that feels ever-so-good.

If you’re looking for more detail, you should check out the project’s public GitHub page, where you will find helpful instructions on how you can start poking around where James Gosling never intended for you to be…

The post One Weird Trick to SSH into your JVM appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.

Today, Palomino Labs is equal parts proud, confused, and apathetic to announce the release of 2 Tumble 2 Jump, the second in a series of games that puts the player squarely where they want to be: in the mind of a frozen tumbleweed.

The masses have spoken!  We have listened to what they said!  And we have ignored what they said in favor of bringing you more Tumble Jump!!!  After all, who knows you, better than us?  And we say that you want more tumbleweeds!

You probably thought that your phone doesn’t need more than one game about tumbleweeds.

You probably thought that you could escape Ol’ Slopey Mountain.

You probably thought that Yetis and cacti don’t share exactly the same shape.

You probably thought that we would introduce new mechanics in a sequel game.

YOU THOUGHT WRONG!!!

We humbly accept your apology, and we offer you the chance to atone for your past mistakes by downloading 2 Tumble 2 Jump right now.  You’ll find the same tumbling and jumping that enthralled you the first time around, but this time it’s winter.  What does that mean?  It means that there’s snow now!  And Yetis!

Submit your PTO requests; arrange for the kids to stay at Grandma’s; prepare the hydration IVs— because you’re going to want to play this game way more than you should.

The post 2T2J Release appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.

Tweaks is designed to bridge the gap between developers and designers during the development phase of a project.  Unless a single person is playing the roles of both the designer and the developer, there’s going to be a lot of communication overhead during the refining process of the UI.  The process usually starts with the designer bringing mockups to the developer.  The developer takes these screens and tries to get as close as possible to what the designer had in mind.  Since we’re talking about (at least) two different people, thinking in (at least) two different ways, we can almost guarantee that the product is not going to match the vision.  Even if the developer somehow magically manages to implement the exact thoughts of the designer, it may turn out that what the designer had imagined doesn’t make sense after all.  Regardless, in a project of any scale, both sides are going to spend a lot of time going back and forth in a conversation that you might recognize.

Developers and Designers: Can’t we just get along?

The real problem here is that we can’t afford to have designers and developers working on the same screen while a UI is being created.  It would be hugely inefficient because they speak different languages (or at least different dialects) and it’s pretty much impossible to keep both people actively working the whole time.  That’s why we’re forced to have this back-and-forth conversation that wastes time with multiple deployments and context-switching.

It seems to me like Tweaks is going to consolidate the back-and-forth into a single conversation that looks more like this.

Fewer iterations == more efficient.

Tweaks allows a developer to expose certain UI properties to a designer (or really, anyone who has a dev build of the application) who can update those values dynamically.  While the designer is reviewing the developer’s work, they can use the shake gesture to bring up a secret menu that lets the designer change values on the fly.

One easy example to imagine is adjusting the background color.  This is an extremely easy task for a developer, but the time required to redeploy and pass the changes on to the developer is going to be wasted.  On the other hand, the designer might not know how to change the background color and might not even have access to the source.

Before Tweaks, the developer probably would have hardcoded the view with something like this:

self.backgroundColor = [UIColor colorWithRed:0.2
                                       green:0.9
                                        blue:0.2
                                       alpha:1.0

And then when the designer comes back and tells the developer that the background color should be more red, they’ll update those hardcoded values and push a new version to the designer.  If the designer doesn’t have specific RGB values in mind, this could be repeated several times while they zero in on the color that is “just right.”

Instead, Tweaks is proposing that you replace those hardcoded values with a Tweaks macro like this:

self.backgroundColor =
    [UIColor colorWithRed:FBTweakValue(@"Window", @"Color", @"Red", 0.2)
                    green:FBTweakValue(@"Window", @"Color", @"Green", 0.9)
                     blue:FBTweakValue(@"Window", @"Color", @"Blue", 0.2)
                    alpha:1.0

The first three arguments describe where in the Tweaks hierarchy you’ll find the adjustment.  In this example, you’d be able to change the red component of the RGB value by going to the “Window” section and looking for the “Color” section of that table.  As you can see below, you’re able increment or decrement the values that developer exposed, or you can tap the value itself to show a keyboard if you have a specific value in mind.  In addition to numeric values you can expose other basic data types like strings and booleans.

What the designer will see after they shake the device and navigate to the leaf values.

Are you worried about how this library will affect your production releases?  You should be!  However, you can rest easy knowing that the adjustment functionality is disabled by default in production.  When you deploy in production mode, the macros are expanded into the default values that the developer provided.  This means that you don’t incur any performance penalty for evaluating values, and at the same time you don’t expose any secret dev options to the end user.

Final Thoughts?

• It’s a very cool idea and one that I’d really like to start including in my iOS projects.
• Fortunately for us, Ron (the brilliant gentleman who most often wears the designer hat at Palomino) is more than capable of manipulating an iOS view himself, so I’m not sure how much time it would actually save us.
• This is still going to require some designer-developer face time, so that the developer can show the designer what things can be tweaked.  It’s easy to understand in a small example, but when you have a real app with lots of changeable properties, the developer is going to have to be very careful about how he organizes the hierarchy of adjustable properties.  It would be very helpful to take some time to explain his scheme to the designer.
• This library would really benefit from an export function.  When a designer finishes making all of the adjustments that he wants, there should be some easy way for him to pass the new (changed) values back to the developer.  As far as I know, there is currently no functionality to do this.  Update: it looks like this ticket was raised to accomplish the exact thing that I want, but it hasn't been merged yet.  Hopefully soon!
• The library is still young and has a few rough edges.  For example, installation via Cocoapods did not work for me.  I found this issue that claims to resolve the problem, but it was easier for me to just drop the library into my project.  If it continues to grow and be maintained, I expect these sorts of problems to disappear, but make sure you go into it with your eyes open.

The post Too Much Pressure or: How I Simplified My iOS Design with the Tweaks Library appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.

As you’re reading this, it’s important to keep in mind that the Ninefold Rails platform is relatively young and still looking to build out it’s feature set.  With that in mind, a big part of what I’m evaluating is potential.  There are certainly other, more mature tools that have more features, but what I saw in Ninefold was promising enough to bring it to your attention.

Interface

Before you start using Ninefold, you should know that the GUI is going to let you do most of the things you want to do, but it’s going to be in a very no-nonsense kind of way. If you came from the Ninefold home page—which looks very cool with its faceted design—you might be expecting a dashboard with a lot of personality and a cool design. I wouldn’t call any of the dashboard pretty, but any developer is going to be immediately comfortable within it, and it’s going to let you get things done efficiently.

The last time you’ll see any color…

The no-nonsense dashboard

I found that it was fairly straightforward to navigate around the dashboard and I never found myself asking “Where do I go now?”

The one big downside to the web dashboard is that it tends to be slower than I’d like.  Every tab is a separate page load, and it doesn’t take long to start feeling the pain of that.  That said, I didn’t feel like it was unusably slow and I’m hoping that that’s something that would improve with time.

Logging

In my experience, log aggregation is one of those things that seems like it should be easy, but is never as elegant as I would like it to be. I am very happy to say that this is not the case for any Ninefold apps that you might create. Once you deploy an app, the Ninefold dashboard shows a logging section that makes debugging and issue resolution much easier.

The logs for my application along with the sources that are available.

Log Searching

If you look at the screenshots, you’ll notice that the dashboard kindly offers you the ability to string-search whichever logs you’re looking at. When I look at a log, I almost always want to do some kind of search like this, so the fact that it’s built in is pretty cool and it saves me a bunch of munging that I might otherwise have to spend time on. As happy as I was to see a built-in log searcher widget, I was even more excited to see the ability to select sources and hosts of logs to filter by.

Log Filtering

When I write to a log, I always feel like I’m trying to walk a fine line between giving enough information to diagnose issues that may crop up and giving so much information that the really important stuff is lost in a sea of garbage. Ninefold makes me feel much better about my logging because they allow you to restrict what you’re looking at to one (or many) of any of a dozen different logging mechanisms. Most of the time, I don’t want to see something like the migration logs, so I can remove those from the list of what is displayed. Being able to filter at a high level like that is really cool and it’s something that I’m going to miss the next time I’m not on Ninefold. It’s worth noting here that you can do the same thing, relative to the servers that you’re deployed on. If you’re running on two different hosts, you can restrict your log view to only look at the host(s) that you’re concerned with. I was running a simple app with just a single host, so I didn’t have reason to use that feature, but I can imagine it being really cool in a high-traffic production environment.

Support

It seems to me like Ninefold is still trying to gain traction (at least here in the States) so they don’t have nearly as big of a user community as some other platforms might.  When I started using Ninefold, I was a little worried that this would mean that it would be easier to get stuck on one issue or another.  After using it for a while, I think that it would be hard to argue against that unfortunate truth.  However, in my experience, the in-app support that Ninefold offers is good enough that the smaller community ends up not even being a factor.  I rarely had any problem figuring out what to do next, but when I did get stuck, Ninefold has a little “Chat Now” dialog on the bottom of every page that connects you almost instantaneously with a support person.  Normally, I avoid these support chats as much as possible, but the person who answered my support requests was prompt, obviously familiar with the framework, and had the power to solve my problem.  I’m no longer worried that I’ll run into any sort of significant blocker that would halt my development.

Data Migration

The thing that I was probably least happy with during my Ninefold experience was the way that you interact with data.  I started with an app that one of my coworkers built that tracks the beers that we’re trying at Palomino Labs.  The app is new and the existing dataset is relatively small, so I wanted to import the data from the real app into my test app.  Unfortunately, it doesn’t seem like there’s a good way to do that from the dashboard.  I was able to take a snapshot of the other database without any problem, but I couldn’t find any way to bootstrap my app with that snapshot.  I ended up using the Ninefold CLI gem to manually recreate a few important pieces of data (e.g. app user accounts) and then living in a sad reality where my app didn’t have much data.

At this point, I would like to add two caveats to my complaints here.  First, like I mentioned above, Ninefold provides a CLI that I didn’t explore much, but that seems like it would be pretty useful.  I didn’t try to do any sort of data restoration through that system, instead preferring to use it just like a Rails console.  It’s possible that the CLI provides a way to restore database backups, but I was trying to restrict my usage to the dashboard as much as possible.  The second caveat is that I mentioned this specific use case to one of the Ninefold developers last time I had a chance to talk with them, and it sounded like this might be on the short-term roadmap.  I’m hopeful that the next update to the dashboard includes a means to restore backups.

Deployment

The first thing that I’ll note about deployment is that it’s extremely easy.  If you have a git repo in Github or Bitbucket, Ninefold provides you with a handy little wizard that will create your app in about 30 seconds.  It’s easy to deploy from branches, and you can check a box to add post-commit hooks that will automatically redeploy  your app whenever you make a change.  I never had any problems with the post-commit hooks on this project, but one of my coworkers reported that the hooks stopped working for him mid-development.  This is one of the areas that I’m willing to overlook some rough edges because of the new-ness of the platform and I’m fairly confident that this is a piece of functionality that the Ninefold developers are fully on top of.

The big downside to the deployment process was that it seemed to take a fairly long time for me.  Due to a few of my own mistakes, I had to redeploy our (small) app 3-4 times in a short timespan, and it seemed like I was waiting about 10-15 minutes for each deploy.  I don’t expect anything blazingly fast, but I spent more time waiting on a deployment than I would’ve liked.

Add-Ons

At the moment, the Ninefold ecosystem is a little bit young and that shows in the number of add-ons that are available to include in the app.  There are a handful of cool-looking modules (e.g. New Relic, SSL, etc.) that you can add to your app with the click of a button, but you’ll need to wait (or roll your own) if you want to use any modules that aren’t on the shortlist.  That said, the number of add-ons that ARE available right now is totally reasonable given the age of the platform, and they claim some interesting functionality (like when they set up a New Relic account for you, if you don’t already have one).  I’m optimistic that more tools are going to get added as time goes on, so if you have something you need, try reaching out to them.

Environments

I have yet to see a Rails hosting platform that is really good at splitting an app into different environments (e.g. staging and production environments for a single logical app) and I didn’t feel like Ninefold did much to solve that problem.  I only deployed one version of our app, but when I talked to Hayden about how he solved the environment problem, he told me that he just handles the environments as separate apps.  So, we have one app for production and one for staging and there is nothing (except the code) in common between the two.  I don’t fault Ninefold in any way here, because I’m not sure how I want these to be related in the interface, but it seems like they could be linked better.

Overall

After spending some time with Ninefold, I’m fairly happy with the service.  It’s still a young product, but what they have is solid and, even better, they seem to be moving in the right direction.  If you have the time, I’d definitely recommend checking it out to see if it fits in your workflow.

The post Easy, Fast, Powerful: This is Your Rails on Ninefold appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.

However, what is revitalizing from an individual’s perspective can end up becoming destructive when you look at it from a step back at the team level.  When team-members are frequently moving to new projects and new clients, it can be nearly impossible to get a good sense of what anyone else is working on.  Developers begin to get siloed and you lose all the benefits of collaboration and over-the-shoulder-ness that working together conveys.  When you have to give the person next to you 15 minutes of context before you can ask what should be a simple question, it becomes hugely expensive and inefficient to get a second opinion on anything.

At Palomino, we had an influx of new projects last fall, which meant that we were more distributed than we had been in the past.  We saw a few indicators that we now think might be early warning signs:

• Very few questions asked during a weekly sprint review.  We expect our internal sprint review audience to provide a thorough critique of the work done during that sprint.  Asking questions is the first step in the process, and the absence of questions usually means that either the presentation was flawless or that the audience is not really engaged.
• Meetings dragged out due to a need to fill in missing context.  When team-wide decisions need to be made, the discussion should be around the various options.  However, we found that we were spending a significant amount of time just bringing the team up to speed and making sure that everyone had an understanding of the issue.
• Reduced accountability to the team.  When the rest of the team doesn’t have a good understanding of the commits that you’ve made for the week, it’s hard for them to hold you to those or ask why they might not have been completed.

Ron, Drew and I decided to spend some time with our heads together to figure out how we could address these issues.  We started out by coming up with a list of requirements that we wanted to satisfy:

1. Team-members should not have to actively do anything to see the commits of other teams.
2. The solution has to be usable by remote team-members, since we’re not all in the same office.
3. The solution should easily integrate into our daily standup meetings to provide advance notice if a deadline is going to slip.
4. Team-members should be able to indicate progress on their commits over the course of the week.

The first solution that we considered was creating a new Trello board that had columns for each team.  Our team uses Trello on most projects anyway, so it seemed like a convenient option. The problem with this approach is that we wanted a permanently visible fixture on the wall reminding us of our weekly commits. As much as we love Trello, the flaw with this solution is that we need to actively seek out the information. Since we make a point of not bringing laptops and other distractions to standup meetings, it would be disruptive to check a Trello board during standup.

From there, we decided to go the low-tech, physical route.  For a few weeks we tried writing on a big whiteboard that was mounted in our main workroom.  This worked well insofar as it did a good job of keeping the people in the office informed about project status.  However, it was very difficult for our remote employees to be involved in this process.  We tested several different webcams and even gave FaceTime a try, but the results were never very compelling.  It was always hard to read the writing on the whiteboard and it was a significant amount of work to get everyone connected to Skype or whatever flavor of video we were currently trying.

Based on our experiment with the whiteboard, we realized that we really wanted a camera feed that broadcast in high-definition, was always on, and was available to anyone who we wanted to give access to.  Furthermore, we discovered that sometimes we wanted to be able to take down the details of our sprint without removing them completely (e.g. we obviously don’t want to let clients see the confidential information of other clients if they’re in our office).

With all that in mind, we arrived at the solution that we currently have in place.  We hung a Dropcam on the ceiling in the conference room that we use for standup and got some poster-sized post-it notes that we could stick to the walls.  The Dropcam Pro has surprisingly good clarity for such a small camera and required less than 10 minutes in setup time.  Once we had the camera set up and calibrated, we were able to pass out a login that would drop any Palomino employee into a real-time view of our sprint board instantly.  Although our sprint board is big enough to be readable through the Dropcam, the whole setup is small enough to be easily moved or taken down if we don’t want it displayed in the conference room.

The setup:

And the clear view from the Dropcam:

We’re still fine-tuning a few small details of this process, but we’re very happy with our current solution, especially since we spent less than $250 on the whole setup ($199 for the Dropcam Pro and $38 for the first batch of Post-it pads).

The post How To Put Your Distributed Development Team On The Same Page appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.

We’re particularly excited about the digital medium that Rumrunners is going to use for gameplay. We’ve spent many of our weekly Spielnacht (Game Night) gatherings playing games in the “traitor” genre. Specific mechanics in this genre vary from game to game, but the common thread is the hidden information that’s handed out at the beginning of the game and the later discussion that’s used as an attempt to reveal that information. For example, one of our favorite games, The Resistance, has the players collectively trying to figure out who among them are spies. Throughout the game, players elect subsets of the group to go on missions. Loyal members of the resistance will help pass the mission, but if a single spy has been selected to go on the mission, they’ll cause it to fail. Whichever group can put 3 results in their favor first wins the game.

We love this type of game because of the social connections that it creates between players. Information is critical, so it really means that the group is encouraging everyone to take on an active role in the game. Unfortunately, the game can be completely ruined by something as simple as a card accidentally being flipped over.

After many, many games (with an embarrassing number of restarts due to accidents) we decided that we could fix these problems with a quick and dirty app. We started talking about what we wanted the app to do, and suddenly a whole new world opened up. We realized that in addition to making it easy to distribute secret information, we could create exciting new mechanics that wouldn’t have been possible. For example, what if a player had the chance to, once per game, make it so that no one could see the number of votes for or against some proposed action. As we began to tinker with various ideas, we realized that we were creating a whole new game, and it quickly grew beyond its initially humble beginnings.

I’d love to tell you about some of our more interesting ideas, but we’re saving those to reveal during our Kickstarter campaign. Become a backer today to stay updated on all the new gameplay mechanics that we’ve created. It’s going to be a wild ride!

The post Rumrunners Kickstarter Campaign appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.

Unfortunately, while you were reading that last paragraph, ten other developers each launched a new game and the same fickle users that downloaded your game solely because it was free are going to leave your game behind in search of other entertainment.

In an increasingly competitive App Store, it’s important to update your app semi-regularly. This serves a dual purpose: giving your users new features that provide a better experience and reminding your users that they already have an app on their phone that is worth opening.

At Palomino Labs, we’ve found that it can sometimes be difficult to find a nice bite-size chunk of functionality that makes sense as an app update. When we recently re-evaluated our game Tumble Jump in preparation for an update, we came up with several ideas, but the one that I want to focus on in this post is Game Center integration.

There are plenty of good resources that provide step-by-step instructions on how to integrate Game Center, so this post will assume that you’ve got at least a general idea of what your integration will look like. Rather than a complete tutorial, you should consider this to be a list of a few tips that will hopefully make your life a little easier if you decide to integrate Game Center.

Watch Out For Disabled Game Center

One of the more questionable features of Game Center is the watchdog that ensures that users aren’t prompted to log in too many times. The idea is that if a user has seen three login prompts without actually following through with the login process, then that user isn’t interested in Game Center and should never be shown the login prompt again. In theory, it’s not necessarily a bad idea; users will quickly become fed up with closing what feels an awful lot like a popup ad. In practice, it means that once a user has used up their three cancels, they will never again be able to get into Game Center from your app, even if they initiate the action (i.e. pressing the Game Center button on the menu screen of your game). The worst part of this is that Game Center will swallow up your request to begin authentication without so much as a peep. There is no message to tell the user that they have disabled Game Center and any time they try to interact with Game Center functionality it will look like a freeze, crash, or bug.

So how can we resolve this issue? Unfortunately, there is very little that we can do to alleviate the pain of a disabled Game Center. First, let’s look at our initial implementation to see where we might make good of a bad situation:

GKLocalPlayer *localPlayer = [GKLocalPlayer localPlayer];
if ([localPlayer respondsToSelector:@selector(setAuthenticateHandler:)]) {
    [localPlayer setAuthenticateHandler:^(UIViewController *viewController, NSError *error) {
        if (viewController) {
            self.gameKitAuthViewController = viewController;
        }
    }];
} else {
    if ([[NSUserDefaults standardUserDefaults] boolForKey:kHasEnabledGamekitUserDefaultsKey]) {
        [localPlayer authenticateWithCompletionHandler:nil];
    }
}

Something that should jump out is the error in the completion block. We should be able to discern why authentication failed (or if it was never started) by examining that error. In fact, we do get a little bit of information from the error; unfortunately, the information is not as useful as we might hope. The message that comes to us with the error reads something like:

ErrorDomain: GKErrorDomain Code: 2 "The requested operation has been cancelled"

Well…yes, that is technically true, but the error that is returned is the exact same “error” as the case when the user cancels a login attempt. What this means is that we see the same error when a user closes the authentication dialog and when they never even see the dialog in the first place.

Faced with this issue, we decided that an extra alert was a less bad experience than the appearance of a crash, so we use the error to remind the user that Game Center might be disabled. Once the alert has been included, we ended up with an authentication handler that looks like:

GKLocalPlayer *localPlayer = [GKLocalPlayer localPlayer];
if ([localPlayer respondsToSelector:@selector(setAuthenticateHandler:)]) {
    [localPlayer setAuthenticateHandler:^(UIViewController *viewController, NSError *error) {
        if (viewController) {
            self.gameKitAuthViewController = viewController;
        }

        if (error) {
            if (error.code == 2 && [error.domain isEqualToString:@"GKErrorDomain"]) {
                UIAlertView *alertView = [[UIAlertView alloc]
                        initWithTitle:@"Game Center"
                              message:@"If Game Center is disabled try logging in through the Game Center app"
                             delegate:self
                    cancelButtonTitle:@"OK"
                    otherButtonTitles:@"Open Game Center", nil];

                [alertView show];
            }
        }
    }];
} else {
    if ([[NSUserDefaults standardUserDefaults] boolForKey:kHasEnabledGamekitUserDefaultsKey]) {
        [localPlayer authenticateWithCompletionHandler:nil];
    }
}

Now, when a user declines to login to Game Center they will be alerted that Game Center can be disabled. Additionally, this updated handler means that when Game Center has already been disabled, the user will be given a route to fix the perceived problem if they try to take any Game Center actions. It’s worth mentioning that this isn’t a particularly elegant solution, it’s simply the least bad of the few options that Game Center has left us.

Finally, you may have noticed the second button in our alert. Since we can’t do much else to remedy Game Center’s state, we give the user the chance to go directly into the Game Center app with the following delegate method:

- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex {
    if (buttonIndex == 1) {
        [[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"gamecenter:"]];
    }
}

Use Separate Leaderboards Based on Game Conditions

One thing that Game Center is really good at communicating is rankings on a leaderboard. With essentially zero developer work, Game Center will happily tell the user exactly what ranking they have relative to other players, and it will even show what percentile the user is in. The catch is that for the information to be actually useful, users need to be compared to other users that are playing in the same conditions. We found that the definition of a “good” score changes drastically across difficulty levels and across device types. So instead of a general-purpose leaderboard, we broke our leaderboards into separate categories based on playing conditions. If your rankings are too broad to mean anything to a user, they have no reason to spend any time looking at them.

Put Some Thought Into When Achievements Should Show

It’s nice to pat the user on the back when they earn an achievement, but you should make sure that you’re not congratulating them over and over again. One example of this that we found in Tumble Jump was that we were awarding an achievement for playing the game for more than one hour. At the end of the game, the controller would add up the time that you had played so far and if it was more than one hour, it would present the achievement. The problem was that the next game that the user played, the controller would again indicate that they were over the one hour threshold and it would display the banner again.

Luckily, Apple has a setting called “Achievable More Than Once” on their achievement settings screen. So we can just turn that feature off and we won’t show achievements after the first time, right? Wrong. If you open up the info icon next to that setting, you’ll see that this setting applies to challenges, and when you turn it off, the user will continue to see achievement banners every time you post them.

What this means is that if you don’t want to annoy your users with extraneous banners, you can either switch on the GKAchievement.completed property, or you can keep your own state in something like NSUserDefaults. We decided that since we were already keeping state for aggregate-type achievements (like 1 hour total gameplay), we would decide ourselves whether or not we should update the Game Center achievements:

if ([GKLocalPlayer localPlayer].authenticated) {
    int actions = [[NSUserDefaults standardUserDefaults] integerForKey:@"actions"];
    if (actions < 5) {
        actions++;
        [[NSUserDefaults standardUserDefaults] setInteger:actions forKey:actions];
        [[NSUserDefaults standardUserDefaults] synchronize];
        GKAchievement *achievement = [[GKAchievement alloc] initWithIdentifier:@"Achievement"];
        achievement.showsCompletionBanner = YES;
        achievement.percentComplete = actions * 100.0 / 5;
        [achievement reportAchievementWithCompletionHandler:nil];
    }
}

Be Wary of Overly Long Descriptions

At Palomino, one of our favorite parts of game development is writing the user-facing text. Probably no one will ever read it, but we have a lot of fun writing instructions, dialogue and App Store content that we think gives the game some of our own personality. Unfortunately, Game Center implicitly imposes a very small character maximum by truncating all text past a certain point. Apple will actually allow you to enter quite a bit of text when you are creating the description, but when you actually run the app, it’s easy for this

to turn into

When you write a description, the best practice is to check out the resulting display across a couple of different device sizes. When you’re checking for truncation, you’ll need to check the completion banner and the two different types of display (detail vs list views) in Game Center.

Default Open Location For Leaderboards

When creating multiple leaderboards, Apple’s interface takes the first leaderboard that you create and calls it the “Default” leaderboard

From that point on, when you present a leaderboard controller, the controller will open into that default leaderboard, regardless of what preferences the user has set (in our case, what difficulty the user was playing on). If the default leaderboard is not applicable, the user still has to go back one view before they see the list of all leaderboards. We decided that this particular behavior was not very effective for our purposes; luckily there is an easy fix for it. When presenting a leaderboard view controller, set the category to be nil. This directs the user to the root leaderboard view, where they can navigate to whichever area is most appropriate. Now, when we want to present the leaderboard, we can write:

GKLeaderboardViewController *leaderboardViewController = [GKLeaderboardViewController new];
leaderboardViewController.leaderboardDelegate = self;
leaderboardViewController.category = nil;
[[CCDirector sharedDirector] presentViewController:leaderboardViewController animated:YES completion:nil];

This will result in being taken to the list screen

instead of the detail screen, which might not apply

The post iOS and Game Center: Tips to Avoid Sad Times appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.