My app draws a UIImageView with a photo to the screen every time a button is pressed.
The normal use case for my app would probably be about a dozen or so imageviews, but a user could potentially abuse it by continually pressing the "Add" button.
After about 50 or so the new images turn black. And after 100 or so the app freezes.
Now the majority of people using my app probably wont come close to these numbers, but through sheer abuse, they can crash the app. Is it my responsibility to design and implement failsafes that prevent the user from purposefully crashing the app?
I would argue that you should ensure that any software you produce meets the requirements of the user to the best of your ability. I suspect there is a memory allocation issue at hand here. In any case, I would argue it's better to find a bug and fix it rather than get complaints from users when they inexorably find them. If a bug affects the functionality of the program noticeably for the user, then I think it should be fixed. Cutting corners should be considered when adding extra features that may take more time than appropriate, not when fixing existing features.
Related
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'm currently designing an app for the iPhone and I'm deciding on some features that imitate several native iPhone UI components and elements.
In my app, the user has to arrange several items on screen. Basically, they are free floating (not in a grid). In order to be able to move them, the user has to hold a finger on one of the items until all items start to "wobble". Just like on Springboard, when moving applications. Is it allowed to imitate this functionality?
Another function is the "split screen", as seen when adding an application to another application. The screen breaks open, showing a new group with the familiar textured background. In my app, some screens require a user decision by picking one out of four icons. I want to present this by using such a modal view over the main view, more or less like the "add to group" function of Springboard. Is this allowed?
I'm well aware that there are several programming questions related to my issue, but none of them covers whether apps are allowed if they include the functionality. Any help is greatly appreciated!
(On a side note, I read on HN today that Apple doesn't really answer questions to Support about app approval, therefore I ask here.)
I think the biggest problem you might have is the "free floating" functionality. There's a very big gray area as to what's accepted and, from my experience, you can't have an app with with seemingly floating windows like a desktop.
I can't see Apple having a problem with the Springboard functionality because the Facebook app has it. I would just try to make your own version and not try to reproduce the code.
Also, the Split Screen animation should be fine.
My 2 cents.
There is nothing in the guidelines about such functions not being allowed. I have submitted to apple an app recently with a wobble function like you mention and the reviewer did not mention anything about this being not allowed (The app was rejected for another reason which has to do with content licensing).
Currently I'm testing an app that I've written with ios 4. I've spent a good bit of time looking for memory leaks and that side of things seems o.k.
I have a problem where the app seems to "randomly" quit after going from one view to another. Sometimes this will happen after a minute or 2 and sometimes it won't happen at all. Because of this it's really very difficult to determine where the flaw in my application is and under what circumstances because my observations of whats going on is subjective. Also it can get very annoying very quickly sitting there hitting buttons until something happens and then trying to remember the sequence of your actions.
What would be a good method to hunt down the cause of this seemingly randomly occurring problem?
For example,
I remember speaking with QA engineer before and he spoke of tools that he used to automate a user using an application. He'd leave it running over night and then in the morning he could examine what combination of user actions and under what circumstances a problem occurred.
Are there such tools available for testing iphone applications? Ideally what I'd like to see is a report of
action a
action b
action c
= everything ok.
action a
action c
action b
= there was a problem.
There's also fonemonkey: http://www.gorillalogic.com/fonemonkey
As for random crashes... I am tester, not developer, and random crashes are usually one of the topics I examine more thoroughly on every iphone app. My favorite scenarios are: leave the phone for 2 min, for 10 min, and switch apps (on iOS 4). In all cases it's better to use a real phone (and the older the better), not a simulator (some crashes never happen on simulator). Commonly nested views are affected (e.g. get to some view, let phone sleep, click "Back" button to return to previous view - crash). Usually developers say that incorrect retain / release, autorelease while another object holds pointer, and other memory issues are to blame. Also Device Logs (which will have crash report) usually can pinpoint problem pretty accurately.
Hey.
Instruments by Apple. Apple reference.
Instruments has its limitations and drawbacks, but just try it. It may be confusing at the begging so try to follow tutorial, or some other.
Check out running the app with zombies enabled. Also, instruments in Xcode is very helpful.
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 :).
Suppose one wants to port a desktop app to a smartphone (which can mean write from scratch).
How in your opinion should a mobile version relate to to the desktop one? In other words, what are the common features of mobile apps?
I can say:
short user interface (not time consuming)
dense content, filtered in comparison with the desktop relative
personal: no mult-user requied (smartphone is a personal device)
What else?
Apple has some guidance in the Human Interface Guidelines
Some things I would think about are:
How do you want to present your data efficiently, yet elegantly?
Which controls and view types will you use? Meaning, does this part of the program do best with a UITableView or a UIScrollView or should there be a drill-down Navigation to flow better? Essentially, I'm just saying, determine the flow-down structure of your application. You need to become familiar with each and every control so you know where a typical user expects them to be.
Users on an iDevice (except for iPads) are used to a one-window environment. Therefore, don't try and pack every little detail into the screen. Break it up logically and intuitively.
Strike a balance between functionality and useability. Don't just throw an app out there that works great but looks like garbage. People like eye candy (men especially).
Like you said, multi-user is only realistic on the iPad and even then it's a stretch for anything other than games.
Think about what the user expects and is used to based on other apps and try to continue that trend. For instance, if you are showing the keyboard and there is no obvious way to dismiss the keyboard, make it so that when they tap on some area of the view outside of the keyboard, the keyboard gets dismissed. Otherwise, the user is just stuck there with this stupid keyboard on the screen and no logical way to get rid of it (sorry, I really hate when developers do this one).
Lastly, use the app yourself for at least a week prior to releasing it. If you aren't 100% behind it, change it. Some people are all about "failing first and fixing later" but I disagree. The most important day is the first day of launch. After that, it's either word of mouth, cross-promotion, or your advertising money. Make it a success on the first day.. and also realize that more people use the AppStore on Wednesday/Friday/Saturday/Sunday than any other days of the week.