24 Oct 2012

Hidden iPhone 5 Upgrade Fees And Bad AT&T Math

3 Comments Uncategorized

This is a break from my normal postings about technology, but I just needed to rant on this a little. Because as a programmer I understand that bad math happens, but this seems deliberate on AT&T’s part.

Let me start out by explaining, I like many other Americans updated to the iPhone 5 on launch day.  I found a lot of the expected fees, such as the “One Time Charge for Upgrade” fee of $36.00, which still baffles me because I have to essentially pay for the privileged to being locked in for another 2 years, but I digress.

The fee that I didn’t expect to find, was one related to AT&T’s bad math, which seems to work out in the favor or AT&T.

If you look closely at this plan change, they changed the old “DataPro 2GB for iPhone” data plan costing $25.00 a month for the new “DataPro 2GB for iPhone on 4G LTE with VVM” data plan costing $25.00 a month.  And some how this change worked out in favor of AT&T to the tune of $3.33 for essentially what should have been an even swap.

So when I noticed this, I called AT&T and they were quick to turn around and give me a good faith credit, no fighting, no haggling, and no bartering required.  So they must know something is going on with their billing system, to part with their money so easily.  Personally I think AT&T should retroactively credit all customers this bogus fee back, instead of forcing people to call them if they actually notice the charge on their bill.  And obviously fix their billing system, because something is obviously wrong.

By the way this isn’t a rare incident.  This also happened to another account of mine that I also upgraded to an iPhone 5.

In this case the change worked out to a $6.00 fee that goes into AT&T’s pockets.

I encourage all of you to look your own bill, and make sure you weren’t hit by the AT&T bad math fee.

23 Aug 2011

Three20 And Custom NIB TableViewCells

2 Comments Uncategorized

I am pretty new to Objective-C development and iOS development in general, but in my effort to fill small gaps on the internet with useful information, I believe I have found a small area that hasn’t had much love.

If you are unfamiliar with iOS development you may have never heard of Three20.  Three20 is a framework developed by Facebook and used in the creation of Facebook’s iOS app.  It can best be described from their own site:

Three20 is a open source Objective-C library used by dozens of well-known brands in the App Store, including Facebook, Posterous, Pulse, Meetup.com, and SCVNGR. Three20 provides powerful view controllers such as the Launcher, the popular Photo Browser, and internet-aware tables.

The library is modular, meaning you choose which elements of the library to include in your app. This modular design allows Three20 to be one of the only Objective-C frameworks that encourages what are called ‘extensions’ from the community.

Overall the Three20 framework is really well documented and has proven to be more than useful. As a developer who is new to Objective-C and iOS development, I have been pleasantly surprised by how fast I have been able to create a very useful application in a very short period of time.

One thing that isn’t supported by Three20 and that there isn’t much documentation on the internet about, is using Three20 in conjunction with a view created by the Interface Builder. In my case using Three20 and a custom UITableViewCell created by Interface Builder.

Using A Custom UITableViewCell In Three20

For this blog post I am going to narrow my focus to just the code that is needed to get a custom table view cell, built in Interface Builder, to show up in a Three20 managed table view. There are tons of useful examples on the internet on how to create a custom table view cell in Interface Builder, so that part of this exercise is outside of the scope of this post.

I am also going to assume you are familiar with creating your own data sources for the table views, which is critical to what I am going to talk about next.  If you are not familiar with how table views work in iOS and Three20 please review this sample Twitter app provided by Three20.

The first thing you need to do is setup your own table view cell in Interface Builder. If you need help or want a refresher I found this site to be very useful.

The next thing we need to do is add the following code to our tables data source. This code tells the data source the class type of the cell we want to use for a specific data type. In the case of the app I am creating the object that is being bound to the cell is called TickerItem, and the cell is called TickerCell.

-(Class)tableView:(UITableView *)tableView cellClassForObject:(id)object {
    if ([object isKindOfClass:[TickerItem class]]) {
        return [TickerCell class];
    } else {
        return [super tableView:tableView cellClassForObject:object];
    }
}

The above code checks that the object in question for the cell is a TickerItem class, and if so returns the TickerCell type. For any other kind of object passed in, it is forwarded to the parent classes same method for type determination.

The second and final piece of code that we need to support showing Interface Builder built objects (that is a mouth full) is used search the mainBundle for the for the NIB named TickerCell and then bind the data object and the cell together to create our custom cell.

- (UITableViewCell*)tableView:(UITableView *)tableView 
        cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    
    UITableViewCell* cell = nil;
    id object = [self tableView:tableView objectForRowAtIndexPath:indexPath];
    
    if ([object isKindOfClass:[TickerItem class]]) {
    
        cell = [tableView dequeueReusableCellWithIdentifier:@"TickerCell"];
    
        if (cell == nil) {
            NSArray *nib = [[NSBundle mainBundle] loadNibNamed:@"TickerCell" owner:self options:nil];
            cell = [nib objectAtIndex:0];
        }
        
        if([cell isKindOfClass:[TTTableViewCell class]]) {
            [(TTTableViewCell*)cell setObject:object];
        }
        
        [self tableView:tableView cell:cell willAppearAtIndexPath:indexPath];
    } else {
        cell = [super tableView:tableView cellForRowAtIndexPath:indexPath];
    }
    
    return cell;
}

As always if the object doesn’t match the TickerItem type, same as in the previous class, we need to forward the call on to the parent class to handle the correct binding.

From this point your code should be able to display the cell that you created in Interface Builder.

Conclusion

This took me a good half day to figure out, because you have to merge some Three20 specific method calls with some custom NIB instantiation calls that usually happen automatically. But after I figured out these internals hooking the two of the frameworks together was easy and straight forward.

I hope that somebody will find some use in this code, and save them selves a half day of searching the internet for the answer.

20 Oct 2010

To Go Native Or Not To Go Native… That Is The Question

2 Comments Uncategorized

Over the past couple of weeks I  have been slowly planning and revamping my iPhone app to address user concerns, bugs, and problems.  And as part of the rework I decided to support other platforms, in addition to the iPhone, such as the iPad, Android, and Windows Phone 7.  However with this new focus, I had one huge problem, how was I going to learn each new SDK.

This problem led me to struggle with if I should develop for each platform natively in its own language and SDK or use a cross platform programming language that would basically put a shim on top of the native SDK.  The pros and cons of each approach where the following:

Go Native Not Go Native
Pros
  • Take full advantage of SDK
  • Design flexibility
  • Officially supported
  • Easier to integrate already developed toolsets
  • Program once
  • Test once
  • No extra hardware to buy
Cons
  • Many hours spent researching problems and pulling hair out
  • Have to test each platform individually
  • Buy extra hardware, (i.e. devices and in the case of the iOS a computer)
  • Less design flexibility
  • Could only support the platforms that the cross platform toolset supported
  • Not officially supported
  • Harder to integrate toolsets (i.e. Native Adsense, Facebook Auth)
  • Limited access to accelerometer, GPS, and native hardware

Eventually I came to the conclusion that I had to accept the fact that if I wanted to support all the platforms, I was going to have to use a cross platform programming language, because I am one guy with a limited amount of time and don’t really have time to learn Obj-C and Java on top of the SDK’s for iOS, Android, and Windows Phone 7.  So I started browsing around and came up with the following options for developing cross platform:

  1. MonoTouch & MonoDroid : I would be able to share the C# code across the platforms with Windows Phone 7 app if I crafted the libraries for accessing the core data, but this choice still required me to use each platforms UI, so I would have to spend the time diving in to each individual platform.
  2. JavaScript & PhoneGap : This seemed like a perfect solution, because I know JavaScript and HTML, and PhoneGap would turn them into native applications by running them in a shell browser on the device, however this severely limited me in what I could do with the UI.

I really found the fact that I could continue to program in C# with MonoTouch and MonoDroid very alluring.  But, ultimately I decided I was going to go with jQuery Mobile and PhoneGap, because I lacked the time to even dive in to MonoX frameworks, and I already had a solid grasp of HTML and jQuery so I decided to use PhoneGap as the platform for my next release. If you have never used PhoneGap here is how they explain it on their website:

PhoneGap is an open source development framework for building cross-platform mobile apps. Build apps in HTML and JavaScript and still take advantage of core features in iPhone/iPod touch, iPad, Google Android, Palm, Symbian and Blackberry SDKs. Learn More ›

Sounds great huh?  Well it sort of is, but has some rough spots when reaching outside of the browser.  But so far I have been able to successfully do the following from JavaScript from within the browser:

  • Popup Native Alerts
  • Get GPS coordinates
  • Vibrate The Device

I will be posting updates during the development process here on my blog.  And the nice thing about doing something with HTML and JavaScript, is that I can share them all with you through your browser with out ever having to deploy the app to a single device.  So that part I am completely thrilled with.