Today Apple released iOS 7.1.1 to the general public. According to this TechCrunch article most of the updates are focused on improving Touch ID performance. I’ve noticed the fingerprint recognition not performing as well recently as it has in the past, so this is a very welcome update. Other improvements bug fixes for keyboard responsiveness and Bluetooth keyboards when the VoiceOver user accessibility feature is enabled. To update to the latest version simply navigate to the Software Update option within your iOS device Settings.
The Apex Data Loader for Salesforce.com is a tool with an easy to use GUI to interact with your database – insert, update, delete, export, etc. Unfortunately the Data Loader magic is only natively supported on the Windows platform. However Mac OS X users are no longer excluded from the party, as the Data Loader has been ported to OS X under the name LexiLoader.
I’ve installed LexiLoader and given it a test drive in my developer sandbox and I’m happy to report that it works just like the native Windows version. Below I’ve included some screen shots of LexiLoader.
My four month old MacBook Pro is officially dead. She took a turn for the worse last week and I had been hoping for the best, but alas now all hope is lost and she is sitting at the Apple Store awaiting a hard drive transplant to bring her back to life.
Things started looking bad last week when it tried to perform Spotlight Indexing and it said “78 Hours Remaining…” Then they got worse after a reboot when the computer wouldn’t reboot. The worst part about it is I didn’t have anything backed up! The best part about that is that Carin got me an external hard drive for Christmas! Oh the irony!
So I booted off the Snow Leopard CD and plugged in the external hard drive. The Disk Utility failed so I couldn’t repair the hard drive, but through the Terminal I was able to save many of the files by copying them to the external drive — most importantly our pictures (however the iTunes folder is adios).
Last night I went to the Apple Store and after explaining the situation to them they took a quick look at it and confirmed my synopsis but unfortunately didn’t have the part I need on-site. So they ordered a new one which will take a few days to come in then they’ll swap it out and let me know when it’s ready — all free of charge.
Apart from having to get my iTunes music back via my iPhone or other Macs which is my fault for not having my data backed up this is more of an annoyance than anything else of just not having my MacBook Pro. Apple has been great thus far and we’ll see how they are throughout the rest of the process. Note to all: backup all of your data no matter how new your computer is!
As I was doing some development on my iPhone app yesterday night and this morning I ran into an issue that I figured I would blog about and hopefully it may be of use to some stray Googler in the future.
In a nutshell, the issue is that the iPhone Simulator caches the SQLite database in a local Mac OS X directory to improve performance, so I was getting runtime errors about tables not existing from the Xcode Console, which of course was driving me absolutely mad since the SQL file itself in the project bundle showed the database table being there!
After double and triple checking my models and controllers, and verifying that everything was hooked properly in my NIB files, I set out to do some Googling to see if I could determine what could possibly be wrong. As mentioned above, I knew the table in question was in the database, because if you opened the .sql file you could see it plain as day. But at the end of the day it seems that deleting your old database file from Xcode and adding the new one simply may not be enough, as in my case I had to actually go to the directory on my Mac where the iPhone Simulator stores all the files it uses to build the apps and delete the directory of the app I am building. Then, upon re-building, it pulled a fresh copy of my files (with my new database) and voila!
So, where is this mystical iPhone Simulator directory? It’s a bit of a hike but to get there just follow this path:
/Macintosh HD/Users/<username>/Library/Application Support/iPhone Simulator/User/Applications/
Once you’re in there you’ll see a bunch of directories with some cryptic directory names. Just browse around each one until you find the application in question and then delete the one you need to.
That should do it. Once done go back to Xcode and Build/Run and your updated SQLite database should be brought into your project. Hope this information helps someone. Any questions feel free to ask in the comments.
One of my New Year’s resolutions for 2009 was to get off my arse and write an iPhone app and get it published in the App Store. Not much progress was made in the way of attaining this goal during January and early February of this year, as the 60-70 hour work weeks have steadily continued from last year into this year. However, in mid-February I finally got the motivation to get started on this endeavor. I ordered an Objective-C book and an iPhone SDK Programming book from Amazon and eagerly awaited their arrival.
A few weeks later they arrived in the mail and I began to dive into iPhone programming. I recall big Steve saying back in the day that for anyone wanting to program on the Mac (and thereby iPhone since it runs Mac OS X) they ought to learn Objective-C, as that is the main language that Mac applications are written in. So I started off with the Objective-C book, reading the first hundred pages or so.
Most of the high-level concepts of the language are very similar to what I already know. My first real programming class (html doesn’t count) was back in the fall semester of 2002 at community college in California, an Introduction to C++ class. At the time I loved that class, I was using Red Hat 7 and writing everything in EMACS and compiling via the command line with gcc. It was great and I had serious aspirations about being a computer science major. Alas, the advanced mathematics requirements and me didn’t mesh well so that was the end of my computer science experience in college. After college I was heavily involved with a friend’s nightlife web site called Partybody and over the course of 6 months to a year taught myself PHP. Over the past few years since then I have become fairly knowledgeable in PHP and have started branching out into other languages like Python and Ruby. The reason I mention all this is because in my experiences with Objective-C so far, the fundamentals seem to be pretty similar (variables, loops, function, etc.), albeit the syntax is a bit different, which is where the real learning curve comes into play.
Despite using a completely new language, I’m utterly thrilled at the amount of progress I’ve been able to make so far in the little time I’ve had to devote to iPhone programming. Apple’s IDE Xcode is shaping up to be the best programming tool I’ve ever used — which says a lot because I absolutely love Coda. Fact is the CodeSense built into Xcode is phenomenal!
Additionally, I must say thank you to Stephan Kochan, author of Objective-C 2.0, and Dave Mark & Jeff LaMarche, authors of Beginning iPhone Development, their two books are very easy to follow and unlike most programming books I read, they’re actually teaching me something!
As I said before I read about 100 pages in the Objective-C book before switching over to the Beginning iPhone Development book, of which I am currently on Chapter 8. But already I have been using Xcode and Interface Builder extensively, and Apple’s iPhone Simulator software is truly remarkable.
After only a few hours of programming I’m starting to churn out real-world type applications that I feel I can later reuse the code base into developing my own apps to submit to the app store. I haven’t had this much fun developing in ages!
Now if only I just had some more free time to code….I can’t wait to see the results.
We are painfully reminded every day when we venture out of our homes that the iPhone does not have 3G technology. The EDGE network is brutally slow and painful and there simply is no way to sugarcoat that harsh reality. But wait! All hope is not lost my fellow iPhoners, as we do have a little feature called Wireless Fidelity, better known as WiFi (and no, I didn’t need to Wikipedia that ).
Many features on the iPhone, most notably Safari and Mail, operate such that the greater the available bandwidth the greater the experience of using the application. So it becomes important to know how much you got coming down the pipe back and forth between your iPhone and wireless router. Enter iNetwork Test.
The Web site iNetwork Test exists to perform exactly this function, to tell you how fast your WiFi network speed is currently operating. The site is a piece of cake to use, simply navigate to inetworktest.com and click the “Start Test” button. Then just wait. The quicker your connection the quicker the test will complete. Once the test completes, you select whether you’re operating via WiFi or EDGE, and the Web site records your score.
My WiFi network speeds were as follows:
1st attempt – 925 kbps
2nd attempt – 940 kbps
3rd attempt – 841 kbps
4th attempt – 894 kbps
5th attempt – 910 kbps
Once your score has been recorded you can click on the “Results” button to see how your score relates to the average EDGE and/or WiFi speeds. At the time of this writing, the average EDGE speed is 208 kbps, and the average WiFi speed is 798 kbps, putting me a bit above the average — gotta love that fiber optic pipe.
And to the wise guys out there, yes, it can detect if you’re not using an iPhone:
iNetwork Test for iPhone