Category Archives: Apple / Macintosh

[[UIDevice currentDevice] orientation] vs [[UIApplication sharedApplication] statusBarOrientation]

Biblicious was originally an iPhone only app because the iPad did not exist.  When the iPad was coming out, I used a similar algorithm to my Elastic Window product in order to naturally scale up the drawing so that the game looked just as good on the iPad as it did on the iPhone. The iPad was released, and then the iPad2 was released, and Biblicious still only worked in portrait mode.  After a few requests and knowing that Apple prefers iPad apps to work in any orientation, I started the work of manually repositioning controls on the game screen.  After a couple of days of work, mostly in the iOS Simulator, the game was ready. I could control when changing orientation was allowed or not. For example, not allowing the orientation to be changed while any Core Animation was going on. Everything looked great! I thought it was so neat that I would actually sit there and play with the orientation just so I could watch the controls move around. Life was good, and I was happy that I finally got this code done. I released that update & everything was good. But after a few days I saw a “nasty” review on the AppStore: “With the latest update the answers are all on top of each other and cannot be read unless you start trying to tilt the iPad in such a way they clear up. It doesn’t always help. Please try to correct.” Not very helpful, I know.

I repeatedly tried to make Biblicious do this, asked Pariahware followers on Facebook & Twitter, and received no responses.  I asked a few friends and nobody said they had every seen this overlapping button issue.  As every developer knows, we have no way of contacting our customers when they comment and we have no way to rebut. After a few days this person also sent me a support email from within Biblicious. I told them that I could not make it happen and asked them to send me detailed steps. — No response.

I figured that I should go ahead and try it again. Due to my scaling code, I thought I would try to make the overlapping button issue happen on the iPhone where no scaling happens. If it didn’t happen on the iPhone, then I knew I would need to concentrate on the scaling code. So, I hooked up my iPhone and ran the app from Xcode. I start a new game and began to play with the device’s orientation. Lo and behold I saw a button partially land on top of 2 other buttons as the buttons were being animated onto the screen. I was perplexed and tried it again, this time on the iPad. How could this happen? I check the device orientation for UIDeviceOrientationPortrait  and UIDeviceOrientationPortraitUpsideDown and perform portrait drawing code otherwise perform landscape drawing code.

Upon further searching, I noticed that sometimes I was checking for [[UIDevice currentDevice] orientation] and in other places, I was checking for [[UIApplication sharedApplication] statusBarOrientation]. The latter was actually “forced” upon me with the iOS 5 SDK install due to compiler warnings.  The former, obtains the device’s orientation which can return a number of results corresponding to the 3D plane, including face down.  The latter essentially returns landscape or horizontal.  So, what was happening in my code was, I was asking the device for it’s orientation in 3D space which was most likely returning UIDeviceOrientationFaceUp. Since my code didn’t know how to react, it just kept drawing in it’s last known state and place the button in the incorrect spot. I was able to get this to happen by changing the device’s orientation and then holding it at an approximate angle of 45 degrees. By changing all of my orientation checking code to [[UIApplication sharedApplication] statusBarOrientation] the problem was solved.

My conclusion: [[UIDevice currentDevice] orientation] it NOT necessarily the same as [[UIApplication sharedApplication] statusBarOrientation]

I hope this helps other people out and saves them some time when coding for their iOS devices.

Doc Merge on the Mac App Store

Some of you may have seen the message “Doc Merge” is damaged and can’t be opened. Delete “Doc Merge” and download it again from the App Store.

We are extremely sorry for the situation, have sent a new version to the Mac App Store, and alerted Apple twice in order to obtain an “expedited review”. At this point our hands are tied as we wait for Apple to release the update. In the interim, if you are having this problem, please contact us at the contact page so that you can be sent a serial number for the non-Mac App Store version. Then, once Apple releases the update to you, the Mac App Store version will update and you can switch back to that version. If you insist on having a refund, you will need to contact Apple directly. Thank you for your patience.

The Mac App Store

I am happy to announce that Doc Merge is now available for purchase on Apple’s Mac App Store.

As I expected, the Mac App Store is both an exciting new platform for reaching new customers, and somewhat frustrating at the same time.  I hope to answer some questions I’ve been receiving.

I already own your software, how can I migrate my purchase to the Mac App Store?

So far Apple has not indicated that there will be any way to migrate existing paid customers into the Mac App Store update process. For existing customers, my applications will continue to receive regular updates outside of the App Store. I hope that Apple will come up with a solution to allow us to migrate those who prefer the App Store into that workflow.

Some of you may have noticed that apps from some companies show up in the App Store app as “Installed” even though you purchased them outside of the App Store. I believe this is a quirk in the way the App Store works, and for example you will not be able to review or update these apps through the store. In a nutshell: the App Store app is confused into thinking that you bought the app through Apple, and this is causing many customers to believe that developers have found a way to “migrate” them onto the store. I don’t believe this is the case.

Is the Mac App Store version different from the version I can download from your site?

The Mac App Store and site versions are identical in core functionality and features, but there are minor differences having to do primarily with the way updates are performed. The version version from Apple can only be updated by Apple and is dependent on Apple’s approval schedule.

I have an older version of your software, can I get upgrade pricing on the Mac App Store?

At this time the Mac App Store does not allow for variable pricing based on customer qualification such as a previous purchase.

Is it possible to download a trial of your software before I commit to buying it on the Mac App Store?

The Mac App Store doesn’t have an official mechanism for downloading trial versions of software, but you can download the standard trial version of my applications from the respective product pages. If you decide to purchase the application on the Mac App Store, you will be able to download and install a separate, authorized copy from Apple through the App Store interface.

The iPad is here

I ordered my iPad the morning it was available.  Actually, 20 minutes after it was available.  I thought it would be a neat device to have, but mainly I bought it for development purposes.  One just can’t be certain an app will work unless it is being tested on a real device. As iPad day approached, I was getting more excited.  With the excitement was concern, because the UPS tracking said that my iPad was still in China until Friday. Not to worry, as promised, my iPad arrived on Saturday.  And the more I use it, the more I like it! This little device is great! It is much much faster than my iPhone 3G, and the screen is really bright!  After using the iPad for awhile, the iPhone actually feels too small.  I hope Apple has some plans for the iPhone because having using the iPad, the phone just doesn’t seem quite as cool anymore.

One thing that I am really proud about, is that I worked hard to get Biblicious ready for the iPad.  After a couple of bounce backs from Apple due to a couple of bugs, one that could only be found on the device, and not the simulator, Biblicious was approved as a universal app that runs on both the iPhone/iPod Touch and the iPad.  As an added bonus, Biblicious, was the first (and currently only) iPad-ready Bible trivia game in the App Store.  As a developer, I understand making money from selling apps, but I don’t like the idea of charging customers twice, once for each platform. I may re-address my opinion in another post, if necessary.

In case you are unaware, Biblicious is a Bible trivia app that puts the player in a game show setting, with your host Flip Ant.  Even if you aren’t interested in a Bible trivia game, you need to watch one of the demo videos and listen to the host’s voice.  It’s perfect!

Multi-database Manager for Mac, Windows, and Linux

Let’s face it, having to learn the ins & outs of a unique database interface for each type of database we come across is annoying.  If you’re using a PostgreSQL, MySQL, or SQLite database, you’re either using the archaic command line interface each with their own syntax, a web-based interface, or a specialized GUI application.  If you need to administer the MySQL database, you’ll need to either command line your way through or find an application.  But if the next day you need to administer a PostgreSQL database instead, you need a new set of commands to command line your way through, or use a separate application.  Now the  phpMyAdmin and phpPgAdmin guys have tried to solved this, but to be blunt, web interfaces stink.  In fact even if you use these two web interfaces, the GUIs are nothing alike.  It is as ridiculous as it is irritating.

So, how would you like a single desktop application that would let you, your employees, and coworkers mange, maintain, and query PostgreSQL, MySQL, SQLite, Oracle, and perhaps any other database that can be connected via ODBC?  What if it would work on your Mac machines, your Windows machines, and your Linux boxes? Well, I have already started on this and have the ability to read PostgreSQL and SQLite databases since those are the two that I use the most.  Currently databases are readable but not editable; one step at a time.

Before I go further into development, I’m looking for your thoughts: If you were to buy such an application…

- What are the most important databases that the application supports?

- Would you want to pay more to have access to all supported databases or purchase access to databases a la cart?

- Is starting with simple query & editing enough, or would scripting, filtering, and triggers be required in a first release?

- What are the most important features for a SQL editor in your mind?

The Long Road to Microsoft Office 2008

Over the long weekend we soft launched Doc Merge version 2.1 for both Macintosh & Windows. For Windows users this version is mostly a face-lift. And by a face-lift, I mean that the application is now driven via toolbar buttons. But for Macintosh users, this is a major overhaul. They have been stuck at version 1.1 since 2005!  As a predominantly Mac shop, it really hurt us that the Windows version of our product was better than the Mac version. This post will get a little geeky, so if you choose to continue reading, make sure that your propeller hat is securely fastened.

It has been a long road to get here, but we are happy to finally be able to support Microsoft Office 2008 with Doc Merge.

Most of our products are developed in REALbasic, a tool that allows us to more or less write code once and deploy on Mac, Windows, and Linux. Of course there are minor tweaks to make the application work properly for each platform, but most of the code is exactly the same.  At the heart of Doc Merge has been something called Office Automation.  Office Automation is a “VB Lite” language that allows a third-party application, such as Doc Merge, to control Microsoft Office products. Unfortunately with Office 2008, Microsoft decided to remove this ability from their suite of products for the Mac.  We could no longer “drive” Word in the way we had in the past on the Mac, and how we still do today with Word 2007 on Windows.  But this problem was actually the third hurdle.

The first hurdle was actually painful for the users of Doc Merge for Macintosh to install it.  In order for users to use Doc Merge, they had to place Doc Merge in the “Office” folder of “Microsoft Office 2004″ folder, which was located in the Applications folder of OS X.  Due to the agreement between REAL Software and Microsoft, this was how it had to be done.  Although annoying for the end user, this solution did work for quite some time until REALbasic dropped the old Macintosh executable format called PEF for the new Bundle-based model, that was the second hurdle.  With PEF, the executable was a single file with a data fork and a resource fork.  Once PEF was dropped, an application built with REALbasic could no longer drive an office application because in a Bundle-based application, the executable is actually located in a MacOS folder, within the Contents folder of the application’s .app folder.  We waited for a REALbasic-based solution.  It never came.

When Office 2008 was released we figured REAL Software would update their Office Automation components since Microsoft had removed the “VB scripting” capability.  I met up with one of the engineers at REAL World conference and asked about this.  The unofficial response I received basically said that REAL had no intention of updating that portion of REALbasic and that I should look into automating with the Apple Event model or the Applescript model.  After talking to some other developers and even obtaining some sample code, I decided that the Apple Event method was not going to work.

I never had any intention of learning Applescript.  Its ultra high-level coding style was very confusing to me.  I had even purchased and read a reference guide for converting the VB model to Applescript and it didn’t help.  Additionally, there didn’t seem to be a way at the time to create and run dynamic Applescripts from REALbasic. The latter is no longer the case, but I still find Applescript difficult to write.  With the use of the MBS plugins, Doc Merge can now generate a custom Applescript and run it.

With this Applescript solution, Doc Merge no longer has to be in that pesky “Office” folder.  Doc Merge 2.1 for Macintosh is also now able to be a Universal Binary application!  Previously on Mac and currently on Windows, the Doc Merge engine would give Word step by step instructions, so if Word returned some sort of error message, Doc Merge could try something different in order to continue.  With Applescript, we no longer have direct control over Word.  Instead, a custom script is dynamically  created, compiled, and then sent off with a “good luck”.  If the script fails, we know about it but are mostly helpless.  However, the only time we’ve seen this fail is if a Word Document is password protected and the user does not unlock the document; not a big deal.

Over all, we’re pretty happy with this new release of Doc Merge for Macintosh. The only thing that we wish could be changed is that Word apparently can not be driven via Applescript and remain hidden.  Other than that, it’s an easier install (read: nothing to do), it’s a Universal Binary, and it has a pretty, new, toolbar driven interface!

The future of REALbasic is unknown

I have been a faithful REALbasic user for many years.  It is such a wonderful development environment that I have staked my business on it for the past seven years.  Recently REAL Software let go a couple of key employees.  Additionally, while they put a good spin on it by saying “mini conferences around the country”, they have canceled their upcoming annual conference.  The affects of the former are already evident in that the beta process has suffered.  If this continues, the recent rock solid releases will suffer as well.  The minds of its users will say that REALbasic is again buggy and it was due to the lack of man power.

However, I think that the affects of the decision to cancel REAL World 2009 is going to have larger repercussions than REAL Software expects.  Closing down the conference, which is pure marketing, also crushes the perception of a viable product and company.  Conferences are not meant to make money.  They are there for the users.  Us.  The people who purchase the product and support the company that helps us make a living.  This announcement will shatter the hopeful, if it hasn’t already.  The conference is the only time I am able to sit face to face with many of my friends; I see them once a year.  We get to take a week off of working in order to learn and have fellowship.  It is a working vacation of sorts.  I have already spoken to people who think the cancellation is just another nail in the coffin.

And finally, I have been waiting for years for the 3rd party add-on market for REALbasic to come into its own.  I have two projects already developed and two more project partially developed.  We recently ran a very disappointing 70% off sale (test) for one of our projects.  The problem is that nobody is buying; REALbasic still has the hobbyists, and not the professional in its market.  Hobbyists either want everything for free or cheap due to their limited funds (or mindset).  Free doesn’t work for business unless it is to make people pay for the hell known as support.  Cheap?  Yeah, well, I have to feed my family, too.

Due to REAL Software’s layoffs, it was obvious that waiting for REALbasic to compile for the iPhone was unreasonable.  We have to move on and continue to innovate.  Pariahware is starting to develop in XCode for the iPhone.  Dusting off the C files in our brains and getting up to speed with Objective-C is part of that plan.  I don’t think 100% web apps are the future, but some mixture of desktop and internet applications is what is ahead.  And the iPhone is part of that strategy.

I sure hope that REAL Software survives and that REALbasic lives on as a quality product.  For building cross-platform applications, nothing can beat it.  However putting all of one’s fruit in one basket in never a good idea so getting more familiar with XCode seems like the way to go.