2014-05-25

Convert html page to mobi

Introduction

Sometimes I want to read webpage on my kindle. There are many pictures and source code blocks on this. What can you do? You can print webpage as pdf, but this is not good idea, because you cannot scale such document on kindle. Mobi is better file format so there must be better option and indeed is.

Kindlegen

Amazon provides little program called kindlegen, which could convert html, epub and some other formats to another and there is mobi. You have to save webpage with all css files and images somewhere on your disk. You could do this for example with Google Chrome, just push CTRL+S and select place. Now you should have html file and directory name like your html file without extension, but with _files suffix. For example I have download this webpage on my desktop and I have file Przybysz Dominik TechBlog.html and Przybysz Dominik TechBlog_files directory.
To use kindlegen you need all css and image files placed in the same directory as html file, so all local links from html files have to have deleted prefix describing directory. For example I have deleted ./Przybysz Dominik TechBlog_files/ from all src atributtes and moved html file to directory with other files.
Now you could use kindlegen:
kindlegen Przybysz\ Dominik\ TechBlog.html -o blog.mobi
Now your mobi file is ready to be placed on you kindle.

Conclusion

With one simple program you could convert any webpage to mobi format and read it on your kindle.

2014-05-17

Guice Tutorial - 09 - Providers in modules

Introduction

Module in Guice is not only a place where binding are defined. It also could have definition of many providers inside.


Provides

Suppose we have quiz class which has to be initialized before usage by call of method init.
public class Quiz {
    private boolean initialized = false;

    public boolean initialized(){
        return initialized;
    }

    public void init(){
        initialized = true;
    }
}
Provider is quite simple, because it only creates Quiz object and call method init, so we define it inside module.
public class QuizModule extends AbstractModule {
    @Override
    protected void configure() {}

    @Provides
    private Quiz getinitializedQuiz(){
        Quiz quiz = new Quiz();
        quiz.init();
        return quiz;
    }
}
Provides annotation tells Guice that annotated method is provider for its return type. Provider could be defined in this manner only in module.
Let's test it:
@Test
public void shouldClassInstanceFromProvider(){
    //given
    Injector sut = Guice.createInjector(new QuizModule());
    //when
    Quiz quiz = sut.getInstance(Quiz.class);
    //then
    assertTrue(quiz.initialized());
}

Conclusion

If you have to define provider, but you do not want to have separete provider class, than you could create method which acts like provider in your module. Sources are available here.

2014-05-10

Guice Tutorial - 08 - Combine modules

Introduction

Single injector could be created from many modules, so dependecies could be separeted depends on their domain.


Combining modules

Suppose you have two modules. One describes classes using to talk with database and second provides classes for frontend. For database there are SessionFactory interface with its implementation - SessionFactoryImpl. The bining is defined in DatabaseModule.
public interface SessionFactory {}
public class SessionFactoryImpl implements SessionFactory {}
public class DatabaseModule extends AbstractModule {
    @Override
    protected void configure() {
        bind(SessionFactory.class).to(SessionFactoryImpl.class);
    }
}
Widget interface is bound to LabelWidget iFrontendModule .
public interface Widget {}
public class LabelWidget implements Widget{}
public class FrontendModule extends AbstractModule {
    @Override
    protected void configure() {
        bind(Widget.class).to(LabelWidget.class);
    }
}
We want to have injector, which uses this two modules, so we could create it in this way:
@Test
public void shouldJoinTwoDisjointModules(){
    //when
    Injector sut = Guice.createInjector(new DatabaseModule(), new FrontendModule());
    //then
    assertNotNull(sut.getInstance(SessionFactory.class));
    assertNotNull(sut.getInstance(Widget.class));
}
One constraint is that combined modules cannot have bindings for the same classes or interfaces.


Overriding modules

Suppose you have TestSessionFactoryImpl that you want to use in your tests.
public class TestSessionFactoryImpl implements SessionFactory{}
Binding for tests is defined in TestDatabaseModule.
public class TestDatabaseModule extends AbstractModule {
    @Override
    protected void configure() {
        bind(SessionFactory.class).to(TestSessionFactoryImpl.class);
    }
}
Tring to combine this module with your DatabaseModule ends with CreationException.
@Test(expected = CreationException.class)
public void shouldThrowExceptionWhenJoiningTwoModulesWithTheSameBindings(){
    Guice.createInjector(new DatabaseModule(), new TestDatabaseModule());
}
To not obtain CreationException you should tell Guice that you want to override bindings of DatabaseModule with your TestDatabaseModule.
@Test
public void shouldOverrideModule(){
    //when
    Injector sut = Guice.createInjector(Modules.override(new DatabaseModule()).with(new TestDatabaseModule()));
    //then
    assertEquals(TestSessionFactoryImpl.class, sut.getInstance(SessionFactory.class).getClass());
}

Conclusion

You can combine many modules during creation of injector, but only if they have no bindings for the same classes. If they have, you have to explicitly tell Guice which module overrides bindings in another module. Sources are available here.

2014-05-01

Guice Tutorial - 07 - Module

Introduction

So far, we was using only annotations and creating injector without giving any parameters. It could be possible, because we was using classes defined by us or having no-arg constructor. But sometimes we have to use classes from external library, which do not meet these conditions. With the help comes to us Module.

Module

The module is an interface which has only one method - configure, where bindings could be defined. Binding is a form, which tells injector how to obtain instance of class that we ask for. It looks like this: bind(class).toSth(...). The best way to have defined bind method in your module is extend AbstractModule class.
public class MyModule extends AbstractModule{
    @Override
    protected void configure() {
        //...
    }
}
Module is the main definition for injector and when something is undefined then it also use bindings defined via annotations. Important is that module always overrides annotations, for example when class has annotations and module defines binding for it, then module binding is used.

Binding to constructor

First binding tells how to obtain class using constructor and there is method toConstructor where you could pass a constructor:
try {
    bind(FirstClass.class).toConstructor(FirstClass.class.getConstructor(Dependency.class));
} catch(NoSuchMethodException e) {
    // But i know it exists
    e.printStackTrace();
}
FirstClass class (and almost all class used in examples) looks like this:
public class FirstClass {
    private Dependency dependency;

    public FirstClass(final Dependency dependency) {
        this.dependency = dependency;
    }
}
It is not so easy to define constructor in this way so if I could I use Inject annotation, which means the same.
public class SecondClass {
    private Dependency dependency;

    @Inject
    public SecondClass(final Dependency dependency) {
        this.dependency = dependency;
    }
}

Binding to provider

We are using Provider to prepare class and module changes nothing, but we could replace ProvidedBy annotation in class with toProvider method in module:
bind(ThirdClass.class).toProvider(ThirdClassProvider.class);

Binding to instance

Of course, you could create one instance of class and want to pass it to every class, which could use it. We bind it using toInstance.
bind(FourthClass.class).toInstance(new FourthClass(new Dependency()));

Binding to concrete implementation

When we want to inject concrete implementation for interface or abstract class we have been using ImplementedBy annotation. In module we could simply use to and tell which class we want to bind to it. Of course, we have to define how to obtain this class (in module or via annotations).
bind(SomeClass.class).to(FifthClass.class);

Using scope

We could define that we want the class to be the singleton via annotation Singleton, so in module we should have this possibility too. And we have. We could tell in which scope class should be using method in at the end of each binding. For example:
try {
    bind(SixthClass.class).toConstructor(SixthClass.class.getConstructor(Dependency.class)).in(Singleton.class);
} catch(NoSuchMethodException e) {
    e.printStackTrace();
}

Conclusion

Annotations and module could be used to describe how injector should create instances of classes that we ask for. But annotations could be placed only on our classes, while module could describe creation for each class and is more important for Injector than annotations. 
All sources are available here.