Pinball Mini - Dino Board

In the coming weeks, we'll be adding many, many new boards (in fact, the first one will be submitted in just a day or two).  We're also working on some additional features/refinements (e.g. online leader boards, brag about your score on twitter, etc) for future releases.

More information (screenshots/support/etc) here: http://www.cogitu.com/products/pinballmini/

Just a quick update for anyone waiting on the 2 main features coming in Budgee 1.5 (multiple budgets & integrated web server)... The update was submitted to Apple a while ago, but Apple found an issue in the middle of the week last week. The issue was addressed and re-submitted last Wednesday, so the update should now be going live by Wednesday or so of this week unless things are delayed due to changes related to the Apple announcements on March 17th.

Multiple Budget Support

One of the limitations on pre-1.5 Budgee is that you are always working with a single budget. If you wanted to keep budgets around from previous periods, you couldn't. If you wanted to track other projects, a kitchen remodel for example, you couldn't do that either - not unless that was the only budget you tracked. Starting with this release, Budgee will now support multiple budgets. If you want to delete a budget after you've exported it, you can still do that, but Budgee won't force you to do that if you don't want to.

Multiple Budgets

Budgee Web - an alternative to CSV export

Until now, the only way to extract budget info was via the CSV export to email.  Over the last two months or so, I've been getting more reports of CSV export to email failing for users.  I've released several fixes that attempted to work around the issues.  In the end, there is a bug within the core iPhone/iPod Touch itself that is causing these issues and there isn't anything I can do about it until Apple fixes it (there is an open bug report on the item).  So CSV export to email will remain in Budgee, but you'll get a popup notification if your particular data runs into the Apple bug.  With Budgee Web, all of those issues go away.  In a nutshell, Budgee Web is an internal web server built right into Budgee.  It only runs while you have the Budgee Web screen open and it is only accessible while on a Wi-Fi connection.  It allows you to browse to your iPhone/iPod Touch and download CSV data right from your PC/Mac using Safari, IE, Firefox, Chrome, or whatever you'd like.  Right now, Budgee Web only supports downloading transaction information in true CSV format, but the CSV data that was previously exportable via e-mail is also an option (just not as a .csv file).  This is simply the start for Budgee Web - it's one of the features I would really have liked to hold off on until 2.0, but I'd rather put it in place early so that anyone having CSV export problems can easily work around the email bug.

Budgee Web

Version 2.0 of Budgee will have several upgraded features as well as at least one new major feature. The "under the hood" components of Budgee are also being re-written to support future features and to greatly improve application performance & stability. The 2.0 release is currently targeted for on or before May 1st. Between now and the 2.0 release, there will be a series of minor updates to further improve existing Budgee functionality.

To the Budgee Users

First off, to anyone still having CSV export issues with Budgee - I apologize.  The bottom line is that there is a bug in the OS itself that is preventing it from working (more detail below if you're interested).  After getting a couple of new bug reports since the last update, I've been able to create an example of the problem and have sent it to Apple - but the reality is that the next OS update will be the earliest it will be fixed.  I'm looking into alternatives to the current export method at this time, but do not have a solution at this point.

To Developers Thinking of Using mailto: or Currently Seeing Bugs with mailto:

Since the first version of Budgee, I've been using a simple CSV export method that passes the encoded data to the iPhone/iPod Touch's Mail application.  It's worked great - no issues at all - until about two months ago.  I don't remember which OS update started causing problems...it seems like it was one of the 2.1 releases.  The export code is really simple - it goes like this:

1. Build NSMutableString with data to export
2. Url encode said string so it is safe to use in an url (i.e. convert a space to %20 etc)
3. Tack on a mailto: with a subject & body parameter passing in the url encoded data
4. Call the shared UIApplication's openUrl method

Pretty basic stuff.  Well, as the OS has evolved, the openUrl method has gradually been getting more and more screwed up.  There is no feedback as to what went wrong when you call it - it simply returns "NO" randomly now...which means it did not pass the url to the Mail application...which means my customers can't get the CSV data out of the iPhone app.

My first thought was that I didn't encode things properly.  Sure enough, there were "reserved" characters getting through the encoding process.  I should have done more extensive testing, but from reading the docs (and the method name), one would think using NSString's stringByAddingPercentEscapesUsingEncoding would kinda do what it says.  But that wasn't the case...it escapes some things, but not all things.

So the next approach was something I found on the Apple devforums.  The suggestion there was to use CFURLCreateStringByAddingPercentEscapes to do the escaping.  It certainly looked a little nastier than the NSString method, but whatever works right?  Well, the most recent Budgee update used this new method of encoding.  On my development device, this new fix did indeed make things better and export started working again.  After releasing the update on the App Store, I had several reports of users seeing CSV work again as well - so all was good right?  Wrong.

This weekend, I had more reports of CSV breaking.  After testing for about 4 hours with all kinds of different data, I saw that openUrl seems to fail arbitrarily.  Budgee is a budgeting application where you enter categories and transactions and it tells you how much money you have remaining in your budget.  Well, when I added a new category, just one, the export would sometimes work.  When I took away that category, the export would sometimes fail.  The thing is, the data is more or less the same each time...the is a new record for the new category and the message has a new timestamp, but other than that, nothing changed.  But openUrl refused to actually open Mail about 1/2 the time I tried the export.  After more testing, it seems that even the timestamp can change the url enough to cause openUrl to fail - so it's not just the category data that is causing the problem.

At this point, I have verifed the URL I'm passing to openUrl is correct and encoded properly.  In fact, I went overboard and encoded everything other than basic ASCII letters - that should be overkill, but I saw reports of openUrl failing when periods were in the url (which should be legal)...so I opted to encode the heck out of the thing.  I passed the url to openUrl and guess what?  No dice - still refuses to open.  It does this 100% of the time as long as I hardcode this url into my test application.  So, the good news is that I've opened a bug with Apple (bug #6635825 if that is useful to you) and attached sample code that should reproduce this error consistently.  Before I opened this bug, there were posts by an Apple employee (also on the devforum) stating that they know there are issues with mailto: links, but they essentially haven't been able to track down what is happening to cause the issue.  Maybe the sample code I posted to them will help.  The bad news is that my customers still can't export data sometimes and I have no workaround other than to try adding a new category, transaction, etc. and then trying the export again.  That is totally unacceptable for me - but the only other workaround I can do is to totally re-write the export to use a method other than a mailto: link...but of course, that's not a trivial thing to do quickly.

The bottom line for developers is that if you're thinking about using a mailto: link to export data, be ready to hit this issue and have to wait on Apple.  It still isn't clear what triggers it.  It may be the complexity of the data I'm exporting, but it's just not clear.  There are quite a few reports around the different forums where people are having similar issues - so I know Budgee isn't the only app exhibiting this problem.  It looks like the only reliable way to get this data off the phone is to send it yourself via web service calls, export to google docs, built-in web server, etc...all of which are considerably more involved (for the dev and/or end user) than the mailto: link.

Hopefully, everything will be approved in another day or so...usually the approvals do not take longer than a week unless Apple finds something they want changed first (in which case, it takes about 2 weeks for them to let you know what is going on).  I'll post an update here once I get the green light from Apple.

I'm currently working on a fix and should have the update submitted to the app store late this evening.  I'll post again once everything is in the App Store, but hopefully the update will be downloadable from the App Store by Wednesday Feb. 4th if not earlier.  

In the meantime, if you'll hold off on resetting your budget until Wednesday (and track new expenses via an alternate method temporarily), you'll be able to export your existing data again.  If you don't care about doing an export, then you can just keep using Budgee as usual.

Introducing...

So we've been working on this concept for a little over a month at this point...mostly doing tech prototypes and initial graphic designs. We're still pretty far away from releasing the game - probably around 2 months away if all goes well, but I wanted to give those of you that read this blog an early look. Since this is the first game either of us have undertaken, there are plenty of things we have to figure out along the way. We've both played plenty of games, but to go from wanting to build a game to turning it into a reality is quite a challenge.

The basic idea for the game is that it's a cross between a "sliding puzzle" (where you have tile pieces that have to be moved into a certain configuration, but only certain moves are allowed) and a "rolling ball" type of mechanic. Additionally, there will be a bit more flavor to it than that, but if you combine those two concepts, you've got the core concept of ROLLAB. I love this concept because it's a great fit with the iPhone/iPod Touch's touchable display (for sliding tiles) and the accelerometer (for controlling the ball).

To give you some idea of what I'm talking about, here's an early (as in pre-alpha) version of ROLLAB:

NOTE: All graphics are very much in development so things are very likely to change as we move forward.

You'll start off with a sample of Recombinant Organic Liquid, or "ROL" (the green sphere in the shot above), which will be placed within a test chamber. Your goal will be to observe & guide the ROL as it experiences different stimuli which are provided by injectors (the small silver object with the 5 green spheres inside) located at various points within the chamber. Within each chamber, there will be an exit point (the red opening in the bottom right) that you must guide the ROL to in order to complete the experiment, but in order to do so, you'll have to overcome certain challenges. You'll have the ability to manipulate the test chamber by rearranging certain objects (the white blocks in this example), but some objects can only be manipulated once certain conditions are satisfied.

At some point in the not too distant future, Chris will be posting some of his thoughts about the game development process from his perspective and I'll be doing the same from my perspective. Hopefully it'll be interesting to watch the game's progress (particularly if you're wondering what it would take to create an iPhone game). We still have tons of issues to work out (e.g. how to calculate a player's score, developing the sound components, several more secondary game mechanics, etc) and as we work though each of these, I'll share our thought process right here. So expect to see plenty more ROLLAB posts (particularly about the technical challenges) on this blog soon...I may even get an early gameplay video online in the not too distant future so you can really see why Chris and I are so excited about this project.

Additional export/backup/sync option(s)

I realize that the CSV export Budgee provides is useful for archival purposes, but the current CSV export was never meant to be the only way to get data out. I'm writing another post about the whole data export situation on the iPhone, but the short version is that the CSV export was the easiest and most "universal" format to add and I didn't want to ship Budgee without some form of export. Going forward, there are several different paths to choose from, but at this point, Budgee will likely get a small desktop app for Windows & OS X. What that desktop app will allow (other than exporting Budgee data) is TBD at this point, but this approach seems to be the most appropriate way to go.

Import option(s)

Along with the backup/sync feature, the other big feature that Budgee needs is a way to import data. If you backup your budget via CSV, you can do whatever you want with it on the PC/Mac, but you can't get it back into Budgee. In a future version, you'll have at least one way to restore the data...so if you end up needing to reset your device for some reason, you don't have to worry about re-entering your budget and transactions.

Multiple budgets

Right now, Budgee only supports tracking one budget and then you reset that budget when you're ready for the next budget cycle. One situation I've wanted to use Budgee in, but couldn't, is where I had my main "household" budget, but then I had a couple of small projects (e.g. kitchen remodel) that I wanted to keep a budget for as well...which I couldn't do. So, in the future (probably in the 1.5 release), Budgee will allow for multiple budgets to be used at one time. Along with this will will come the ability to name a budget. With this new functionality, you'll also be able to keep a budget for each month, week, year, etc. if you so choose (although I still feel that there are going to be better apps out there if you're really wanting to keep detailed budget statistics on the phone).

Shared budgets

This feature will be one of the last to be implemented, because it's the most complex to create and the most expensive to maintain. Budgee currently works pretty well for a single individual, but if you're really wanting to do budgeting the right way, everyone with access to the same finances (husband & wife, entire family, significant other, etc.) should be sharing a common budget even if everyone uses a different device. If you don't do this, then even though Bob & Jane budgeted $200 this month for food, Bob can spend $200 and Jane can do the same, but neither will know the other had spent that amount until it's too late. At this point, I'm expecting this particular feature will be one of the big features in Budgee 2.0.

Income tracking

An ideal personal budget is one that is zero-based - meaning you spend every dollar you make on paper such that:

budgeted income - (budgeted expenses + transfers to savings/investments) = 0

If you really want to do this today, you can enter categories and transactions with negative amounts, which will negate your budget expenses and allow you to do this, but Budgee 1.5 will make this a little more elegant for those that want to keep a zero-based budget. This will also give you the ability to see how much money you should have left AFTER all of your budgeted expenses (if you don't use a zero-based budget).

User Requested Features

There are several features that have been requested by current Budgee users, the top ones being:

• Numeric keypad to enter transactions more quickly
• Ability to "turn off" certain categories for a particular budget (without deleting them)
• User specified currency for budgets (effectively overriding the device's built-in regional setting)
• Set overall budget amount explicitly instead of summing up all of the categories
• Protect access to your budget(s) with a PIN/Password

Plus several other smaller enhancements to make things flow a little better, be easier to read, etc. Most of these will be options that are turned off by default, but you as the user can opt to enable them if you so choose. Budgee is still going to focus on being the most simple, elegant, and useful budgeting app out there - so the default configuration will still be as straightforward as ever, but hopefully Budgee will be adaptable to meet just about anyone's needs with these enhancements.

Various internal changes

Starting with version 1.5, Budgee will be using an entirely new architecture and most likely, a new design (although it'll be in the same spirit as the current design). Other than some visual tweaks, what this means to you is that Budgee will be more stable, better performing, and more streamlined.

If you have additional ideas you would like considered, feel free to leave a comment on this post or let me know at support@cogitu.com