I have the requirement to close the application after 10 minutes if the user has not interacted with the application.
All the questions about this are related to the session time out, the problem here is that the application has no security and is a requirement to run it without connectivity.
Any idea about how to implement this?
Thank you.
First of all, as I mentioned in the comments above, this is a really bad user experience. You should tell your customer you just don't do something like this to your users. never.
If I understand you correctly, the application is running offline, meaning it does not connect to the Worklight Server...
So you should probably just maintain some counter... if the user does any action in the application (touch a button, whatever), reset it. If no action was done and 10 minutes have passed, called WL.App.close.
Please note that using WL.App.close in such a manner in iOS can make your application be rejected from the App Store if found.
Related
I'm submitting my first app through iTunes Connect. It is a social networking community so I have to provide a demo account for the submission. My app already has a live database of users as there is currently an active web version.
I'm new to this and confused as to how I should handle this. Should I be creating a demo account that will not show up in any other live user's search results? Are the testers going to be attempting to interact with other live users? I am assuming I will need to show the various functions of the app, like messaging and events. In that case should I be creating a few "demo" users for the testers to interact with?
Alternatively, should I be linking them to the development version and development database? If that's the case, then the build that I send them would only be a development build then?
I am confused on how this is supposed to work and can't seem to find any information to help?
In my experience, you'll need to give them the production version that will go into the store. So not the development build.
When we submit an app for approval, it seems to get installed and activated on a couple of devices, but nothing much ever happens. They barely use it, as far as we can tell. We can tell that it's installed and run. We have previously been rejected when the network connectivity wasn't working right, so we know that they do look at the app after it's installed.
I'd suggest you make them an account that looks relatively anonymous (or even "Test Account" which you real users are hardly likely to try to interact with). You could create another account and say "If you want to send a message, send it to account xxxx". We've never had them interact with our app enough to utilise the suggestions we've made.
If you have an active / inactive flag, you could think about making these accounts inactive once the app is approved, then re-activating it when you next want to submit your app.
I need a bit of guidance, so for my application i'm looking at using local notifications to send a notification every morning at 7 o'clock.
The issue i'm having is how can i make the content for the local notification dynamic mainly the body and the attached image? As it will vary for the user on a daily basis.
What would be the best way to go about this since you can't edit future notifications.
Here's a little lesson about notifications. First, what is a notification? It's basically an alert presented on your behalf by the system. Second, there are two kinds of notification: local and remote.
Let's imagine, then, an app that aims to present a notification to the user every morning at 7 AM saying what the current temperature is outside. (Assume for purposes of the example that we have a way of learning this information.)
A moment's thought will reveal that this cannot be done with local notifications. We cannot know the current temperature at 7 AM until 7 AM (or close to it) and we cannot schedule the notification unless the app is running. Therefore we would need the great good luck to have the app running at 6:59 AM in order for this app to work. But an app only runs when the user summons it, so that is extremely unlikely.
Therefore a task of this kind is possible only with remote notifications. A remote server is always running; therefore it can get the temperature and "ping" the user's device at 7 AM, and the system will present the notification on your behalf. You would therefore need to possess such a server in order to write the imagined app.
(An alternative using local notifications would be this: You schedule, say, a week's worth of local notification in advance. Then if you have the great good luck to find the app running before a notification is presented, you tear down all the scheduled notifications and do it again with a more up-to-date forecast. But of course this cannot possibly work as well as using remote notifications, and it will stop working entirely after a week if the user doesn't launch the app. That, to put it bluntly, sounds pretty lame.)
My company uses Quick Books Online for its accounting, and that's where we go to log our time against projects. In an effort to make time entry easier, and a way to learn how to write a Windows 8 Metro app, I thought it would be a useful project that simplified time tracking, application that could automatically submit my time to QB. The thought would be users would use their own QBO logins so it would be able to see their time entries.
I have been looking around the api for QBOE and can't seem to tell if its possible to connect to a QBOE account with non admin credentials. Is what I am thinking even possible?
No, this is not possible. You will need something in the middle to talk between QB and your application.
There are a number of different timesheet apps on appcenter that you might look at. https://appcenter.intuit.com/category/time-tracking
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'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.