My team is developing an iPhone app which is very demanding in terms of memory. In order for a better user experience we are thinking of presenting a pop-up to the user upon startup stating the memory requirements and also a pop-up upon low memory.
Has anyone had a problem with such a solution, in terms of being rejected from the app store?
Thanks
It's simple, don't show any UIAlertView in a memory warning.
The user is not responsible to manage the memory for you. You need to take actions in memory pressure by releasing caches or other less important information.
iOS itself will release memory and kill other apps when it's needed.
To answer your question, I don't know if Apple reject apps for that reason, but they repeated more then once to not to do so.
IMHO, on iOS systems, specifying the memory requirements to the user is not relevant. Most smartphone users won't know the available memory and don't want to be bother by technical aspects. To be successful, your app need to be robust and that also means memory adaptive.
As far as i remember you can ask the system to give you the amount of free memory. Try to manage your memory consumption using it. There are many strategies. Common ones are to ask it periodically or ask it lazily only when you are going to load big data.
When you receive memory warning, try to reduce your memory footprint the more you can
I'm not sure anyone can say anything sensible about whether this behavior will be acceptable in the app store. I've never heard of an app trying it.
Philosophically, it seems counter to the HIG. Memory management is your job, not the user's. You could maybe give them some "usage information" on first launch asking them to close backgrounded apps when using this one, but putting a memory alert in front of the user just feels inappropriate.
Apple might not be happy with an alert, but possibly some kind of subtle ui graph showing available memory abstractly would be ok, and probably a nicer experience as the user could see how what they were doing affects memory.
Related
If my app uses less than 10MB do I have to bother to use those methods? I know that they are for caching low memory situations but this might occur only if you do not tested you app before releasing it. If you have tested your app, the app does not have leaks, have a small memory footprint, then why should anyone bother to use memory warning methods?
Your app is probably not the only thing running on the device. Other apps and processes are also taking up memory, and in some situations they may need it more than you. It's always a good idea to respond to memory warnings by releasing cached data that can easily be loaded again. That way the operating system has control over the memory usage, and it won't have to terminate your app.
hi i just want to know this: When will iphone 3gs and iphone 4 send out memory warnings
i mean after how much memory our app uses does the both devices send warnings?
Thanks
You don't know when it will fire. You don't know how much memory is being used by other apps running in the background, Safari keeping webpages, etc. Pandora might be streaming in the background and it might be using a significant amount of memory. Don't count on any single amount of memory. Load lazily, and release uneeded allocations in didRecieveMemoryWarning.
If your app requires a lot of memory, some game developers tell their users to restart the device before playing to ensure the most memory for the app, and best performance.
It is not strictly defined but Apple suggests you don't use more than 24MB of graphical memory as overuse of graphical memory is typically why an application receives a low memory warning.
The only good way to manage critical low memory situations on the iPhone is to implement the didReceiveLowMemoryWarning delegate methods and release as much memory as possible at that point. This means for instance:
All non-visible images currently loaded in memory
All view controllers and their subviews if not in use
This can of course be done safely provided your application is able to reload that information at a later stage. didReceiveLowMemoryWarning is however a last resort situation for your application.
To avoid getting to that point it is recommended to only load resources lazily i.e. when and only when you need them, and release them when they are no longer needed (for instance implementing viewDidUnload on all your controllers).
I've been looking at some very great online services iPhone app, such as the Twitter app. It's very robust, I can't crash the app no matter what I do.
When I try to build one, I always get crashes whenever there's something wrong, like no internet, wrong passwords, etc. Especially I notice that my app crashes when I switch between tab bars too quickly (when one of them is waiting for a response from the Twitter server, for example). How do I elevate this issue?
Is there any tips to build apps that never crashes like Twitter for iPhone?
Crashes tend to happen because of one of two reasons:
You're referencing a deallocated object
You have exceeded the amount of memory that you are permitted to use, either due to leaks, not lazy loading, or just an overall bad design.
As far as Internet connections go, this StackOverflow question has your bases covered there.
It's hard to say why making fast tab bar switches are causing your app to crash without code.
I have written such an app (a shopping app that uses the network for everything). Here are some tips:
Implement reachability so you know when the network is there (and keep checking it)
Run all network access asynchronously so the app does not freeze, thread networking when you can.
Send and receive the smallest amount of data per request. For example, in my shopping app, I only get 50 products per search, with only the SKU, description and price. Use JSON.
Round trip - request network data - as infrequently as possible, and at most once per screen. If you can do with the data you have in memory, do so.
Lazy load images
Cancel all network connections as soon as possible. As soon as the tab changes, kill any outstanding network access.
Cache, cache, cache. Its always quicker to get data locally.
Hope this helps.
One big differentiator between great network apps and terrible network apps is handling network latency. I can't stand apps where the UI stalls or becomes jerky when data is requested from the network, or where the entire interface is frequently locked up with an activity indicator. I tend to quit and uninstall these types of apps right away. Sometimes it is not entirely obvious how to allow the user to continue interacting with the app when some data is required from the network, but the hallmark of great design is that you think about these issues ahead of time. Really, those lengthy stalling activity indicators are a big "fail!" in my book.
I'm writing a network-data-heavy app myself, and implementing a really simple URL image cache singleton class and a "lazy" subclass of UIImageView that loads images in the background using an NSOperationQueue was really pretty simple, and the app runs smooth as glass :).
I'm reading some people stating that if another (3rd party) app on someone's iPhone has been leaking memory, that this may reduce the (mystery) amount of RAM your app would otherwise have available.
This confuses me -- does not all app memory get released when the app is closed by the user? And only one app is open at a time on iPhone?
Normally, any memory that your application allocates will be freed when it exits. However, many of Apple's applications continue running after they're "closed", so memory leaks in Mail, for instance, can affect available memory.
In addition, there are apps out there that claim to free up allocated memory. They really don't do anything other than force some dirty pages out of the buffer cache, but they appear to do something, so people believe they must be doing something useful.
On a jailbroken phone - yes, third party apps can be running at the same time as yours. Running out of memory is common with people who like to have many apps running at once hence the need for task managers, killing tasks etc.
On an unhacked phone - no. Yours is the only non-apple app that is running, no others can run at the same time.
So what can you do? All you can do is try to use the minimum memory possible which you're probably already doing. Realistically you can only test with a factory, unhacked phone, unless you are going to spend hours trying to please everyone. If you think you are maybe using too much you could identify the larger allocations using the instruments tools ("Run with performance tool >" from within Xcode) and then post that chunk of code here to get ideas of how to reduce it.
You should run Instruments and then add the instrument "Memory Monitor" to see the memory use of all of the other processes on your phone. (Add with Window -> Library , then drag the Memory Monitor instrument to the instrument panel.
What I'm still trying to determine is why is iOS releasing memory from MY app, and not all of the other memory pig apps that are not currently running.
So, I finished writing my first iPhone App, and I have sent it out to a group of beta testers.
Everybody is happy, except for this one guy who noticed that after having run my app, another app is not starting up anymore.
Not knowing too much about memory management, I started looking at the Leaks graphs in Instruments, and noticed, that there are some leaks going on in my app.
Three questions:
Are leaks always bad? The biggest leak is 15k on a total of 5,1 MB allocated memory.
Will Apple refuse my app because of leaks?
Is not all the memory automatically freed up as soon as my app quits? Could it be that my leaking app is harmful to other apps?
Thanks
Sjakelien
Each app is supposed to run in its own "sandbox," and is by design not supposed to affect any other app installed on the phone. If your reviewer found a case where your app really did affect another app, that's definitely not your fault, although I'd love to know how that was accomplished ;).
My guess is, though, that your reviewer's other app broke completely independently of your app, and he/she is spuriously attributing the fault to your app. Ask him to try to reproduce the problem (uninstall both apps, install the other app, install your app).
what the other two answers say i agree with, however nobody has answered the first question ("Are leaks always bad") directly. i would say that yes they are. it's true that your program can possibly run with them for long periods of time without issue. and the OS should clean up the memory after termination (unless there's a bug in the OS, as said before). but eventually the leak will become an issue for someone at some point when they run long enough. also, even if it doesn't become an issue, it's probably a best practice to always fix memory leaks that you know about.
Any leak that persists beyond the exit of your application is an OS bug, and hence Apple's problem.
It would be unfair to reject your app on this basis.
I don't know if that's any comfort to you.
For the record, my app provokes a leak in mediaserverd.
The leak is a tiny bit smaller in the 3.0GM.
Another incorrect usage of an API crashed mediaserverd.
Also 3.0GM. Nasty. I'd have preferred an error code, however
this could theoretically be used to work around the leak.
It depends on what "memory" you are leaking. Are you using device storage space to cache something? In theory then it's possible that you've used up enough space the other app cannot start because it needs a certain amount of free space.
If we're talking physical memory, then no. When your app is dead it is dead. You could ask them to restart the device and see if they have the same issue.
Apple does approve apps that have memory leaks.
That said, we thoroughly check that none of "our code" leaks before submitting to Apple because users don't like having an app suddenly shut down on them. I say "our code" because there are memory leaks in the framework that are not your doing. Thus Apple approves apps with memory leaks.
Also, I am doubtful your app has adversely affected the user's other app. I have not seen that behavior.