Recent

Author Topic: Android NDK  (Read 22115 times)

siegfriedn

  • New Member
  • *
  • Posts: 22
Android NDK
« on: January 13, 2011, 03:18:18 pm »
Hi,

I know this has come up in another post but I want to highlight it again. Revision 5 was released in December 2010 amd may be of interest to building GUI apps on Android with Lazarus/FPC.

"It provides headers and libraries that allow you to build activities, handle user input, use hardware sensors, access application resources, and more, when programming in C or C++."

"This release of the NDK includes many new APIs, most of which are introduced to support the development of games and similar applications that make extensive use of native code. Using the APIs, developers have direct native access to events, audio, graphics and window management, assets, and storage. "

Read more here..

http://developer.android.com/sdk/ndk/index.html

Siegfried

felipemdc

  • Administrator
  • Hero Member
  • *
  • Posts: 3538
Re: Android NDK
« Reply #1 on: January 13, 2011, 03:23:33 pm »
It is good news for OpenGL apps, but the entire GUI APIs are still unavailable. One can access them with my Java-to-Pascal bindings, however.

siegfriedn

  • New Member
  • *
  • Posts: 22
Re: Android NDK
« Reply #2 on: January 14, 2011, 10:48:48 am »
[discussion]

Does it mean that you do not need the c headers and have the 'pascal bindings' directly accessing the Java GUI API?

If so and it is the only way..

A. This sounds very efficient from a Lazarus/FPC perspective. Brilliant actually! :)

However to consider..

A. Some Android functionalities may only be accessed via the Android NDK API.
B. It may be more sophisicated to do the direct pascal bindings.
C. The c headers may be a level of abstraction that may shield us from future changes to the Android API?
D. OpenGL apps:
The indusctry trend is to move all GUI to OpenGL, think WPF, Wayland (replacement if X11.org ~ New Unity DE for Ubuntu). Does it mean that there will be a different Lazarus/FPC API (bindings) for the Android OpenGL API?
How does this fit in with the LCL ?

Siegfried


felipemdc

  • Administrator
  • Hero Member
  • *
  • Posts: 3538
Re: Android NDK
« Reply #3 on: January 14, 2011, 12:20:20 pm »
Does it mean that you do not need the c headers and have the 'pascal bindings' directly accessing the Java GUI API?

You can use both at the same time. In my current hello world I use only Java APIs in Pascal, but I am considering using native APIs for logging for example (unit log.pas in the lazarus-ccr bindings/android/ndk/log.pas). They are faster. If a native API is available, then the native API should be prefered. If only a Java version is available, no problem, we can use the Java version =) I am writing an article about this for the Blaise Pascal magazine.

Quote
A. Some Android functionalities may only be accessed via the Android NDK API.

As explained above, no problem. You can still use the NDK too.

Quote
B. It may be more sophisicated to do the direct pascal bindings.

It already works, just needs to be extended to support more classes / more methods.

Quote
C. The c headers may be a level of abstraction that may shield us from future changes to the Android API?

So far they are keeping backwards compatibility in the Java APIs. I don't have much experience in the NDK ones, and the entire NDK is too new to tell if it will have a good backwards compatibility.

Quote
D. OpenGL apps:
The indusctry trend is to move all GUI to OpenGL, think WPF, Wayland (replacement if X11.org ~ New Unity DE for Ubuntu). Does it mean that there will be a different Lazarus/FPC API (bindings) for the Android OpenGL API?
How does this fit in with the LCL ?

The Android Java GUI API uses OpenGL deep down.

I think that a LCL interface for Android could combine native GUI elements and OpenGL widgets (for TCustomControl descendents) together to achieve the best result.

A fully OpenGL LCL interface would be possible too, but it is a huge, imense work. And when you get the basic functionality done you will realise that you have no arabic letter joining, no virtual keyboard, etc, etc, etc. All features which are automatically taken care by native components.
« Last Edit: January 14, 2011, 12:21:51 pm by felipemdc »

 

TinyPortal © 2005-2018