I'm developing an HTML application for mobiles and desktops. The application is optimized for WebKit based environment. To improve a rendering speed I'm using hardware accelerated layers (something like -webkit-transform: translateZ(0); etc...).
This works great on my iOS devices (using PhoneGap aka Cordova to package a "native" app).
On Windows and OS X I'm using Adobe AIR 3.5 to package a captive runtime HTML/JavaScript based application. I have found this to be the best solution (for now) even though I have tried many others (Cordova for Windows 7 / OS X, TideSDK, ...).
The point is that the HTML rendering in Adobe AIR seems not to be hardware accelerated. Does anyone of you have experience with this? Is here any possibility to enable hardware accelerated layers in AIR HTML rendering?
Thanks a lot :)
Related
A friend of mine has developed an excellent game using the starling framework. He is now wondering if he could port the game to FirefoxOS before he launches. The game is written in actionscript 3 and the starling framework project can build mobile packages for android and ios. It also can generate the flash file for the web (using flash player). Are there any paths for porting the game to FirefoxOS?
Someone suggested using shumway. If you know about this way, or any other path, please give a bief account of advantages/disadvantages. I am specially concerned about the performance, since the game in question has very high quality graphics. I think it needs to run in a GPU accelerated environment.
EaselJS uses a similar syntax to ActionScript; it has a Display List, Stage, Graphics and even Filters, this will make working with the canvas easier for us Flash developers.
I suggest you to port that game to EaselJS and TweenJS (both from CreateJS), I have used it to develop games for Firefox OS and worked quite well.
An advantage is that CreateJS now uses a WebGL renderer, but it also has a fall back to Context2D rendering if WebGL is not available. That would make your device more widely supported.
You will find all its features very explained in the following post from Mozilla Hacks. It has also some cool benchmarks to try it.
WebGL and CreateJS for FirefoxOS
Is there any way which can be adopted, to create cross platform responsive mobile apps using Flash Builder ?
We are using our custom written Resigning Engine for this purpose right now, but we tend to replace it with any generic Resigning tool or to cater responsiveness for all kind of devices/platforms.
Being on the same cross platform development, i.e. Flex, Action Script and MXML, is there any solution for this?
Thanks
It's possible deploy Flex-apps on Mobile devices, see Mobile app development
at Adobe Devnet more details
You definitely can develop Android and iOS apps using Adobe Air, Flex, AS3, MXML and publish them on Apple App Store and Google Play Store. But it's limited to these platforms, and Adobe is very unlikely to add any new platform to this list.
Pros:
it's really cross-platform. Once your application works on one, it's really easy to get it working on the other; so the development cost compared to native applications is much lower;
you may have some OS specific features/design; using by example OS specific CSS directives;
You perfectly may create an app with a responsive design, all tools are provided, but like for HTML/CSS, it requires a lot of work;
you may access all phone features (sensors, camera, etc...) using Adobe Native Extensions
Cons:
the size of the generated application: as it includes the AIR runtime, even a very simple app will weight around 12 Mb (9 for the runtime + 2.5 for Flex);
the performances are correct but not as good as those of native apps; one of the reasons is that Flex does not allow to use GPU for rendering (but Flex is not a framework for creating games);
it would be costly to get an app looking like a native one, as you would have to mimic all of native components. There was a project to do this (Eskimo), but it looks dead, and the components were not polished enough to be used in production when they stopped the development;
Adobe Native Extensions offer is rather limited, and they are quite tricky to write; (these drawbacks are not strong ones: you can write extensions, assuming you know to write native code; and most of the common features are available as ANE);
like with any other cross-platform technology, there are a few issues that you can't fix by yourself; you just can wait for Adobe to fix them when it's a problem in the compiler or the AIR runtime; hopefully they follow a 3 months release cycle since they launched AIR on mobile;
it runs on Android 2.3+ devices only; and only devices that are matching the minimal requirements defined for the AIR runtime; that is to say, most of the smartphones and tablets, except cheap ones like ZTE products. When a device is not considered as powerful enough by adobe, the AIR based apps are not displayed in the stores.
Some recommendations:
The best way to organize your code is to create a project for each OS, with specifics assets (icons by example) and a specific manifest file (app.xml), and put all of your application code in a library used by these two projects. It will allow you to test your code (Flex mobile project can't be unit tested), and will avoid you permanent modifications of the manifest.
Worflow: it's usually faster to develop for Android, and then adapt you app for iOS, because it's faster to deploy and test on Android device (although you may use the Adobe Simulator most of the time).
Use the latest release of Apache Flex; it handles the high resolution devices. Forget Adobe's release (4.7 and lower)
Test quickly and often on mobile, especially for the responsive aspects.
Use FXG instead of bitmap graphics each time it's possible (i.e. if they arent animated); it's lighter and very easy to scale.
Mad Components
Alternatively, you may consider using Mad Components instead of Flex.
Flex was not designed for mobile at first; MC was. So it's faster (looks like native), and much lighter (although you still need the embedded AIR runtime which weights 9 Mb).
This month I started to play with Flash Builder because I don't have a mac to create native iPhone apps.
I have made a Flex Mobile Project and an AS3 Mobile project. Both do mostly exact the same and I see great differences in operation speed (AS3 version is much faster). Also the size of the AS3 version is less than the size of the Flex version when I deploy the project.
But one thing disappoints me, the size of a deployed AS3 app (Android) is still about 8MB. I think that is quite huge for a simple app, or is it normal? I did not test the iOS version because I am not an Apple Developer member (is there a trick to deploy an iOS app with fake certificates)?
Resources I have used in the apps:
Two images approx. 35kb in size
A StageWebView
I want to know:
What is the average size of a simple app when it is a native app (apk file)?
What is the difference between an AS3 app and a Flex app except the libraries that re used?
Is the AS3 app converted to C or another language?
Why is the apk so huge (IMO)?
Is there a trick to deploy an iOS app with fake certificates? (just for testing)
Thanks for the answer(s).
What is the average size of a simple app when it is native app (apk file)?
I have no idea. When you were comparing sizes; did you export a release build or a debug version? The full version of my app; using Captive Runtime is 12MB. That includes all the embedded images. I thought that roughly 8MB is the size of the embedded runtime. Of course, if you don't use Captive Runtime then the app will be smaller; but it will have a depency on the user having the runtime installed.
What is the difference between an AS3 app and a Flex app except the libraries that are used?
For all intents and purposes nothing. The Flex Framework will need to execute code to setup the framework and such. In theory this 'impact' is offset by the value that the framework brings.
- Is the AS3 app converted to C or other language?
Not for Android or Playbook. It relies on the Mobile AIR Runtime--which I assume is written as a native app somehow. For iOS there is a more in depth conversion taking place; but no on knows the exact magic sauce; but it the process is much more intensive than Android or Playbook and people believe that your code and the AIR Runtime is converted to Objective C somehow in a way that is not in violation of the Apple licensing agreement.
Why is the apk so huge (IMO)?
Huge is open to interpretation. Without seeing your full app code; it's tough to judge.
Is there a trick to deploy an iOS app with fake certificates? (just for testing)
I don't think so; although there may be possibilities on unlocked devices.
You would like to use Mobile AS3 Project if you want you apps to be smaller and your GUI mainly contains vector graphics and Mobile Flex Project if you prefer to use standart GUI Controls that comes together with Flex framework but adds overhead in size because of controls that come with it.
As of the other questions:
the size of the apps is different on mobile platforms. Typical iOS app is about 2MB - 20MB. It really depends on resources you store with your app. What might be important to you is not to overcome 20MB if not needed because 20MB+ apps require Wi-Fi connection to be downloaded.
(However you should export release build version only as mentioned by www.Flextras.com)
there is no fundamental difference between AS3 and Flex apps - they both compile to the same instructions that executes on targeted mobile platform.
as far as I know (being iOS developer myself) there is no workaround to deploy an iOS apps. You need to use Mac and become Apple Developer to deploy with valid certificate.
to make your app smaller try to pai special attention to the resources you add to the project. Although I believe the size is so big because of framework itself, you would like to use more vector graphics vs. bitmaps when compiling apps with Flash/Flex.
When you export for Android you have an option of embedding the air framework in the application, that way your users don't have to download air. you can export your application without air embed which will result in a much lighter application, however your users will need to download air runtime. http://cookbooks.adobe.com/post_How_do_I_create_an_AIR_application_for_Android_tha-19299.html
I have a simple game that I am building in as3/air using flash develop, and I would like to be able to put it onto the iPad 3.
My question is, if I develop the app in a 1024 x 768 resolution, will it scale effectively when deployed onto an iPad 3?
All assets will be vector art, so losing quality from scaling isn't an issue.
if you publish it out to with the param fullscreen = true then it will automatically scale up. Though just be sure to optimize everything to the fullest extent as vectors are pretty processing intensive.
But it also depends on the version the SDK you're using, the newer air 3.3 sdk i believe supports it.
I am building an enterprise application using HTML5 for Blackberry OS 6.0. I am planning on using PhoneGap for developing the application. I found out that Blackberry also has something similar called WebWorks.
What are the differences between WebWorks and PhoneGap?
PhoneGap-BlackBerry-Widget uses the BlackBerry Widget SDK to support BlackBerry OS 5.0 & 6.0. WebWorks is basically Widget SDK 2.0 and it is intended to support OS 6.0 specific features.
The advantage of using PhoneGap-BlackBerry-Widget over WebWorks is that you can port your application to other platforms that are supported by PhoneGap.
You can still port an application that was written using WebWorks/Widget SDK, but you will need to switch out the BlackBerry-specific JavaScript bindings for the PhoneGap JavaScript bindings (e.g. invoking Geolocation, contacts, or accelerometer).
Looks like WebWorks is specifically for BlackBerry while PhoneGap is attempting to support multiple mobile platforms.
I haven't looked too deeply into WebWorks, it appears to be more tightly integrated with a specific device, a Blackberry
WebWorks is a specific development tool managed by RIM for BlackBerry, while PhoneGap is in the MEAP (mobile enterprise application platform) space where they represent the next generation of mobile development. You develop your app with PhoneGap and it helps you to deploy across all major platforms such as iPhone, Android, Windows Mobile and BlackBerry. If you're a developer then it opens the doors to more phone models and increased opportunity for app sales.
webwork vs phonegap
both are used for build application .using webwork u get for feature for specially blackberry....using phonegap u can use same code for multipal phone like iphone,android..
but i prefer webwork because phonegap add unwanted code to your applicatio due to application very slow ....phonegap + wework in blackberry 5.0 take too much load...it's min size is around 600 kb......
so for blackberry webwork is better than phonegap
One issue to consider is testing and compiling applications.
When testing on devices and simulators it is possible to compile/sign once and access/edit your JavaScript and HTML5 from a remote location, such as the SD Card or a local server. While PhoneGap and WebWorks are both using JavaScript to access native functions, I have found the 'compile once' method doesn't seem to pick up and utilise PhoneGap - this is also the case with the Ripple emulator. In my experience, using PhoneGap requires multiple, time-consuming compilations and launches when testing an application. If testing on a Blackberry device, you need to factor in the time it takes to have your app signed prior to each test and the time it takes for the device to reboot. I'm talking 2+ mins on a simulator or 4+ mins on a device, per each change to your code.
I'm working with webworks for Blackberry and phonegap for iPhone. Not sure whether the problem is with webworks or underpowered handsets but we've had to spend a lot of time ripping features out of the webworks app to get any kind of robustness or performance when running on the device. Static google maps and thumbnail photos had to go.
All webworks apps on a handset share the same pool of memory, about half of the memory available to the BB browser. Webworks also leaks memory. There's a thread a year old on the webworks forum about the memory leaks and no solution forthcoming from Blackberry, just "workarounds". We had to alter the webworks sdk to make the garbage collection more aggressive to stop the app running out of memory all the time. But if other webworks apps are running on the handset and haven't had this GC tweak you will still get grief with memory.
Don't know if phonegap is any better than this but it'd have to go some to be worse than webworks.
If you want to do a webworks app keep the design simple, package all the graphics and assets in the deliverable (we were trying to get icons from an api but have ended up storing them base64 encoded in localStorage) and get it onto a handset asap so you don't waste time adding features that the handset can't cope with.
To sum up, webworks is pretty poor.
PhoneGap : is an application with a webview control that renders your HTML5 and JS. PhoneGap has diferent versions or say release for different platforms like Android, iOS, BB, WP8 etc.
WebWroks : is conceptually the same thing as PhoneGap just that it is owned and developed by Blackberry (Previously RIM) themselves.
Also one most important thing in the context of the question is that, for Blackberry Phonegap uses WebWorks as its base, that is why while developing PhoneGap Apps for blackberry you need to download WebWorks SDK first, the build process is also the same as WebWorks so the benefit of using Phonegap for balckberry is that the same HTML5 + JS Code that you used for say Android will work on Blackberry as well.
However BB OS 7 and below do not have the best WebView Control, BB 10 and playbook are MUCH MUCH Better.