I am writing an application which requires access to the microphone of a device to determine instantaneous volume levels. The app will have a web version, iOS version, and Android version, and must be compatible with as many devices as possible, since the particular user base our application targets may not be able to switch browsers easily.
At first, I looked into using HTML5 for my application. However, it does not seem to be viable for my purposes, because I can't find any cross-platform way to get instantaneous microphone input and many users may be using an out-of-date version of their browser, which would not support HTML5. Is there any tool which alleviates these challenges and would allow me to use HTML5?
As a replacement, I began looking into Apache Flex. It seems to have all of the features I seek: It is cross-platform, allows me to access microphone volume levels, and will work even on very old devices, as long as they have Flash installed. However, many people predict the imminent death of Flex and strongly argue against using it, opting rather for HTML5. For my purposes, is Flex an appropriate tool, or would it still not be recommended?
You can achieve it by using PhoneGap or similar backend app which can host a webview and allow you to access native api through JavaScript or JSObject.
For front end, you can use HTML and keep your UI standard across all devices/platforms.
PhoneGap is little bulky but on Android and iOS, you can create a minimal app by hosting WebView and customize it to create JavaScript bridge and write your own native api.
Related
I am experienced writing automation tests for web apps using Selenium.
However I now have to automate a Windows Desktop app which I'm new to.
I'm using QTP 11 (old version) and I can get QTP to login type username/password to the desktop app. However when the app loads there are icons like a Windows desktop. I tried using ObjectSpy on the Actions folder icon but it can't find the object ID and it thinks the icon is a WinObject("COMPOSITE")
Also tried using QTP Record feature but the code that it generates uses hardcoded x and y values. I don't want to use x,y values as if the Actions icon moves 3cms left or right in future the test will fail.
e.g.
Window("Loan IQ").WinObject("COMPOSITE").Click 369,33
Need help finding the object ID in a Win32 app. Thanks
First of all you should make sure that UFT is configured to test your application. In the Record and Run Settings dialog, make sure that either _any windows application__ is selected or your app is explicitly listed.
If this doesn't improve the situation you can try using image based testing (aka Insight).
WIN32 Apps can be a nightmare to automate especially with QTP 11, as it is a kinda outdated version. If you want to get stable automation I propose the following:
Upgrade to a newer version of UFT (14+)
This will most probably not help you indentify the objects but will have a lot of new technologies supported that may help you as described in the following steps
Use Image Based Recognition
Even if your screen resolution changes UFT is still able to identify pictures.IT does not use absolute vectors to compare bitmaps but a different technology which I won't go in detailed (long story short, screen resolution changes are okay)
Provide support for your Widgets
Microsoft has 2 frameworks that can be used to provide UI Automation capabilities (initially for people with accessibility needs, but now is used for RPA and GUI Testing). UFT supports the MSAA and UIA frameworks of Microsoft so if your company is ready to implement support for the UI widgets via one of these Technologies, you are on your way for a smooth Test Automation Experience. Please note: This is mostly a huge investment, so if the tool is something internal and not planned for longer term usage, go with the image based Recognition
since I am new in the world of developing apps for watches, and the fact that it exists for smartphones the following frameworks:
Xamarin
PhoneGap
appcelerator
kony
Cordova
...
I wonder if there exists for watches apps similar frameworks? So that you code once but run overall.
Thanks
Edit 1:
At this day (12.05.2015) regarding to the answer of a nativescript maintainer here. I will go with nativescript to start writing app for wearables.
Cordova/PhoneGap apps don't work directly on the wearable devices/watches. Cordova/PhoneGap is basically a javascript API which can run on WebKit/WebView on all the mobile OS's. But the Android Watch and Apple Watch doesn't support WebKit and so the apps developed with Cordova don't work directly on Watch devices. But if want to extend some of the features from the existing Cordova app to the wearable app, you need to create the extension app in native language and the extension should be able to communicate with the paired app on the mobile device. The extension on the Watch will have only UI and the bussiness logic etc runs on the Cordova app on the mobile. It is possible to establish communication between these apps which will drive the display on the watch devices.
I am not sure about the other frameworks you listed above on how much they support wearable devices.
As #kiran and #NRimer have mentioned, these cross platform frameworks are relying on the WebKit/WebView which is the almost universal layer supported on every mobile device. They dont run directly on the device, but device runs WebKit platform that runs these cross platform apps. So comparing the capabilities of the native app with cross platform app, native app is bigger, because it can have a hands on device hardware related features. The thing particular to the smart watches is that they mostly rely on other smart phone device, and it uses it's communication protocols, that are hardware specific, and WebKit doesnt have its hands on it.
It depends on what you're looking to do with the framework. Watch apps build off data provided by their containing app. For example if you want to provide custom notifications on the watch, the app (or server for remote notifications) constructs them. When your watch app needs information, it makes a request to the containing app. Lets say you have a group of apps that you want to provide the same notifications or functions on each of their watch apps, you could make a framework that handles these functions for the containing app. As for the watch portion, think of it as more of a display of information provided. Unfortunately i dont think there's a way to generate frameworks for watch apps yet. If you're looking to have a lot of code within the watch app this might be more difficult but for simple display of information you should be alright.
I talking about Native Client thing for google chrome...
Developers claim it can run native code compiled from c / c++ in browser's sandbox.
They describe a lot of things, but never point at what I need... So, if I create window in my application with CreateWindow, would this window appear when my Native Client application loaded into browser?
In short, no. Two key things to know about apps that use Native Client in Chrome:
They are platform independent (platform-specific calls are
disallowed).
They are still web apps with the restrictions and possibilities that come with that.
If Native Client allowed operating system-specific calls like CreateWindow, it would no longer be platform independent (and it would also present a security risk).
Instead Native Client provides a set of platform-independent APIs called Pepper or PPAPI that work the same for all supported operating systems (currently that's Mac OS, Windows, Linux, and Chrome OS). As mentioned, apps that use Native Client are still web apps, so Pepper gives the same possibilities and restrictions that you'd expect from JavaScript. E.g., you can fetch URLs or ask the user for fullscreen permission, but you cannot access any random file from the local file system (app-specific isolated local storage is possible; as is having the user upload a file for the app to use).
Moving an existing C or C++ codebase to Native Client is very much like porting to a different operating system. Instead of using, say, Windows API calls, your app should use Pepper API calls.
For additional background it may be worth noting that Chrome Packaged Apps can request access to a much wider set of APIs in the chrome.* namespace. These APIs include USB, sockets, opening new windows, and more. A Chrome Packaged App will still not be allowed to make OS-specific calls, but they have access to quite a few more APIs, all of which are platform-independent.
In short, if your app can be made to work with the Pepper API plus the chrome.* APIs, you could write it in Native Client and JavaScript, and you'd have an app that worked the same way across the four operating systems mentioned above. If your app cannot be made to work with those APIs, Native Client in Chrome is not the right choice.
Seems not.
This is a bit related: http://ssj-gz.blogspot.com/2013/01/emscripten-qt-progress-faster-better.html. It's translated to javascript, though, and only for QT. And slow.
Can a Flex application that was designed for use on a PC be run on an iPad, iPhone, or Android-based mobile device?
Seems like a simple enough question. Visiting http://www.adobe.com/products/flex.html yields a picture of a dude running a (presumably) Flex application on an Android. So at first glance, the answer would appear to be "yes." End of story.
but yet…
There is so much (mis)information out there on various tech sites that suggest Flash-based technologies simply won't run on iOS or other mobile platforms. Why is this? Perhaps they mean to say that Flex won't run "out of the box" and requires a plugin? Or do they mean it won't run at all?
Every time I think I've reached a definitive conclusion, some post on SlashDot or CNET directly contradicts it. So what's the scoop? Can one take an existing Flex application and run it on iOS/Android? (I realize there are screen size issues to consider so the app might not run effectively. I just want to know if the runtimes are available on the mobile devices to allow the Flex app to launch at all.)
Sorry for the noob question. My background is WPF / HTML5. Adobe technologies are completely foreign to me.
I wrote a lot below if you'd like to read it enjoy, if not sorry for taking your valuable bytes :) I directly answered the questions up here first:
Why is this?
It's a confusing matter read below for the why details.
Perhaps they mean to say that Flex won't run "out of the box" and requires a plugin?
Or do they mean it won't run at all?
Using the flash builder tools (the bin folder in the SDK) you can compile for native desktop application, desktop web browsers, native iOS application, native Android application. Android with FlashPlayer plugin installed will show Flash content within the web browser, iOS will only run the ones compiled with AIR, not in the the web browser but as a native app.
Every time I think I've reached a definitive conclusion, some post on SlashDot or CNET directly contradicts it. So what's the scoop? Can one take an existing Flex application and run it on iOS/Android?
Yes, if using AIR and run as a native app on all three platforms (the desktop Flex API is for the most part a superset of the web Flex API), your other points about performance and form factor are valid and should be considered though. The nice thing is you can write your model/controller code in a common library in AS3 then write separate presentation layer interfaces that all share the library.
Here's the very long version:
Using the flash compiler results in "bytecode" in the form of a file with a swf extension using the swf format, you can read a ton more about that here:
http://www.adobe.com/devnet/swf.html
To interpret the file you need some sort of run-time similar to some degree to running WPF/XAML/C# within a .NET framework context (either desktop or using silverlight on the web). In the case of adobe technologies (rough equivalence):
AS3 = C#
MXML = XAML
Flex = WPF+WCF (client side RPC not server side)
Flash Player = Silverlight
AIR (Adobe integrated runtime) = .NET
Framework Redistributable .dll(s)/.so(s) for desktop OSes
(Read this list very loosely please, I know XAML is preserved in the MSIL or whatever which is different because MXML is compiled to AS3 and only if a debug flag is set on the compiler does it include the debugging symbols, there's certainly tons of differences but I think this is an easy and correct enough model to use)
On iOS the browser does not allow for plugins in the traditional sense of netscape browser plugins or ActiveX plugins. For this reason you'll not be able to execute a plugin ie flashplayer or silverlight in the browser. Since Adobe did release a flashplayer for Android devices that does run in the browser it will work on those devices in the browser, however they have essentially thrown in the towel for supporting this long term, as they have to support the majority mobile device platform, iOS, in order to remain relevant (this was I think more a collective throwing in of the towel by Google, device manufacturers, carriers, Microsoft, all just following suit and trying to make the best business decision, WebKit and V8 or SpiderMonkey can probably do 99% of what Flash can do and better in some cases and WebKit will hopefully not splinter and will remain open source... frameworks and the browsers just need to get fleshed out and stabilized).
If the user installs AIR (or the runtime is packaged with the app) then a Flex/Flash (that is stuff coded in AS3 and/or MXML and compiled to a swf) can be transcoded/packaged to be interpreted by the run-time for that device correctly (be it iOS or Android or whatever RIM did, I don't think they have AIR for Windows Phone 7 and Win8 on ARM won't support browser plugins either). Part of the confusion is possibly from the fact that Apple denied the distribution of Apps that were "cross-compiled" which kept AIR out of the list of options for iOS for a good year, just after Adobe started announcing it was usable for that purpose (kicking Adobe while their down). Another part of the confusion probably comes from real vids of people who have 1 hacked their device or 2 were able to get open source alternatives to the flash player run-time to work on their iOS device (gnash was one I'm aware of from some occasional Linux tinkering, also possibly FAKE vids).
You can run Flex applications on mobile devices, but you cannot simply run any Flex project.
In Flash Builder ( Flex Ide) or in Flash Professional you can create mobile projects. These projects generate native applications for iOS and Android.
Last time I tried, the result and the available components where less than what I expected. So, if you can, I'll much recommend you go for something like Appcelerator.com or similar, which turns HTML5/Js code into native apps. I tried them, worked a lot better than Flex.
Short answer: No
Long answer: You can use Adobe's tools to compile your Flash/Flex app for use as a native iOS app. So you won't be able to embed the app in a web page like you normally could with Flex, but you can build it as a native app. Note you have to have Flash Builder 4.5 to do this.
It won't run on iPhone as a .swf file, but it will run on Android based devices that have adobe flash installed. It will also run on the BB playbook, which also has flash.
Flex is a framework.( Anyway it is very beutiful one which even sometime looks like complete different language ).
As soon as you are building AIR application it can run on various platforms like : Windows, iOS, Android, upcomming TV's, PlayBook, even .. into the future ( maybe/hopefuly ) on Windows Phone, plus Linux ( which AIR future is not very clear anyway ( but hopefuly Adobe will reconsider ) ).
So - application created with Flash Builder 4.5+ would probably run everywhere as soon as it is AIR application.
The compilation methoods is really simple, and you almost simultaneously compiling for everything you wanna to.
And one of the most important things here - your applications will run, work, look and feel the same way you were designed on one device. Flex is the thing which is responsible for everything to looks beutiful on each platform it is running.
For instance i am compiling currently for Android, and without even test i can clearly say that it will looks and feel the same way under iOS and Windows, and it will.
Ive tried asking on the blackberry forums with no luck... Maybe there are some Blackberry/Adobe experts here...
Im just about to start a project using Adobe AIR/flex for the Blackberry Playbook, I have a few questions:
If I develop an application for the playbook, will the same application be able to run on a desktop? If so will there be any differences?
What is the difference between the desktop and mobile libraries? Can I only access a subset of the SDK on the mobile device compared to the desktop?
Can I create a playbook application that can call methods to a JAVA back end, located on my server?
Thanks
Phil
What’s different about developing a
mobile application versus a web or
desktop application? While many
existing Flex concepts and patterns
carry over directly to mobile
development, developers will need to
take into account the differences in
interaction patterns, screen real
estate, and performance
characteristics of mobile devices
compared to desktop computers. As a
result, we recommend using the new
mobile features in Flex to craft UIs
specific to mobile devices, while
sharing underlying model and data
access code with your desktop or web
application. Additionally, we
recommend certain best practices when
developing mobile applications with
Flex, such as using ActionScript and
FXG rather than MXML for creating item
renderers and skins.
Taken from http://labs.adobe.com/technologies/flex/mobile/faq.html#differences
As per my usual qualifying statement: I haven't tried this. Since this is of some interest to me and I've got a bit of free time I'll give making a hero app and running it as a desktop app versus as a mobile app a shot and post back here once I have it working or find a wall.
The runtime: Adobe AIR 2.5 on mobile
devices The initial versions of the
mobile development features in "Hero"
and "Burrito" are targeted at creating
standalone installed applications
using the Adobe AIR runtime for mobile
devices. By focusing on AIR, Flex can
take full advantage of the integration
AIR provides with each mobile
platform, such as the ability to
handle hardware back and menu buttons
and to access local storage.
Running on AIR Finally, it's important
to realize that in addition to all the
mobile Flex components listed above,
you can also directly take advantage
of all the APIs that are available in
AIR on mobile devices—geolocation,
accelerometer, camera integration, and
so forth. While some of these features
are not exposed as Flex components,
they are easy to access directly using
ActionScript. For more information on
developing using the APIs provided by
AIR on mobile devices, see AIR mobile
docs.
http://www.adobe.com/devnet/flex/articles/mobile_development_hero_burrito.html
Basically it's looking like the answer to all the questions is positive.
Yes and likely yes. (as they re-iterate throughout anything I've found on the topic the controls in Hero were made specifically for touch, taking into consideration the fat finger vs the mouse pointer, my guess is it will render slightly differently on the desktop and it's best to actually develop the UIs separately, although the web-services/model can be combined into a shared library/project)
You should have access to everything provided to the desktop (plus info from GPS/accelerometer etc., but obviously wouldn't get those on desktop), but don't have nearly as good a processor so what will work on the desktop may not on a lower performance computing device, but for low resource consumption tasks this shouldn't be a worry.
Yes this is a core feature of Flex, I don't see how it would be possible to make a (useful) RIA without web services. For confirmation on this one look no further than Adobe TV: http://tv.adobe.com/watch/adc-presents/flex-mobile-part-1-beginning-a-mobile-application/ <-- that app is using a web service (doesn't really matter to Flex what the underlying server technology is so long as it can make HTTP requests against it, RemoteObject/AMFService should serve your purpose)
If I develop an application for the
playbook, will the same application be
able to run on a desktop? If so will
there be any differences?
Depends. the Air file for both desktop and Playbook is exactly the same, however for Playbook development, RIM has provided an Air library so that Flex developers can take advantage of the hardware further than just the normal Air capabilities. With that said, if your application is dependent on that extra library, it will not work on desktop.
What is the difference between the
desktop and mobile libraries? Can I
only access a subset of the SDK on the
mobile device compared to the desktop?
Desktop and mobile libraries? Do you mean the Playbook Air Library or something else? See above for the latter. Comment on this if you can clarify.
Can I create a playbook application
that can call methods to a JAVA back
end, located on my server?
Yes, you can, as long as you have internet connectivity on the Playbook.