Usually on a long press of a third-party application icon, it will give you the option to delete the app. Is there any way to disable that option, the way it seems to be with the preloaded applications on iPhone?
It's not possible to do it from within the app.
You could, however, configure the parental settings on the device to disallow removing applications (Settings -> General -> Restrictions), but you would need to do it on each device you want the feature enabled, and the setting will apply for all third party apps, not only yours.
Nope, you can't disable it. If you're developing some enterprise application where the iPad is supposed to run only your app and nothing else, I suggest getting a case or something along those lines to block the "home" button on the iPad.
Related
I was using the intent with android.provider.Settings.ACTION_SETTINGS to show the system settings screen from inside my app, to allow the user to configure certain details, like a bluetooth keyboard or adjust the timezone. This was working very well in the DP5.1.
But now in the DP6, the intent
startActivityForResult(new Intent(android.provider.Settings.ACTION_SETTINGS), 0);
Does not work anymore. No exception is logged in the console.
Any workaround on this?
THe option to install the apk after configuring the device with the IOT_LAUNCHER screen is not very practical for me. Because I want to deliver an image with a bundle, and my app will be started automatically, not allowing the user to see the IOT_LAUUNCHER screen.
Thanks.
In DP6 the Settings application is either deprecated or removed. APIs to modify the screen or time have been added.
I am developing an iOS app using Xamarin.iOS that should only be triggered by tapping on a URL. Because of this, I would like to prevent the app icon from being placed on the home screen. The reason is, the app will not function properly if they open it from the home screen (it needs some of the data in the URL to load properly). I would prefer to prevent the app from being on the home screen instead of checking whether a link was tapped or not. I know that is possible to do this in Android using the manifest, is this also possible in iOS?
This is not possible whatsoever; the developer has no control as to the placement and visibility of the application, and as such will always be visible on the springboard/home screen.
The best option you have is to show information to the user that explains why opening it from the home screen will not work, if they launch it that way. Most likely though, this will be rejected from the App Store as having no useful purpose. The guidelines are found here (App Store Guidelines), and I think this is what may cause a rejection (emphasis mine):
If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store.
I'm not finding the documentation I was looking for, but, as far as I know, this is not possible in iOS.
You could maybe have a default url that the app launches with and then use deep linking to launch the app with a custom urls. There are lots of great tutorials on deep linking (launching your app through a url) like
This one or maybe this one
Are there any classes or frameworks out there that allow my app to access and modify iPhone settings of the device used to visit my app? I know there's plenty of apps out there which (for example) can change the screen brightness of the device, so I was wondering if it's also possible to modify other settings you can manage in the Settings app on your device (i.e. automatic device lock, time and date, etc.).
No this can't be done... What you can do is to open the settings and that's it. Apple does not allow you to change anything outside your application.
I'm fairly new to iOS development and I am porting an Android app to iOS 7. The Android app provides a screen that allows the user to change a number of non persistent settings. Because these are not saved, it doesn't seem appropriate to me to expose them, on iOS, as preferences via a settings bundle and the built-in Settings app. So I'm looking at an in-app settings screen, which I understand is allowed - but perhaps not encouraged - by Apple.
Some questions:
Am I correct that an in-App approach is allowed by Apple? Most example code seems to use settings bundles. Am I going to have problems when the app is submitted to the App Store?
I can put the settings UI in a simple UITableViewController, but is there an approved way to expose this to the user? XCode 5 doesn't provide a settings identifier (and icon) for toolbar buttons, and the "Info" identifier (letter i inside a circle) seems to have been dropped too. Should I use a custom icon? Are there any de facto standards?
I haven't seen this kind of UI element before on iOS but my exposure to the platform as a user is limited.
There is nothing wrong with doing an in-app preference (table)view. You won't be rejected for that (this point seems to be way too much exagerated outside the iOS community). There are guidelines that you can follow: iOS Human Interface Guidelines... or not. As long as you don't use private APIs (assuming you know how to access them anyway), you're fine! So you can use a custom icon, the "i" button, or any UI element that convey the reasonable meaning of providing access to more info/preference.
In your code, you can use the class NSUserDefaults (with the standardUserDefaults) to store your preferences.
Many apps have in-app settings. It's fine. Apple even states that it is fine. Just don't have both.
Use a custom icon. Many apps seem to use an icon that looks like a gear.
What's the better approach, use In-App Settings (A Screen on Startup) or use the Settings Bundle and if nothing is entered show a popup on start? Or is it possible to combine both?
BR,
mybecks
Apple says:
Which option you choose depends on how you expect users to interact with preferences. The Settings bundle is generally the preferred mechanism for displaying preferences. However, games and other apps that contain configuration options or other frequently accessed preferences might want to present them inside the app instead.
Therefore if the settings are going to be used frequently use in-app settings, otherwise make a settings bundle
Try InAppSettingsKit, it will provide you a hybrid solution by maintaining the Settings.app pane.