I am creating the app for LG and panasonic smart tv's using smart tv alliance sdk. How can i package and test the app in the real tv.
Application deployment is vendor specific – i.e. Philips, Toshiba and LGE have different ways how they publish the application, they have different requirements for e.g. metadata, icon sizes, ways how to publish to for more countries, etc.
The certification for STA is described quite well on their web page http://www.smarttv-alliance.org/
BR
STeN
Related
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 have a Flex web application which uses Flex 3.6 sdk.
What are all the ways to port this application iOs and Android devices.
Before the release of Flash builder 4,
I have converted my Flex 3.6 project to AIR 2.0. (Which required very minimal code change)
and used some command line tools to package it to .ipa and .apk.
Sucessfully deployed it on a iPad. Application worked as expected.
This is all I remember, I totally forgot about the procedures that i followed as it was before two years.
Now in Flash builder 4, There is a option to create "Mobile Project" which exports the application for different mobile platforms just by Rightclick on project - Export - Release Build .
but this page tells that
"Except for the MX charting controls and the MX Spacer control, mobile applications do not support the MX component set defined in the mx.* packages."
Now I really confused which approach to follow.
Can some one please clarify on these
What are all the ways to port Flex3.6 web application to iOs and Android devices.
Do I need to convert my Flex3.6 project to Flex 4 project with all MX components changed to Spark components (This requires major change in my project) for mobile platform support.
Is there any other ways to port my existing Flex3.6 application to mobile with very minimal code change.
(I understand that changes like UI size, etc needs to be taken care)
Thanks.
First of all, I don't think reusing your web application as a mobile app is a very good idea from a user experience point of view, unless the interface is extremely simple (which wouldn't warrant a full blown Flex application in the first place).
the screen size is so different that it would probably be unusable, or at least uncomfortable
you have no touch interactions defined
But to answer to your questions: the mobile components are a completely different component set. They are more lightweight and optimized for mobile interactions. To achieve this gain in performance they were based on the Spark architecture. Which means that:
There is no way to port your Flex 3 code
Yes, you'll have to convert
I can't think of any other way to port your application; minimal code change is out of the question
conclusion
Both the fact that it is technically impossible to automagically port the application from web (Flex 3) to mobile and that - even if it was - it wouldn't be recommended because of UX concerns, lead me to this suggestion: rebuild it from the ground up, both taking care of clean, optimized code for mobile and designing a UI that is appropriate for the targeted platform.
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.
I have a web application that uses SAPI to do TTS. I run it on Windows Server 2003 that has MS Sam installed by default.
I understand that there are a number of 3rd party companies that sell voices. For a commercial application, which of these companies offer licenses that don't charge a lot of money? Do they have API to easily integrate with a ASP.NET app?
I really would like to add more voices to the application.
EDIT: Anymore answers? Thanks
EDIT
Judging by the question and comments it sounds like you have the rendering of the audio file and the delivery to the client down already.
Here's some aditional voices:
http://www.bytecool.com/voices.htm
http://www.nextup.com/attnv.html
Basically resells the AT&T Natural Voices. Which is very expensive to use in a server setting.
https://www.cepstral.com/cgi-bin/store/home reading they're page seems to indicate that a license to play the rendered files over the phone can cost as little as 100 dollars for 2 concurrent ports. Their internet licensing model seems to be based on the SOAP service they offer via voiceforge.com but the fact that the pricing page is not done yet seems to indicate this service is still being built.
http://www.microsoft.com/downloads/details.aspx?FamilyID=5e86ec97-40a7-453f-b0ee-6583171b4530&displaylang=en
Which leaves the L&H voices found on the bytecool.com site or the additional 5 SAPI voices offered in the SDK (setup pack for just the voices linked on bytecool.com).
The AT&T and Cepstral voices sound the best though you pay alot for them.
Changing the rendered voice should be as easy as setting the Sapi.SpVoice.Voice property.
As you may already know, Phoenix is developing an alternative computing environment based on top of its BIOS, called HyperSpace. According to its designers it should run "a collection of commonly-used browser-enabled applications designed to make the Internet browsing experience simple, fast and secure".
Although Phoenix has declared in its FAQ that you will not be able to install/run your own applications on top of the HyperSpace, in a recent interview on MIT's Technology Review said that they are planning to open in June an iTunes-styled store to sell applications.
I'm guessing they are probably up to Apple's business model of providing secure applications via a centralized service thus sooner or later a developer toolkit shall arrive.
Since Qt has an impressive record of cross-platform capabilities, do you believe that Nokia should make an alliance with Phoenix to port the Qt toolkit to the coming HyperSpace application developers? If it's not Qt what should the ideal developing platform for HyperSpace be?
It looks to me that this is basically a dual boot machine.
one boot goes to a version of windows that QT supports (or will presumably support).
one goes to a web browser and will only run web applications or widgets.
If your asking whether QT should allow you to target the second environment, then it all depends on whether that is even remotely compatible with the QT technological choice of including a Webkit engine.
There could also be a licensing issue.
I am not convinced the Hyperspace product is aimed at desktop developers the way QT is. I think it's aimed at web applications developers.
Edit: What you seem to wonder is whether Nokia sees a commercial interest in supporting Hyperspace and whether they have the resources to do it. Unfortunately, I suspect only the head of QT development at Nokia can truly answer that.
"I am not convinced the Hyperspace product is aimed at desktop developers the way QT is"
Qt is aimed at embedded mobile phone apps, they are now owned by Nokia, if Qt happens to run on desktops that is just a nice bonus for Nokia.
Given it's, small size, no external dependencies and 'easy to port'-ness I would have thought Qt was a good start for a bios-os desktop.