Make your app work on Samsung Galaxy Tab

Dec 7 2010

We knew tablets would be great platform for code edititing with touchqode. So we put some effort into making it work great on Galaxy Tab and here are the learnings we found along the way.

Target at least Android 1.6 (yet you can support 1.5 too)

We thought - we are great programmers and Android is magical platform so touchqode will work cool on Galaxy Tab straight away. Sure it was not.

First - the app did not scale its size at all. We saw funny little app huddled in the middle of the screen instead of full 7 inches of cool mobile IDE.

The reason was we target older phones as well (particularly my HTC Hero with Android 1.5 Cupcake). As the result touchqode had the following line in AndroidManifest.xml:

<uses-sdk android:targetSdkVersion="3" />

Which was wrong - Android only acquired ability to support multiple screen resolutions in version 1.6 Donut (API Level 4). The solution is:

<uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4" />

This tells the compiler you ideally need an API level 4 (Android 1.6) but can live with API level 3 (Android 1.5) as well. If you are working in Eclipse you also need to set Project Build Target to 1.6 (go to project properties -> Android -> Project Build Target). Just be careful not to use methods with API level higher than 3.

Now your app should be automatically stretched to full screen on the Tab. For more documentation see http://developer.android.com/guide/appendix/api-levels.html .

Support multiple screens

Once the app was correctly scaled we noticed that buttons and menus were significantly blurred.

Reason - Android is trying hard to make everything look good. But when it scales your ordinary tiny resources from 48 to 72 pixels there is no way for them to look sharp. The only solution was to dive into this great tutorial by Google: http://developer.android.com/guide/practices/screens_support.html and tweak the app.

Here are bits I took away:

• use

  <supports-screens
  android:largeScreens="true"
  android:normalScreens="true"
  android:smallScreens="true"
  android:anyDensity="true" />
  

  in your AndroidManifest.xml That way Android will know that you can support all kinds of screens.

• If you still want to support Android 1.5 you will need following directories for drawables:

  res/drawable-hdpi-v4
  res/drawable-mdpi-v4
  res/drawable-ldpi-v4
  res/drawable-v3
  

  The point is Android 1.5 will not recognize drawable-hdpi as resource directory (remember - support for multiple resolutions only since 1.6). You need to put all your mdpi resources to drawable-v3 as well.

  I actually do not remember if -v3/-v4 suffix (indicating which directory to use in which api level) is really needed. It probably helps to avoid conflicts between drawable-nodpi and drawable. Also it is the way that works, makes it explicit for Android which drawables to choose and generally makes me feel less worried.

• Use device independent pixels (dp) in your layouts (e.g. width="100dp"). Fill parent, wrap content and gravity are also your friends. Text should be of course in scaled pixels (sp).

  We have been using dp since the beginning (btw. Google is stressing it on multiple places in documentation). Thanks to that, once we had the size scaling and drawables sorted out, touchqode started working as expected on the larger screen.

• Scale from device independent pixels (dp) to physical pixels in your code - this one was not obvious at first. All the widths, heights and positions you get from code are in physical pixels. If you have constants (that are presumably in dp) in your app you need to scale them by density:

  float scale = context.getResources().getDisplayMetrics().density;
  // maximum length we still consider touch and not movement
  maxLongTouchDistanceSquared = (int)(maxLongTouchDistanceSquaredDip * scale + 0.5f);
  

  Before we found out this caused us a bit of headache - the long touch was overly sensitive to movement and scrolling felt jittery. Simple two lines to adjust constants saved the day.

Adjust layout for larger screen

While it made little sense to use portrait layout for the phone screen it makes whole lot of sense on Tab. The screen is now large enough to accomodates full width of line even in portrait mode. Additionally widescreen Tab is a bit awkward to type on in landscape at first (this is matter of habit - now I can type really fast and comfortably in landscape).

We wanted to move the main buttons (view, edit...) from the left side to the bottom of the screen in portrait mode. I was considering programmatically modifying the layout but then found much easier solution.

Say our main layout is called editor.xml. You then need following structure in your project:

res/layout/editor.xml
res/layout-land/editor.xml

Android automatically uses layout appropriate for current configuration (layout is default fallback for any orientation, layout-land is for landscape orientation). The drawback is you have to maintain two layouts. Our main layout is simple enough to be maintained this way and in the future portrait and landscape layouts might easily diverge. But that one is still a matter of experimentation.

Your problems are bigger

Yes - the bigger the screen the more apparent are problems in the layout. Thanks goes to one of our users who notified us on fuzzy and unaligned keys in Programmer Keyboard on high resolution.

I must admit the images for keys were done in quite a rush so they weren't correctly aligned/sized. It was not much of a problem on small screens. On higher resolution and larger screen the result was completely terrible.

The only solution - get back to Inkscape templates, set proper grid lines and correctly align and resize all keys.

At the end of the day using proper APIs and adhering to documentation helps a lot to make your app look good on multitude of devices. To sum it up:

• Do not forget <use-sdk minSdk="3" targetSdk="4"/> in AndroidManifest.xml
• Support multiple screens (and read documentation)
• Adjust layout for larger screen
• Carefully align everything

Touchqode can now take the advantage of extra real estate on the screen. Which leads to easier code navigation and editing. Which leads to better general experience for our users. And that is worth the effort.

These were our personal experiences in adjusting app for Samsung Galaxy Tab (and generally any high resolution/large screen device). You might also want to check out Samsung write up: http://innovator.samsungmobile.com/galaxyTab.do

If you have any comments please tell us or check out the app we have been talking about.

Touchqode team.