Where is CurrentAppSimulator Class in Windows.Services.Store namespace ?
I wonder why this class is removed? How MSFT expects developers to do testing?
Testing on live store is reckless, insensible.
isn't there a way to test all code paths in the purchasing process. ?
Regards
The CurrentAppSimulator Class comes from the Windows.ApplicationModel.Store namespace. As #IInspectable mentioned, the document had already said that The Windows.ApplicationModel.Store namespace is no longer being updated and
it is recommended that you use the Windows.Services.Store namespace instead.
To test your in-app purchase, you could check the Test your in-app purchase or trial implementation part of the document, which explains how you could test your in-app purchase. You could create a free add-on for the testing purchase.
Related
I am not able to test this Delegate Scope Feature
https://developers.google.com/android/management/reference/rest/v1/enterprises.policies#DelegatedScope
can anyone Help me!
You can use DPM.getDelegatedScopes(ComponentName, packageName). This will return the scopes assigned to the specific package.
If you want to test end-to-end, you may have to create a separate app with all those functionalities and then delegate the scope to your app.
I already did this for some of the delegations by creating a separate app.
from the official docs
https://laravel.com/docs/5.4/facades
this seems easy to test (the cache class)
public function testBasicExample()
{
Cache::shouldReceive('get')
->with('key')
->andReturn('value');
$this->visit('/cache')
->see('value');
}
as well in the documentation of facades it is written:
When building a third-party package that interacts with Laravel, it's
better to inject Laravel contracts instead of using facades. Since
packages are built outside of Laravel itself, you will not have access
to Laravel's facade testing helpers.
I really don't see how this is true. The package very well will access functions of laravel, so I don't see how it should not work with testing?
now in contracts https://laravel.com/docs/5.4/contracts they go on a little philosophical discussion what to use, facades or contracts. Isn't it better to use them together? Because contracts are nothing else than an interface. Now the idea of an interface is not new at all. I don't really get, what is the point about first of all comparing facades and contracts when:
facades are basically a extended class of laravel adding testing possibilities. They hide the implementation though and make it harder to read what functions are available on the class. E.g. you always first have to figure out what implementation is used of the facade, to see what methods there are.
contracts on the other hand are nothing else than interfaces. Basically the laravel people telling us "use interfaces". I agree, interfaces are great. But I don't see in what way this relates to facades. They are not related. They are not interchangeable neither.
So what is this all about?
why say "use contracts OR facades" they are not related, and should be used together imho.
An example is the Mail facade:
/**
* #see \Illuminate\Mail\Mailer
*/
class Mail extends Facade{...
so accessing Mail:: will return an instance of \Illuminate\Mail\Mailer
lets look at \Illuminate\Mail\Mailer
class Mailer implements MailerContract, MailQueueContract
{
nothing else than a class implementing a contract aka interface.
What exactly are they trying to tell us?
third-party package
is key term here to consider. Not every package is used with Laravel only.
The package very well will access functions of laravel
Is that true if I use CodeIgniter? Nope.
Now if you build a package specifically for Laravel, then by all means, use facades all day.
The whole point of this is to not couple yourself tightly with a single framework.
I have to develop a small daemon, using flask and Dropbox API, that downloads files from my Dropbox account to my local database.
It is my first contact with the Dropbox API.
So I am confused in the choice of the class that I should use:
Dropbox.dropbox class or Dropbox.client class?!
What is the difference between the two classes?!
and what the best use for each class?
Thank you
You should use the dropbox.Dropbox class. That uses the current version of the Dropbox API, which is API v2.
The client class is offered for backwards compatibility, and uses the deprecated API v1.
I am using the WebAPI Versioning package to version my API by the X-Api-Header by using the "VersionHeaderVersionedControllerSelector". I am also using the Microsoft.AspNet.WebApi.HelpPage to autogenerate documentation for the APIs.
In order for controller versionign to work, they need to be namespaced with the VersionXYZ as the suffix in the namespace so that the "VersionHeaderVersionedControllerSelector" is able to route the request to the appropriate version of the controller like so:
namespace WEBAPI.Api.Controllers.Version1
{ public class ProductsController : ApiController {} }
namespace WEBAPI.Api.Controllers.Version2
{ public class ProductsController : ApiController {} }
This works as intended but when I look at the generated help pages the ApiDescription is including the "VersionXYZ" suffix from the namespace in the ID (GETapi/Version1.Products) and RelativePath(api/Version1.Products) properties.
Ideally what I'd like to do is to have a top level help page which just the API Version numbers and drilling in would show the API the normal way i.e. The ApiDescription.ID = GETapi/Products and the ApiDescription.RelativePath = api/Products
Is there a way to achieve this using the Out of the Box APIs or am I going to need to rollout my own implementation of ApiExplorer
Check out this answer Get Help page works with Api Versioning
Make sure you have configure the versioning right, and you need to get a documentation XML file from your project XXXX.Api.v1 project and place it in the bin folder of the XXXX.Api project.
Unfortunately ApiExplorer does not support duplicate controller names. So by implementing controller versioning this way, your (or the package code) doesn't play nicely with the system.
Consider another alternative where you actually change the controller name (and yes you will have to implement your own solution, but honestly its not that complex). For example make the version be part of the controller name itself (rather than its name space).
e.g. Ver1_ProcuctsController
Now these will start showing up on your help page, and since help page is just content package you can change the logic to make the names that start with verxxx_ to mutate.
I use CodeIgniter2.0.3 and facebook-php-sdk3.1.1 to develop an application.
When I run the project,is says:
Fatal error: Cannot redeclare class Facebook in ../application/libraries/facebook.php on line 24
The source of line 24 is:
class Facebook extends BaseFacebook
What's the reason?How to deal with it?
Check the name of your controller. If it is called Facebook then that is your problem, you cannot have 2 classes called the same thing at once, unless they are in different namespaces.
I wouldn't suggest using the normal Facebook PHP-SDK when there are a number available over on codeigniter sparks that perform most of the same functions but already setup to work with codeigniter without these conflicts.