Setting Privacy - Location Default Accuracy Reduced in an apps Info.plist file and then calling locationManager.requestWhenInUseAuthorization() still asks for precise location permission from the user.
This is a bug in Xcode, the plist editor sets Privacy - Location Default Accuracy Reduced to a string when it needs to be a boolean.
To work around this you can edit your plist as source code and then set it to:
<key>NSLocationDefaultAccuracyReduced</key>
<true/>
This will then only prompt for approximate accuracy.
Related
Trying to upload a articulate 360 xapi published course into cornerstone LMS. As first step Published the course with basic settings reporting to LMS and tracking on passing the quiz at 80%.
At Content level there are 2 checkboxes in Cornerstone LMS (1.)IsScoring and (2. )Use TinCAn verbs for completion.
When unchecked both the course marks complete upon launch.
When Checked both or either the course does not mark complete upon passing the quiz.
In debug mode can see the statements generated with passed verb.. Please guide on this. How can I get the completion tracked. Am I missing some setting in Cornerstone LMS.
Let's say I have a website called "Example Website", and it has a bunch of paragraphs in it. Something like the image shown below
Now assume that there is a chrome extension out there which injects some images inside my page. These images are inserted without any animations whatsoever, causing a pretty bad layout shift in my web page. Here is what the page looks like after the extension has inserted the images.
So here are my questions,
Does the layout shift caused by this third party extension affect the CLS in my website?
What can I do as the developer of a web application to prevent such extensions from causing layout shift in my website?
What can I do as a chrome extension developer to not affect any other website's CLS?
Short Answer
Yes, extensions do affect CLS if they cause layout shifts.
There is nothing practical that you could do to stop an extension affecting your CLS.
If you are building an extension, you can limit CLS issues caused by your extension by using positioning that does not change the document flow (where possible).
And above all...don't worry about it too much, it is very unlikely you will ever cause or have someone's extension cause any CLS issues that will affect your SEO efforts etc.
Longer Answer
Does the layout shift caused by this third party extension affect the CLS in my website?
Yes!
If you use performance-observer on your page (which is the same API the CrUX data is built with) to measure layout shifts, you will see that these do contribute to your CLS.
What is not clear (or disclosed as far as I am aware) is whether Google have thought of this and take installed extensions into account on the data set they use for Core Web Vitals (CWV).
This is why whenever you run Google Lighthouse or a Performance Trace in your browser you should always go "incognito", so extensions do not affect your score.
What can I do as the developer of a web application to prevent such extensions from causing layout shift in my website?
Very little!
Extensions operate outside of your site control. Even if you tried to use Content Security Policy to limit script insertion (or similar) it is ignored.
You could try listening for requests using a service worker, have a whitelist of scripts, then delete or intercept any that do not match (I have no idea if this would even work for an extension FYI, just a thought off the top of my head!).
But at that point (assuming it works) you have created a far worse UX problem...you broke an extension I want to use as an end user and I will be annoyed.
The golden rule is to follow CWV as a guide...never do anything that hurts User eXperience just to please Google!
What can I do as a chrome extension developer to not affect any other website's CLS?
Not insert anything within the document flow.
So make your elements appear inside a container that is position: fixed for example (or any positioning that does not affect the original document's layout).
Other than that, yet again, I think you have very few options as you would normally want the page to have loaded before interfering with an extension.
The real question is...is it actually a problem?
I would argue it isn't.
If your extension causes layout shifts then a user is expecting that, so there is nothing you need to worry about there.
In terms of your site performance and CWV...unless a large proportion of your user base are using a misbehaving extension that happens to cause massive layout shifts you will not even notice!
Imagine a very unlikely "worst case" scenario: 10% of your userbase get a CLS score of 1 (which would be a complete page shift!) due to an extension.
Assuming your site has no layout shifts (CLS score of 0), then you will still only have a CLS average of 0.1 and that would still be a "good" rating (only just).
Then consider that CLS only makes up a small percentage of Web vitals scoring, and that web vitals scoring is only a small part of your SEO score...and you will see that it is very unlikely that you will see any negative impact.
In an XPiNC application parameters are packed into the command line with # rather than ?param=x¶m2=y.
Somehow you can edit the extension.xml to accommodate that - I recall having seen that somewhere but I can't find it anymore. Any pointers?
I have the following Message-level entry in my Error List from CodeContracts:
CodeContracts: Checked 410 assertions: 404 correct (6 masked)
I can't figure out:
What masked assertions are
How to locate the 6 that it mentions
Whether or not I should be concerned about them
Sorry for not posting code... I have no idea how to recreate this in a small sample :)
Many thanks
It's simple, in your project properties>Code Contracts>Static Checking> put the warning at "hi".
Now ccCheck made more warning.
Bye.
These seem to be assertions that are masked by virtue of their inclusion in the "baseline" file. From the documentation (emphasis mine):
6.6.8 Baseline
Bringing an existing code base to a point where the verier emits only a few warnings is dicult and time consuming, as it requires adding numerous contracts. To make it easier to use contracts on existing code bases, and to focus warnings introduced by new code or code changes, the Baseline functionality can be used.
To use the baseline functionality, check the box labelled Baseline and provide a file name to store the baseline in. The path is relative to the project output directory. When the analysis is run and the baseline file does not exist, the baseline is created. During this run, all warnings are shown in the output and stored in the baseline file as XML.
When the analysis is run and the baseline file exists, then the baseline acts as a filter and warnings already found in the baseline are not shown again. New warnings are shown and stored in a file called <baseline>.new, where <baseline> is the file name of the baseline file. Since the files are stored as textual XML, it is possible to edit them and to add additional failures to the baseline. The format does not depend on method ordering and additional XML tags for grouping can be introduced freely.
I was wondering about the "masked" messages, too; I turned off the "baseline" option, and they no longer appeared. The answer to your second question therefore seems to be "clear the 'baseline' check box."
As to whether you should be concerned about them, I would say, yes, you should.
I asked about locale translation here Magento: how to translate action tag content?. At the same time magento has translation themes:
app/design/frontend/default/default/
app/design/frontend/default/french/
app/design/frontend/default/german/
If we can do translation in locale files what are design folders for then? (In case we have the same theme for each language). Or is it implied that I should use design folders only when I have different themes?
Actually, a single theme can contain multiple translation locales. The following would be perfectly possible (though obviously not advised):
app/design/frontend/default/french/locale/de_DE/translate.csv
Storeviews are often used for switching between languages, because it is quite easy to set a locale on store-view configuration scope from the backend.
To answer your question more direct, I would suggest that you:
Install an initial language in app/locale/(code).
Anything that deviates from this 'core' locale, to be put in app/design/frontend/(your_package)/default/locale/(code)/translate.csv.
This leaves you room to do overrides in non-default themes at any later point.