My recent Developer Deep Dive webinar “Visualizing Complex Enterprise Data in a Tablet World” is now available on the Adobe Enterprise Developers Portal. In this webinar, I walk through the fundamentals of a rich, enterprise-data driven mobile experience, powered by Flex, AIR, LCDS, & LCCS.
Take a look at this short clip to get a feel for what’s covered in this webinar…
Not only were Flash Player 11 & Air 3 announced yesterday, but also the arrival of Flex & Flash Buidler 4.6. Flex & Flash Buidler 4.6 bring forth a new benchmark in performance, as well as a new & enhanced set of tools for developing mobile, desktop, and web applications. Bonus!!! – Flash Builder 4.6 will be a FREE update to all Flash Builder 4.5 customers.
Adobe remains focused on performance and in Flex 4.6 we’ve made considerable improvements. Many key performance optimizations were introduced, giving mobile applications the native feel you expect. Simply repackaging, an existing Flex mobile application with Flex 4.6 can yield up to a 50% performance gain. Creating a new application in Flex 4.6 will deliver near-native performance with the superior customization you expect from Flex.
If that wasn’t reason enough alone, let’s talk about the framework:
SplitViewNavigator – A new top-level application component specifically designed for the tablet experience. With only a few lines of code, manage the layout of multiple views and have them adapt automatically based on device orientation.
CallOutButton – A versatile component that pops over existing content and can contain text, components or even entire views.
SpinnerList – This popular tablet component is an adaption of the existing List component. It not only has a new look, but also gives options like recirculating content and a position based selection model.
DateSpinner – A highly flexible component that is not only locale-aware, but provides multiple out-of-the-box configurations to fit most date/time entry needs.
Text Enhancements – Flex 4.6 solves the problem of cross-device text input. Flex exposes the native text-editing controls on EVERY platform—this enables the developer to customize the keyboard and the user to experience the native UI of common operations like selection, copy/paste and spelling checking.
This simple and much-requested control is now available in Flex 4.6.
Can you feel the excitement?!?!?! Adobe has just announced the availability of AIR 3 and Flash Player 11 for early October! This release will bring a wave of change to the Internet and development tooling as you know them. From console-quality hardware accelerated 3D, to AIR captive runtime, to native extensions… Adobe tools will enable the next wave of innovation in games, rich media, and multi-device applications. In this release there are a lot of new features to get excited about.
Flash Player 11 and AIR 3 will be publicly available in early October. Flash Builder and Flex will offer support for the new features in an upcoming release before the end of the year. We’ll have a lot of news and new content at MAX, and in the meantime, you can download the Flash Player and AIR betas on Labs, and start checking out some of the amazing content that’s already been built by developers!
Here’s a post that I originally wrote way back in 2006, when Flex 2 was all the rage. No, seriously, Flex 2 was awesome – it is the base of today’s Flex framework, helped to revolutionize applications on the web, and heralded the “RIA” frenzy. The best part is that this post is still very relevant with Flex, AIR & ActionScript for mobile/web/desktop, so I decided to resurrect it from the old blog archive. Enjoy…
I’ve been asked several times, why would you use get/set functions instead of public variables in your flex components and classes? Well, there are some great things you can do with getters and setters that you can’t do with public variables. On the other hand, there are cases where public variables may be an easy choice. When using these functions and/or public variables, the code for the caller will be the same:
[as3]mycomponent.myValue = 1;[/as3]
First, lets look at public variables…
public var myValue : Number[/as3]
Public variables are useful when there are no addional actions that need to take place when the value has been changed. If you change the value of “myValue”, the bindings will update and everything will be handled accordingly. The value will change, and anything bound to that value will change. In this case, there is no need to use getter/setter methods, keeping code simple and easy to implement.
Now, on to getters and setters…
public function set myValue (value:Number):void
_myValue = value;
dispatchEvent( new FlexEvent( "myValueUpdated" ) );
public function get myValue ():Number
return _myValue ;
private var _myValue : Number;[/as3]
First I’ll explain the [Bindable(event=”myValueUpdated”)] statement: This indicates that the data binding to the getter’s value should be updated when the event of type “myValueUpdated” is dispatched.
You’ll notice that when the value is set, this event is dispatched, which would notify and components that are bound to this value. Using a binding event isn’t required for all getters and setters, however this approach can allow you to invoke binding events on the “getter” even if you don’t access the “setter” method.
Now, the rest… The code that I showed above is consumed in exactly the same way as a public property, but requires more code. The benefits of getter and setter functions are that they enable sequential code execution when the value is changed, and also enable inheritance in getter/setter methods.
This means that you can create your components so that specific functions are executed any time that the value is accessed using get and/or set functions.
Here’s an example:
public function set myValue (value:Number):void
_myValue = value;
dispatchEvent( new FlexEvent( "myValueUpdated" ) );
public function get myValue ():Number
return _myValue ;
private var _myValue : Number;
private var numGets : Number = 0;
private var numSets : Number = 0;[/as3]
In this example, every time the value is set, the numSets Number is incremented, and the myFunction() function is executed. Likewise, every time the value is accessed using the “get” method, the numGets Number is incremented, and the myOtherFunction() function is executed. There is no limit to what kind of code you can execute here. You can have it dispatch custom events, change styles, create new components, etc… This turns out to be very handy when creating custom Flex components.
As I mentioned earlier, getter/setter accessors also enable inheritance on “properties” of an object. This means that you can change the behavior of a getter/setter in descendant classes, while usage remains the same. A great example of this are the “get data” and “set data” accessor methods used throughout the Flex framework (and part of the IDataRenderer interface). You can override “get data” or “set data” methods to modify behaviors and/or return values, without changing how those methods are used.
In this series, I’d like to highlight Adobe’s mobile offerings, and the variety of platforms that can be supported from a single codebase. I wrote a simple URL Monitoring utility application that will check the status of various HTTP endpoints using the AIR URLMonitor class. I now have that application running on 3 OS platforms, in 4 ecosystems (5th coming soon), supporting phone and tablet interfaces, and all with a single codebase
Here’s the official app description that I’ve been using:
URL Monitor is a simple diagnostic application that will allow you to quickly and easily monitor the status of various URL endpoints. Simply enter a URL into the text box and add it to the list. A polling HTTP request will be made every 10 seconds to determine the availability of a given endpoint. HTTP codes 200, 202, 204, 205 and 206 will be identified as a success with a green check. All other HTTP codes will indicate a problem as a red ‘X’. To remove a listing, simply perform a horizontal swipe on a given row to reveal a delete button. All monitoring is paused when the application is in the background.
This application is currently available in the following ecosystems:
Flex/AIR on Devices: From Flash Builder to BlackBerry App World (coming soon)
What’s really interesting about this is the activity that I have seen on each market. The application is free on each market, and became available over the last few weeks. I have done absolutely no promotion of it… This is the first announcement that I have made.
As of 9/15/2011, the application has been live in Apple’s store for 3 weeks, and has had 554 downloads; it has been live in the Google Android Market for 3 weeks, and has had 20 installes (only 11 active); it has been in the Amazon market for 2 weeks, with 0 installs (yes, that is a zero); and surprisingly, it has been on the Nook store since Sept 1, and has had 816 downloads! Now, that was unexpected.
Once you are a registered developer, you will have access to tools that enable you to put your apps onto a nook device. First, you must download and install the Nook SDK add-on to the Android SDK.
This will download and install the Nook SDK. Once installed, the installation process will need to restart ADB. Click “YES” and allow it to proceed through the restart process.
Once you are a registered developer, you will have tools accessible to enable “Developer Mode” on your device, which allows you to provision the device for development. Go to the “Developer Mode” section of the nook developer portal and enter the device names and serial numbers for your dev devices. From here you will be able to download a provisioning file.
The provisioning file will allow you to deploy applications directly to the nook via USB. Attach the Nook Color device to your computer via a USB connection. The Nook Color device will show up as a device in Finder. Copy the provision.cmd file that you downloaded from the “Developer Mode” provisioning portal directly into the root of the Nook Color device.
Next, eject/unmount the Nook Color device. Now, use the tools within the Android SDK to restart ADB (Android Debug Bridge):
Once ADB has restarted, use the “adb devices” command to list all connected Android devices (The Nook Color device must still be connect via USB, even though it has been unmounted).
You should see your device listed in the output:
Now that you are able to view your Nook Color device using ADB, Flash Builder will also be able to deploy to it. You will be able to Run/Debug directly from Flash Builder and launch applications on the Nook Color device. This follows the normal Flash Builder debug process.
However, there is one trick… you may notice that if you go to the “apps” menu on the Nook color, you won’t see any of your applications deployed via USB. Don’t fret… they actually are on your device. There is just a trick to view them. From the “apps” menu, click on the “archived” button. A popup will be displayed here. Now, press and hold the “volume up” button. When the speaker appears on the screen (continue holding the volume button), tap on the speaker. When you tap on the speaker, the “extras” screen is displayed. (You can release the volume button now.) The “extras” screen will list all of your manually installed applications, and you will be able to re-launch your installed apps.
From here, you can generate your release-build APK as you normally would from Flash Builder. Once you have your APK generated and tested, you’re ready to prepare it for the Nook Store. Sign into the Nook Developer Portal, and go to the “Applications” section. Click on the “Add New Application” button.
First, you will need to enter the primary metadata for the application (name, type, price, version, etc…).
Once you have completed the basic information, click on “Save and Continue”, and you will be redirected to the “Description & EULA” tab. Enter an application description and an optional license agreement (I left this blank b/c I do not have any special terms for my app).
When ready, click “Save and Continue” to enter the “Keywords and Category” tab. On this screen, enter descriptive keywords and categories to help categorize your application within the Nook store.
When you have your categorical information all set, click “Save and Continue” to proceed to the “Icons & Screenshots” screen. Here you will need to set the application icon and add application screenshots.
Now this is where the application approval process is a little different from other app stores. You need to click “Send for Application Approval”, and the application metadata must be approved before you can upload a binary APK file.
Once the application metadata is approved (this took about a week for my app), you will be able to upload the APK binary.
After you have uploaded and submitted the binary APK file, the binary file will need to be approved before it is actually available within the Nook store. The binary approval took another week+, so the overall approval process took over 2 weeks. Once approved, your application will appear in the nook store, and will be ready for public consumption!
First, navigate to https://developer.amazon.com/ and click on the “Amazon Appstore for Android” link. Once there, you will need to walk through the full registration process to create your account.
Once you click on the “Get Started” button, you will be guided through the Appstore registration process. Once that is complete, you will be directed to the Appstore developer portal home page. From here, just click on “Add a New App”.
Next, you will being the App upload wizard. First, you will need to enter primary metadata for the application, including a title, form factor, supported languages, and contact information. Once you have entered this information, click on the “Save” button.
Next, you need to enter merchandising information. This includes the app category, keywords, a description, price, and release/availability dates. Once you have completed all of your merchandising information, click on the “Save” button to proceed.
Next, you will have to specify content rating information. Just fill out the information about your content, and click on the “Save” button to proceed. I didn’t run into any content rating issues in the Amazon Appstore, like I did with the iOS App Store.
Next, upload multimedia that will be associated with the application. This includes application icons (note: they must match, event though this screenshot doesn’t show it – I was rejected b/c of this), and actual screenshots of the application.
Scroll down to see more of the “Multimedia Content” form. You will also be able to enter promotional images and promotional video assets for your application. Once you have uploaded all necessary multimedia, click the “Done” button.
Now you are ready to upload your APK Binary. Follow the instructions for uploading an APK file. Once it is uploaded you will see information about the file that was uploaded.
Finally, click on the “Submit App” button to submit your application for approval. There is an approval process for the Amazon Appstore similar to Apple’s, and my application was live in less than a week from submission.
Once you have successfully uploaded the application APK, you will be prompted with the details about your application. Click “Save” to being entering application metadata information.
You will need to upload at least 2 screenshots of your application, as well as an application icon for use within the Android Market.
Next, scroll down to the “Listing Details” area and begin entering metadata for your application. This includes an application title and description, as well as release notes, classifications, and promotional text.
Next, scroll down to the “Publishing Options” screen, where you can configure copy protection settings, content ratings, pricing, and available markets.
Finally, enter your support/contact information and check the consent checkboxes.
Once you have completed the form in its entirety, scroll back up to the top of the page and click on the “Save” button to save content, or “Publish” to save and publish the application to the Android Market. Once you have successfully published it, your application will show up in your home dashboard, as shown below.
Thats it! The Android Market makes it extremely easy to publish your application. My application started showing up in the market after about 30 minutes from pressing the “Submit” button.
You can check it out live in the Google Android Market at:
In this post, we will cover the workflow for delivering a solution from development in Flash Builder through packaging for various Android ecosystems. In subsequent posts, this will be followed up with detail for delivering to each individual ecosystem.
You can start developing apps for Android using the debugging simulator built into Flash Builder. However, a critical step in your development process is that you must test and evaluate your applications on a physical device (preferably before you try to ship it). Luckily for all of us, that is really easy with Flash Builder.
First, develop your mobile application. When you are ready to test it on a device, simply go to the “Debug” menu and select “Debug Configurations”.
Next, create a new debug profile, select the platform “Google Android”, and select the “on device” debugging option with “debug via USB” selected.
Make sure that your test device(s) are plugged in via USB, and then hit the “Debug” button. Using this approach, you can deploy to any Android device that has USB Debugging enabled. This applies to phones and tablets… to enable USB debugging, you just need to go to Settings -> Applications -> Development, and then select the checkbox to enable USB debugging. You can also use this method to debug on a Nook Color device, however you must have it unlocked already via your Nook developer account.
Once you have developed and debugged your application, you are ready to export it for real world consumption. The first thing you need to do is specify you applicaiton name, version and id in your app.xml file. Be sure that these are the final values, as the application id will be the unique identifier for your application in all marketplaces and if you distribute the APK manually.
Once your application configuration is finalized, you will be ready to actually export the project. Right-click on your project in the package explorer and go to the “Export…” option. You can also perform the same action by going to the File -> Export menu.
Next, select the “Release Build” export option, and click “Next”.
Set your export folder, and a base filename for the output file(s), be sure to select the target platform “Google Android”, and export as “Signed packages for each target platform”. Click “Next” to setup your platform signing options.
For Android, you can use a purchased signing certificate, or use a self-signed certificate. Just use the browser button to locate your signing certificate, or click “Create” to crate a certificate.
If you create your own certificate, the following window will be displayed. Just enter a publisher name (your name), a password, and a file location. Next click “OK” and the certificate will be created and you will return to the Platform Signing Options screen.
Next, click “Finish” and your APK file will be generated.
Now that you’ve generated your APK binary file, you are ready to push to the various app stores… Let’s take a look at this process for each ecosystem:
In this post, we will cover the workflow for delivering a solution from development in Flash Builder through publishing in Apple’s App Store.
You can start developing apps for iOS without an Apple developer account by using the debugging simulator built into Flash Builder. However, a critical step in your development process is that you must test and evaluate your applications on a physical device (preferably before you try to ship it). 🙂
To get from Flash Builder onto an iOS device, the first thing that you will need to do is create a developer account with Apple and setup your signing certificates and mobile provisioning profiles. To register for a developer account, visit developer.apple.com and walk through the registration process. Note: You can register for free, but you can’t access any of the iOS deployment tools without the paid enrollment into the iOS developer program.
After you have an active iOS developer account, you will need to create a signing certificate and distribution profiles. From the iOS developer center’s home page, click on the “iOS Provisioning Portal” link as shown below.
Next, click on the “Certificates” link on the left side of the screen, as shown in the next screen capture. This will direct you to the certificate management area.
If you are only concerned about developing and not about distribution (or if you are not the iOS account team agent and can’t access distribution profiles), then you simply follow the steps for creating a development certificate.
If you will be distributing your application in the app store, via the enterprise distribution model (if you qualify for the enterprise program), or if you will be using ad-hoc distribution, then you will have a “Distribution” tab, as shown in the screen below. Distribution certificates are required for distribution profiles. Go ahead and click on the “Distribution” tab and follow the instructions for setting up a certificate. You will need to create a certificate signing request through Keychain Access, and then you will need to submit it through the Apple developer portal.
Once you have successfully created a certificate, it will display under your “Current Distribution Certificate” heading within the “Distribution Certificates” tab, as shown below.
Download the certificate and either drag or import the “distribution_identity.cer” file into the Keychain Access application. Once you have imported it, you should see the profile listed. In the next screenshot, you can see that I have selected my “iPhone Distribution” certificate. You will need to export the certificate to a .p12 file so that it can be used by Flash Builder. Just select the certificate at the root level (be sure to not just select the key). Next, go to the file menu and click “Export Items” and save the certificate to a file.
Once you have created your signing certificate, you’ll next need to obtain your provisioning profile from Apple, in order to be able to actually deploy on any iOS devices. If you are only using your registered iOS devices for local development and do not plan to distribute your application yet, then you can go to the Provisioning section of the iOS developer portal and download the development “Team Provisioning Profile”. Click on the download link and save you .mobileprovision file locally, and then proceed on to setting up your debugging environment.
If you will be distributing your application, then you will need to first create an application ID. All distribution provisioning requires an application ID. Within the iOS Provisioning Portal, click on the “App IDs” navigation on the left sidebar, and then click on the “New App ID” button on the right side of the screen.
From here, you need to create the actually application ID. You need to enter a description (what you commonly refer to the app as), and enter a bundle identifier. For the description on my application, I entered “URL Monitor” for my description , and the bundle identifier is “com.tricedesigns.URLMonitor”. The bundle identifier is the unique reference to your application.
Once you’ve create an App ID, next you will need to create a distribution provisioning profile. Click on the “Provisioning” navigation item on the left sidebar, and then click on the “Distribution” tab across the top. To create a new distribution profile, click on the “New Profile” button on the right side of the screen.
Next, select your distribution type. For most of us, this will only contain “App Store” and “Ad Hoc”. For developers who have access to the enterprise developer program, there will be a third “Enterprise” option. Note: “Ad Hoc” distribution means that you can only distribute to a limited number of devices; all of which need to be registered within your developer account. Give your distribution profile a name (I called mine “URL Monitor App Store”), and select the application ID that you just created. Once you click submit, the distribution profile will be created.
Once created, download and save the .mobileprovision file for future use.
First things first, let’s cover debugging. I mean, c’mon… you can’t distribute an app if you haven’t debugged it first… right? To debug, go the the debug menu and select the “Debug Configurations…” option to create a new device configuration.
Select the target platform “Apple iOS”, and then select the “on device” launch method.
From that same screen, cick on the “Configure packaging settings” link to show iOS signing options. In the screen shown below, select the .p12 certificate file that you created earlier, and select the debug .mobileprovision provisioning file that you also just downloaded.
Click “Apply” to save these settings, then click “OK” to close this dialog. You will be returned to the “Debug Configurations” dialog, and you can now click “Debug” to actually debug your application on your iOS device. Flash Builder will not automatically deploy to your device. It will create an IPA file, which you will need to drag into iTunes, and then synch your device to deploy it. However, you can still actively debug your application over the local network, directly within Flash Builder.
First things first, setup your application’s metadata within your app.xml file. In particular, you will need to specify an application name, version number, and ID. The ID MUST match the bundle identifier that you specified when creating the App ID through the iOS Provisioning Portal, and the version number must be a valid number.
Next, right click on your project and select the “Export” menu option, as shown below:
Select the “Release Build” option, and continue the wizard steps:
Next, you will need to specify the export location (“export to folder”) and enter a filename. Also, be sure to have the “Signed packages for each target platform” option selected.
Next, you will need to configure your distribution options. Specify your certificate (.p12) file location, your provisioning file (.mobileprovision) location, and select the correct package type. If you use an App Store or Enterprise provisioning profile, select the “Final release package for Apple App Store” option. If you use an Ad-Hoc provisioning profile, select the “Ad hoc package for limited distribution” option. Keep in mind that you must provision specific devices in the Apple App Store before creating the build. Next, click “Finish”, and out will come an IPA file ready for distribution. Note: If you are using a developer certificate, you will not be able to distribute an IPa file.
If you are using Ad Hoc distribution, you can now simply send the IPA file to your users, and they will be able to deploy the application to any provisioned devices. If you are using the enterprise provisioning option, you can just send the IPA without worrying about specific device IDs. However, keep in mind that you can only distribute those files according to Apple’s rules surrounding the Enterprise deployment model.
If you’ve be “chomping at the bit” to upload your application to Apple’s app store, then this next section is for you. First things first, you must go to iTunes Connect to setup your application with the App Store. Simply navigate to itunesconnect.apple.com and l0g in using the same credentials that you used for the iOS Portal. iTunes connect allows you to manage and monitor your applications, including sales trends, #downloads, etc…
To get started,click on the “Manage Your Applications” link shown in the screenshot below:
You will be brought to the “manage” screen; from which you can edit metadata for all of your applications. To create a new application, click on the blue “Add New App” button in the top left corner.
iTunes connect will now walk you through a series of questions that will provide appropriate metadata for your application. First, select your language, and enter your company name. If you are submitting as an individual (not a company), just put your name.
Next, you need to create the primary metadata about you application: The application name, the sku number (stock keeping unit), and select the bundle identifier. Make sure you select the bundle ID that matches your App Store provisioning profile. DOUBLE-CHECK THIS SCREEN TO MAKE SURE IT IS CORRECT! Once submitted, the bundle ID information cannot be changed. When you’re absoultely sure it is correct, click on “Continue” to proceed.
Next, enter the availability date and pricing for your application. Keep in mind that the availability date only applies after the application has been approved by Apple. If you back-date this, it will not speed up your time into the app store. When ready, click “Continue” to proceed.
Now, enter the primary metadata that describes your application. This includes the version number (try to keep this in synch with your app.xml in your Flex project for organization purposes – although not required to match), description, primary and secondary categories, keywords, contact information, and review notes (for the team at Apple that will review your application).
Next, rate the content within your application. Apple will verify your app against these ratings, and if they do not match, your app will not make it into the app store. Mine was actually rejected for this… No, I do not have crude content in this case. For example, if you provide unrestricted access to the internet, such as allowing a user to type in any URL, and you show that content via a stageWebView, then you are rated 17+. No “ifs”, “ands”, or “buts”. My only options were to remove the unrestricted access (remove stageWebView), or to have the app rated 17+. I chose 17+. Don’t be confused by this though; If you use StageWebView, that doesn’t mean your app will always be rejected – this is only b/c I had unrestricted access to the StageWebView control. In my app, you can enter any URL, and click on the “view” button to view the content of that URL.
Next, upload your application images. The large icon is 512×512, and the phone screenshots should match actual device resolutions. Note: Your main “large icon” must match the one embedded in your application – I also got rejected b/c it didn’t match initially, as shown in the screenshot below.
Image requirements from Apple:
iPhone and iPod touch Screenshots must be .jpeg, .jpg, .tif, .tiff, or .png file that is 960×640, 960×600, 640×960, 640×920, 480×320, 480×300, 320×480 or 320×460 pixels, at least 72 DPI, and in the RGB color space.
Hit “Continue” to save all of your changes, and now you are ready to start uploading your application binary. Click on one of the “Ready To Upload Binary” buttons on either the top of bottom of the screen to move the process along…
Once you click on the “Ready to Upload” button, you will walk through several questions around export compliance and encryption. Answer these questions, then hit “Save” to proceed.
Once you have completed all of the questions, your application will now be ready to upload. After this point, we will be leaving iTunes Connect, and jumping to the OSX desktop to actually upload the application.
Now, we are ready to upload the application. In OSX, launch the “Application Uploader” program, which is a part of the XCode developer tools. When the application loads, you will need to sign in using your iOS developer credentials.
Upon login, the Application Loader tool will allow you to chose which application you want to upload a new build for. Choose the desired application, and then click on the “Next” button.
The Application Loader tool will display metadata about the application that you have selected, and you will need to choose an IPA file from your local filesystem for distribution. Be sure to select your release-compiled, App Store provisioned IPA, or else the upload process will fail.
Once you’ve selected the IPA file, click “Send” to being the upload process.
After the upload process is complete, there will be a verification step, and then you will receive a message “Uploaded package to iTunes Store”.
Click “Next”, and you will be presented with a “Thank You” message, and the upload process is done.
Now, comes the Apple approval process. Generally, this takes about a week for new applications, and only a few days for application updates. However, there are not guaranteed timelines. Once the application is approved, it can be ready for immediate consumption within Apple’s App Store.
You can check it out live in Apple’s App store at: