Tapku

In Album Shuffle, you can move and flick albums across the screen. After a user ends a touch event by taking their finger off the screen, the album will still move across the screen as if it were a real physical environment. This article will focus on figuring out how to move the object in a semi-realistic way after the touch event ends. To figure out the velocity of just how fast the object is moving, we’ll need to brush up on some old geometry, which the article will cover. You can take a look at the code used to calculate the motion.

Recording touch information

When a user touches the screen, the view that receives that touch event through the touchesMoved function. The key to figuring out the velocity of the touch is based on how often this function is called. The touchesMoved function isn’t called after the touch moved every pixel, instead the function is called based more or less on time. (Note: if a user touches the screen and doesn’t move their finger, the function won’t be called either because the touch event didn’t move, hence the name touchesMoved. ) If a user touched across a large area of the screen very quickly, then the touchesMoved function might be called two or three times. If that same touch movement was done slowly, then the touchesMoved function might be called 20 or 30 times. The key is that each time an event is sent, the new coordinates are sent. So by remembering the last two touch events sent through the touchesMoved function, based on the gap between these two coordinates, a velocity can be determined.

Geometry Time

So after a touch event occurs, the touchesEnded function is called on the view. At this point, its time to use the last two touch points given to figure out the velocity. Here is where the good old geometry math will help, the distance between these two points is

Distance Between Two Points Formula

The higher this number, the faster and further you need to animate the object across the screen (You’ll need to divide this number by some constant so the object animates proportionate to the motion). The direction can be figured out based on these two points as well. When animating, the time of an animation can be held constant because an object that needs to travel further will travel faster to a spot because it needs to travel a farther distance in a shorter time.

The iPhone App Store has received flak from developers for promoting “ringtone applications“, forcing app prices to 99 cents, the lowest common denominator before the application is actually free. This downward price trend can be attributed to the top application charts which many believe don’t fairly measure the best applications. This article will discuss why the App Store’s current structure forces applications to become “Ringtone Apps” and why the pay first business model doesn’t pay.

Visibility is King

For a minute, take all the external factors that might lead a person to purchase an application off the table. Features on the App Store homepage, appearing in commercials or any other form of external advertising or publicity don’t exist. Essentially what your left with is that future sales directly correlate to an applications position on the download charts. (In reality, this isn’t too much different from how the app store is now. The charts dictate, for the most part, which applications are sold and which aren’t. ) Developers are competing with other developers for visibility on these charts because visibility leads to sales. If the app store is all about visibility, then developers play the game of getting the most people to hit the “Buy App” button. You’re left with the fact that not only does the price of an app affect the consumers choice to purchase the application, the consumer has an affect on the future consumer because their choice affects visibility. The App Store market place is unlike any other market place because simply purchasing an item hasn’t ever had such a large effect on future sales. In most market places like desktop applications, the media, advertising and reviews serve as the chief credible filter, and sales have less of a direct impact on future potential buyers.

Pay Up Front vs. Free

After reading Chris Anderson’s “Free” book, its clear that the App Store is a lot like the web. Applications which are closer to free gain more traction, and any business model must be intertwined into free services or free content. Another side of me wants to say the App Store, because Apple locks it down so much, is a return to pay-for model though. You pay an application like you pay for something in a grocery store. In reality, the only real way to get attention is by choosing a lower price because their isn’t a lot of ways to get sales through traditional means. A desktop application might rely on a magazine like Macworld to review the application, but the massive amounts of apps leave review sites struggling to review even a a decent amount of applications that are approved. Instead these review site just re-hash iTunes descriptions. Like application approvals, the media have trouble handling the massive amount of applications.

At this point I wish I could offer some solution to this problem. I think that basing the charts solely off application downloads, and not at least factoring ratings and price into the equations leads to pressure to lower prices. Then again, quality of music, movies and TV shows on the iTunes Store isn’t factored into those charts either and everything seems fine. Those pieces of content are, for the most part, locked into only a few certain price points that the industry as a whole can at least agree on. Applications, by nature, are more varied in price but maybe developers might benefit from a more uniform price like music. All I have to say is… time will tell where the App Store economics go…

Article moved to: http://devinsheaven.com/faster-animation-on-an-iphone-quartz-vs-core-animation/

After months of frustration built up from the approval wait, I’m happy to announce the approval of Album Shuffle. The application is a free, little interactive application that allows you to experience your music albums in the iPhone’s multi-touch environment. Go ahead and download it. Enjoy!
I wrote previously on the doubts that surmounted from the extended approval time. So much so, that I doubted that Album Shuffle would ever be approved into the App Store. I still stand by my intuition that any application that takes advantage of the Music API in iPhone OS 3 will be ushered into an extend approval time queue though. All that aside, I’ve written a few articles discussing the various issues that Album Shuffle presented when developing an application that deals with multi-touch and layer transparencies with the iPhone. Stay tuned for those articles!

CONTENTS OF ARTICLE ARE OUTDATED.

You won’t find that cool calendar view class you see in the Calendar app in the iPhone 3.0 SDK, but you will find it in the open source Tapku Library. The tapku library calendar view looks (almost) exactly like the one you see in the Calendar app and it acts the same way with the ability to add an indicator for each day that has some piece of information associated with it. The rest of article will step you through using the TKCalendarView and TKCalendarViewController.

The easiest way to use the calendar view is to use the TKCalendarViewController and implement the following Calendar View delegate methods.

- (NSArray*) calendarView:(TKCalendarView*)calendar itemsForDaysInMonth:(NSDate*)monthDate;

- (void) calendarView:(TKCalendarView*)calendar dateWasSelected:(NSInteger)integer ofMonth:(NSDate*)monthDate;

- (void) calendarView:(TKCalendarView*)calendar willShowMonth:(NSDate*)monthDate;

The first delegate method, the one that expects back an NSArray, is the function that sets up the marks for each day in the month. The monthDate variable is the time-stamp for the first day in that particular month requested, like for instance August 1st 2009 0:00:00.0. The array returned should be filled with 31,30 or 28 (however many days are in that particular month) NSNumber objects with boolean values. In terms of programming, this function is a good time to query a database, and store the objects in memory so you can easily display information when a day is selected.

The dateWasSelected method is fired by the Calendar view every time the user selects a new day or they switch months. The monthDate variable again is the time-stamp day for the first of the month and the integer variable is the actual day of that month. You may wonder why this isn’t another date variable. This is just to keep the memory and processor use down as well as make it easier to code on the controller side.

The willShowMonth method will fire when months are swapped in and out. This method is useful when you want to adjust objects in the view because of the resizing of the calendar. Recall, the Calendar app has a UITableView stuck to the bottom of the Calendar view. When the calendar switches months and calls that delegate method, you can resize something like a table view to the new frame height of the calendar view.

To use the Calendar View, download the Tapku Library from github and make sure to check out view and view controller classes as well as the demo app to see the class in action.

After confirming with colleagues also trying to get their applications that utilize the Music API, included in the iPhone OS 3, it appears applications that utilize this API will be ushered aside in an app approval waiting cell. Speaking from experience, I currently have an application up in holding which is not only a bummer for me, but also everyone who might want to download it (for free). Some developers have received notices from Apple that the review time will take longer, but any and all details including a time table for approval thereafter are not stated in their emails. Any attempts to contact them through email are met with canned useless answers.

My suggestion to developers is to stay away from this cool and enticing API until we have some answers to why Apple doesn’t want to approve them. If you don’t heed my advice, beware , your efforts may get trapped in this app approval cell and not get out.

Article has moved here: http://devinsheaven.com/cocoa-touch-tutorial-receiving-using-the-shake-api-for-iphone-os-3/.

Back in May, I was pondering an iPhone app that was outside the box. Something no one else had done. A mixer application for the iPhone. Soon after, I created a mockup of the application which is the main reason why I’m writing this article. So I can share this mockup. I wanted the interface to be simple with just a pitch and volume control for each track.  I was skeptical all along that an application with such abilities as mixing music could exist on the iPhone and output the audio that way I would have hoped. Here are some reasons why the application couldn’t be:

Why it wouldn’t work

If you know anything about DJing, you’d want to create two channels of audio. One channel to go to the DJ’s headphones and another to go to the speakers. Well, the iPhone in theory is perfect for this because the 30-pin dock connector could relay one signal, and the headphone jack could relay another. In reality, only one signal can come out of the device.

The second red flag was the iPhone’s ability to play certain file formats. MP3, AAC and Apple Loseless can’t be played simultanouesly.  The audio formats that can be played back togther are formats like Linear PCM or AMR. Don’t worry, I’ve never heard of these file formats either. The documentation fails doesn’t mention anything about WAV or AIFF in this section. I figured if you couldn’t play your iTunes library, there would be little point to application.

Since I’ve research this topic, Apple has unveiled the iPhone 3GS which is a big speed increase compared to the 3G. The documentation from what I can tell doesn’t state any changes now that the faster iPhone is out. Oh well, there is always the Tablet Mac…. (don’t steal my UI). Those sliders took forever to make!