Tunemark Radio is now available for both iPhone and iPad on iTunes. There’s still just one app to download but it is now optimized for iPhone and also the larger iPad screen.
This app is designed to be a FREE alternative for playing Internet radio stations, without the annoying ad banners. If you have any suggestions for improvements to this app, please contact Stormy Productions and pass along your thoughts. You can read a full description of the app here.
This latest version significantly improves the “Buy on iTunes” feature. When you now choose that option, you will be presented with a list of matching songs currently available on iTunes. This way, you can verify the song you want to buy is going to be available before you launch iTunes and exit the app. There’s no sense stopping the music and launching iTunes only to be disappointed to find the song isn’t for sale there.
PLEASE NOTE: this most recent version of Tunemark Radio was required by Apple to remove the feature for playing 128K and higher bitrate streams over the 3G and Edge networks. This was not something we wanted to do, but Apple would not approve this update without the bandwidth limit for cellular usage. I’m sure many of you will be disappointed by this change, but please understand it was a requirement from Apple. We will continue to investigate whether Apple may allow this feature again some time in the future, and if the policy is changed, we will update the app accordingly.
Thanks for all the comments, suggestions, and even the complaints. All the feedback is helpful to continuously improve this app.
Thursday, April 22, 2010
Tuesday, April 20, 2010
More Thoughts on iPad Development Decisions
I currently have two iPad apps available in iTunes. One, Artificial Life HD, is an iPad specific app which is a modified version of my Artificial Life iPhone app. I initially struggled with the decision of whether to release the iPad version of the app as a universal app, compatible with both iPhone and iPad, or as two separate apps. After doing some initial work in pursuing a universal app design, I decided it would be better to have an iPad-specific version.
There were mainly 3 reasons for this decision.
First, the iPhone app is currently slightly under 20 meg in size. 20 meg is an important number for iPhone apps. If an app is larger than 20 meg, Apple will not allow the app to downloaded via the cellular network. This has the potential for lost sales. Adding support for the iPad required adding higher resolution artwork and some iPad-specific code additions which made it very likely that the app would be larger than 20 meg.
Second, due to some early decisions I had made in the design of the the iPhone app, it was going to be very tedious to make the app run-time compatible with both iPad and iPhone. It was definitely possible, but a lot of time could be saved by making the iPad changes compile-time rather than run-time.
Third, while both the iPad and iPhone versions are nearly identical in functionality right now, I hope to be adding features to the iPad version which take better advantage of the larger screen area. Having the apps as two separate and distinct versions in the app store made the most sense.
My second iPad app is a universal app - Tunemark Radio. Tunemark Radio is a free streaming radio player which supports the full SHOUTcast directory as well as adding custom streams via pls, m3u or other custom URL formats. It supports both mp3 and AAC+ audio formats. It also has a few unique features such as support for custom wall-paper and a built-in fullscreen visualizer which reacts to the music. In the case of this app, a universal app made the most sense. The app binary is quite small (about 1 meg) and there will be little change in functionality between the two apps. The iPad version required a new layout, which meant new iPad specific view controllers, but the code differences were minor and were easy to handle during run-time.
In addition to becoming more familiar with the iPad vs. iPhone differences while adding iPad support for these apps, I learned a few important details during the app submission process.
1) When using a UIPopoverController, it is very important that you test that the popover continues to point to the correct section of the iPad screen as the screen is rotated to various orientations. This means testing rotating the screen while the popover is being displayed, not just testing the popover’s initial appearance in each orientation. I had the Artificial Life HD app rejected because one of my popovers did not redisplay itself with the arrow pointing to the proper button after the screen was rotated. I had never thought to test that behavior and has falsely assumed it would be handled automatically via the iPhone SDK internal logic. This is not the case.
In order to have your popover redisplayed properly when the screen is rotated, you must first save all the popover attributes to some state variables. This includes saving the sender which initiated the popover, the containing view, the popover arrow position, and a pointer to the popover itself. Here’s a snippet of code displaying a popover and saving some of the creation details:
Class classPopoverController = NSClassFromString(@"UIPopoverController");
id aPopover = [[classPopoverController alloc] initWithContentViewController:navController];
activePopover = aPopover;
activePopoverSender = sender;
activePopoverView = sidebarView;
activePopoverArrowDirection = UIPopoverArrowDirectionLeft;
[aPopover presentPopoverFromRect:[activePopoverSender frame] inView:activePopoverView permittedArrowDirections:activePopoverArrowDirection animated:YES];
I suggest saving the sender rather than the sender’s frame because when the screen orientation changes, the sender’s frame could change position and size, so you want to be able to get the current frame size and position, not the size and position when the popover was first displayed.
Then, you need to add some code in the view controller’s didRotateFromInterfaceOrientation to check for the presence of a popover, and if one is active, redisplay it. Here’s an example:
- (void)didRotateFromInterfaceOrientation:(UIInterfaceOrientation)fromInterfaceOrientation
{
if (activePopover){
[activePopover presentPopoverFromRect:[activePopoverSender frame] inView:activePopoverView permittedArrowDirections:activePopoverArrowDirection animated:NO];
}
}
Even though the popover is already being displayed, it’s OK to call presentPopoverFromRect: again. Doing this has the effect of simply redisplaying the existing popover at the proper new orientation. If you don’t do this, sometimes the popover will rotate properly, but in most cases it will not and if Apple notices this, your app will be rejected.
2) On the iPad, Apple strongly suggests supporting all orientations. If you do support all orientations, then it is critical that all views display at the proper current orientation.
This seems like an obvious point, however if you are converting an app from an iPhone-specific project and you have lots of view controllers, it’s easy to overlook adjusting a view controller so it supports all the orientations. As a result, you need to make sure you test every single view at every single orientation while testing the app. It may not be immediately obvious if some buried menu item is only displaying at one orientation. It’s an easy enough fix if you do discover something comes out wrong - just find the view controller responsible and make sure shouldAutorotateToInterfaceOrientation returns the proper value for iPad.
If you are doing this in a universal app and the iPhone version only supports one orientation, here’s an easy way to handle it:
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation {
// Return YES for supported orientations
if (UI_USER_INTERFACE_IDIOM() != UIUserInterfaceIdiomPad){
return (interfaceOrientation == UIInterfaceOrientationPortrait);
}else{
return YES;
}
}
3) If using a UIPicker (such as date picker) on iPad, it must appear within a UIPopoverController. This is mentioned in the HIG, but it's just one sentence and is easy to overlook. If you don't display a picker within a popover, Apple will reject your iPad app. I'm not sure why this is a requirement, but rules are rules, as they say.
These are some fairly simple examples, but may be easy to overlook the first time you create an iPad app from an existing iPhone project. Hopefully they can help someone else avoid time lost in resubmitting an app.
There were mainly 3 reasons for this decision.
First, the iPhone app is currently slightly under 20 meg in size. 20 meg is an important number for iPhone apps. If an app is larger than 20 meg, Apple will not allow the app to downloaded via the cellular network. This has the potential for lost sales. Adding support for the iPad required adding higher resolution artwork and some iPad-specific code additions which made it very likely that the app would be larger than 20 meg.
Second, due to some early decisions I had made in the design of the the iPhone app, it was going to be very tedious to make the app run-time compatible with both iPad and iPhone. It was definitely possible, but a lot of time could be saved by making the iPad changes compile-time rather than run-time.
Third, while both the iPad and iPhone versions are nearly identical in functionality right now, I hope to be adding features to the iPad version which take better advantage of the larger screen area. Having the apps as two separate and distinct versions in the app store made the most sense.
My second iPad app is a universal app - Tunemark Radio. Tunemark Radio is a free streaming radio player which supports the full SHOUTcast directory as well as adding custom streams via pls, m3u or other custom URL formats. It supports both mp3 and AAC+ audio formats. It also has a few unique features such as support for custom wall-paper and a built-in fullscreen visualizer which reacts to the music. In the case of this app, a universal app made the most sense. The app binary is quite small (about 1 meg) and there will be little change in functionality between the two apps. The iPad version required a new layout, which meant new iPad specific view controllers, but the code differences were minor and were easy to handle during run-time.
In addition to becoming more familiar with the iPad vs. iPhone differences while adding iPad support for these apps, I learned a few important details during the app submission process.
1) When using a UIPopoverController, it is very important that you test that the popover continues to point to the correct section of the iPad screen as the screen is rotated to various orientations. This means testing rotating the screen while the popover is being displayed, not just testing the popover’s initial appearance in each orientation. I had the Artificial Life HD app rejected because one of my popovers did not redisplay itself with the arrow pointing to the proper button after the screen was rotated. I had never thought to test that behavior and has falsely assumed it would be handled automatically via the iPhone SDK internal logic. This is not the case.
In order to have your popover redisplayed properly when the screen is rotated, you must first save all the popover attributes to some state variables. This includes saving the sender which initiated the popover, the containing view, the popover arrow position, and a pointer to the popover itself. Here’s a snippet of code displaying a popover and saving some of the creation details:
Class classPopoverController = NSClassFromString(@"UIPopoverController");
id aPopover = [[classPopoverController alloc] initWithContentViewController:navController];
activePopover = aPopover;
activePopoverSender = sender;
activePopoverView = sidebarView;
activePopoverArrowDirection = UIPopoverArrowDirectionLeft;
[aPopover presentPopoverFromRect:[activePopoverSender frame] inView:activePopoverView permittedArrowDirections:activePopoverArrowDirection animated:YES];
I suggest saving the sender rather than the sender’s frame because when the screen orientation changes, the sender’s frame could change position and size, so you want to be able to get the current frame size and position, not the size and position when the popover was first displayed.
Then, you need to add some code in the view controller’s didRotateFromInterfaceOrientation to check for the presence of a popover, and if one is active, redisplay it. Here’s an example:
- (void)didRotateFromInterfaceOrientation:(UIInterfaceOrientation)fromInterfaceOrientation
{
if (activePopover){
[activePopover presentPopoverFromRect:[activePopoverSender frame] inView:activePopoverView permittedArrowDirections:activePopoverArrowDirection animated:NO];
}
}
Even though the popover is already being displayed, it’s OK to call presentPopoverFromRect: again. Doing this has the effect of simply redisplaying the existing popover at the proper new orientation. If you don’t do this, sometimes the popover will rotate properly, but in most cases it will not and if Apple notices this, your app will be rejected.
2) On the iPad, Apple strongly suggests supporting all orientations. If you do support all orientations, then it is critical that all views display at the proper current orientation.
This seems like an obvious point, however if you are converting an app from an iPhone-specific project and you have lots of view controllers, it’s easy to overlook adjusting a view controller so it supports all the orientations. As a result, you need to make sure you test every single view at every single orientation while testing the app. It may not be immediately obvious if some buried menu item is only displaying at one orientation. It’s an easy enough fix if you do discover something comes out wrong - just find the view controller responsible and make sure shouldAutorotateToInterfaceOrientation returns the proper value for iPad.
If you are doing this in a universal app and the iPhone version only supports one orientation, here’s an easy way to handle it:
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation {
// Return YES for supported orientations
if (UI_USER_INTERFACE_IDIOM() != UIUserInterfaceIdiomPad){
return (interfaceOrientation == UIInterfaceOrientationPortrait);
}else{
return YES;
}
}
3) If using a UIPicker (such as date picker) on iPad, it must appear within a UIPopoverController. This is mentioned in the HIG, but it's just one sentence and is easy to overlook. If you don't display a picker within a popover, Apple will reject your iPad app. I'm not sure why this is a requirement, but rules are rules, as they say.
These are some fairly simple examples, but may be easy to overlook the first time you create an iPad app from an existing iPhone project. Hopefully they can help someone else avoid time lost in resubmitting an app.
Saturday, April 17, 2010
"The iPad isn't a computer"
You aren't buying a computer when you buy an iPad, you are buying a 16GB Walmart store shelf that fits on your lap - complete with all the supplier beat downs, slotting fees, and exclusive deals that go with it - and Apple got you to pay for the building.-Jim Stogdill, O'Reilly Radar
The above is just a short quote from a very thought provoking article regarding the closed ecosystem of Apple's new iPad. It's got me feeling a bit conflicted since I agree most of what he wrote, I just I hadn't thought of it from that perspective before.
As I've mentioned in another forum, I can understand the idea of having to lock down the iPhone for potential adverse affects on the cell network, but the iPad is another story.
Wednesday, April 14, 2010
Hitting the Moving Target - the inconsistent app review process
Just when I was starting to think Apple’s review process was getting better, fairer, and more consistent, I get proved wrong. Maybe Apple’s employees are getting spring fever or something and need to take out their excess energy on their clients.
As I mentioned a few days ago, I had a couple of radio station apps rejected because the reviewer thought they should be combined into one app via In-App Purchase. Never mind that these were free apps and In-App Purchase, as the name implies, requires the extra content be something that you actually purchase. The main point was these apps were for two different radio stations, and each station wanted their own app. There are literally hundreds of these apps already in the iTunes store. Radio stations want to have their own app - they can advertise it on air (“Hey, download our iPhone app”) and they can have their own icon on the iPhone.
So, the good news for me is the two rejected apps were finally approved, but in typical fashion, Apple made no comment or explanation or ever answered my query as to what the issue was. One app just mysteriously changed state from rejected to approved without me even resubmitting it. Apple simply sent an automated message saying, “Thank you for the additional information. We will continue with the review process and will inform you of any update.” and later “Thank you for contacting the iPhone Developer Program. Our records indicate [your app] has been flagged 'Ready for Sale', and should be available via iTunes shortly.” No explanation of whether a mistake had been made originally, or whether there’s something I could have done to avoid the misunderstanding in the first place.
It reminds me of when we used to have Internet problems at a company I used to work for and we would call our service provider (the local telco at the time) and they’d say “There’s no known problem or work being done with the network.” Meanwhile, we’d look out the window and see the local telco company’s truck parked outside and a guy working on the wires. And, of course, the Internet service would mysteriously start working again after the truck drove away.
But that’s not my point. That’s just me ranting.
My point is the app review process still needs improvement. It has improved as far as timeliness goes, but it still has serious problems. Developers need some sort of consistency and transparency in the process. Receiving boiler-plate email is not helpful, especially when there is a problem that affects your business. In my case, I had several clients projects on hold. I wasn’t even sure if I could continue my existing business model of developing apps on behalf of radio stations. Actually, I still don’t know if I can for certain. I never received a definitive answer from Apple* . The last thing I want is to be doing work for a client, only to find out at the end that I can’t fulfill what was promised due to something out of my control (Apple’s review process).
Here’s another example of the app review inconsistency. Today, Tunemark Radio, an app which allows playing thousands of radio stations in the SHOUTcast directory, was rejected for the reason that “it is transferring excessive volumes of data over the cellular network.” Apple went on to explain that all apps:
The problem is, the above two lines of text are all Apple will officially say about cellular usage. Apple will not provide any exact numbers. It’s not like we’re trying to define how many angels can dance on the head of a pin. The app reviewers must be looking at a specific cut-off number. Why can’t we be told what that number is?
Last year, I had sent a formal (paid) tech support query to Apple asking for clarification on this policy. The engineer who replied stated that there was no official bandwidth usage number to stay under, but instead said I should look at the amount of bandwidth used by the Pandora app and stay around that amount. While the Apple engineer said it wasn’t an official number, he said to stay around 4.5 meg over a 5 minute time period was a safe number. That works out to around 112K/sec. And that was the advice I had followed for about a year.
Then, about 6 months ago I noticed there were many competing radio apps in the iTunes store that were using streams at the 128K/sec rate and I was receiving complaints with my apps because they did not allow 128K streams to be played over cellular. I sent another email to Apple asking if their bandwidth polices had changed and the response was no, the bandwidth limits were the same. But, I could clearly see that based on what was being approved, 128K streams were being allowed. I thought maybe 128K was considered close enough to 112K to be allowed So, I modified my apps to allow 128K, and sure enough, they were approved.
Now, this brings us to today’s rejection. Is it that 128K is no longer permitted over cellular, or was it never allowed but the reviewers hadn’t been paying attention for the past 6 months? I know one thing is certain. Based on past experience, I’m not going to get any helpful answer from Apple. In fact, I’m 100% certain of it. Here’s my query to Apple:
And here is Apple’s official reply received a few minutes ago:
That's all. Now I’m not a man who easily curses, but this response is testing my self control. Are Apple’s replies generated by robots?? Maybe they’re using the old Eliza program to answer support queries. It certainly doesn't look like an English speaking human read my question.
Regardless, one thing I've learned is there's no arguing with the Apple brick wall. You state your case, hope to get a reasonable answer, but regardless of what answer is received, you move on. Repeated queries gets you nowhere. I’m going to have to resubmit my app, disabling the 128K access (which has been available in this app for the past 6 months) and as a result have lots of unhappy users. I’m tempted to have a dialog box pop up saying the 128K is not permitted due to Apple’s policy, but last time I mentioned something like this in my app description, Apple called me on the phone and requested I remove the text before the app would be approved. Seriously. Apple would not approve a feature of my app, but I was not allowed to mention in the description that the feature was removed per Apple’s request. Instead, I get to just deal with negative reviews from unhappy users without being able to offer an explanation.
And that’s my point. The review process seems to be a moving target, changing at the whim of Apple. This being just one example, too many of Apple’s policies are intentionally vaguely worded. It makes life for us developers more challenging than it should be. Yes, when I joined the iPhone developer program I signed an agreement giving Apple the right to reject an app for any arbitrary reason, but it still doesn’t mean I have to be happy about it. And, as much as I may complain about the process, I still find the Apple development environment the best to work with given the alternatives. I’m not jumping ship just yet. It’s just unfortunate that things could be so much better.
* UPDATE: Coincidentally, about an hour after posting this, I received a phone call from Apple regarding the two radio station app rejection and subsequent acceptance. The person I spoke with on the phone wanted to clarify that Apple doesn't have a specific policy regarding single radio station apps. It is just that they would prefer that apps be combined if at all possible (such as two stations from the same company serving the same city).
As I mentioned a few days ago, I had a couple of radio station apps rejected because the reviewer thought they should be combined into one app via In-App Purchase. Never mind that these were free apps and In-App Purchase, as the name implies, requires the extra content be something that you actually purchase. The main point was these apps were for two different radio stations, and each station wanted their own app. There are literally hundreds of these apps already in the iTunes store. Radio stations want to have their own app - they can advertise it on air (“Hey, download our iPhone app”) and they can have their own icon on the iPhone.
So, the good news for me is the two rejected apps were finally approved, but in typical fashion, Apple made no comment or explanation or ever answered my query as to what the issue was. One app just mysteriously changed state from rejected to approved without me even resubmitting it. Apple simply sent an automated message saying, “Thank you for the additional information. We will continue with the review process and will inform you of any update.” and later “Thank you for contacting the iPhone Developer Program. Our records indicate [your app] has been flagged 'Ready for Sale', and should be available via iTunes shortly.” No explanation of whether a mistake had been made originally, or whether there’s something I could have done to avoid the misunderstanding in the first place.
It reminds me of when we used to have Internet problems at a company I used to work for and we would call our service provider (the local telco at the time) and they’d say “There’s no known problem or work being done with the network.” Meanwhile, we’d look out the window and see the local telco company’s truck parked outside and a guy working on the wires. And, of course, the Internet service would mysteriously start working again after the truck drove away.
But that’s not my point. That’s just me ranting.
My point is the app review process still needs improvement. It has improved as far as timeliness goes, but it still has serious problems. Developers need some sort of consistency and transparency in the process. Receiving boiler-plate email is not helpful, especially when there is a problem that affects your business. In my case, I had several clients projects on hold. I wasn’t even sure if I could continue my existing business model of developing apps on behalf of radio stations. Actually, I still don’t know if I can for certain. I never received a definitive answer from Apple
Here’s another example of the app review inconsistency. Today, Tunemark Radio, an app which allows playing thousands of radio stations in the SHOUTcast directory, was rejected for the reason that “it is transferring excessive volumes of data over the cellular network.” Apple went on to explain that all apps:
- Must comply with Apple's best practices and other guidelines on how Applications should access and use the cellular network;
- Must not in Apple's reasonable judgment excessively use or unduly burden network capacity or bandwidth;
The problem is, the above two lines of text are all Apple will officially say about cellular usage. Apple will not provide any exact numbers. It’s not like we’re trying to define how many angels can dance on the head of a pin. The app reviewers must be looking at a specific cut-off number. Why can’t we be told what that number is?
Last year, I had sent a formal (paid) tech support query to Apple asking for clarification on this policy. The engineer who replied stated that there was no official bandwidth usage number to stay under, but instead said I should look at the amount of bandwidth used by the Pandora app and stay around that amount. While the Apple engineer said it wasn’t an official number, he said to stay around 4.5 meg over a 5 minute time period was a safe number. That works out to around 112K/sec. And that was the advice I had followed for about a year.
Then, about 6 months ago I noticed there were many competing radio apps in the iTunes store that were using streams at the 128K/sec rate and I was receiving complaints with my apps because they did not allow 128K streams to be played over cellular. I sent another email to Apple asking if their bandwidth polices had changed and the response was no, the bandwidth limits were the same. But, I could clearly see that based on what was being approved, 128K streams were being allowed. I thought maybe 128K was considered close enough to 112K to be allowed So, I modified my apps to allow 128K, and sure enough, they were approved.
Now, this brings us to today’s rejection. Is it that 128K is no longer permitted over cellular, or was it never allowed but the reviewers hadn’t been paying attention for the past 6 months? I know one thing is certain. Based on past experience, I’m not going to get any helpful answer from Apple. In fact, I’m 100% certain of it. Here’s my query to Apple:
What is the threshold at which you determine an app is "transferring excessive volumes of data over the cellular network"? What number should the app stay under? Nothing has changed in the app in regards to cellular bandwidth-usage from this version from the previous approved 1.6 version.
Without know what number the app should stay within, it is hard for me to know what needs to be changed.
Thank you for any clarification you can provide.
Best regards,
Brian
And here is Apple’s official reply received a few minutes ago:
In order for your application to be reconsidered for the App Store, please resolve this issue and upload your new binary to iTunes Connect.
That's all. Now I’m not a man who easily curses, but this response is testing my self control. Are Apple’s replies generated by robots?? Maybe they’re using the old Eliza program to answer support queries. It certainly doesn't look like an English speaking human read my question.
Regardless, one thing I've learned is there's no arguing with the Apple brick wall. You state your case, hope to get a reasonable answer, but regardless of what answer is received, you move on. Repeated queries gets you nowhere. I’m going to have to resubmit my app, disabling the 128K access (which has been available in this app for the past 6 months) and as a result have lots of unhappy users. I’m tempted to have a dialog box pop up saying the 128K is not permitted due to Apple’s policy, but last time I mentioned something like this in my app description, Apple called me on the phone and requested I remove the text before the app would be approved. Seriously. Apple would not approve a feature of my app, but I was not allowed to mention in the description that the feature was removed per Apple’s request. Instead, I get to just deal with negative reviews from unhappy users without being able to offer an explanation.
And that’s my point. The review process seems to be a moving target, changing at the whim of Apple. This being just one example, too many of Apple’s policies are intentionally vaguely worded. It makes life for us developers more challenging than it should be. Yes, when I joined the iPhone developer program I signed an agreement giving Apple the right to reject an app for any arbitrary reason, but it still doesn’t mean I have to be happy about it. And, as much as I may complain about the process, I still find the Apple development environment the best to work with given the alternatives. I’m not jumping ship just yet. It’s just unfortunate that things could be so much better.
Saturday, April 10, 2010
Linking to an iTunes search via an app
In many of the radio station apps I've developed, the station wants a way for the listener to choose to buy on iTunes the current playing song. Since most stations don't provide the iTunes ID of the song as part of the "Now Playing" information, the best option I've been able to come up with is to have the app launch iTunes using a searching string.
For example, suppose the station was playing the song by the Talking Heads, called "And She Was". A station might simply provide this as "Talking Heads - And She Was" without any indication of who the artist is and what the song title is (other than what may, or may not be correctly inferred from the dash). Performing an iTunes search, this doesn't really matter.
You can use a URL like the following to do a blanket search on iTunes:
http://phobos.apple.com/WebObjects/MZSearch.woa/wa/search?submit=edit&media=all&term=talking%20heads%20and%20she%20was
Simply launch this URL from within your app and iTunes will automatically launch and perform the requested search.
This will work on both iPhone and iPad. Please note: if you omit the "media=all" term, the search will return on error on the iPad.
You aren't limited to searching for music. You could also do a search for movies, or apps, etc.
For example, suppose the station was playing the song by the Talking Heads, called "And She Was". A station might simply provide this as "Talking Heads - And She Was" without any indication of who the artist is and what the song title is (other than what may, or may not be correctly inferred from the dash). Performing an iTunes search, this doesn't really matter.
You can use a URL like the following to do a blanket search on iTunes:
http://phobos.apple.com/WebObjects/MZSearch.woa/wa/search?submit=edit&media=all&term=talking%20heads%20and%20she%20was
Simply launch this URL from within your app and iTunes will automatically launch and perform the requested search.
This will work on both iPhone and iPad. Please note: if you omit the "media=all" term, the search will return on error on the iPad.
You aren't limited to searching for music. You could also do a search for movies, or apps, etc.
Thursday, April 8, 2010
My oddest iPhone rejection yet
I develop iPhone apps mainly on a contract basis with a large focus on radio stations. Most radio stations don't have in-house programmers who are skilled with developing apps, so I am often contracted to develop an app for a station. Since they often lack any in-house programmers they often also ask me to host the app using my iPhone developer account. I've been doing this for about a year and a half and have about 50 radio apps under my developer account.
Today I received the oddest rejection from Apple for a pair of iPhone apps I had submitted for two different radio stations. Apple rejected the apps with the explanation that they were of a similar "Family of radio applications" and "should be packaged in a single application using In App Purchase".
There are a couple obvious problems with this. First, these apps were created for two different radio stations and each station wanted their own app. From a radio station's point of view, it's good advertising for them to have their own app which they can offer their listeners. They don't want to have their station just within some larger list of stations in a single app. It's all about branding.
The second problem with this is the radio stations want their apps to be available for free. Using in-app purchase would not make sense.
I replied to Apple explaining how combining the two apps is not an option, but I haven't yet heard back. I'm hopeful this isn't the start of a new policy on Apple's part prohibiting apps for individual radio stations.
UPDATE 4/13/2010: The two apps have now been approved, although I never received any clarification from Apple regarding my inquiry. The apps just suddenly became approved. Best I can assume is the original reviewer had made a mistake.
Today I received the oddest rejection from Apple for a pair of iPhone apps I had submitted for two different radio stations. Apple rejected the apps with the explanation that they were of a similar "Family of radio applications" and "should be packaged in a single application using In App Purchase".
There are a couple obvious problems with this. First, these apps were created for two different radio stations and each station wanted their own app. From a radio station's point of view, it's good advertising for them to have their own app which they can offer their listeners. They don't want to have their station just within some larger list of stations in a single app. It's all about branding.
The second problem with this is the radio stations want their apps to be available for free. Using in-app purchase would not make sense.
I replied to Apple explaining how combining the two apps is not an option, but I haven't yet heard back. I'm hopeful this isn't the start of a new policy on Apple's part prohibiting apps for individual radio stations.
UPDATE 4/13/2010: The two apps have now been approved, although I never received any clarification from Apple regarding my inquiry. The apps just suddenly became approved. Best I can assume is the original reviewer had made a mistake.
Sunday, April 4, 2010
The Good and the Bad: iPad from a Developer's Point of View
Like lots of other Apple-faithful, I had pre-ordered and iPad and received it on iPad launch day yesterday - April 3rd. Since I develop software for the iPhone and iPad, it was a definite requirement to have an iPad in-house for testing as soon as possible.
While I did have a native iPad app (Artificial Life - HD) ready for sale on launch day, it was a bit of a leap-of-faith endeavor. The Artificial Life app makes use of a lot of texture maps via OpenGL and the performance on the provided iPad simulator from Apple was less than ideal. In all my initial development and testing using the simulator, the frame rate was pretty poor - around 9 frame-per-second. Since it was not possible to test on a real device before the iPad launch day, the simulator was the only available baseline. I knew based on iPhone testing that for certain optimized OpenGL operations (such as using PVRTC textures) the simulator was significantly slower than the iPhone hardware, but for a lot of other simpler operations the simulator was faster than the iPhone.
Apple had required that in order for an iPad app to be guaranteed available in iTunes on launch day, the app had to be submitted to Apple for initial review approximately a week before the launch date. Not wanting to miss the opportunity to be in the store on launch day, I optimized things best I could and sent the app to Apple for review. Thankfully, Apple approved the app with no comments regarding poor performance, but still I was a bit apprehensive. I did however have a fail-safe option. Since I knew I’d be getting my own iPad on launch day, worst case, if the performance was really bad, I could just remove the app from the store. Thankfully, that turned out to be unnecessary.
The Good
The iPad turns out to be one speedy hand-held device. My own app, which ran at a poor 9 frames-per-second in the simulator was running at a smooth 35 frames-per-second on the actual iPad. Because of this, I’ll now be able to make some significant enhancements to future updates of this app - the main one being able to increase the population cap from 300 individual protozoa to over 1000, without much a noticeable change in frame rate.
Others have done some benchmark comparisons of the iPAd processing speed vs. the iPhone 3GS and the results are impressive. For CPU operations the iPad is on average about twice as fast as the iPhone. Based on what I am seeing with OpenGL performance, I suspect the graphics chip may be more than twice as fast than the one in the iPhone 3GS.
While the iPad shares much of the same SDK functionality as the iPhone, the larger screen on the iPad makes possible a lot more functionality than the iPhone. Those who say the iPad is just a larger iPhone are missing the point. The iPad isn’t just a larger iPhone. A more accurate comparison might be to say the iPad is a smaller laptop. The things you can do on an iPad are a lot closer to laptop activities than iPhone activities, and once you start developing applications for the iPad this quickly becomes apparent. While a lot of existing iPhone apps will initially be blown-up iPhone apps, in the long term there will be a much richer experience available with the iPad versions of apps in comparison to iPhone apps.
XCode project conversions
Since many developers will have existing iPhone apps, Apple has made it fairly easy to do an initial port over to the iPad from an iPhone project. There’s a built in menu item which gives the option to convert a project either to a Universal app (which supports both iPhone and iPad) or modify the project to it now contains two separate targets - one for iPhone and one for iPhone. Both options have there plusses and minuses.
A Universal app means just one listing in the iTunes store - someone can buy your app and not have to pay attention to what device it runs on. The drawback is more on the developer side. You have to do run-time checking for which device you are running on and present the appropriate UI. Also, you app will have to contain all nib files and artwork for both versions in one bundle, leading to larger binary sizes.
The double-target approach has the benefit of more easily being able to segment your code. You can use macros to conditionally compile code based on the target. This is the approach I used for Artificial Life.
In either approach, when the XCode project conversion first runs, it automatically creates iPad versions of all your nibs, although their sizes have not automatically been updated - you still have to do that by hand, properly adjusting where all the subviews and controls should be. Also, since Apple highly recommends supporting every view orientation, you’ll want to make sure you have the proper resizing and positioning options so your controls are placed properly as the views rotation. I found this was one of the most time consuming parts of my application porting to the iPad.
Pop-overs are your Friend
One very handy new UI element for porting and iPhone app to iPad is the UIPopoverController. As the name implies, it’s a window that appears over a portion of the screen. From a developer’s perspective, think of it as a modal View Controller that isn’t full screen. What is nice about these is they can take a UIViewController as an argument when they are initialized. This makes converting existing helper view controllers very simple. If you previously had a UIViewController on the iPhone which was used for configuring something, you can easily re-use it as a pop-over without having to change any of the underlying UIViewController code. Just make the pop-over the same size as the original iPhone UIViewController and you instantly have your existing view controller now working as a pop-over.
Using this approach is very helpful if you want to make a fairly rapid port of an existing iPhone app. For example, using this technique I was able to have a fully working iPad version of my existing Artificial Life iPhone app in just one day. For iPad, Apple discourages the use of full-screen transitions which were common on the iPhone (such as animated page slides), so using pop-overs for such content is an easy solution. Granted, long term I’ll be making a lot more enhancements to the iPad version of the app to take better advantage of the larger screen real estate, but short term, this was a quick way to get something up and running with a fairly good presentation.
The Bad - the iPad App Store
One thing with which I was very disappointed on launch day was the iPad App Store. For an indie software developer without a large advertising budget, the new design for the app store is absolutely terrible. As of this date, Apple no longer provides a way to browse the full categories of the app store. Sure, they list all the store categories (music, games, education, etc.), but going to view any one category now gives a limited “New and Noteworthy” view sometimes accompanied by a “What’s Hot” category. Completely lacking is a way to browse all the apps in the category. If you aren’t lucky enough to have your app featured by Apple, the only way a customer will find it is via keyword searching.
I’m hoping this is just an opening weekend glitch, but nevertheless this was a huge disappointment, especially after Apple had encouraged developers to have their apps ready for launch day. Shopping the iTunes store via iPad right now feels sorta like walking into a Wal-Mart and only being allowed to walk into the first 20 feet of the store. Anything else you might want to buy, you have to ask someone to get from the back room for you.
While I did have a native iPad app (Artificial Life - HD) ready for sale on launch day, it was a bit of a leap-of-faith endeavor. The Artificial Life app makes use of a lot of texture maps via OpenGL and the performance on the provided iPad simulator from Apple was less than ideal. In all my initial development and testing using the simulator, the frame rate was pretty poor - around 9 frame-per-second. Since it was not possible to test on a real device before the iPad launch day, the simulator was the only available baseline. I knew based on iPhone testing that for certain optimized OpenGL operations (such as using PVRTC textures) the simulator was significantly slower than the iPhone hardware, but for a lot of other simpler operations the simulator was faster than the iPhone.
Apple had required that in order for an iPad app to be guaranteed available in iTunes on launch day, the app had to be submitted to Apple for initial review approximately a week before the launch date. Not wanting to miss the opportunity to be in the store on launch day, I optimized things best I could and sent the app to Apple for review. Thankfully, Apple approved the app with no comments regarding poor performance, but still I was a bit apprehensive. I did however have a fail-safe option. Since I knew I’d be getting my own iPad on launch day, worst case, if the performance was really bad, I could just remove the app from the store. Thankfully, that turned out to be unnecessary.
The Good
The iPad turns out to be one speedy hand-held device. My own app, which ran at a poor 9 frames-per-second in the simulator was running at a smooth 35 frames-per-second on the actual iPad. Because of this, I’ll now be able to make some significant enhancements to future updates of this app - the main one being able to increase the population cap from 300 individual protozoa to over 1000, without much a noticeable change in frame rate.
Others have done some benchmark comparisons of the iPAd processing speed vs. the iPhone 3GS and the results are impressive. For CPU operations the iPad is on average about twice as fast as the iPhone. Based on what I am seeing with OpenGL performance, I suspect the graphics chip may be more than twice as fast than the one in the iPhone 3GS.
While the iPad shares much of the same SDK functionality as the iPhone, the larger screen on the iPad makes possible a lot more functionality than the iPhone. Those who say the iPad is just a larger iPhone are missing the point. The iPad isn’t just a larger iPhone. A more accurate comparison might be to say the iPad is a smaller laptop. The things you can do on an iPad are a lot closer to laptop activities than iPhone activities, and once you start developing applications for the iPad this quickly becomes apparent. While a lot of existing iPhone apps will initially be blown-up iPhone apps, in the long term there will be a much richer experience available with the iPad versions of apps in comparison to iPhone apps.
XCode project conversions
Since many developers will have existing iPhone apps, Apple has made it fairly easy to do an initial port over to the iPad from an iPhone project. There’s a built in menu item which gives the option to convert a project either to a Universal app (which supports both iPhone and iPad) or modify the project to it now contains two separate targets - one for iPhone and one for iPhone. Both options have there plusses and minuses.
A Universal app means just one listing in the iTunes store - someone can buy your app and not have to pay attention to what device it runs on. The drawback is more on the developer side. You have to do run-time checking for which device you are running on and present the appropriate UI. Also, you app will have to contain all nib files and artwork for both versions in one bundle, leading to larger binary sizes.
The double-target approach has the benefit of more easily being able to segment your code. You can use macros to conditionally compile code based on the target. This is the approach I used for Artificial Life.
In either approach, when the XCode project conversion first runs, it automatically creates iPad versions of all your nibs, although their sizes have not automatically been updated - you still have to do that by hand, properly adjusting where all the subviews and controls should be. Also, since Apple highly recommends supporting every view orientation, you’ll want to make sure you have the proper resizing and positioning options so your controls are placed properly as the views rotation. I found this was one of the most time consuming parts of my application porting to the iPad.
Pop-overs are your Friend
One very handy new UI element for porting and iPhone app to iPad is the UIPopoverController. As the name implies, it’s a window that appears over a portion of the screen. From a developer’s perspective, think of it as a modal View Controller that isn’t full screen. What is nice about these is they can take a UIViewController as an argument when they are initialized. This makes converting existing helper view controllers very simple. If you previously had a UIViewController on the iPhone which was used for configuring something, you can easily re-use it as a pop-over without having to change any of the underlying UIViewController code. Just make the pop-over the same size as the original iPhone UIViewController and you instantly have your existing view controller now working as a pop-over.
Using this approach is very helpful if you want to make a fairly rapid port of an existing iPhone app. For example, using this technique I was able to have a fully working iPad version of my existing Artificial Life iPhone app in just one day. For iPad, Apple discourages the use of full-screen transitions which were common on the iPhone (such as animated page slides), so using pop-overs for such content is an easy solution. Granted, long term I’ll be making a lot more enhancements to the iPad version of the app to take better advantage of the larger screen real estate, but short term, this was a quick way to get something up and running with a fairly good presentation.
The Bad - the iPad App Store
One thing with which I was very disappointed on launch day was the iPad App Store. For an indie software developer without a large advertising budget, the new design for the app store is absolutely terrible. As of this date, Apple no longer provides a way to browse the full categories of the app store. Sure, they list all the store categories (music, games, education, etc.), but going to view any one category now gives a limited “New and Noteworthy” view sometimes accompanied by a “What’s Hot” category. Completely lacking is a way to browse all the apps in the category. If you aren’t lucky enough to have your app featured by Apple, the only way a customer will find it is via keyword searching.
I’m hoping this is just an opening weekend glitch, but nevertheless this was a huge disappointment, especially after Apple had encouraged developers to have their apps ready for launch day. Shopping the iTunes store via iPad right now feels sorta like walking into a Wal-Mart and only being allowed to walk into the first 20 feet of the store. Anything else you might want to buy, you have to ask someone to get from the back room for you.
Friday, April 2, 2010
5 new iPhone radio app released
Stormy Productions has recently produced 5 new radio station apps for broadcaster Local Media of America in San Diego, CA. Apps were created for 5 of their stations: 91X, 105.7 The Walrus, Z90.3, Magic 92.5, and XX 1090. All apps are available for free on iTunes now.
Subscribe to:
Posts (Atom)
Posts
