[Suggestion] Overhaul of AppIntro

Issue details: So, Since I have some free time at my disposal, I was thinking of revamping the API a bit and making it more customizable. I suggest that instead of having the two classes AppIntro and AppIntro2, we just have these 2: SimpleIntro and CustomIntro. If the user wants just a simple solution we provide SimpleIntro and allow the user to change layout type by using setLayoutType(LayoutType1/2), and provide other methods to change the colour/icon of layout defined in AppIntro. For more sophisticated solution, we provide a CustomIntro class that allows the user to provide their own layout file(with correct ids set for required buttons I.e. next button, skip button etc) via setLayout(R.layout.custom_layout) . It will allow users more freedom to choose their layout and spend more time on design while AppIntro does the heavy lifting (Controlling indicators, managing page swipes, permissions etc.) This will give users more flexibility. I am opening this issue to discuss about this before I touch any code so that I can get an idea of the implementation. So tell me your thoughts on this and I will try to implement ASAP ( I have successfully made some partial implementations as a proof of concept so it ought to work…)

Your Code: Nothing Yet

It will be easier to make layouts like this and this

Also, I have put my work on the sample app on hold as it is better to rework the app after we rework the library 😛

[cortinico]

Okay, I get it that ids are hard to enforce, but there are only a handful of trivial ones here, and we could just mention them in readme.

The README is getting less updated than the code. Moreover people just bump the library, without reading the readme every version.

We need to create atleast some sort of implementation that gives users more freedom to choose the positions and shapes/sizes of their buttons.

I’m generally against this. Libraries should be simple and solve simple tasks.

Big APIs are hard to handle. Giving the full control over all the widgets, will make the library developer life harder, for the benefit of a little group (users tends to use the default layout of the library).

The basic idea is more control over the AppIntro layout, otherwise I don’t think there is a way that we can currently make layouts like the ones mention in the first post using this library.

I don’t think this library has to solve this problem actually.

[AnuthaDev]

Hey @cortinico if you think enforced ids are bad, then along with setLayoutRes(@layoutRes) we can also expose methods : setNextBtnRes()/setNextbtnid(). Or something like that, which basically tells AppIntro which view is defined as next BTN, back BTN etc. So that it can manage their behaviour accordingly…Also, instead of removing the AppIntro and AppIntro2 classes we just have to deprecate them or at first we will introduce these classes along with them and deprecate in future, so no breaking API changes and more customizability… What do you say? Problem solved?