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.
Related
I have a question regarding executeJs function.
page.executeJs("$0.click();", downloadAnchor.getElement());
This line of code is not working in real iPhone Safari browser, though it works in mobile responsive mode from desktop safari. Appreciate your help on this
Browsers will be "suspicious" of anything starting a download that isn't a direct reaction to interaction by the user. This is done as a security precaution since starting to download files without the user's explicit consent can be dangerous in specific cases. Different browsers and configurations have different policies for exactly where to draw the line.
In your case, the download isn't started as a direct consequence of user interaction but instead as direct consequence of receiving a message from the server. This kind of pattern will simply not work reliably no matter what you do.
Instead, you need to design the interaction so that the download is directly triggered by the user. The easiest way of doing that is by having the user directly click on the actual download link. If you want to have some indirection, then you still need to make the action work directly in the browser without going through the server.
A colleague recently asked a similar question ( How to start a MetroApp directly in Snapped mode? ), but this question is not a duplicate...
Programmatically forcing a Windows Store app to open in snapped view does not seem to be possible – by design. But can you do this or something similar on a Windows Embedded 8 machine? Similar things could include:
automatically start an app in snapped view on system start up, or
always start a specific app in snapped view
???
What we are trying to achieve:
The user logs in (on a preconfigured machine, assembled by us, possibly running Windows Embedded 8), starts our app and a snapped communication app (e.g. Skype or Lync) is (A) automatically there alongside our app, or (B) can be opened by pushing a button in our app.
Developers have the API necessary to take their app from SnapView to Fill or FullView. This is usually a less-advertised API because it could easily be abused. To that end, the reverse is not available. There is no API to move to SnapView.
I might also caution you, that unless you are sure of the device resolution, starting in SnapView (which is not possible as it is) would be a dangerously unreliable step as many (most?) displays do not support it (too small). And since you are talking embedded, I imagine this might be exaggeratedly so. Since it sounds like you might know the hardware, you can take that as a general rule, not for your circumstance.
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 need my application to perform a background task every day, but it does not comply with Apple's specification for running in background.
It's none of these: audio, location, VOIP, news stand, external-accessory—, Bluetooth-central.
I'm planning to use local notifications, but the point is, that if the user doesn't open the app (and just leaves it in the background), I cannot plan new local notifications.
What should I do in this situation?
Make something else.
Seriously, if your app doesn’t at least technically fit one of those categories, you’re not going to be able to get it to do background work in a way that’ll get you approved for the App Store.
I’ve seen apps that added specific functionality in one of those categories, orthogonal to their actual purpose, to be allowed to run in the background; for instance, there’s a couple of weather apps out there that play a continuous audio file—one of the available sounds being a silent one—in order to be able to update the lock screen’s “now playing” image with live data. If you don’t mind your users being unable to listen to any other music, and have your app continuously active (which might cause additional battery drain), that could work. But if you’re trying to have your app invisibly do things in the background, without interfering with anything else, in a way that’ll get you into the App Store, you’re probably out of luck.
Four options:
Go for jailbreak
Try to get in the app store as one of those types of apps, making up a feature that uses one of those types.
(my favorite) Really rethink your system, is it really necessary to schedule background tasks? Can't the user wait a bit when he opens the app? That loading can be performed in background. And can't you offload some of the work to a webserver? Are you collecting data? You shoudln't without the user consent.
Let your user know that it's important for him (he's the one using it right?) that he opens the app once a day.
I think I covered all yohr options except the one already covered by Noah.
I'm brand new to OS X and mac programming. I'm looking to write an app that runs continuously or is woken up every 30 seconds to do some minor task. It would do something like check the weather via a web service and shoot off an email if the temperature drops below freezing. In Windows I would just use a service or put a repeating task in the task scheduler. Is there a standard way to accomplish this in OS X which the mac app store allows? I would like to write something that I can put in the store but Apple seems to have vague restrictions against running background processes.
I've learned a little about launchd but I can't tell if I am allowed to use it. Ideally the process would get run even when no one is logged in, but it probably won't need root access. If someone does happen to be logged in, it would trigger some popup if it sent an email temperature alert out. I would also have some GUI which the user would be able to modify the configuration files that determine the behavior of the background process. I don't anticipate any app store restriction for that piece of the project though.
I'm pretty sure an app that runs invisibly like that would not be allowed into the App Store. What you're going to want is to create a menubar-only application, which can be enabled by setting a key in your app's info, namely LSUIElement. Although it won't be able to be run unless a user is signed in, it's your only way to get it into the store successfully.
The MAS guidelines have several prohibitions that would impact you. Go to the guidelines and read section 2. In particularly consider 2.15, 2.23, and 2.27. I don't know any way to get your application running prior to login without at some point requesting admin privileges (even if you don't use the privilege when you run).
I would probably make it a Login Item (System Preferences>Users>Login Items), probably as an LSUIElement app as sudo rm -rf suggests. Definitely if it's your first app, I wouldn't go diving into launchd in any case. It is one of the most infuriating system processes I've ever dealt with.