Limiting orientation modes for Appcelerator app

You have a few options for handling device orientation:

• Lock orientation for the whole app
• Lock the orientation for a given window
• React to orientation changes.

Before we begin, it’s important to cover some caveats and subtleties on Android. With that platform, it’s important that you keep in mind that the orientation values you set don’t match those you get. With Android, you can set the UI orientation to any of four possibilities: portrait upright, landscape right, portrait upside-down, and landscape left. But, when you request the current orientation, you’ll get one of two values: portrait or landscape. This is a platform feature, not a Titanium implementation issue.

A further consideration is that portrait and landscape vary between phones and tablets. A phone is in portrait mode when its “top” is at 0 degrees (hardware buttons at the bottom) and landscape when the “top” is at 270 degrees. A tablet is in landscape mode when its top is at 0 and portrait when its top is at 90 degrees. (Based on sensor degrees.) These portrait/landscape values are what you receive when you get the devices current orientation.

ORIENTATION DESIGN PRINCIPLES:

Apple’s Developer documentation says: “People expect to use your app in different orientations, and it’s best when you can fulfill that expectation.” In other words, don’t look at handling orientation as a bother but an opportunity.

Apple further recommends that when choosing to lock or support orientation, you should consider following these principles:

On iPhone/iPod Touch – don’t mix orientation of windows within a single app; so, either lock orientation for the whole app, or react to orientation changes.

On iPhone – don’t support the portrait-upside-down orientation, because that could leave the user with their phone upside-down when receiving a phone call.

On iPad – you should support all orientations because that matches how people use those devices.

These same principles apply to an Android app as well.

ORIENTATION IS AN OPPORTUNITY:

Rather than considering orientation a “necessary evil” to handle, think of it as an opportunity. When a user rotates their device, you could display different content. Consider a recipe app that shows a list of ingredients when in portrait mode but shows cooking directions when the device is in landscape mode. Some handsets mute the speaker when the device is face down. You can probably think of other interesting ways your app could react to an orientation change.

LIMITING ORIENTATION MODES SUPPORTED BY YOUR APP:

You specify the orientations your app can support by modifying the tiapp.xml file. This type of configuration controls the splash screen orientation possibilities. And it constrains which orientations the windows of your apps could possible show in, but not necessarily the orientation of a specific window.

The techniques for iOS and Android vary, so we’ll look at them separately.

LIMITING ORIENTATION MODES ON IOS:

On iOS, you specify the orientations your app supports with values in the tiapp.xml file. By removing an orientation from the list, you prevent the app from displaying in that way. For example, to support only portrait on the iPhone, but support all rotations on the iPad, you’d use this XML in your project’s tiapp.xml file:

CODE:

<iphone>
<orientations device="iphone">
<orientation>Ti.UI.PORTRAIT</orientation>
</orientations>
<orientations device="ipad">
<orientation>Ti.UI.PORTRAIT</orientation>
<orientation>Ti.UI.UPSIDE_PORTRAIT</orientation>
<orientation>Ti.UI.LANDSCAPE_LEFT</orientation>
<orientation>Ti.UI.LANDSCAPE_RIGHT</orientation>
</orientations>
</iphone>

LIMITING ORIENTATION MODES ON ANDROID:

CODE:

<android xmlns:android="http://schemas.android.com/apk/res/android">
<manifest>
<application>
<activity
android:name="org.appcelerator.titanium.TiActivity"
android:configChanges="keyboardHidden"
android:screenOrientation="portrait"
/>
<activity android:name="ti.modules.titanium.ui.TiTabActivity"
android:configChanges="keyboardHidden"
/>
</application>
</manifest>
</android>

“Try to be like the turtle – at ease in your own shell.”

Appcelerator Cloud Services Impact on Mobile Server-Side Development

The cloud is truly redefining the way we work and play. In it we store our music, our pictures and movies, and our enterprise data. From it we access all of that information from laptops, tablets, smart phones, cars and TVs anywhere anytime. Of course, the mobile revolution is also delivering its fair share of transformation

When we speak with enterprise customers all the time and what we commonly hear goes something like this:

“We have many mobile initiatives and expect to roll out [tens/hundreds/thousands] of apps across multiple platforms over the next few years”

“The apps need to be of high utility and value to our [employees/partners/prospects/customers] and they need to access data from many sources including social networks, public data sources, enterprise data systems like ERP, CRM, SFA, and our custom apps”

“Our competitors have already published something similar, so we need the apps out ASAP”

“But we don’t have the time/money/resources/skills to build all the permutations of mobile client apps as well as the server-side components to support them”

“How can we prioritize one over the other, when we need both. What should we do?”

To answer this question, let me take a slight detour. Remember the good old days of client/server? Life was relatively simple then. We created a database instance with a bunch of tables and fields, hooked it up to a thick client with GUI controls and widgets, and before you knew it, our app was out the door (or more appropriately, on the desk). Network connectivity was not really an issue with LANs and the apps gave us access to the data in an acceptable form factor, on a not-so-portable, big screen, with more than enough room for extras.

But today’s mobile apps are now a complex mash-up of data from many different sources.Today’s apps need to not only look delightful on a multitude of different and smaller-sized screens, but they also need to feel great. They have to support device specific gestures and menus. They have to be cool and engaging. They need to integrate into the user’s life, so they can’t even imagine what it was like before they downloaded it.

In order to do that, an app needs automatic push notifications to update us even when we’re not in the app. We need status updates and feeds from other users so we know what’s happening. We need to “Like” things and share comments so our friends and colleagues know what we’re up to. We want to upload photos so we can share the moments of our lives. Our employees need supply chain data from the SAP system, financial data from the Oracle system and employee data from the HR system, so in that moment of need, in front of a customer or prospect, they can deliver real-time information.

So essentially what we have now are two very different sets of competing requirements – client-side applications and server-side services – both with different success criteria, different development tools and different skill sets.

And therein lies the problem – other than the biggest mega-companies on the planet who don’t have the constraints of money, people, skills, etc, the rest of us are faced with what seems like an impossible predicament.

I would suggest that of the two, the no-brainer winner has to be the client-side app. I don’t think anyone even questions the value of the user experience any more. Look at Apple. They epitomize that maniacal focus in all their products. So too does Google and Amazon.

So that leaves us with the displaced backend server-side. In order to deliver many of the above-mentioned required capabilities, “do-it-yourself” server-side development is perceived as the only solution, where you develop custom software and architectures made up of web, app and database servers to deliver these services and then integrate them to the different client apps. Then you build or provision a new infrastructure to support it all. Then wash, rinse and repeat for every new app and every time one of those data sources changes.

Fortunately there is a way out, and mobile cloud-based services offer a welcome solution. Such backend services provide the core capabilities required, over the cloud, so you can continue to focus on the client-side experience while simply consuming the backend services as needed on the cloud.

At Appcelerator we have Appcelerator Cloud Services (ACS) which offers a fast, easy, and simple way of building next generation mobile apps. With a proven set of ready-to-consume APIs, you can build beautiful apps in a fraction of the time from any mobile toolkit (of course there are numerous benefits if you use Titanium Studio too). ACS is also extensible, so it can integrate with other public services and private corporate apps to shield you from that complexity on the client.