Automatically Re-size Height in a Facebook Page Tab App to Prevent Scrolling

Facebook Page Tab Apps allow you to show any web content in an app that displays on your Facebook page.  This could be anything from a contact form to a survey, or even a newsletter signup form.  The content is displayed on Facebook through an IFrame, but it resides on your server, allowing you to connect to any necessary databases or web services to create a rich user experience.

If you have created a Page Tab App, you know that they are restricted to a maximum of 810 pixels in width, but no maximum height is specified in Facebook’s documentation.  During testing, you may find that you have to scroll in both the Facebook window and in the IFrame to view all of your app’s content, resulting in very unfriendly behavior for the end user.

With a small snippet of JavaScript and HTML, you can automatically re-size your Page Tab App’s IFrame to the size of your content.  You just need to include Facebook’s JavaScript SDK and a call to your app’s canvas.

Here is the code:

<div id="fb-root"></div>
<script>
  window.fbAsyncInit = function() {
	FB.init({
	  appId      : '{PASTE_YOUR_APP_ID_HERE}',
	  status     : true,
	  xfbml      : true
	});
	FB.Canvas.setAutoGrow();
  };

  (function(d, s, id){
	 var js, fjs = d.getElementsByTagName(s)[0];
	 if (d.getElementById(id)) {return;}
	 js = d.createElement(s); js.id = id;
	 js.src = "//connect.facebook.net/en_US/all.js";
	 fjs.parentNode.insertBefore(js, fjs);
   }(document, 'script', 'facebook-jssdk'));
</script>

Just include this code on your page and Facebook will automatically re-size your app to the correct height so you no longer have to scroll inside the IFrame. The great thing about the setAutoGrow method is that it sets a timer to automatically re-size your app’s canvas at a 100ms interval, so it will update if you have loaded any dynamic content on your page. Nice and easy!

From the Bookmarks Bar – August 30, 2013

This week from the bookmarks bar I’ve got some interesting new developments in the world of Android development, a great new JS app for chip tune lovers and some great suggestions for front-end developers to promote code reuse.

C++ Compiler for Android

Want to start tinkering with Android applications but not that up to date on Java.  Good news!  Intel has released their own compiler for C++ that generates native Android applications.  Better yet, it is free for the time being.

Band.js: An 8-bit JavaScript Audio Library

Anyone who loves video games is no doubt a fan of the old chip tune music from the days of the NES and Game Boy.  Using a new library, you can create 8 bit chip tunes using only JavaScript and the HTML5 audio API.  Check out the link for some sample tunes from Super Mario Bros., Tetris and Zelda.

Decoupling HTML, CSS and JavaScript

Decoupling is a must with web applications; we have many design patterns that we follow and we split our applications into layers for this purpose.  However, we often think of the view as just one part of that application.  Most web applications have multiple front ends and it helps to be able to reuse HTML and CSS where possible.  Here is a good look at ways to do it.

Thanks for reading!  If you have some great bookmark suggestions please let me know in the comments!

Dynamic Font Size (and other styles) in an Android App

I was recently tasked with adding the ability to change font size globally through the user’s selection in the application settings panel. Android provides accessibility settings on the device level that allow you change the font size for all apps on the device. This is made easy to implement in your app through built-in structures in Android, but documentation is not specific on the most efficient way implement this on an application level. This is likely to be because it is not an encouraged practice, but in my particular case, the requirements were that this needed to be changed in the settings for the application since more options would be available than the standard usability features of Android provide.

SharedPreferences

The key to storing settings in an Android application is SharedPreferences. The examples below do not demonstrate how to write values using the SharedPreferences editor, just how to retrieve them. For more information on writing to SharedPreferences, see this article.

The case against subclassing TextView

Do a quick Google search on implementing a global font size in code and you’ll see many responses suggest to subclass TextView and load the text size options there. Then all you have to do is make sure you use this class for every TextView in your layout. Simple enough, right? Will this work? Absolutely. Is this option going to cause more trouble than its worth as development on your app becomes more complex? Definitely.

The problem here is that many of the Android widgets subclass TextView, such as Button, RadioButton, and CheckBox. Some of these are indirect subclasses of TextView, which makes implementing your version of TextView in these classes a pain. Not to mention the trouble that could arise from migrating to newer versions of Android in the future.

Styles vs. Theming

As you may already know, you set styles for your layouts to control the look and feel of the view. Themes are essentially just collections of these styles. Theming can often be ignored by developers because it is seen more as a method for controlling collections of styles and not just a single style like text size. Many developers think, “I like the default Android theme, so I don’t need to worry about configuring themes.” However, you can use a theme just for text size settings; they don’t need define values for every property. Using a theme over styles provides us with one huge advantage: we can set a theme for the entire view programmatically. Without this, we would have to traverse the tree of children in the view and set each style using the associated property. With multiple properties to change and multiple nested child views, this can get complicated.

Example

First, we need to define the settings in our themes.xml file. This file normally resides in the “res/layout” folder within your application. If it does not exist, you can create it. Here I only use options of Small, Medium and Large, but we could easily add many other options here if necessary. Here is an example:

<resources>
	<style name="FontSizeSmall">
		<item name="android:textSize">12sp</item>
	</style>
	<style name="FontSizeMedium">
		<item name="android:textSize">16sp</item>
	</style>
	<style name="FontSizeLarge">
		<item name="android:textSize">20sp</item>
	</style>
</resources>

Then we will create a class to handle loading our preferences. I called it FontSizeActivity, you could call it ThemedActivity if you are setting more values than just the font size.

public class FontSizeActivity extends Activity {
	@Override
	public void onStart() {
		super.onStart();

		// Enclose everything in a try block so we can just
		// use the default view if anything goes wrong.
		try {
			// Get the font size value from SharedPreferences.
			SharedPreferences settings =
				getSharedPreferences("com.example.YourAppPackage", Context.MODE_PRIVATE);

			// Get the font size option.  We use "FONT_SIZE" as the key.
			// Make sure to use this key when you set the value in SharedPreferences.
			// We specify "Medium" as the default value, if it does not exist.
			String fontSizePref = settings.getString("FONT_SIZE", "Medium");

			// Select the proper theme ID.
			// These will correspond to your theme names as defined in themes.xml.
			int themeID = R.style.FontSizeMedium;
			if (fontSizePref == "Small") {
				themeID = R.style.FontSizeSmall;
			}
			else if (fontSizePref == "Large") {
				themeID = R.style.FontSizeLarge;
			}

			// Set the theme for the activity.
			setTheme(themeID);
		}
		catch (Exception ex) {
			ex.printStackTrace();
		}
	}
}

Finally, we extend our existing Activity classes with the new FontSizeActivity, like this:

public class AppActivity extends FontSizeActivity {

Caveats

Yes, I know. I plead the case against subclassing TextView and then I ended up subclassing Activity for my example. What gives? Think of it this way; you should have a much fewer amount of Activities in your application than you do TextViews or widgets that inherit TextView. This will be exponentially so as complexity increases, so this solution requires less changes in code for you. In addition, the built-in subclasses of Activity are much less commonly used than the subclasses of TextView. You will need to extend those activities as well, but again they will ultimately require less code.

Conclusion

I’ve fought with all of the other ways to allow style based settings in Android and none of them have even come close to being this easy to implement. It is important to consider future changes to your application and this solution handily beats the other options in that regard. Thanks for reading.