we are starting a new desktop project and we are evaluating adobe air as our development platform. this is because most our team are flex developers and we want to take advantage of that. but we have several question in order to decide whether or not to use air as a development platform.
How recomended is to use a bridge to
communicate with peripherals through
serial and paralell ports.How can i
communicate air application with my
system database.
There is a well known framework for
object persistence, like hibernate
??. if not, what is the best approach.?
Which are the best approach for our
applications distribution, how can we
deal with product key, product
licenses, etc. What advantage do we
have using AIR MarketPlace ?
Any help you can provide me, to point me in right direction, i will appreciates
Cheers,
system communication via NativeProcesses (since Air 2.0)
Air supports SQLite; from Air you can communicate via RPC or socktes with (for example) a JavaServer with Hibernate
Air App Licensing with Sharify
Damian
Related
Is Universal Windows Platform the replacement of WinRT of Windows 8 and Windows Phone apps?
I mean, there was a WinRT platform to develop metro apps exclusively for Windows 8. Now, that is replaced by UWP, isn't it?
That is correct, UWP is the new platform for ALL Windows devices going forward (Win 10+). However WinRT is not replaced by UWP but is instead an extension on top of it, making UWP a much broader set of APIs that can be used across even more devices. As Microsoft themselves state:
With this evolution, apps that target the UWP can call not only the WinRT APIs that are common to all devices, but also APIs (including Win32 and .NET APIs) that are specific to the device family the app is running on.
The UWP platform supports the "Universal Device Family" class of APIs which is then supported on ALL windows platforms (Xbox, Phone, Desktop etc). There are some extension families that you can use that will limit the apps reach, such as a "Mobile Device Family".
These specific device family APIs can however be checked for and used at runtime gracefully. For example you could show your own position using GPS on a phone, but not enable that functionality on a Xbox.
I hope this answer helps you, if you have any more questions about this I recommend reading this article about the UWP platform:
Source: https://msdn.microsoft.com/library/windows/apps/dn894631.aspx
Have a wonderful day!
This is a bit confusing because in Windows 8.x, "Windows Runtime" was actually used to refer to a few different things:
A new pattern (and supporting code/OS components) for defining and consuming Windows APIs, meant to largely supersede "Win32" (i.e., flat C-style) and classic COM for new APIs in most scenarios. This was/is really about language interop: allowing the Windows team (and potentially others) to create components in C++ that expose APIs that don't depend on GC or a runtime like the CLR, but still feel relatively natural to use from C# or JavaScript without needing manually written wrappers.
The set of Windows APIs that follow the above pattern.
A new platform/environment for building and running a new type of Windows app, which are meant to have some of the characteristics of mobile and web apps in terms of causing fewer potential problems with system security, reliability, performance, battery life, etc. This is what evolved into UWP with Windows 10.
In the Windows 8 days, these apps were called "Metro style apps" during most of 8.0's public preview period, and officially dubbed "Windows Store apps" just before RTM. The platform/environment for these apps ... officially didn't really have a name (other than "platform for Metro style apps"). Unofficially, people (including at Microsoft) sometimes referred to it as "Metro" (a whole can of worms in itself) or ... "WinRT".
So what's the relationship between WinRT "proper" (definitions 1 and 2), and unofficial WinRT definition (3) aka UWP aka the formerly-nameless "platform for Metro style apps"? Well, since WinRT and the new app platform were both introduced in Windows 8, most of the WinRT APIs at that time were specific to the new platform. The app platform (and Store policy) at the time was also much more restrictive about which legacy Win32 APIs were allowed for use in apps - for the most part this was less about any technical limitation and more about the team hoping to use the new apps as an excuse to clean up the bloated Win32 API surface. But technically, WinRT is meant to be the common pattern for new Windows APIs in general, whether used in UWAs or not, and "UWA vs. classic app" and "WinRT vs. Win32" are mostly independent; over time, they've gradually enabled more WinRT APIs for use outside UWAs and also relaxed their policies on using a lot of legacy Win32 APIs in apps (and also continued to introduce new flat C-style APIs for certain use cases).
So to summarize, it's not technically accurate to say that "UWP replaced WinRT", though understandable since this stuff is pretty confusing. UWP replaced the nameless app platform (3); essentially it's just an updated version that's been ported to other device types and integrated with the classic desktop UI. WinRT, in its proper definition (1), continues to be the basis for new Windows APIs for use in UWAs and even outside them.
Windows Universal Platform is the development platform going forward for devices running Windows. Previously, development was separate for Desktops and Tablets vs Phones. With UWP you are now able to target any device running Windows 10, could be phone, desktop, tablet, xbox. The beauty is that you can now use one Binary for all of these platforms and has brought us much closer to a truly to a universal Windows app.
So, to answer your question, yes, UWP is the platform going forward for any device which runs Windows 10
As far as I understand, Microsoft wants to allow "having both desktop and modern ui GUIs" only available for web browsers (am I mistaken here ?).
Does that mean common apps will be developped twice ? With e.g Skype being available both as pure desktop app and pure modern ui app ? And if a user installs both, these both instances will share no data ?
I can't imagine them doing a shift towards gesture friendly uis/hybrid ui, and leaving full blown desktop apps (not toy/phone-like/game apps, that can live in one space only) with no integration/entry points inside modern ui. Or maybe they want to participate in that "kill full-blown desktop apps" movement ?
So is there a model for a desktop app developped in whatever GUI toolkit, that wants to have some minimal integration with a small HTML/CSS/JS frontend in modern ui, like for e.g providing a dashboard of favorite or recently accessed files, contacts, etc ?
Your first statement of "only in a browser" is not correct. Desktop applications don't change their current design paradigms. You can have browser-based apps on the desktop, of course. But full clients are still supported and still viable as a real solution to problems.
Your takeaway from that comment should be that desktop applications are not deprecated as people assert. The reality is, desktop applications are still the only solutions to many problems.
Your second question of shared data is not correct. Skype shares lots of data with its app companion. Not because of shared local storage, however; it is because of the services that it shares. My account and contacts are on the server. So, they share a lot.
Your takeaway from that comment should be that Windows 8 apps should not highly leverage local storage but should be built as service-oriented clients. To that end, your desktop applications should have already started to leverage this architecture, too.
Your third question (which is very cryptic) seems to be asking if a desktop application and a companion Windows 8 app can share or integrate with each other. The answer is yes. Not only can they share the same service, but file associates, custom protocols, and some of the non-Store manifest capabilities allow for this explicitly. Line of business applications should have a companion app, if you ask me. The integration points are many - though not every. But there is no other way to leverage the new capabilities of Windows 8 without introducing a companion app - even if that app does very little.
Your takeaway from that comment should be that Windows desktop applications and companion Windows apps are the preferred and anticipated development approach.
Best of luck, thanks for the question.
at first i thought with Titanium, i can develop for Mobile and Desktop over AIR on Desktop only, but a quick look at the AIR Site, i guess i am wrong.
Benefit from a consistent, flexible,
and visual development environment for
applications on multiple platforms and
devices such as smartphones,
smartbooks, tablets, netbooks, and
PCs.
so my question is are there any major differences of titanium over air that i shld be aware of?
if no, i guess now air maybe better documented and has the backing of a more recognized company? after working with titanium desktop for a while i felt abit helpless and the docs are not really helping much
There are a lot of subtle differences, of course, and there are advantages and disadvantages to working in either, but the largest difference is that Titanium can produce apps for the iPhone/iPad, and AIR can't (well, at least not conveniently).
AIR can produce iPhone apps that you can deploy using the ad-hoc provisioning, but you can't distribute via the app store.
I've got desktop apps on both and am making a mobile app right now. Titanium desktop will cut your dev time to 1/3 of the time you'll take jumping through AIRs various sandboxes and security measures. Best yet, the code I wrote for my Ti desktop app is all javascript with about 3 Ti API calls and can be taken anywhere. The AIR app is all mangled by the wild structure you have to use with AIR apps and 1 million api calls.
The downside to Ti desktop is the API isn't as fully featured, and the Ti team pushes 4 times as many updates for the mobile API as the desktop API. Also, you won't be able to port your app from desktop to mobile easily as they are two different structures and APIs.
That said, developing for iPhone and Android on Ti is the same exact process and that won't happen on AIR.
Lots to weigh, but for my money it's Ti over AIR.
Hope this helps.
Recently I was asked by someone if there is such a magic framework that will allow one let's say to design and build once a single library of controls and then use them separately to build web and desktop applications.
Does Google, Microsoft or other company have such a RAD framework and tools?
Thx
Depends on how you define a Web App. If you consider RIAs to be Web Apps, then yes...
Microsoft has Silverlight and Adobe has Flex/AIR.
Well, you can always go and look for adobe flex, adobe flash or even microsoft silverlight, which in the next version will support desktop applications as well.
Other types of frameworks currently do not build so well under desktop/web environments.. Take .NET for example, which can be used in so many set of environments, but there are limitations if you want to use it for mobile, web, desktop or XNA, everyone has his own set of tools.
That is mostly resumed in the capability of the desired environment, since you can browse a web page in an iphone, which does not have the same capabilities of a desktop or even laptop PC.
Seva is telling you how this is normally dealt with. MVC is a good start.
The Eclipse foundation offers Rich Client Platform vs Rich Ajax Platform - one allows you to build desktop apps, the other web-based apps, all using SWT concepts. I wouldn't describe it as magical though - the reality is it is much more difficult and I would not recommend RAP.
Adobe has AIR, and Google wants everybody write HTML5+JavaScript. both Chrome and FireFox can run those as standalone apps.
Were such thing to exist, it would produce lousy desktop apps and lousy Web apps. The underlying platforms and ideologies are too different. You'll do better by isolating as much of business logic away as possible, then building two separate clients.
EDIT: assuming that by a "Web app" you mean an HTML-based app, as opposed to something that happens to execute within a browser. For the latter option, you can have Flash, Silverlight, Java Applets, ActiveX controls... And for the vice versa, you can have a desktop app that opens a Web browser control and runs a Web app in it. :)
Microsoft has a Smart Client Factory that has a lot of built-in guidance packages that make development fairly quick and standardized.
http://msdn.microsoft.com/en-us/library/aa480482.aspx
It is entirely possible that I misunderstand this question, but if all you need, is the ability to seperate models an business logic into some kind of reusable library, just about any programming platform/language will do.
Java: keep models and business logic in seperate project, compiled to jar
.NET: keep models and business logic in seperate project, compiled to DLL
Python, Ruby, Perl: keep models and business logic in separate directory, and include as module
What are the requirements for the desktop application? On which platforms should it run? If Windows only, .NET seems like an obvious choice, otherwise Python and Qt or Java if you like to Swing.
I also would go for a Webservice and implement as much Business-Logic as possible in the Service. You can then build a very small Clinet in Html/JS, Java, .Net or Whatever.
You should choose that Framework you feel most familiar with.
If you are a .Net-Developer you can develop a WCF-Service (is also great with WP7).
For Java, i would choose Google-App-Engine or the Play-Framework.
And of course you can make a PHP-Webservice, for examble with the Flow-Framework
Check CrossUI RAD tool. It enables developers to rapidly develop and package the exactly same code and UI into Web Apps, Native Desktop Apps(Windows, OS X, Linux and UNIX) as well as Mobile Apps.
I'm curious what "features" are in Adobe AIR that makes it unique from browsers. I've heard that it has SQLlite on board, but what else makes it any different from Chrome's application mode (get the same functionality using Firefox's Prism plugin)
Is it fair to call it a browser?
AIR is technically a runtime much like Prism, and Silverlight (dunno about Chrome) for RIAs. They try to bridge the gap between the desktop applications and the browser. Browsers typically do not have disk access.
I'd suggest you go through this link.
Adobe Air is sort of like having a web application run on your desktop as if it was a windows/mac application. It is the answer from Adobe to Microsoft Silverlight out of browser experience. There are some technical differences; for one you need to install a seperate piece of software before you can use it while the Silverlight one comes with the Silverlight runtime. Another difference is applications running on Adobe Air have much higher permissions on your system than Silverlight ones.