Johannes is the co-founder of Three days ago, madvertise, one of my favourite ad networks, updated its Android SDK in a major update to 2.0. So what changed and what’s new? Here is an overview over the major changes.
First of all, get the new SDK here.
How to make it work again: Renamed classes
When updating the new SDK, there are some minor changes a developer has to consider.
In order to make the naming of the SDK for iOS and Android equal, the names of the classes have been changed. Every class that started with ‘Mad‘ before now starts with ‘Madvertise’. So the MadViewCallbackListener is now called MadvertiseViewCallbackListener and the MadView is now called MadvertiseView. Accordingly, the method to set the MadvertiseViewCallbackListener is now called setMadvertiseViewCallbackListener(), not setMadViewCallbackListener().
The MadvertiseViewCallbackListener now has two more callback methods:
public void onError(Exception exception)
which will be called when an exception in the SDK occurs and
public void onIllegalHttpStatusCode(int statusCode, String message)
which will be called when the madvertise-Server returns something different than a HTTP status code 200. The code you will probably see the most is a 204, which means that the device requesting an ad is not yet known to the madvertise-Server.
Also, the banner-type ‘iab’ has been renamed to ‘medium_rectangle’. However, at the moment ‘iab’ still works.
When you included all these changes, everything should work fine again.
New functionality
The update of the SDK adressed some bugs many of you experienced. Here is an excerpt:
- Requests are now interrupted when a MadvertiseView is destroyed.
- No reloading of ads when a phone is turned, keyboard is being opened, and so on, anymore.
- Banners are scaled correctly now.
- Before, when the request interval was set to <60, it was adjusted to 30 automatically.
- The width of a MadvertiseView was sometimes not calculated correctly
There are also some improvements where you have to do nothing to activate them:
- Animated banners: Ads provided as animated GIFs are now played when the device is capable of doing so.
- Banners are shown automatically now, so you don’t need a MadvertiseViewCallbackListener to make your ads visible anymore.
- Ads now don’t acquire space in the layout before they are shown.
- Multiple ads: You can now display more than one ad on a screen, for example one fixed on top and one in a list. However, the total number of ads on a screen should not exceed four.
And there are some new features you should think of when integrating the new SDK:
- New banner formats – you can now display the following banner types:
- mma (320×53)
- medium_rectangle (320×200)
- leaderboard (728×90)
- fullcreen (768×768)
- portrait (766×66)
- landscape (1024×66)
- Multiple banner formats – you can now request multiple banner formats in your XML-declaration of a MadvertiseView like this:
<de.madvertise.android.sdk.MadvertiseView android:id="@+id/madad" android:layout_width="match_parent" android:layout_height="wrap_content" mad:isTestMode="false" mad:backgroundColor2="#000000" mad:textColor="#FFFFFF" mad:bannerType="mma,portrait,landscape,leaderboard" mad:deliverOnlyText="false" />
The list is sorted by priority. So in the above example, when there is no mma-banner available, a portrait-banner will be shown, when there is no portrait-banner, a landscape-banner will be shown, and so on.
- Animations: Ads can now be animated when they are received. To add an animation, add
<attr name="animation" format="string" />to your attrs.xml file. Now you can set animations in your XML-layout using mad:animation. You can choose between fade (default), left_to_right and top_down. - New request parameters: You can set the gender and age of your users by calling MadvertiseView.setGender() or MadvertiseView.setAge(). As these methods are static, it is recommended to call them before your layout is inflated.
Conclusion
The new madvertise SDK comes with some nice new features and bug fixes. The new formats are suitable for tablets and phones with large screens like the Galaxy Nexus. I’m curious whether the animation banners and animation of new banners will lead to more clicks.
Please feel free to leave your thoughts and questions on the new update in the comments below.
Tutorial: How to play animated GIFs in Android – Part 2
Animated GIFs in Android is a difficult topic. It is an issue that has been discussed heavily and still, it is very difficult for developers to bring GIFs to life. There are three ways to animate GIFs on Android, each of them has its pros and cons. Each part of this series will cover one of these approaches.
Getting started
For this example, we will use an image I found on gifs.net, it’s this one:
I will store it in our project’s asset folder and name it ‘piggy.gif’. We will also use an Activity to set the views we define as content views. If you want to know everything about playing GIFs, please start at part one.
Approach 2: Extracting the Bitmaps
For this approach, we will use the GifDecoder class published here on googlecode. It’s Apache licensed, so don’t worry. What this class esentially does is, it extracts the different bitmaps from the given stream so you can use it the way you want.
To get started, download this class first. Place it somewhere in your project, maybe in a util package.
Now, we create a new class which inherits from ImageView:
We create a constructor with a Context and an InputStream, just like in the first part of this series. This time, we call a method playGif(InputStream) and pass it our InputStream:
public GifDecoderView(Context context, InputStream stream) { super(context); playGif(stream);We give our class five member variables: A boolean which will state whether the thread we will use to play our animation is runningor not, an instance of the GifDecoder-class you just downloaded, a Bitmap which stores the different frames of the animation, a Handler to post our updates to the UI-thread and a Runnable that will arrange that the Bitmap we just defined will be drawn using the Handler:
private boolean mIsPlayingGif = false; private GifDecoder mGifDecoder; private Bitmap mTmpBitmap; final Handler mHandler = new Handler(); final Runnable mUpdateResults = new Runnable() { public void run() { if (mTmpBitmap != null && !mTmpBitmap.isRecycled()) { GifDecoderView.this.setImageBitmap(mTmpBitmap); } } };Let’s take a look at playGif(InputStream). First, we need to initialise mGifDecoder. After that, we let it read our stream and set mIsPlayingGif to true, so that our thread can run:
private void playGif(InputStream stream) { mGifDecoder = new GifDecoder(); mGifDecoder.read(stream); mIsPlayingGif = true;Now we need to define our thread. We retreive the frame count of our GIF’s frames and the number of repetitions. When GifDecoder.getLoopCount() returns 0, this means the GIF should be played infinitely. Now for every frame, we receive the according Bitmap by calling getFrame() on the GifDecoder. We post our new Bitmap using the Handler and Runnable members we defined and send our thread to sleep until the next Bitmap needs to be drawn.
new Thread(new Runnable() { public void run() { final int n = mGifDecoder.getFrameCount(); final int ntimes = mGifDecoder.getLoopCount(); int repetitionCounter = 0; do { for (int i = 0; i < n; i++) { mTmpBitmap = mGifDecoder.getFrame(i); final int t = mGifDecoder.getDelay(i); mHandler.post(mUpdateResults); try { Thread.sleep(t); } catch (InterruptedException e) { e.printStackTrace(); } } if(ntimes != 0) { repetitionCounter ++; } } while (mIsPlayingGif && (repetitionCounter <= ntimes)) } }).start();That’s it. All we have to do now is use our GifDecoderView in an Activity, just like we did in the last part of this tutorial:
// ... InputStream stream = null; try { stream = getAssets().open("piggy.gif"); } catch (IOException e) { e.printStackTrace(); } // GifMovieView view = new GifMovieView(this, stream); GifDecoderView view = new GifDecoderView(this, stream); setContentView(view); // ...Now, what’ the bad thing about this? It’s the memory footprint. Bitmaps on pre-Honeycomb-devices are stored in an native heap, not in the heap the Dalvik VM uses. Still, this heap counts to the maximum of memory your app can use. So when you have a lot of Bitmaps, the garbage collector might not notice that you are running out of memory because it only controls the heap of the Dalvik VM. To avoid this, make sure you call recycle() on every Bitmap you don’t need anymore. If you want to see how much space your native heap allocated, call Debug.getNativeHeapAllocatedSize().
If you want to know another, maybe better way of playing animated GIFs, stay tuned: The next part of this series will come soon.
You can checkout the code of the three parts of this series at http://code.google.com/p/animated-gifs-in-android/.
As always, please feel free to leave your thoughts in the comments.