Consider using other 3rd party widgets

[NeverGivinUp]

Carbon is a great feat. But (so far) it is incomplete. Consider using /building upon other 3rd party widgets. Or enable Carbon users to easily carbonify widgets, e.g. by providing an easy to use pre processor.
Regarding EditText for example, MaterialEditText's implementation (https://github.com/rengwuxian/MaterialEditText) currently is better than the Carbon implementation. It is work in progress though (e.g. the baseline adjustment does not work correctly yet).

On top of the added flexibility this would also reduce the Carbon codebase, thus making it more stable and easier to maintain.

[ZieIony]

While having a preprocessor is a great idea, I don't think that it's possible due to complexity of Carbon's widgets. Most of them is tightly integrated with other parts of the library to provide the best compatibility with all Android versions and offer good performance and quality. I was thinking of a preprocessor for duplicated parts of code, but my approach failed badly long time ago.

Carbon uses AppCompat's libraries for RecyclerView, GridView and NineOldAndroids for older devices support. All of them are very general and it's eary to fit them in one library.

I'm aware of that there are fine libraries offering very good implementations of Dialogs, EditTexts, PTR pattern and others. I'm not trying to surpass them, but provide a consistent interface for all MD-related things for all Android platforms. Other libraries libraries often lack hardware ripples, realtime shadows or doesn't support for pre-Honeycomb versions. Because of that I think that including other libraries and translating Carbon's calls and attributes for them misses the point. I think that it's the end user who should pick other implementations of certain widgets if the Carbon's version is not sufficient.

[NeverGivinUp]

What you say makes a lot of sense to me. How about this then: If the end user should pick different 3rd party she needs a way to integrate them. Especially the hardware ripples, and real-time shadows. From my understanding of Carbon, you created a lot of interfaces, which widgets must implement, so that the layouts in which they are embedded grant them the features. If translating Carbon's calls and attributes can't be done with preprocessors, it needs good documentation and tutorials.

I think my original point about a reduced code base, added stability and maintainability holds whether 3rd party libraries are integrated by preprocessor or end user. Easy Integration of 3rd party widgets frees you from the need to produce a complete set of good widgets. It allows you to focus on the core material designishness (elevation & z-order, ripples and fonts -- considering that animations are more or less given and tinting is something each widget must allow on its own). And it seems you already mastered that beautifully, supporting even old versions of Android.

At the current state of Carbon (and Carbon's documentation) its not exactly easy to integrate 3rd party widgets -- at least not for me (It really might be my lack of understanding). Just thinking of writing a carbonified version of my recycler view layout manager weakens my knees...

[ZieIony]

Good point. Let's leave this issue open, I need to think about it.

[ZieIony]

I'm working on a tutorial/article explaining how to use Carbon with other libraries. Is there any specific library/component you'd like to have explained? I'm not sure what would be the most useful for the users.

[NeverGivinUp]

It's not just a single part that needs explanation. It's also the whole. You created Carbon and have a very good understanding of material design. So the points in the following list come to even without thinking. But for someone who has less experience programming and styling Android, knows material design not as deep and does not know Carbon's architecture carbonifying her 3rd-party elements is quite intimidating.

Design goals of Carbonification

• key elements of material design (mostly links to Google's documentation)

Walk through the architecture

• the meaning of key classes and interfaces regarding the implementation of the above elements of material design
• which class/interface is used by what component on which trigger.
• description of the key classes interfaces.

Styling

• which theme attributes / styles should be evaluated for a consistent image -- this is a very important subject that is badly neglected by Google's documentation. So, ideally, any relevant android standard styles/attributes should appear here as well.

Examples, which illustrate the easiest way to implement the required interfaces/classes (as opposed to more complicated or plain wrong and ugly ways)

• carbonification of a simple view, like a button
• carbonification of a layout, which enables carbonified views

Architecture and styling should be the biggest parts, in my view.

Personally I have (at least) two carbonification tasks: Carbonifying the SeekBar and this floating action menu (I have carbonified the button already).

[ZieIony]

Thanks for the comment, lots of cool ideas! As you probably noticed it's hard for me to pick and document all unclear things, because I know MD and Carbon pretty well. That's why your explanation is very useful/important. Seems like a tutorial is not enough. It would be better to prepare a bunch of wiki pages explaining Carbon's structure and principles.

If you wish, you can help me with that. Wiki for this project is open and you can create pages. When you find something missing, feel free to create a placeholder page.