Blog Post: How does mill build android apps

[vaslabs]

An introductory blog post for Mill's android support. I tried to focus on celebrating mill's design in helping to add all this android support. I think I need a better title, please let me know your ideas and also feedback for the content.

Also added a page in the android docs for the native endless tunnel example (so as I can also reference it in the blog post).

[lefou]

Nice article. I think the diagrams are a real value, even to non-Mill users. I once had a rudimentary android build working with sbuild (my personal predecessor of Mill) around 2014, where Android builds where simpler, but even then, it was hard to get these dependencies out from pure documentation. Reverse engineering is required to get the whole picture and your work here is really appreciated.

[vaslabs]

Nice article. I think the diagrams are a real value, even to non-Mill users. I once had a rudimentary android build working with sbuild (my personal predecessor of Mill) around 2014, where Android builds where simpler, but even then, it was hard to get these dependencies out from pure documentation. Reverse engineering is required to get the whole picture and your work here is really appreciated.

thank you!

[vaslabs]

Fixed the links and added a page in the android docs for the native endless tunnel example (so as I can also reference it in the blog post).

I shortened the diagram, but it still overflows

if you have any ideas how to fix it, if it's an issue

[lihaoyi]

Some comments on this:

1. We should definitely have screenshots/demos of things that work: Emulator, IDE, etc. That makes it look a lot more "real" than just describing things in words.

2. Less generic Mill praise (e.g. "This was possible because Mill’s design, incremental, transparent, and extensible maps surprisingly well onto Android’s intricate build process."), more of a user-perspective of why they may be interested in this. Is it easier to set up? Does it build faster? Is it easier to extend? How can we demonstrate these attributes in a concrete way that people who don't care about Mill at all can understand and appreciate? This will help motivate the blog post and tell users why they should care about the technical accomplishment and implementation details discussed below

3. The Try it Out section needs complete, concrete, copy-paste-able commands rather than instructions like Clone one of the example Android projects. Download instructions should come with curl commands or clickable links. We need to hook people into trying this out before they get bored and leave, and asking them to go to another page of the docs and try to figure it out will result in a lot of people just giving up

[vaslabs]

Some comments on this:

1. We should definitely have screenshots/demos of things that work: Emulator, IDE, etc. That makes it look a lot more "real" than just describing things in words.
2. Less generic Mill praise (e.g. "This was possible because Mill’s design, incremental, transparent, and extensible maps surprisingly well onto Android’s intricate build process."), more of a user-perspective of why they may be interested in this. Is it easier to set up? Does it build faster? Is it easier to extend? How can we demonstrate these attributes in a concrete way that people who don't care about Mill at all can understand and appreciate? This will help motivate the blog post and tell users why they should care about the technical accomplishment and implementation details discussed below
3. The Try it Out section needs complete, concrete, copy-paste-able commands rather than instructions like Clone one of the example Android projects. Download instructions should come with curl commands or clickable links. We need to hook people into trying this out before they get bored and leave, and asking them to go to another page of the docs and try to figure it out will result in a lot of people just giving up

Thanks. I've made the adjustments. In some place, I put comparison with Gradle and in other a generic "other build tools", I'm not sure which one you'd prefer, but when you get the chance, let me know of any more feedback

[lihaoyi]

Let's leave out fast, predictable here. Whether or not it's true, it sounds too salesly. Let's just say "Mill provides an alternative to Gradle that is easier to use and learn", and hope that enough people have had trouble with Gradle that they empathize

[lihaoyi]

Is there any angle we can discuss of Mill being easier to setup v.s. Gradle in terms of the number of manual steps? Or more performant, in terms of time-to-update-the-app? We should try to discuss some user-facing benefits in a way people can see for themselves why it's cool, rather than just "Mill is fast and predictable because we say so", so they are more engaged for the internal technical discussion below

[lihaoyi]

This should probably be a bullet-point list, so it's easier to skim: each bullet can either be a technical feature or tool-integration, or a demo or example app that we got working.

That way users can quickly look at it and see that it hits many of the requirements for day-to-day work developing Android apps, v.s. now they have to read a sentence and try to parse the important parts out of it

[lihaoyi]

The obvious question to me here is: is this not true of Gradle? Maybe it's not, but you have to show that in more detail for me to understand why Mill is cool

[vaslabs]

ok, yeah I have an idea how to show it and connect it with the diagram above (i.e. using inspect) . I think, at least empirically, it's true for gradle too, as a lot of times it wasn't obvious what steps were followed to build android apps and we had to do some reverse engineering. but again, I'm not an expert in gradle to know any tools to inspect its internals, but that's another point, you shouldn't be an expert to use and extend the tool, so I think I'll demonstrate the points in my comments here

[lefou]

Maybe the output of plan, visualizePlan, visualize or path can help showing what's going on under the hood. It will also show what default tools users have to explore an unfamiliar project.

[vaslabs]

thanks for the comments, I will come back to this tomorrow or the day after (just fyi)!

[vaslabs]

I think I've addressed the comments, if you could do another review. There's time as I want to get the latest mill version in the example so it's compatible with the build.mill I'm referencing which I should also update to the most recent I can so it's easier for me to reason and test the content

[lefou]

Minor things

[lihaoyi]

@vaslabs now that 1.0.5 is out with your latest improvements to the android toolchain, shall we finalize this blog post and publish it?

[vaslabs]

@vaslabs now that 1.0.5 is out with your latest improvements to the android toolchain, shall we finalize this blog post and publish it?

Yes, I will get on with it today!

[vaslabs]

I added the following gif as well after the android test, but it's the first one as far as I can tell, let me know if you'd prefer it wasn't there, or if you like it I can make a gif for the pokedex app or native app instead of showing a static image, showing more liveness is good imo for demo purposes.

[vaslabs]

updated the versions as well and retested the scripts.

oops, need to update the date too I guess

[lefou]

IMHO an animated GIF is ok, but it should not change content multiple times a second. Give the reader some time to recognize the image, before changing it.

[vaslabs]

IMHO an animated GIF is ok, but it should not change content multiple times a second. Give the reader some time to recognize the image, before changing it.

this one is a live recording when the tests run (without any speedups), I mean it's purpose is to show android tests run in emulator and as fast(?) as Gradle - I haven't done any benchmarks, but my very first implementation was running extremely slow

[lihaoyi]

I'm getting an error trying to build the website on this PR locally

$ ./mill website.fastPages                                      
[2641/2641, 1 failed] ============================== website.fastPages ============================== 1s
1 tasks failed
[2151] example.kotlinlib.basic[2-module-deps].parsed java.lang.RuntimeException: No build file named build.sc/build.mill/build.mill.scala found in /Users/lihaoyi/Github/mill/out/example/kotlinlib/basic/2-module-deps/testRepoRoot.dest
    scala.sys.package$.error(package.scala:27)
    mill.testkit.ExampleParser$.$anonfun$2(ExampleParser.scala:14)
    scala.Option.getOrElse(Option.scala:201)
    mill.testkit.ExampleParser$.apply(ExampleParser.scala:15)
    build_.example.package_.build_$example$package_$ExampleCrossModule$$_$parsed$$anonfun$1$$anonfun$1(package.mill:92)
    mill.api.Task$Named.evaluate(Task.scala:338)
    mill.api.Task$Named.evaluate$(Task.scala:323)
    mill.api.Task$Computed.evaluate(Task.scala:349)

[vaslabs]

I'm getting an error trying to build the website on this PR locally

$ ./mill website.fastPages                                      
[2641/2641, 1 failed] ============================== website.fastPages ============================== 1s
1 tasks failed
[2151] example.kotlinlib.basic[2-module-deps].parsed java.lang.RuntimeException: No build file named build.sc/build.mill/build.mill.scala found in /Users/lihaoyi/Github/mill/out/example/kotlinlib/basic/2-module-deps/testRepoRoot.dest
    scala.sys.package$.error(package.scala:27)
    mill.testkit.ExampleParser$.$anonfun$2(ExampleParser.scala:14)
    scala.Option.getOrElse(Option.scala:201)
    mill.testkit.ExampleParser$.apply(ExampleParser.scala:15)
    build_.example.package_.build_$example$package_$ExampleCrossModule$$_$parsed$$anonfun$1$$anonfun$1(package.mill:92)
    mill.api.Task$Named.evaluate(Task.scala:338)
    mill.api.Task$Named.evaluate$(Task.scala:323)
    mill.api.Task$Computed.evaluate(Task.scala:349)

strange, I had it running let me try again

[vaslabs]

I cleared the out folder but it's still working

could it be some file system difference, I don't know

I don't see this 2-module-deps though

 ls out/example/kotlinlib/basic/
1-simple  2-custom-build-logic  3-multi-module  4-compat-modules  6-realistic  7-dependency-injection

[vaslabs]

only thing I can think of, is when I make some changes and don't track the directory, then mill is complaining with a similar error, could you double check with git status that it's clean?

[lihaoyi]

Sure lemme try on a clean checkout and get back to you

[lihaoyi]

Managed to get it building on a clean checkout. Blog post looks good to me, can merge and publish it whenever you're ready

[vaslabs]

Ok, nice! it's ready then from my side!

[vaslabs]

looks like it failed on some link check but the link seems to be valid, but it's a doc page included in the PR and referenced from the blog post, is this a case of checking blog post links against older versions of the docs?

[lihaoyi]

@vaslabs yes there is version skew: on PRs we build everything against HEAD, but post-merge we build the blog against main and the docs against the latest stable (e.g. 1.0.5). Perhaps you could remove the problematic link for the time being?

[vaslabs]

@vaslabs yes there is version skew: on PRs we build everything against HEAD, but post-merge we build the blog against main and the docs against the latest stable (e.g. 1.0.5). Perhaps you could remove the problematic link for the time being?

that makes sense, yeah will do a PR

[vaslabs]

PR to fix the broken link #5894