Elsewhere there are things that we all miss, yet it takes just one to notice...

Good and bad for embedded and Android

Embedded Linux is the bees knees for doing a lot of things, especially when you really don’t want the Android overhead on top of it. For a device such as the Odroid range which can be used as a headless server providing and IPTV gateway and a web interface for controls, linux is the better option.

When it comes to graphical applications, for example decoding video streams and openGL rendering, it always becomes a toss up between Linux and Android. A lot of people who are familiar with Java will automatically pick Java and I have to say, I do actually like the Java Virtual Machine. The JVM is handy whilst developing because a crashed application just gets cleared out.

Qt can also be used for developing mobile applications and has a very extensive framework and because it’s C++, time critical code isn’t a problem.

The only issue I have with Qt is that when it comes the day when I do want to release and application for whatever it is I finally do, packaging it up for all OS’s becomes a pain.

Qt for Android is easy, just build the project and get the APK. Just one file and it can be copied to any Adroid device.

Qt for Windows is a nuisance because you have to faff about with the terminal (which is awful in Windows) to package all the required libraries, and then it’s not guaranteed to run straight out of the box. For Windows you have to use a dependency walker to find the missing libraries.

Qt for Linux isn’t too bad unless you want the latest libraries. At this moment you can install Qt5.5 from the Linux repositories and away you go. Unfortunately, the latest version of Qt is 5.7 with some very nice additions so it’s back to packaging stuff up.

For embedded Linux it would have to be Qt from the Linux repositories.

For Android it is still a toss up between Qt and Android Studio + NDK. Although if I could get away with it I would use Qt and Linux unless it was going to be an application for the Android market.

Eclipse update and GWT

After upgrading from Linux Mint 17.3 to 18, I found that the minimum Java available was 8. For GWT projects, up to 7 is allowed because there are issues running with Java 8.

So, I deleted Eclipse ready to install the latest. It installed fine. Still some issues along the way with Java 7 and 8 with GWT.

Eventually I installed Oracle Java 7. So far so good.

After finding that there is no longer support for Android in eclipse and installing all the Android stuff I cleared eclipse again. Actually I removed Eclipse a few times until I got Java 7 and 8 and all the GWT web stuff. Including Java EE version of eclipse.

Now I’ve figured out how to run a GWT project straight out of Eclipse without needing to upload onto the Apache server too. This makes for much faster build times. However, one cavaet is that I will have to create a linux group and add my user to the group next so that Tomcat7 and my user can read/write to the servers home directory.

Having sped up the build times, development of GWT projects will be so much easier and less time consuming. I will only need to deploy to the Apache main server when it has all been done. All I need to do is to save all files that I’ve been editing, click refresh in the server pane in Eclipse and go to the page in the browser. The browser will then tell the project to build itself the changes made.

Good stuff for a few hours of headaches.

LibGdx TextureAtlas (non .pack file)

Okay, I hit a block when I was starting to think about writing a quick networked multiplayer shoot em up game in LibGdx.

LibGdx texture atlas’s are very handy things because you can store a load of smaller images in one image. This also optimises the GPU draw routines because it doesn’t have to keep swapping textures for each sprite drawn.

I found pre-made free to use sprites from Kenney.nl, below is a section of what they look like:

spritesheet

Unfortunately though, LibGdx uses .pack files for it’s texture atlas’s and this one come with one that looks like this:

<TextureAtlas imagePath="sprites.png">
 <SubTexture name="spaceAstronauts_001.png" x="998" y="847" width="34" height="44"/>
 <SubTexture name="spaceAstronauts_002.png" x="919" y="142" width="37" height="44"/>
 <SubTexture name="spaceAstronauts_003.png" x="824" y="0" width="50" height="44"/>

...
</TextureAtlas>

Which is completely different to a .pack file.

So without further ado I decided to test out an xml parser to retrieve all the sub-regions from the xml file.

Test code as follows:

[snippet id=”19″]

So, armed with this now, all thanks mainly to working with GWT, I can quickly move on to creating my own class to generate the texture atlas in LibGdx.

Android load and scale a bitmap

Before I move onto the application itself, I was testing out loading in and scaling a bitmap, when I came across a very annoying Out Of Memory error. The image I was testing was ~4000 x ~3500 pixels and the test was running in the android emulator.

Initially, after using the android logging I found the image wasn’t being scaled and I couldn’t load it in and then scale it. And I didn’t want to up the memory on the emulator.

I know I needed an AsyncTask to do this, plus I needed to figure out how to implement them anyway as I’ve used Async’s in GWT extensively.

Eventually after a bit of digging around I eventually found out how to get everything done and it doesn’t waste any memory.

After this has been done, I want to figure out how to display a large image with a zoom option.

See below for the code…

[snippet id=”15″]

TCP home server test client

With the previous post setup I’ve written a very basic example of how to test the server. At the moment, there are no back and forth communications, just a simple send of a 4 byte header.

Run the server program first, and then run the test. These can actually be run in the same order from Eclipse.

The good news is, this also works over the internet. The ‘Global’ in the code hold a string of my web server address and also the port that my router has open.

So, all working as expected.

[snippet id=”11″]

The output from the server will be:

WLGfx Home Server - Starting up
Shutdown hook attached
TCP Server thread started...
TCP Incoming socket handler
Got header: HEAD

Java server test 1 [UPDATED]

My first test for Java as a console daemon. There’s not much here at the moment and the project is in Eclipse IDE.

From Eclipse, right click on the project and select export and then export as a runnable jar. Then in the terminal just type:

java -jar myexportedjar.jar

The JVM will continue to run as long as there are non daemon threads still running as in the below code. Also note that the hook handler allows catching of CTRL+C and other errors.

UPDATE:

I’ve now added the actually tcp server code which has a timeout on the server socket to allow for the thread to shut down safely. And a thread to handle each incoming connection.

[snippet id=”9″]

(I’m currently not well at the moment but I’m plodding on with some studies.)

Posts navigation

1 2 3
Scroll to top