HockeyTweet version 1.2 is now available in the Apple App Store. This is a minor release which fixes a change to Twitter's OAuth system used for user authentication.
You can download the upload today if you are already a user. Enjoy!
Showing posts with label Twitter. Show all posts
Showing posts with label Twitter. Show all posts
Sunday, February 7, 2010
Wednesday, February 3, 2010
Fix for Twitter-OAuth-iPhone Due to Twitter Mobile OAuth Update
Today at 6pm EST Twitter pushed a new OAuth update for the mobile web page that users use to authorize an application to send tweets on their behave. This is great since they made the user experience on mobile devices and specifically the iPhone better.
I am using Ben Gottlieb's Twitter-OAuth-iPhone library to handle the retrieving of the pin that Twitter assigns to the an app for the requesting user. Ben's library is great and makes it very easy for a dev to drop OAuth support into a Twitter enabled application, like HockeyTweet.
There was a small problem with this mobile update. The web page element that contains the oauth pin was changed from oauth_pin to oauth-pin. This broke any app using the Twitter-OAuth-iPhone library.
The fix is simple. Go into your code and so a search for oauth_pin and change that to oauth-pin. Here are the files from Ben's library that are impacted by today's change:
Make the change, recompile, and retest your app. You should be sending tweets again in no time.
HockeyTweet was updated (submitted to Apple for review) to version 1.2 tonight as part of this fix. I'll send an update when the fix is pushed to the App Store.
I am using Ben Gottlieb's Twitter-OAuth-iPhone library to handle the retrieving of the pin that Twitter assigns to the an app for the requesting user. Ben's library is great and makes it very easy for a dev to drop OAuth support into a Twitter enabled application, like HockeyTweet.
There was a small problem with this mobile update. The web page element that contains the oauth pin was changed from oauth_pin to oauth-pin. This broke any app using the Twitter-OAuth-iPhone library.
The fix is simple. Go into your code and so a search for oauth_pin and change that to oauth-pin. Here are the files from Ben's library that are impacted by today's change:
- Libraries & Headers/jQueryInject.txt
- SAOAuthTwitterEngine/SA_OAuthTwitterController.m
Make the change, recompile, and retest your app. You should be sending tweets again in no time.
HockeyTweet was updated (submitted to Apple for review) to version 1.2 tonight as part of this fix. I'll send an update when the fix is pushed to the App Store.
Sunday, January 3, 2010
HockeyTweet Breaks into the US App Store
I made my first sale in the US App Store yesterday for HockeyTweet. It's a small start and encouraging to see the app selling outside Canada.
I also updated the Lockernine website based on feedback from a user. There is now a direct link to the App Store for the apps for sale by Lockernine (Lockernine being me and apps being yes there are more in the works).
I also updated the Lockernine website based on feedback from a user. There is now a direct link to the App Store for the apps for sale by Lockernine (Lockernine being me and apps being yes there are more in the works).
Labels:
Hockey,
HockeyTweet,
iPhone,
Lockernine,
sales,
Twitter
Saturday, January 2, 2010
Steve Ballmer Scoops HockeyTweet
Steve Ballmer announced the future of Hockey viewing on CBC's The Hour with George Stroumboulopoulos. Steve knows that part of watching hockey is yelling at your TV and sharing with your friends and driving the other fans crazy. He scooped HockeyTweet on the show and talked about how you should be able to immediately tell your friend about a fantastic goal -- no matter whether your friend is next to you on the couch, at the bar or at the game.
Steve's vision of the future didn't take long to realize. HockeyTweet is now available in the Apple App Store. After you've downloaded a copy, take a minute to check out Steve Ballmer''s interview.
Steve -- just visit the iTunes store to get your copy. Better yet, send me an e-mail and I'll send you a promo code.
Steve's vision of the future didn't take long to realize. HockeyTweet is now available in the Apple App Store. After you've downloaded a copy, take a minute to check out Steve Ballmer''s interview.
Steve -- just visit the iTunes store to get your copy. Better yet, send me an e-mail and I'll send you a promo code.
Saturday, December 26, 2009
NC-17 Rated Hockey Twitter App on the iPhone
I've gotten feedback about HockeyTweet that goes along the lines:
For most developers and those that follow the App Store saga, the reason is probably clear. For those that don't know let me explain. There is what is called a UIWebView, for non-programmers, this means a web browser view/window in my app. That UIWebView has access to Twitter so users can authenticate and if required to create a new Twitter account. There is a loop-hole in that UIWebView when you are on Twitter that means you could go out onto the Internet at large and view "objectionable material."
Since I allow the user to be able to navigate through Twitter to the internet they could view something that is objectionable. This sounds ridiculous and it is but the point here is that some apps have been rejected due to this and chose the route of least friction in the app review process.
So, yes, the app is rated NC-17. Does it have objectionable material in it? No. Should it be rated lower? Yes, but why would I go the route that has lead other devs to have their apps rejected?
- An NC-17 Hockey app for the iPhone, that is my kind of hockey.
- Hey, where are the girls in this app?
- What no porn?
For most developers and those that follow the App Store saga, the reason is probably clear. For those that don't know let me explain. There is what is called a UIWebView, for non-programmers, this means a web browser view/window in my app. That UIWebView has access to Twitter so users can authenticate and if required to create a new Twitter account. There is a loop-hole in that UIWebView when you are on Twitter that means you could go out onto the Internet at large and view "objectionable material."
Since I allow the user to be able to navigate through Twitter to the internet they could view something that is objectionable. This sounds ridiculous and it is but the point here is that some apps have been rejected due to this and chose the route of least friction in the app review process.
So, yes, the app is rated NC-17. Does it have objectionable material in it? No. Should it be rated lower? Yes, but why would I go the route that has lead other devs to have their apps rejected?
Thursday, December 24, 2009
Designing HockeyTweet
It's been a long road, longer than I thought it would take but then aren't many things? How did HockeyTweet begin?
The main design goal of HockeyTweet was to create a fast Tweet creation interface for Hockey, specifically the NHL. This was born from the desire to allow people to quickly tweet their thoughts about the game without missing the action.
This desire stems from my youth, watching Hockey with my Dad. When there was a play we did not agree with we shouted out our protests. When there was an awesome save, there were shouts of joy.
So how do you bring this experience to the iPhone?
First I thought about how to speed up tweet entry. To do that let's save the user time by giving them the list of teams, players, penalties, and games. What did I need to consider for each?

Teams
During my design I identified that players and schedules had to be updated regularly. How to handle that? This was something new for me since I had to figure out how to do regular updates to my app without impacting the user experience in a negative way.
After some research I settled on web services as the solution. I first designed a web service with Perl SOAP::XML. What did I learn besides new tech (I had never programmed a web service before so this was all new)?
Google App Engine
I started researching hosting solutions that offered the ability to run my own Perl services. All the hosting services seemed more expensive than I wanted to pay. Through the searching I kept coming back to Google App Engine. The pricing model is generous and I use lots of Google services which I find sometimes limited but get the job done 90% of the time.
How does Google App Engine work when hosting from it? My summary would be, unless you write something that is very successful, it's free. Once it starts to cost money (nothing for me yet) you should be already monetizing your product. If you are not making enough money to pay the generous hosting with Google App Engine then why are you offering the product?
Google App Engine had a kink though, I had to convert the already written (though prototype) service in Python or Java. Python was just poking it's head up at my day job so I figured why not go that route. At this time I enlisted a friend who was interested in the project. He signed on to rewrite the prototype Perl SOAP::XML web service using Google's App Engine and in Python. This relieved me of some work so I could concentrate on the app.
JSON 2.2 Framework for iPhone
Around the same time, I came across JSON 2.2 Framework for iPhone. Let me just say, that this is an awesome framework. It let me remove a lot of the hairy XML parsing code from my app and replace it with a clean implementation that effectively lets me pass Python Dictionaries of arbitrary complexity from the Python web service to HockeyTweet where the JSON string is cast to a Cocoa NSDictionary. The ease of using this library can not be said enough.
If you need to write a web service to work with the iPhone, look at Google App Engine, use Python, and the JSON 2.2 Framework for iPhone.
Ok, so time passed, my partner came and went; he had other pressing projects to work on. I finally finished version 1.0 of the app near the end of November. I submitted the app about November 28, 2009. Then it was time to wait.
iPhone Tech Talk Toronto
A week later I was off to Toronto for the iPhone Tech Talk World Tour. This is a one day conference where Apple Evangelists run 1 hour sessions (courses/tech previews/tech tricks) and provide services such as UX (User Experience) reviews. It is effectively a pep rally + course + feedback + networking session with Apple's face to the development community.
It was AWESOME!
The UX Review and The Redesign
At the Tech Talk, as soon as I heard that there would be UX reviews I signed up for one. The review went well. I received valuable feedback from the Apple team which resulted in 10 new features they felt would polish the app and give it a Wow factor.
So began The Redesign. The list of features were:

Not so Fast
But first, I got feedback that the icons could use more polish. Eck! I hired a graphic designer online and he went to work on new icons. I received 5 of the 7 icons and had good ideas on the other two which I implemented in the tight deadline I gave him.

Phew! Now it was time to ship.
I uploaded again and on Monday HockeyTweet hit the App Store.
What would I do differently?
The main design goal of HockeyTweet was to create a fast Tweet creation interface for Hockey, specifically the NHL. This was born from the desire to allow people to quickly tweet their thoughts about the game without missing the action.
This desire stems from my youth, watching Hockey with my Dad. When there was a play we did not agree with we shouted out our protests. When there was an awesome save, there were shouts of joy.
So how do you bring this experience to the iPhone?
First I thought about how to speed up tweet entry. To do that let's save the user time by giving them the list of teams, players, penalties, and games. What did I need to consider for each?

Teams
- Full name or abbreviation? Abbreviation wins out by far, we are only working with 140 characters in a tweet afterall.
- Do we need to update this? Not if we limit our scope to the NHL (teams are pretty static, name changes are not common.)
- Full name or abbreviated? After some testing and consideration for length, I went with full last name and first initial.
- Numbers? Extraneous info, if you are a not a big fan you know the star's names but not necessarily their numbers. No numbers.
- Do we need to update this? Yes, team rosters change often due to injuries, trades, retirement, new players, etc. This will need to updated regularly - need to consider this in how to perform updates.
- Full name of abbreviated? For clarity and since I expect some of the long ones will not be used often I went with full name for each. Where the penalty had a common name that was shorter I used that.
- Do these change often? No, no need to build in updating for penalties.
- How to handle showing a game? Use abbreviated team name with vs.
- Games change often so this definitely needs to be updated on a regular basis.
- Do we need time of the game? No, this app is for tweeting about the game while it is happening. Also, want to consider the day before and after since people may want to tweet about an upcoming game or yesterdays game. Time can be dropped.
- Ok, we are showing yesterday, today and tomorrow. How are we showing that? I went with the 3 letter month and the date only.
- Why no year? Don't need it, we are only showing current games, not previous years.
- Numeric month would be shorter, why not use numerical month? You save 1 character for less clarity. Then you have to decide on a format MM/DD or DD/MM. I feel the 3 letter month provides more clarity, another decision done.
- Why no year? Don't need it, we are only showing current games, not previous years.
During my design I identified that players and schedules had to be updated regularly. How to handle that? This was something new for me since I had to figure out how to do regular updates to my app without impacting the user experience in a negative way.
After some research I settled on web services as the solution. I first designed a web service with Perl SOAP::XML. What did I learn besides new tech (I had never programmed a web service before so this was all new)?
- I know Perl well so writing the prototype web service took about 1.5 hours. Good references through The Perl Bookshelf and Google certainly helped.
- Integrating the web service using asynchronous URL requests with asynchronous XML parsing was a mess. There was a lot of code to handle what was a simply a problem of go get some data and populate this array for display in the UIPicker. Trust me, the first pass of this code was ugly and hairy.
- Where would I host this? My home system was out of bounds, I did not want to re-enter the world of IT and server maintenance to host my own web service. A hosted solution would work but that would cost money for an app that would likely have a limited customer base (iPhone Fans who are Hockey fans, that watch the NHL, and use Twitter). The total earnings for the app would probably not cover the cost of one year of hosting, so I needed something free.
- How will this web service scale? Not sure, probably not well without lots or testing and more research to make sure I wrote a good web service.
- How would I cache the web service data? In memory? On disk? If on disk how would I do that on the hosting service? What about Perl version? Which would the hosting service support? Could I install my own custom Perl modules? Many questions here to answer.
Google App Engine
I started researching hosting solutions that offered the ability to run my own Perl services. All the hosting services seemed more expensive than I wanted to pay. Through the searching I kept coming back to Google App Engine. The pricing model is generous and I use lots of Google services which I find sometimes limited but get the job done 90% of the time.
How does Google App Engine work when hosting from it? My summary would be, unless you write something that is very successful, it's free. Once it starts to cost money (nothing for me yet) you should be already monetizing your product. If you are not making enough money to pay the generous hosting with Google App Engine then why are you offering the product?
Google App Engine had a kink though, I had to convert the already written (though prototype) service in Python or Java. Python was just poking it's head up at my day job so I figured why not go that route. At this time I enlisted a friend who was interested in the project. He signed on to rewrite the prototype Perl SOAP::XML web service using Google's App Engine and in Python. This relieved me of some work so I could concentrate on the app.
JSON 2.2 Framework for iPhone
Around the same time, I came across JSON 2.2 Framework for iPhone. Let me just say, that this is an awesome framework. It let me remove a lot of the hairy XML parsing code from my app and replace it with a clean implementation that effectively lets me pass Python Dictionaries of arbitrary complexity from the Python web service to HockeyTweet where the JSON string is cast to a Cocoa NSDictionary. The ease of using this library can not be said enough.
If you need to write a web service to work with the iPhone, look at Google App Engine, use Python, and the JSON 2.2 Framework for iPhone.
Ok, so time passed, my partner came and went; he had other pressing projects to work on. I finally finished version 1.0 of the app near the end of November. I submitted the app about November 28, 2009. Then it was time to wait.
iPhone Tech Talk Toronto
A week later I was off to Toronto for the iPhone Tech Talk World Tour. This is a one day conference where Apple Evangelists run 1 hour sessions (courses/tech previews/tech tricks) and provide services such as UX (User Experience) reviews. It is effectively a pep rally + course + feedback + networking session with Apple's face to the development community.
It was AWESOME!
The UX Review and The Redesign
At the Tech Talk, as soon as I heard that there would be UX reviews I signed up for one. The review went well. I received valuable feedback from the Apple team which resulted in 10 new features they felt would polish the app and give it a Wow factor.
So began The Redesign. The list of features were:
- Improve the Info button (it was not very responsive)
- Change the text buttons to icons
- Add Arenas to the pre-loaded UIPickers
- Add a UIPicker for pre-loaded Hockey Phrases to give the app a more positive spin (the app had a negative spin with just the Penalties that could be combined with Players or Games)
- Make the Hockey Phrases user customizable
- Change the colour of the Add button from white to the same colour as the other buttons on the main view (the one different button made the view look unfinished)
- Indicate using colour (red) to the user when they typed a Tweet over the 140 character limit for a Tweet
- Make the fact that a Tweet was successfully sent clearer
- The buttons on the flipside view (Settings) could be retouched to make the app look finished
- (My own) Add pre-loaded Team rosters and Schedules so that if the user bought the app and ran it without an internet connection, there was data in the app from day one. The original design was to get the first load of data from the web service.

Not so Fast
But first, I got feedback that the icons could use more polish. Eck! I hired a graphic designer online and he went to work on new icons. I received 5 of the 7 icons and had good ideas on the other two which I implemented in the tight deadline I gave him.

Phew! Now it was time to ship.
I uploaded again and on Monday HockeyTweet hit the App Store.
What would I do differently?
- Hire graphic help earlier in the process. Work with them to turn my paper/sketch prototypes into the UI which I code on the back end.
- Work longer on pinning down the design and the requirements before I start. I let feature creep push the app in a direction I had to reverse early in the process.
- Solicit more early UI design feedback.
Labels:
design,
HockeyTweet,
iPhone,
Twitter,
UI,
User Interface Design,
UX
Wednesday, December 23, 2009
Adding Twitter + OAuth to an iPhone App
First you will want a way to use the Twitter API. Go get MGTwitterEngine for that (I won't talk about that here since lots of people have explained it well). Get that and install it and play with it. You should be posting tweets very quickly from your app with Basic Auth.
Ok, once you get tweets sending and can retrieve tweets with Matt's code (MGTwitterEngine) you might want to start posting your tweets with your own app name and website. To do this you will need to use OAuth. See the Twitter API FAQ about OAuth and Twitter.
The best way to get this working on the iPhone is to use Ben Gottlieb's Twitter-OAuth-iPhone. This is a awesome piece of work by Ben, piecing together several examples, frameworks, and the OAuth process to make using OAuth from the iPhone a piece of cake.
Follow Ben's readme and sample project and you will be up and running with application branded tweets in no time.
Ok, once you get tweets sending and can retrieve tweets with Matt's code (MGTwitterEngine) you might want to start posting your tweets with your own app name and website. To do this you will need to use OAuth. See the Twitter API FAQ about OAuth and Twitter.
The best way to get this working on the iPhone is to use Ben Gottlieb's Twitter-OAuth-iPhone. This is a awesome piece of work by Ben, piecing together several examples, frameworks, and the OAuth process to make using OAuth from the iPhone a piece of cake.
Follow Ben's readme and sample project and you will be up and running with application branded tweets in no time.
Tuesday, December 22, 2009
First iPhone App: HockeyTweet has Launched
HockeyTweet is my first foray into the Apple App Store. HockeyTweet is a Twitter client which makes it fast to send Twitter updates about hockey games in real-time.
HockeyTweet is purpose built for the NHL. But enough of repeating the product page in the App Store, check out HockeyTweet in the App Store.
Here are some of the questions I've gotten about developing for the iPhone and what my next plans are:
Does it cost money to develop for the iPhone?
HockeyTweet is purpose built for the NHL. But enough of repeating the product page in the App Store, check out HockeyTweet in the App Store.
Here are some of the questions I've gotten about developing for the iPhone and what my next plans are:
Does it cost money to develop for the iPhone?
- Short answer no, for the majority of people though the long answer is yes.
- No, if you 1. Own a Mac, 2. Only want to write and test apps on your Mac.
- Yes, if you 1. Don't own a Mac, 2. Want to run the app on your own device, 3. You want to post the app to the App Store.
- $99/year (before taxes) for the iPhone Developer license.
- $$$$ for your Mac
- $219 CAN (before taxes) for the 8GB iPod Touch to approximately $1200/year for an iPhone
- Well yes, what is your time worth? If you are like me and you love to try new things, love to play with different programming languages and create, then this is not a real cost. If you add that time into your costs, it starts to skyrocket, but hey we are here to have fun and design cool apps that solve problems for people.
- In a word, AWESOME. I love Xcode (the Apple provider IDE) and the toolset that it comes with. Basically everything I've used to write, debug, run, test software is available. The list of features is long but you won't be disappointed.
- NOTE: Your mileage may vary if you don't accept the tools and learn them. I love vi, the editor is not vi. I decided with Xcode to not fight the tools and try to use replacements. This is paying off as I learn more shortcuts and they start to sink in.
- I plan to market HockeyTweet using several tactics with minimum cash. I'll write about how each of these pans out as I try them.
- I will be working on the next version. The app is designed to allow me to quickly integrate other sports. I will be improving the design as I work on the second sport and seeing how I can improve the design to let me integrate other niches quickly.
- I will be adding localization to the app for French.
- I will be monitoring user input for future features and working on any issues that arise.
- UI design
- Objective-C
- The Cocoa Touch framework - the SDK you build iPhone apps in
- Web Services using Google AppEngine
- Python for the Web Services
- Dealing with performance and responsiveness in a constrained environment
- Integrating open source frameworks into code
- Managing deadlines with team members
- Learning when to stop implementing and ship it ;-)
- Are you a programmer? Do you have passion? Are you ready to learn? If so, no it is not hard. Again, back to the time issue. If you have it and are willing to do a lot of self learning then it is fairly easy.
- Yes, I am currently building Lockernine as my (planned) various apps home on the internet.
- Yes, though does my wife and friends count?
- I will post an update on sales numbers later once I have something interesting to report, be it good sales, or poor sales.
Subscribe to:
Posts (Atom)