Since iOS7 it's possible to block a caller when she/he calls your phone...
Is it possible to change this setting from within an app?
The idea is having an app that lets the user block people temporarily from calling them. Another option would be to send them directly to voicemail or send them a (predefined) text-message if they're calling.
I don't need code, just a hint whether this would be possible and which settings I'd have to change.
No, it's not possible from within app. Apple hasn't provided any such API. Check here
Related
How would I monitor the users Trash so that when a file is added I can send an action.
Thanks in advance!
A sandboxed application cannot access the Trash. Sandboxed applications are sandboxed for security reasons and in the Trash may be all kind of documents a user has deleted and that a sandboxed application would have never had access to in their former destination. Of course a user expects that those files are still save once they are put into the Trash.
If it really makes sense for your app to access the Trash, e.g. because it is a Trash Management app (stupid example, I know), Apple will still grant your application access to the Trash, if you only ask for it. Therefor you need to specify a Temporary Exception Entitlement, either of the type
com.apple.security.temporary-exception.files.home-relative-path.read-only
if read-only access is enough for you or
com.apple.security.temporary-exception.files.home-relative-path.read-write
if you also need write access. Those are the keys in the entitlement dictionary and the value is an array of strings, each string specifies a directory. In your case they array would contain /.Trash, which translates to /Users/<username>/.Trash for the current user. E.g.:
<key>com.apple.security.temporary-exception.files.home-relative-path.read-write</key>
<array>
<string>/.Trash</string>
</array>
This will allow your app to be partially freed from its sandbox, as long as it only accesses this directory (or its sub-directories).
Note that Apple will only approve an app that uses one of the Temporary Exception Entitlements under certain conditions which are listed on the App Store Connect webside (you must login to see that side and you need an Apple ID with permission to use App Store Connect).
AFAIK those conditions include that you must file a bug report with Apple's Feedback Assistant (again, you must log in to the webside, but this time every Apple ID is allowed to log in) and you must explain Apple why you need this exception as otherwise your app cannot do whatever it is supposed to do. You better be good at explaining that! If Apple doesn't consider your use case legitimate, they will close this bug as invalid and then your app submission will be rejected. If the bug is considered valid, you must tell Apple that your app uses a temporarily entitlement when you submit the App and you must point Apple to the bug report you have created. They will read it again and if the store team agrees with the development team that this is a valid reason, they will allow your submission to pass through.
Once your app has the appropriate entitlement, you should be able to monitor Trash the same way as a not sandboxed app can do so. E.g. using the FSEvent API. With the function FSEventStreamCreate() you can create a FSEventStreamRef that monitors a certain path (in your case the Trash), calls a user defined callback function whenever the contents at this path changes and can be scheduled on a RunLoop. Once scheduled, whenever the content of the directory changes, the callback function is called. In the callback function you may do whatever you want to do, e.g. to get a higher level event (since the callback function is only plain C, so you may want to post a NSNotification that you can handle in your Obj-C code, e.g. in your UI code) or maybe directly call an Obj-C method of some object (stored in the callback context, a global variable or which is accessible as a singleton, etc.)
My Windows 8 app needs to run a background task triggered by the receipt of raw notifications sent from Windows Phone 8 apps. Responding to that event to invoke a background task is apparently only allowed for lockscreen apps:
http://dotnet.dzone.com/articles/windows-store-app-development-10?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+zones%2Fdotnet+%28.NET+Zone%29
Normally, the user has control of whether they will allow an app to be a lockscreen app or not. In my case, though, it must be such or be basically braindead. So, can I enforce that: IOW, inform that users "Install this as a lockscreen app, or don't install it at all"?
What I mean is: assuming the user retains ultimate control, will letting them know that the app won't work well without them allowing it to be a lockscreen app cause it to fail certification?
You bet, that's how it's done.
Want to force them to allow it? Disable the "Block" button. (just kidding, you can't)
Remember, it's your app.
Check out how the Store app "supports" snap view. That's a nice example to show certification requirements can be "met" at the bare least implementation.
When you read the cert reqs. read them literally.
Responding to that event to invoke a background task is apparently only allowed for lockscreen apps:
Not exactly true. But anyway, the short answer to your question is no. And in reality, I can't see why the user would want to use your app, if it were to constantly do things in the background and thus drain their battery-life, for no good reason.
You might want to detail what your app actually will do, for more accurate advice.
No, only the user decides what is, or is not, on their lock screen. Because a user decides what is on the lock screen app list, apps preferably should provide a decent degraded experience if they are not on the lock screen. Messaging can be provided in the application to make the user aware of the degraded experience, but again, it is ultimately up to the user.
To answer your question "will it fail certification" no. You can programmatically request that the user promote your app to the lock screen when you run, but you should consider degrading gracefully if they don't. (E.g. register for a timer event to give your app some time to periodically update itself, or send a notification through WNS and handle it then.)
While it's great to assume that your users will want to run your app under the lock screen, providing a consistent, delightful experience under different conditions is what will set you apart.
I know that there are some restricted api's or code that are not allowed to be in your app when you submit it to the app store.
How do you know what they are? Is there a way to check your app before you submit it to ensure you have not used such api's?
It is probably better to avoid this problem at the design stage, than trying to fix it later, so I was wondering if there is any tool in Xcode, or document to determine this.
The way Apple intends for you to do this is to use XCode's Validation feature. When you're submitting an app, you build for achiving (or Archive from the XCode menu). Then, you open up Organizer to see the archive you just created. At this point, you can press the Validate button in Organizer. That will perform a validation, without actually submitting the app. It will tell you if you're using Private APIs. Depending on how you use them, it might identify what the violation is:
There's definitely ways that code can fool this validation step, and "get away" with using Private APIs until the reviewer looks at the bundle. But, as far as I know, those ways would all be intentional methods of hiding Private API usage, and it sounds like you're trying to discover accidental usage.
If you fail this Validation test, then you might want to use something like AppScanner, mentioned in alan duncan's answer. But, for completeness, I wanted to make sure people knew that this Validation step is available in XCode, and checking for Private API usage is one of the things it's doing before you submit (and have to wait a few days to be told what you did wrong). Also, even if you don't use the Validate button in Organizer, but just use Submit, the tool is performing a Validation for you. The only difference is whether the bundle actually gets uploaded to iTunes Connect.
If you stick to documented interfaces as suggested above, you're fine. The only issue is with third-party libraries whose implementation may be opaque to you.
There is a Mac app called AppScanner that scans from private API usage. I have no experience with it, though.
You will get more information on Apple approval process from
App Store Review Guidelines for iOS apps (You must be a registered iOS developer for accessing this data).
iOS Human Interface Guidlines.
get the private API list.
use class-dump to process the Mach-O file, and get the processed string.
use regex to get the interface, class, or method in the string.
match the API to private API list.
then GOT it~
I opened a porject to do this, but because the reason of my company, canceled. very sorry for this.
How can an application perform stuff when its actually closed like google+?
I notice that I got a notification from huddle chat from the google+ app for iOS. But google+ was actually not active, it was closed. Same situation with Whatsapp, I always get push messages both if the app is closed or active.
This kind of behaviour seems for me to be impossible to implement. From other questions I know that we cannot register some kind of background process. How do this apps handle that?
Can I still listen form something when my app is minimized?
When my app is just minimized but not closed I know that a certain method is called. Can I perform a repeating update task, e.g. read geo data?
The apps you mentioned use something called Push Notifications which work regardless of your App being open/in the background/closed. They are notifications sent to the device when an action happens and most of the processing is done on the Server (The notifications are not generated by the App itself. A server pushes the Notification on).
Apple has a fantastic section on Executing Code in the Background when your App is minimised which should provide most of the answers you need. It even has a dedicated section on explaining the Geo Data capture which should help you in this case.
Is it possible to load up another application when the first application enters the background?
Say I have application 1 and application 2 installed.
When application 1 enters the background, the method is called to invoke the loading of application 2, but application 2 is never loaded.
Is it possible that Apple have disallowed this sort of thing?
I am 100% sure that the custom URL schemes I'm using are able to be called as I have done testing within MobileSafari to make sure they work.
Should mention this is for an iPad application and not iPhone application. Albeit, I don't think there should be much difference between the two when it comes to this issue...
EDIT
Let me explain. The application itself is for a specific purpose. What we want to do is allow our clients to set a setting that will allow the application to "bounce" back via another installed application.
We want to limit the users of the application to only be able to use the application in question. This is due to the fact that the iPad's using this application will ONLY be using this application. Hence why we want to lock it down as best we can.
This will not work, simply because the application can only have the system open URL schemes while in the foreground. Think of it like this, if your application is not in the foreground can it, say, present a modal view such as a UIAlertView or a simple Modal View Controller?
Also, you would be horribly breaking Human Interface Guidelines and would most likely be rejected. URL schemes, especially custom ones, should only be called when the user prompts.
Sounds to me like you want a lockdown/kiosk iOS system. There's simply no way to do this and make it work like they want without breaking out of apple's sandbox. Jail breaking. Or, write one application with two halves. The initial half with authentication or whatever, then the secured half. Maybe we need more context, but as you describe it, URL schemes are incredibly easy to circumvent or fail altogether. What happens when they just delete the goto app?
Now why would you do that? Say the user is getting a call and he proceeds to take it. He definitely wouldn't want to go to another app in between. Other case considered, he would actually leave your app to go to another app he wants to attend to without being taken to another app in between.