Fellow developers. My thanks to you all for your help and suggestions.
My app SafetyKnight has been approved for sale by Apple and I have submitted an inApp Purchase version for approval.
One last 'bug.' When first opening my app, it sometimes quits unexpectedly. Not often. But only rarely sometimes.
Does the MKMap or maybe not strong signal from communications provider cause an app to cut out at start-up?
Any thoughts or suggestions of code I might add to NOT have the app close/crash to enhance the user experience?
Check your app's memory usage during launch and initial view display. The app might be running out of memory if a lot of other Apple processes (or background apps) are running (Mail fetch, music player, etc.). Also make sure you are checking all your error and status return values from your networking code.
From the Organizer, you can access crash reports of any device connected to your computer. Make your application run in debug mode on the device until it crashes and check in debugger where it happens.
Did you handle the low memory notifications in the didReceiveMemoryWarning methods of the relevant UIViewControllers? What is the iOS you are building against?
Related
My application uses the core location also after the application terminates with the method startMonitoringSignificantLocationChanges in CLLocationManager class.
My application launches with a location key in iOS 5 and 6 in the method:
- (BOOL) application:application didFinishLaunchingWithOptions:launchOptions;
in AppDelegate class and everything works well.
But in iOS-7 betas the application doesn't launch with a location key after a significant location change.
Has anybody encountered this problem?
I tried it on a simulator and in the device.
Thanks for the help.
I have the same problem in my app, when the app was terminated by user from app switcher.
But it does launch with location key if it was terminated by OS for low memory or other reason.
It is the expected result from iOS7 unfortunately. An official apple response I got from one of their evangelists:
If a user swipes up in the app switcher then the OS will not launch
the app unless explicitly told to do so by the user. So no, SLC will
not be launching the app, nor will silent notifications. The only
thing that will launch the app at that point is the user tapping the
icon. The intention here is that the user has expressed their choice
of not having that app running any more for any reason, so we honor
that. In this situation, there's really nothing that you can do. The
next time the user launches the app you can let them know that some of
the data may be missing, although you really cannot tell whether
there's missing data or not (i.e. you might have been killed by the OS
in the background and the user may not have moved thereby not
triggering any SLC notifications). My suggestion would be to gather
the data you can within the policies of the OS and if the user has
manually killed the app then respect that wish and don't do anything.
By all means, feel free to file a bug report if this change in
behavior winds up causing problems for you or (especially) confusion
for your users.
Attach link to Apple DEV forums:
https://devforums.apple.com/message/882691#882691
Our apps are live on the app store.
I wish to recognise crashes of out of memory that some users are getting.
I understand there is no way to 100% recognise an out of memory crash.
Is there any way to recognise these crashes(with a pretty large probability) by doing some logic in the applicationDidReceiveMemoryWarning? (I am not talking about finding it in xcode during development time, i am talking about code that will recognise the out of memory crash from actual users and will log something to file)
While I was looking for any service or library that give me OOM tracking, I could only find this article from Facebook engineering:
https://code.facebook.com/posts/1146930688654547/reducing-fooms-in-the-facebook-ios-app/
The idea is to deduce the reason why the app needs to be launch, checking different aspects (like if the app was at background, if there is an app/OS update,...).
Discarding all the other possible reason that can force the previous app exit, you can know if the reason is a background out of memory or a foreground out of memory.
It would be nice to have a library that implements the Facebook article procedure. But nowadays I couldn't find any, probably there is some reason that make this difficult or may be impossible to add it as an sdk.
If anyone knows any service, please share it with everyone with a comment or a new answer.
Edit:
I have discovered this github (https://github.com/jflinter/JRFMemoryNoodler) with an implementation of the Facebook post procedure. I haven't tried yet, but we will deploy it in our apps to try it.
Look out for the applicationWillTerminate message in your app delegate. This is called if you app is terminated by the system (due to e.g. low memory), but not if the user leaves the app in the usual way by pressing the home key. Note: if your app is in the background and memory runs out, your app gets killed without any messages being sent to it.
YMMV, especially with older versions of iOS, and it's worth researching to ensure that the above is accurate.
The images at this blog post are quite informative (although slightly dated).
For more info, see How to know whether app is terminated by user or iOS (after 10min background)
Firstly Analyse your application by clicking on the Product at the top menu bar of your Xcode and click on Analyse section it will show you the number of leaks on in the application and can take you to the place where leaks occurred. This is how you can find the memory leak and rectify it.
Secondly it above does not worked then see to the view controller where crash occurred and check whether you have left any object to release.
Hope this might help you to resolve your problem.
I want to develop one application which should be monitoring how much application is running on how much time on my I-Phone Device(including internet browsers).
Please share your idea regarding this post.
little similar like this:
https://itunes.apple.com/us/app/system-manager/id455736462?mt=8
thanks
You really can't since Apple has placed very restrictive guidelines on Apps for iOS.
Although with some low level call you might get some running process information.
Because of the sandbox environment you might not be abele to much more information then that.
Also app's in background are suspended if they have no background running flaggs (voip, audio, location or accessory). Also if the system gets low on memory app that are suspended get killed and there memory freed up.
What you can do:
Try the List of All Processes OS X code which
Can we retrieve the applications currently running in iPhone and iPad
But keep in mind the restiction placed on you app by Apple: The iOS Environment, thus that there are app availble in the appstore that do what you want does not mean that you app will be allowed.
So I have an app that has twice been rejected from the app store and I really could use some help!
It has been rejected for the Watchdog timer forcing it to quit when it is first opened. However I have not been able to reproduce this on any of my devices. It does take a long time to build to a device when using xcode (i know that when built from xcode the watchdog is disconnected). But I have a couple questions that might help me fix this.
Does the watchdog take into account only didFinishLaunchingWithOptions: or are their other methods that it calls?
Does the number of frameworks used by the program have anything to do with it? and if so is 11 frameworks just too many?
Once the app is installed to a device, and I unplug said device is the watchdog timer re-enabled?
What are some other things that can add to the watchdog timer?
Apple said that another possibility could be Another possibility could be a missing entitlement. Could someone please explain what this means, I hav'nt seen this before with my other apps but thought maybe it was something new? And does it have to be installed on all apps for the appstore?
Time Profile for first seconds
You are blocking the UI thread for too long. To solve this problem, first you'll need to figure out what code took that long. It might be worthwhile to profile your app. Note that the simulator doesn't emulate the device, it only emulates the API. It could run much faster than the actual device because your computer is more powerful than an iPhone. Try click and hold Run at top left of Xcode, and choose Profile. Choose Time Profiler and run for a few seconds. Stop the profiler to analyze timing in function calls. Note that you may need to dig deeper, find some tutorials or books to really understand profiling.
When you know what parts have been running slow. You can put them into a thread. The easy way would be to use Grand Central Dispatch. To get started, visit this tutorial. You can skip the first half and focus on the actual thread blocks. The APIs are dispatch_queue_create, dispatch_async and dispatch_release.
This will unblock your UI.
Do you do a lot of processing in
application:didFinishLaunchingWithOptions,
applicationDidBecomeActive,
applicationDidEnterBackground,
applicationWillResignActive or
applicationWillTerminate?
Things like multiple file access, loading/saving data, synchronous network access can cause your application to freeze on startup or when the user exits, and could cause the watchdog to kill your app.
This Apple Technical note suggests that the watchdog is only looking at the launch, suspend, resume and terminate user interface events, so I would say you should look into these first, and maybe post back some more details of what your app does in the methods listed above.
http://developer.apple.com/library/ios/#qa/qa1693/_index.html
11 frameworks is fine. I have used 11 in an app no problem.
If you start the app up by tapping the icon on the home screen then the watchdog timers will be active and monitoring your app. If you start the app up by hitting run or debug in Xcode, then the watchdog will not be monitoring your app.
Ever since the first beta came out I’ve been trying to find out if “real” multitasking is possible — i.e. can you put a program in the background and have it hang on to a network connection indefinitely?
I’m thinking about IM or IRC apps, for example. I’ve compiled an app myself on iOS 4, and without changing a thing it appeared to stay running in the background, but for all I know it was just suspended to memory.
The docs say the best you can do is request up to 10 minutes, but in the developer presentation they showed off Skype sitting in the background and then notifying the user that a call was coming in. Does anyone know for sure how this all works?
It appears the answer is no. The API for Skype is a very special case, called the "voip" mode, and requires special behavior, such as marking the socket in use for VoIP.
You can receive alarm notifications in the background (such as time passed). The amount of time you are in the background running state is severely limited by the OS.
Android's background model is complete and in many ways much nicer.
Apple has a guide named "Supporting Multitasking In Your Applications" which you should be able to locate.
Apple's iOS 4 developer docs outline this all very clearly.
When your app is closed or switched away from, it is almost immediately "suspended", meaning the OS freezes the app's state. When the user switches back to your app, your code keeps running just where it kept off. You don't need to add any code to your app to do this, just compile it against OS 4.
The above is true in most cases. There are two reasons the "suspended" model may not apply:
1) If the device starts to run low on memory, the OS will start terminating suspended apps that haven't been switched to in a while, without warning. This is why it's in your best interest for your app to remember it's state as well, so if your app is terminated, then re-opened, the user doesn't really notice because it still returns to right where they left off.
2) Your app uses one of the "background" APIs. These are for audio playback, VoIP services, or location services. In this case, your app is allowed to continue running in the background but only has access to those APIs. Additionally, your app can designate certain long-running tasks as "background tasks" that need to be completed before the app is suspended or terminated, like uploading pictures to Flickr or rendering a video, etc.
The "background task" method doesn't cover pinging servers indefinitely, as there is a time limit for the task, after which it will be forcibly halted. Apps that need that sort of functionality are expected to implement push notifications, just as before.
That should clear this up. All in all I think it's a pretty elegant solution to multitasking on a mobile device.
iOS 4 applications can either be running or suspended. The operating system will try to keep as many requested applications as possible in memory, while all other applications are suspended.
Applications that run in the background can access features such as navigation, audio, and VOIP (but NOT instant messaging). So it looks like you might be out of luck.
-- PC World Multitasking on Apples iPhone 4
It is possible for apps to request background time. Read the docs. I would say it iOS is "controlled multitasking".
You can create a long running background task, I believe these can include networking features. Just have to set the background task flag on the work block.
https://developer.apple.com/iphone/library/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
the OS can limit exactly how much time you get though... it will tell you when your time is up giving you a chance to cleanup nicely.
iOS 4 has "real" multitasking to some extend. There are two things to consider:
The UI event loop is single tasking. So only the front app executes on the UI event loop. Not a big deal: detach your main code form the UI event loop (maybe you need to redesign your app).
The OS "may" terminate your app if some criteria are met (e.g. low memory).
Currently one of these criteria is that execution time is limited to 10 minutes (real time not cpu time). However I expect this to change and see better criteria for background app termination (I hope to).
Apart from this you can have timers (event loops) in background.
There is no real multitasking in iOS 4.2 even. because apps will only be allowed to finish the task related to states..for small interval of time and then it will be in suspended state.. If you will set background task for long interval of time then... it will behave unexpectedly like no method will be called when you will try to run the app from anywhere..
You may be interested in this blog post that outlines how "multitasking" works in systems such as iPhone OS 4 and Android.
in fact u can do this, although it's not allowed by Apple. u gotta set up a toolchain in ur mac and use some unofficial SDK...
check http://code.google.com/p/iphone-backgrounder/ for more information
You should use the Push Notifications framework for the feature set you are creating!