marcocantu.blog

Using Open SLL in Delphi iOS

2013-05-24T13:51:07.204Z

Delphi uses OpenSSL for Indy's HTTP support, but also for Amazon and Azure cloud services. it is also used for DataSnap clients when encryption filters are enabled. Here are some tips on how to get this library up and running.

To enable Indy's OpenSSL support in your Delphi code, all you need to do is add the unit IdSSLOpenSSLHeaders_Static in one of the uses statements of your project. In fact, as you probably know, on iOS you cannot use dynamic libraries but have to link external compiled libraries (.a files) to your executable. The unit above has the code needed to bring in the proper library files, libcrypto.a and libssl.a.

Now the problem becomes, where do you find it? We would have been more than happy to ship a version of the library with Delphi but given it is a general purpose encryption library there are restrictions to ship it due to US export laws. One option is to build these libraries from the sources. You can find OpenSSL for iOS at http://github.com/st3fan/ios-openssl . You can compile the libraries following the detailed steps and using the compilation script at http://x2on.de/2010/12/16/tutorial-script-for-building-openssl-for-ios-iphoneipad/ . Once you have done that, you need to copy the two .a files indicated above in a folder visible by the project (the main project source folder could certainly be an option).

This covers the device, but not the simulator, which can use dynamic libraries. For the simulator you can use IdOpenSSLSetLibPath and set the path to a location on the Mac where the .dylib files are located. Notice that if you let the Mac just find the OpenSLL libraries, this generally works for an OS X application, but might not run for one running in the simulator. In fact, you might have a different / wrong version of the dylibs in the library folders the simulator uses. You can also grab the right dylib files, copy from the Mac to your project source folders, and deploy them to the simulator along with the application, using Delphi's deployment support. Remember, though, that you cannot add these dylibs to the device deployment.

Thanks to three Steve/Stephen of Embarcadero (Blas, Ball, Axtell) for the information in this post.

Keynote at DDD Frankfurt and Amsterdam

2013-05-22T21:02:18.080Z

Over the next two weeks I'll visit and given a keynote at the two European stops of the Delphi Developer Days tour, with Cary Jensen and Bob Swart. As you might remember, I used to co-organize and speak at these events with Cary, but given my new job at Embarcadero I couldn't do that any more. However, I was asked to attend and give the Embarcadero keynote... and stick around for Q&A sessions and in general to discuss the status and future of Delphi with attendees.

I'll be next Thursday and Friday (30th and 31st) in Frankfurt, and the first few days of June (3rd and 4th) in Amsterdam. I'm sure I'll also learn a lot from the sessions Cary and Bob are doing, and it will be a pleasure to spend time with them and Loy. I think their Amsterdam event is fully booked, while there is still room for the German one (language is English anyway). For all information and details you can refer to their web site, www.delphideveloperdays.com.

If you are in those cities during those dates but cannot attend the seminars, I might still have time for an extra meeting, so feel free to reach me over email. By the way, good to see these events fully booked once more, seems a good sign for Delphi (and a prove Cary and myself did a good job in the past).

Of Strings, Immutability, COW, and AnsiStrings

2013-05-17T10:21:11.290Z

Not unexpectedly, there is debate in the Delphi community around strings in the NextGen compiler, touching on string immutability, copy-on-write, the loss of the AnsiString type in Delphi's new iOS compiler, and the like. Some sources are:

Before I start, let me clarify that this blog post is not the result of any internal debate or discussion, so it is not an official company position. It does reflect my understanding of the current scenario and it is a direct reaction, after reading some of the posts above (which do contain a lot of insight and good ideas).

Let me start with what I posted as a comment to the first blog entry above:

Very nice roundup about the features and advantages of strings in Delphi compared to other platforms. I agree on some speed loss compared to FastCode, but mostly because we moved away from assembly (given platform portability is very relevant for Delphi today). Also, TStringBuilder can be faster in the scenarios it beats the native memory manager in terms of pre-allocations, something FastMM4 does pretty well on Windows, the native iOS allocator doesn’t seem so smart doing.

Stay assured, there is no plan to change anything going forward unless there is a proven advantage. This is particularly true for immutable strings. They could provide some advantage (for example in heavy multi-threading, when managing string fragments, and in other scenarios)… but will also have disadvantages. At this point there is no definitive decisions on this. Strings in the current Delphi iOS compiler are NOT IMMUTABLE, there is only a warning indicating where things might change in the future. Native might change, not will certainly change.

The last part is key to the debate. The current implementation of strings is still centered around the COW (Copy-On-Write) mechanism, with some really minor differences. And you can change a string in each of the following ways in Delphi for iOS (aka, our NextGen compiler):

Delete(S, 1, 2); // not allowed

Insert(S, 1, 'He'); // not allowed

S[7] := 'T'; // not allowed

I grabbed these three lines from the forum thread. The first and the latter (and their TStringHelper equivalents) are still and will be allowed in the future. The only question is if their performance will stay the same or decrease, which will make sense if most other string operations will become faster. As for the last statement, this triggers a warning in Delphi for iOS (a warning you can disable), indicating a potential future compatibility. This means there is an internal evaluation of truly immutable strings, no decision taken.

We more than welcome input, but better if based on some substance. Immutable strings are used in some languages to help the garbage collector, and that's something we don't need (given we don't have and don't plan adding a GC in Delphi). But they are used in other language that break away from the concept of linear strings (string s= array of characters) and use a concept of string fragments (string = tree of immutable string fragments, potentially shared by different strings). Again, this is just a research area, and there is nothing decided. Unless we prove significant advantages, we won't deviate from the current model.

So getting back to the thread, at one point someone suggested a petition around 4 requests:

- the loss of AnsiString (and single byte Chars)

- that strings may become immutable

- that strings are either 1-based or 0-based

- the re-implementation of RTL functions with rather suboptimal code

Let me comment in the reverse order:

Improving RTL functions is always a goal. honestly, with fewer RTL functions (and fewer string types) it becomes easier to focus on those.
For now, 1-based or 0-based is just a local compiler option, not sure if the request is to keep it this way...
Immutability, as described above, is a potential future, which would be implemented only if there is a proven advantage
The loss of AnsiString is the most controversial issue. The problem is that it is also the loss of UTF8String. And of AnsiChar. And of using pointers to directly manage character buffers. Which is not really lost, because this is what we are doing internally and suggesting externally. I do understand the request, but it seems to have different implications for different people (and string formats). Optimizing for English language is not a primary goal, as Delphi is used a lot around the world. Improving the management of raw dynamic arrays of bytes storing characters is certainly on the table.

Two more (short) comments related with other complains.

The first is around the fact we are supposedly "dumbing down" the language or making it "Java-like". I really disagree this is the case. Adding features shared by many modern languages doesn't imply dumbing down, but might have the effect of making the language easier to learn and use. Letting the power users go ahead with all the tricks they know of. Cleaning up the large collection of string types goes in this direction. The fact a type is not native implies that an operation requires a function call rather than an internal (magic) function call, but I don't see a huge difference in using a record with methods versus a native type, for any complex operation.

The second is the idea that we should help maintaining the code on very old versions of Delphi. This is quite debatable. We are adding language features across compilers (Delphi ships with 5 compilers today) for platform cross-platform compatibility. Worrying about how to write Delphi code that shines today and still works on Delphi 6 (a twelve years old development tool) would be like asking Microsoft to add WinRT support in Visual Basic 6.

Now having said this we are open to feedback, particularly constructive feedback and suggestions. And would someone want to start an open source project to implement a few cross-platform Delphi string types (AnsiString, UTF8String), I'll be willing to contribute.

Italian Delphi Day 2013

2013-05-17T08:18:43.025Z

On June 6th there will be the 12th edition of the Italian Delphi Day, featuring local and international speakers, including myself as Delphi PM and Bruno Fierens of TMS. Beside conference style presentations, the day will see roundtable discussions, showcases, and lots of Q&A sessions, covering all Delphi things, form iOS to databases, from web development to 3D user interfaces. The day before the event has some pre-conference tutorials, 4 seminars in 2 parallel tracks, in which Andrea Magni and Paolo Rossi will cover some of the most recent features of Delphi (FireDAC, iOS, Language changes, Live Bindings).

All Italian developers are invited to the largest annual gathering of Delphi developers, a full day devoted to the product produced as an independent event by Wintech Italia, with the help of a few sponsors. After organizing the event for many years, I'm now a guest speaker, and will cover the present and future of Delphi. Detailed information and sign up at:

www.delphiday.it

XE4 Articles, Comments, Intelli-J, and More

2013-05-16T13:52:11.390Z

I saw a very interesting article on ZDNet about a real case of an Australian company in the medical field. You can read the article, with extensive #34es from Malcolm Groves, at www.zdnet.com/pascal-still-an-advantage-for-some-ios-android-developers-7000014743/. I also witnessed a few companies trying to switch away from Delphi and realizing this is much more difficult than they had anticipated, because despite great marketing, most other development tools have their own shortcomings. Now, while migrating to Unicode or mobile requires you to have a second look to your code, a lot of it moves over quite seamlessly, including database access, and more.

Speaking of other tools, I think Eclipse received a significant blow yesterday by the announcement of Google transitioning their "primary" Android IDE from it to Intelli-J. This is a very nice Java tool, with a free community edition and a paid version including high-end features. I guess that when some of our users claim all IDEs should be free these days, we have a counterpoint (honestly they do have lower prices, but they are selling "only" an IDE, while we have compilers and libraries on top of it).

In terms of comments, we found a very nice one from Wilfred Olouch on this David I blog post on iOS support in Delphi XE4 vs. XE2 (which is also worth reading), answering to why a developers should pay for an IDE to build iOS apps, when xCode is free from Apple:

I can think of three reasons that apply to me and might to you as well:

(1) I already know the Delphi language and prefer it to Objective C

(2) The drop component / double-click / code behind model is easier than the X-Code inlet/outlet, etc model

(3) when FireMonkey for Android ships, there will be no X-code for Android; your app in Delphi will cross-compile.

Three points I fully agree with, thanks for the coincise summary, Wilfred.

Delphi XE4 IDE videos by José León

2013-05-14T20:39:47.974Z

José León has been posting some in depth videos about the changes in the Delphi IDE to support iOS development (and not only that) in XE4.

The complete series is on his blog at joseleon.es. Specifically the first three videos were published in April, while there have been 6 more already in May.

This is the first one, as an example (and a very nice one):

Stay tuned to José blog for more about the RAD Studio IDE.

IBLite, Free InterBase for iOS

2013-05-09T09:14:11.212Z

Embarcadero has formally announced IBLite, the free version of IB ToGo for iOS, already shipping in RAD Studio XE4. You can read the announcement at edn.embarcadero.com/article/43128.

As you might know, IBToGo is a DLL-based or in-process version of InterBase, requiring no deployment and giving developers access to the same InterBase GDB files and almost all of the same features of the server version of the RDBMS. Being in-process only an application at a time can use the specific database file, but beside that features are complete and include full transactions support and concurrent access by multiple threads of the same application. Another notable feature IBToGo shares with the full database is strong encryption support. Now this database engine has been available also on iOS: in this case you bind the library to your app executable, given dynamic libraries cannot be used on iOS. Delphi XE4 has full support for this, right in the box. The same library, anyway can also be used to connect to a full InterBase server.

The second part of the announcement, even more relevant, is that there is a new version of this in-process engine called IBLite and currently available only for iOS. This is completely free and can be used in free and commercial apps, with some limitations on database size and the lack on encryption support. Again, this is fully supported in Delphi XE4 for iOS, in the same way of IB ToGo. In fact, there is only one library and you get one behavior or the other depending on the license file you deploy along with the application. Notice, you have to log on Embarcadero web site to ask for that licence file: instructions are in the email with the Delphi or RAD Studio license.

Finally, why do you want to do this, adding extra files to your deployment rather than using the built-in SQLite engine? Beside the fact this is totally up to you, given Delphi for iOS has also full integrated support for SQLite, the advantages are in the file compatibility with InterBase, the extensive feature set, the quality of the SQL engine, and its speed... and the ability to switch to an encrypted database (you don't want to have plain sensitive data on a portable device, do you?) with a license change and no modification in your app code.

Delphi for iOS supports IBToGo and IBLite via dbExpress, FireDAC, and IBX. And you get a free developer license of the InterBase server, now part of the RAD Studio installation.

XE4 DataBase Components Updates and the Reviewers Guide

2013-05-03T20:17:41.426Z

There are two hot fixes available for the database side of XE4:

IBX (Interbase Express) is now available for registered users at cc.embarcadero.com/item/29408
The FireDAC Enterprise download for XE4 (if you are entitled to it) is at cc.embarcadero.com/item/29368. It has been updated from the original version, so you might want to download it again.
The FireDAC Professional for Mobile, similarly, is at cc.embarcadero.com/item/29410 for registered users and has been updated since the original version.

This is the link to the reviewers guide, a non-technical introduction to Delphi for iOS: edn.embarcadero.com/article/43099.

Assorted Delphi XE4 Links

2013-04-24T17:06:04.439Z

I've been busy with launch webinar and other activities, but I've also spent some time online. Here is a collection of links related with Delphi XE4:

JT on True Native at blogs.embarcadero.com/jtembarcadero/2013/04/18/true-native/
Long long post with many technical details by Brian Long at blog.blong.com/2013/04/delphi-for-ios-aka-delphi-xe4-aka-rad.html
I know someone at Embarcadero will be unhappy but there is a FishFact for iOS at https://www.youtube.com/watch?feature=player_embedded&v=6rDyD7k24Z0
Very nice tip about persistent setting in Delphi iOS by David Clegg at edn.embarcadero.com/article/43065
Jose Leon on what's new in the IDE at joseleon.es/
Jens Fudge on ARC and other language changes at delphi.exotech.dk/#post18
Long long list of QC fixes at edn.embarcadero.com/article/43068
Sarina blogged about segmented controls for iOS and custom icons and orientations
All download links are here, delphi-insider.blogspot.com/2013/04/download-links-for-delphi-xe4-cbuilder.html (very useful, Tim)

That's all for now, more will come as information and technical tips become available.

My Delphi Podcast Interview

2013-04-24T08:04:54.334Z

I was interviewed by Jim McKeeth for a new episode of the Delphi Podcast. The first good news here is that the podcast is coming back after quite some time, kudos to Jim for that. The second news is I was interviewed for it, and spent quite some time chatting about Delphi in general, Delphi for iOS in particular, future plans for the product, my own personal projects including books, and so on.

Listen to or download from at http://delphi.org/2013/04/52-delphi-xe4-for-ios/.

PS. There is still time to register for today's Delphi XE4 Launch Webinar at embt.co/RADXE4PAS. I'll be talking about language changes and database support. JT and Sarina will cover all other areas of the product. And I'll be online to answer questions at 3pm European time today (6 am pacific), 8 pm European time (11 am pacific).