[AIR, 번역] AIR 개발자가 흔히하는 실수 10가지

원문 : http://www.adobe.com/devnet/air/articles/10_common_mistakes_air.html?devcon=f3

10 common mistakes when building AIR applications

David Tucker

DavidTucker.net

• Send feedback
• Get an e-mail update of new articles

Created:

18 August 2008

User Level:

All

Products:

Adobe AIR

AdobeAIR has grown immensely popular over the past months. With itspopularity, many new applications have been released. During thisperiod, the following 10 issues have been the mistakes I have seen mostoften among developers. Hopefully, this list can help you avoid thesame mistakes when building your next AIR application.

1. Making an application platform specific

ManyAIR developers have a primary platform that they use as theirdevelopment environment. In some cases, developers have not spent agreat deal of time on other platforms, and they may not know how userson those platforms interact with desktop applications. Developersworking on Windows, for example, need to have a good understanding ofthe user experience in respect to the Dock and the Application menu onthe Mac platform, and Mac developers need to understand the userexperience with the task bar and application window menus on Windows.Failure to understand these concepts can lead to applications that feelawkward and unnatural to the end user.

Consider thisexample: A Mac developer might place a Preferences menu item in theapplication menu for his AIR application. However, for the Windowsversion of the AIR application, he fails to add this menu item to eachwindow menu. If the application were only tested and developed on a Macthis error might not get caught.

Some developers don't haveaccess to other systems, but virtualization helps to eliminate some ofthese issues by providing the developer access to multiple operatingsystems on a single computer. One of the most useful tools in creatingeffective native applications is to have a regular user of anotherplatform evaluate your application for both functionality andusability. By taking this extra step, you can catch mostplatform-specific issues in your AIR application.

2. Not including update capability in an application

Oneof the most important changes in the transition from the web to thedesktop is the way that updates are handled. No longer does the user"come to you" to get your application, but rather you send theapplication to the user. Depending on how you configure yourapplication, users might not ever have to return to your site to getthe latest and most secure version of your application.

Previously,it took a little bit of work to develop an effective update mechanismfor your AIR applications. However, Adobe has done most of the work foryou with the Adobe AIR Update Framework.Adobe even gives you the option of using two different flavors of thisframework: one includes a default user interface, and the other handlesthe logic and allows you to create a custom user interface that fitswith your application.

Anytime you send a version of an AIRapplication to someone outside of your core development team, you oughtto have some update mechanism in place (see Figure 1).

Figure 1. Adobe AIR Update Framework

3. Changing the application ID after an app has been released

TheAIR runtime uses two factors to determine the signature of anapplication: the application ID and the publisher ID. These valuesbecome very important when you distribute your application. If youchange one of these pieces of information, an end user might be unableto update her version with the newer version. This could result in theuser installing two different versions of your application, which, inturn, could result in the update version being unable to access anyapplication-specific data from the first installation. In eithersituation, the end user might get frustrated enough to not use yourapplication again.

To avoid this situation, you need tosettle on a few things when you create your application. First, youneed to set an application ID in the application descriptor file. Thisapplication ID is invisible to the user and will not change. It does,however, need to be consistent. Second, you should always use the samesigning certificate when creating your application. The AIR packageruses the signing certificate to determine the publisher ID. If you doneed to use a new signing certificate, the AIR developer tools providea means to do so. For more information, refer to the article "Signingan AIR file to change the application certificate" in the AIRdocumentation for Ajax, Flash, and Flex developers.

4. Not planning for offline support

Oneof the advantages of Adobe AIR is the online/offline capability forapplications. Many applications might not need or use thisfunctionality. In most cases, this will not cause any problems, unlessgoing offline breaks the application.

Every AIRapplication that interacts with an online service needs to be testedwhile the development environment is offline. This way you candetermine where you need to place warnings or disable user interfaceelements so that the end user understands what functionality is notavailable while the application is in an offline mode.

Ifyou want to expand your application to include specific offlinefunctionality, AIR has APIs to work with the local file system, theSQLite embedded database, and even a secure data store. By utilizingthese APIs you can create applications that can easily storeinformation on the user's computer to create a seamless offlineexperience. For an enterprise solution, the newest version of LiveCycle Data Servicesprovides online/offline synchronization of data for AIR inside of Flexbased AIR applications. For more information, see Christophe Coenraets'blog post: Offline Synchronization using AIR and LiveCycle Data Services.

5. Not thinking in AIR

TheAIR APIs are powerful and provide a great deal of functionality todevelopers. However, I have often found that there are pieces of theAPI that some developers are not familiar with. For example, I havenoticed developers trying to encrypt data in a text file instead ofusing the EncryptedLocalStore functionality, or storing delimited datain a text file when using the embedded SQLite database would providebetter functionality.

This oversight can be extremelycommon in web applications that are ported to Adobe AIR. One of thegreat things about AIR is that many of these applications can be portedwith little or no changes to the code. However, in some cases theapplication could benefit greatly from using some of the AIR APIs toadd functionality that enhances the user's experience.

To get a better grip on the APIs provided in AIR, you can review the AIR documentation and sample applications.

6. Using custom chrome to create confusing interfaces

Customchrome puts a lot of power in the hands of developers and designers. Byusing it, you are altering the way a user interacts with anapplication. If this custom chrome has a consistent feel with thestandard operating system chrome, users will be able to interact withit seamlessly. However, if users cannot easily maximize, minimize, orclose an application window, the chances of them using your applicationon a regular basis are very slim.

Having a single lookacross all platforms certainly has its benefits. Using the standardchrome will cause the application to appear different on each platform.Custom chrome gives a single branded experience across all platforms,and if it can be accomplished without confusing the user, it is apowerful tool. Some applications, such as the EBay DesktopAIRapplication, give the user the option of the standard or customwindowchrome. As long as you approach custom chrome with caution andkeep theuser's experience in the forefront as you develop yourapplication,custom chrome will be an asset. For more information,refer to EthanEisman's article Adobe AIR and the experience brand, Lee Brimelow's Creating custom-chrome AIR applications in Flash CS3, as well as the AIR Quick Starts for Flex, Flash, and Ajax.

7. Not using the seamless install badge

Developerssometimes assume that everyone's system is configured in a similar wayto their own. This can be dangerous when distributing packaged AIRapplications to your end users. First, you cannot guarantee that usershave the Adobe AIR runtime installed on their computers. Second, youcannot assume that the server delivering the file will know how toproperly handle packaged AIR files.

Luckily, these issuescan both be handled by properly configuring and using the seamlessinstall badges for Adobe AIR. This allows users who have Adobe FlashPlayer installed to download your application as well as the AIRruntime (if needed). It will then install the necessary elements. Thistakes the guesswork out of AIR application distribution. There arecurrently two versions of the badge that can be used: the originaldesign (see Figure 2) and a new version designed by Grant Skinner (seeFigure 3) that is on Adobe Labs.

Figure 2. Original install badge design

Figure 3. Updated install badge design

For more information, refer to my article, Deploying AIR applications seamlessly with badge install and to Additional Seamless Install Badge with new look and feel on Adobe Labs.

8. Not encrypting sensitive data

ManyAIR applications interact with other services on the Internet. In manyof these cases, the user inputs sensitive information such as ausername and password to access these services. This is just oneinstance where secure data is stored by an AIR application. Anytime youstore sensitive information for an AIR application, it needs to beencrypted.

Many developers have confused the security ofdifferent storage options within AIR. Some developers have mistakenlyassumed that information with the local database is secure, but thatinformation can be accessed by any application that can read a SQLitedatabase. Essentially, the only truly secure way to store informationwith the AIR API is to use the EncryptedLocalStore class. This usesplatform-specific encryption to store information, and it can(optionally) also be configured to be accessed by a single AIRapplication only. Some developers have created custom ways to encryptinformation in local files, but in almost all cases theEncryptedLocalStore class is your best option. For more information,see Kevin Hoyt's article Using the encrypted local store feature.

9. Not preserving native interaction

Someactions span almost all applications on a specific operating system.For example, Windows users can be sure that in almost every applicationobjects can be copied by using the Ctrl+C keyboard shortcut. Inaddition, Mac users expect the same behavior with the Command+Cshortcut. These are the type of actions that need to be preserved sothat the user can have a familiar experience when interacting with yourapplication. If you changed the Copy keyboard shortcut to a differentkey combination, it would only cause confusion and decrease usability.

For example, if you are dealing with SWF content, the normal keyboard shortcuts for copy, cut, and paste are enabled in TextInput, but they are not enabled in TextArea(the default shortcuts work for all types of text inputs in an HTML AIRapplication). In this case, you would need to be sure that thisfunctionality was preserved for the user by manually adding them.

Whendealing with keyboard shortcuts, review other applications to ensurethat if you are performing a standard action, you use the commonkeyboard shortcut for that specific platform. In addition, if certainitems appear in application or window menus (such as Cut, Copy, andPaste) be sure that those items are present and indicate the relevantkeyboard shortcut.

10. Assuming performance doesn't matter outside of the browser

Developingapplications for the desktop can be a liberating experience. Bybreaking out of the browser, you are freed from many constraints.However, the temptation is to not worry about issues such as memory andprocessor utilization. These issues become compounded when you utilizeresource-intensive functionality within AIR, such as custom chrome andwindow transparency. Just as with a web application, every AIRapplication should be tested and profiled for system resourceutilization. If you are creating an AIR application in Flex Builder,you can use the Profiler to view your application's resourceutilization over time.

Remember that your AIR applicationhas the ability to slow down the entire desktop experience for the enduser. Your AIR application needs to use only the amount of resourcesthat make sense. If your application performs complex tasks, a highutilization of system resources might make sense. However, if yourapplication performs a relatively simple task, the end user will not besatisfied with a high usage of system resources. For more information,refer to Using the Profiler in LiveDocs.

(부드러운 번역을 위해 다소 의역이 포함되어 있습니다.)

AIR가 점점 인기가 많아지고 있습니다. 인기와 더불어 많은 어플리케이션들이 올라오고 있기도 합니다. 이번 기회에 제가봤던개발자들이 가장 많이 빼먹는 부분들 10가지를 골라보았습니다. 이글을 읽는 개발자분들에게 도움이 되었으면 합니다.

1. 하나의 OS에서만 개발한다.

많은 AIR 개발자는 주로 개발하는 플랫폼을 누구나 가지고 있습니다. 예를 들면 개발하면서 다른 플랫폼에서는 별로 시간을보내지않고 다른 플랫폼의 유저들이 데스크탑 어플리케이션을 어떻게 주로 다루는지 잘 모릅니다. Windows에서 개발하는 개발자는Mac에서의 Application 메뉴나 Dock에 대해서 알아야 합니다. 또 Mac에서 개발하는 개발자는 윈도우의태스크바나기본 윈도우 메뉴에 대해서 알아야합니다. (야꼬왈 : 아무래도 지르기로 했던 맥을 질러야되나 봅니다 -_ㅜ)그렇지않으면유저에게 어색하고 불편한 어플리케이션일 수 밖에 없습니다.

가정을 해봅시다. 맥에서 주로 개발하는 개발자가 Preferences menu 를 AIR 어플리케이션에 넣었다고 했을때 이어플리케이션을 Windows에서 설치하면 이 메뉴는 쓸모가 없어집니다. 맥에서만 개발하고 테스트했기 때문에 이런 현상이나타나는것이죠. (야꼬왈 : 저도 몰랐습니다 -_- 깊히 반성중...)

어떤 개발자는 다른 OS를 만져보지도 못했습니다. 하지만 사실 한 컴퓨터에서 Multi-OS를 설치하는것만으로 이런 문제들은해결될 수 있습니다. 어플리케이션의 기능성과 사용성을 고려한다면 다른 OS의 일반 유저에게 테스트를 부탁하는것만으로도 매우효과적입니다. 이렇게 함으로써 당신은 보다 완성도 있는 어플리케이션은 만들 수 있을것입니다.

2. Update 기능을 넣지 않는다.

웹에서 데스크탑으로 옮겨오면서 가장 큰 변화중의 하나는 바로 업데이트를 할 수 있다는 것입니다. 유저가 당신의어플리케이션을구하러 오지 않아도 된다는 이야기입니다. 그저 유저에게 어플리케이션을 보내주기만 하면 되는 것이죠. 어플리케이션을업데이트 할수 있게 해놓으면 유저는 최신버젼을 받으러 굳이 사이트까지 오지 않아도 되는 것입니다.

하지만 그 전에, 효과적인 업데이트 기능을 위해서는 약간의 개발작업이 필요합니다. 그러나 Adobe AIR Update Framework이라는 프레임웍을 사용하면 보다 쉽게 개발할 수 있습니다. 이 프레임웍은 두가지 방법으로 사용할 수 있습니다.AIR의default update interface를 사용할 수도 있고 어플리케이션의 특화된 custom updateinterface를 만들수도 있습니다.

업데이트를 하기 위해서는 아래와 같이 몇가지 업데이트 설명을 반드시 넣어주어야 합니다.


그림 1

3. 배포하고 난 후 Application ID 바꾸기.

AIR Application 은 두가지 요소를 가지고 하나의 Application 임을 구분합니다. 바로ApplicationID와 Publisher ID 입니다. 이 두가지는 어플리케이션을 배포할때 가장 중요한 정보입니다. 이중하나라도 다르다면Application은 다른 Application으로 인식하기 때문에 업데이트를 할 수 없습니다. 심지어 당신의어플리케이션을 두개로 설치할 수도 있습니다. 이렇게 되면 새 버젼을 설치하면서 최초 설치시에 저장했던 설정 정보들을 가져올수없는 현상도 발생할 수 있습니다. 그렇게 되면 사용자는 불만을 가지게 될것이고 다시는 당신의 어플리케이션을 사용하지 않겠죠.

이런 현상을 방지하기 위해서는 어플리케이션을 만들때 몇가지만 고려하면 됩니다. 첫번째로 applictiondescriptorfile (-app.xml) 파일에 application ID를 꼭 적어주십시오. 이 applicationID는 일관되도록정하는것이 좋습니다. (야꼬왈 : 야꼬가 만드는 어플들은kr.as3.applications.ApplicationName 으로정해놓습니다. :) ) 두번째는 publisher ID가저장되어 있는 항상 같은 signing certificate를 사용하십시오. 만약 새로운 signing certificate가필요하다면 개발자는 선택해서 사용할 수도 있습니다. 더 자세한정보는 F1에 나와있는 "Signing an AIR file tochange the applicationcertificate" 챕터를 참고하시기 바랍니다.

Flash
- http://help.adobe.com/en_US/AIR/1.1/devappsflash/WS13ACB483-1711-43c0-9049-0A7251630A7D.html
Flex
- http://help.adobe.com/en_US/AIR/1.1/devappsflex/WS13ACB483-1711-43c0-9049-0A7251630A7D.html
Ajax
- http://help.adobe.com/en_US/AIR/1.1/devappshtml/WS13ACB483-1711-43c0-9049-0A7251630A7D.html

4. 오프라인에 대한 대책이 없다.

Adobe AIR의 큰 장점중에 하나가 온/오프일때의 기능을 넣을 수 있다는 것입니다. 대부분의 어플리케이션은 이러한 기능이필요하지 않을 수도 있습니다. 오프라인일때 어플리케이션이 아예 작동되어선 안된다면 상관없기때문에 사실 대부분 이런부분이 문제가되지 않습니다.

온라인 서비스를 제공하는 어플리케이션은 오프라인 환경에서 꼭 테스트를 해봐야 합니다. 그래야만 유저가 "아 이 기능은 오프라인일때는 못 쓰는구나" 라고 이해할만한 경고문구나 디자인을 어디에 넣을지 결정할 수 있는 것입니다.

만약 오프라인일때도 작동하는 온라인 서비스를 만들고 싶을땐 SQLite나 EncryptedLocalStore같은localfile system을 이용할 수 있습니다. 이 기능을 잘 활용하면 유저에게 오프라인일때도 온라인같은 환경을 제공해 줄수있는것입니다. 엔터프라이즈 솔루션일 경우에는 LiveCycle Data Services(LCDS) 를 사용하면 온/오프라인 싱크기능을 Flex 기반의 AIR 어플리케이션에 구현할 수 있습니다 더 자세한것을 알고 싶으면 Christophe Coenraets의 블로그에 올려놓은 Offline Synchronization using AIR and LiveCycle Data Services 포스트에서 볼 수 있습니다.

5. AIR 같지 않은 어플리케이션.

AIR는 매우 훌륭한 기능들을 제공합니다. 하지만 필자는 AIR에 적응하지 못한 개발자들을 가끔 봅니다. 예를 들면 암호화된정보를 텍스트 파일에 저장한다던가 목록정보 같은것을 텍스트에 저장한다던가 하는 것들입니다. 이런것들은EncryptedLocalStore나 SQLite를 사용하면 훨씬 간단하고 강력하게 활용될 수 있는 부분입니다.

이런 점을 알지 못하면 그저 데스크탑에서만 돌아가는 Flash와 다를바가 없습니다. AIR의 장점이 코드를 바꾸지 않아도데스크탑 어플리케이션으로 변환할 수 있다는 것이지만 AIR API를 잘 활용하면 어플리케이션을 훨씬 훌륭하고 강력하게 바꿔줄수도있습니다. 이는 유저에게 훨씬 훌륭한 UX를 제공하는것이고 어플리케이션의 가치를 높여주는 것입니다.

AIR 가 제공하는 API에 대해서 자세히 알고 싶으시면 AIR documentation 과 예제들을 참고하세요.

6. Custom Chrome은 혼란스러울 수도 있다.

Custom Chrome은 개발자와 디자이너에게 매우 매력적인 기능입니다. CustomChrome으로 개발함으로써 유저와의 인터렉션이 변경될 수 있습니다. Custom Chrome이 OS와 비슷한 모습으로 제공된다면 불편함이없겠지만 유저가 최소화, 최대화 또는 닫기를 쉽게 찾지 못한다면 불편한 어플리케이션일 수 밖에 없습니다.

다른 OS들을 살펴보면 Standard Chrome이 OS마다 다르게 보인다는것을 알 수 있습니다. Custom Chrome은플랫폼에 상관없이 일관된 GUI를 제공할 수 있고 유저에게 혼란스럽지만 않다면 정말 매력적인 기능임에는 틀림없습니다. EbayDesktop 같은 어플리케이션을 보면 사용자에게 Custom Chrome을 사용할것인지 사용하지 않을 것인지 설정할 수 있도록옵션을 제공하고 있습니다. 어플리케이션을 개발하면서 유저의 입장에서 고려하고 잘 설계한다면 Custom Chrome은 정말훌륭한 기능이 될 것입니다. 더 자세한 정보는 Ethan Eisman의 포스트 Adobe AIR and the experience brand, Lee Brimlow의 Creating custom-chrome AIR applications in Flash CS3, 그리고 AIR Quick Start : Flash, Flex, Ajax를 참고하시기 바랍니다.

7. Install Badge를 사용하지 않는다.

개발자들은 가끔 모든 컴퓨터가 자신과 환경이 비슷할것이라고 가정할때가 있습니다. 이런 섣부른 예상은 AIR 어플리케이션을배포할때 매우 위험할 수 있습니다. 첫째로 모든 유저의 컴퓨터에 AIR Runtime이 설치되어 있다고 장담할 수 없죠. 둘째로AIR 파일을 다운받을때 어떤 프로그램으로 연결될지 장담할 수 없습니다. (야꼬왈 : 실제로 런타임이 설치되어 있지 않으면압축파일로 열리죠 -_ㅡ^)

하지만 다행스럽게도 이런 문제는 install badge를 이용해서 해결할 수 있습니다. Badge는 Flash Player만설치되어 있으면 AIR Runtime을 설치시켜줍니다.(필요하다면) 그러고나서 필요한 것을 설치를 자동으로 진행시켜 줍니다.배포가 훨씬 편해지겠죠. 현재 badge는 두가지 버젼이 있습니다. 초기 디자인(예제2)과 Grant Skinner(예제3)가디자인하고 Adobe Labs에서 받아볼 수 있는 새 버젼이 있습니다.

예제2 초기 디자인

예제3 새 버젼의 디자인

더 자세히 알고 싶으시면 Adobe Labs에 포스팅했던 Deploying AIR applications seamlessly with badge install과 Additional Seamless Install Badge with new look and feel을 참고해주시길 바랍니다.

8. 민감한 데이터를 암호화하지 않는다.

많은 어플리케이션은 웹서비스와 연동을 합니다. 그중 많은 서비스들에서 유저는 비밀번호 같은 민감한 정보를 입력해서 이용할 때가많습니다. 그저 하나의 예일뿐이지만 여러분은 민감한 정보를 저장할때는 암호화를 통해서 저장을 해야합니다.

많은 개발자들이 AIR 안의 저장기능에 대해서 헷갈려합니다. 어떤 개발자는 정보들을 로컬 데이타베이스에 저장해놓고 안전하다고생각합니다. 하지만 SQLite 데이터 베이스를 읽을 수 있는 어떤 프로그램이든 읽어들일 수 있습니다. 근본적으로 이런 정보를안전하게 저장할 수 있는 방법은 EncryptedLocalStore 클래스를 이용하는것 뿐입니다. 이 클래스는 플랫폼마다의암호화를 통해 저장할뿐 아니라 설정에 따라 하나의 어플리케이션만 읽을 수 있도록 할 수도 있습니다. 어떤 개발자는 다른 방법으로로컬파일에다가 암호화해서 저장하는 경우도 있습니다. 하지만 대부분의 경우에서 EncryptedLocalStore 기능은 최선의선택일수 있습니다. 더 자세히 알고 싶으시면 Kevin Hoyt's가 쓴 Using the encrypted local store feature를 참고하시기 바랍니다.

9. Native Interaction을 유지하지 못한다.

어떤 동작은 시스템에 따라 모든 어플리케이션이 똑같습니다.. 예를 들어 Windows 유저는 거의 대부분의 프로그램에서 복사하는동작은 Ctrl + C 단축키를 이용합니다. Mac유저도 마찬가지로 Command + C 단축키로 같은 동작을 할 수 있습니다.이런 유사한 동작들은 유저에게 비슷한 프로그램을 사용할때 비슷한 경험을 할 수 있도록 해줍니다.  만약 복사하는 동작의 단축키가어떤 프로그램에서만 다르다면 그 프로그램은 사용성이 떨어지고 혼란스러움을 유저는 느낄것입니다.

한가지 예를 들어보면 SWF 컨텐츠를 사용하면서 TextInput에서 copy, cut, paste은 일반적인 단축키로 할 수있는데 TextArea에서는 사용할 수 없다면(기본적으로는 동작합니다.) 유저에게 단축키를 추가할 수 있도록 기능을 제공해줘야합니다.

단축키 기능을 설정할때는 일반적으로 동작하는 다른 어플리케이션을 참고해서 각 플랫폼에 맞는 단축키를 사용해야 합니다. 이에 더불어 윈도우 메뉴나 아이콘등을 단축키와 연관있는 적당한 아이템들을 사용하시기 바랍니다.

10. 브라우저안이 아니기 때문에 퍼포먼스는 별 문제가 아니라고 생각한다.

데스크탑 어플리케이션을 개발하는것은 당연히 매우 자유롭습니다. 브라우저에서 벗어났기 때문에 많은 제한에서 자유롭게 되었기때문이죠. 그러나 이것이 메모리최적화나 CPU점유율에 대해서 걱정할 필요가 없다는 뜻은 절대 아닙니다. 만약 CustomChrome과 Window Transparency등의 리소스를 많이 사용하는 기능을 사용한다면 오히려 더 복잡해질 수 있습니다.웹 어플리케이션을 개발하는것 처럼 모든 AIR어플리케이션도 여러가지 리소스 툴을 이용해서 테스트되고 최적화 되어야 합니다. 혹시Flex Builder로 개발하고 있따면 Profiler를 통해서 항상 관리할 수 있습니다.

항상 여러분이 만든 AIR Application은 유저의 데스크탑 전체를 느려지게 만들수있다는것을 잊지 마십시요. 적당한리소스를 사용하도록 고려해야합니다. 만약 어플리케이션이 복잡한 작업을 한다면 리소스를 더욱 많이 쓰게 되겠죠. 그치만어플리케이션이 단순한 기능인데도 시스템이 버벅인다면 유저는 당연히 싫어하겠죠. 더 자세하게 알고 싶으면 LiveDocs의 Using the Profiler를 참고하시기 바랍니다.