[Ohrrpgce] Android port

[Ralph Versteegen]

On 7 June 2013 04:18, Simon Bradley <neworiginal at gmail.com> wrote:
> On Thu, Jun 6, 2013 at 4:44 PM, James Paige <Bob at hamsterrepublic.com> wrote:
>>
>> On Thu, Jun 06, 2013 at 04:16:32PM +0100, Simon Bradley wrote:
>> >    On Thu, Jun 6, 2013 at 3:22 PM, James Paige <Bob at hamsterrepublic.com>
>> >    wrote:
>> >
>> >      On Thu, Jun 06, 2013 at 01:28:10PM +1200, Ralph Versteegen wrote:
>> >      > On 6 June 2013 02:19, James Paige <Bob at hamsterrepublic.com>
>> > wrote:
>> >      >
>> >      > > For people who don't have their own domain name, we can provide
>> > a
>> >      > > namespace like com.hamsterrepublic.ohrrpgce.games.gamename but
>> > I
>> >      would
>> >      > > also like to allow people to specify their own namespaces, so
>> > for
>> >      your
>> >      > > own game, tmc, you might choose to use
>> >      > > com.castleparadox.tmc.foresttemple or maybe Mogri would want to
>> > use
>> >      > > com.slimesalad.phantomtactics or Harlock might use
>> >      > > org.crithit.spellshard
>> >      >
>> >      > Is there any point to allowing customisation of namespace? I
>> > think it
>> >      > just has to be unique, eg a com.hamsterrepublic.ohrrpgce.games.
>> >      > prefix.
>> >      > I see that the Android documentation says "To avoid conflicts
>> > with
>> >      > other developers, you should use Internet domain ownership as the
>> >      > basis for your package names (in reverse)."
>> >
>> >      Well, from a making-things-work perspective, no, there is no point
>> > to
>> >      allowing people to specify their own namespaces, but from the
>> >      perspective of people signing their own games and uploading them to
>> > the
>> >      google play store, I would like to give people that option,
>> > especially
>> >      for people who are going to sell their games rather than post them
>> > as
>> >      free apps.
>> >
>> >      Someone can still sell their game with a name in the
>> >      com.hamsterrepublic.ohrrpgce.games.* namespace, but by doing so the
>> > are
>> >      trusting me as the owner of that domain to behave honorably about
>> > it :)
>> >
>> >    The simplest way would presumably be to make the ohrrpgce a library
>> >    project and wrap it with the new namespace, I think:
>> >
>> >    package com.newnamespace.myrpg;
>> >
>> >    public class MainActivity extends com.ohrrpgce.games.OHRActivity
>> >
>> >    etc.
>> >
>> >    I believe that would work. That seems to be how these examples I am
>> >    looking at are set up.
>> >
>> >    (I am actually working on an Android project right now for my day
>> > job, but
>> >    it's been a while and I'm a bit rusty. And someone else has already
>> >    written it; I'm just changing it.)
>> >
>> >    Cheers,
>> >    Simon
>>
>> Hmm... If that is the only way to change the namespace, then it sounds
>> like having the Android SDK installed and recompiling the project would
>> be required. Maybe it isn't worth it if it is that much trouble?
>>
>> Even though I want people to be able to customize the namespace of their
>> game, I guess that should be a low-priority goal :)

Don't forget that while allowing the user to select the namespace is
low-priority, packaged .apks still need to have unique namespaces,
otherwise Android will consider them all as the same program.

> Ah, yes. Maybe not ideal. It might be possible to change it with something
> like proguard instead, in the compiled version.

There's an additional problem. It turns out that in addition to all
the Java code, lots of the C code in the SDL port requires the
namespace to be compiled in too. I have no idea how JNI works, but it
appears that Java code like...

package com.hamsterrepublic.ohrrpgce.game;
class AudioThread
{
    private native int nativeAudioInitJavaCallbacks();

requires an implemention provided by a C function named
Java_com_hamsterrepublic_ohrrpgce_game_AudioThread_nativeAudioInitJavaCallbacks!

However perhaps by using Simon's library suggestion we can use a
separate namespace for all of the code compiled into the .so files,
leaving just the xml metadata and compiled Java files to worry about.

In order to edit the namespace in compiled Java code we would have to
modify .dex files (targetting .class files instead would mean still
having to convert them to .dex and requiring the NDK). Looking around
a bit I see there are a couple projects like smali/baksmali
(https://code.google.com/p/smali) for disassembling/reassembling a dex
file.  It sounds a whole lot simpler to just set up a web server which
compiles the required java source files with desired on request :)

Unless creating a single trivial java module which includes everything
else is enough; in that case smali/baksmali could be practical, or
even a small edit to the right offset in the file...