According to the Android Wear Developer Training guide for Wear 2.0 Watch Face Complications, though the developer can, via the manifest file, define a set interval where a complication provider can request an update, there is the caveat that "update requests are not guaranteed to be sent with this frequency" and that "the system does apply a minimum update period, and in particular, update requests may come less often when the device is in ambient mode or is not worn."
Is there any documentation or source specifying exactly what this minimum update period is, or how it is derived?
UPDATE: The reason that I am asking this is that our organization is looking to develop an application that will both run on Apple Watch and Android Wear, and it was noted by the Apple Watch side of development that the Apple Watch OS only permits 50 updates to their complications for every 24 hour time period; the project manager for this application is very curious if the Android Wear 2.0 OS has any similar restrictions, or if a developer is, in theory, capable of updating complications "freely" (i.e. without consideration of the end user's device's battery).
As I've read the documentation you linked, it didn't state the minimum update period you can specify. However, based from this example, developers should consider intervals in the order of minutes. Also, remember that this is only a guidance for the system. Android Wear may update less frequently. Unfortunately, I cannot also see any documentation regarding the exact time to specify but this value should be set as large as possible, to not have a too big impact on the device battery, due to frequent updates. You can check this blog. But if your app needs to push updates instead of updating on a regular schedule, you should set this value to 0 and use ProviderUpdateRequester.requestUpdate() instead to trigger an update request when you need one.
Related
I'm an Android developer.
From Android 11, the GnssAntennaInfo class that can utilize dual-frequency GNSS has been added, and it has been confirmed that developers can use it.
If so, is GnssAntennaInfo already used in getLastLocation method of locationManager provided by google location api??
Or is it still necessary for developers to utilize GnssAntennaInfo provided to improve location accuracy??
Sorry I can't give a definitive answer but, since there hasn't been any other response yet I'll answer what I'm pretty sure is the correct answer.
No.
From: https://www.androidpolice.com/2020/03/19/pixel-4-dual-band-gps/
In the sheer infinite expanse of the Android 11 developer documentation, an entry for GNSS or dual-band GPS support has surfaced. While the Pixel 4 isn't explicitly mentioned, it's plausible that owners will be able to use the hardware once developers add support for the new GnssAntennaInfo class to their apps. Hopefully, Google Maps will be among the first to utilize it — even if the difference isn't too meaningful, it might make GPS more reliable.
This matches my own experience. I recently purchased an S20 hoping for this exact feature (~ 1 yard accuracy), currently I'm seeing ~ 4 yrds. I've confirmed I see L5 satellites and my phone just got the Android 11 update tonight. All of my GPS apps show NO improvement in accuracy. I'm unsure of Google Maps, don't really know how to tell with it. However, if some "provided" function like getLastLocation were benefitting from high accuracy I think I'd see it in my GPS apps.
Hence, if I can figure out exactly how L5 can improve accuracy, I' going to attempt to write this myself. I'm having a hard time tracking that info down though...
So at WWDC 2016, ATS was announced as being mandatory as of January of 2017. At least for iOS.
Finding documentation about what's changing has been tricky (but I suppose I could hunt through a few WWDC videos to find the one or two slides where this is mentioned).
Will NSExceptionDomains exceptions be allowed for macOS Sierra apps? Or will my app magically stop working as of January without some server intervention?
The change is in regards to what App Review will allow into the Mac/iOS App Store (without "reasonable" justification). It is not a behavior change in the OS itself, and existing apps will continue to work.
First up, there have been no changes to the technical behaviour of ATS (other than the addition of NSAllowsArbitraryLoadsInWebContent and NSRequiresCertificateTransparency). From a technical perspective, ATS exceptions in the newly seeded OS releases work the same way as they do in the current OS release.
What has changed is that App Review will require “reasonable justification” for most ATS exceptions. The goal here is to flush out those folks who, when ATS was first released, simply turned it off globally and moved on. That will no longer be allowed.
Source: Post from Apple Developer Relations / Developer Technical Support
New device unboxed a couple of days ago. Cannot use OTA to upgrade, says current software is up to date even though it is not. Without a current kernel I cannot download tango core, etc. So the device is basically non-functional (other than a plain tablet :-)) out of the box.
Same problem as this question:
Cannot update Tango Core - "Package file was not signed correctly"
Factory resets did not fix the problem. Unlike the previous question, waiting 48 hours provided no resolution. Several users on the Google+ developer group are having similar issues with this batch of devices, so this seems to be a common problem
Thanks!
We had an error in our OTA server configuration that we fixed this morning. This might take some time to propagate, but you should start seeing updates soon. Sorry for the inconvenience!
I've noticed while I'm out and about (specifically at HyVee and Walmart) that the Continuity prompt (bottom-left corner of the lock screen) shows the App Store. When I open it, it takes me to their respective apps to be downloaded.
I thought that Continuity only shared to other devices with your Apple ID, so how are they advertising their apps? Are they receiving App Store links from nearby iBeacons? Various Google Search terms haven't turned up any information.
This is the new Suggested Apps feature of iOS 8. This is an AppStore feature that uses geofences (not beacons) to find apps relevant to your location. The description of this feature in settings says:
Leaving this option turned on will allow iOS to offer suggestions for App Store apps that you do not already have installed. These can be based on what you already have installed or what people near you find interesting.
Apple's mechanism for suggesting apps is undocumented. Perhaps it is based on an algorithm (other folks regularly using an app in the vicinity), a database (known locations of major retailers), or paid marketing (e.g. Starbucks pays Apple to suggest their app when near one of their shops.) It could be a combination of all three.
I know that this technology is not based on beacons (at least not exclusively) because I received an app suggestion for Starbucks (without having the app installed) and then I immediately used a non-iOS-based beacon scanner that verified no beacons were in the vicinity.
So far they're the only people I can find that are doing a chart control...
What happens when the beta expires? How does it expire? (Does it expire?). They look great but there is no pricing information or expiry information.
Here is a direct quote from the EULA:
“You may distribute the Programs as embedded in Your Integrated Products to Your end-users only pursuant to an end-user license that meets the requirements of this Section.”
So, yes, you can ship Apps built with Telerik Windows 8 Controls Beta to the Store.
"Beta," by definition, suggests not ready for production use.
There are at least a couple of things you should think about before moving forward:
Does the license agreement for the controls allow use in a production app (you did read the license, right?)
Are you willing to risk the possibility that the app might suddenly stop working for any and all users who have downloaded it, until such time as you replace the controls with working versions (and get the updated version of your app submitted to the store)?
As long as the controls fit the Windows 8 app design, and don't cause performance or crashing issues, they may not have any impact on whether or not the app gets through certification.
But the larger issue is one of risk. Betas are for testing. IMO, unless the beta includes a "go-live" license, you should probably stick with using beta software for evaluation and testing only.
To be clear, that's no knock on Telerik's beta quality (or anyone else's, for that matter). Just a reminder that beta software isn't finished yet.