I'm new to Windows 8 and I'm particularly interested in Live Tiles.
I was wondering - How frequently can an app update a live tile? For example, is it possible to create a clock with seconds?
A Live Tile update every second is far too frequent.
The MSDN guidelines for Live Tiles documentation does not set explicit limits on how often a tile can be updated, but does make a few recommendations about the frequency of updates. For an app with very frequently changing content, the highest average frequency expected is approximately 15 minutes. A few choice excerpts:
For nonpersonalized content, such as weather updates, we recommend that the tile be updated no more than once every 30 minutes. This allows your tile to feel up-to-date without overwhelming your user.
For example, a busy social media app might update every 15 minutes, a weather app every two hours, a news app a few times a day, a daily offers app once a day, and a magazine app monthly.
Recommendations for clock updates are absent, as that isn't an intended purpose for Live Tile updates. The apps in the store showing the time on their tile use scheduled tile notifications creatively (intended to be used for one-time calendar events), or frequently push notifications to WNS (Windows Push Notifications Service). The former is very tough, if not impossible, to implement correctly even for per-minute precision (see app reviews), and the latter is prone to being flagged as abuse and throttled by WNS.
This post explains the thinking behind live tiles and how they are implemented, which I'm sure you'll find useful.
I haven't seen a limit on frequency of sending a notification, but practically seconds might be unrealistic to assume consistently.
I tried to display live clock with seconds running in the tile. But It is getting updated every 4 seconds. So, minimum amount of time needed to update tile is 4 seconds. We cannot reduce more than that.
Related
My goal is to maintain "real-time" (or as close as possible) information about the email messages sent by a group of users.
My ideal solution would be to periodically query the API for messages by all users in the group. This feature is not (yet?) implemented.
My second choice would be to create subscriptions (https://graph.microsoft.io/en-us/docs/api-reference/v1.0/api/subscription_post_subscriptions) for every member in the group and then request message information after I become aware of an event. The problem is, in practice, I am only allowed to create 20-30 simultaneous subscriptions (Issues to use Webhook for Microsoft Graph API), which might not be enough.
So I'm stuck with polling all the users in a cycle. The main problem with this approach is I can't find any information how many request are "too many", ie I get throttled. I want to maximize the number of requests to minimize the time it takes to get through one cycle.
A solution that comes to mind is to develop an adaptive program that slowly decreases the time between requests until throttled, then abruptly adds some time to it until a nice balance is found and maintained. This seems like a lot of work though. Right now I'm working on the assumption that 1/second is about the highest I can safely go (0.5 seconds on average per round trip, then a cool down of another 0.5 seconds).
What is the best way to deal with an unknown throttling limit in general, and Microsoft Graph in particular?
Edit:
While I think the accepted answer is a good response, it might not be suitable for all cases. For instance, if you don't want to use the 365 API, and you don't mind using beta features, perhaps you might check out this (delta tokens), which seem to be designed for real-time syncing with the data.
The only potential downside with the accepted answer is that you still need a subscription for each user you want to track (I think...), and there are limits on those. Very curious as to how other people tackled this problem.
While still in Preview, you may want to take a look at Outlook Streaming Notifications. These APIs provide a more robust notification model than simple web hooks. You would still need to establish multiple subscriptions but I expect you'll see far less latency.
I'm making an iBeacon based app for a shopping mall with notifications based specifically on which store is nearby.
My question is, with background tasks in iOS 7.1 and above, can I run database calls(to reference location on the basis of the closest beacon). What about network calls(like a PFQuery?).
Yes, you can do anything you want on iBeacon detection in the background including database access and web service calls. I have developed apps doing both of these things. The only trick is that iOS only gives your app 5-10 seconds of running time after the detection takes place, so you must make these operations relatively fast.
I have a live tile working which updates how many users are online and how many lobbies are open within the app. This begins updating when my app loses its visibility (no point it updating the live tile whilst the app is running), but I want it to update when I first turn the computer on.
I have had a look around and mentions of making the app a lock screen app have popped up but that is all, no explanation how to do it.
Does anyone know how to do this and provide a nice little explanation or link of how to do so?
Many thanks,
Kevin
You should use push notifications for this kind of behaviour. This msdn link has more info:-
Using tile notifications
Choosing the right notification method to update your tile
There are several mechanisms which can be used to update a live tile:
Local API calls
One-time scheduled notifications, using local content
Push notifications, sent from a cloud server
Periodic notifications, which pull information from a cloud server at a fixed time interval
The choice of which mechanism to use largely depends on the content you want to show and how frequently that content should be updated. The majority of apps will probably use a local API call to update the tile when the app is launched or the state changes within the app. This makes sure that the tile is up-to-date when it launches and exits. The choice of using local, push, scheduled, or polling notifications, alone or in some combination, completely depends upon the app. For example, a game can use local API calls to update the tile when a new high score is reached by the player. At the same time, that same game app could use push notifications to send that same user new high scores achieved by their friends.
You're right with the assumption that you require a lock screen capability to be able to run background tasks without your app being started once. The main process would be to extract the part of your application that gets the data into a background task that is probably triggered by a timer and write some code to be on the lock screen.
When I first encountered that restriction I was kind of surprised, but in terms of battery performance this design decision makes sense: Only consume battery power if the data is absolutely worth it. If it's worth, it is also of interest having it on the lock screen.
On MSDN is a good overview about lock screen along with further reading links. It's much better than what I could type in here. Come back with problems related the implementation (which actually even better fits the purpose of SO). This blog might be useful, too.
The application will select a random latitude and longitude to create a point which the user must find.
The user's distance from the point will be displayed using a "hot-cold meter", which will change color depending on the distance. This meter must constantly update, which would require that I constantly retrieve the user's location. I would also need to use kCLLocationAccuracyBest. However, this sounds like it would use up a lot of battery.
Can I do anything to save battery?
From the official documentation
Gathering location data is a power-intensive operation. It involves powering up the onboard radios and querying the available cell towers, Wi-Fi hotspots, or GPS satellites, which can take several seconds. Leaving the standard location service running for extended periods can drain the device’s battery. (The significant-change location service drastically reduces battery drain by monitoring only cell tower changes, but the service works only on devices with cellular radios.) For most apps, it is usually sufficient to establish an initial position fix and then acquire updates only periodically after that. If you are sure you need regular position updates, you should use the significant-change location service where you can; otherwise, you should configure the parameters of the standard location service in a way that minimizes its impact on battery life.
http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/LocationAwarenessPG/CoreLocation/CoreLocation.html
PS: On the same link there's a section at the bottom of the page with other tips too :)
My iphone app runs 8 hours of recording fixes evey second on iphone4. The display needs much more power. Dont worry. Measure how long you can record. Then claim, not before.
I want to have a movie start the first time my app is launched to train users on its use, say a 50 second clip.
How would I go about doing this in an iPad app?
(I am building a very complex platform that has hooks into the web and need users to be aware of that. The video will explain that users can go to the website for different features. When the app starts for the FIRST TIME only I want the video to play.)
Don't force users to sit thru a 50 second movie when the app starts. Your user interface should be obvious enough that they can figure out the basics without watching a training video. If you want to offer it, provide a help button, where they can watch it when they choose to.
See the iPhone HIG section Minimal User Help, which says:
A hallmark of the design of iPhone
OS–based devices is ease of use, so
it’s crucial that you meet users’
expectations and make the use of your
application immediately obvious.
EDIT -- The simplest way to keep track would be to store a flag indicating whether or not you have shown the video by using NSUserDefaults. Check if it's set at startup, set it after showing the video the first time.