Dev GuideAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunitySubmit a ticketLog In
GitHubNuGetDev CommunitySubmit a ticket

Class configuration

Extend Optimizely's classes to add functionality to your app.

See an example of how you can override one of the classes within the Logger() class below.

This example consistently logs all messages, including those within the API SDK. There are a few required steps:

  1. Define your interface with the new methods
  2. Implement your interface
  3. Add your class to the IoC Container
  4. Add your class to the CoreServiceProvider (optional)

Define the interface

Since you want to change how the ILoggerService (provided by the Commerce API SDK) logs its messages, you will need to provide a new class that tells the app how you want to log messages. In this case, implementing the logger requires additional new class functionality. You create a new interface that defines the other methods needed. Below, you name your new service IOptiLogger, and add EnabledAllLogs(bool) and GetLogText().

public interface IOptiLogger : ILoggerService
{
	void EnableAllLogs(bool enableLogs);
	string GetLogText();
}

Implement

Now that your interface is defined, you will need to implement it. You can browse your implementation by navigating to the Logger.cs class in the CommerceMobileApp.Core/Services/ directory. There you will see that you have overwritten the ILoggerService methods and implemented the new methods inherited from IOptiLogger.

Add to IoC container

In this project, Optimizely uses dependency injection with the help of MvvmCross. If you wish to add your service to the IoC container, or if you are overwriting a service provided by the Commerce API SDK, then you will need to add your service to the IoC container to have it available to be injected. If you want to avoid injecting your new class into ViewModels and Services, and if you have not overwritten a Commerce API SDK service, you can skip this step.

You can register your new class to the IoC container inside the CoreApp.cs class. You will see many other services registered in the CoreApp.cs class, including registering the Logger class as an IOptiLogger.

    Mvx.IoCProvider.LazyConstructAndRegisterSingleton<ILoggerService, Logger>();
    Mvx.IoCProvider.LazyConstructAndRegisterSingleton<IOptiLogger, Logger>();

The above code sample redefines how the API SDK logs, since now you have told the app to use your instance of Logger() whenever an ILoggerService or IOptiLogger object is needed.

Add to the CoreServiceProvider (optional)

📘

Note

If you have overwritten a service included in the Commerce API SDK, then you can skip this step.

By providing two separate Service Providers, CommerceAPIServiceProvider and CoreServiceProvider, Optimizely has created a solution that helps reduce the number of injections of services required by a ViewModel or Service. Both Service Providers provide a single class that returns a specified service instance created by MvvmCross.

The Commerce API SDK provides the CommerceAPIServiceProvider and will give you access to all the services offered by the Commerce API SDK. The CoreService provider is specific to the mobile project and will provide you with access to all of the included services defined in the mobile project.

If you want your new class to be included within the CoreServiceProvider, you must first register your class as a singleton (see the previous step). The next step is to add an accessor method to the ICoreServiceProvider that returns an instance of your new service.

public interface ICoreServiceProvider
    {
        ...
        // List of already existing accessor methods here
        ...
        IMyNewService GetMyNewService();
    }

You will need to implement this new accessor within the CoreServiceProvider class, the implementation of ICoreServiceProvider. Below, you can see how you use MvvmCross to return an instance of the service. Mvx.IoCProvider.Resolve<Type>() will return an instance of the specified <Type> that was registered to the IoC container.

public class CoreServiceProvider : ICoreServiceProvider
    {
        public CoreServiceProvider()
        {
        }
        
        ...
        // List of already existing accessor method implementations here
        ...
        
        public IMyNewService GetMyNewService()
        {
            return Mvx.IoCProvider.Resolve<IMyNewService>();
        }
    }

Again, this step is optional. However, if you skip this step and wish to use dependency injection to get access to your class, you will need to update all of the ViewModel's and Service's constructors to include your new class.

        public ShopViewModel(
            ICoreServiceProvider coreServiceProvider,
            ICommerceAPIServiceProvider commerceAPIServiceProvider,
            IMvxNavigationService navigationService,
            IMvxMessenger messenger,
            IMyNewService myNewService)
            : base(
                coreServiceProvider,
                commerceAPIServiceProvider,
                navigationService,
                messenger)
        {
        }

In the above ShopViewModel, you have added IMyNewService as a parameter. MvvmCross will provide the class registered to IMyNewService in CoreApp.cs.

📘

Note

If you are adding a service to a base class, all other classes that inherit from it will need to be updated to include the additional parameter. This is why Optimizely recommends adding your service to the CoreServiceProvider, which is already included in each ViewModel & Service.


Next

After customizing the SDK, you can deploy your application to the app stores.