I am using a third party framework, which in rare cases does not respond anymore, if the internet connection is lost. My tests showed that when I am connected via WiFi on my home network and I start using the app and when the network changes from WiFi to the carrier network, the thread does not respond, if it was exchanging data at that very moment.
Of course I got in touch with the vendor of the framework to fix this, however, it will take some time, until I will get the patch.
In the meantime I would like to implement a work-around, so the user does not have to deal with a non-responding app, especially as this is a no-go for the app approval.
My question: Is there a way I can monitor such a thread and terminate it after a timeout?
Or would anyone have another solution approach for this issue? I know about the reachability framework of Apple, but as far as I understand the framework, it is a detection tool only, which in my case would not solve my issue, right?
Thanks, René
Related
I'm working on a Voice over IP (VoIP) application using the SIP protocol which requires the application to be listening to incoming calls. This means the application must not sleep or die.
For old code, it seems the way to do this is to acquire a PARTIAL_WAKE_LOCK.
Now from Android 6.0 and higher, there's the new Doze. It is recommended that, if you don't want your app to go to standby, you should "whitelist" it by requesting the REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission. This is specifically for VoIP applications according to the documentation.
These two different things seem to be related. I'm not sure how they are related, if they interfere with each other, if I should use one or the other or both, and if there are other considerations. Please explain.
Also, I am not allowed to use Push Notifications on this project. If you have other advice for saving the battery please let me know.
In your case looks like you should be asking for whitelist, as the documentation you linked, it advises that GCM can collide with the SIP protocol. I would handle this case like a typical runtime permission. On some place of your app(the on create of your main screen for ex) ask for whitelist and the reason why you need it, if they dont want just disable functionality related to receive calls.
You should only use one of them at a time, you can always do it the hard way and handle the voip calls without sip, then you could handle incoming calls with push notifications from your server, but i dont think someone is up to that unless you need a top tier product.
There is no workaround for this, indeed the only good way is to do the heavy lifting by yourself, because its kinda popular on users to use battery optimizators / improved doze apps so you could get killed anyway.
I want to build an app that can communicate to some external third party hardware. I come to know that External Accessory framework can help me out in that, but I have few confusions……
Do I need to register ‘Made For iPod’ program before I start?
Do I need the third party hardware before I start, or I can start without hardware?
Is there any alternative to test the app, if the hardware is not currently available?
You could do that. But they don't approve everyone who registers like in the iOS program. It takes (in my experience) a lot of time and they have requirements that not everybody can met. You don't need to apply if the hardware is ready. The MFI program is for hardware developers. If you don't make hardware I wouldn't even try to get into MFI. It's a waste of time and money.
If you write an official app for the accessory, the company that makes it should give you a prototype so you can get started ASAP.
I would highly suggest to get the hardware. And if this is the first accessory project for you and the company then I would consider to go there and start writing the basic code on site, where you can get your hands on the developer.
The communication works with streams. I never tried it but I think you could write the whole protocol specific communication with network connections and then replace the networking stuff with the EASession once you have the hardware.
If you want to test the External Accessory framework you should have a look at EADemo. I never tried (and I don't have a accessory near me to test) but I think this should work with all accessories. But in my opinion everything EA Framework related is the easy part of the whole process.
Summary: Get the hardware. If you'll get the hardware in two weeks do the User Interface part now. If you can't get your hands on the accessory within two weeks you should beg for a prototype.
Regarding your comment to the other question: Test equipment is available when you are a member of MfI.
If you want legitimately produce and certify your third party hardware, you will need to apply for 'Made For iPod’ program. You will get and API and documentation to do that.
Unfortunately your chances to be approved are very low.
used this website for the long time to find answers, now need to ask on myself! :)
I have implemented multi player for my game using GKSession and client/server approach, not using peer picker (up to 4 player allowed).
I have one big problem which I can't find solution for.
If you disconnect/reconnect server peer quickly enough, client peer will "remember" that host and will show it in the list of all available peers permanently, only turning wifi/bluetooth off resets this.
So if I do this 5 times in a row, my client will show 5 available hosts with the same name!
Anyone had experience with this? Any idea of workarounds?
I should note that requirements for my game is iPhone SDK 3.0 for Bluetooth and 3.1 for Wifi as GKSession supports both now.
I have a similar problem. In fact I event get peers listed who are not even currently playing the game. Even more so, peers who are not acting as server are listed. I am wondering if there is some behind the scenes caching going on.
I'm thinking about implementing some kind of timer with visual feedback to show the disconnect progress, ideally to prevent this situation. It seems like in general there is a bit of time delay involved with connecting/available and disconnecting/unavailable. It might be better to code the interface to take these time delays into consideration, though I'm not sure exactly how.
I am trying to determine feasibility of certain features required in a (potential) project. I am not (yet) looking for a how-to, just a can-do. I apologize for any vagueness and ignorance: the former due to an NDA that makes Apple's NDA look like GPL, and the latter due to the fact that I have no iPhone or MAC experience.
I do have a solid understanding of objective-c and interface builder (going back to NextStep) and some PDA development experience, so I'll probably understand the answers, even if my questions are naive. I have done a bit of browsing, so I know some buzzwords.
I can't go into detail about the actual project, but I have come up with a lame analogy.
a large number of users in the same room are asked to complete task(s) in the app (say a puzzle)
they are under supervision, but the monitor cannot watch them all closely
they are not allowed to leave the application until done.
they cannot send/receive phone calls or messages during the task.
the monitor receives notification of various steps during the task
the monitor is notified when the task is completed, or the app is exited
the app sends a heartbeat, so the monitor also knows if signal is lost
Jailbreak is not an option.
The app should also work on iPod Touch.
So the things I need to do that seem dicey to me are
can I turn off (or require the user to turn off) phone and sms but still be able send http to my server
can I prevent an app from being switched out (even if, say an alarm app triggers or the phone rings).
failing prevention, can I at least detect any of these events and notify my server.
failing notification, can I record the event for the monitor to check later.
The user will be aware (and in fact welcome) these restrictions. It's a trust issue - the user must not seek help or use a helper app to solve the puzzle, and wants the monitor (and other contestants) to know that he did not. It's feasible for the user to click on an "OK, I understand and approve" screen at the beginning, but not for each communication to the server.
The app would only communicate with a central server (run by my company) - the monitor would not be able to buy the server software, and the url's of the server would not be user (or monitor) modifiable.
Hey! This looks like an app for taking exams. Not what I am doing, but that would be cool too!
EDIT --
I changed the title and am adding a few more parts to the question, based in part on mmc's answer. The App may run in an offline mode that would have to do the following:
So using the exam analogy, the user off line experience would be something like this
Launch App
App download test questions, registers start time, etc.
Turn off phone (if app can't do it by itself)
Disable any app that might interrupt my App (can app do this?)
Resume and Take Test
Indicate test done (or finish last problem).
Turn on phone (if app can't) and restart App (if needed).
App uploads test results and log of any interruptions.
So the question becomes
Am I sure that I at least get to log any interruption I can't prevent
can I know the cause of the interruption (phone answered, alarm launch, user initiated)?
can the user be prevented from modifying the log
can I know what other Apps are running when I start? (to guard against a daemon that occasionally displays a hint or something.
I would still like to run with real time uploads, so a few other ideas come to mind.
If I can reliably detect and record that the phone or another app was used, that might be almost as good as preventing it.
Can the user prevent the phone from ringing even if it's on (eg. call forward + ringer off)
Can my app know if the ringer is off
Same question for sms messaging
If I can't block it, can the user just ignore (silent) call or message and not leave my App. Would my app know that?
Sounds like you might be better off doing away with the phone, and making it exclusive to the iPod Touch.
You've nailed your trouble spots.
There is no way to disable phone functionality, and at the same time maintain network functionality of any type (3G, WiFi, or bluetooth) If you disable the phone operations with Airplane mode, all of them are disabled.
There is no way to prevent the Home button from returning you to Springboard
You can notify a server of a premature app interruption (there is an applicationWillTerminate: method on your app delegate) but is not reliable. If the operation takes too long, your app will be forcibly terminated.
You could write to the local file system that a premature interruption happened, and this would be far more reliable, as this operation would be much faster.
does the code for checking network availability works well with 3g.(provided it works fine with wifi and 2g). Whether i should send the message to the destination and then show the error or first check for network availability.
I don't have experience from the iPhone, but in general detecting network presence is hard. It can change within a very short time since you last tested it, so any result from the test will still be unreliable.
I would suggest trying to send the data, if it's something you (or the user) want to send out anyway, there is no loss in trying. It's better to try, and get a failure from e.g. TCP (having done retries automatically as usual), than to decide at a single moment that sending is impossible.
I would suggest reading through this best practices guide, and then studying the Reachability example source code. That is the "apple prescribed" approach.