I develop a well-looking professionally designed application, which loads events for some clubs at startup (it has more functionality, but all require network connection).
If there's no internet access, app shows "Error: No network access" message with OK button. It exits when user presses this button.
Will it be accepted in App Store? If no, what should I change?
Thanks! :)
This is an opinion question, but my experiences suggest:
It's OK that your app requires network access to provide meaningful content.
Do NOT forcibly terminate (exit) your app in this case, but instead show a helpful message, and keep polling the network status (ie use something like Reachability). If and when the network connectivity comes back, remove the message and proceed.
Bonus points: If you can cache data from when there is a connection, then you can run the app anyway showing the most recent data you have. This is generally preferable as a user experience to simply blocking access to the UI if you can't get to the internet.
Do not exit the application.
If your app work only if network is available, that's okay. But if network is not there, it would be better if you show an empty view with proper message (That for this app, network is needed or something like that. Add some error images or graphics it'll improve the user experience also). Don't forcefully close the app, it can be consider as a crash(Apple will reject your app).
Related
I've been developing iOS apps for enterprise use for several years now. It was an adjustment from having spent many (!) years developing desktop apps. One of the first things I learned very early on was that it is frowned upon for an app to kill itself. The posters in the Apple dev forum were downright hostile about it, which is a reason I never go there anymore.
Now I have an app that has very critical functions, and it requires that the user accept the terms and conditions before using the app, and that the app will not function if the terms have not been accepted. The choice is there to accept or to decline, but it seems like the best thing to do when the user actively declines is to kill the app entirely.
My question is, under those circumstances, would there be anything wrong with that? Will I be damned to developers hell for eternity?
You can change the interaction here.
Instead of accept (and use the app) or decline (and never be able to use the app) change it to accept (and use the app) or nothing.
If the user does not accept then they cannot use the app. They do not have to decline anything. Absence of acceptance is all you need.
If they don't accept then don't do anything. They can always come back later and accept and start using the app.
Why kill an app on a declying? I would rather just leave a user at the same screen with no actions before he puts acceptance checkbox, disabling all buttons
If you make the app kill itself, Apple won't let you post it on the App Store.
You should adjust your User Experience to the case of the user declining the terms and conditions.
For example, show a screen saying that the app can't be used unless terms are accepted, with a button saying "Take me back" that takes the user back to the terms screen.
If No Internet connection and I block UI with present one View controller with "Please check your Internet Connection" pop up then Can Apple reject my application for blocking UI?
I don't work at Apple, but I guess if an app requires an internet access to work properly, it is fine to block the UI until the user has an actual internet access.
Think about social network apps, if you just installed Facebook app, you would not be able to login upon first launch if you don't have an internet access.
However, blocking the UI seems a little bit strong and probably bad UX as well. Nevertheless, it should not prevent you from publishing your app to the App Store.
Vibha Singh,
Why block the UI ??? Blocking the UI is probably the worst user experience. Apple might not reject it (not sure as I never tried it before but certainly people will not appreciate it)
In case you have an app which you dont want to work when there is no internet then consider designing a screen which you will load which will have text saying "No internet connection try connecting your device to internet something like that"
Facebook, Twitter all the main stream app's follows the same approach rather then blocking UI
I have an in-app subscription product. When the app is loaded, I present a "subscribe now" screen to initiate the buy process. If the user cancels, the application MUST close/move to background/terminate since they have refused the service. What is the best method to use to do this?
This situation is addressed in the iOS Human Interface Guidelines, under "Don't Quit Programmatically":
Never quit an iOS application programmatically because people tend to interpret this as a crash. However, if external circumstances prevent your application from functioning as intended, you need to tell your users about the situation and explain what they can do about it. Depending on how severe the application malfunction is, you have two choices.
Display an attractive screen that describes the problem and suggests a correction. A screen provides feedback that reassures users that there’s nothing wrong with your application. It puts users in control, letting them decide whether they want to take corrective action and continue using your application or press the Home button and open a different application
For example, consider the iTunes Store or App Store apps, which are useless without a network connection. If you put your device in Airplane Mode and then launch either one, they will display a large Wi-Fi icon with a message saying an Internet connection is required. (I think an alert offers to disable Airplane Mode, but if you tap Cancel you'll see what I mean; the app will not quit.)
Be assured, if you simply force-quit the app, Apple will reject it.
I don't know if it's allowed.. but you can use
Exit(0);
OR:
[[NSThread mainThread] exit];
The application will close.
Best not to do that. You could just display another screen after they hit cancel explaining why they can't continue and give them a button to try again.
I've got a Blackberry app (5.0 and above) that I'm making changes to. One feature of the app launches an online banking function in a BrowserField2. I'm investigating a change to the app that would have the online banking function launch in the native browser, using this basic function:
Browser.getDefaultSession().displayPage(myBankingUrl);
The change is mostly motivated by performance -- the BrowserField2 seems a lot slower than the external browser.
My show-stoppper is this: in the existing implementation, I can detect when the BrowserField2 screen is shut down, and I can force the invocation of a logout call. The bank that's associated with the online banking function really really cares about this. I have not yet found any way to hook in to the shutdown of the external browser to port over this piece of functionality. Has anyone tried something like this?
There is no API to detect that. You can listen when your app is activated - if you open browser your app screen is second in stack and becomes first when user closes first. But there is no garante that user will close browser or move to another app (to view incoming sms for example).
I would suggest you to continue with BrowserField2 for 5.0+.
The browser on a BlackBerry is always running. It provides the default push service reception and other required services.
I'm working on an iPhone application that makes a few calls to web services. I posted this application on the Apple store but it got rejected (and rightly so) since there was no error message displayed to the user if no Internet connection is available. Since obviously the application would not work without it.
So I just wanted to know how to best achieve this? I'm guessing something needs to go in the viewDidLoad method that will throw an alert box saying something like "You need an Internet connection to use this application".
Any ideas would be appreciated.
If your application must have network access the easiest way is to add the following settings to your info.plist as boolean values.
SBUsesNetwork - Ensure the device has an active connection (Edit: not applicable, this seems to be a private API someone found at some point. It is not in Apple's developer documentation.)
UIRequiresPersistentWiFi - Ensures the device is connected via WiFi
If your choice is not true then the user will be presented with an appropriate message when starting your application. Best of all this message is from the OS and thus is localized.
If your application cannot download data from a website while running (loss of signal, site down) you should still warn the user though and not just spin indefinitely.
Apple Developer Connection has a sample application (Reachability) that uses the System Configuration framework to determine network status. It will tell you whether you have a WiFi, EDGE/3G or no Internet connection.
You would use portions of this code in your application to determine network state, and then provide interface cues if no connection is available, such as a UIAlertView.
Cautionary word: beware SBUsesNetwork. I would personally love to know where SBUsesNetwork originally came from, because it's not mentioned anywhere in Apple's docs that I can find. When I add the key to my app's plist (as a boolean) and set to true, it doesn't seem to affect the behaviour of my app -- I get no warning about airplane mode, whether starting app completely afresh, or foregrounding a previous launch that was backgrounded.
My app has UIRequiresPersistentWifi set to true, which appears to also do the job people claim SBUsesNetwork does (plus other things!).
(I'm running iOS4.2.1 on an iPhone 4, XCode 3.2.5 64 bit).