Just to be clear ,this is a university project that i am doing ,this is my first time working with flash/AS.i am half way implementing the mobile web application.I have used Flash Lite 4 and Actionscript 3.
http://en.wikipedia.org/wiki/Adobe_Flash_Lite
"Adobe Flash Lite 4 has been released (2010) and integrated in Symbian^3 (Nokia N8, Nokia E7...)"-wikipedia
The problem is only a no of devices are currently supporting Flash Lite v4.my question is would older models able to render it?
Depends! if you are using Flash Lite 4 specific features, it won't run on earlier devices.
Not clear from your question, if you are concerned about specific APIs/features.
I would advise to compare Flashlit 4 API and previous versions:
http://www.developer.nokia.com/info/sw.nokia.com/id/43ca0681-c8c6-4684-ad71-c4ac41f3ee4f/Flash_Lite_Developers_Library.html
Also check if the SDK supports full-backwards compatibility
Flash, especially FlashLite, is only supported on a very limited selection of devices. The very fact that Adobe does not make a big show of what devices actually support it should give you an indication of its adoption rate.
Apart from hardware capabilities, there are also limitations on a per device basis, based on carrier constraints (some devices which might technically support the FlashLite runtime may have its installation restricted by carriers who block user installation of apps).
Related
I'm new to VR development, I am a bit confused what's the differnce and the relationship between Cardboard Sdk and Oculus Sdk, if I want to develop an App which can play 360 VR video or photos, then which one is better I should to choose?
By Oculus SDK, I assume you mean the mobile SDK for GearVR since you mention cardboard. If you're talking about the SDK for PC, then the question is Oculus vs SteamVR vs OpenVR vs Morpheus :)
The major choice for which to develop for I think probably comes down to what your timeline and audience is.
GearVR is the best quality device out there right now and it is SIGNIFICANTLY more polished than cardboard, and it requires specific expensive hardware (Note 4 or S6, soon the Note 5). It has a store that people are buying things off of (even if it's not much yet). But since GearVR apps in development need to be signed, you will only have an audience if you can commit to at least a demo that will be accepted on the Samsung store. (the alternative is to have every user use the developer-signing system, which means you'll get tens of people instead of thousands to see it probably)
Cardboard is a very short-term experience. There are no head-straps on cardboard for a reason - it's intended to be something you hold up for only a minute or two at a time. Most of the audience is people interested in tech demos, but many more people will be able to try out your app. Google is working on stuff behind the scenes, so there may be more meat on it in the future - a non-cardboard VR device I've heard rumors of, and they're pushing cardboard pretty hard for classroom experiences. And in a couple years, every phone MIGHT have sensors good enough to give a GearVR-level experience.
Both SDKs will give you the basic two-eye 3d stereo rendering framework. Oculus' is a little more fleshed out with some built in scene loading (it converts from FBX format which is made by MODO, which is expensive) and a UI library (I'm not very happy with it though).
Either way, most of the work you do will likely be independent of the SDK you use, so I don't think you'll be boxing yourself in whichever one you choose.
Now that unity natively support Virtual Reality you can use both of them in your project but it is a bit tricky.
Have a look at this tutorial that show how to compile for both the Cardboard SDK and the Unity Virtual Reality Supported option:
https://github.com/ludo6577/VrMultiplatform
If it's a web based project a-frame might be all you need.
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).
So, our Windows Phone developer left recently, and I primarily do Android development.
We had a question from a client about the possibility of installing our Windows Phone 8 app on a Surface Tablet. Namely, is it possible to do? As it stands, our WP8 app was not written with tablets in mind, so my question is:
Is there anything I need to do to the WP8 app to get it to install on a tablet, (should it work as-is (like Android apps do), is there some sort of flag I have to enable and then rebuild, etc.?)
As #AMR mentions, the biggest challenge will be the UI; however, depending on the device functionality being used, the "backend" may or may not be a challenge as well.
There is great guidance on the Windows Phone Dev Center about practices and techniques for building for both platforms, so depending on when the phone app was built and your former developer's awareness of the overlapping platforms, you could be in great shape or just so-so shape.
Additionally, the following resources may be of help in mapping from what you have already coded in Windows Phone 8 to what you'd do in Windows 8:
XAML controls comparison between Windows Phone 8 and Windows 8
(much will be relevant to Windows Phone 7 too)
Windows Phone 8 and Windows 8 platform comparison (shows common
APIs, storage, networking, etc.)
Lastly, the Windows Phone Runtime API documentation gives a listing
of APIs only on Phone 8 vs. APIs adopted from Windows 8.
Okay well first off yes, there will be a few things that change but nothing to serious.
HOPFULLY you have a good MVVM model. If this is the case then you should be able to just copy and paste 99.999% of your backend code right into your tablet app. There are a few things that are different but its just namespace stuff. Nothing too serious.
The Major change is going to be your UI layout and UI controls. Depending on what libs you are using you will probably have a lot of conflicts.
Your best bet is to just copy and paste your backend code in and then creating a new UI. I have tried to merge phone UIs in the paste into the tablet and its rediculous at times. I found it takes less time to just recreate it.
If you need any help you can hit me up at www.AnthonyRussell.info Maybe I can help with your transfer. Just make sure to leave your contact info.
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'm completely new to Windows Phone and the Windows galaxy in general as far as programming goes. For a project of a phone app that has to run on a windows phone, I started exploring the resources and I have some questions.
One of the problems I encountered is that things change very quickly. For example, answers to this question say that browsers in Windows Phone will most likely not support HTML5. However, there are many online tutorials (for instance here) introducing ASP.NET MVC 4 and how it is appropriate for mobile apps.
I would personally like to go the "HTML5+javascript" way instead of learning how to develop with Silverlight, which apparently has been discontinued by Microsoft. However, my first concern is evidently to be able to create an application that works!
So with that in mind, my questions are the following:
My impression is that HTML5+JS is being introduced in replacement of Silverlight and will be more used in the future. Is that correct?
Knowing that I have to build an app which should be able to play videos and audio, record audio, and connect to a library to do some speech processing in the background, should I use Silverlight or can I try using ASP.NET MVC 4? (From what I gather, Silverlight would be better than XNA)
Are there limitations to using HTML5+JS as compared to Silverlight or the other way around?
Can you package a web app (i.e. using HTML5+JS) to be used locally on the phone if there is no access to a distant server?
Any specific pointers or answers on these specific issues will be more than welcome! :)
Currently, Windows Phone 7.1 does not support full HTML5+JS as a replacement for Silverlight. In Windows 8 (NOT the next version of windows phone, but the next version of Microsoft's desktop OS), HTML5+JS is presented as an alternative to using XAML and C# (it's a little confusing because on Windows 8, "metro" apps do not run Silverlight, but they still operate using XAML and C#). But that's neither here nor there... To summarily answer your question(s): In the phone's browser, there is very limited HTML5 capability.
From what you've described, you definitely want to use Silverlight for your Windows Phone app. The answer to that part of your question has never changed, Silverlight from the beginning of WP7 would be your best option. XNA is exclusively designed for gaming development.
To answer all of your questions, point by point:
My impression is that HTML5+JS is being introduced in replacement of
Silverlight and will be more used in the future. Is that correct?
This has not been confirmed (as of this post), but speculation is that this will be the case in some future release of the OS (no word on when that may be). But no, this is not currently an option, and there is no promise from Microsoft that it ever will be.
Knowing that I have to build an app which should be able to play
videos and audio, record audio, and connect to a library to do some
speech processing in the background, should I use Silverlight or can I
try using ASP.NET MVC 4? (From what I gather, Silverlight would be
better than XNA)
Silverlight. Silverlight. Silverlight. :) ASP.NET + MVC will not work. XNA is intended to be used for building games. Attempting to build more standard user interfaces using it would give you a migraine to say the least, and would not look anywhere near good.
Are there limitations to using HTML5+JS as compared to Silverlight or the other way around?
and
Can you package a web app (i.e. using HTML5+JS) to be used locally on the phone if there is > no access to a distant server?
As answered above, there is no way to do this on the phone.
As for pointers on all of this. I strongly encourage you to simply google (or bing if you're into that kind of thing) "getting started with windows phone" or "windows phone tutorials". Best source I could point you to is the Windows Phone Developer website. It's got some great tutorials that don't assume you know lots about windows phone. Best to get this material from Microsoft. It'll be more reliable, more well written, and ultimatly more useful. I've been writing Windows Phone apps since before the phone was released, and I still use it for learning the basics of something new. Great place.