I am about to start work on a project that will aid in teaching new vocabulary, in an interruption-driven style, presenting new words, via interrupts, for the user to learn at optimal times.
I am looking for a way to detect which app is running. I found some posts that touched on retrieving the running app list part of my question, "Can we retrieve the applications currently running in iPhone and iPad". Is this still viable to use in iOS 6?
I cannot find any relevant posts about retrieving data about the type/category of app that is running (media player/game/pdf viewer etc.). Do iOS apps contain any meta data or way of retrieving this type of data?
Naturally, to interrupt the user at an optimal time it would have to take the type of app in use, into consideration.
I am open minded about alternative ways of detecting when interrupts may be optimal and open to criticism of my current plan.
You can get a list of running processes (aka apps), as noted here, but you can't get any meta data on them from the OS. From a UX perspective, you might consider a solution where the user manually schedules the interruptions, or gives you a schedule window. For instance, maybe every day between 3 and 4, start notifying me. Personally, I delete spammy apps super quickly, so I'd consider doing something other than interruptions.
Related
I'm facing this problem while designing my iOS app. Suppose that a user purchases an app and downloads it to the iPhone. I would like to provide him with a default consumable item the first time he runs the app to use whenever he wants , however I would also like to track if the user has already consumed the item. This way if he decides to reinstall the app we can restore the transactions (if he used the item) or we can avoid possible intents to download different kind of content by reinstalling app and consuming default items each time. (Guess NSUserDefaults is not an option here).
One approach that came to my mind was using UDID(or any iOS 6 alternatives) to keep a record on server of the user's device the moment he uses the default item. But this will limit items just to the device from which they consumed content.
It would be great to support all the user's devices (like inAppPurchases), but I can't figure out a way to implement this.
Any suggestions or help would be great.
Thanks a lot.
In order to tie information to a user (not just a device she used at one time), you'll need to ask the user to identify herself and save it someplace other than the device. In other words, a backend that implements registration and login.
From scratch, this can be a lot of effort that an iOS developer didn't count on. Fortunately, there are several services in the world that provide a substantial head start. Here's a nice round-up. I've had direct experience only with Parse.com, and think it's excellent.
I am new to ios development and doing development in ios4.0.1 and xcode 3.2.3. My application should capture other application's launch time and (close) end time. how can we do this? Any help will be appreciated.
Thanks
Pushpa
For apps in the app store, the answer is "You can't". The best way to think of other applications on iOS with respect to yours is: don't. You can't access their data, you can't see if they're running, you can't control them, and you can't change them. Apps are well and truly sand-boxed as a fundamental design decision in the current setup.
About the only thing you can do is trigger their launch with a suitably formatted system URL. If a Wikipedia application has registered the scheme wiki, you might be able to launch and communicate some simple data by having the system load the URL wiki://articleName, but that's the limit. You don't even know what application will be launched, only that one has the wiki handler.
Jail-broken iOS systems are a whole different matter, but I'm assuming you're not working on those.
I know with ios 4 it is possible to run application in background as per this documentation
http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/BackgroundExecution/BackgroundExecution.html
this documents states that if application updates user's current location in background continuously then it is possible to run it in background.but is it necessary that we have to use only CLLocationManager for updating current location?can we user other apis like google latitude apis for updating current location?then also it is possible that application is able to run in the background forever?
As far as I understand from the document you posted, if you define the UIBackgroundModes with a value of location in your info.plist, "the system should allow the application to run as needed in the background". So, the first answer is yes, the application can run in the background and it will run indefinitely (up to battery life). This could be easily checked, actually.
Anyway, it seems to me that this kind of functionality is "reserved" to GPS-like apps and that Apple is really concerned about its usage:
For applications that require more precise location data at regular intervals, such as navigation applications, you need to declare the application as a continuous background application. This option is available for applications that truly need it, but it is the least desirable option because it increases power usage considerably.
so, I understand that Apple will screen really thoroughly all apps that activate this mode in order to assess if they really need the continuous update or do not (and in this case, possibly, the app would not be let in into the App Store).
Now, to answer the second part of your question, I think that one way that Apple will know if your app really complies with the rules, is its usage of CLLocationManager. The risk is that if you use another service, then Apple could think when reviewing your app that you just need background time without needing to constantly update the location.
But this is just a guess...
I'm currently testing the latest iOS4 Feature to put my location aware app in the background. Well, it does work! But on the other hand it's quite hart to handle the immense power usage.
The app consumed about 50% battery power in the last four hours. It read the entire official documentation by Apple on this topic but I'm still not sure which parts of my application are still running and which functionality is suspended (beside the UI Drawing, which should be clear).
I don't use any real boilerplate code but extended libraries like ASIHTTPRequest to talk to my webservice. Tests with a friends car did you show that the Network Connectivity and and the Location Services is still running when I'm using i.e.
[locationManager startMonitoringSignificantLocationChanges];
Apples Documentation on the different application states
Background: The application is in the background and executing code
[...]
Should I write a "bare metal" functions to receive and send this location data? Should I remove all other objects for the time the application resides in the background to reduce the memory footprint? It seems there isn't any best practice yet.
Any ideas? Maybe you guys can provide me with some of your insights. Thanks.
Edit:
There's a new Instruments tool called Energy Diagnostics Instruments to record any power usage (for iPhone 3GS and later) with an attached device. Also there's another service on the device in the Settings App -> Developer -> Power Usage. It's great to test your power usage in field. The created logs can be pulled later in instruments.
Reference: WWDC 2010 Session 309 - Advanced Performance Analysis with Instruments
Sounds like your app is transmitting location data over the cellular network. Turning on the cellular radio is one of the most rapid causes of power drain, especially if the user has a weak signal connection to the cell tower.
You might want to save and package up a bunch of location data, and send the data in a quick burst as seldom as possible (twice per day, when the user stops moving for 30 minutes, only after the user gets to one of their favorite restaurants, etc.) Turning on the radio less than half as often could get you close to doubling the battery life (unless the user is doing something else with the device as well).
I'm writing an iPhone app for a client, and they have requested a feature whereby the app "wakes up" at certain times during the day to display a message to the user.
I'm well aware that I can't have the application run in the background and simply move to the foreground at the appropriate time (short of requiring jailbreaking, which isn't really an option for a commercial app). What I'd ideally like would be to simply have the system schedule the application to be run at a particular time of day.
As far as I can tell, the only way to achieve this seems to be to implement push notifications and have a server send the app a message at the appropriate time of day. But this is really ugly and undesirable for several reasons:
It requires a constant internet connection on the user's phone (something that I can't really assume)
It places a large burden on the server in having to keep track of these times (which may be different for each user)
Its just a generally crappy workaround - that's not what push messages are designed for, a dedicated scheduler seems like a much better option.
Does anyone know of a better alternative?
Currently, this is the only option. File a bug with Apple requesting 'local notifications' (a term I've heard their engineers use in relation to this problem.) Ideally, they would work just as push notifications work now, but not require any net connection. Sorry!
Now you can use local notification instead of push notification. Available in iOS 4.0.