[UPDATE: InvokeEventReason.NOTIFICATION added for accessing the notification payload when application was not running in the background. Latest AIR build containing these changes available here]
Push/Remote Notifications support for iOS platform has been made available in latest release of AIR 3.4. This blogpost will cover everything you need to do to get remote/push notifications working in your AIR application: subscribing for remote notifications, configuring your application in the iOS Provisioning Portal, sending notifications to Apple’s Push Notification Service (APNS), and handling them in your application. Another detailed article discussing Push Notifications Support in AIR can be found at http://www.adobe.com/devnet/air/articles/ios-push-notifications.html
Remote notifications, or server push or push notifications, describe a style of Internet-based communication where the request for a given notification is initiated by the publisher or central server. It contrasts with pull technology, where the request for the transmission of information is initiated by the receiver or client (device in our case). Push technology has the advantage over pull notifications that device battery and network bandwidth are saved when no new data is available. Continue reading…
On iOS, an application in the foreground moves to background when user presses the home button, or presses sleep/wake button, or the system launches another application. Most applications get suspended on transition to background. Applications that have requested for background execution (such as playing music, location updates, file upload/download) may continue to run for a while longer. In order to improve the device battery life and user’s experience with the foreground application, iOS limits what an application can do in the background.
Default Behavior of AIR application on iOS
By default, an AIR application on iOS gets suspended on entering background, primarily to preserve application’s in-memory state. Thus allowing the application to be quickly re-activated when it is brought to the foreground. When a low-memory condition occurs, the system may purge suspended applications without notice to make more space for the foreground application. Continue reading…
Update in AIR 3.6: PreventBackup Property introduced for File Objects. More Details here.
AIR applications targeted for iOS may get rejected in the application review process with the reason “Rejection: 2.23 Apps must follow the iOS Data Storage Guidelines or they will be rejected“. Usage of File.applicationStorageDirectory or Local Shared Objects (LSOs) in the application might be the reason. Recently, Apple has updated the Data Storage Guidelines with the release of iOS 5. Since the guidelines are accessible only to registered iOS developers, let me summarize the key points below:-
- The entire home directory is backed up to iCloud by default, except the Application bundle itself, Caches directory and the tmp directory.
- In order to minimize the data that needs to be backed up, Apple expects the developer to adhere to the following guidelines:
- Only user generated data, which other wise cannot be recreated like an image capture or voice recording should be stored in Documents directory.
- Application Support Directory must be used to store only application specific data files. For example:- application configuration files or game levels. Data stored here is not vulnerable to be purged under low memory conditions. Continue reading…
Adobe tools like Flash Builder allow you to compile actionscript sources of your application and then package all the swf content and assets as .air, .ipa, .apk and native package formats.
This post is meant to stress on the importance of using Release version of swf file for packaging when you intend to publish it on an application store.
Why should I care to create the release version of a swf?
There are two major advantages of using the release version for publishing applications:
- Application Size – The debug version of a swf contains lot of extra information which is required for debugging during development. As a result, the size of debug version of a swf is always more than the corresponding release version. Continue reading…
AIR 3 Beta got released on Adobe Labs last week, providing a great opportunity to try out some of the exciting new enhancements that have been made by the team. Christian’s post provides the quick steps to get started with the AIR 3 Beta SDK.
In the “Additional compiler arguments” box, you need to add “-swf-version=13″ to make use of the new APIs introduced in AIR 3. So one question you might have is that if you are already specifying the namespace in your AIR application descriptor as 3.0, then what is the need of specifying more versioning information? Let me share with you some background about versioning in Flash Runtime.
Starting with AIR 2.6 release (and Flash Player 10.2), we changed our SWF versioning approach. Earlier we used to increase the SWF version only with major release of Flash Player. For eg. Continue reading…