search

PanicInitiative / PanicButton

Panic Button turns your mobile phone into a secret alarm for when you're in trouble
https://panicbutton.io
GNU General Public License v3.0
200 stars 99 forks source link

Discuss JSON based declarative UI refactor #73

Open jmatsushita opened 9 years ago

jmatsushita commented 9 years ago

http://www.theguardian.com/info/developer-blog/2014/dec/11/functional-android

jmatsushita commented 8 years ago

Oh... Retrolambda and RxJava with Retrolambda. Sweet.

jmatsushita commented 8 years ago

Moving the broader refactoring of declarative UI derived from JSON/Markdown from #82 to this issue.

Other things to get some inspiration from:

Relevant quotes from #82

Some of it is the result of separating content for the wizard (in the assets folder) which is generated from a jekyll based site, allowing content editor to use Prose to submit content updates to the github repo which trigger a rebuild of the site, including a json version which used to be consumed directly by the app. It is now generated once and baked into the APK. The advantage of this is that it allows content editors to be able to modify the content of the website and of the wizard from a single, simple interface. The downside is that it is a non standard way to manage content in an Android app, adds an extra step in the generation of the APK, and is currently implemented as a content database which slows down the startup of the app (#75).

And

All of this was the result of decisions to make the system flexible and driven by markdown files (with frontmatter) in github. The markdown files (such as this one) would then be built (using this jekyll template) into a versioned JSON file. Note that we also did the same thing to share the Help section between the Android app and the Website.

I have been thinking also that maybe we don't want to loose the flexibility of the system, but I was also attracted to the possibility of simplifying it, given that it can be a source of bugs and therefore security flaws. Could you do a little bit of research to see if others are using a similar approach or not, so that maybe we could move to using a library instead of doing it ourselves? There is also the possibility to build this into a library... Do you think that would be a possibility?

Please note that storing JSON in the string is not satisfying given that we want to make the translation easier.

So maybe a better approach is to do as follow:

  • Keep the flexible UI system and start thinking about it as a library.
  • Go back to thinking of the panicbutton.io github repo as being the master for the android content. (this might require some changes to be done upstream to the content).
  • Include a step in the build process to download the api/*.json files (maybe remove the versioning and just compare to remove the manual steps needed previously in the Jekyll build).
  • Manage the translation at the level of the markdown files (this would mean doing the reverse of what I've been saying and moving things out of the strings.xml and into the markdown). I've tried this but Transifex only manages plain text files or YAML separately, not markdown with a frontmatter (which creates lots of noise for the translator with keys that are relevant and others that shouldn't be translated).

Also iilab/openmentoring-mobile#4 uses a similar approach via ionic. And I'd be keen on converging.

jmatsushita commented 8 years ago

Also this approach of creating XML which are converted to POJOs at runtime is quite interesting.

jmatsushita commented 8 years ago

Anko is also really cool as a DSL but probably generating Java is not a good idea... There could be a isomorphic representation though I bet, in some kind of JSX way...

And of course there's StoryPath from Story Maker which porbably doesn't have to deal with the backstack but is a very well thought out declarative UI DSL for Android too.