I want to get information about blocked and dropped calls. When you call someone through your phone, sometimes your call get blocked or dropped, then you hear a message, "Please try again". I want to access that information in my app. Is it possible in iPhone? Maybe for jailbroken devices?
Call information is not available to apps on stock OS iOS devices, due to security sandboxing.
The decision to play a "please try again" recording is (generally) made by a device called a Service Control Point in the telephone network. From the phone's perspective, a "please try again" recording looks the same as a successfully completed call: The network doesn't tell your phone that it routed the call to secondary treatment, so there's no data stored on the phone that you could collect or analyze.
When your iPhone displays a "Call Failed" message and a "Try Again" button, the point of failure is closer to you – usually it means your phone lost contact with the cellular base station – and the phone does log that the call didn't go through. Apparently it's possible to access the iPhone's call history database without using private APIs, so in theory you could use this in your app (if Apple approves).
Related
In my application , i works with web-services and when user log in into my app my app is sending a request with status 1 means loged in and when on log out button click sending a request with status 0.
Now problem is , when user removes app from devices , status in my server is remain 1(log in) , hence other user can see him available while his app is not in device. so is there any way by which i can send request when my app removes from device (i don't think it is possible) or is there any other way that i can do in my backend side ?
Thanks in advance.
It is not possible to call a web service when the user deleting the app from an ios device. There are three methods to came to know that whether your application is there in user's ios device. But there are few limitations also.
Activate Push notification: By doing this, device will get registered with Apple's push notification service. When user delete the app from device, the registration will be revoked from APNS server and through the APNS feedback service, you can get to know whether the application is existing. (Limitation: If the user did not agree with receiving push notifications, then the app will not be registered with APNS and you never came to know that whether application is existing or not)
Activate Location Based service: If your application enables location based service, then your application will get periodic location updates in a location delegate method. In this delegate, you can call a webservice and keep update the status of user even the application is in background. (Limitation: If user disables the location update, then your server will not get info about user status)
Periodically Call a Webservice From you app: This is possible only if your app is active. (Limitation: When you application pushed in to background, your application will be in suspended mode, so it will not possible to call webservice)
Sorry Unfortunately Apple not provide any method that user Uninstall app from user's device, There is no such method.
When user delete any application device does give the alert "Do you want to delete this application" with option "Delete" and "Cancel". You don't have to write any specific code for this.
I just assume that There is one method in which you can find out when user is about to delete your app. That is you need to implement push notification Apple server will inform you when you try to push to an uninstalled instance. Other than that there's no way to detect it but i am not sure its helpful or not.
You can't do this from within the app. You would want to do something like have a periodic task which runs on the backend, checking the last activity date of logged in users and setting them to 'not available' after some configured period of inactivity. This will probably require some changes to the backend to record last activity date and a change to the app so that while it's open it sends a periodic 'heartbeat' to the backend. You probably want to make the timeout quite big (say 15 minutes, big enough to not have a large impact on performance).
So all the documentation and posts I see about auto-renew subscription are using the server side model to deliver products. Is there a particular reason why one couldn't use the Built-in model.
I am creating a audio player app that will provide new original music every month. With service side verification I understand that it checks to see if the receipt is valid before allowing the user to download the audios from my server.
However, couldn't I just program my app to ping the app store to see if their subscription is active. If their subscription isn't active have the app sit on the home screen saying "Please renew your subscription before regaining access to the audio player"
It's my understanding that the server side model is there to prevent pirates from gaining access to my servers resources. Is there any other reason I should use it?
It depends on whether you want your application to be hacked or not.
Main reason for all the validation routine is that once application is available to user, he can modify it in any way he likes which can be seen on all the hacked iPhone apps out there.
So in your case they would delete all checks from your code and set "active" to true.
We are developing an iPhone application that allow users to send messages to others via Apple Push Notification Service when the target user have installed our application or SMS when haven't.
We want to get notified immediately when our app is uninstalled so that we can decide how to send the message to the target user.
We find the APNS feedback server have a long time delay that doesn't agree with our requirement. So we use another way: when our server recorded the target user have installed our application, we send him message via APNS, if he haven't read the message in 30 minutes, we believe that he has uninstalled the application, so we send the message via SMS.
Is there any way better?
As Oleg said, there is no way to accurately detect if your app was uninstalled.
The APNS feedback service returns a timestamp and a push token for messages it was not able to deliver. Sometimes, this indicates an uninstallation but it can also simply indicate a user that was simply offline at that moment. The Feedback service does have some lag so can not be used for time-sensitive intel gathering.
Based on your requirements, I'd say you're doing it right.
One suggestion that may or may not work for you would be to include a link (via url handler) to your app when you resort to sending an SMS. If it makes sense for the user to return to your app, clicking on that link should launch the app and you'll have a trace on your server if you make a simple call. If, however, after sending the SMS the user is not detected as coming back into the app, chances are highly likely that the app was indeed uninstalled or that the user is offline for an unusually long amount of time which may require some other type of action on your part.
Currently I am developing an authentication module for my application. The user provides his phone number and a SMS with some pin code is send to him.
The user enters the code and if it is valid his phone number is authenticated. Maybe you know WhatsApp, it does quite the same when you run the app first time.
However if the user puts a new sim card in his phone he should authenticate it again.
I want to know how to determine if phone number has changed. I read in some other question that it is not possible to determine the phone number itself. But e.g. WhatsApp recognizes that there is another phone number.
Any ideas?
Update 2
One (not the best) way it's detecting carrier changing. Here you can see how to get carrier's name. Save it at first launch and do compare on next launches.
Update 3
I'd recommend to you look at Core Telephony Network reference and especially at CTTelephonyNetworkInfo reference
subscriberCellularProviderDidUpdateNotifier allow you respond on events such like:
... when the user’s cellular provider information changes. This occurs, for example, if a user
swaps the device’s SIM card with one
from another provider, while your
application is running
I observed in a Hotel I am that when other apps trying to access the internet a pop-up appears that ask the iPhone user to enter the user id and password of the Hotel's Wireless LAN. I guess it is some kind of redirect on all requests to protect misuse of the WLAN.
I have an app and it does use the NSURLConnection but I am not getting the pop-up instead it goes via the regular data network of the carrier. I removed the SIM to see what happens then and then the connection fails with an error "The Internet connection appears to be offline".
I wonder whether this is because the NSURLConnection does not provide such a pop-up and this other apps (e.g. Safari, e.g. WhatsApp) use a different API. One the other hand I thought that might be what the documentation says is the "Authorization Challenge". I have implemented those delegate methods but they are not called.
If someone with some experience on this can help me.
Search the documentation for the UIRequiresPersistentWiFi Info.plist key - there are some tradeoffs (users will get an alert every time they open your application if their phone is in Airplane Mode - doesn't seem to be any way to turn that off) but that should force it to make the connection.