-
Notifications
You must be signed in to change notification settings - Fork 500
Migrating from version 1.3.4 to 2.0
Version 2.0 is a major update for the SuperToasts library. It is so major, only a very few scraps of version 1.3.4 code will remain in the project. Unfortunately, this means that developers currently using the library will have to adapt to some significant changes to the API.
The biggest, baddest, and almost certain to break your code changes are listed below.
If you happened to be using them, you will notice that SuperCardToasts have been completely removed from the library. Wait, before you send me a less-than-friendly email let me explain myself here.
SuperCardToasts were fundamentally SuperActivityToasts that lived within a ViewGroup container right? That's a rhetorical question, I assure you they were. Coincidentally, one of the most frequent requests I received was to add the ability to specify a ViewGroup for a SuperActivityToast. Do you see where I'm going with this? Instead of having a separate class professing itself to be a SuperActivityToast in a container, I decided to "absorb" the functionality of SuperCardToasts by the SuperActivityToast class by allowing a ViewGroup parameter to be specified.
To create a "SuperCardToast" in version 2.0, add a LinearLayout to your layout file and use the following code:
new SuperActivityToast(YourActivity.this, Style.grey(), Style.TYPE_STANDARD, R.id.card_container)
.setText("I look like a SuperCardToast!")
.setDuration(Style.DURATION_LONG)
.setFrame(Style.FRAME_STANDARD)
.show();That's it! I should note that you are not restricted to use the @+id/card_container for your layout container anymore, I used it here for simplicity.
Please note however, the ability to stack messages with SuperCardToasts has been removed from the library. Not only does showing multiple messages make your UI more complex for the user, its not good practice. Don't over-toast!
No matter if you were using a SuperToast or SuperActivityToast in your code, version 1.3.4 constants are not compatible with version 2.0 parameters. I realize this may be aggravating, so grab a hot chocolate while I attempt to explain why I decided to change it.
Blame the SuperActivityToast class. SuperActivityToasts do not remain on the screen if the device changes orientation, so I had to come up with a way of saving and re-showing them to cope with orientation changes. Parcelable to the rescue! With some extra code in their Activity, a developer can now be rest assured that any SuperActivityToasts that were showing or in queue before an orientation change will be re-shown when the device recovers from the orientation change. Since I did not want to break existing functionality, I created an inner class that duplicated each attribute and then saved them to a Bundle. Upon recovering from an orientation change, the Bundle gets ripped open and each SuperActivityToast finds his/her way back onto the screen.
Duplicating each attribute (eg. text, background color, text size, etc.) just to send them through a Bundle creates twice as many objects as necessary. In version 2.0, a dedicated Style class handles every attribute. When you change the background color of a SuperToast, you are effectually changing a reference in a Style object. When a SuperToast is shown, it asks its Style partner what size, shape, and/or color everything should be. What does this mean?
Every constant parameter is now stored inside the Style class.
I put that sentence by itself in case you didn't read the above few paragraphs and just wanted a short answer.
No functionality was harmed during the coding of this update. Whatever method you were using most likely still exists, so try typing part of it and let auto complete fill you in. Very few methods were actually removed from the library. If they were, they probably served little or no purpose. If they did serve a purpose, open a feature request and let me know.
The not as big, not as bad, and almost certain to never break your code changes are listed below.
Unless you are actually using an incorrect parameter, like trying to pass a List<Drawable> through the String.valueOf() method, your code will still run. These errors may show up from time to time if you try to avoid using the constants provided in the Style class. I tried to limit the parameters you can pass by using the wonderful Android support annotations. I didn't make the constants just to give you default values to use, they exist to provide some form of consistency across applications that use this library.