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

Author: csnorwood

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.

Re-install PC

I’ve recently upgraded from Linux Mint 17.3 to 18 and although everything else is working just fine, the tomcat server doesn’t. The client side of a web application works but there’s no joy from the server side so zero RPC calls are working.

A fresh install will be good anyway as it will clear a lot of junk out.

Ah well, should be about 30 minutes to an hour installing most of my software back. It’s handy having a nice 480Gb SSD and decent download speeds.

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.

TCP internet communication notes

Now that I’ve got that working over the internet, there are many things that this kind of thing can be used for. Most of them are obvious, but a few I’ve had in mind for some time now.

  1. For an app running on a device, it can download media specific to that device. ie, scaled to fit the resolution.
  2. A device can be checked for memory and storage space limits and then download media that is optimised for the device to run the app.
  3. Even for 3D apps, a device can request 3D meshes optimised to run on that device depending on the graphics capabilities. This can be useful for animated meshes with lots of vertices. The server can reduce the size of the mesh and the animation.
  4. If a device can output in surround sound then audio can requested that supports surround sound.
  5. Multiplayer games. The server can receive players positions and then send the local information back out to other devices.
  6. Devices can also send data to the server. This can be for a multitude of reasons. ie. a players profile picture or for audio communication between players.

As you can see from the above, there’s no limit to what a running server can do.

One thing I will have to do soon is to handle brute force attacks on the server. This happens when a DoS (Denial Of Service) attack occurs, which is a deliberate attack in which lots of data is sent to the server continuously. The simple way around this is to have a damn good fast CPU in the server and to record IP’s that are connecting. If an IP is not requesting the usual data and has attempted X amount of times then it goes onto a block list. Each connection attempt will first check the block list and instantly close the connection if that IP is blocked so that no further time is spent processing the connections request. At this current moment in time the Intel Xeon and the latest Intel i7’s have the cores that could handle DoS attacks.

Multiplayer games requires a whole new line of thinking, especially when they’re real time. Band width can be a pain, but there are many ways to get around this. In one of the above notes, I mentioned ‘local’ data. This comes into play when a players device only needs to receive the local updates in the surrounding area. Although the server will handle all players, it will only send each device its local data.

Anyway, that’s me done for now while I think of what to do next.

Any ideas, then get in touch.

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″]

Notes on encryption and security

An important part of communicating over the internet is having some security in place. For my own project this will have the server setup so that it only accepts connections from known devices. It will also encrypt data before it is sent and decrypted when the server receives it.

Encryption:

There are many ways to encrypt data:

  1. Inverting all bits in the data being sent. This was handy in the very old days of 8-bit cpu’s to hide data in memory to stop people spying on code and data in memory.
  2. Apply a key to the data. A good method of securing data which could be a password protected to unlock on the receiving side. However, it doesn’t take long for key to be found.
  3. Apply a key and add salt. Skewing the data like in method 2 is good, but when adding salt, it makes it almost impossible to decrypt without having access to the code.

I’ll be using a system which adds a key and pours in some salt. Now how this is done is using a key to skew the data, and then by splitting the bits of the data up randomly and adding random bits in between, the bitstream will be larger but impossible to decrypt. 2 things will be needed to decrypt the data, the code itself and the key.

Security:

Most of the time, security means logging in with a username and password. The final project will require the device to first log in which will have a timeout feature on it. This is just like session handling in GWT for the web. The login data will still be sent encrypted.

Fortunately, I’ve worked with encryption since 8-bit cpu’s, so this shouldn’t pose a problem for me at all. I’ll have some generic classes written that can be used on both client and server for de/encryption. Apart from the usual login credentials, the client and server will have some hardcoded (still encrypted) transport keys, which can be updated when software is updated. The server can also handle software updates which includes data security updates. This will mean that software that isn’t updated will no-longer work unless it gets an update.

Obviously, this means a lot of boilerplate code, but it will be worth it. And hiding it from a web interface by using TCP, it will be more secure.

One last thing to note about security is server/port attacks. On each socket connection, the server will log the number of requests from an IP address. It it gets too many then it will ignore that IP address for 30 minutes or another set time. This will reduce DoS attacks on the servers port/s.

When the application is transferring data back and forth to the server, most of the communication will be done in one connection. Too many connection attempts will simply be denied.

Posts navigation

1 2 3 … 8 9 10 11 12 13
Scroll to top