I have an app that has 2 parts: A preference pane and an app that runs in the background.
I need the user to input some secure data in the preference pane, the pane then saves it to the keychain. My question is, what is the best way for the preference pane to tell the app to update from the keychain?
Let me know if you need anymore information
Thanks in advance.
Use NSDistributedNotificationCenter. The API is similar to NSNotificationCenter except that a distributed notification can be posted and received across process boundaries. So in your case, the preference pane would post a distributed notification with some unique name, and the app would register for that notification to know when to update from the Keychain.
Related
I understand that there is a very limited number of options to do with the Applescript notification alert call, but I am curious as to whether alerts can be called with icons or specified images to better identify them?
I ask this as i have seen it employed by other Applications which use the Notification Centre, and each Application has its notifications heralded by its own Application Icons.
Example:
Thanks in Advance.
Basically it's not possible to change the icon programatically.
A workaround is to save the script as application and change the icon (applet.icns) in the Resources folder of the package.
After choosing the user in the login view, the library saves this information somewhere so that the app has not to ask for the user again.
Where is this information stored? I need to know how to reset this setting for a fresh start?
If you're simply looking to switch between users, there is an easy way to do this when the app starts up.
On iOS, there is a brief message shown at the top of the screen when the app starts up, if you click on that, you can change to a different user.
On Android, there is a notification that you can reach by pulling down from the top of the screen once the app has started. Click on the notification and you can change user.
A quick search of Apple's Human Interface Guidelines and Developer Library yields an unequivocal guideline:
Users, and not apps, place menu bar extras in the menu bar.
Anecdotal data backs that up: submitting an app where - upon quit of a dock process/main view, the extra is left running - yields a tidy rejection.
Now - I'm a User experience designer (UXD) who typically plays, I mean, works in the mobile and web space. So please pardon my lack of Obj C chops, thanks.
I understand well the guideline and behavior/pattern: apps like Skitch, Wunderlist, Evernote, et al however very clearly leave the extra (often termed HelperApp) running in the menu bar on quit of main app. They all, do offer explicit user toggle of this w/i preferences.
There's no additional Human Interface Guidelines w/ specifics around handling this requirement for user control. Must this be included in onboarding? Dialog at 1st quit? Again: I can speak to best behavior UX wise, but my (very senior) dev wants the mandate - how are others not getting rejected?
Focus: what means of user control is/are mandated to avoid rejection?
Known/given: include in preferences
Other: ???
After hours of searching online and Apple Dev guidelines, I humbly bring this question here. There simply isn't time to play a carnival game of requirements: guess, get rejected, repeat. Thanks in advance.
Do you have a button somewhere in your user interface that adds the menu extra to the menu bar? Or does your app just do it automatically without the user telling it to do so?
I think that's the distinction, your app must only add an extra when instructed to do so. Also if the primary purpose of your app is to create a menu extra (eg, I have one that puts a calendar in the menu bar) then just launching the app is an implicit instruction, so it can be added automatically.
Ultimately, this rule really is vague and can't be clarified. What it comes down to, is that there should not be many menu extras in a user's menu bar unless the user explicitly chooses to have them. So unless your app really needs a menu extra, you must disable it by default.
If you think the reviewer should have allowed your app through then reply to the rejection explaining your position. I've had an app change to approved once after doing that.
If they still reject your app, then you can appeal the app rejection.
Alternatively, just disable the menu extra by default and have a button somewhere to add it to the menu bar.
Also, all of this assumes you are using NSStatusItem and not the "real" menu extra system — which is a private API. Only NSStatusItem menu extras can be placed in the app store as far as I know.
Can anyone enlighten me as to how one would be able to trigger a "non standard" realtime notification on a Windows 8 machine? My objective here was simply to find a slick method through which the end user is presented with an enhanced notification slide displayed via a slide in/5 second fade out dialog box.
Best example I can think of to illustrate what I am trying to achieve would be thinking of it like when the charms bar is presented which can automatically fade away. I simply require that this enhanced notification layer is somewhat customizable in order for me to provide summary content along with 3-4 buttons a user can press directly. This notifications needs to be triggered automatically upon the system receiving a push notification.
I have loomed into various "notification" methods such as default windows notifications, offline Google Apps notifications,... problem however is that they all seem not to allow me to customize the notification window to meet my needs.
Any suggestions / examples would be very helpful.
BTW - as an alternative solution - is there simply a way that I might be able to have Windows automatically load and "snap" into view the contents of a specific Windows app containing my content to the left or right side of the screen (upon receiving a push notification vs displaying the standard toast bubble?
Are you looking for something like growl?
I am implementing a simple webview application with only one url. I have over ridden back button function for webview navigation (which is working fine). Now my app has only one screen with webview and user visits the links inside main url and navigates using back button.
I want to know that, What is Microsoft Certification Policy as my application has only one screen so should it Close when user press back button anytime? Or Microsoft allows implementing of webview with over ridden back button functionality.
If question is still unclear Kindly tell me. I'll explain more but I need to know answer to this question.
Thanks.
You shoulld be fine, I have submitted applications which works like that myself which passed certification.
As long as the application quits when pressing the back button when there is no more "history" for the webbrowser control it shouldn't be a problem because the user still get the experience of moving "backward" in his use and can finally quit the app.
Regarding WebBrowser control and content of the app please consider this requirement:
"Your app and metadata must have distinct, substantial and legitimate content and purpose. Your app must provide functionality other than launching a webpage."
So, the application's sole functionality must not be only to launch a website.
This is not releated to back button but very important thing that need to be considered!
Best regard