I have an app that styles the user's photo, then saves and/or uploads to Facebook, etc..
My users have asked if they could save/upload to several services with one button click. So I've implemented a dialog that lets them choose which services to upload, and once you press the button, it uploads to each service, one at a time.
My worry is that if the user selects, say, 4 services and has a full res photo, it could take quite a bit of time for all that data to go up the wi-fi pipe, much less 3G.
Is there anything I should do besides put up a UIActivityIndicator and tell the user where his photo is going...and WAIT? It just bothers me that they could sit there for a long time, waiting for the network gods...
Any thoughts?
Thanks!
Make the upload asynchronous and backgrounded (using whatever 3rd party library you're using--wait you're not trying to do this with AFNetworking or something, are you??) and then use the Task Completion API to ensure the upload completes successfully even if they leave the app.
I'd go ahead and scale down the image some, too. If they're going to be looking at it on a website, there's no need for it to be full multi-megabyte.
It wouldn't hurt to add a display string that says "Uploading to Facebook...." then change it to "Uploading to Flickr...." etc. You'd be surprised at how faster your app seems if you let the user know that something is going on. (You could also use a progress indicator as well.)
Related
I have an application that runs in the background, I need it to pseudo randomly take a picture using the forward facing camera and send that to a database.
A possible solution I thought of was to use URL schemes to open another application, which will take the picture and send it, then use another URL scheme to open the background application back up. Does anyone know if this is possible?
Or perhaps there is a better solution.
It is not possible for an iOS application in the background to initialize, utilize, or grab photos from the camera hardware, let alone store or upload them to a local database.
Not only is this a security risk, but it poses a potential privacy invasion, and is just plain creepy. Besides, background apps only stay alive for 10 minutes or so, so even if this activity were possible, sustaining it would be impossible.
However, it is possible to use the camera directly from an active app without having to delegate the task to another application (perhaps you are thinking a little too much like an Android developer :p). Take a look at UIImagePickerController.
There's a very limited set of actions background applications can do—GPS, audio, phone & VOIP calls, and a couple of others. Accessing the camera is not one of those allowed actions, so you can't take a picture in the background.
As an alternative, you could set up a notification system to alert the user that it's time to take a picture (for whatever reason), and if they choose to open the app it could do your required actions then.
As you may have seen in some apps an alert pops up asking the user to rate the app in itunes and usually the alternatives you get to choose from is something like: Sure which opens the rate page for the app. The second option is No Thanks which closes the alert and the third option usually is maybe later which displays the alert later.
I was wondering how to do this.
I want the alert to be displayed after say the app has launched 20 times if that would be possible.
And how can I create an maybe later alternative which displays the alert maybe 15 launches of the app later?
And a final question is there a special link for the apps rate page? So when you click the sure button or whatever it will take your directly to the rate page.
I've used this: https://github.com/arashpayan/appirater. You can look at my fork as well for a specific mod I needed.
[EDIT: comment re NSUserDefaults]
I suggested this link because it is a full, working implementation of what you describe that is easily integrated into existing apps. I've used (and modified) it myself. NSUserDefaults is a general purpose mechanism for persisting app state. I agree with the others that it's a very useful thing to learn and use, it's just not a full answer to your question. If you choose to roll your own implementation of a rating system (nothing wrong with that) you will most likely use NSUserDefaults to store the relevant info.
Check out my answer for this similar question. I provide two different links you can use for taking the user to the "rate this app" screen in the App Store.
Direct "rate in iTunes" link in my app?
You can use NSUserDefaults to save the launch count (increment it in application:didFinishLaunchingWithOptions:), then save the user's choice another preference key. If the user says later, you could reset the counter back to zero.
I don't think there is a special rating link, but you can link to your app's specific App Store page. This was incorrect, as TomSwift points out; see Direct "rate in iTunes" link in my app?
I wrote a library for doing this with minimal effort on your part:
https://github.com/nicklockwood/iRate
I'd recommend using a library rather than rolling your own solution. It may seem like a simple problem but the library takes care of a whole bunch of extra stuff, like ensuring that the user is prompted for each new installed version, that they are reminded after a certain time if they decline, that they aren't prompted to go to the app store unless they have a network connection, etc.
The docs don't seem to offer any guarantees - I'm just wondering if anyone's had any experience of uploading a large amount data after a user 'backgrounds' an iPhone app.
E.g., recording some audio or video and uploading it while there's the possibility that the user will start another app. Is is reasonable to expect to be able to be able to upload several MB of data in the background, perhaps using the VOPI UIBackgroundMode, which should keep sockets active?
First, uploading anything that is not VoIP data in a VoIP background mode violates Apple's guidelines and will probably get your app rejected. But you still have the option of using the normal background task completion API that gives your app another 10 minutes (at the moment, the amount might change in a future release) to finish a task like an upload.
If a foreground app uses a large amount of bandwidth, it is likely that the OS will give it priority over the background task.
Of course, you cannot rely on your upload being finished. If you run out of time, the system will notify you and you should try to resume the upload when the user reactivates your app. But you can't rely on a stable internet connection anyway, even if your app is in the foreground, so I don't really see the difference.
NO, this is not possible. i agree that it creates problems when you have a long operation to make but it is defiantly not possible.
I'm creating an app which connects to server and sends some text.
If network (both wifi or 3g) is there, it will immediately send the text to server.
But if there is no network, it keeps on polling for server connection every 5 minutes.
All this part is working fine.
But when using iPhone 4 device, i want the app to check for server connection even when app goes into background. So, when app goes to background and when network comes back, it must be able to send the text to server.
How can I achieve it? I've seen some apps where they say that the app will upload photos to server even in background. How will they do it?
I suggest you read this article from Apple carefully, especially the Completing a Finite Length Task in the Background section.
http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/BackgroundExecution/BackgroundExecution.html
Something to clarify:
Once your app is in the background and is frozen by the OS, there would be no way for your app by it self to wake up and re-connect to the internet.
However, according to the article above from Apple, you can call this beginBackgroundTaskWithExpirationHandler method from your app's delegate to apply for additional time when put in the background, which is to say, though your app cannot wake up by it self when in background, it can, when in the background and not frozen, try to apply for additional time to finish its lengthy task.
Hope it helps.
There is a trick that I think flayvr is using.
If you download and use the app, you will see that they require you to enable your location.
And why is that?
because they want like you to do something in the background even when the app is terminated (they creating an album out of your newly captured photos), and how do they do that?
They use the significant location change, where when someone is traveling some significant distance (something like 500m) each app that registered for significant location change will get awaken for a limited amount of time to perform some quick task and will be terminated in a few seconds.
So your app can register to that event also and when the event of significant location change fired you will be able to send the text to server (quickly).
Hope that helps.
Until now you can do that on iOS7 with Background Fetch.
Take a look at this article.
However you only have up to 30s to get the task done.
According to the article above, there's also another solution called Background transfer service.
If more time is required though, then the Background Transfer Service
API can be used
Create a new project in Xcode and you will see there are bunch of new methods auto generated in app delegate file. like applicationDidEnterBackground, applicationWillEnterForeground etc.
read the description you have to call your thread to upload data on server here.
What is the proper way of ending an application on the iPhone when you are finished with it?
thanks,
anton
Jaanus is referring to this paragraph in the Apple iPhone Human Interface Guidelines
Stopping
People quit an iPhone application by opening a different application. In particular, note that people don’t tap an application close button or choose Quit from a menu. In iOS 4.0 and later, and on certain devices, the quitting application moves to a suspended state in the background. All iPhone applications should:
Be prepared to quit at any time. Therefore, save user data as soon as possible and as often as reasonable.
Save the current state when stopping, at the finest level of detail possible. For example, if your application displays scrolling data, save the current scroll position.
iPhone applications should never quit programmatically because doing so looks like a crash to the user. There may be times, however, when external circumstances prevent your application from functioning as intended. The best way to handle this is to display an attractive screen that describes the problem and suggests how users can correct it. This helps users in two ways:
It 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
If certain circumstances prevent only some of your application's features from working, you can display either a screen or an alert when users activate the feature. Although an alert doesn't allow much flexibility in design, it can be a good choice if you can:
Describe the situation very succinctly
Supply a button that performs a corrective action
Display the alert only when users try to access the feature that isn’t functioning
As with all alerts, the less users see them, the more effective they are. For more information about creating alerts, see “Using Alerts.”
There is no way for an iPhone application to quit/terminate itself. Apple actively advises against it in their Human Interface and/or programming guides (can't remember which exactly) because it would look like a crash to the user.
An app should not terminate by itself.
Also, avoid showing an "exit screen" that prompts the user to quit the app manually as in iOS4, the app might stay open in the background and your user would be stuck in that exit state.