Archive for July, 2011

Installing Android apps to the SD card

Thursday, July 28th, 2011

Editor’s note: This blog post is a basic tutorial, a more update version of this tutorial is always available on the wiki.

Your Android apps are installed by default to the device’s internal storage. But that limited space can fill quickly, especially on older devices like my Motorola Droid original. Fortunately, you can configure your Titanium apps to install to the SD card.

To do so, you need to modify the AndroidManifest.xml configuration file. Titanium makes this easy: you simply update your tiapp.xml file and Studio will take care of creating the necessary manifest file. Locate the <android> node near the end of that file. You’ll need to add a couple of properties and tags. When you’re done, it should look like this:

Build and deploy your app to a device. As the screenshot shows, your app should be installed to the SD card (though that’s not guaranteed, read on).

Let’s go over that code, because you can control a few options. First, the <tool-api-level> node specifies the version of the Android development tools that will be used to compile your app’s code. At minimum, you must specify version 8. Higher (newer) versions aren’t necessary for installing to the SD card, but perhaps offer other benefits.

Next, is the <manifest> node and the android:installLocation property. You’d choose one of these values for that property:

  • android:installLocation="preferExternal" — specifies that you prefer your app to install to the SD card, but if one isn’t present the app can be installed to internal storage.
  • android:installLocation="auto" — specifies that the phone’s configuration will determine the installation location. Generally, your app will be installed to internal storage if sufficient space is available. In that case, users could still move your app by opening Settings > Applications > Manage applications, tapping your app, and tapping Move to SD card.
  • android:installLocation="internalOnly" — which specifies that your app cannot be installed to the SD card. See the Android docs for the various reasons why you might choose this option.

Finally, you need to add the <uses-sdk> tag within the <manifest> node. This tag specifies that your app requires Google’s version 7 or newer APIs — in other words, the phone must be running Android 2.1 Update 1 or newer. That pretty much covers all the newer phones, but will exclude some older devices. On those phones, your app will install to the internal storage.

Keep in mind that even if your app is installed to the SD card, application data (such as your database) will still be stored on the device. For more details, visit this Android docs page.

Win $10,000 at our Developer Conference Hackathon!

Tuesday, July 26th, 2011

We’re kicking off our CODESTRONG hackathon in a big way by awarding $10,000 to the best mobile app! The hackathon is open to all CODESTRONG attendees, and will look for innovative mobile apps for iOS, Android, and Blackberry. In addition to the $10,000 first-place award, the top ten most innovative and useful apps will receive other cash and prizes.

Don’t forget to let your friends know so they have a chance to win $10,000 (or get them on your team to help you win) – share the CODESTRONG $10k Hackathon on Facebook, Twitter, and LinkedIn with the hashtag #codestrong.

Register for CODESTRONG today and save $100 on your ticket!

Android Window Orientation behavior change for 1.7.2

Monday, July 25th, 2011

With the release of Titanium Mobile SDK 1.7.2, we are making some changes to orientation behavior focused mainly on Android. These changes bring the behavior more in line with how orientation works in a native app and enhance our support for tablet and 3.x (Honeycomb) devices.

In order to understand the driving force behind the changes, it is important to understand the orientation behavior on Android.  There are a few key things to remember when dealing with orientation in Android:

1)  Orientation values that can be requested go beyond the values that get reported back when orientation actually changes.  For example:  when setting orientation in a native app, you may be able to ask for reverse portrait or reverse landscape but Android itself will only report whether the orientation is portrait or landscape – not the specific type of portrait or landscape.  On many devices you can make assumptions regarding the sensor degrees of the device and do a little math to determine the orientation but that brings us to the next point…

2)  Orientation values do not match up to sensor degrees across all devices.  For example:  on a Droid 2, portrait mode (the primary mode) is when the “top” of the device is at the 0 degree position and landscape mode (secondary mode) is when the “top” of the device is at the 270 degree position.   On a Xoom however, landscape mode (the primary mode) is when the “top” of the device is at the 0 degree position and portrait mode (secondary mode) is when the “top” of the device is at the 90 degree position.  Note the difference in the secondary modes.  Due to the hardware configuration of the device (location of the camera, etc) the position of a certain orientation mode may not be exactly where you expect it to be.

Given this understanding, its important to mentally break apart the values you use when setting orientation versus the value you get when requesting orientation.  The value you get when requesting the current orientation is geared more toward the general orientation of the device (useful for knowing what resources to use).  The values you use to set orientation are actually much more detailed allowing for setting the specific orientation of the device.

Our changes

Titanium.UI.orientation is now deprecated and should no longer be used for setting orientation mode.  Instead, it is suggested to set the orientation mode or modes on the Titanium.UI.Window.orientationModes property since orientation in Titanium is linked to the window itself.

The following lists the orientation behavior that can be expected when setting various modes on Titanium.UI.Window.orientationModes:

  1. Any portrait mode AND any landscape mode:  this combination will set the screen orientation to be driven by the sensor and default OS behavior.
     

     
  2. Both portrait modes:  on API level 9 (2.3.0) and above, this will set the screen orientation to be “sensor portrait” which allows the OS to shift the orientation to either of the portrait orientation modes based on what the sensor reports.  If the device is older than API level 9 then this will lock the orientation to what the device considers portrait.
     

     
  3. Both landscape modes:  same as #2, just for landscape.
     

     
  4. Portrait mode:  locks orientation to portrait
     

     
  5. Landscape mode: locks orientation to landscape
     

     
  6. None:  if you set the Titanium.UI.Window.orientationModes array to be empty, then this defaults back to full sensor mode (same as #1)
     

     

Additional Resources

Kitchen Sink examples:
https://github.com/appcelerator/titanium_mobile/blob/master/demos/KitchenSink/Resources/examples/orientation.js

Titanium Mobile 1.7.2 is Here

Thursday, July 21st, 2011

Titanium Mobile 1.7.2 brings support for deploying Titanium applications to Android 3.X (Honeycomb) devices along with bug fixes for both Android and iOS.

Please review the Release Notes for full details on Titanium Mobile 1.7.2.

Upgrade notices will appear when you log into Titanium Studio.

Win $25k in Box.net’s Developer Challenge!

Tuesday, July 19th, 2011

Our friends at Box.net have kicked off their first developer challenge, and they’re inviting Titanium developers to enter their apps and get a chance to win great prizes:

All entrants who register for the contest will receive $75 in free InMobi ad spend.

1ST PLACE
$25,000 Cash, $5,000 InMobi Ad Network Spend, and a Pitch Meeting with VC firm Draper Fisher Jurvetson

2ND PLACE
$10,000 Cash, $5,000 InMobi Ad Network Spend, and a Pitch Meeting with Draper Fisher Jurvetson

TOP TEN BEST APPS
Each of the top ten apps will receive a brand new HP TouchPad.

They’re looking for powerful enterprise apps for Android and iOS and are offering cash prizes as well as the chance to pitch your company to leading VC firm Draper Fisher Jurvetson. The top ten most innovative and useful apps will be eligible for prizes and the final winners will be invited on stage at our upcoming BoxWorks customer conference in September.

Don’t forget to let your friends know so they have a chance to win $25,000 (or get them on your team to help you win) – share the Box Mobile Dev Challenge on Facebook, Twitter, and LinkedIn with the hashtag #boxdev.