REST is awesome. There I said it. And, like many of you, I’ve lived through several generations of remoting technologies over the years.
What I like most about REST is its simplicity and inherent flexibility AND the fact that everyone is exposing their services this way AND it’s relatively painless to integrate regardless of the language used. Basically, REST is everywhere and there countless services exposed that will add value to your apps.
In RAD Studio XE5, we’ve introduced components for VCL and FireMonkey to easily integrate REST services and although there have been a few other blogs about it, I wanted to share a simple example that illustrates how REST works really well. For this example, I will wire together a VCL app to gather surf forecast information.
REST is made up of a couple of key concepts: the server, the request, and the response. Additionally, it would nice if the data exchange format, called JSON (which is basically a tuple of strings) could be turned into an compatible dataset to integrate into our UI controls.
So, as I mentioned, the basic REST components are RESTClient, RESTRequest, RESTResponse, and RESTResponseDataSetAdapter. There are of course other components provided in the framework to deal with authentication, with OAuth, for example, but these are the basics.
First up is the API server. Most services will use a convention like api.domain.com. In this example, the service is provided by spitcast.com and they provide the API server api.spitcast.com. So the first thing I need is a TRESTClient component and to set its base URL.
Now, that we are pointing to the API server, let’s setup our first request. REST requests are formatted like an URL off of the BaseURL, using standard HTTP requests, like GET, PUT, DELETE, etc. So, since a big swell is coming in this weekend I would like to see what the top spots are using the resource /api/top/spots.
We are ready to get a response now. REST responses usually come back as a string based data packet called JSON. First, let’s take a look at the JSON through the web browser.
Great, now let’s add a Tesponse component to grab this JSON. And now, let’s execute the request within the IDE and populate the Resonse component.
The request is good.
Now, we should see that JSON packet in our component Content property.
Now, we could parse this simple format but there is a VCL/FM component that can turn this into a compatible dataset that we could easily integrate with LiveBindings. For that we will use a TRESTResponseDataSetAdapter.
After we make them both Active we can add fields and bind the data visually using the Live Bindings Designer to get them into a ListBox.
Ok, everything is setup now and I can see my results live in the designers. Like I said, Awesome!
Now, look at that 3 out 5 top spots are here in Santa Cruz. Choices, choices.
So, now that you have a flexible REST client components set for VCL and FM in XE5, go forth and integrate.
And don’t forget to take advantage of our current promotions before December 31st to get REST with RAD Studio XE5. Current offers include "Coding in Delphi" book by Nick Hodges and the InfoPower XE5 VCL Grid and Components in addition the the InfoPower for FireMonkey. And a 45% off upgrade offer for previous owners of any version of RAD Studio, Delphi, or C++Builder.
http://www.embarcadero.com/radofferPosted by J T on December 19th, 2013 under C++, C++11, C++Builder, Delphi | Comment now »
Embarcadero extends congratulations to Apple on shipping iOS 7 today. Now that we have the public shipping bits we are doing some final testing our iOS 7 Style (which should be available to registered XE5 developers shortly). To whet your appetite, here is a screenshot of the FM Controls samples app we built this early afternoon.
~/jtPosted by J T on September 18th, 2013 under Uncategorized | Comment now »
From Marco’s Blog: http://blog.marcocantu.com/blog/delphi_arc_android.html
Delphi mobile compilers use Automatic Reference Counting. While ARC is commonly used on iOS, Android developers generally rely on a Garbage Collector.Posted by J T on August 30th, 2013 under Uncategorized | Comment now »
Or all three?Uncategorized | 1 Comment »
Printing from an Android device requires a little bit more setup than in iOS where you simply connect to an AirPrint capable printer (like my Epson XP-400). However, Android printing appears to work with any Wifi printer (or PC connected printer), so its more flexible. Basically, it consists of three steps.
First, download and install Google CloudPrint onto your device.
Second, setup your Wifi or connected printer with CloudPrint support (simple firmware upgrade on the XP-400).
Lastly, register the printer (and device you wish to print from) with your Google account.
Now that that is setup. I built and deployed FirePhoto and added support for the share intent through a standard (and provided) MediaPlayer action in the ActionList component.
And Voila! Printing from Android using FireMonkey.
Don’t forget to check out the current RAD offers and apply for Android beta access today:
Sign up for Android news/info and apply to be a beta tester: http://embt.co/RADBetaA
Special Offers: http://embt.co/XE4RadOffer
- 6 months maintenance free with new user purchases
- 2009 users get the upgrade price when buying with 1 year maintenance
- bonus pack of extras free
~/jtPosted by J T on August 16th, 2013 under Uncategorized | 6 Comments »
~/jtPosted by J T on August 14th, 2013 under Uncategorized | Comment now »
We’ve been in beta for a while now with Delphi for Android and the progress has been awesome. In particular, I’ve been taking iOS apps written with Delphi/FM and simply retargeting them to Android. It’s really amazing. Since this Android support has been under wraps, I am very excited to share with you some first public peeks.
Here’s an example of one such application, FirePhoto. First built with Delphi for iOS and by retargeting it in the IDE, it’s now running on an iPhone 5 and on my S4 and my Nexus 7 tablet.
Here are few more pics for your enjoyment:
Installing the APK package (and informing the user of requested permissions):
FirePhoto on iOS taking a picture of FirePhoto on Android and vice-versa.
Two different mobile OSs, same app functionality with the exact same source code!
In case you weren’t aware, we have a special offer going right now: 6 Months Support & Maintenance free on select new user products! Not only will you get the next 6 months of updates and major upgrades free, but you’ll also get priority access into our Android beta program!Posted by J T on August 9th, 2013 under Uncategorized | 21 Comments »
I was reading, with great interest, an article on Wired today about LLVM. The author correctly points out that most of his readership will probably not have heard of this technology but he posits it is incredibly important in the world they do know, iOS and Android, and how it is the last bastion of technology that binds Apple and Google together. As such, it is quickly becoming the industry standard.
LLVM is a technology that Embarcadero has been investing in for many years as well. Our first toolchain with LLVM was our 64-bit C++ compiler for Windows back in November. That release, by the way, represents the first commercial LLVM based compiler for Windows. It took many years to get to that point and now the pieces are falling into place for rapid releases. In April, we delivered our first ARM toolchain for iOS with LLVM and later this year it will be available for Android, followed shortly by a C++ version for both platforms.
LLVM is more than just a compiler backend (code generator) these days. It has become the umbrella project for many other of the toolchains from other language front-ends, to linkers, and debuggers, and many other ancillary build tools. For instance, one of the other tools we’ve been investing is in LLDB, the debugger project. While LLDB has quite a bit of work still to make it production ready we’ve been actively brining it to Windows and enabling our debug info within it. You can check out our posted sources for more details.
In addition to international language standards, like ANSI/ISO C++, industry standards like LLVM have tremendous importance - as conveyed in the Wired article and we are very excited to participate in its emergence.Posted by J T on July 25th, 2013 under Uncategorized | 3 Comments »
The FireDAC library we’ve recently released for XE3 and XE4 contains some powerful encryption support that was originally part of AnyDAC. That code was donated to DA-Soft by StreamSec (http://www.streamsec.com/) - a Swedish company focused on developing the security library, StreamSec Tools for Delphi, and on providing consultancy services related to security development in Delphi.
In particular, the StreamSec encryption code is used in the SQLite database driver on the Windows platform. Notice that for export reasons this is the only unit in FireDAC we don’t ship in source code format, but only in the compiled (DCU) version.
So, thank you, specifically to Henrick Wibell Hellström of StreamSec for this contribution to, what is now, our principal database access library.
~/jtPosted by J T on July 3rd, 2013 under Uncategorized | Comment now »
C++ is a multiple platform language and always has been. It’s predecessor, C, can be found on virtually every single device ever created because C is the foundation of every operating system kernel and runtime library. As such, you will find a C/C++ compiler toolchain on every single device as well. So, why is it so challenging to have a single C/C++ source code base for your application across all platforms?
One of the bigger considerations is binary compatibility. By that, I mean the binary format created and used by the actual compiler, linker, and debugger. The short of it is, every single compiler and linker out there use a different binary format from one another. Therefore, it is difficult (and many times impossible) to share object files or libraries created from a different compiler. And just as difficult to have a common debugger although there is seems to be more industry standardization on debug formats these days. This isn’t an easy problem to solve.
But that’s OK if you have all the source code you need, right? Well, sort of. Just like binary formats there can be differences between all of the various compilers such as standards language compliance, library compliance, and finally language extensions. With the ratification of C++11, most compiler vendors, including Embarcadero, are shooting towards full compliance with this new language standard and library standard. This is a good thing and improves source compatibility, however not every compiler front end is at the same level of compliance with all of the same features. And the same is true of standard library support (the other half of the "language").
The majority of our standards compliance efforts will be geared around the recently release BCC64 architecture and this is the same toolchain we will be brining to mobile and eventually back to 32-bit Windows (and any other supported platform). In the meantime, to help you manage your source code across both platforms more effectively we have published the following language compliance table between the two.
We will be doing the same for library compliance and Boost over the coming months. Additionally, I will be discussing more Critical C++ Toolchain Considerations during a webinar this Wednesday, June 5th. Come join us!Posted by J T on June 3rd, 2013 under Uncategorized | 1 Comment »