I made Radio Streaming Iphone App.
And submit to itunes app stroe.
But they rejected my app.
This is the reason.
2.2: Apps that exhibit bugs will be rejected
When the user taps on a radio, an alert is displayed stating the connection is lost
and no further action can be produced.
Yes, If the connection failed, I let the connection bad message appear to screen.
But they demand that there should be further action.
Do you think What further action is needed?
Did you use Wunder Radio or Tunein Radio? These app did same action if the connection failed.
Only shows connection error messase.
What should I do?
Your best bet here is to produce better user experience when connection is lost, has failed or was interrupted. I mean you should implement a mechanism visible to user that tries to reestablish connection with your streaming server based on network condition changes.
Also it would be good if you allow your users to trigger that action from the alert view you mentioned, e.g. "Connection is lost. Would you like to retry" + no/yes.
A good place to start with is adding Reachability to your project (Apple has demo code which uses it).
Related
I'm developing a chat-app for iOS that must use an existing server API. The way it works is pretty straightforward: the app checks every given interval whether there are new messages on the server and displays them, plus, it sends the server new messages that the user typed.
When the user starts 'multi-tasking' or presses the home button, my app will go to the background and therefore will not be able to check the server for new messages. The server will automatically assume that the user stopped the chat when a certain timeout has been reached.
Often, the user isn't aware of the fact that when the app is put to the background, it is unable to maintain the connection to the server and will stop the chat. I'm looking for a method that will notify the user of this behavior as soon as the app is put to the background.
My current idea is to notify the user when applicationWillResignActive and/or applicationDidEnterBackground is fired, but I wouldn't know in what way. Can it be done in a way that complies with Apple's guidelines?
I'm aware of the fact that the best solution would be a different overall design of the software (e.g., using push notifications and no server-side chat termination by timeouts), but in this case I can't change that.
I would continue running in the background and set an expiration handler block (called by the os when you app is REALLY killed) and there schedule a UILocalNotification
use
- (UIBackgroundTaskIdentifier)beginBackgroundTaskWithExpirationHandler:(void (^)(void))handler
I'm working on a iOS app where the user is fetching a reasonably sized database online, and then working with it offline. The update, and sync is taking around 10-15 minutes due to the memory constraints on the device and the way I'm handling the transactional inserts. All the while I have a dialog view open notifying the user of the progress, and give him the option of cancelling and reverting the changes to the database.
Anyway, today while testing I noticed that the iTunes app was trying to contact as server and do some background work, but threw an error:
itunesstored[68] <Warning>: Could not load download manifest with underlying error:
Error Domain=NSURLErrorDomain Code=-1001 "Cannot connect
to 112.168.198.2" UserInfo=0x1f8d6150
{NSLocalizedDescription=Cannot connect to 112.168.198.2}
This caused a dialog to display on top of the one I was already displaying, notifying the user that iTunes was unable to connect.
Now when I clicked the 'close' button, that somehow also closed my dialog, causing only parts of the actions, to be taken when the user decides to stop the update, to take place. The async update kept on going in the background, while the database tried to revert the changes causing the database to lock up and I needed to kill the process and restart the app and update. By design, that reverts everything if something terrible like this happens.
Now I noticed that I should make some changes in my code to make it harder for the database to lock up like that, and I'm working on that.
But what I want to know is: is it possible to forbid iTunes, or any other process for that matter, to do any work on the UI thread while a certain critical process in your app is taking place?
The behavior of the iTunes dialog cancel button, i.e propagating down into my dialog can't be considered normal or reasonable.
No, this is not possible. Apps should be coded in a way that accounts for these kind of interruptions. For instance, on an iPhone, what happens if a telephone call comes in? It's the apps responsibility to deal with it; the system will let the call come through irrespective of your "critical process".
In general, it sounds like your app isn't designed in the best way. For instance, 10 minutes to parse a database seems extremely long — how many records does this database have? You should be able to import databases with 100,000 records in a couple of seconds on the iPhone.
I have an iPhone app that uses ASIHTTPRequest to transmit data input by the user to a remote MySQL database via a PHP webservice layer. This works perfectly.
If the user presses the submit button the data should be sent regardless...the problem arises when there is insufficient bandwidth...rather than displaying some uialert to inform the user, I would like to implement some kind of function that constantly 'sniffs' for an internet connection even when the app isn't running (in main view) that ensures that the user only has to press 'submit' once.
How is this possible? Has anyone come across any tutorials/examples of anything similar?
Check out this example application from Apple: Reachability
It'll help you with some code to detect when the connection has changed.
Here's a link about backgrounding tasks. As you'll read, you can request additional time to complete a task, but it won't wait an infinite amount of time until it's complete. Background Tasks
Use the Reachability API in conjunction with a flag of some sort that will perform the desired action once it detects that a connection is available.
I have a app from where i hit different REST urls. one of the service is login service.
Now, do i have to use the apple rechability test everytime i want to make a connection?
I use ASIHttpRequest
No, ASIHTTPRequest will return a timeout error / a connection failure error if it can't reach the host. You can use those errors to show something to the user to tell them their login has failed.
The connectivity status of your mobile device can change very often and unforeseeably, so checking it often is advisable.
Say, for example, that you check at app startup, and find that not network is available. You go to offline mode, but then in a few minutes you could get in a WI-FI area or your 3G signal might be stronger. If you don't check it again, you lose the possibility of going to online mode.
Indeed, checking for network availability is pretty fast compared to how long a network request lasts (say: sending a login request and waiting for the response), so you can safely do the check whenever you need it according to your policy, be it at each request, every 5 minutes, or whatever.
EDIT:
about your concern as to the approval process: you should ensure that your app has a reasonable behavior when no connection it available. Simply showing an alert to the user (and not crashing) is enough for Apple, but you could also resort to disabling all your network related buttons, or whatever fits your app. The idea is that your app should not behave crazily when no connection is available.
If you want more advanced behavior, you can check reachability with each request.
You can also use the Reachability notification service (ASIHTTP-bundled Reachability includes that feature). You can find an how-to here. But in my opinion is a bit easier to just do the check when you need it. YMMV
From what I remember the reachability demo code is effectively a listener so can update a variable as the device's reachability state changes. You then need to check this variable before making a request.
Would be surprised ASIHTTP doesn't do this kind of thing already.
I am building a video streaming app that allows users to create playlists and has content that updates quite regularly. It has 4 main views, each with a list of videos, the content of which is loaded as xml when the view is loaded and cached for a period of time (not when the app is loaded)
So basically at any time on any view the app requires a valid internet connection.
I have set the 'Application uses wifi' to YES in the plist.
I have tested the reachability example code as seen in this excellent answer How to check for an active Internet connection on iOS or OSX? and added it to each of my views viewDidLoad methods.
My question is how often and where should I implement this? am I right in including it in each views viewDidLoad or should I create some other class that I can call on more often?
Many thanks
You do not need to check continually the connection. You must check just before initiating an operation that requires a working connection. So, you do not check in viewDidLoad, or in another class.
You are in charge of reporting to your users that the connection is not available if this is the case. Before starting an operation requiring the connection to the Internet, you do the check. If the connection is not available notify immediately the users.
It may happen that the connection is available when you do the check but becomes unavailable later, during the operation. You must be careful here to include in your code a check for this. When you lose the connection, again you need to notify the users.