Do you think delphi for android will support new api or need to wait until delphi get updated? i mean, can we just make translation to the api header and make use of them?
Do you think delphi for android will support new api or need to wait until delphi get updated? i mean, can we just make translation to the api header and make use of them?
Originally shared by Android Developers
Android 4.3, updated developer tools, and backwards compatible Action Bar Available Now
Android 4.3, a sweeter version of Jelly Bean, includes performance enhancements to keep your apps fast, smooth, and efficient; together with new APIs and capabilities including:
* OpenGL ES 3.0 Take advantage of OpenGL ES 3.0 and EGL extensions as standard features of Android, with access from either framework or native APIs.
* Bluetooth Smart Communicate with low-power Bluetooth Smart devices and sensors to provide new features for fitness, medical, location, proximity, and more.
* Restricted profiles Tablet owners can create restricted profiles to limit access to apps, for family, friends, kiosks, and more. Your app can offer various types of restrictions to let tablet owners control its capabilities in each profile.
* New media capabilities A modular DRM framework enables you to more easily integrate DRM into your streaming protocols, and apps can also access a built-in VP8 encoder from framework or native APIs for high-quality video capture.
* Notification access: Access and interact with the stream of status bar notifications as they are posted — including routing them to nearby Bluetooth devices!
* Improved profiling tools New tags in Systrace, and on-screen GPU profiling, give you new ways to optimize performance.
We’re also releasing a new version of the Android NDK (r9), which provides native access to the OpenGL ES 3.0 APIs and other stable APIs in Android 4.3.
The Support Package has also been updated with the long awaited Action Bar API that lets you include this Android design pattern in your app with compatibility back to Android 2.1.
You can download the Android 4.3 Platform (API level 18), as well as the SDK Tools, Platform Tools, and Support Package from the Android SDK Manager.
Android 4.3 powers the new Nexus 7 tablet and is rolling out now as an update to Nexus 4, Nexus 7, Nexus 10, and Galaxy Nexus HSPA+ devices.
Android 4.3 API Overview
http://developer.android.com/about/versions/android-4.3.html
Blog Post
http://android-developers.blogspot.com/2013/07/android-43-and-updated-developer-tools.html
#AndroidDev
http://developer.android.com/about/versions/android-4.3.html
Originally shared by Android Developers
Android 4.3, updated developer tools, and backwards compatible Action Bar Available Now
Android 4.3, a sweeter version of Jelly Bean, includes performance enhancements to keep your apps fast, smooth, and efficient; together with new APIs and capabilities including:
* OpenGL ES 3.0 Take advantage of OpenGL ES 3.0 and EGL extensions as standard features of Android, with access from either framework or native APIs.
* Bluetooth Smart Communicate with low-power Bluetooth Smart devices and sensors to provide new features for fitness, medical, location, proximity, and more.
* Restricted profiles Tablet owners can create restricted profiles to limit access to apps, for family, friends, kiosks, and more. Your app can offer various types of restrictions to let tablet owners control its capabilities in each profile.
* New media capabilities A modular DRM framework enables you to more easily integrate DRM into your streaming protocols, and apps can also access a built-in VP8 encoder from framework or native APIs for high-quality video capture.
* Notification access: Access and interact with the stream of status bar notifications as they are posted — including routing them to nearby Bluetooth devices!
* Improved profiling tools New tags in Systrace, and on-screen GPU profiling, give you new ways to optimize performance.
We’re also releasing a new version of the Android NDK (r9), which provides native access to the OpenGL ES 3.0 APIs and other stable APIs in Android 4.3.
The Support Package has also been updated with the long awaited Action Bar API that lets you include this Android design pattern in your app with compatibility back to Android 2.1.
You can download the Android 4.3 Platform (API level 18), as well as the SDK Tools, Platform Tools, and Support Package from the Android SDK Manager.
Android 4.3 powers the new Nexus 7 tablet and is rolling out now as an update to Nexus 4, Nexus 7, Nexus 10, and Galaxy Nexus HSPA+ devices.
Android 4.3 API Overview
http://developer.android.com/about/versions/android-4.3.html
Blog Post
http://android-developers.blogspot.com/2013/07/android-43-and-updated-developer-tools.html
#AndroidDev
http://developer.android.com/about/versions/android-4.3.html
Well, considering its not out all, it's hard to say how API updates are going to be surfaced. And anyone who might know right now is almost certainly under NDA.
ReplyDeletewell how about ios, will delphi for ios support ios 7 new apis as well when it comes out?it's the same i think
ReplyDeleteAssuming that Embarcadero can even make their approach work on Android, they have bet their farm (and yours) on FireMonkey.
ReplyDeleteAndroid API updates will be transparent to your code since your code will have to be written to the SmokingChimp API's, not the Android ones.
So when a new Android API comes out, you don't get to choose if and when to access them, you will have to wait for Embarcadero to make them available to you (if at all) through the FireMonkey framework.
In exactly the same way that the current "support" for iOS has no way to take advantage of the new iOS 7 unless and til Embarcadero update FireMonkey (oh, and charge you for the privilege).
Hope emb change that policy, if they failed to make delphi for mobile can adapt new api as soon as it get's out without waiting them to give the support, then it will the same like other mobile solution and it's not appealing
ReplyDeleteWhich part do you regard as policy that can be changed ?
ReplyDeleteCharging for upgrades is policy. But they won't change that. If anything, they'll use it as an opportunity to charge you more and more.
The dependency on the framework is baked in to their approach, not a policy that can be changed. At least not without throwing out the entire approach and delivering a true native solution.
I don't know what "other" mobile solutions you are thinking of, but it you are developing iOS applications using XCode and/or Android apps using Android Studio (or NetBeans or Eclipse) and the Android SDK, or even RemObjects Oxygene, then you are developing true mobile platform applications directly against those platform API's. As soon as the API's are released, you can start developing apps with those API's.
It's the Delphi approach that is already unappealing.
I meant for the policy to charge upgrade on new api support
ReplyDeleteOther mobile solution i mean here is the cross platform support with one code base, it is like the phonegap or xamarin or other multi platform capable mobile development tools
What is the delphi approach that is already unappealing to you?
ReplyDeleteI don't find zero ui library framework code reuse all that appealing. Jolyon us oversimplifying things considerably. Nothing prevents you from directly accessing any cocoa api you like via the objective C bridge. Have you built a production ios app and is it in the app store Jolyon? Because i have, using xcode and objective C and cocoa. I know enough to know that the oxygene approach is no picnic. Nor xamarin. Nor is firemonkey truly ready to substitute for plain native xcode on ios. But its close. Whereas the alternatives are offering you zero RAD ui capability. Zero.
ReplyDeleteWarren Postma the "UI" part in that complaint about reuse is important. Since Android and iOS (and other devices) have different UI's and different UX, it only makes sense to have different UI's on each platform.
ReplyDeleteForcing everything to be the same and then using crude styling to make it look superficially right is only one approach, and the least important in terms of actual application function.
But Embacadero chose that route and if you are invested in it then of course it makes sense to defend it.
But over-emphasising the ZERO part rather than the mort important UI part is just cheap.
What percentage of an app is in the UI ? If properly architected, there should be very little.
But in the meantime, if you are happy to have your look-a-like iOS app be stuck with an old iOS look-and-feel until such time as Embarcadero feel inclined to release you an update - free or charged for - or someone put's together a style kit to get the iOS 7 look that a true native app gets intrinsically, then that is your choice.
Speculation on how easy or otherwise it might be when it comes to Delphi for Android... well, that is still yet to be determined since they haven't delivered anything in that arena yet.
And no, I don't have an app in the store yet. So what ?
I didn't actually say zero UI code reuse. ... Although that's true, they don't provide any code reuse. I said ZERO UI RAD (Rapid Application Development). That means, there are NO form building tools included with their solution. It's like it's 1993 again, we're back to using those Windows Dialog Box Editors and then trying to connect dialog boxes to our code. Lame.
ReplyDeleteOh ?
ReplyDelete"zero ui library framework code reuse"
You'll have to forgive me for being confused if you didn't say that. ;)
As for ZERO UI RAD, it's a big step from "no GUI form designer" to "ZERO RAD".
Given the form factor of mobile devices, UI design doesn't benefit from GUI layout tools as much as desktop apps used to. The types of apps that a form designer would be useful with can be just as rapidly built in code using layout management containers.
RAD is after all about the "R" (to differentiate it from just plain "application development"). There is no "G" in RAD. :)
And the other very common type of app - games - typically aren't well suited to forms design anyway (at least not the sort that a tool chain would have baked in - games designers may have their own GUI design tools - level editors etc - for their own specific engines of course).
For what i see right now, Delphi for mobile offer RAD tools on mobile device, and it might be the first to do it.
ReplyDeleteIt might seem to be that not all mobile developer need form designer nor same ui and ux on all mobile platform. But with Delphi capable of creating mobile application whether it would be the same on all mobile platform or not, it really give a great boost at enterprise system level, where enterprise user might prefer the same ui and ux on all mobile platform, and it give RAD to the developer to extend the platform support for the enterprise system
About using new api from Apple (iOS7) you can write your translation iOS API and use it in you application. And you don't need to wait a new realease of IDE for it. Because IDE use only a part of iOS api.
ReplyDeleteI said i don't find zero code reuse appealing but that zero Rad Tooling is even Worse. How is manual anything Rapid? It isn't. I have tried oxygene and Xamarin and both are useless to me. When they even have at least a little bit of a platform abstraction library i will loom again. I don't think even Firemonkey will ever provide a just recompile and you are done level and I don't expect it. What i do expect is a common MessageBox/alert/notification and basic screen layout assistance. Nib files are the crappiest part of xcode and i dont want to use Interface Builder and then wire it all by hand, because if i have to do that, then forget it i will rewrite or stick to just Ios. The level of effort to hit both android and ios is too much for a single person.
ReplyDeleteBTW i wonder how do they think to support x86 and MIPS processors in Android. Also, I remember running TripleTown on my Sony Live Walkman phone. It was a VERY heavy and unfriendly application, dut to being "native" thus playing against all the Dalvik optimizatin strategy. Don't think NDK-based FMX apps have any reason to be more friendly.
ReplyDeleteThe challenge is formidable. I suspect in the end that Xamarin and RemObjects offerings will mature quickly. I want firemonkey to mature and win but if it doesn't, i will just write iOs apps in Xcode and ignore android.
ReplyDeleteI'm just curious Warren Postma , what is it about using Interface Builder with RemObjects Oxygene for Cocoa that represents "zero RAD UI capability" ?
ReplyDeleteSince Oxygene for Cocoa plugs directly into the TRUE true native facilities of the target platform, you build your UI using the true native UI building tools. For Cocoa (iOS) that means you can design both individual "forms" (views) in separate XIB files, or complete "storyboards", with zero-code navigation flows built in, all using Interface Builder.
I didn't mention this before because although I bought Oxygene some months ago, I haven't had chance to even spin up the Cocoa support yet, until this evening. This also means that I haven't as yet spent any quality time with these tools.
All I can say at this stage is that getting an Oxygene / iOS dev environment up and running on my Mac (with a Windows VM, obviously) was virtually friction free. Yes there were some tools to put in place, but these all worked straight "out of the box", in stark contrast to my experience with getting even this far with Delphi and iOS, for example.
I guess what I want, that Firemonkey has today, that Oxygene doesn't have is the ability to work in ONE IDE on ONE OS and build my UI and compile it. In Oxygene, you're in Visual Studio, in a VM on Windows, then you switch out of there, into your mac's native side, and fire up XCode, and then how do you access interface builder exactly? Tell me after you've tried to figure it out. My guess is you need to create a dummy XCode project, then add a nib to it, then modify that nib, then copy that nib file, copy WHERE exactly (hmm, another manual step). Now try to build, try to run. Oh it didn't find the thing in the nib. What was the object named in the nib? oh right objects in nibs don't have names. Do you see what I mean by Not Very RAD?
ReplyDeleteUm, you still need a Mac with FireMonkey if you want to get your iOS-a-like code running on an actual iOS device, so you don't have "one OS to rule them all" even with FireMonkey.
ReplyDeleteYou can't even get Xcode out of the equation entirely.
As for the situation with Android... you simply don't know what you will have with FireMonkey in that case.
Whether I am using Delphi (I still do) or Oxygene, I am running Windows in a VM since my primary machine is now a Mac (and now that I have discovered the benefits, still would be even if I never did another line of Mac coding ever again), so that's a null argument. Not just for me but for anyone doing Mac development unless you want not just two IDE's but two entirely separate machines - one purely Windows and one for the Mac Host + Windows VM that you need to at least deploy to iOS (not to mention testing ... or does FireMonkey have an iPad/iPhone simulator/emulator now that I am not aware of ?).
As for your speculation as to how Xcode and Visual Studio interoperate, why don't you check out some of the RemObjects videos on the matter ? Or you can wait as I shall start blogging about it myself soon. :)
Either way, you will see that the integration is all but seamless. And CrossBox - the equivalent to the "PA Server" component - is fo far ahead of PAS in terms of ease of use (and reliability) that if I were an Embarcaderodrone I would be embarrassed.
The only bit that requires a specific interruption in workflow is a "Sync Storyboard" operation (and I presume "Sync XIB" if you are using XIB files instead of storyboards), which is required after you add any code which Interface Builder needs to be aware of (e.g. a new ViewController derived class to be associated in the RAD UI builder with a particular View).
This presumes I suppose that you have your project source in a location that is transparently accessible from both the VM and the Host OS. But who wouldn't have such a set up ? I certainly do.
No need to copy anything from VM to Host or vice versa unless you want to deliberately make life difficult for yourself.
The integration between a Parallels Windows VM and OS X, and the performance of Parallels, means that the fact that Interface Builder is across the VM boundary in a separate app is largely insignificant these days. Apart from the above mentioned periodic "Sync"step, having Interface Builder running in the host OS is practically no different from the days when the VCL Form Designer was a separate, undocked window. In fact, if you are running Parallels VM in Coherence Mode, this is exactly how it would feel.
It seems to me that you don't really know what it is that you don't like about the alternatives (and by extension, what it is you do really like about FireMonkey).
First it was the lack of a UI framework - which you then said wasn't what you meant and that you really meant the lack of RAD UI building tools. And when those are shown to exist after all the problem becomes an artificial and one about end-to-end development within one IDE on one OS (something that isn't even possible using FireMonkey to target iOS).
You seem to be assembling a strawman army. :)
Incidentally, on the question of "How do you access Interface Builder"...
ReplyDeleteTwo ways:
First:
i) Locate the storyboard file in your project source folder
ii) Double-click it.
Or alternatively:
i) Start Xcode
ii) Select "Open other..." from the launch gallery
iii) Locate and select the storyboard file
There is possibly a third, even more direct way:
Parallels VM supports file associations across the VM boundary, so you might even be able to just double-click the storyboard file within your Visual Studio solution explorer and be taken directly to Xcode on the Mac. I am not at my Mac right now so can't try this out to make sure.
But in any event, it's not exactly difficult.