Recognising gestures from the home screen - iphone

I am developing an app for iPhone.
I am looking for a way to run some code once a drag gesture is recognized on the homescreen (or on all screens if possible).
Does anyone know how to get this with the iOS SDK using Xcode and Objective-C?

Your app cannot receive gestures anywhere in iOS except within itself and its own views while it's active (not counting system notifications and the app icon).

I doubt this is possible. To do this, you will need to hook into the OS at a lower level than is usually allowed.
iOS is locked down much more than Mac OS, I'm afraid.

Related

App works on iphone simulator,iphone device, ipad simulator but not ipad device

So I made an app, And it runs on all possible platforms except the ipad device. I would understand if it ran on the ipad device and not the iphone device since the processor is better on the ipad, but this has me stumped. It also worked fine on the ipad simulator. Can anyone think of a reason why this could be?
There are too few details to give an explanation. A possibility is: when you run the app in two different devices, iPhone and iPad, some nib files could be different. Even the app delegate is different if you use XCode templates for universal apps. So this means that it is possible that the code executed is different in the two devices.
So imagine that in the iPad app delegate / view controller you're allocating - at launch - a lot of memory (scroll view with many large images for example). Then the app will not crash in the simulator (it uses your Mac memory). The app will not crash in the iPhone (different code). So at the end it will crash in the iPad only.
Other possibilities: you're going short in memory very soon. But the iPad 1 has less memory than iPhone 4G.
Other possibility: the watchdog timer kills your app at launch. It happens on the iPad 1 only because you're loading a few large images and it takes a lot of time, just enough to be killed by the watchdog.
Other possibility: iPad 1 is still with iOS 3.2, while iPhone and simulator are linked to iOS 4.0. In this case it is easy to have the app crashing in iPad 1 by calling one of the many new APIs introduced with iOS 4.
As you can see there are many possible explanations...
add target for device or convert it to universal application
Yes, it's easy to target both platforms. If you login to ADC and read the Programming Guide, it'll provide the basics for specific development. I can't legally speak of the "how."
Um. If you follow their directions, build two targets, share your source within the same project... then you'll be set. It's the same SDK, just different Nibs & main(), from what I can tell.
You say different xibs... you might be missing an Outlet connection somewhere.
Ok gents, sorry but I did not provide enough information for any of you to correctly answer this, but! here was my problem.
I had a login screen with 2 textfields, and a submit button. The submit button would release the current view and add a new view. I would usually press submit while the keyboard is being shown. Aparantly this makes everything blow up. You must manually hide the keyboard first. Hopefully this saves somebody some time.

iPhone - fast-app switching and iOS 4

I'm trying to get the following functionality in my iPhone app:
When backgrounded, stays running (doesn't have to do any background work)
When resumed, app picks up where it was left off
I'm mainly wanting the same screen on my app still up, as there are several UINavigationControllers within a UITabBarController.
I have done all of the following:
Made sure I'm compiling with 4.1 SDK
Set UIApplicationExitsOnSuspend to false
Handle DidEnterBackground and WillEnterForeground in my AppDelegate
Call BeginBackgroundTask in DidEnterBackground, to attempt to keep my app open
I'm using MonoTouch, but that it probably beside the point. I can take answers in Obj-C, for sure.
I've tested my app on a jailbroken phone with Backgrounder, and I see the "app in background" badge disappear immediately after pushing the home button. I also tried setting UIBackgroundModes in my Info.plist, but to no avail.
Is there anything I'm missing?
Or is this something I would have to implement on my own to resume the previous state of my app? Everywhere I've read talks like it should just work automatically.
If you don't want to be doing work in background, don't call beginBackgroundTask. That call is for situations where you want to do some kind of work in the background. And if you don't finish that work fast enough, iOS will terminate your app.
When I upgraded to iOS 4.x, my MT application started exhibiting this behavior without me having to do anything. iOS should take care of it for you.
I finally got in touch with someone on MonoTouch's irc.
In MonoDevelop there is an option to make a dual iPad/iPhone project, which I used. This is causing my app to behave as if it's running with the 3.2 SDK when deployed to the device.
I think my solution is to install the iOS 4.2 SDK that just came out, since this ads the new multi-tasking feature on iPad.
Not only do you need to support going into the background, you also need to support cases where your app has been terminated. In your app’s initialization code, you should resume the state that it was in. For instance, when you push a view controller, use NSUserDefaults to store a value for the currently-displayed screen, and then when you start read that value and display the associated screen.

GUI is stuck with uibackgroundmodes= voip, audio

I have tabbar-based application. When I put in my plist UIBackgroundModes (my application is supposed to support voip), the GUI doesn't load. It sucks on Splash screen and doesn't load the first tab view. When i remove the UIBackgroundModes property from info.plist, it works fine. More than that, pressing the home button when it stuck does nothing. Did somebody encountered a similar problem? (The problem exists on simulator)
Thanks,
Nava
It appears, that the problem happens on Simulator only, it works on the device... So the solution (temporary one) is not to put UIBackgroundModes into info.plist for simulator version.
You are responsible for loading/unloading the interface when going in and out of the background mode. You'll also need to update the interface accordingly when coming out of background.
iOS helps a bit by taking a screenshot before putting the app in background and displaying it when getting the app to foreground (a bit like Default.png when starting the app) and also some UIImage caching.
It might be worth sharing some code.
Supporting Background State Transitions
Supporting the background state transition is part of the fundamental architecture for applications in iOS 4 and later. Although technically the only thing you have to do to support this capability is link against iOS 4 and later, properly supporting it requires some additional work. Specifically, your application delegate should implement the following methods and implement appropriate behaviors in each of them:
application:didFinishLaunchingWithOptions:
applicationDidBecomeActive:
applicationWillResignActive:
applicationDidEnterBackground:
applicationWillEnterForeground:
applicationWillTerminate:
Being a Responsible, Multitasking-Aware Application
Applications that run in the background are more limited in what they can do than a foreground application. And even if your application does not run in the background, there are are certain guidelines you should follow when implementing your application.
Do not make any OpenGL ES calls from your code. You must not create an EAGLContext object or issue any OpenGL ES drawing commands of any kind. Using these calls will cause your application to be terminated immediately.
[...]
iOS Application Programming Guide
I see this bug as well. It's very annoying. It's as if the app is stuck in the simulator and won't keep going. When this happens, I know how to "unstick" it.
In the simulator I just go to menu Hardware > Lock and then unlock the phone again. Now I stop the debugger and start the app again. This seems to kick it back to life.
Fortunately this bug doesn't happen on a real phone, only in the simulator.

Not getting clicks in iPad version of my iPhone application

Using the latest SDK from Apple, I noticed that while running on the iPhone works fine, the iPad version of my application doesn't "accept clicks" on any view/widget that is outside the "bounds" of the standard iPhone screen.
Any idea?
Thanks,
Reuven
Vanilla iPhone apps will only accept touches within that little bounds, to reproduce that fact that the iPhone resolution is only 320×480.
To fix it, upgrade your app for iPad.
(Also, make sure you don't hard-code any numbers. For example, use [UIScreen mainScreen].bounds.)
OK - found it...
All I needed to do was to open MainWindow.xib in Interface Bulder, and in the Window Attributeds palette, to check "Full Screen at Launch".

Dynamic (Default.png) splashscreen in 3.0 [iPhone SDK]

I know it's possible to create a dynamically changable Default.png by creating a symbolic link. But that's not possible in iPhone SDK 3.0 anymore (only in 2.0).
How can I make this in 3.0, or is this impossible?
Tim
This worked on iPhone OS 2.0 http://collison.ie/blog/2008/11/dynamic-defaultpng-files-on-the-iphone but not on iPhone OS 3.0 anymore. The default-screen is always black.
I can change the default-screen in the documents-folder and the symbolic-link does link to that file. I tested that by browsing to the app-folder from the Simulator. I saw the right file in the documents-directory and I saw that the symbolic link points to that (the right) file.
It's not possible in 3.0. It was only possible on 2.0 because it was an exploitable bug. The bug was fixed in 3.0 which is why it's not possible.
Apple don't intend the Default.png to be a "splash screen".
If you read the HIG, you'll see that the Default.png is suppose to represent your user interface as it would be "empty" - without any content. It is intended to give the user the illusion of an "near instant" launch.
Check out all of the Apple apps on the iPhone and you'll see how the default.png is meant to be used properly.
Apple frown upon using the Default.png as a splash screen. They say that it is really only appropriate for apps such as games that don't use the standard UI elements that are provided in the SDK.
That being said - lots of apps these days are using this feature to show splash screens, and seems Apple aren't really enforcing this guideline.
Long story short, you can do a splash screen, but it can't be dynamic - not anymore.
Use a blank Default.png and then in your app delegate's -applicationDidFinishLaunching: method, load a UIView that contains your dynamic content. This solution sidesteps any conflicts with Apple's SDK terms as well as all technical problems.