RE: Application source options

Jun 19, 2014 at 8:24 PM

I should also add that after reflecting on this for an hour, I think secret option 3 has a lot of merit: Just get the TDH UI going by itself, and finish the remaining (critical) features, such as httpkey pouch support – then after more folks get a chance to handle the code (and it evolves a bit) we make an informed decision on how to proceed with making it easily consumable by others.

From: Stefan Gordon
Sent: Thursday, June 19, 2014 12:18 PM
To: '[email removed]'
Subject: Application source options

I see two reasonable approaches to how we structure the source and developer experience for following our HTML 5 app model.

A bootstrap/seed project

Common with several frameworks (e.g. Angular), we give developers a clean working project structure that builds a hello world application for Desktop and Android, and they take it from there. We would have a folder in our source for something like “Application Sample Project”. The root project can easily be opened in IntelliJ and both platforms can be built in the same IDE instance through the Gradle tasks pane.

Main benefit is that for applications that want more than just HTML5 it is simple for them to add crosswalk extensions, additional common code, or even ‘magic’ URI’s to the proxy layer. They just copy the code and go from there.

Downside is a bit of additional complexity for people that want to only deal with HTML (clone the project, copy/rename it, drop your files in, gradlew build)

A ‘framework’ which takes a web folder as a parameter

So right now there are four child projects, Android, Desktop, Common, Web. The web child project is referenced by both platforms. We could instead pass a parameter to gradle so that you call a script, pointed to your ‘www’ folder, and you get binaries.

You’d still probably need a basic seed project for the web bits, as we do require a trivial manifest and application icon/description, but you’d be copying much less code.

You wouldn’t have the ability to make any modifications or add java code.

I think I’m inclined to start with the top one, because it aligns more to what we need in the short term. Things like the TDH UI will likely be highly customized (installing TDH background services, settings up intents and protocol handlers) so they’ll want to add some code to the Android extension, etc. (and we can always easily spin off option 2 later.) If we went this route we’d be checking in two parent projects with some duplicate code – our new ‘TDH UI’ and a dumbed down ‘Hello World’ sample. Over time they will diverge but initially they’ll be very similar. Obviously we’ll want to pull as much common code out into the Universal Utilities as possible.

For reference on what one of these looks like:

Jun 19, 2014 at 8:47 PM
A few things to chew on.

Naming

I really would like our names to be consistent. All our other projects use 'universal' for what is called 'common' and 'java' for what is called 'desktop'.

Customer

Our first and foremost customer for the HTML5 work are Thali app developers, not the TDH. We want an experience where it is falling off a log easy for them to write up some HTML, press a button and have an Android and Java executables.

Updating

This is the issue that worries me the most. Image

Above is a picture of all the various projects and their rough dependencies. It's a lot of projects and a ton of dependencies. This is, unfortunately, necessary but it a'int pretty. And what really has me concerned is what happens when there is an update? If using ThaliClient's various projects requires using either clone or fork then updates just aren't going to happen. Nobody is going to take an update to ThaliClientCommon if that requires a merge!

My suggestion then is as follows: We need more projects! (Sigh) Something like:
  • ThaliClientUniversalLibrary
  • ThaliClientAndroidLibrary
  • ThaliClientJavaLibrary
then we would add:
  • ThaliClientAndroidExecutable
  • ThaliClientJavaExecutable
The idea being that 99.999999999% of the logic hangs out in the library projects. The Executable projects just bring the final parts together. They should be incredibly tiny. If you are a pure HTML 5 developer then you configure Executable to point to your HTML directory, build and call it good.

If you are the TDH (or anything else reasonably sophisticated) then you would steal some code from the Executable libraries but otherwise wouldn't use them.

But everyone would have a hard dependency on the ThaliClient*Library projects which would contain the vast majority of code and which would then support updating by just changing a version number in a build.gradle file.

Option 3

I'm fine with Option 3 IFF it is NOT in master branch. Master branch should always represent what we believe is our committed approach with code we think works. If we don't think we are ready to make that commitment then we should do this work in a separate branch.

Thoughts?
Jun 19, 2014 at 8:58 PM

Agreed – We should “get it working” outside of master first as I’m sure we’ll learn things over the next few days that will affect decisions, but this is the right direction for naming, etc.

Truth is that today there is basically zero code in the Android and Java/Desktop specific projects, its mostly just a build.gradle and a few lines for an executable wrapper, which leaves us with just “ThaliClientUniversal”. That may change, we’ll see.

Jun 19, 2014 at 9:13 PM
That would be awesome btw, if we just end up with ThaliClientCommon and then two tiny TinyClientJava and TinyClientAndroid projects! But in any case, let's put it in another branch for now, play with it and then merge it when we are ready.