Quick Start

Details of how this works

I had a few Apple gift cards laying around and now using apple's Touch ID more often, I wanted to place these into Passbook for safe keeping and easier access. So how do we go about adding Apple gift cards to Passbook?

First, the simplest way to add a gift card to passbook is tapping the "Add to Passbook" button when receiving a gift card over email.  It looks something like this.

However, what if you already have a physical gift card and want to add this one to Passbook?  It turns out it's not too easy or straight forward.  Some people recommend downloading the Gyft iPhone app which allows you to import many gift cards from many merchants, however I'm a little skeptical of adding them to an app from a 3rd party other than Apple.  This app, and others similar to it, require you to enter all the confidential information from the gift card into the app and transmit it over the internet to their servers.  Although I'm pretty sure these are legit applications, I still had concerns over the security of my information.  Are the connections from the app to their cloud servers secure?  How secure are the servers themselves, etc.

So I then started to investigate the URL apple generates for "Add to Passbook" button.  Part of the URL includes the card number, but the remainder of the URL seems to be some unrecognizable encoded string.  Not relenting, after some research over the web, I discovered Apple has a specific URL they use to add Apple store gift cards to Passbook.  Since this URL is hosted by apple over a secure SSL connection, I feel quite comfortable using it to add my gift cards to passbook.  The url is:

https://storepass.apple.com/pc/v1/card/9999999999999/AAAAAAAAAAAA

where 9999... represents the card number and AAAA... represents the PIN of the card.

When I enter this URL into Safari on the iPhone, Safari reports it as an invalid card even for a valid one. The Passbook app however expects to scan a QR code to add cards, so I then searched online for a free QR code generator and came across this open source javascript project on github¹ which generates a QR code on the clients browser with JavaScript.  After reviewing the code to make sure there was no transfer of information, I used it to generate a QR code for the URL above replacing the 9999... and AAAA... with the numbers on the back of one of the Apple gift cards.  Once the QR code was generated, I then used the Passbook app to scan this code successfully adding my gift cards to passbook as shown.

I added all of my remaining cards with out issue.

I'm now embedding the generator for anyone to use as the wish here. This is pure javascript running on your browser and no information is delivered from your browser elsewhere.  Intact, the QR code changes in real time as you enter digits or letters. Simply enter your gift card number, pin number and then scan the generated QR code with passbook to add it to your passbook.

1.  http://davidshimjs.github.io/qrcodejs/

Over the fall quarter of 2012, we created the Bank Failures app for iOS.  I thank a colleague of mine for the detailed graphics and CSV parsing library we ended up using extensively for this and other apps. The idea is very simple -- banks have been failing at a very fast pace since 2008 and there is no easy way to access this information in an organized way to search or simply filter this data by year or by state.

Since we were applying techniques in iOS development, we decided to leverage this need while at the same time applying advanced UI techniques in iOS such as UITableView among others. A recently blog covers some interesting details with UITableView's.

The following are some screenshots of the app as submitted to the Apple App Store.  In a future blog update, I will decompose the entire application from the nightly process which pulls bank data from us government web sites to the filtering, tab views, etc.

xCode allows for multiple convenient ways for configuring the UITableView cells.  Using one of default custom configurations, specifying it in storyboard as a prototype, specifying it in a nib file which is then reused, and simply creating it in code directly.  While developing an app which makes use of the UITableView, I came across an interesting dilemma where I wanted the flexibility of using xCode's UI to configure it however I wanted to avoid certain issues each approach carries as described below.

One approach is to define each UITableViewCell as a prototype of each UITableView directly in storyboard as shown below,

however if there are going to be multiple UITableViews displaying cells in a similar fashion, the inclination is to configure them repeatedly in each UITableView.  This is very repetitious and may even lead to inconsistencies if one is not careful and generally is considered bad programming practice similar to copying a pasting an entire method just to make one small modification within.  One can improve upon this approach by inheriting a common base UITableView class where the configuration is specified in code, however this defeats the flexibility of using xCode's UI to custom configure the UITableViewCell's various sub views.

Another approach is defining the UITableViewCell in a separate nib / xib file, you can then register the nib and reference the UITableViewCell for reuse accordingly from any UITableView controller.  This method retains the configurability of the UITableViewCell via the xCode interface as shown below.

When reusing the UITableView cell in this fashion however, most online examples indicate to register the nib file for reuse and then dequeue as usual to populate the data for each individual cell.  The problem here is, the UITableView's rowHight property is not updated automatically as it is when one specifies the UITableViewCell as a prototype and at run time, you may see something like this:

Many online blogs emphasize the height should be specified as part of the cell construction while executing with the cellForRowAtIndexPath method within the UITableViewController.  The problem I have with this solution is quite frankly, even though perhaps only 10 or actual cells will be constructed and then reused, this code is repeated unnecessarily for those 10 or so times.

The easier route is simply to specify a fixed height in the nib file, say 60 and then specifying the same 60 points in the UITableView's rowHeight property as shown in both images below.

 This will produce the balanced height we are seeking as shown below:

While this has improvements on reuse as we will have consistently looking UITableViewCell's throughout our various controllers and retains the ability to configured and edited via the xCode UI, it still has the ill effect of having to maintaing the rowHeight in two or more different places whenever the height changes and is not yet to my satisfaction of cleanliness.

Further research online reveal many blogs emphasizing the implementation of the heightForRowAtIndexPath method for the UITableViewController. This method is great when there are UITableViewCells with dynamically varying content which need varying height for each cell, however this is not the case here. The problem with this approach continues to be the repeated calls for a UITableViewCell which doesn't vary in height.  Furthermore, in the various examples I found not only is the height specified repeatedly, but registration of nib is repeated as well and some additional lines of code which could also be avoided.

The Solution:

Since in this particular example, the UITableViewCell height will remain the same across all sections and rows and UITableViews, it makes sense to programmatically tell the UITableView it's rowHeight much like we would via the xCode UI, however do so once and be done with it.  The value should also be extracted programmatically from the UITableViewCell residing in the nib / xib file so if the height is ever changed in the future via the design tools, the UITableView is automatically adjusted accordingly without any further intervention in the code.

To accomplish this, the logical place to put such code would be in the UiTableViewController's viewDidLoad method as this code is executed once regardless of the number of rows to rendered.  In this method, we simply load the nib by name, register this nib with the UITableView, and then simply set the rowHeight of the UITableView to match the height of the first view in the nib which we already know is simply a UITableViewCell.

    UINib* nib = [UINibnibWithNibName:@"ADTableViewCell"bundle:nil];

    [self.tableViewregisterNib:nib forCellReuseIdentifier: [ADCustomCellIdentifier]];

    self.tableView.rowHeight = ((UITableViewCell*)[[nib instantiateWithOwner:selfoptions:nil] objectAtIndex:0]).bounds.size.height;

In the example code above, we additionally reference a predefined class method for the cell identifier we conveniently placed in the strongly typed class representing the UITableViewCell with [ADCustomCell Identifier].

With the next iPhone just around the corner, I've decided to consolidate all the rumors i have read in the past 6 months into a concise list of the ones which are most certainly coming to the iPhone.

Rumors:

The new iPhone will have a 4" screen by increasing the height and making it a true wide screen 16:9 display

All iPhones up to and including the 4S have had the similar aspect ratio of the original iPhone released back in 2007.  The new iPhone for 2012 will have a slightly longer profile with a total resolution of 640x1136.  While this may seem to make the phone significantly longer and awkward, it was accomplished efficiently and with only increasing it's physical length every so slightly.  If you look at your current iPhone, the large areas where the home button and speaker reside are reduced by about 40%.  It not too obvious in the side by side comparison below as this was just a mockup using an existing iPhone 4S modified.  With this optimal use of space, along with a slight increase in height, Apple is able to add a 4" screen while retaining the similar look & feel of the already great iPhone 4S.

The new iPhone will have a unibody case.

Unlike the previous two iPhones, where a revolutionary stainless steel frame acts as the main support for the phone while doubling as an antenna for the various services, the new iPhone will sport a unibody case.  While the rumors don't solidly say this case is made of Liquidmetal, I will go on record and almost bet the farm on it being based on Liquidmetal.  The reasons are outlined in a separate blog to be posted soon.  Liquidmetal uses a very unique manufacturing method which allows for building very precise pieces out of molds much like plastics.  This method, while challenging to work with metals, can produce more intricate pieces than traditional CNC machining of metals or aluminum.

 

The new iPhone will sporta faster processor

Some competing smart phones are already using quad-core cpu's and the iPad3 introduced in early 2012 uses Apple's A5X CPU which is a dual-core cpu with quad-core graphics subsystem.  This CPU is necessary to push the extra pixels the iPad3 requires (4x as much as the previous iPads).  If this CPU is used for the next iPhone, it would be sufficiently powerful for all of the iPhone's needs as it's resolution is significantly lower and consequently making the next iPhone that much more faster on graphics when compared to the iPad3.  It's possible Apple may introduce the quad-core A6 processor, but this might simply be an overkill making battery suffer -- a high priority in a mobile device with aconstrained battery such as the iPhone and other smart phones.

 

The new iPhone will sport a thinner profile

The new iPhone, with the screen flush, will be 7.6mm thin.  If you want to compare how thin this is when looking at the current iPhone, imagine an iPhone4 or 4S with both of the glass pieces on the back and front removed.  This is approximately how thing the next iPhone will be and it's significant.  How can they do this without shorting battery life?  Two ways, one is of course ever improving battery technology and secondly by using an in-cell panel for the screen.  This simply means the screen and touch technology are built together reducing the space needed to fit both technologies separately as with previous generation iPhones.  Apple's new supplier, Sharp, also confirmed shipments of this new screen a few days ago.

 

The new iPhone will utilize next generation cellphone technology called LTE (Long Term Evolution)

The first generation iPhone utilized EDGE, which was limited to about 128Kbs speeds and was good for emails and basic data, however wasn't good for general web surfing.  The original iPhone ushered in the mobile data era and not too much later, the next generation iPhone (iPhone 3G) ushered in the next generation mobile data - 3G.  As cellphone companies, particularly AT&T, struggled to keep up with data demands it was clear higher speeds where necessary.  In the US, HSPA (High Speed Packet Access) became the GSM standard for 3G on AT&T's network and later, with the iPhone 4S, introduced yet an upgraded version termed HSPA+ which provides very high speeds under ideal conditions.  The HSPA+ standard however was still not efficient and yet a newer, data oriented, transmission technology was necessary -- LTE.  With LTE (Long Term Evolution), we are littering entering the broadband era for mobile devices.  The speed at which your mobile devices operate is largely indistinguishable from your home broadband speeds with low latency and large throughput.  Early LTE chipsets, similar to initial 3G chipsets, where power hungry and significantly drained the battery when compared to the previous generation 3G and EDGE respectively.  With iPhone5, the LTE chipsets have improved significantly, even within the last 6 months, making LTE more suitable.  Verizon has the largest deployment of LTE, while AT&T has the largest deployment of HSPA+ with LTE available in about 25% of the population Verizon covers.  AT&T however claims more consistent speeds when switching in and out of LTE while Verizon will allegedly switch to their slower 3G technology.  Incidentally, for those which may require voice and data use simultaneously, Verizon's 3G has a small imitation where data cannot be used while on a phone call unlike AT&T's.  The choice of carrier for the new iPhone has become that much more difficult to decide.  Regardless if you choose Verizon or AT&T, you'll have access to the latest LTE speeds where available.

New Smaller Dock Connector

The next iPhone will certainly have a smaller dock connector.  Lots of miniaturization has occurred in the last ten years and retaining same 30pin dock connector now certainly start to impact the space utilization in modern devices.  As a result, Apple has little choice but to update the dock connector to not only support modern protocols such as USB3 or Thunderbolt, but also from a footprint perspective making it smaller.  The actual pin out is unknown with certainty, but you can expect it to be smaller and fit universally in either orientation unlike the existing dock connector which fits only in one orientation.

 

Relocated Microphone Jack

When you hold your phone in your hand, you hold it upright.  When you place it in your pocket, you usually place it top down while holding it in the same orientation.  If you have the audio headphones plugged on the top, as with previous generations, this would require you to reorient your phone in your hand prior to placing it in your pocket so the headphones remain in the upward position.  With the next iPhone, the headphone jack is relocated to the bottom and this particular scenario & inconvenience is alleviated.

Next Major Version of iOS, iOS6

• As traditional with all previous releases of iPhone, the next iPhone will certainly be released with iOS6.  There are many interesting features of iOS6.

1. New Maps application utilizing SVG graphics for better realtime scalling
2. Turn by Turn Directions
3. New Alarm features such as wake up to iTunes song
4. New Bluetooth features such as specific group synching rather than all contacts
5. Deeper Twitter integration as well as Facebook as an OS feature API available to all applications
6. New metallic-like refresh in many areas such as phone & iPod apps, etc.

This is the latest update to the original cross multiplication application released a few weeks ago -- original posting here. 

Version 1.1 of the app allowed me to practice with threading as well as state.  The app has an interactive timer which is not intrusive by starting/stopping automatically.  Your best error-free scores are saved so you can challenge yourself to beat it over and over.

Update 5/9/2012:

-------------------------------------------------

Yusnier Viera, a former co-worker and current world record holder in calendar mental calculation, brought to my attention the concept of cross multiplying.  After learning the basics and practicing over time, I have been able to successfully multiply upto four digit by four digit computations in my head.  Since the exercise is stimulating and to a certain extent entertaining, I decided to build an iPhone application to easily practice.

Unlike paper and pencil, using an iPhone app allows for immediate feedback while entering the answer.  I've been learning how to develop iOS apps for both iPhone & iPad and I am on the verge of releasing this application.  Since I'm anxious to get it out to the world, I have defer creating the tutorial, the statistics page as well as game center integration, until future updates.

I decided to give the app a representative iconic person, so Einstein fit the bill.

Once loaded, you are presented with the home screen where you can link out to a video tutorial or simply start the app.

Once started, you can interactively create up to 4x4 multiplications to test your mental calculating abilities.  In a future update, I'll hook it up to game center and keep track of best times for each type as well as increase the scale up to 8x8.

I believe I have a solid work around for the the wifi issue where disconnects occur. First it appears only to happen when connecting to wireless-n connections. Wireless-g doesn't seem to have any problems.  Note this is only for the repeated disconnects and has nothing to do with the low signal issue some have mentioned. For the record, I have a 32gb Verizon iPad.

The symptoms are as follows.  

Symptoms:

• You connect fine and surf fine. Put the iPad to sleep or come back to it later after sleeping automatically and your wifi is not connected.
• When tapping the previously connected wifi to reconnect you are usually asked to enter the password again.
• When you connect the first time, it says failed to connect but re-tap the join button it connects.
• If you turn off wifi and then turn it back on  it doesn't reconnect.
• Once connected to the wifi, if you click on the right arrow to go to the details you will NOT see the "forget this wifi" button even though you are connected.

 

If you fall in any of those scenarios, this WILL solve your problem in the interim until Apple updates software. In short it seems as though the wifi is not stored or remembered.

Solution:

Configure wifi manually, explicitly typing your wifi's broadcast name, explicitly choose the security your wifi is using (wep, wpa, wpa2, etc. ) and then proceed to enter your password. Once connected if you go to the details of the connection you should see the "forget this wifi" button. If you do, you can now rest assured it will allways reconnect and  the above symptoms can no longer be reproduced.

4/12/2012 Addendum:

Not sure if this is related or not, however I have the "Ask to Join Networks" feature off in the wifi settings too. 

4/13/2012 Addendum:

Here I show how easily I can reproduce the automatic disconnects because the iPad doesn't remember the wifi connection.  My solution, and working now for weeks without a problem, has been to set it up manually.  Interestingly, after setting it up manually, I haven't had to set other networks manually as they connect and remember fine.  It's only the first one it seems or my home one.

5/2/2012 Addendum:

Updating the router firmware has resolved this issue in two separate situations (my home and a friends home).

Good luck!

Battery Life Resolved

I was extremely delighted with my iPhone4 battery life.  With my work exchange mail and gmail set to push and normal use, I could go about two days sometimes without needing to charge.  I would go to bed with say 60% charge and wakeup with 58% remaining.

When I installed iOS5, this all came to a crashing halt.  Initially I though it was the new iCloud stuff doing an initial sync or backup, but after a few days the drain continued.  I tried the multitude of things from rebooting, to turning off location services, removing some unnecessary items from the notification center, pretty much everything in the book.  While this alleviated the situation partially, it was nowhere near what it was pre-iOS5.

I read through most of the postings on the Apple forum regarding this issue ( https://discussions.apple.com/thread/3387864 ).  One posting in particular mentioned a process taking up 50% cpu.  I'm not sure how he measured this process, but it dawn on me to cold boot the phone rather than warm boot.  Unlike a computer, warm booting (sliding the red slider after holding the sleep wake button a few seconds) the iPhone saves the state of the apps and presumably the running processes and returns them back to the original state after the phone starts up.  If you don't believe, try warm booting and then go into to running tasks (double clicking home bottom) and you'll see all your previously launched apps still there.

To make a long story short, while I did turn off some features (I'll list them below in case it helps some folks) I feel the cold boot is truly what returned the iPhone back to its pre-iOS5 battery consumption.  Cold booting is simply holding the home button down while simultaneously holding the sleep/wake button for a few additional seconds after the red slider to shut off appears until it turns off on its own and then pressing the sleep/wake button to turn it back on.

Today it charged to 90% while driving to the office and by lunch time it was 87% -- now that's definitely pre-iOS5 battery life!  During lunch, I used it for a while dropping it to 83%.  By the time I arrived home in the afternoon it was 80% (I didn't use it much for the remainder of the day).  Once home I did a 20 minute jog with RunKeeper gps-tracking me all the time while listening to streaming podcasts via stitcher.  Looking at my phone now after a few hours after the jog, its at 69%.  So I can claim with certainty, the pre-iOS5 battery life has returned.

So, first thing you should try is cold booting the phone.  Just in case it's another culprit, I'll list a few of the other changes I made.

I'm going to reactivate some of the features below one by one over the next few days, even though I do not believe they are the root cause but here they are anyways:

• turned off location services for the weather
• (since it's on the notification center, it's probably always checking location)
• turned off all iCloud features except the features I like the most:  contact sync, find my iPhone, photo stream, documents & data, & iCloud backup
• (i thought bookmarks where probably the culprit after realizing the bookmarks are constantly in sync and it coincidentally has a history folder I presumed was syncing constantly as I surfed on my work and home iMacs).