Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #30541 > unrolled thread

casting/converting android API calls to java.awt objects

Back to article view | Back to comp.lang.java.programmer

Contents

  casting/converting android API calls to java.awt objects me <noone@all.net> - 2014-12-11 21:45 +0000
    Re: casting/converting android API calls to java.awt objects Joerg Meier <joergmmeier@arcor.de> - 2014-12-12 16:49 +0100
      Re: casting/converting android API calls to java.awt objects me <noone@all.net> - 2014-12-12 22:44 +0000
        Re: casting/converting android API calls to java.awt objects Joerg Meier <joergmmeier@arcor.de> - 2014-12-13 09:47 +0100
          Re: casting/converting android API calls to java.awt objects me <noone@all.net> - 2014-12-13 09:40 +0000
    Re: casting/converting android API calls to java.awt objects Roedy Green <see_website@mindprod.com.invalid> - 2014-12-15 16:57 -0800
      Re: casting/converting android API calls to java.awt objects me <noone@all.net> - 2014-12-16 07:36 +0000

#30541 — casting/converting android API calls to java.awt objects

I'm creating a bunch of custom graphics displays for an android app using 
the Canvas object to paint my 2D primitives onto an 
android.graphics.Bitmap.  However, I'm not ready to put these custom 
screens into Activities and push them to either a real android device or 
the emulator at this point.  I simply want to see the screens on my 
desktop using traditional awt/swing classes.

What is the most direct way to cast or convert an android.graphics.Bitmap 
object to something that can go into the paint(Graphics g) method of an 
awt widget, while maintaining image/pixel format information?

The code compiles fine on the PC with the correct classpath pointing to 
the ADT libraries, it doesn't appear that there are any trivial Bitmap 
conversion methods to bridge android->PC.

[toc] | [next] | [standalone]

#30549

On Thu, 11 Dec 2014 21:45:59 GMT, me wrote:

> I'm creating a bunch of custom graphics displays for an android app using 
> the Canvas object to paint my 2D primitives onto an 
> android.graphics.Bitmap.  However, I'm not ready to put these custom 
> screens into Activities and push them to either a real android device or 
> the emulator at this point.  I simply want to see the screens on my 
> desktop using traditional awt/swing classes.

> What is the most direct way to cast or convert an android.graphics.Bitmap 
> object to something that can go into the paint(Graphics g) method of an 
> awt widget, while maintaining image/pixel format information?

> The code compiles fine on the PC with the correct classpath pointing to 
> the ADT libraries, it doesn't appear that there are any trivial Bitmap 
> conversion methods to bridge android->PC.

You would likely benefit from abandoning this pretty doomed path and
looking into LibGdx, which is a graphics library that lets you write code
that compiles to backends on both Android and desktop (as well as HTML5 and
iOS). That way, you can do exactly what you seem to want - develop on
desktop, and only test the finished code on Android.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#30553

On Fri, 12 Dec 2014 16:49:07 +0100, Joerg Meier wrote:

> On Thu, 11 Dec 2014 21:45:59 GMT, me wrote:
 
> You would likely benefit from abandoning this pretty doomed path and
> looking into LibGdx, which is a graphics library that lets you write
> code that compiles to backends on both Android and desktop (as well as
> HTML5 and iOS). That way, you can do exactly what you seem to want -
> develop on desktop, and only test the finished code on Android.



I'll give it a look.  thanks.

I did manage to get the android.Graphics.Bitmap into an java.awt.Image 
via an integer array, but of course the bimap methods for android called 
some android hardware native methods (for optimization I'm guessing) and 
it went to hell in a handbasket quickly.  Which brings up the point: 
would libGDX do me any good, since the problem I had was that the  
android jar files called native methods that dont exist on the PC?  The 
base code I'm writing is ultimately FOR android.

It is important to me that I be able to develop and unit test non-
hardware specific code directly on the PC, and deal with eclipse and 
android emulator only when really necessary.

[toc] | [prev] | [next] | [standalone]

#30562

On Fri, 12 Dec 2014 22:44:08 GMT, me wrote:

> On Fri, 12 Dec 2014 16:49:07 +0100, Joerg Meier wrote:
>> On Thu, 11 Dec 2014 21:45:59 GMT, me wrote:
>> You would likely benefit from abandoning this pretty doomed path and
>> looking into LibGdx, which is a graphics library that lets you write
>> code that compiles to backends on both Android and desktop (as well as
>> HTML5 and iOS). That way, you can do exactly what you seem to want -
>> develop on desktop, and only test the finished code on Android.
> I'll give it a look.  thanks.

> I did manage to get the android.Graphics.Bitmap into an java.awt.Image 
> via an integer array, but of course the bimap methods for android called 
> some android hardware native methods (for optimization I'm guessing) and 
> it went to hell in a handbasket quickly.  Which brings up the point: 
> would libGDX do me any good, since the problem I had was that the  
> android jar files called native methods that dont exist on the PC?  The 
> base code I'm writing is ultimately FOR android.

It depends - it will not do you any good with the code you currently have,
as from the sounds of it, you're "doing it wrong"(tm).

> It is important to me that I be able to develop and unit test non-
> hardware specific code directly on the PC, and deal with eclipse and 
> android emulator only when really necessary.

But yes, it will let you do that, as that is exactly what it was made for.
You can pretty much write your entire game (or whatever you are making) on
the desktop, and only test the finished code on Android/the emulator to
deal with the little quirks where things work on desktop but not on Android
(like, say, memory related).

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#30563

On Sat, 13 Dec 2014 09:47:40 +0100, Joerg Meier wrote:

> 
>> It is important to me that I be able to develop and unit test non-
>> hardware specific code directly on the PC, and deal with eclipse and
>> android emulator only when really necessary.
> 
> But yes, it will let you do that, as that is exactly what it was made
> for. You can pretty much write your entire game (or whatever you are
> making) on the desktop, and only test the finished code on Android/the
> emulator to deal with the little quirks where things work on desktop but
> not on Android (like, say, memory related).

I looked at libGdx.  I'm not convinced it's worth "the cost", especially 
since at that point I've introduced a 3rd party library requirement into 
my project, just for the convenience of developing what should be 
"platform neutral" functions on the PC.  I think it makes more sense in 
this case to bite the bullet and stage the code on the android emulator 
and not have to deal with the libGdx quirks like selective garbage 
collection requirements.  I want the code to be as android specific as 
possible.  I just thought I might get lucky but I'm now thinking that 
something even as trivial as packing bitmaps with graphics primitives are 
going to probably have some native JNI code to optimize the memory 
operations, thus prohibiting any real platform portability.

[toc] | [prev] | [next] | [standalone]

#30571

On Thu, 11 Dec 2014 21:45:59 GMT, me <noone@all.net> wrote, quoted or
indirectly quoted someone who said :

>
>What is the most direct way to cast or convert an android.graphics.Bitmap 
>object to something that can go into the paint(Graphics g) method of an 
>awt widget, while maintaining image/pixel format information?

I would suggesting using the emulator. That is what it is for.

Basically you are asking for a lightweight emulator of just one class.

You could do it by writing your own class with methods matching the
android ones you use, but that make calls to AWT Image/BufferedImage
classes to implement the methods.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Software is a gas; it expands to fill its container.
~ Nathan Myhrvold (born: 1959-08-03 age: 55) Nathan’s First Law

[toc] | [prev] | [next] | [standalone]

#30572

On Mon, 15 Dec 2014 16:57:51 -0800, Roedy Green wrote:
> 
> I would suggesting using the emulator. That is what it is for.
> 
> Basically you are asking for a lightweight emulator of just one class.
> 
> You could do it by writing your own class with methods matching the
> android ones you use, but that make calls to AWT Image/BufferedImage
> classes to implement the methods.



The stumbling block is the JNI stuff that is throughout the ADT code. In 
hindsight I'm not surprised.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web