My first Delphi Android app

One of the test programs I just built is an EditBox, ListBox, Button app (the same app that was the first used to launch Delphi version 1.0 and shown at the Software Development Conference in 1995 running on 16-bit Windows). Using three components and one line of code, I have the same app running on my Samsung Galaxy S4 phone.

To develop a FireMonkey Mobile App, you can start with a mobile application project template.  I chose the "Blank Application" template for my first app.



Next, I placed the 3 components on my main form.



I double clicked on the button to bring up the code editor and added the one line of code inside the Button’s onClick event handler to take the contents of the editbox and add the text as a new item to the listbox.




Finally, I selected Android as the target platform in the project manager and made sure the IDE was connected to my Samsung Galaxy S4 phone ("SCH-I545").


I hit the run button to build the application using our true native code Delphi ARM compiler for Android to create the APK file and deploy it to my Samsung Galaxy S4 phone. I added "Hello" and "world" text in the application and pressed the power and home buttons to grab the screen (I could have also used the Palm Swipe method to capture the screen).



What’s even cooler, the same code can be used with our Delphi true native code compilers for Intel and ARM to compile and run the same project on Windows, OSX and iOS.  All you have to do is set the target platform and use the same form and code.  With my PAServer running on my MacBook Pro, I configured my iOS Device target.

I hit the run button again to build the same application using our true native code Delphi ARM compiler for iOS and deploy it to my iPhone.



Going back to the Project Manager window, I activated the Win32 target and compiled the same app and ran it on my Windows virtual machine.

.

. .

Posted by David Intersimone on Tuesday, August 20, 2013, at 1:13 pm

Sneak Peek: Android SDK, NDK and Device Support in Delphi

A juicy sneak peek of the Android support in the SDK Manager and Project manager being developed in the beta. This video shows the updates to the SDK Manager to support the Android SDK & NDK. These can be installed and configured automatically, or you can install them on your own and configure them here. Then it shows how easy it is to add Android as a target. The project manager will automatically detect any Android Emulators or devices with USB debugging enabled and provide them as an option.

Why Some Mobile Apps are So Slow

If you haven’t read the lengthy article on Why Mobile Web Apps are So Slow I recommend you check it out. It appears well researched, citing lots of tests, sources, benchmarks and authorities. In summary JavaScript is garbage collected, and garbage collection introduces overhead making it up to 5x slower than native code. This isn’t such a big deal on x86 desktops, but with the slower architecture of ARM it is killing the performance of mobile apps.

Take a look at it, even if you just skim it you will no doubt learn something about this heated debate. Oh, and everywhere it talks about LLVM and ARC remember that is the same architecture that Delphi uses ^[PDF]  for iOS development (and Android soon too).

Also keep in mind that JavaScript isn’t the only garbage collected language on mobile devices. Languages that run on the Java Virtual Machine and .NET Framework are also garbage collected, as are most all scripting languages. This includes the Dalvik Virtual Machine that non-NDK Android apps run on. Granted Dalvik is optimized differently than that Java Virtual Machine, but it is still garbage collected, so it will still pause program execution at some point.

Quote from the article by Herb Sutter:

Managed languages made deliberate design tradeoffs to optimize for programmer productivity even when that was fundamentally in tension with, and at the expense of, performance efficiency…

Which was endorsed by Miguel de Icaza of Mono & Xamarin:

This is a pretty accurate statement on the difference of the mainstream VMs for managed languages (.NET, Java and Javascript). Designers of managed languages have chosen the path of safety over performance for their designs.

Points to remember:

• Garbage collection is up to 5x slower than native code
• This is a much bigger deal on ARM architecture than x86
• Automatic Reference Counting (ARC) is not Garbage collection
• Delphi uses LLVM architecture and supports ARC like Objective-C

Clarification: A big part of the slowdown is that JavaScript is also a dynamic language, so all garbage collected languages are not 5x slower than native code. There are pros and cons to GC and ARC. There is a comment on the article that points out the 5x comparison was between GC and manual memory management, not ARC. There is overhead with ARC, but it doesn’t pause your apps execution.

Read the article and draw your own conclusions, but I’d love to hear what you think.

From : http://delphi.org/2013/07/why-mobile-apps-web-are-so-slow/