My team is in the planning phase of a multiplatform mobile app. We're considering Adobe Air/Flex or Appcelerator Titanium instead of native development, but will eventually be needing to use an external API that is ported to iOS and Android. **(one that harnesses the device's camera)
The idea would be to use platform detection and overloaded classes to determine which platform version of the API to import. Is something like this possible in either Adobe or Appcelerator? If so, would the native Objective-C or Java need to somehow be wrapped in Actionscript (if Adobe) or JavaScript (if Titanium)?
Any advice would be fantastic.
A near-term (no dates yet) release of Mobile Air will include native extensions. The native code will be written in the platforms' native languages. ActionScript interfaces will exist to interact with these extensions, the specifications for which have not yet been released.
http://active.tutsplus.com/articles/news/industry-news-week-22-2011/
Titanium is 100% native code.
How Does Appcelerator Titanium Mobile Work?
Related
Is Xamarin.Forms considered a simple sum of Xamarin.Android and Xamarin.IoS with a shared code library wrapper? or is there more under the hood than meets the eye?
I am not talking about the shared code library because I realize it is specific to Xamarin.Forms but rather (for example) if I am to compare a Xamarin.Droid project to an android codebase of a Xamarin.Forms solution, will I find any considerable differences? Will I find any differences. Same goes for IoS & Windows...
Just to provide context; I am interested in utilizing some tools which were originally designed for Xamarin.android however my projects are Xamarin.forms solutions and it would be cool to know in advance if I am running into a rathole.
Thanks in advance you fine people.
Xamarin Forms, in the end, is a wrapper over the native API's so if you have something in Xamarin Forms you can of course port it to Xamarin Android, iOS or Windows.
Is Xamarin.Forms considered a simple sum of Xamarin.Android and Xamarin.IoS with a shared code library wrapper? or is there more under the hood than meets the eye?
At its simplest, Xamarin.Forms is a mobile application framework for building user interfaces. The definition from Xamarin's website is:
Xamarin.Forms is a cross-platform UI toolkit that allows developers to easily create native user interface layouts that can be shared across Android, iOS, and Windows Phone.
But don't simply focus on the term "UI" in that definition and think only on-screen controls. Instead, focus on the word "toolkit" as Xamarin. Forms offer so much more in addition to user interface controls that work across platforms.
Xamarin.Forms will emit a 100% native iOS, Android or UWP app – in fact the starting point of any Xamarin.Forms app is within one of those platform projects. However, that's as far as the platform-specific code needs to go. The rest of the code can all be written in one of the layers that are shared amongst all the applications.
if I am to compare a Xamarin.Droid project to an android codebase of a Xamarin.Forms solution, will I find any considerable differences? Will I find any differences. Same goes for IoS & Windows...
Just Basic API differences, which are different between forms and native
You shoud see Xamarin.Forms as the abstraction of the UI over the actual platform. Xamarin.Forms (XF) renders the UI in native platforms controls, but they are created using XF XAML.
Coding against XF is like coding for a different platform with a different set of tools, at the UI level!
You can, if needed go deep in platform specific details if needs be via interface implementation and injection.
I'm working on a React Native project that uses Realm for React Native.
It works without problems but now, I am faced with a problem of writing Android Service that would use the same Realm instance. Is it possible and how would I do that?
I think you can communicate from Java to React Native through Native Modules and do your Realm-related code in Javascript as you normally would.
Otherwise, Realm for Android's multi-process support for non-encrypted Realms will arrive in Realm-Java 2.0.0 (and that part is actually in with the snapshot), which will most definitely support this use-case; when the core version of Realm-React-Native (currently 1.5.0) and Realm-Java (previously 1.5.1, now 2.0.0-rc4) will be the same (2.0.0).
So not yet, but actually quite soon. I'd estimate a month or two at most from the time of writing.
EDIT: According to https://github.com/realm/realm-js/issues/984#issuecomment-297716769 the only way to get the same core and sync and object-store versions reliably for your app is if you build Realm-JS and Realm-Java from scratch and use them in your application like that.
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.
something strange happens when I switch between the adobe sdk (3.90.1210), and the apache sdk (which includes the same adobe sdk (3.90.1210)
one would think that there should be no differences when I make this switch, as my app is AS3 only, no flex references, and the underlying sdks are the same
the app builds and runs under both sdks, but about half of my images just dont show up when I run under the adobe sdk
so I dig down and I can see that the bitmap data objects that dont show up all have their HxW set to zero, the others have it set to proper HxW
the thing is, this has worked fine for a long time under the various adobe sdks, and something in the apache sdk fixes the problem, would like to understand it
meanwhile the wierdness in the images has something to do with having been flattened or not during production... images are all pngs, imported into flash and compiled to a swc, then merged into code
not a graphics guy, was hoping I wouldnt have to become one... have poked around and cant figure that side of it out...
suggestions?
one thought is to go back thru our hundreds of images and flatten (unflatten? whatever) them all with some photoshop batch process... this would not be fun
or I could stick w/ the apache sdk... which makes me a little nervous in that I have no idea what magic it's bringing
thoughts? anyone else seeing this?
thanks
To avoid stretching out the comments on the main question further, I'll throw this into an answer.
There are three official SDKs for Flash development. There are several others (like Starling) which have no affiliation with Adobe, so we won't count those.
Flash SDK - This is the basis for all things Flash and is developed solely by Adobe. Your core classes (DisplayObject, Object, Number, System, etc) are all found within this SDK. No matter what you are building for, every Flash application must include this SDK.
Flex SDK - Flex is a GUI framework originally developed by Adobe. After v4.6, roughly two years ago, Adobe donated the framework to Apache. Since that time, Apache has been developing the framework with fairly consistent development. We are currently at 4.11 with 4.12 due out in the coming months. This framework is also open-source, so it is partially community developed, partially Apache developed. There are two main different GUI frameworks in Flex: MX and Spark. MX is no longer in development, while Spark is. You should not mix components from the two.
AIR SDK - This is the Adobe Integrated Runtime. AIR allows you to run Flash apps as native apps on various platforms. The AIR SDK is the bridge between Flash and the native platform and nothing more. It is developed solely by Adobe and is closed-source. Apache has no part in this project, other than Adobe's promise to keep supporting Flex and MXML for the foreseeable future.
So with those things in mind, let's look at how they interact. As I said, the Flash SDK is included in all Flash apps. The AIR and Flex SDKs are built in ActionScript 3 (Flex is NOT built in MXML) using the classes found within the Flash SDK. The AIR SDK is used to build a native application, and that is the only time it should be used. The Flex SDK is a set of GUI components that make building interfaces easy and can be used in both web and AIR applications.
The Flex SDK can exist without the AIR SDK and the AIR SDK can exist without the Flex SDK. There is absolutely no reliance between the two. For the sake of unity, the Flex and AIR SDKs are generally combined into a single folder. This does not mean they are the same SDK or related in any way, just that this is how the SDKs are loaded. This was an ease-of-use decision by Adobe years ago when they still developed Flex.
So if your AS3 project is using the same AIR SDK version are your Flex app and you are getting compiler errors when you compile AS3, there must be something Flex in your project. Maybe a Formatter or the RPC classes used to make SOAP calls). You need to find that and get rid of that or import the correct SWC file from the Flex SDK, assuming it isn't a GUI component.
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.