One way to resolve ADFS error “The web server has been unable to contact the Federation server”
If you’re running ADFS and, after doing some maintenance such as taking an app server off and then re-joining the domain, find that you’re getting the “The web server has been unable to contact the Federation server” do an “iisreset” from the command prompt. It seems that the app server will not make new calls to the Federation server defined in web.config until you do an “iisreset”, so even though you may have resolved the root issue of the failure (undoubtedly a DNS or other networking issue), the app server will report a false error until you “iisreset.”
More Dev-friendly Tools for iPhone Emerge Pointing to Apple’s Achilles’ Heel
This morning came news, via InfoWorld writer Paul Krill, that Novell is releasing MonoTouch, a development toolkit which will enable developers to program an iPhone app in .NET and cross-compile to a native iPhone SDK-based binary. Opinions as to whether this is good or bad are already emerging. Setting technology biases aside, I think, on the whole, this is a good development and indicative of the weakness which has plagued Apple since its inception — Apple doesn’t know how to embrace and empower developers — they should adopt as their mission statement towards developers the tagline of Apple co-found Steve Wozniak’s blog: “Everyone is welcome.”
This failure to truly embrace developers is playing out with the iPhone as well. Let’s recap:
- When the iPhone was first announced in 2007, the word from Apple was that if you want to develop for the iPhone, web based apps are the way to go — no SDK nor Flash support will exist.
- In 2008 Apple announced the iPhone SDK and App Store — woo hoo! BTW, to code for the iPhone you needed to learn an arcane language (Objective-C) and remember long-lost memory management skills you learned way back in high school/college. Unless you’re a real-time/embedded systems programmer memory management is a menial task that the OS vendor should handle for you — there’s no time to deal with this non-sense when you’re a line-of-business app developer.
Naturally, tools started to emerge to make iPhone development more approachable. Tools like Appcelerator’s Titanium Mobile (which is very popular and received a lot of recognition), and now MonoTouch, represent hope for those who don’t have the time to explore learning a new language but who have to just get an app done using their existing skillset — these are the modern day 3GL/4GL frameworks for iPhone development and shine a spotlight on the fact that the experience for iPhone users and iPhone developers couldn’t be further apart. Apple has a long way to go to make developers feel welcome and, moreover, productive.
Titanium Mobile Web Service Sample App
If you’re an aspiring iPhone Developer, have a web development skill set, but don’t want to learn Objective-C in order to develop a native iPhone app, then Appcelerator’s Titanium Mobile is for you. In a nutshell, using HTML and JavaScript you can develop full-fledged iPhone SDK-based native apps (which compile down to native code, not just HTML/JS hosted in a Web View Controller like PhoneGap).
Using TitaniumMobile, I’ve created a small sample app which demonstrates taking user input, passing that data to a web service, then displaying the results to the user, with a little bit of error trapping too. You can check it out on the Titanium Mobile SampleApplications page — it’s called “Web Service Call Tutorial.” Enjoy.
P.S. — An added benefit of Titanium Mobile is that it support cross-deployment currently to iPhone and to Google Android.
Long-standing Mouse Acceleration Problem Seems Fixed in Snow Leopard
Those who have used Mac OS X with a third-party mouse know all too well the terrible mouse performance — the most fitting description I’ve heard describing the issue comes from the author of PlasticBugs.com: “…OS X’s mouse tracking feel like you’re mousing through mud.”
Well, after installing Mac OS X 10.6 Snow Leopard last week I encountered a pleasant surprise — the mouse acceleration problem seems to be gone. The only way that could have happened is if Apple finally fixed it. Has anyone else noticed this?
Recovery Utility for Deleted iPhone Text Messages
I’ve been getting barraged with so many requests to help folks retrieve deleted text messages from their iPhone backups that I decided to write a small utility to help out — fumbling around with a text editor was a little daunting for some.
Those using Windows can download my iPhone SMS Retriever here.
[Update 09/23/2009] – there have been many reports of installation problems. Thank you to those folks who have reported the issue — I’m working on an update to the utility within the next week to fix this problem. Thanks for your patience and understanding. I’ll keep you updated here.
Here’s how to use it:
- Download and unzip the file
- First, run the SQLite Setup.exe file — this is a pre-requisite for iPhone SMS Retriever to work.
- Second, run the iPhone SMS Retriever Setup.exe file
- The app will install and run. It will appear under your Programs as iPhone SMS Retriever
- You do need to know how to get the iPhone SMS backup file so you can point the app to load it. If you need help locating this file here’s some help — please read carefully as this step is where most folks get hung up:
- First, connect up your iPhone, run iTunes (if it doesn’t autostart), and start a sync. iTunes should say “Backing up iPhone…” or something to that effect. Let the backup process finish.
- If you’re running Windows XP: go to the c:\Documents and Settings\[your username]\Application Data\Apple Computer\MobileSync\Backup\ directory. There will be at least one directory with a very long and cryptic name — this is the backup directory that contains all the backup files from your iPhone. If you see more than one of these directories that’s fine — it just means you have several backups, each from a different time and/or iPhone on your computer. Go into the backup directory of your choice and locate the file 3d0d7e5fb2ce288813306e4d4636395e047a3d28.mddata.Copy that file to your Desktop or some other easily remembered location.
- If you’re running Windows Vista or Windows 7: go to the c:\Users\[your username]\AppData\Apple Computer\MobileSync\Backup\ There will be at least one directory with a very long and cryptic name — this is the backup directory that contains all the backup files from your iPhone. If you see more than one of these directories that’s fine — it just means you have several backups, each from a different time and/or iPhone on your computer. Go into the backup directory of your choice and locate the file 3d0d7e5fb2ce288813306e4d4636395e047a3d28.mddata. Copy that file to your Desktop or some other easily remembered location.
- If you cannot find the Application Data or AppData directory make sure you go into the Tools menu in your Windows Explorer window, select Folder Options and be sure the enable Show hidden files, folders, and drives.
- Click the “Load iPhone SMS Backup File” button in the iPhone SMS Retriever app and select the file 3d0d7e5fb2ce288813306e4d4636395e047a3d28.mddata you saved a few steps above.
- Voila! The messages in the file will appear in the window for you to browse.
This is a v1.0 app, I wrote it in about an hour, there are no bells and whistles, but you should find that it serves the basic function of loading an unencrypted iPhone SMS backup file and displaying all messages sent from/received by the iPhone in question and the date/time of the messages.
I’ll add more features over time — would love to hear your ideas for features to add. Finally, I’m providing this as a free utility, use it at your own risk and only on your own iPhone backup files or those of others only with their permission.
[Update 09-10-2009]
There was a bug in the original installer I posted. I have updated the download link in the following post to point to the new installer package.
Apple: No non-iTunes Managed Media Allowed on iPhone
An iPhone app we’ve been trying to get through Apple iTunes App Store review since June, GainCast for iPhone, was crushed for the third time today when we got this message from Apple (red emphasis mine):
Thank you for submitting GainCast for iPhone to the App Store. We’ve reviewed GainCast for iPhone and determined that we cannot post this version of your application to the App Store at this time. Because your app downloads media files that are not managed by the iTunes application, which also manages media files, we believe this would be confusing to the user. To avoid this customer confusion, we have chosen to not publish this type of application to the App Store.
If you believe you can make the necessary modifications to bring your application in compliance with the iPhone Developer Program License Agreement, we encourage you to do so and resubmit it for review.
Regards,
iPhone Developer Program
****************************
GainCast for iPhone is basically an RSS reader that allows you to connect to a Microsoft SharePoint server running the Podcasting Kit for SharePoint (PKS), which turns a SharePoint server into a YouTube-like server. It’s very cool and companies are increasingly using it as an enterprise podcasting solution.
For some background, the reason given for our two previous rejections was that GainCast transferred too much data over the cellular network — an unfounded claim in our opinion as many other apps already in the App Store do this (for example, the Consumer Reports app and FlipShare app). GainCast requests XML from a SharePoint server and streams H.264 encoded video (like many other apps), yet was rejected.
Therefore, to appease Apple we went back to make the app work only when a Wi-Fi connection was active. After nearly two weeks in review we got the aforementioned rejection notice. It seems we satisfied their concerns that we not use cellular bandwidth, but now the reason for rejection changed – we download media files and those media files are not managed by iTunes and this might cause confusion for users, according to Apple.
Let me see if I understand this logic — we can’t stream media because Apple won’t let us do so over the cell network, we can’t stream over Wi-Fi because the iPhone SDK’s Movie Player class doesn’t support streaming under NTLM authentication, so now we’re left with having to download media over a Wi-Fi connection, but now we can’t do that either because users might be confused if they download a media file into the app’s sandbox on their iPhone and then freak out when it’s not in their iTunes library. Would a dialog box telling users to not expect the media file to be in their iTunes library suffice? Will this bring us into compliance? It seems Apple has checkmated us.
By the way, when you’re watching a video on the iPhone, streaming or not, it’s being downloaded — mere semantics to Apple, I presume. The Consumer Reports app lets you stream video and it doesn’t save the videos into the iTunes library — goodness, I wanted that review of the latest toaster to be in my iTunes library forever in case I need to refer to it! Why isn’t it there?!? I’m confused, Apple!!! The FlipShare app doesn’t put the videos into my iTunes library and Apple’s very own YouTube app doesn’t. What’s going on here? Ironically, I predicted this nightmare back when we only had written a few lines of code — however my fear then was that Apple would reject the app because it integrated with Microsoft SharePoint. Maybe that’s a reason, who knows.
The truth is that all of this is bulls**t, control-freak, “we know what’s best for you” behavior on Apple’s part. I’m starting to question the claims of ignorance and lack of malice by Apple and its die-hard supporters — there is something rotten at work here. The larger issue is that by the rejection of GainCast for iPhone, Apple is saying that if you want to download media to your iPhone you have to go through the iTunes app to get it.
Feds Need to Connect the Dots on iPhone Jailbreak/Google Voice Issues
The FCC and U.S. Copyright Office Need to Recognize the Powerful Bargaining Chip they Have
Apple’s corporate ego has been on quite the roller coaster ride recently. Last week, as first reported by Wired Magazine, the team in Cupertino felt an unlocked iPhone was such a threat to national security that they pleaded with the U.S. Copyright office to make unlocking the device illegal under the Digital Millenium Copyright Act. There were claims of terrorists and drug dealers wielding unlocked and jailbroken iPhones unleashing bedlam on the country. Feeling quite important about yourselves weren’t you Apple?
Then an ego-crushing bombshell landed in Apple’s Washington, DC office late Friday (yesterday) afternoon — a letter of inquiry from the FCC with questions about this whole Apple/AT&T/Google Voice app rejection debacle. The questions posed by the Feds are all the right ones — I was pleasantly surprised with how craftily worded they were (I guess I don’t usually associate the phrases “government” and “tech prowess”). These queries are tank-buster missiles aimed right at the secret App Store review process that’s been rolling over developers for over a year and now it’s hurting consumers.
While Apple’s response will be interesting to read, unless Apple does a mea culpa and rapidly implements developer and consumer-friendly changes, it seems reasonable the government has no choice but to reject any ban on unlocking. If the status quo is allowed to continue, a consumer’s only real counter-measure to Apple’s anti-competitive behavior is unlocking, giving them the freedom to run any application they wish.
There’s no doubt the unlocking issue is important to Apple and the government should use this bargaining chip to its fullest advantage. I hope the folks at the U.S Copyright Office and FCC are talking with one another so they can connect the dots on this.
Apple is Making the Case for iPhone Web Apps
Apple’s Behavior Has Made the Case Why iPhone Developers Should Focus on Web Apps
Although the outrage over Apple’s capricious treatment of iPhone developers isn’t new, with the news of Apple killing off the Google Voice app it has finally acquired the gravity needed to make consumers sit up and pay attention.
Gaincast for iPhone, an app my team and I labored on for months, has been rejected twice by Apple, allegedly because it transfers too much data over the cellular network (it’s an app that lets you stream video from a Microsoft Podcasting Kit for SharePoint-enabled server). Forget for a moment there are a dozen other apps that stream video over AT&T’s cellular network (most recently Pure Digital’s FlipShare app), but we were special enough to get rejected twice. Most infuriating is Apple’s refusal to provide direction on how we could change our app to comply with their requirements. I’m beginning to think they torpedoed our app because it’s a value-added application for anyone using Microsoft SharePoint (their way of sticking it to the folks in Redmond).
Steven Frank, from Panic software, wrote something telling in his recent blog post:
“Fact: You can still do everything that the Google Voice app would have done by accessing the web interface through Safari, albeit slightly less conveniently. I doubt they’ll pull Safari from the iPhone, although that would be the logically consistent thing to do.
This illuminated a thought I’ve been kicking around for weeks now – that Apple is making the case why developers should focus on creating web apps, apps that run solely in the iPhone MobileSafari browser.
The first obvious cry from developers is “how can you monetize a web app?” My answer: “The same way web apps are monetized today on the desktop.” The entire AppStore experience can be replicated via a web app itself. App access and authentication can be governed via user login and cookies. The biggest upside to this, in my opinion, is that I’d never again pay twice for an app and could access it on my wife’s iPhone in case my phone was dead or out of reach. I’d love to have a web-based app store where developers with all manner of web apps could sell their wares and not be raped in the revenue sharing agreement or subject to censorship.
The next obvious challenge is that web apps have been second-class citizens in terms of functionality compared to native iPhone apps. It’s true that web apps on the iPhone previously had limited potential as they couldn’t access location services, the accelerometer, or the core graphics engine, but with the release of iPhone OS 3.0 the situation is improving – geolocation can now be tapped from a web app. Games with the robust graphics of Assasin’s Creed won’t be possible, but games aren’t taking the brunt of the ax-wielding AppStore Reviewers – innovative and useful apps such as the Google Voice app are. The first question a developer should ask before writing a line of code is “can this be done as a web app” and, if so, it should be done as a web app.
Consumers wouldn’t stand for a moment Apple or AT&T blocking access to a web app – the free speech, anti-censorship crowd would be on them like a plague of locusts in a nano-second. If they blocked a web app what’s next, web sites that Apple/AT&T censors/bean counters don’t approve of? You only need consider that if Apple/AT&T took one half step in this direction it would be game over for the iPhone and all its trappings that have made both companies filthy rich.
My new motto as a developer is “if it can be built as a web app, it should be built as a web app.”
Apple Rejects Microsoft SharePoint-related App
[UPDATE 07-07-2009]
The guys at The App Show mentioned GainCast for iPhone and the absurdity of Apple AppStore reviewers rejecting it twice. Go to mark 24:00 in the episode here: http://www.ustream.tv/recorded/1760924
[Original Post]
For three weeks I’ve been trying to get an application our team has spent nearly six months developing and testing approved by Apple for the AppStore. The application, GainCast for iPhone, is an app which lets users connect to a Microsoft Office SharePoint Server running the open source PodCasting Kit for SharePoint (PKS). Basically, PKS turns your SharePoint server into a YouTube-like server.
The first rejection from Apple had a robotic-like response stating:
GainCast for iPhone cannot be posted to the App Store because it is transferring excessive volumes of data over the cellular network, which as outlined in the iPhone Developer Program License Agreement section 3.3.20, is prohibited: " If an Application requires or will have access to the cellular network, then additionally such Application: - 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;"
I sent two emails back to Apple Developer Support asking for exact clarification because, upon browsing the AppStore, I found other apps which do the same thing our app does — the Consumer Reports app among them, where one can stream video reviews from a browse screen. Both requests for more info resulted in more robotic-like responses asking that I provide details of the support problem, including screenshots. It’s as if no one even reads emails over at Apple — the only technical support issue here is that Apple Developer Support folks don’t actually read emails before shooting off automatic replies asking for information irrelevant to the issue at hand.
So I re-submitted GainCast for iPhone for another review and in this submission I included verbose comments such as “before rejecting our app please note the following list of apps which utilize identical core functionality (e.g. fetching XML and streaming video). Today I learned that, again, the reviewer(s) seemed to have ignored my comments and questions, which included “please explain in detail how Apple perceived our app differs from others with similar functionality already approved and available in the AppStore.” The result: GainCast for iPhone was rejected again for the same reason — too much consumption of cellular bandwidth and, despite my request for a deeper explanation, there was none.
Ths is nonsense. Is there a deeper issue here? Does Apple not want apps in the AppStore that connect to SharePoint? Or am I giving Apple too much credit and is it that, as one could surmise by the multitude of complaints from other developers, that Apple’s app review process is secretive, inconsistent, not at all respectful of the interests of developers (e.g. read and answer my questions), and just plain broken?
If someone from Apple is reading this and has an ounce of compassion please comment with how I can reach you. I just want to have my specific list of questions addressed. Thanks!
COMING NEXT: Side-by-side comparison of the network traffic transferred by the Consumer Reports app vs. GainCast for iPhone.
