[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions regarding the use of EDICT2 and/or JMDICT in a mobile app



Nils,

I'm in really early planning stages right now, not to mention the fact that I've got to learn how to program for Android, so I'm not even sure what my main priorities are. Paid apps on Android don't seem to be as well-received as they are on iOS (according to sales figures for each platform), so maybe open-sourcing this project and asking for tips is the way to go...

In any case, I'm going to sit down and plan this out a bit more before I jump into the code itself. I want to have a solid vision for where I want to take the app so I don't get lost in "ooh, this might be nice!" feature creep.

-Matt


On Wed, Jan 9, 2013 at 7:15 AM, Nils Roland Barth <jmdict.nbarth@********> wrote:
Hi Matt,

General interest comments here, more detailed ones in direct mail.

Matthew Miller:
> [...Aedict build problems...]

It is possible to build Aedict, but you need to use an older
build environment, as detailed here:
http://code.google.com/p/aedict/wiki/Compile
(Updating the build would also be a good project ;-)

> I might want to sell my app on Google Play, and I don't want to run
> into any issues from using source code directly out of Aedict.

To be clear:
* If you use Aedict code, the resulting program is GPL (v3)
* You’re welcome to sell GPL software on Google Play

  You would need to provide the source, so people can build
  and install it themselves (unlikely), and someone else could
  build and post it (more likely, but might not happen, or
  not for a while – little benefit to them).

So if commercializing your app is a priority, you’re
probably better off starting from scratch, as you suggest,
but it’s not strict
(JED has a similar goal.)

> Coming from a web developer background, my first instinct is to use a DB
> engine like SQLite to handle all the hard work of querying info, but I
> won't discount anything until I take a closer look at the methods you
> mentioned.

If you’re more interested in UI etc., abstracting away
implementation details is fine, though IME responsiveness is
a key issue on mobile – laggy/janky apps are very frustrating.

This requires lower-level optimization though, and may not
be necessary, depending on your goals – for me responsiveness
is the sine qua non of a mobile dictionary.

> Is there a better avenue of discussion for development-related questions?
> I don't want to get this mailing list off track.
> If you wouldn't mind, I'd like to get in contact with you from time to
> time to get some clarification or to simply bounce ideas off of you.

Yes, feel free to email me directly.

I’m more interested in supporting Free Software, so if you
use a free license (GPL etc.) I could be more helpful (and
actually contribute code).

However, I’m also interested in supporting JMDICT, and we
sorely need better Android dictionaries, so I’d certainly be
happy to provide reasonable assistance!

  ~nils