iOS developer, php developer, runner I write, edit, and code stuff. I also raise children and sometimes clean things
http://www.corywiles.com
One of the greatest new features that is included in iOS4 is the power that developers have to deliver local notifications. At the time that the first beta was released in April I was writing specs/requirements and project timeline for a potential app which would have ended up taking me about 5 months to develop. A large part of the project schedule dealt with having to setup/maintain user reminder preferences...the number of reminders, frequency of each one, time zones, etc. I tried to think of ever solution that I could that didn't involve the server component, but there really wasn't any other way.
UILocationNotification to the rescue. After looking over the API docs, Apple had provided exactly what I needed and I was able to cut out 2.5 months from the project schedule because of it.
I was able to create an POC app using UILocationNotifications in literally 5 minutes. It involved two easy steps:
There are two possible end results. The first being that the event is fired off while the app is running in which case you will not see anything. Hence, why I added the NSLog to the didReceiveLocationNotification method. The second is if you close the app before the notification has fired and in that case you will receive the alert box with your message.
Note: This was compiled with iOS4 GM and tested on iPhone 3G/3GS
One of the biggest gripes that I have with working with the FBConnect iPhone SDK, and really the Facebook API, in general was having to deal with a very inefficient REST implementation. Callback after callback, protocol after protocol, major bugs (that have yet to be fixed as far as I know), and my biggest issue is the nasty user experience having to login a user. I was very excited to hear when last month Facebook announced they had came out with a new API that would allow great security, ease and flexibility. The pains of having to go through currently working functionality and refactor the code to accommodate the new features wasn't too much of a problem for me because it would mean a reduced code set on my part and I would be able to get rid of the Facebook Connect SDK. I set out to test my theories and functionality via a quick web app. No problems. Then I proceeded over to my native iPhone app. EraseUrX v2.0. The new authentication mechanism utilized in Open Graph is OAuth2.0. While many of the headaches and complexities of using OAuth are addressed and the documentation for using it in a mobile web app are well documented with Facebook they TOTALLY dropped the ball on providing any direction on using it with a native iPhone app and they don't provide an updated SDK.
I am currently working on a photo gallery/slideshow app and one of the requirements is for the main gallery listing page to have static header and footer that shows the app name, contact information and adverts. The logical first method of attack is to just setup a UITableViewController subclass, slap some views and subviews to the table view header and footer and get on with the day. However, the table itself should scroll, but the "header" and "footer" views should remain stationary. My first approach, I found out quickly, did not work. Surprisingly, there are a lot of people having issues with custom sized uitableviews in general and the discussions that I saw online didn't provide a very straight forward solution so I decided to create one.
The first big problem that most people run into is that they can't seem to resize the uitableview no matter what frame size they set. It doesn't matter if you do it programmatically or through Interface Builder it still takes up the ENTIRE screen. That is because they have subclassed UITableViewController. To be honest I am not sure that happens "under the covers", but the custom frame sizes/locations are ignored. You must make your controller a subclass of UIViewController and then add your UITableView as a subview to the your controllers view.
For example:
At this point your frame size and height will be respected.
In my example I setup a simple UINavigationController project with two controllers. The first has a header view, footer view and uitableview. The second "detail" controller just has a UILabel with placeholder text. Everything is built programmatically so that you can adjust frames and positions easily as well as any other customizations you would like. Comments/suggestions are always appreciated.
As my experience, and hopefully skill, in iPhone development has matured over the past year and half I am in the constant search for the best techniques for my apps to run better, faster, and consequently more efficient. Of the top developers that I follow they all make references to the importance of utilizing subclasses of UIViews and the underlying subsets of views in general.
I love the UI elements that are used on the phone. I didn't realize the awesome power of CoreAnimation and the flexibility that it gives you to manipulate and create graphics as such a granular level. I set out to see if I could recreate a common iPhone UI element completely programmatically: a glossy gradient button that still responds to touch events.
The end result was a success and a great learning experience. I still need to add in more testing to make sure that interacting with all these views is more efficient than interacting with standard pngs.
This biggest issue that I ran into was "re-enable" the button actions.
Simply subclassing UIButton did create a problem when dealing with the UIControlEventTouchUpInside/UIControlEventTouchUpOutside methods that you associate with buttons.
I was able to overcome this issue by implementing the touchesBegan and touchesEnded methods. Remember...UIButton inherits from UIControl, which in-turn inherits from UIView.
Problem solved.
