Category: Firemonkey

Modernize your codebase: Inspiration to Ditch your Ancient Delphi Version

I still see a lot of people running old versions of Delphi, the most common one people freeze at is Delphi 2007, because of the Unicode changes to String types, but I have also seen the odd one stick at Delphi 7, or even Delphi 6. Here are some suggestions on getting out of those Don't-Upgrade-Ever Tar-Pits.1.  You may lack motivation. You may not realize how much you need a modern Unicode String type.  You start by believing you can upgrade your AnsiString-forever, or shortstring-forever codebase. Yes, yes you can.  The internet is Unicode, and every computer is connected to the Internet 24/7.  WideString is not enough.  The modern String (UnicodeString) in Delphi is fast, flexible, and internet ready.   I've spoken to people who aren't upgrading because they assume the new String is slower. On some benchmark code (Sieve of Eratosthenes and some string crunching code), the latest Delphi XE5 is actually faster at UnicodeString (String) operations than Delphi 7 was at AnsiString (String) operations, and basic IntToStr and StrToInt functions.2. Upgrade for Productivity boosts. The IDE INSIGHT feature is fantastic.  Once you get used to it, I find it hard to use a version of Delphi that lacks it.  It's google for your IDE.       I like to supplement it with the GExperts file open dialog, but the combination of the two is magic.3.  You've been down the Ancient Delphi Codebase road, and you know what a pain things like Z-Order bugs are.  If it helps you decide to move up,  remind yourself that the VCL in 2007 and later supports proper Z-Order parenting, so if you're on Delphi 6, or 7, it's time to say goodbye to silly Z-Order bugs. (Window A behind Window B).  If your code is not Unicode ready yet, you can get XE5, and it will entitle you to a Delphi 2007 license (previous versions access), get your Z-Order bugs fixed, then continue to work towards proper modern Unicode readiness in your codebase.4. Maybe you don't really need 64 bit Delphi, but having the possibility open sure is good, right?  Or maybe you would like to build something 64 bit? Running Windows 64 bit? Want to access lots of memory? Want to write a shell extension?  32 bit may be great for lots of things, but having 64 bit in your bag of tricks is worthwhile.  64 bit Windows will be so mainstream eventually that (like Unicode) the whole Delphi world will eventually move to it, and Win32 will eventually fade away. Yes. Yes, it will.  Do you still want to be building Win32 apps when Win32 goes the way of Win16? Remember NTVDM? WOW is the new NTVDM. It isn't where you want your apps to live, is it? Inside the backwards-compatibility box?  So be ready.5.  Mac OS X support. You can write apps for OS X with Firemonkey.  Maybe this isn't a "need" thing, but it's nice to have in your tool-belt.    Being on a modern Delphi version means having this around when you want it.6.  iOS support.  You can write native iPhone apps with either RAD Studio XE 5 or Delphi XE5 + the mobile add-on.   Your kids will think you're cool, if you make them a little App for Christmas. Right? Of course right. 7. Android support.  You can write Android apps using the Delphi compiler for native ARM and Android NDK.   8.  If you're stuck on a version prior to 2010 you don't have proper platform support for Windows 7, and Windows 8.  Things like the file-open dialogs, etc, changed at the Vista level, and that support was never in Delphi 6,7 or 2007.  I think it's kind of funny that Delphi grew proper Glass (DWM) support, and then Microsoft suddenly yanked Glass out of windows 8.  But maybe it will come back in Windows 8.2.  You think?  Anyways, the core VCL on modern versions like Delphi XE5 is a lot less painful to support Windows 7, 8, and 8.1 on, than the creaky old version you're using, if your version is older than, say Delphi XE.9. VCL styles.  This is an amazing way to add a "face lift" to your VCL application without rewriting it.  There is a bit of work involved, but a lot less than you'd think.   The amazing third-party add ons like RRUZ's awesome helper library make it easy to make your VCL app look great.  If you haven't got at least Delphi XE2, you don't have this great feature.  To go with that pretty Style support, add some VCL gesture support.  Support touch gestures on a  touch-screen laptop or Windows Surface Pro tablet, using VCL gestures. Swipe, pinch, or make your own custom touch gestures.  Combine this with the VCL styles and you can modernize your look, and functionality from "90s" to "up to date" pretty quickly for your core Win32 desktop apps.10.  Delphi Language Evolution. If you're still on Delphi 6 or  7, and you don't have Generics, or modern RTTI, or the new module grouped-naming system (Unit Scopes), you might be surprised how much nicer and more readable these things make your code. For example, I love my Uses clauses to be grouped with all the System units first, then VCL units, then my third-party library units. The ones that have no dots in the namespace are either primitive third party libraries, or my own units. It's amazing how convenient and nice and "expressive" these longer names are. I love them.I hope this list gives someone the motivation they need to kick themselves in their own butts and get their codebases out of Delphi versions that should be retired, and moved onto a modern Delphi version.  You'll thank me.Oh. And how do you actually DO it when you get the nerve?  I'll write more about that later.   But for starters, I suggest you try to write some Unit Tests.  Remember that while you are in progress of modernizing your codebase, you can do it without ever breaking your application or introducing unknown behaviour.  I'll write more about that approach, in an upcoming post.Update:  If someone is sceptical about the value of updating, I ask them, what does it hurt to download the trial and try it?   You can do almost anything you want to try with the demo version, get your code mostly ported, try to port your components up,  get stuck, and post questions on StackOverflow. If you really love Delphi 7, great. It was a great version.  Enjoy it until the heat death of the universe, or at least, until the sun goes super-nova. No problem.  But most of us moved on long ago, and I just wanted to let you know why we did.
Read More

Update 2 for RAD Studio XE5, Delphi XE5 and C++Builder XE5

If you have not noticed yet, Embarcadero published the second update for their latest tools: Delphi XE5 as well as RAD Studio XE5 and C++ Builder XE5. More than one hundred bugs have been fixed. Thanks for the users having taken the time to write a bug report to Quality Central, the web tool used to keep track of bugs and feature requests. Most fixed bugs are related to the mobile platforms and
Read More

Smart Mobile Studio 2.0 beta 1

I know we promised it for November so here it is – Smart Mobile Studio 2.0 beta 1, released on November 39th ;) I know some were waiting anxiously for this release so joke aside – we are sorry that we couldn’t release it in November but you know how it goes – there is always one more showstopper problem :( We know that this beta is not yet perfect (and we’ll release another one before the product is finalized) but as we do want your feedback we have exposed it for the public consumption. A list of changes since the last released version is available here. In case you were not actively following Smart since the last release, I would like to recommend few interesting articles on our site: New ways to run a project Micro-controller programming New build system How to use Cordova And remember – Smart targets everything from microcontrollers (Espruino) to mobile devices (in-browser, PhoneGap, Cordova), desktop (in-browser) to servers (NodeJS). --- Published under the Creative Commons Attribution 3.0 license
Read More

EurekaLog RoadMap

This is updated roadmap for EurekaLog's development in the near future. What it is A technology roadmap is a plan that matches short-term and long-term goals with specific technology solutions to help meet those goals. Disclaimer: This information describes EurekaLog's general direction at this time, and should not be relied on in making a licensing decision. The future development, release, pricing and timing of features and functionality remains at our sole discretion and may be changed at any time without notice. What is current EurekaLog status EurekaLog 7 is our current product, which is under active developing and support. EurekaLog 7 was released about 1 year ago as a replacement for the previous version (EurekaLog 6). While EurekaLog 6 was a great product, but its internal structure prevented major changes - such as bringing new major features and going cross-platform. Therefore, our primary goal for EurekaLog 7 was refactoring old code into more flexible and modular system, which should allow us to add new features and support for new platforms more easily. Thus, EurekaLog 7 introduced support for native Unicode and Win64 platform, as well as large amount of your suggestions and improvements. There were problems, of course. First, while we tried to keep backward compatibility as much as we could, but this was not always possible. There are limits for retaining backward compatibility. Existing EurekaLog users try to port/upgrade their applications from EurekaLog 6 to EurekaLog 7. And they encounter problems due to these limitations. Project options, source code, behaviour changes - some of these may need adapdation for older projects. Still some projects may be upgraded very easily, while some other require more changes. Second, EurekaLog 7 has to change some "play rules" because of the Unicode/Win64 support1 (see notes for more info). Existing customers of EurekaLog 6 may see a behaviour of EurekaLog 7 that is different from behaviour of EurekaLog 6, and they consider this as a bug - not realizing that this may be a limitation of technology/platform support. Code or options adaptation may be required to mitigate this issues. We greatly expanded our documentation to cover many new topics. For example, there were sections added: configurations, DLLs, external tools (protectors, etc.), multi-threading, etc. Third, there always be problems for such major changes in code base. While we use automatic testing and do beta-testing2 (see notes for more info) - there still are not-yet-found bugs in stable releases. So, our next concern was improving stability and reliability of EurekaLog. EurekaLog 7.0.07 is our latest stable release. It fixes a lot of found problems. And we feel that most critical issues were fixed. Check out our change log to see all fixes! Immediate plans We will continue to improve and bug-fixing EurekaLog. Currently, we think that most problamatic part is C++ Builder support, which should be addressed soon. We want EurekaLog 7 to be rock-stable, thus we do as much as we can to keep it bug free. New features may be added as well, EurekaLog 7 is expected to be more changeable than EurekaLog 6. For example, there already were many little and big features added since initial (7.0.00) release. Personally, when talking about major new features since initial release - I would note support for JIRA, non-Embarcadero compilers (and other external tools), 64-bit disassembler, and "Deferred call stacks" option. Of course, there were many less significant features added. See our change log for a complete set of new features! Our forums were recently changed. Now "Suggestions" forum is sorted by top views, so now we all can easily track most-wanted features. Both "Suggestions" and "Bugs" forums now have "Closed" sub-forums. We will move completed issues to "closed" sections. If you had posted a suggestion - check if it is still open. Most likely it was already completed - which means your topic was moved to "closed" and we had given the explanation where to look/how to perform for the desired behaviour. We may close some features as "won't do" verdict - due to technical limitations or other reasons. If you are not satisfied with our resolution on your suggestion - please feel free to re-port it again, appending explanation about how you think your suggestion was not resolved. The same holds true for bug reports, of course. Suggestions and bug reports in normal forum are considered to be "active". This means we either are working on these or put it on hold (but not rejected/closed). Our web-site now have new section dedicated to you as EurekaLog user. There we will publish contributions from all of our customers. There you can find code samples, plugins, localizations (translations), tools, etc. So far there are not a huge amount of things to see, but this list will be expanded over time. For example, we hope to publish a detailed memory analyzer/dumper from Alexandr Bagel (Rouse_) (link points to Russian blog post). Feel free to report a bug, post a suggestion, or share your work as contribution! Plans for the near future Now we are getting close to the point of this roadmap :) We feel that it is about time to move EurekaLog a bit forward. We are evaluating possibilities for the next direction. Preliminary, we want to add support for: Delphi for Mac - MacOS is a closest alternative for Delphi/WIntel platform with a great amount of backward compatibility. EurekaLog is not specific to UI framework, so no VCL -> FMX migration is necessary. We only have to adapt OS-specific calls. Doing MacOS support will allow us to concentrate on removing/adapting Windows-specifics, keeping Delphi specifics at place. Generally, we expect this to be faster and most easy solution. Lazarus - while we are not sure about exact amount of interest in exception tracer for Lazarus, we are still consider it as a viable option. Doing Lazarus support will make EurekaLog much more platform-universally ready. Ideally, little changes would be required to port EurekaLog to new platform (once Lazarus support would be implemented). However, doing this initial conversion would come at high cost: not only we have to make cross-platform changes, but we would also have to make Delphi -> Lazarus adaptation. While we know that Lazarus is somewhat Delphi-compatible, but we lack real expertise with it and have some concerns (such as strings support). Luckily, we have to keep our code Delphi 4-compatible, so no complex structures support (like generics) is required. As it was already mentioned, we are currently evaluating these possibilities. What do you think about it? Do you have any ideas/feedback? Or want to share your expertise? We would love to hear your feedback. Aside from primary road, we also have a secondary way of development. EurekaLog Viewer was significantly improved in EurekaLog 7, but still lacks important database qualities: the current build is still based on old file-based approach (even when used with FireBird database). We see a large area for improvements here. Viewer should be upgraded in database support aspect. It also could support "databases" like bug tracker integration. However, since EurekaLog Viewer is auxilary tool and it performs its primary function (view reports) quite well - we consider updating Viewer as lower priority than updating EurekaLog itself. Again, share your thoughts on this! Distant future For a very distant future we think about porting EurekaLog to non-Pascal IDEs (such as Visual Studio) by providing a DLL with exposed public interface to control EurekaLog. A mobile world (iOS/Android, perhaps a WinPhone) is also a possibility. We understand groving interest in mobile technologies, but currently lacking "a vision" for mobile error reporting solution. Notes: 1 For example, Delphi 3 support was dropped because Delphi 3 did not have 64-bit integer type (Int64) at all, while Delphi 4+ supports Int64 and (for even later versions) UInt64. While it may looks like you do not need 64-bit integer in 32-bit code, but there are certain places in our code base which have to share the same routines' prototype. (Thanks god, there was support for Unicode since Delphi 3.) Another example: EurekaLog 6 has the ability to delay building call stack for the exception until this exception is handled (by EurekaLog) - normally, exception tracer should build call stack right away (when exception is raised). This feature was possible due to specifics of x86-32 platform. This feature greatly speed up execution of code which raises exceptions and handles them (like try/except block in OnDrawItem handler). However, EurekaLog 7 could not use the same technicue - because it has to support other platforms (Win64), where such feature does not exist. Thus, initial release of EurekaLog 7 (7.0.00) did not have any replacement for this old behaviour. Of course, there were many complains about execution speed of EurekaLog 7 in 32-bit mode. That is why we made improvements in EurekaLog 7 - we introduced "deferred call stacks" option (this option will copy call stack and parse it later) and "speed optimization" option (this option will cache calls to kernel's code). 2 EurekaLog has many unit-tests, as well as integration and system tests. All of these tests are run automaticlly when EurekaLog's installer is build from sources. Installer can not be build if any test fails. However, EurekaLog was not created via TDD approach (Test-Driven Development), and it does not have full code coverage. In particular, we do not have automatic tests for external software (e.g. IDE, SMTP servers, etc.). We also do beta-testing in the form of RC releases. Changes in source code are first made into a current RC version, which is published regulary on our web-site (in customer's control panel). Any customer have ability to download and try this build. Once we get a decent amount of fixes or improvements, and if there was no negative feedback for some time - then we re-release last RC build as new stable version of EurekaLog. Despite all of these measures, there still may be bugs in stable releases. For example, since EurekaLog 7 supports Unicode and Win64, we had to walk through old EurekaLog 6 code looking for places where Char is mixed with Byte and Pointer is mixed with Integer. While there are some compiler-assisted warnings, but there were little assistance for the most part in our code base (especially for Win64 support). Therefore, we mostly rely on Range Checks, Overflow Checks (both were disabled in EurekaLog 6), and memory profiling. But these checks happen at run-time, not at design-time. And the buggy code may run OK - depending on the actual data. Thus, some bugs may be discovered later. There are other examples when bugs slips through automatic and manual tests. Still, as noted above, we think that latest EurekaLog stable release is quite reliable.
Read More

SapMM

This is a guest post, written by Anton Alisov, software PM and developer from Ivanovo city, Russia. I’m posting it here because I want to increase visibility of this new memory manager which featured quite well on my recent test (guest posted at Eric’s blog). I’m perfectly aware that my test was superficial and I intend to do a better test with more memory managers in the following weeks. Arnaud Buchez already posted a overview of the memory manager on his blog. And now I’ll give word to my colleague Anton. We were waiting for the robust and scalable memory manager for Delphi for the long time. Our best choice - FastMM - did not scale well under multithreaded use in memory intensive applications. Memory manager with a new design was required. We have tested many scalable managers such as TopMM, ScaleMM and other. Some of them are quite robust, but not supported currently by its developers (TopMM), some are not yet ready for production. So, we decided to develop our own memory manager to have more control over it. We believe, one doesn't have to be big to be efficient. Meet a new player - SapMM - Simple As Possible Memory Manager. SapMM is robust, production quality memory manager, developed by software guru Alexei Nedoria from Ivanovo city, Russia. SapMM was designed for use in memory intensive multithreaded applications with the scalability in the first place. In single threaded use SapMM is only a bit (up to 40% on certain scenarios) slower than FastMM (on some scenarios SapMM is faster than FastMM even in single threaded use), but the real power of SapMM shows in multihreaded applications. SapMM scales very well and in a vast majority of scenarios is much faster than FastMM in multithreaded use. SapMM is used in production 24/7 system since June 2013. Currently SapMM was well tested only with Delphi XE and XE3, small code changes may be required in order to use it with other versions of Delphi. Currently SapMM supports only 32-bit mode and cannot be used in 64-bit applications. You can grab SapMM sources and do some tests yourself: https://code.google.com/p/sapmm/ --- Published under the Creative Commons Attribution 3.0 license
Read More

Delphi (Mobile world): One Code for multiple Platforms

  Wow we finished with Delphi XE5 a great final. One Code to multiple Platforms. Our Product HarleyMobile is a Application for Harley Bikers (like me) to stay in contact between Dealers and Customer. With Delphi we have written everything. 1. Webbased Administration Portal for the Dealer to insert/update the new Offers, Events, News, Employee …
Read More

Read More

Read More

Embarcadero Special Offer XE5

For Developer working with a previous version of Delphi/RadStudio XE5, Embarcadero have a great offer ! Only a limited time you can update any earlier Delphi/RadStudio Product to XE5 !!!!!!!! More details see here: http://www.embarcadero.com/radoffer   Upgrade to XE5 from any earlier version (Upgrade price from any previous version) Bonus pack with up to $1,150 in …
Read More

Read More

Read More

Delphi XE5 – First Impressions

Well, it’s been quiet on this blog for a while now. Delphi XE3 and XE4 have seen the daylight and not even a single post has appeared here about those. With the launch of Delphi XE5 and it’s promise of developing cross-platform applications for Android made me quite curious. I wanted to check it out as soon as possible, but we were in the middle of a big project for a client (a Warehouse Management Project written in Delhi), and the last thing we wanted to do was change our development environment from XE2 to the new shiny XE5. The last thing we wanted was Murphy sneaking in so close to the actual delivery of the WMS System. … Read More

Read More

Delphi XE5 Android Send Mails with Attachments over Android Mail Client

Customer asked me how to send with a Delphi XE5 Android Application a Mail from the Delphi App with attachment. Why not to share? Here is the code: unit u_frmMain; interface uses  System.SysUtils, System.Types, System.UITypes, System.Classes,  System.Variants,  FMX.Types, FMX.Controls, FMX.Forms, FMX.Graphics, FMX.Dialogs, FMX.StdCtrls; type  TForm1 = class(TForm)    Button1: TButton;    procedure Button1Click(Sender: TObject);  private    procedure CreateEmail(const Recipient, Subject, Content,      Attachment: string);    { Private declarations }  public    { Public declarations }  end; var  Form1: TForm1; implementation uses  Androidapi.JNI.GraphicsContentViewText,  Androidapi.JNIBridge,  Androidapi.JNI.JavaTypes,  FMX.Helpers.Android,  Androidapi.JNI.Net,  Androidapi.JNI.Os,  Androidapi.IOUtils; {$R *.fmx} procedure TForm1.CreateEmail(const Recipient, Subject, Content,  Attachment: string);var  Intent: JIntent;  Uri: Jnet_Uri;  AttachmentFile: JFile;begin  Intent := TJIntent.Create;  Intent.setAction(TJIntent.JavaClass.ACTION_Send);  Intent.setFlags(TJIntent.JavaClass.FLAG_ACTIVITY_NEW_TASK);  Intent.putExtra(TJIntent.JavaClass.EXTRA_EMAIL, StringToJString(Recipient));  Intent.putExtra(TJIntent.JavaClass.EXTRA_SUBJECT, StringToJString(Subject));  Intent.putExtra(TJIntent.JavaClass.EXTRA_TEXT, StringToJString(Content));  AttachmentFile := SharedActivity.getExternalFilesDir    (StringToJString(Attachment));   Uri := TJnet_Uri.JavaClass.fromFile(AttachmentFile);   Intent.putExtra(TJIntent.JavaClass.EXTRA_STREAM,    TJParcelable.Wrap((Uri as ILocalObject).GetObjectID));   Intent.setType(StringToJString('vnd.android.cursor.dir/email'));   SharedActivity.startActivity(Intent);end; procedure TForm1.Button1Click(Sender: TObject);var  sl: TStringList;  sFileName: string;begin  sFileName := Androidapi.IOUtils.getExternalFilesDir + PathDelim + 'Test.txt';  sl := TStringList.Create;  try    sl.Add('TestContent');    sl.SaveToFile(sFileName);  finally    FreeAndNil(sl); // Arc eigentlich unnötig  end;  CreateEmail('aaaaa@bbbbb.com', 'TestFromDelphi', 'Dödeldiedeidiedödeldiemöp','Test.txt');end; end.
Read More

Delphi and Android services (part 2)

It’s been a while now since I posted up the link to my Delphi service example on Google Play. I mentioned at the time that it was not a trivial exercise and was somewhat imperfect in implementation (although I’d done my best to disguise this fact). Indeed you only really see an issue if you are looking at the logcat output from the app (either using the command-line adb logcat command, or using the deprecated DDMS tool or the replacement Monitor tool). Alas the app dies while endeavouring to tidy up for exit… I also mentioned at the time that I was hoping to work out some scheme to remedy the situation before releasing the example source, something to do with pride or perfectionism or some such… Anyway, with the day job, the evening job, the prep work for last week’s Be-Delphi 3.0 event in Belgium my plans haven’t been accomplished and I have still to work out if it’s feasible to clean up the shutdown part of the sample. All my current efforts have come to little in resolving it. So, given that there have been a number of requests for the source I have now made it available at this download link. This is the same as the sample online other than it has no splash screen. This example is free of a splash screen to simplify the example and leave it clearer. There are a couple of examples that incorporate a splash screen and have similar custom build steps available in my CodeRage 8 session files. Please note that the archive has a Readme file in it, and you should take the time to read through this file carefully as it explains the non-standard build steps required to get the sample successfully built for deployment. If you don’t follow the Readme file, then you’re unlikely to get any joy with the sample at all. For your convenience I include the text of the ReadMe file below. As you will see, since Delphi has no catering for building Delphi services or broadcast receivers, I’ve had to go “round the houses” to do it, using Java stubs, and pertinent thread-switching between the Java and Delphi threads. As you will also perhaps appreciate, I don’t recommend this as a productive way of building an Android service. However if you need to add a service to a Delphi Android application, then this approach allows you to do so. But… as of the time of posting there is a still the small matter of a (slightly brushed under the carpet) death-by-tombstoning bug on shutdown. If any keen reader can work out a clean way of closing I’d be most obliged to hear of it! [Update] When the small Java source files get compiled, the Android dx tool expects them to be compiled by the JDK 1.6.x compiler as opposed to the JDK 1.7.x compiler. If you have JDK 1.7.x installed, you hit a problem with dx reporting: bad class file magic (cafebabe) or version (0033.0000) However, to avoid forcing a reinstall of JDK 1.6 you might like to modify my build.bat batch files and add in extra command line switches to the javac.exe command-lines. You need to insert this after the javac.exe command to force Java 1.6 byte code output, which is digestible by the Android dx command: -source 1.6 -target 1.6 [Update 2 – Feb ‘15] There has been a longstanding issue with my service sample, which I originally wrote for Delphi XE5. The issue was that when updated and tested in Delphi XE7, it hung on startup with a black screen. This was rather disappointing. Unfortunately I’ve been very much tied up with stuff and haven’t managed to get to looking into the problem up until now. Anyway, Aleksey N’s comment (below) put me onto the way of getting it to work. The OnCreate handler now triggers a timer to start the service, after the initialisation process. The download sample project now incudes both a Delphi XE5 and a Delphi XE7 project. Enjoy! Service example===============This project implements an Android service along with a coupleof broadcast receivers to catch and respond to intent messagesflung around the system. The service and receiver classes areimplemented as extremely shallow Java classes, which need to becompiled and converted to an appropriate executable format(dex), and then merged into the other dex code deployed with anAndroid app.The Java code calls into native Delphi code to implementthe "business end" of the service and receivers.Build the Java support files:----------------------------In the project's java directory are some source files: - java\src\com\blong\test\ActivityReceiver.java - java\src\com\blong\test\SampleService.java - java\src\com\blong\test\ServiceReceiver.javaThese need to be compiled to .class files, archived into a .jarfile, converted from Java byte code to DEX (Dalvik Executable)format and merged into the normally used (by Delphi's Androiddeployment process) classes.dex.To set this up, follow these steps: - Ensure the useful subdirectory of Android SDK's build-toolsdirectory is on the system PATH (e.g. C:\Android\android-sdk-windows\build-tools\18.0.1 or C:\Users\Public\Documents\RADStudio\12.0\PlatformSDKs\adt-bundle-windows-x86-20130522\sdk\android-4.2.2) - Ensure the Java Development Kit's bin directory is on thesystem PATH (e.g. C:\Program Files (x86)\Java\jdk1.6.0_23\bin) - Run a command prompt in the project's java subdirectory andensure you can successfully launch each of these: - javac - jar - dx - Review the build.bat file and ensure the environmentvariables are set correctly: - ANDROID needs to point to your Android SDK basedirectory, e.g. C:\Users\Public\Documents\RAD Studio\12.0\PlatformSDKs\adt-bundle-windows-x86-20130522\sdk orC:\Android\android-sdk-windows - ANDROID_PLATFORM needs to point at an installed SDKplatform installation, e.g. %ANDROID%\platforms\android-15 or %ANDROID%\platforms\android-17. Check for one that is installed. - DX_LIB needs to point to the lib subdirectory under theAndroid SDK build-tools directory, e.g. %ANDROID%\build-tools\18.0.1\lib or %ANDROID%\build-tools\android-4.2.2\lib - EMBO_DEX needs to point to the Delphi-supplied Androidclasses.dex file, wrapped in quotes to take care of any spacesin the path, e.g. "C:\Program Files (x86)\Embarcadero\RADStudio\12.0\lib\android\debug\classes.dex" - Run build.bat - You should now have a new file in the project directory treecalled java\output\dex\classes.dexThis file replaces the supplied classes.dex and has the Javaservice and broadcast receiver compiled classes included in it.Set the new classes.dex for deployment:--------------------------------------Open the project in the IDEChoose Project | DeploymentNote that the classes.dex file from the project'sjava\output\dex directory is set to be deployed.You must ensure that the default classes.dex file is de-selected. As you switch configurations, this de-selection willbe lost (the file will be re-set to be deployed) and will needto again be de-selected. This is an IDE bug with Delphi XE5 RTMand XE5 UP1 and is logged in Quality Central as bug 118472.Register the service:--------------------This has already been done for this demo. It involves thefollowing: - Open the Android manifest template,AndroidManifest.template.xml, which is generated on firstcompile, from the project directory - Add in a description of the service in the applicationelement: <service android:name="com.blong.test.SampleService" />Build the Delphi Android application library:--------------------------------------------In the IDE choose Project | Compile ServiceApp (or pressCtrl+F9)Deploy the library to an Android application package (.apk):-----------------------------------------------------------In the IDE choose Project | Deploy libServiceApp.soInstall the app on the device:-----------------------------In the IDE choose Run | Run Without Debugging (or pressCtrl+Shift+F9).This will implicitly do the compile and deploy steps above, sothey are actually optional.This step will uninstall the app if already installed and theninstall the newly built version.
Read More

ITDevCon 2013 Slides, Code and Photos

ITDevCon 2013 has finished and as always it was a beautiful (but wearying) experience. I’m still trying to pull myself together.

My session slides and code are now available on this blog – just click on the Presentations link on the right.

Some snapshots from the conference (take with the crappy camera on the Sony Xperia P phone):


Opening session


Last preparations …


Smart Mobile Studio everywhere


Three fifths of the Smart Mobile Studio team


Christian during the “LLVM” presentation


Stefan Glienke talking about Spring4D


The Spring4D session was packed


Christian preparing for the “Microcontrollers and Pascal” session

— Published under the Creative Commons Attribution 3.0 license

Read More

Read More

We’ll be at the Embarcadero Event at Argentina


This November 14 we'll be present on the Embarcadero Event at Buenos Aires, Argentina.

The event is focused in mobile development with the new Embarcadero Rad Studio XE5. Along with many other interesting speeches, I will be giving a session about dealing with files in iOS and Android, and how to use TMS FlexCel to generate xls, xlsx, pdf or html files in a mobile device. If you are near Buenos Aires on this date, make sure come and say hello.

Read More

Using a unit for both standard windows application and firemonkey mobile application [closed]

I am using Delphi Xe5 for both windows and Firemonkey mobile applications. I have a unit I share among two different projects in my projects group. (Windows Application and a Firemonkey Mobile Application) 1.) How do I determine the version of Delphi Xe5 ? Or, what is the version? 2.) Is there a way to determine between a Win 32 application,. Win 64 Application, and Firemonkey mobile Application 3.) In code, how do I tell the compiler which version of Dialogs to use based on the type of my app. That is VCL.Dialogs (Windows App) versus FMX.Dialogs (Firemonkey Mobile App) Thanks you
Read More