Naming conventions

[Zordid]

I notice, that the naming conventions of member fields, local variables and parameters are wildly mixed in the code.

In Android, it's convention to use the prefix "m" for member fields only, not for local variables. In your code, sometimes you have member fields without any prefix but also some local variables have an "m" prefix.

Makes your code hard to read and understand. I would offer help, but I am new to github and don't know how to contribute...

[JohnPersano]

Sordid, thanks for the input I didn't know all that. I thought m stood for "my" as I have seen in other code You would have to fork the repository, make the changes and send me a pull request. Would you mind explaining the member field vs local variable thing a bit more in depth? I'm afraid I don't fully understand it.

[Zordid]

Hey John, as far as I know the only basic rules for naming in any Android project are listet here:
http://source.android.com/source/code-style.html#follow-field-naming-conventions

Of course, it's always a matter of taste, but I would suggest for some public Android library it's kind of good to stick to these convention just as the Android core Java programs do.
In short the rule I was referring to is stated here:

Follow Field Naming Conventions

• Non-public, non-static field names start with m.
• Static field names start with s.
• Other fields start with a lower case letter.
• Public static final fields (constants) are ALL_CAPS_WITH_UNDERSCORES.

One other thing I noticed when I forked your code and applied some renaming changes was that my code style setting like line length and so differ from yours as well. On the page linked above you also find common code style settings that I would guess can help keep shared code like here on GitHub manageable for multiple contributors.

Hope that helps?

[JohnPersano]

Thanks! I've never actually seen this page before. I'm rewriting some of the library now, I will be sure to use these rules.

[Zordid]

Great! When you decompose and re-organize, maybe you could also give a common creation method to all of your toasts. Like when I understood how to get a normal SuperToast, I was not able to apply this to the SuperButtonToast and I didn't know why.
Plus: I would not include all the Roboto font stuff into your library at all. Just give the setTypeface methods and that's it. Keep your library focused on what it does.

[JohnPersano]

I was looking for an excuse to remove the Roboto stuff and now I have it lol! I just put that in there for an "all-in-one" package kind of effect. I'm nitpicking through the SuperActivityClass right now, I have addressed the creations issue yesterday and after a little polish I will push it on here. While were on the subject I was wondering if you could answer a question for me. You know how sometimes an IDE will tell you something about the methods you are using? For instance if you call a Toast and do not add the show() method your IDE will underline the code and basically say "Hey you didn't call show!". Do you know how this is achieved? I could not find this on Google.

[echthard]

The answer to the last question is: done by Lint I guess.You can find several articles of how to write custom Lint rules.

[JohnPersano]

Thanks, now I know what to search for!

[Zordid]

Hi John, sorry for late answer - Lint is the correct answer. I am not sure whether you could supply a set of own rules to Lint to enable it to detect this with SuperToast, too. But, that's not really critical, I guess. :)