I've converted from using MGTwitterEngine to the new iOS 5.0 twitter API. My app works like a champ when running in the simulator. However, when I run it on the iPad (a device) performRequestWithHandler always ends up with a request timeout. I have allowed my app access to my Twitter account, and the official iPad Twitter client (which is also using the new iOS 5.0 twitter api) works fine.
I am at a loss why it will not work on the device when it works great in the simulator.
My iPad is running software version 5.0.1 (9A405)
Turns out that my issue was related to making the Twitter calls within a NSOperation. I noticed on the device if I brought up other UIViews (or generally manipulated the UI) it would complete the Twitter execution. If I did not touch the UI and wait, it would timeout. So it seems the Twitter operations on a non-main thread behaved differently between the simulator and on an actual device.
Pulling all of my TWRequest calls into the main thread solved the issue.
I did not experience this problem with my prior implementation using MGTwitterEngine.
Is anyone aware of different thread behavior of the iOS 5.0 Twitter framework?
Related
I would like you to help me here.
I'm developing an app that works in the background. It's a location-based app and I think I'm going crazy because when I'm debugging the app in the device it works perfectly, I make it sleep I wake it up and I works as expected. Then I unplug the device from the computer and I put in my pocket and whenever I open it, it sometimes works and other it doesn't, I'm talking about several hours in the background.
Are there any known issues about this? My device is running iOS 5.0 and I'm developing for iOS 4.0
Thanks
Applications in the background are handled by iOS. Therefore if iOS "thinks" that it needs memory it maybe frees some of the memory your app needs to run.
Have you tried to look into it with Instruments?
Both versions of my first App "Puffer's Train challenge" are currently sitting in the Apple queue "In Review". Saturday night I upgraded my iPhone 4 from 5.0 to 5.0.1 and also installed 5.0.1 on a new iPad 2.
Built & installed Lite versions of my app with iAds onto both devices. 5.0.1 initially caused both to crash. I was able to resolve that quickly (bad order of framework calls on my part) However! I spent the REST of Sunday trying to chase down any reason that test iAds are being served up to my iPhone (using wireless connection only to compare apples-to-apples), but the same code and the same calls fail with the error message "No inventory available" on my connected "wireless only" iPad 2.
App is built using xcode 4.2 for iphoneos, not universal, so I verified that the iAd framework call: ADBannerContentSizeIdentifierPortrait is returning 320x50 as it should. I "think" this rules out any problem that would be caused by different sized iAd requests.
Has anyone else experienced this same issue with Apple's test Ads using an iPad 2 device upgraded to 5.0.1? If so, I'd love to know that so I can stop (or at least slow down) pulling my hair out!
ps. Google's AdMob ads with which I replace iAds when not available, work Just Fine!
Because you're doing a Build & Install you're not using the Live (read: App Store) version of your app. This is why you're seeing Test Ads instead of actual Live ads.
Any time I've ever install an app to a device with Xcode I'm greeted with Test Ads from Apple. I believe this is because Apple intelligently looks at your app (either the version numbers or the provisioning file baked into the app) and knows that it's a developer build.
Now, if you're seeing Test Ads from the version of your app you've downloaded from the App Store then that's an entirely different problem. I've seen this as well but it doesn't sound like your problem.
As Apple adds new APIs and new methods to APIs with every new iOS update or release and given that nowadays you can't even test on an iOS 3.x simulator, is there any way to test your iPhone app in older SDKs or to know what SDK level you are using through it?
Downgrading to an old Xcode with a 3.x simulator is not an option and, well, there are tons of methods introduced in, say, 4.2.
Has any one come up with a lib, script, tool, anything, that analyzes the code to show API usage?
The way most iOS developers do this is to keep around an old 1st or 2nd generation iPod Touch (or other old iPhone device) that hasn't been updated past the oldest iPhone OS version that they plan on supporting with their Deployment Target setting.
A cheap used iOS device, even with a scratched/cracked display or mostly dead battery, from eBay (et.al. or some neighbor or nephew who upgraded), might work.
Testing on an old device is actually a better and more accurate check than just testing with the Simulator, as the Simulator for various SDK versions supported APIs that the device at that OS level did not.
I can't find anywhere definitively, if you build an app against the iOS 4 SDK, to thus support multitasking, does that mean the app won't work in iOS 3? If not, how can you support iOS features like multitasking but still support iOS 3? I'm sorry if there are Apple docs on this, I'm happy to read them, I just can't find them. Thank you
You can build against a 4.x Base SDK, and set the Deployment Target to 3.x.
But you have to make sure not use any of the new 4.x APIs without checking for their availability first (or you will start to run, then crash as soon as you call one of those APIs on a device running 3.x). And you will need to test thoroughly on an actual device running iPhone OS 3.x since there is no simulator support for this kind of OS portability testing.
In some cases, converting a 3.x app to also allow what is called "multitasking" under 4.x is as easy as rebuilding the app using a new 4.x Base SDK, but leaving the deployment target where it was at 3.x, and adding an applicationWillResignActive: delegate to handle both suspend and potential termination.
No it does not. iOS 3 just ignores the delegate methods that get called.
However, if you try and launch a background task, you'll have to check for the API first, otherwise yeah, you'll not run on 3.
I'm writing an iPhone app that needs direct access to the camera. Since it is in-house, I have no qualms about using the full set of headers and private frameworks.
I included and the PhotoLibrary framework in the application. It compiles for the 2.0 firmware, and I can put it on the device and run it. As soon as it is started, however, it quits and returns to the home screen.
I think that the PhotoLibrary framework is somehow not being loaded or something similar.
I would post some debugging output, but I don't actually have the phone yet.
Thanks!
That might or might not be the problem. The iPhone simulator lets you get away with a lot of stuff that doesn't work on an actual device-- there's any number of classes that a simulator app can use that don't exist on the phone (e.g. NSXMLDocument, available on Mac OS X and iPhone simulator but not actual iPhones). Get the phone, run the app, and use Xcode to look at the phone's system console to see why it's crashing.
Thanks for all the help.
It turns out that I was trying to use classes from the iPhone 2.0 SDK with an iPhone that has 2.2.1. Thus, it would compile correctly when I set the device to 2.0 in Xcode, but would fail on the iPhone because the old classes were no longer there.
I fixed my problem by getting the classes from the 2.2.1 SDK. Now my program runs fine on the iPhone.