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: